KR102625485B1 - 사물 인터넷 구성가능한 이벤트 및 동작 시퀀싱 프레임워크 - Google Patents

Abstract

사물 인터넷(IoT) 시스템들에서 이용가능한 데이터의 복잡한 이용들을 효율적으로 가능하게 할 수 있는 이벤트 및 동작 시퀀싱 프로세스를 달성하기 위해 다양한 IoT 이벤트들을 함께 상호접속하기 위한 IoT 구성가능한 이벤트 및 동작 시퀀싱 메커니즘들이 개시된다.

Description

사물 인터넷 구성가능한 이벤트 및 동작 시퀀싱 프레임워크

관련 출원들에 대한 상호 참조

본 출원은 "사물 인터넷 구성가능한 이벤트 및 동작 시퀀싱 프레임워크(Internet of Things Configurable Event and Action Sequencing Framework)"라는 명칭으로 2017년 9월 6일에 출원된 미국 가특허 출원 제62/554,753호의 이익을 주장하며, 그 내용들은 본 명세서에 참조로 포함된다.

사물 인터넷(IoT)은 일상적인 객체들을 포함하는 디바이스들이 인터넷 또는 어떤 다른 네트워크 기술을 통해 상호접속되어 데이터를 전송 및 수신할 수 있는 신생 기술이다. 디바이스들 자체는 크거나 작을 수 있고, 센서 데이터를 제공하거나 액추에이터 명령들을 수신하여 동작들을 수행할 수 있으며, 상이한 기능들 및 능력들을 가질 수 있다. 집 내의 IoT 디바이스들의 일부 예들은 감지 센서들, 조명들, 커피 제조기들, 천장 팬들, 냉장고들, 오디오 시스템들, 및 스마트 TV들이다. 복잡한 IoT 디바이스들은 산업 로봇들 및 머신들, 인터넷 게이트웨이들, 스마트폰들로부터 심지어 자율 주행차들(또는 그 구성요소들)까지의 범위에 있을 수 있다.

IoT 애플리케이션들은 IoT 디바이스들에 의해 생성되는 방대한 양의 정보를 처리하도록 구축될 수 있다. 분석 및 데이터 마이닝이 수행되어 원시 데이터에 의해 제공되는 패턴들 또는 경향들을 추출할 수 있다. 전통적인 웹 애플리케이션들은 특정 애플리케이션에 대한 제한된 데이터 세트의 이용가능성으로 인해 수행될 수 있는 분석의 유형의 범위가 대개 제한되었다. 이것은 일반적으로 다양성에서의 제한을 의미하며 반드시 크기에서 그러하다는 것은 아니다. 반면, IoT 기술들은 IoT 디바이스들에 의해 제공되는 다양하고 방대한 데이터 세트의 원시 데이터에 대해 데이터 마이닝을 수행하기 위한 능력들을 제공한다.

IoT 시스템에서 다양하고 때때로 이질적인 "사물"을 연결하는 것이 가능한 많은 애플리케이션들이 있을 수 있다. 예를 들어, 자택 소유자의 일정표 스케줄은 서로 관련되지 않은 다양한 IoT 디바이스들, 즉 커피 제조기, 스피커들, 조명들, HVAC 시스템, 차고 문 여는 기구들, 차들 등과 상호작용하고 제어하기 위해 IoT 집 자동화 시스템에서 이용될 수 있다. 아침에 일어나서, 사용자가 샤워를 하고 있는 동안 그 날의 뉴스가 욕실 내의 스피커들로 스트리밍될 수 있다. 감지 센서는 사용자가 욕실을 나가서 한 잔의 커피를 끓이기 시작할 때를 검출할 수 있다. 유사하게, 다른 감지 센서는 사용자가 직장으로 출발할 준비가 되어 있으면 차고 내의 차를 원격으로 시동을 걸고 차고 문을 열 수 있다. HVAC 시스템은 이후 차고 문이 닫힌 후 에너지 사용량을 절약하도록 조절될 수 있다.

알 수 있는 바와 같이, 전술한 동작들 각각은 이전에 발생한 동작들에 의존한다. IoT 이벤트는 특정한 발생의 검출, 예컨대 사용자가 방을 나가거나 차고 문이 닫히는 것을 감지 센서가 검출하는 것으로 정의된다. 한편, IoT 동작은 그 이벤트의 발생에 응답하여 수행되는 그 결과의 동작이며, 그 예들은 스피커들로의 뉴스의 스트리밍, 차의 자동 원격 시동, 및 차고 문 열기를 포함한다. 그 결과, IoT 이벤트들 및 동작들은 서로 상호관련되고 IoT 시스템들에 의해 제공되는 실생활 편의들의 실현을 허용한다. 집 자동화 이용 사례에서, 사용자의 스케줄은 상이한 발생들에 기반하여 동작들의 시퀀스들을 지시한다. 한 세트의 동작들은 사용자의 정상적인 통근에 기반하여 트리거링될 수 있는 반면, 다른 세트의 동작들은 사용자가 집에서 일하거나 휴가 중일 때 발생할 수 있다. 동작들의 시퀀스는 심지어 사용자가 늦게 일어나는 경우에 지연될 수 있다. 따라서, 이러한 동작들은 미리 프로그래밍된 스케줄과는 대조적으로 실시간으로 발생하는 이벤트들의 검출에 의해 트리거링된다.

IoT 기술들의 주요 가능자들 중 하나는 서비스 계층(SL) 아키텍처들의 사양이다. oneM2M 및 OCF와 같은 표준 개발 조직들(SDO들)은 IoT가 실현될 수 있는 아키텍처 구성요소들을 정의한다. 이러한 구성요소들은 물리적 및 가상 엔티티들, 리소스 모델들 및 표현들, 서비스들 및 능력들, 프로토콜 메시징 등으로 구성된다. 이들 표준들을 구현하는 IoT 디바이스들은 이후 서로 통신할 수 있고, IoT 기술들이 약속한 다양성 및 크기 양쪽 모두에서 큰 데이터 세트들을 제공할 수 있다.

SL 아키텍처들 내에서, 수집된 데이터가 이용되고 처리될 수 있는 다양한 기능들이 제공된다. 하나의 이러한 기능은 oneM2M에서의 이벤트 관리이며, 이 기능은 동작 트리거링이라고 지칭된다. OCF(Open Connectivity Foundation)는 장면들, 규칙들 및 스크립트들을 이용하는 기능과 같은 제한된 이벤트 관리를 갖지만, 이 기능은 동작들을 자동화하는 것에 주로 초점을 맞추고 복수의 동작들을 갖는 이벤트들을 처리하는 것에 초점을 맞추지는 않는다. 이벤트 관리는 시스템에서 이벤트들을 검출하고 이들 이벤트들의 발생에 응답하여 일부 결과적인 동작들을 수행하는 프로세스이다. IoT 시스템들에서, 이것은 많은 소스들 및 유형들로부터의 데이터가 함께 결합되어 전술한 집 자동화 이용 사례에 도시된 바와 같이 더 스마트한 애플리케이션들을 가능하게 할 수 있기 때문에 강력한 능력이다.

IoT 아키텍처들은 여전히 진화하고 있고 애플리케이션들에 이용가능한 방대한 양의 데이터를 어떻게 최상으로 이용할지를 결정하기 위한 시도가 있다. IoT 시스템들에서 이용가능한 데이터의 복잡한 이용들을 효율적으로 가능하게 할 수 있는 최종 프로세스를 달성하기 위해 다양한 IoT 이벤트들을 함께 상호접속하기 위한 IoT 구성가능한 이벤트 및 동작 시퀀싱 메커니즘들이 본 명세서에 개시된다.

이 요약은 상세한 설명에서 이하 추가로 설명되는 개념들의 선택을 간략화된 형태로 소개하기 위해 제공된다. 이 요약은 청구되는 주제의 핵심 특징들 또는 필수 특징들을 식별하고자 의도되는 것도 아니고, 청구되는 주제의 범위를 제한하는데 이용하고자 의도되는 것도 아니다. 또한, 청구되는 주제는 본 개시내용의 임의의 부분에서 언급되는 임의의 또는 모든 단점들을 해결하는 제한사항들에 제약되는 것도 아니다.

첨부 도면들과 관련하여 예로서 주어지는 이하의 설명으로부터 보다 상세한 이해를 가질 수 있을 것이다.
도 1은 예시적인 레드 와인 제조 프로세스를 도시한다.
도 2는 예시적인 IoT 구성가능한 이벤트 및 동작 시퀀싱 아키텍처 프레임워크를 도시한다.
도 3은 예시적인 EASP 리소스 계층구조를 도시한다.
도 4는 요청들을 처리하기 위한 예시적인 리소스 관리자 절차를 도시한다.
도 5는 IoT 시스템 절차에 대한 예시적인 실행 유닛 액세스 검증을 도시한다.
도 6은 예시적인 실행 유닛 상태 처리 흐름을 도시한다.
도 7a는 와인 제조 프로세스의 동작들을 업데이트하는데 이용될 수 있는 단계들을 개략적으로 나타낸다.
도 7b는 업데이트 엔진 이용의 예시적인 이용 사례를 도시한다.
도 8은 예시적인 업데이트 엔진 프로세스 흐름을 도시한다.
도 9는 와인 제조 이용 사례에 대한 예시적인 oneM2M <easp> 리소스를 도시한다.
도 10은 와인 제조 이용 사례에 대한 예시적인 oneM2M <eventState> 리소스를 도시한다.
도 11은 와인 제조 이용 사례에 대한 예시적인 oneM2M <transition> 리소스들을 도시한다.
도 12는 역할들의 예시적인 OCF 아키텍처 예를 도시한다.
도 13은 예시적인 산업 공장 이용 사례를 도시한다.
도 14는 EASP 리소스의 예시적인 상호작용 제어를 도시한다.
도 15는 본 명세서에 개시된 방법들 및 시스템들에 기반하여 생성될 수 있는 그래픽 사용자 인터페이스 상에 표시될 수 있는 예시적인 테이블을 도시한다.
도 16은 도 1로부터의 와인 제조 프로세스 및 oneM2M 실시예를 갖는 예시적인 디스플레이를 도시한다.
도 17a는 개시된 주제가 구현될 수 있는 예시적인 기기간(M2M) 또는 사물 인터넷(IoT) 통신 시스템을 도시한다.
도 17b는 도 17a에 도시된 M2M/IoT 통신 시스템 내에서 이용될 수 있는 예시적인 아키텍처를 도시한다.
도 17c는 도 17a에 도시된 통신 시스템 내에서 이용될 수 있는 예시적인 M2M/IoT 단말 또는 게이트웨이 디바이스를 도시한다.
도 17d는 도 17a의 통신 시스템의 양태들이 구현될 수 있는 예시적인 컴퓨팅 시스템을 도시한다.

IoT 시스템들은 IoT 디바이스들이 크기 및 다양성 양쪽 모두에서 생성할 수 있는 큰 데이터 세트들을 이용, 마이닝, 및 분석하기 위한 많은 능력들을 제공한다. IoT 시스템들에서의 이벤트 관리 능력은 시스템에서 이용가능한 데이터의 더 스마트한 이용들을 생성하기 위해 다양한 데이터 소스들을 어떤 기준들에 대해 함께 관련시키고 결과적인 동작(들)을 실행하는 것을 허용한다. 이러한 능력은 강력하지만 이벤트들 및 결과적인 동작들의 1차원 뷰를 제공하고, 이벤트들이 사용자 선호들과 비교되고, 일치가 있는 경우, 시스템은 일부 원하는 동작들을 수행한다. 일부 IoT 이용 사례들은 동적으로 발생할 수 있는 특정 이벤트들의 발생에 기반하여 수행될 상이한 동작들을 요구할 수 있다. 종래의 서비스 계층(SL) 이벤트 관리 능력은 이러한 기능을 지원하지 않을 수 있고, 지원하는 경우, 너무 복잡할 수 있고, 이러한 기능을 효율적으로 실현하기에 충분히 사용자 친화적이지 않을 수 있다.

종래의 애플리케이션 프로그래밍은 IoT 시스템에서 잘 스케일링하지 않을 수 있다. 본 명세서에는 이러한 이용 사례들의 구현이 서비스 계층을 고려하여 더 효율적인 시스템(예를 들어, 프레임워크)이 개시된다. 서비스 계층은 서비스 계층에서 이용가능한 서비스들 및 리소스들을 이용하여 복잡한 애플리케이션들이 구축될 수 있는 RESTful 프로세스를 제공한다. 개시된 EASP는 서비스 계층이 이러한 복잡한 애플리케이션들의 동작들 및/또는 업데이트를 효율적으로 관리하는 것을 허용한다. 본 명세서에서 정의된 바와 같은 리소스들(예를 들어, EASP 리소스, EventState 리소스, 또는 전이 리소스)은 EASP 시스템에 상당한 지원을 제공한다.

레드 와인 제조 이용 사례는 IoT 시스템들에서 더 진보된 이벤트 관리 능력들에 대한 필요성을 예시할 수 있다. 도 1은 포도들이 수확된 후 레드 와인을 제조하는 단계들의 하이 레벨 프로세스를 도시한다. 이러한 단계들은 일반적으로 다음과 같이 설명될 수 있다: 포도들의 꼭지 따기 및 으깨기(단계(201)), 불리기(단계(202)), 발효(단계(203)), 펌핑 오버(단계(204)), 프레싱 및 래킹(단계(205)), 말로락틱 발효(단계(206)), 통 숙성(단계(207)), 및 정제 및 병에 채워 넣기(단계(208)).

단계(201)에서, 수확된 포도들은 줄기들로부터 포도들을 추출하기 위해 꼭지 따기 기계 또는 컨베이어 벨트 내에 넣어진다. 추가로, 포도들은 으깨져서 과즙들이 껍질들과 혼합되고 또한 발효된다. 과즙 및 포도 고형물들은 "과일액(must)"이라고 지칭된다. 단계(202)에서, 과일액은 발효 탱크들로 전달되고, 향미, 색, 및 탄닌을 고르기 위해 안착되도록 허용된다. 과일액은 총 산도, 당도 및 pH 레벨들에 대해 테스트되고, 더 나은 와인을 보장하기 위해 레벨들 중 임의의 것이 충족되지 않으면 정정들이 이루어진다. 단계(203)에서, 효모들이 탱크들에 추가되어 발효 프로세스를 시작한다. 효모는 과일액 내의 당을 이산화탄소 및 알코올로 변환하여 와인을 생산한다. 과일액이 발효할 때 열이 발생되므로, 양호한 품질의 와인을 보장하기 위해 온도가 특정 범위에서 제어되어야 한다. 발효 온도는 최대 2주일 수 있는 발효 기간에 걸쳐 화씨 60도에서 화씨 70 내지 85도 또는 화씨 80 내지 90도의 일정으로 운영될 것이다. 또한, 당도는 정기적으로 모니터링되어 발효가 완료되었을 때를 결정한다. 발효 동안, 포도 고형물들(껍질들 및 씨들)은 위로 떠오르고 "캡"으로 지칭된다. 단계(204)에서, 균질의 혼합물을 보장하기 위해 캡의 상단 상의 탱크의 하단에서 과일액을 펌핑하기 위해 "펌핑 오버"의 프로세스가 하루에 수회 수행된다. 이 프로세스는 캡을 과일액 아래로 다시 미는데 툴이 이용되는 경우에 "캡을 펀칭하는" 것으로 또한 지칭된다. 온도는 이 프로세스 동안 원하는 범위에 조정된다.

도 1을 계속 참조하면, 발효가 완료되면, 단계(205)에서, 과즙(이제 와인)은 유지 탱크 내로 배출되고, "짜고 난 찌꺼기(pomace)"라고 지칭되는 나머지 과일액이 프레스로 전달된다. 프레스는 짜고 난 찌꺼기를 압착하여 나머지 와인을 얻고, 이는 유지 탱크 내의 와인과 합쳐진다. 더 높은 품질의 와인의 경우, 배출된 와인만이 이용된다. 프레싱 후, 유지 탱크 내의 와인은 침강되도록 남겨지고, "앙금"이라고 지칭되는 침전물의 층이 하단에 형성된다. 와인은 그 후 "래킹"되고, 이는 와인을 다른 탱크로 이동시켜 "앙금"을 남겨두는 것 및 와인을 클라우딩할 수 있는 다른 어떤 것을 포함한다. 단계(206)에서, 와인은 이어서 말산이 젖산으로 변환되는 임의적인 제2 발효 단계를 겪을 수 있다. 와인에 더 많은 향을 주기 위해 화합물들을 생성하는 말로락틱(ML) 박테리아가 추가된다. 와인은 1주에 두 번 섞이고, 온도는 화씨 70 내지 75도 사이에 유지된다. 이 프로세스는 2 내지 6주 지속될 수 있다. ML 발효가 완료되면, 단계(207)에서, 와인은 다시 래킹되고, 통과 같은 저장 용기에 전달된다. 이 전달 동안, 총 산도 및 pH는 와인을 향상시키도록 조정될 수 있다. 숙성 프로세스는 화씨 55 내지 60도 사이의 일정한 온도 범위를 요구하고, 와인은 4 내지 6주마다 시음되고, 와인이 잘 진전되는 것을 보장하기 위해 필요한 경우에 조정된다. 또한, 와인이 통들에 저장되었다면, 습도는 65 내지 75%로 유지된다. 이 단계는 와인이 다음 단계를 위해 준비되기 전에 몇 달에서 1년 넘게 걸릴 수 있다. 단계(208)에서, 와인은 정제 단계를 거칠 수 있다. 이 단계는 청징제를 와인에 추가하여 와인에 있는 임의의 원하지 않는 요소들을 제거하는 단계 및 이어서 그 청징제를 와인으로부터 필터링하는 단계를 포함한다. 또한, 와인이 병에 채워지기 전에 임의의 최종 조정들(총 산도, pH, 잔여 당 등)이 이루어질 수 있다. 병에 채워지면, 와인은 와인이 시간이 지남에 따라 더 좋아지기 때문에 2달 내지 수 년 사이에 어디에서든 추가로 숙성될 수 있다.

와인 제조 프로세스로부터 알 수 있는 바와 같이, 수반되는 복수의 단계들 및 와인을 만드는 수많은 변수들이 존재한다. IoT 시스템은 이러한 복잡한 프로세스의 시스템에서 다양한 "사물들"을 모니터링하고 제어하는데 이용될 수 있다. 센서들은 온도, pH, 당, 및 총 산도 레벨들을 측정하는데 이용될 수 있는 반면, 명령들은 "펌핑 오버" 및 프레싱과 래킹 단계들 둘 다에 이용되는 펌프들을 제어하기 위해 보내질 수 있다. 하나의 단계로부터 다음 단계로의 전이가 센서 측정들의 결과들 및 프로세스의 이전 단계들에 의존할 수 있기 때문에, IoT 시스템은 와인 제조 프로세스의 대부분을 자동화하도록 쉽게 설계될 수 있다.

와인 제조 이용 사례를 관찰하는 것으로부터, 이벤트 관리 능력들의 진보된 실현을 요구할 수 있는 IoT 시스템들 상에 배치되는 다양한 요건들이 존재한다. 하나의 요건은 특정 이벤트의 상이한 트리거링 조건들에 응답하여, 예를 들어 와인 제조 이용 사례에서의 당도들 또는 다른 측정들에 기반하여 다음 단계로 진행하기로 결정하는 것과 같은 복수의 동작들의 이용일 수 있다. 다른 요건은 센서 측정들의 결과들에 기반하여 이루어진 조정들을 포함할 수 있다. 세 번째 요건은 와인 제조 프로세스 동안 총 산도, pH, 및 당도들을 조정하는 능력에 의해 나타낸 바와 같이 입력들의 변경으로 인해 애플리케이션의 동작을 업데이트하고 그 업데이트를 정상 동작 거동에 통합하는 능력일 수 있다.

종래의 IoT 이벤트 관리 능력은 주로 단일 이벤트의 발생에 중점을 둔다. 이것은 이벤트의 성공적인 검출에 초점을 맞추고, 이벤트들의 실패한 또는 대안적인 발생들에 대한 동작들을 지원하지 않는다. 단일 이벤트에 대한 중점으로 인해, 다양한 이벤트들 간의 상호작용들은 복수의 별개의 이벤트들을 정의하고, 복잡하거나 번거로울 수 있는 그 상호작용들을 구성하는 것을 요구한다. 이벤트들의 추가 또는 업데이트는 기존의 이벤트들에 대한 파급 효과들을 야기할 수 있고, 동작들의 일시적인 중단을 요구할 수 있다. 실시간 IoT 동작들에서, 이러한 제한들은 기존의 이벤트 관리 능력들의 유용성 및 이점들을 감소시킨다.

IoT 시스템들의 장래성은 방대하고 다양하다. 수십억개의 IoT 디바이스들은 많은 유형들 및 많은 이용들의 데이터를 제공할 것으로 예상된다. IoT의 미래는 많은 상이한 소스들로부터의 다양한 데이터를 이용하여 새로운 더 스마트한 애플리케이션들을 생성할 방대한 데이터 세트를 야기할 것이다. 그 결과, IoT 애플리케이션들은 더 복잡해지고 더 많은 능력들을 요구하여 이러한 더 스마트한 이용들을 가능하게 한다.

IoT 아키텍처들은 여전히 진화하고 있고 애플리케이션들에 이용가능한 방대한 양의 데이터를 어떻게 최상으로 이용할지를 결정하는 것이 시도되고 있다. 본 명세서에 개시되는 것은 IoT 시스템들에서 이용가능한 데이터의 복잡한 이용들을 가능하게 할 수 있는 최종 프로세스를 달성하기 위해 다양한 IoT 이벤트들을 함께 상호접속하기 위한 IoT 구성가능한 이벤트 및 동작 시퀀싱 메커니즘들이다. IoT 구성가능한 이벤트 및 동작 시퀀싱은 다음을 포함할 수 있다:

ㆍ 복잡한/분산된 IoT 시스템들의 이벤트들이 함께 상호접속되어 크고 다양한 데이터 세트들 및 진화하는 시스템 조건들 모두를 이용하는 아키텍처를 정의한다.

ㆍ 모니터링 및 관리 목적들을 위해 사용자들에 대한 이벤트들의 상호접속을 동적으로 정의하고 노출시키기 위해 리소스들 및 속성들이 이용되는 RESTful 인터페이스를 정의한다. 이들 리소스들은 이벤트들 을 결과적인 동작들 과 링크하기 위한 잘 구조화된 IoT 프로세스 에 함께 결합된다.

ㆍ 시스템에서의 진화하는 조건들을 고려하기 위해 능동적으로 실행되는 동안 IoT 프로세스를 동적으로 업데이트하기 위한 절차를 정의한다.

ㆍ 훨씬 더 복잡한 동작들을 가능하게 하기 위해 상이한 IoT 프로세스들의 상호작용들을 서로 지정하기 위한 능력을 제공한다. 이러한 상호작용들은 다른 IoT 프로세스의 시작, 정지, 중단, 재시작, 및 리셋을 트리거링하는 하나의 IoT 프로세스를 수반할 수 있고, IoT 프로세스들은 서로 병렬로 실행될 수 있다.

ㆍ 시스템에서 IoT 디바이스들과의 상호작용들을 통해 IoT 프로세스를 실행하기 위한 절차를 정의한다.

ㆍ 개시된 구성가능한 이벤트 및 동작 시퀀싱 시스템이 기존의 IoT 아키텍처들에 어떻게 적용될 수 있는지의 예들을 제공한다.

도 2는 본 명세서에 개시된 바와 같은 IoT 구성가능한 이벤트 및 동작 시퀀싱을 위한 예시적인 시스템(210)을 도시한다. 이 시스템의 구성요소들은 리소스 관리자(214), 업데이트 엔진(213), 및 실행 유닛(216)을 포함할 수 있다. IoT 시스템과 이벤트 및 동작 시퀀싱 시스템(210) 사이의 상호작용들을 허용하는 인터페이스 구성요소들, 입력 인터페이스(211) 및 출력 인터페이스(212)가 있다. 입력 인터페이스(211)는 IoT 엔티티들이 IoT 프로세스의 이벤트들 및 동작들에 관한 정보를 지정, 구성, 업데이트 및 액세스하기 위한 RESTful 인터페이스를 제공할 수 있다. 출력 인터페이스(212) 구성요소는 IoT 프로세스 동안 수행되는 동작들에 응답하여 시스템 내의 IoT 디바이스들을 모니터링하고 제어하기 위한 메커니즘들을 제공한다. 이러한 인터페이스 구성요소들은 IoT 구성가능한 이벤트 및 동작 시퀀싱 시스템과 IoT 시스템 사이의 접착제로서 역할을 할 수 있고 완전성을 위해 포함된다. 입력 인터페이스 및 출력 인터페이스 구성요소들은 일반적으로 플랫폼 및 프로토콜 중심이고, 동작하기 위해 이벤트 및 동작 시퀀싱 시스템(210)에 필요한 보조 기능들이다.

시스템(210) 내에서, 리소스 관리자(214)는 외부 IoT 엔티티들로부터 입력 인터페이스 구성요소를 통해 입력들을 취한다. 리소스 관리자(214)는 IoT 프로세스와 연관된 리소스들의 생성, 저장, 및 유지를 관리한다. 또한, 리소스 관리자(214)는 IoT 프로세스가 활성화되고 동작 중이면 상태 정보를 제공하기 위해 실행 유닛(216)과 인터페이싱한다. 실행 유닛(216)은 IoT 프로세스의 동작들을 수행하고, IoT 디바이스들에게 명령들을 전달하고, 트리거 조건들의 상태를 모니터링하고, 이벤트 전이들을 관리하는 것을 담당한다. 이는 IoT 프로세스의 동작들의 상세들을 획득하기 위해 리소스 관리자(214) 및 업데이트 엔진(213) 양자에 인터페이싱한다. 마지막으로, 업데이트 엔진(213)은 동적 요청들을 처리하여, 여전히 동작 중인 동안 IoT 프로세스의 이벤트 조건들 및 동작들을 업데이트하고, 업데이트들이 현재 동작들을 간섭하지 않도록 보장하는 것을 담당한다. 그 결과, 이것은 리소스 관리자(214)로부터 입력들을 얻고 실행 유닛(216)과 인터페이싱한다.

시스템(210) 내에서, 이벤트 및 동작 시퀀싱 프로세스(EASP)는 원하는 동작을 달성하기 위해 함께 상호접속되는 이벤트들 및 동작들을 캡처하도록 정의된다. EASP는 EASP가 동작하는 변화하는 시스템 조건들을 검출하는 이벤트들로 구성될 수 있다. 일부 동작들을 시행하기 위해 상이한 동작들이 이벤트들에 할당될 수 있고, EASP 내의 다음 이벤트(들)의 시퀀스를 지정하기 위한 메커니즘들이 제공된다. 사용자들이 EASP의 동작들을 동적으로 제어할 수 있도록 EASP를 표현하기 위한 리소스들이 개시되어 있다(예를 들어, 동작들에 영향을 주지 않고 요청을 통해 EASP를 제어할 수 있는 능력이며, 그 경우, EASP는 그 요청에 어떻게 응답할지를 처리한다). EASP는 IoT 이벤트들 및 동작들을 의도된 애플리케이션에 대한 원하는 시퀀스로 함께 상호접속하는 IoT 프로세스라는 점에 유의한다. EASP는 이벤트들 및 동작들을 함께 링크하여 처리 흐름(예를 들어, "동작 시퀀싱")을 형성하는 방법에 대한 프레임워크로 고려될 수 있다. EASP 리소스들 자체는 EASP CSF가 실행하는 "프로그램"일 수 있다. 실행될 때, EASP CSF는 하나의 EventState 리소스로부터 다른 EventState 리소스로 전이할 수 있다.

EASP의 이벤트들 및 동작들은 이벤트 및 동작 시퀀싱 시스템(210)에서의 리소스들로서 표현될 수 있으며, 여기서 요청자는 EASP가 무엇인지 그리고 어떤 이벤트들이 동작들의 그 동작을 트리거링하는지를 생성하고 정의한다. 그 결과, EASP 리소스는 EASP를 설명하는데 이용되는 파라미터들로 개시될 수 있다. EASP 리소스 내에서, EventState 리소스는 EASP 내의 각각의 이벤트를 설명하는데 이용될 수 있고, 또한 EventState 리소스 내에서, 하나 이상의 전이 리소스가 EASP에서 실행되는 동작들 및 다음 이벤트를 설명하기 위해 제공된다. 도 3은 개시된 리소스들의 관계들의 예를 도시하며, 여기서 EASP 리소스(예를 들어, EASP 리소스(217))는 복수의 EventState 리소스들(예를 들어, EventState 리소스(218)) 및 그 연관된 전이 리소스들(예를 들어, 전이 리소스(219))을 갖는 부모 리소스이다. 각각의 리소스 내에서, 그 리소스에 대한 정보를 캡처하기 위한 관련 정보를 제공하는 파라미터들이 있을 수 있다.

EASP 리소스(217)는 EASP에 의해 요구되는 모든 이벤트들 및 동작들을 포함할 수 있다. 이벤트들은 일부 동작(들)이 수행되게 하거나 이를 트리거링할 수 있는 IoT 시스템에서의 조건들이다. 이벤트들의 일부 예들은 특정 센서의 임계값 또는 값들의 범위, 타이머의 만료, 리소스에 대한 RESTful 동작(생성, 검색, 업데이트, 삭제), 디바이스 또는 엔티티를 턴 온 또는 오프하는 동작, 다른 EASP에 의해 실행되는 동작 등이다. 한편, 동작들은 이벤트의 검출 시에 수행되는 것이다. 이들은 리소스에 대한 RESTful 동작, 타이머의 시작, 디바이스 관리 동작, 저장 및 전달 동작, 다른 EASP의 인에이블링, 액추에이터의 제어, 명령의 실행 등을 포함할 수 있다.

이벤트 및 동작 시퀀싱 시스템(210)에 의해 제공되는 다른 중요한 특징은 EASP들의 서로의 상호작용들을 지정하는 능력이다. EASP의 동작은 다른 EASP로부터의 일부 동작들의 실행에 의존할 수 있다. 또한, 2개의 EASP의 이벤트들은 서로 엮일 수 있고 IoT 시스템의 상이한 양태들을 제어하는데 이용될 수 있다. 이들은 개시된 이벤트 및 동작 시퀀싱 시스템(210)에 의해 제공되는 강력한 특징들이며, 더 간단한 EASP들의 상호작용들을 통해 복잡한 EASP들을 구축하는 것을 허용한다.

EASP는 본 명세서에 개시된 IoT 프로세스의 실현이다. 요약하면, 이벤트 및 동작 시퀀싱 시스템(210)은 EASP가 동작하는 전체 기능 시스템으로 고려될 수 있다. 이것이 도 1에 도시되어 있다. EASP는 특정 애플리케이션에 대한 이벤트들 및 동작들의 상호접속들의 인스턴스, 예컨대 와인 제조 이용 사례이다. EASP 리소스는 EASP를 나타내는 리소스이다. 이것은 도 3에 도시된 바와 같이 자식 리소스 전이를 가질 수 있는 자식 리소스 EventState를 가질 수 있다. EventState 리소스들은 원하는 애플리케이션을 달성하기 위해 EASP가 거치는 상태들(예를 들어, 와인 제조 이용 사례의 각각의 단계)을 설명한다. 본 명세서에 개시된 바와 같이, "EventState"는 일반적으로 리소스로 지칭되고, "이벤트 상태"는 "EventState" 리소스와 연관된 상태의 발생이다. 전이 리소스들은 하나의 이벤트 상태로부터 다른 이벤트 상태로의 전이들을 트리거링하는 이벤트들을 설명한다. 또한, 이벤트 전이 동안 동작들이 실행될 수 있다.

EASP 리소스 - EASP 리소스(217)는 전체 EASP의 상세들을 캡처할 수 있다. 표 1은 EASP 리소스의 일부 예시적인 파라미터들을 도시한다. EASP 식별자는 EASP 리소스(217)를 EASP의 상세들과 연관시키는데 이용될 수 있고 실행 유닛(216)에 의해 이용되어 EASP의 동작들을 실행할 수 있다. EASP 식별자는 다른 EASP 리소스들에 의해 이용되어 전제 조건으로서 또는 일부 이벤트로 인한 동작으로서 이 EASP의 동작들을 트리거링할 수 있다. 설명 파라미터는 인간 판독가능한 형태로 EASP의 목적을 지정하는 것을 허용하는 반면, 현재 상태 파라미터는 전체 EASP의 실행 상태를 제공한다. 제어 파라미터는 EASP를 인에이블링하는 것으로부터 EASP를 일시정지, 재개, 나가기, 및 디스에이블링하는 것까지의 EASP의 동작들을 제어하는데 이용될 수 있다. IoT 시스템 내의 이벤트들에 기반하여 EASP가 자율적으로 실행되는 자동 제어가 또한 존재할 수 있다. 전제 조건 파라미터는 EASP가 시작할 수 있기 전에 발생할 수 있고 제어 파라미터와 함께 이용되어 자율적으로 EASP를 실행할 수 있는 전제 조건 이벤트들을 제공한다. 나가기 조건 파라미터는 동작을 계속하면 유해하거나 위험할 긴급의 사례들에서 EASP의 갑작스런 나가기를 허용한다. 이 파라미터는 실행 유닛(216)으로부터의 비동기 응답이 EASP에 관련된 모든 동작들을 중단시키고 그 동작들을 비활성화하는 것을 제공한다. "전체" 나가기 조건(들)은 그 이벤트 상태에 관계없이 EASP의 동작 동안 연속적으로 모니터링되고 적용될 수 있다.

EASP가 제어 파라미터에 의해 지정된 바와 같이 제어될 수 있는 많은 방식들이 있다. 이것은 이벤트 및 동작 시퀀싱 시스템(210)의 구현에 의존할 수 있고, 이하는 제어 파라미터가 어떻게 지정될 수 있는지의 일부 예들이다. EASP가 자동 제어로 설정될 때, 이벤트들 및 동작들과 연관된 파라미터들은 이벤트 및 동작 시퀀싱 시스템(210)이 EASP의 동작들을 어떻게 제어해야 하는지에 대한 안내를 제공하도록 지정되어야 한다. 이 모드에서, 전제 조건 파라미터는 EASP가 시작하는데 필요한 이벤트들(예를 들어, 조건들) 또는 동작들을 지정할 수 있다. 일단 시작되면, EASP의 시퀀싱은 지정된 EventState 리소스들(218) 및 전이 리소스들(219)에 의존할 것이다. EASP는 또한 '인에이블, 시간 지연' 또는 '디스에이블'이 있는 타이머에 기반하여 '인에이블, 온-디맨드'를 이용하여 제어될 수 있다. 일단 EASP가 능동적으로 실행되고 있으면, 이것은 '즉시 나가기', '완료 비율로 나가기 또는 이벤트 조건들 나가기', '일시정지', '재개', 또는 '리셋'을 이용함으로써 상호작용적으로 제어될 수 있다. EASP를 일시정지, 재개 또는 리셋하는 능력은 다양한 시스템 조건들을 설명할 수 있는 매우 IoT 중심적 상호작용을 제공한다.

<표 1>

EventState 리소스 - EventState 리소스(218)는 이벤트의 상세들 및 다른 이벤트로의 전이까지 유지하는 상태를 캡처한다. 트리거링될 때, 이벤트는 동작을 수행하고 다른 이벤트 상태로 전이하기 전에 다른 이벤트가 발생하는 것을 모니터링하기 위한 상태에서 대기할 수 있다. EventState 식별자는 실행 유닛(216)이 이벤트 상태 전이들을 처리하고 상태 정보를 유지하도록 정의된다. 이벤트 상태는 설정 지속시간 동안 또는 특정 이벤트(들)의 발생으로 인해 다른 이벤트 상태로 전이할 수 있다. 이벤트 상태가 타이밍되는 경우, 지속시간 파라미터는 이벤트가 얼마나 오래 동작하는지(예를 들어, 남은 시간의 양) 그리고 다음 이벤트 상태로 언제 전이하는지를 지정한다. 이벤트 상태가 다른 이벤트로 인해 전이하는 경우, 전이 리소스(219)는 이벤트의 상세들을 지정한다. 이벤트 나가기 조건 파라미터는 EASP 리소스(217)의 나가기 조건 파라미터와 유사하게 현재 이벤트 상태를 나갈 수 있는 이벤트들을 지정하는데 이용된다. 표 2는 EventState 리소스(218)에 대한 일부 예시적인 파라미터들을 도시한다.

<표 2>

전이 리소스 - 전이 리소스(219)는 현재 이벤트 상태로부터 다음 이벤트 상태로의 전이를 트리거링하기 위한 조건(들)을 캡처한다. 다음 EventState ID 파라미터는 전이할 EventState ID를 지정하고, 실행될 필요가 있는 임의의 동작들이 있다면, 이것은 실행 동작 파라미터에서 지정된다. 전이 이벤트 파라미터는 이벤트 상태 전이가 발생하도록 트리거링할 이벤트(들)를 지정한다. 이벤트들은 AND, OR, XOR, NOT 등과 같은 논리 연산자들을 통해 개별 이벤트들을 함께 결합하는 복수의 표현들로서 지정될 수 있다. 현재 이벤트 상태로부터의 각각의 전이에 대해 하나의 전이 리소스(219)가 생성될 수 있다는 점에 유의한다. 그 결과, 각각이 상이한 트리거 이벤트들을 갖고 잠재적으로 그 연관 동작들을 갖는, 특정한 EventState 리소스(217)에 대한 복수의 전이 리소스들(219)이 있을 수 있다. 표 3은 전이 리소스(219)에 대한 일부 예시적인 파라미터들을 도시한다.

<표 3>

리소스 관리자(214)는 요청이 파싱되고 검증된 후에 입력 인터페이스(211)로부터 요청들을 수신한다. 다음으로, 리소스 관리자(214)는 요청된 방법에 기반하여 그 요청을 처리하도록 진행한다. 요청된 방법이 업데이트이면, 리소스 관리자(214)는 EASP 프로세스가 능동적으로 실행되고 있는지를 확인하기 위해 체크한다. EASP가 여전히 동작 중인 경우, 리소스 관리자(214)는 그 업데이트의 상세들과 함께 요청을 업데이트 엔진(213)에 전달한다. 도 4는 리소스 관리자(214)가 그 요청에 응답하여 실행하는 절차를 도시한다.

도 4 내지 도 6, 도 8, 도 12, 도 14 등과 같은, 본 명세서에 도시된 단계들을 수행하는 엔티티들은 논리적 엔티티들일 수 있다는 것이 이해된다. 이 단계들은 도 17c 또는 도 17d에 도시된 것들과 같은 디바이스, 서버, 또는 컴퓨터 시스템의 메모리에 저장되고 그 프로세서 상에서 실행될 수 있다. 예에서, M2M 디바이스들의 상호작용과 관련하여 아래에서 더 상세히 설명하는 바와 같이, 도 5의 IoT 디바이스(242)는 도 17a의 M2M 단말 디바이스(18) 상에 존재할 수 있는 반면, 도 2의 시스템(210)은 도 17a의 M2M 게이트웨이 디바이스(14) 상에 존재할 수 있다. 본 명세서에 개시된 예시적인 방법들(예를 들어, 도 1, 도 4 내지 도 8, 도 12, 도 14 등) 간에 단계들을 스킵하거나, 단계들을 조합하거나, 또는 단계들을 추가하는 것이 고려된다.

도 4의 절차는 IoT 요청자로부터의 요청을 평가할 때 리소스 관리자(214)에 의해 수행되는 단계들을 설명한다. 단계(221)에서, 요청된 리소스가 존재하는지를 체크한다. 만일 존재하거나 또는 그 요청이 위에서 개시된 리소스들(예를 들어, 전이 리소스(219), EventState 리소스(218) 또는 EASP 리소스(217)) 중 하나를 생성하는 것이라면, 단계(222)로 진행한다. 존재하지 않는 경우, 단계(234)(응답 전송)를 포함할 수 있는 에러 응답을 전송한다. 단계(222)에서, 필요한 경우, 인가 또는 액세스 제어 정책들을 체크하고, 여기에 수반되는 복수의 단계들이 있을 수 있고, 이는 외부 엔티티들과의 상호작용들을 포함할 수 있다. 인가 또는 액세스 제어가 승인되면, 단계(223)로 진행한다. 승인되지 않으면, 단계(234)(응답 전송)를 포함할 수 있는 에러 응답을 생성한다. 단계(223)에서, 요청된 동작 - CRUD(생성, 검색, 업데이트, 삭제)을 체크한다. 요청된 동작이 검색이면, 단계(224)로 진행한다. 요청된 동작이 삭제이면, 단계(225)로 진행한다. 요청된 동작이 생성 또는 업데이트이면, 단계(226)로 진행한다. 단계(224)에서, 데이터베이스에 액세스하고 아래에 열거된 적절한 응답들 중 하나를 회신한다. 응답 유형은 요청 옵션, 질의 스트링 등의 일부로서 지정될 수 있다. 적절한 응답은 현재 리소스 표현, 전체 EASP의 현재 상태뿐만 아니라 현재 이벤트 상태의 그 상태 또는 전체 EASP 리소스 구조를 포함할 수 있다. 이 정보는 단계(234)(응답 전송)에서 회신된다. 단계(225)에서, EASP가 동작하고 있는지의 현재 상태를 체크하고, 이어서 단계(234)로 진행하여 적절한 응답을 전송한다. EASP가 실행되지 않는 경우, 삭제 요청에서 식별된 적절한 리소스 및 대응하는 자식 리소스들을 삭제한다. EASP 리소스(217)가 제공되는 경우, 전체 EASP 구조가 데이터베이스(215)로부터 제거된다. EASP가 여전히 실행 중인 경우, 에러 응답을 회신한다.

계속해서 도 4를 참조하면, 단계(226)에서, 제공된 정보가 원하는 동작에 대한 요건을 충족시키는지를 체크한다. 예를 들어, 생성 요청들의 경우, 제공된 정보가 연관 리소스 유형에 대한 스키마 파일의 요건들을 충족시키느냐이다. 정보가 스키마 요건들을 충족시키면, 단계(227)로 진행한다. 정보가 스키마 요건들을 충족시키지 않으면, 에러 응답을 전송하고 단계(234)(응답 전송)로 진행한다. 단계(227)에서, EASP가 동작 중인지를 체크한다. EASP가 동작 중이면, 업데이트 엔진(213)에 요청을 전송하고 단계(233)에서 응답을 기다린다. 평가의 일부로서, 리소스 관리자(214)는 식별된 IoT 디바이스들(만약 있다면)이 액세스에 이용가능할 수 있도록 보장하기 위해 실행 유닛(216)과 상호작용할 필요가 있을 수 있다. 이 검증 절차는 EASP를 활성화하기 전의 나중으로 지연될 수 있고 시스템 의존적이다. EASP가 동작 중이지 않은 경우, 단계(228)로 진행한다. 단계(228)에서, 요청된 방법을 체크한다. 업데이트이면, 단계(229)로 진행한다. 생성이면, 단계(230)로 진행한다. 단계(229)에서, 데이터베이스(215) 내의 정보를 요청에서 제공되는 데이터로 업데이트하고 단계(234)(응답 전송)로 진행한다. 단계(230)에서, 요청된 리소스가 존재하고 그것이 생성 동작인 경우, 에러 응답을 전송하고 단계(234)(응답 전송)로 진행한다. 그렇지 않은 경우, 단계(231)로 진행한다. 단계(231)에서, 요청된 리소스가 생성될 수 있는지를 평가한다. 리소스가 생성될 수 있는 경우, 단계(232)로 진행하고, 그렇지 않은 경우, 에러 응답을 전송하고 단계(234)(응답 전송)로 진행한다. 단계(232)에서, 필요하다면, 리소스에 대한 식별자를 생성한다. 리소스 관리자(214)는 시스템 내의 고유성을 보장하기 위해 식별자를 생성할 수 있다. 대안적으로, 식별자가 제공될 수 있고, 리소스 관리자(214)는 고유성을 체크할 수 있으며, 이어서 단계(234)(응답 전송)로 진행한다. 단계(233)에서, 업데이트 엔진(213)으로부터 응답이 수신되고, 결과들을 단계(234)(응답 전송)로 전송한다. 성공 응답이면, 데이터베이스(215) 내의 정보를 업데이트한다. 단계(234)에서, 적절한 코드를 이용하여 응답을 생성하고 이를 요청자에게 전송한다.

앞서 언급된 바와 같이, 리소스 관리자(214)는 요청자의 요구들에 기반하여 요청들을 검색하기 위해 상이한 응답들을 회신할 수 있다. 디폴트 응답은 검색 요청에서 타겟 식별자에 의해 지정된 리소스의 리소스 표현일 수 있다. 그러나, 리소스 관리자(214)는 또한 요청자에게 관심 있는 다른 관련 정보를 포함하도록 응답을 포매팅할 수 있다. 하나의 이러한 응답은 EASP 프로세스의 동작들의 상태의 집성이며, 하나는 전체 EASP에 대한 것이고, 다른 하나는 현재 이벤트 상태에 대한 것이다. 다른 유형의 응답 리소스 관리자(214)는 그 응답 내에서 EASP 리소스 구조의 집성을 제공할 수 있다. 이것은 요청자가 하나의 요청으로 EASP의 모든 이벤트들 및 동작들을 검색하는 것을 허용한다. 이 정보는 요청자가 EASP 및 그 이벤트들 및 동작들을 구축하거나 모니터링하는 것을 도울 수 있다. 다른 응답 유형들이 있을 수 있고, 이벤트 및 동작 시퀀싱 시스템(210)이 또한 회신할 수 있고, 이벤트 및 동작 시퀀싱 시스템(210)의 설계에 의존할 것이다.

실행 유닛 - EASP 프로세스가 정의되었으면, 그 동작들은 (예를 들어, 타이머의 만료에 기반하여, 일부 전제 조건들로 인해, 기타 등등으로) 다양한 이벤트들에 의해 트리거링될 수 있다. 다른 트리거들이 또한 정의될 수 있고, 이벤트 및 동작 시퀀싱 시스템(210)에 의존할 것이다. 이어서, EASP의 실행은 실행 유닛(216)에 의해 처리되며, 실행 유닛(216)은 출력 인터페이스(212)를 통해 IoT 시스템에 인터페이싱하여 실행 유닛(216)이 EASP에의 입력들에 그리고 또한 동작에 의해 지정되는 경우 제어를 위해 액추에이터 유형 디바이스들에 액세스할 수 있게 한다.

EASP의 실제 동작 전에, 실행 유닛(216)은 EASP가 실행하기 위해 요구되는 모든 입력들 및 출력들에 대한 액세스를 검증할 수 있다. 이 검증은 EASP 리소스 정의 및 그 이벤트 상태 리소스들이 생성됨에 따라 수행될 수 있다. 대안적으로, 검증은 활성화 후에 그러나 실제 동작 전에 수행될 수 있다. 이 경우, EASP 리소스(217)의 현재 상태 파라미터는 "EASP 검증" 또는 그 효과에 대한 일부 유형의 표시자로서 지정될 수 있다.

실제 검증은 이벤트 및 동작 시퀀싱 시스템(210)이 IoT 시스템과 통합되는 방법에 국지적으로 또는 원격으로 의존하여 발생할 수 있다. 이벤트 및 동작 시퀀싱 시스템(210)이 IoT 시스템의 일부로서 통합되는 경우, 센서 및 액추에이터 디바이스들에 대한 액세스들이 이미 확립되었을 수 있고, 실행 유닛(216)은 그 디바이스에 액세스하기 위해 식별자 또는 일부 URI를 참조할 필요가 있을 수 있다. 그러나, 원격 경우들에서, 실행 유닛(216)은 디바이스들과의 메시징 상호작용들을 설정하기 위해 출력 인터페이스(212)의 지원을 필요로 할 수 있다. 이것은 가입/통지 메커니즘들의 형태, 프로토콜 메커니즘들(예를 들어, CoAP 관찰)의 이용, 폴링 방법들의 이용, 또는 IoT 시스템에 의해 노출되는 일부 API 호출들일 수 있다. 이러한 경우들에서, 인가 또는 액세스 제어 정책들은 또한 IoT 디바이스들에 대한 액세스를 얻는 이벤트 및 동작 시퀀싱 시스템(210)에서 역할을 할 수 있다. 이러한 문제들은 이벤트 및 동작 시퀀싱 시스템(210)의 범위 밖에 있고, 이벤트 및 동작 시퀀싱 시스템(210)의 동작을 가능하게 하기 위해 이러한 액세스들을 위한 IoT 시스템에 의해 일부 메커니즘이 제공되어야 한다. 도 5는 리소스 관리자(214)를 실행 유닛(216)과 통합하여 EventState 리소스의 생성 요청을 처리하는 예시적인 절차를 도시한다. 이벤트 및 동작 시퀀싱 시스템(210)의 다른 구성요소들이 도면에서의 클러터를 최소화하는 것으로 도시되지 않음에 유의한다. 애플리케이션이 리소스를 생성할 수 있고, 하나의 EASP에 대해 복수의 리소스들이 생성될 수 있다는 것에 또한 유의해야 한다. 리소스들은 동작하는 방법에 대해 EASP에게 지시하기 위해 먼저 생성될 수 있다. 본 명세서에 개시된 리소스들은 애플리케이션들이 EASP를 프로그래밍할 수 있는 방법의 예들이다. 다른 예들은 2개의 리소스와 같은 더 적은 리소스들을 포함할 수 있다.

도 5는 IoT 시스템 절차에 대한 예시적인 실행 유닛 액세스 검증을 도시한다. 단계(251)에서, IoT 요청자(241)는 EventState 리소스(218)를 생성하라는 요청을 전송한다. 이 절차는 또한 EASP 리소스(217) 또는 전이 리소스(219)의 생성에 적용될 수 있다. EASP 리소스(217)를 생성할 때, 지정된 파라미터들은 EASP ID, EASP의 설명, EASP가 제어되는 방법, 및 EASP에 대한 임의의 전제 조건들 또는 나가기 조건들을 포함할 수 있다. 표 1은 또한 지정될 수 있는 다른 파라미터들을 열거한다. EventState 리소스(218)를 생성할 때, EventState ID, 지속시간, 및 전이 이벤트들과 같은 파라미터들이 지정될 수 있다. 다른 EventState 파라미터들이 표 2에서 발견된다. 전이 리소스(219)와 관련하여, 이것은 표 3에서 설명된 바와 같이, 전이 이벤트들, 다음 EventState ID, 및 실행 동작 파라미터들 등을 포함할 수 있다. 단계(252)에서, 리소스 관리자(214)는 요청들을 처리하고 이벤트 및 동작 시퀀싱 시스템(210)에 의해 요구되는 임의의 필요한 검증들을 수행한다. 단계(253)에서, 검증이 성공적이면, 리소스 관리자(214)는 EventState 정보를 실행 유닛(216)에 전송하여 액세스가 IoT 디바이스들(242)에 대해 이루어질 수 있는지를 검증할 수 있다.

계속해서 도 5를 참조하면, 단계(254)에서, 실행 유닛(216)은 (출력 인터페이스(212)와 함께) 요청을 IoT 디바이스(242)에 전송한다. 이 요청은 IoT 디바이스(242)가 도달가능하다는 것을 검증하기 위한 간단한 검색일 수 있거나, 또는 이것은 가입 또는 CoAP 관찰을 생성하는 것을 포함할 수 있다. 이 요청의 다른 목적은 임의의 인가 또는 액세스 제어가 IoT 디바이스(242)에 대한 이벤트 및 동작 시퀀싱 시스템(210) 액세스를 허용하도록 구성되는 것을 보장하는 것이다. 액세스가 승인되지 않으면, 이 정보는 IoT 요청자(241)로 회신될 수 있다. 단계(255)에서, 액세스가 승인되면, IoT 디바이스(242)는 Ok 또는 적절한 응답을 회신한다. 단계(256)에서, 실행 유닛(216)은 IoT 디바이스(242)에 대한 액세스가 검증되었다는 응답을 회신한다. 단계(257)에서, 리소스 관리자(214)는 EventState 리소스를 생성하고 정보를 데이터베이스에 저장한다. 단계(258)에서, 생성된 응답이 생성되어 IoT 요청자(241)에 전송된다. 이 절차가 성공적이지 못한 경우, 적절한 에러 응답이 회신된다.

검증이 완료되고, 이벤트 및 동작 시퀀싱 시스템(210)이 EASP에 의해 요구되는 모든 동작들을 실행할 수 있으면, 실행 유닛(216)은 동작을 시작하고 EventState 전이들을 추적할 것이다. 동작들의 과정 동안, 실행 유닛(216) 및 리소스 관리자(214)는 필요에 따라 요청자에게의 상태 정보의 전송을 가능하게 하기 위해 통신들을 유지할 수 있다. 실행 유닛(216)은 또한, EASP에 대한 새로운 동적으로 추가된 EventState 리소스들(218) 또는 기존의 EventState 리소스들(218)에 대한 변경들이 동작들에 영향을 주지 않고 통합될 수 있는지를 결정하기 위해 업데이트 엔진(213)과 인터페이싱한다. 본 명세서에서는 능동적으로 실행 중인 동안 프로세스(예를 들어, 애플리케이션)를 업데이트하는 능력이 개시된다. 통상적으로, 이것은 애플리케이션의 중단을 필요로 하지만, EASP는 중단될 필요가 없다. 이벤트 및 동작 시퀀싱 시스템(210)은 변경이 발생하는 것을 허용하고, 변경되는 것 이외의 기존 동작들에 영향을 주지 않고 이를 행한다. 즉, 변경을 행하기 위해 실행 중인 어떠한 것(예를 들어, 와인 프로세스)도 중단시킬 필요가 없다. 이벤트 및 동작 시퀀싱 시스템(210)은 변경을 행하는 것을 동적으로 처리할 수 있다. 이와 같이, 변경은 원래 프로그래밍되었던 것과는 상이한 이벤트 상태로 진행하도록 동작들을 바꿀 수 있다. 도 1과 도 7b 사이의 차이들을 참조한다. 도 7b의 다음 이벤트 상태들(단계(243) 및 단계(244))은 도 1이 처음에 실행되었을 때 존재하지 않았다.

도 6은 EASP가 활성화되고 실행될 때 실행 유닛(216)에 의해 수행되는 처리 절차를 도시한다. 이 도면은 "다음 EventState로의 전이" 단계 동안 제공되는 상태 정보만을 도시하지만, 실행 유닛(216)은 전체 상태 처리 흐름 동안 임의의 시간에 상태 정보를 제공할 수 있다는 점에 유의한다. 상태 정보는 현재 EASP 처리가 어디에 있는지(예를 들어, 완료 비율), 어떤 이벤트 상태가 현재 활성인지 등을 나타내기 위해 EASP 시스템에 의해 제공되는 임의의 정보를 포함할 수 있다. 상태 정보의 예들이 도 15 및 도 16에 도시되어 있다.

도 6은 예시적인 실행 유닛 상태 처리 흐름을 도시한다. 단계(261a-261c)에서, 활성화가 존재한다. 이것은 실행 유닛(216)이 처리를 시작하도록 트리거링될 때이다. 이것은 다양한 방식들로 트리거링될 수 있고, 도 6은 3가지 잠재적인 방식, 즉 EASP 리소스(217)에 지정된 전제 조건들에 기반하는 것(단계(261a)), 장래의 시간에 기반하는 것(단계(261b)), 또는 요청자의 온-디맨드 제어에 기반하는 것(단계(261c) - EASP를 활성화하라는 요청을 수신하는 것)을 도시한다. 표 1에 설명된 제어 파라미터는 EASP가 활성화될 수 있는 추가적인 방식들을 제공한다. 예를 들어, EventState 리소스들 각각을 초기에 생성할 때, EASP가 활성화되지 않는 경우들이 있을 수 있다. 다른 시나리오에서, EASP가 능동적이지 않고 활성화되어야 할 때, 사용자가 하루 중 특정 시간들 동안에만 EASP를 실행하기를 원하지만, 다른 시간들 동안에는 아무런 이익이 없다. 단계(262)에서, EventState 정보의 로딩이 존재할 수 있다. 일단 EASP가 활성화되면, 실행 유닛(216)은 초기에 초기 EventState의 정보를 로딩한다. 처리 흐름의 후속 반복들에서, 다음 EventState ID 파라미터에 의해 식별된 EventState 리소스(218)가 대신 로딩된다. 또한, 이 단계가 EventState 리소스의 생성 동안 이미 이전에 수행되지 않았다면, 실행 유닛(216)은 IoT 디바이스들에 대한 액세스들이 이루어질 수 있는지를 검증할 필요가 있을 수 있다. 이것은 이벤트 및 동작 시퀀싱 시스템(210) 및 IoT 시스템이 원격으로 위치하는 경우, CoAP 관찰을 이용하여, IoT 시스템 내의 디바이스들에 가입들을 행하거나, 이벤트 상태에 입력을 제공하기 위해 디바이스들을 폴링하는 것에 의해 달성될 수 있다. 더 통합된 솔루션들의 경우, 이것은 적절한 API 호출들을 호출하는 것을 포함할 수 있다. 필요한 경우, 다음 단계로 이동하기 전에 지속시간 동안 실행되는 이벤트 상태들에 대해 타이머가 시작될 수 있다.

계속해서 도 6을 참조하면, 단계(263)에서, 이벤트 검출이 존재할 수 있다. 일단 실행 유닛(216)이 EventState 리소스(218)의 동작에 필요한 IoT 디바이스들(242)과 통신할 수 있고, 모든 EventState 리소스 파라미터들이 국지적으로 저장되면, 잠재적인 전이 이벤트들을 검출하기 위해 입력들을 모니터링하기 시작한다. 이 시점에서, 나가기 조건들 및 타이머 만료 입력들은 또한 이들이 인에이블되어야 하는 검출 논리에 적용된다. 나가기 이벤트가 검출되면, 실행 유닛(216)은 이벤트 상태 또는 그렇게 구성되었다면 심지어 EASP를 나갈 수 있다. 마지막으로, 실행 유닛(216)은 또한, EASP에 대한 변경이 이루어졌다면 업데이트 엔진(213)으로부터의 입력을 획득할 수 있다. 이것이 발생할 때, 실행 유닛(216)은 국지적으로 저장된 파라미터들을 업데이트 엔진(213)에 의해 제공되는 것들로 대체한다. 단계(264)에서, 실행된 동작(들)이 존재할 수 있다. 전이를 트리거링하는 이벤트들의 검출 시에, 실행 유닛(216)은 IoT 디바이스들에 대한 현재 이벤트 상태에 대해 지정될 수 있는 임의의 동작들을 실행할 수 있거나 이벤트 상태 또는 EASP를 나갈 수 있다. 모든 동작들이 완료되었으면, 이것은 다음 단계로 이동할 수 있다. 업데이트 엔진 입력이 존재할 때, 실행 유닛(216)은 저장된 파라미터들을 입력에 의해 제공되는 것들로 대체해야 한다는 점에 유의한다. 이것은 전이할 다음 EventState 리소스(218)의 ID뿐만 아니라 수행될 필요가 있는 임의의 새로운 동작들을 포함할 수 있다. 이 능력은 EASP 프로세스의 동작들을 동적으로 업데이트하는 지원을 제공한다.

단계(265)에서, 다음 EventState 리소스(218)로의 전이가 있을 수 있다. 다음 EventState ID가 전이 리소스(219)의 일부로서 존재하는 경우, 실행 유닛(216)은 단계(262)로의 전이를 수행하여 다음 EventState ID에 의해 지정된 다음 EventState 리소스(218)에 대한 정보를 로딩할 수 있다. 실행 유닛(216)은 다음 EventState 리소스(218)의 식별자 및 전이에 대한 다른 관련 정보, 예컨대 현재 상태, 어떤 트리거 이벤트가 검출되었는지 등을 리소스 관리자(214)에게 시그널링할 수 있다. 이 신호는 EASP 동작들을 동적으로 업데이트할 때 존재할 수 있는 잠재적 경쟁 조건들을 검출하는데 이용될 수 있다. 경쟁 조건들은 동일한 트리거 이벤트에 대해 2개의 EventState가 존재할 가능성이 있을 때마다 발생한다. 이것은 본 명세서에 설명된 바와 같이 EASP에 대한 업데이트들 동안 발생할 수 있다. 이것의 예는, EventState 리소스(218)가 업데이트 엔진(213)에 의해 최근에 수정된 경우, 다음 EventState 식별자가 현재 저장된 식별자와 일치하는지를 리소스 관리자(214)가 체크할 수 있는 때이다.

업데이트 엔진 - 업데이트 엔진(213)은 요청자가 동작 중인 동안에 EASP 프로세스를 업데이트하기 위한 메커니즘을 제공한다. 이 업데이트는 심지어 새로운 이벤트 상태들을 EASP에 추가하기 위해 전이 이벤트를 변경하는 형태로 되어 있을 수 있다. EASP 동작들에 영향을 주는 다른 변경들도 지원될 수 있다. 업데이트 엔진(213)은 업데이트들이 EASP의 동작과 간섭하지 않도록 보장하기 위해 실행 유닛(216)과 조정할 수 있다. 간섭이 검출되는 경우, 업데이트 엔진(213)은 업데이트를 인에이블링하지 않고, 필요한 에러 응답을 리소스 관리자(214)에게 제공할 것이며, 리소스 관리자(214)는 그 후 그 응답을 요청자에게 중계할 것이다.

도 7b는 도 1로부터의 와인 제조 프로세스에 대한 예시적인 업데이트를 도시하며, 여기서 래킹 단계(단계(205))는 더 높은 품질의 와인을 만들기 위해 2개의 별개의 단계로 분할된다. 업데이트들은 이미 실행 중인 EASP 프로세스에 대한 변경들을 시행하기 위해 업데이트 엔진(213)이 어떻게 이용되는지를 보여준다. 도 7a는 와인 제조 프로세스의 동작들을 업데이트하는데 이용될 수 있는 단계들을 개략적으로 도시한다. 단계(341)에서, 새로운 "제1 래킹 전달" 단계(단계(243))를 추가한다. 단계(342)에서, 새로운 "제2 래킹 전달" 단계(단계(244))를 추가한다. 단계(343)에서, 새로 생성된 "제1 래킹 전달" 단계(단계(243))로 전이(전이(245))하도록 "프레싱 및 래킹" 단계(단계(205))의 전이 리소스(219)를 업데이트한다. 단계(344)에서, 새로 생성된 "제2 래킹 전달" 단계(단계(244))로 전이(전이(246))하도록 "말로락틱 발효" 단계(단계(206))의 전이 리소스(219)를 업데이트한다.

발효 단계 동안, 와인이 양호한 품질을 갖는 것으로 결정되었고 2개의 래킹 단계를 갖는 것이 이익이 될 것이다. 이때, 와인 제조자는 도 7b에 도시된 바와 같이 EASP에 제1 및 제2 래킹 전달 이벤트 상태들을 생성한다. 이 EventState 리소스들(218)의 생성이 기존의 동작에 영향을 주지 않으므로, 생성 요청들은 성공적이다. 리소스들이 생성된 후, 이벤트 및 동작 시퀀싱 시스템(210)은 이제 도 7b에서 "프레싱" 단계로서 라벨링되는, 도 1에 도시된 (원래의) "프레싱 및 래킹" 단계로 EASP를 전이한다. 이어서, 와인 제조자는 "말로락틱 발효" 단계(206) 대신에 "제1 래킹 전달" 단계(243)로 전이하는 동작을 재구성함으로써 단계를 업데이트하라는 요청을 전송한다. 업데이트 엔진(213)은 요청을 평가하고, 그 요청이 와인이 완전히 프레싱되기를 기다리는 도 6의 이벤트 검출 스테이지(단계(263))에서만 있기 때문에, 처리 흐름을 변경하고 다음 EventState ID를 "제1 래킹 전달" 단계(243)로 변경하기 위해 새로운 입력들을 투입할 수 있다. 와인 프레싱이 완료될 때, 새로운 업데이트 엔진 입력은 다른 탱크에 와인을 래킹하는 동작을 실행하고 "제1 래킹 전달" 이벤트 상태로 전이하도록 EASP에게 지시할 수 있다.

와인 제조 프로세스가 "제1 래킹 전달" 이벤트 상태에 있으면, 와인 제조자는 "말로락틱 발효" 이벤트 상태에 대한 전이 리소스(219)의 전이 이벤트 파라미터를 수정할 수 있다. 이 변경은 "통 숙성" 단계 대신에 "제2 래킹 전달" 단계(244)로의 전이를 재지시하는 것을 포함한다. 실행 동작 파라미터는 또한 숙성을 위한 통들에의 펌핑이 아니라 와인을 별개의 탱크로 펌핑하도록 수정될 수 있다. 이러한 요청은 처리가 여전히 "제1 래킹 전달" 단계(243) 내에 있으므로 성공적으로 처리될 수 있다.

업데이트 엔진(213)의 전체 절차가 도 8에 도시되어 있다. 단계(271)에서, IoT 요청자(241)는 대응하는 EASP 프로세스가 능동적으로 실행되는 동안 전이 리소스를 업데이트한다. 예로서, IoT 요청자(241)는 전이 리소스(219)의 전이 이벤트들 및 다음 EventState ID 파라미터들을 변경하기를 원할 것이다. 대안적으로, IoT 요청자(241)는 현재 전이 리소스(219) 내의 값들보다는 상이한 전이 이벤트들 및 다음 EventState ID 파라미터들을 갖는 새로운 전이 리소스(219)를 생성할 수 있다. 이러한 경우들 중 임의의 것은 업데이트 엔진(213)의 활성화를 트리거링할 수 있다. 또한, EventState 리소스를 생성 또는 수정하는 것은 또한 업데이트 엔진(213)의 동작들을 트리거링할 것이다. 단계(272)에서, 리소스 관리자(214)는 단계(271)의 요청을 처리하고 이벤트 및 동작 시퀀싱 시스템(210)에 의해 요구되는 검증들을 수행한다. 단계(273)에서, 리소스 관리자(214)는 EASP 프로세스가 능동적으로 실행되고 있다는 것을 인식하고 업데이트 요청을 처리를 위해 업데이트 엔진(213)에 전송한다. 단계(274)에서, 리소스 관리자(214)는 ACK 응답을 회신하여, 업데이트 요청이 처리되고 있고 업데이트 엔진(213)으로부터의 결과가 계류 중이라는 것을 IoT 요청자에게 알린다. 응답은 추적 목적들을 위해 리소스 관리자(214)에 의해 생성된 UpdateID를 포함할 수 있다. 현재 상태의 그 상태뿐만 아니라 전체 EASP의 상태와 같은 다른 관련 정보가 또한 포함될 수 있다.

도 8을 계속 참조하면, 단계(275)에서, 업데이트 엔진(213)은 실행 유닛(216)과 통신함으로써 업데이트가 안전하게 이루어질 수 있고 동작들에 부정적으로 영향(예를 들어, 치명적 에러 또는 다른 임계 에러)을 주지 않는지를 평가한다. 업데이트가 안전하게 이루어질 수 있는 경우, 단계(276)로 계속되고, 그렇지 않으면 단계(277)로 진행한다. 전이 리소스(또는 속성)는 다음 단계로 EASP가 어떻게 전이하는지를 지시할 수 있다. 단계(276)에서, 업데이트가 EASP의 동작들에 부정적으로 영향(예를 들어, 치명적 에러 또는 다른 임계 에러)을 주지 않고 행해질 수 있는 경우, 업데이트 엔진(213)은 도 6에 도시된 바와 같이 실행 유닛(216)에 입력들을 추가하여 EASP 동작들을 업데이트한다. 단계(277)에서, 업데이트 엔진(213)은 리소스 관리자(214)에게 적절한 응답을 회신한다. 단계(278)에서, 업데이트 엔진(213)이 성공적인 응답을 회신하는 경우, 리소스 관리자(214)는 업데이트 요청에서 제공되는 정보로 데이터베이스(215)를 업데이트한다. 단계(279)에서, 리소스 관리자(214)는 IoT 요청자(241)에게 적절한 응답을 회신하고, 단계(274)로부터의 UpdateID 및 업데이트된 상태를 포함할 수 있다. 에러들과 관련하여, 이것은 EASP의 구현에 의존할 수 있다. 도 6에서, 단계(263)는 EASP에 영향을 주는 이벤트들을 검출하는 것을 담당한다. 업데이트가 행해지고, EASP가 타이머 만료에 대한 이벤트를 모니터링하고 있는 경우, EASP는 변경을 행할 수 있다. 그러나, 다른 입력들이 모니터링되고 있다면, EASP는 이들이 트리거링할 때를 알지 못한다. 따라서, EASP는 "치명적 에러"를 생성할 수 있다. 타이머 만료로 다시 돌아가면, 업데이트가 수신될 때 타이머 만료가 곧 만료되는 경우 "임계 에러"가 생성될 수 있다.

추가적인 예들: 구성가능한 이벤트 및 동작 시퀀싱 시스템(210)(본 명세서에서는 이벤트 및 동작 시퀀싱 시스템(210)이라고도 지칭됨)은 oneM2M 및 OCF와 같은 기존의 IoT 아키텍처들에 통합될 수 있다. 이하에서는, 이벤트 및 동작 시퀀싱 시스템(210)이 이러한 아키텍처들에 통합될 수 있고, oneM2M 예들이 본 명세서에 개시된 와인 제조 이용 사례에 적용되는 방법에 대한 예들이 제공된다. 또한, 이벤트 및 동작 시퀀싱 시스템(210)을 이용하여 EASP들의 상호작용 제어가 어떻게 실현될 수 있는지를 보여주기 위해 산업 공장 이용 사례가 제시된다. 또한 본 명세서에서는, EASP의 단계들을 요약하는 사용자에게 회신되는 표를 나타낼 수 있는 예시적인 그래픽 사용자 인터페이스가 도시된다(도 15).

oneM2M은 공통 서비스 기능들(CSF들)이 애플리케이션들에 데이터 관리, 디바이스 관리 등과 같은 서비스들을 제공하는 서비스 계층 아키텍처를 정의하였다. 이러한 CSF들은 클라우드 서버, 게이트웨이 디바이스 또는 심지어 모바일 디바이스 상에서 실행될 수 있는 공통 서비스 엔티티(CSE) 내에 함께 결합된다. 애플리케이션들은 이어서 CSE에 의해 제공되는 서비스들을 이용하도록 등록할 수 있다. 구성가능한 이벤트 및 동작 시퀀싱 시스템(210)은 이후 제공되는 서비스들 중 하나로서 CSE 내에 통합될 수 있다. 사실상, 이벤트 및 동작 시퀀싱 시스템(210) 자체는 CSF들 중 하나일 수 있다.

일단 이벤트 및 동작 시퀀싱 시스템(210)이 통합되면, EASP 리소스(217), EventState 리소스(218) 및 전이 리소스(219)에 대한 개시된 리소스들은 이후 oneM2M 아키텍처에 추가될 수 있다. 표 4 및 표 5는 개시된 <easp> 리소스에 대한 자식 리소스들 및 리소스 특정 속성들을 각각 열거한다.

<표 4>

<표 5>

표 6 및 표 7은 새롭게 개시된 <eventState> 리소스에 대한 자식 리소스들 및 리소스 특정 속성들을 각각 열거한다. transitionEvents 속성은 여기서 상태 전이들을 지정하는 잠재적인 방식으로서 지정된다는 점에 유의한다. 대안적인 방법은 표 8 및 표 9에 나타낸 바와 같이 이벤트 상태 전이들에 관한 정보를 <transition> 리소스에 두는 것이다.

<표 6>

<표 7>

표 8 및 표 9는 새롭게 개시된 <transition> 리소스에 대한 자식 리소스 및 리소스 특정 속성들을 각각 열거한다. <transition> 리소스의 존재는 <eventState> 리소스의 transitionEvents, transitionActions, 및 nextEventStateID 속성들에 대한 필요성을 제거할 수 있고 그 반대도 가능하다는 점에 유의한다.

<표 8>

<표 9>

도 9는 와인 제조 이용 사례에 대한 개시된 <easp> 리소스(280)의 예를 도시한다. 이 예에서, 와인 제조 프로세스는 <easp> 리소스에 의해 표현되는 EASP로서 실현된다. 따라서, 와인 제조 프로세스 및 EASP는 상호교환적으로 이용될 수 있다. <easp> 리소스는 "wineMaking"이라고 명명되고, 그 속성들 및 자식 리소스들은 아래에 열거된다. 이 리소스는 와인 제조자에 의해 CSE 상에서 먼저 생성되어 와인 제조 프로세스에서 요구되는 단계들을 캡처한다. 전제 조건들, exitConditions, 및 다른 속성들(281-287)이 도 9에 도시되어 있다. 도 9는 이벤트 상태들이 생성된 후의 <easp> 리소스(280)의 표현을 도시하고, 따라서 numberEvents 속성(285)은 "8"이고, initialEvent 속성(286)은 "eid1"이고, finalEvent 속성(287)은 "eid8"이다. EASP는 아직 시작되지 않고, 제어 속성(284) 및 currentStatus 속성(283) 모두는 각각 이것을 "디스에이블" 및 "시작되지 않음"의 값들로 반영한다. 와인 제조자가 제어 속성(284)을 이용하여 EASP를 상호작용적으로 제어할 수 있기 때문에, 전제 조건 이벤트들이 없고, exitConditions 이벤트들도 없다. 일부 구현예들에서 속성(예를 들어, finalEvent 속성)이라고 지칭되는 것이 리소스일 수 있고 그 반대도 가능하다는 점이 고려된다.

<easp> 리소스(280)가 생성되면, 와인 제조자는 이후 8개의 <eventState> 리소스(288)를 <easp> 리소스(280)의 자식 리소스들로서 생성한다. 각각의 <eventState> 리소스(288)는 이름 "step#" - 여기서 #는 와인 제조 프로세스 내의 단계의 번호임 -, 및 "eid#"의 eventStateID - 다시 #는 단계 번호와 연관됨 -를 갖는다. 도 10은 단계(203), 발효 단계에 대한 <eventState> 리소스(290)의 예를 도시한다. currentStatus는 2주의 timeDuration 동안 50%에 있으며, 이는 발효 프로세스가 1주 동안 이미 경과했다는 것을 의미한다. 여기에 도시된 값들은 하이 레벨의 예시적인 표현들이고 실제 값을 반영하지 않을 수 있다. 예를 들어, timeDuration 속성은 인간의 판독가능한 라벨 "주" 대신에 초 단위의 값을 가질 수 있다. 단계(203)에 대한 이벤트 상태 내에서, 이들 각각의 전이 이벤트가 발생할 때 어떤 동작들이 수행되는지를 지시하는 3개의 <transition> 리소스(예를 들어, transition1 리소스(295), transition2 리소스(296), transition3 리소스(297))가 존재한다.

exitConditions 속성(294)은 발생하지 않아야 하는 전이 이벤트들 중 임의의 것을 무시하는 메커니즘을 제공한다. 이 메커니즘은 이벤트 상태가 고착되고 이벤트 상태에 남아 있는 것이 바람직하지 않은 동작들을 초래할 경우들을 방지하는데 이용될 수 있다. 예를 들어, 와인의 발효는 2주 또는 당도가 0에 도달할 때로 제한되며, 어느 것이든 먼저 발생하면 된다. 나가기 조건을 지정하는 것은 당도가 결코 0에 도달하지 않더라도 단계가 결국 종료할 것임을 보장한다. exitConditions 속성(294) 내의 각각의 엔트리는 2개의 값을 포함한다: 제1 값은 나가기 이벤트를 지정하고, 제2 값은 executeActions 및 nextStateEventID가 지정된 전이 리소스를 지정한다. 이것은 메커니즘의 하나의 실현이지만, 명시적으로 동작들 및 nextEventStateID를 지정하기 위한 다른 메커니즘들이 구현될 수 있다. 속성은 심지어 복잡한 데이터 유형을 이용하여 복수의 나가기 조건들을 지원할 수 있다.

<eventState> 단계(203) 내에서, 3개의 전이 이벤트 중 하나가 2주 발효 기간 동안 발생할 수 있다. transition1 이벤트는 온도를 측정하기 위해 4시간마다 수행되고, 값이 표시된 범위 밖으로 떨어지면 조정들이 이루어진다. 이벤트는 단계(203)가 시작되었고, 취해진 동작들이 checkTemp 및 adjustTemp일 때 초기에 설정되는 타이머의 만료에 의해 트리거링된다. 이벤트들 및 동작들 모두는 M2M, V-0.5.0 [2]에서의 동작 트리거링의 TR-0021 연구에서 제공된 메커니즘들에 의해 캡처될 수 있거나, 또는 "<resource_URI> <operator> <value>"와 같은, 연산자와 분리된 키-값 쌍으로서 지정된 간단한 표현일 수 있다. 간단한 표현들을 결합하기 위해 논리 연산자들을 이용하여 복잡한 표현들이 생성될 수 있다. nextEventStateID 속성은 전이할 다음 이벤트 상태를 지정한다. transition1 이벤트의 경우, 지정된 동작을 수행한 후에 EASP는 현재 단계에 남아 있는다.

transition2 이벤트는 발효 기간 동안 6시간마다 발생한다. 이 이벤트는 펀치 툴이 더 균일한 발효를 위해 과일액을 균질의 상태로 혼합할 수 있게 한다. transition2 이벤트의 경우, EASP는 단계(204)로 이동하고, 여기서 펀치 툴은 발효 단계로 복귀하기 전에 5분 동안 가동하도록 구성되며, 그 상세들은 도 15를 참조한다. 마지막으로, transition3 이벤트는 당도가 0에 도달할 때 발효 기간의 끝을 검출한다. 이에 응답하여, 프레싱 툴을 턴 온하는 동작이 실행되고, EASP는 단계(205)로 이동한다.

발효 기간 동안, 와인 제조자는 와인을 맛보고 그 전개를 모니터링한다. 이 시간 동안, 와인 제조자는 마지막 순간에 두 번의 별도 시간에 래킹 절차를 수행하여 더 높은 품질의 와인을 생산하도록 선택할 수 있다. 이것은 도 7b에 도시된 바와 같이 말로락틱 발효 단계(206) 전후에 와인을 래킹하는 것을 포함한다. 도 1에서의 원래의 와인 제조 프로세스가 단계(205)에서 프레싱 및 래킹 절차들을 함께 결합했기 때문에, 이 결정은 EASP 흐름에 대한 업데이트를 요구한다. 와인 제조자는 먼저 2개의 래킹 절차 각각을 캡처하기 위해 새로운 단계(243) 및 단계(244)를 추가한다. 그 후, 와인 제조자는 프레싱 절차가 실행되는 동안 단계(205)의 전이 리소스(295)를 업데이트한다. 이러한 업데이트는 프레싱이 아직 완료되지 않았기 때문에 업데이트 엔진(213)에 의해 안전하게 통합될 수 있다. 도 15의 랙 1 및 랙 2와 관련하여 도시된 업데이트는 기존의 전이 이벤트를 무시하고 단계(205)에서 래킹 절차를 우회한다. 대신에, 새로운 전이는 제1 래킹 절차를 수행하기 위해 단계(243)로 진행할 것이다.

제1 래킹 전달(단계(243))이 발생함에 따라, 와인 제조자는 전이 리소스(297)를 업데이트하여 단계(206)의 전이(297) 리소스에 대해 도 15에 도시된 바와 같이 제2 래킹 전달을 시작한다(단계(244)). 단계(243)에서, 와인은 24시간 동안 침강시키는 것이 허용되고, lees1(총 찌꺼기라고 함)을 제거하는 동작들 및 발효를 위한 박테리아의 추가가 뒤따른다. 이때, EASP는 단계(206)로 계속되고, 여기서, 말로락틱 발효는 최대 6주 동안 발생한다. 단계(203)와 유사하게, 말로락틱 발효는 발효 레벨이 0이거나 6주의 지속시간이 만료되는 나가기 조건을 갖는다. 이러한 조건들 중 임의의 것은 EASP가 제2 래킹 전달이 가능하게 되는 단계(244)로 계속되도록 강제할 것이다.

제2 래킹 전달 내에서, 3개의 전이 리소스는 서로를 따라 함께 링크된다. transition1은, 탱크 레벨이 0에 있는 것으로 나타난 바와 같이, 래킹 절차가 완료될 때 이벤트를 캡처한다. "transition1 = 수행됨"이라는 표현에 의해 나타낸 바와 같이, EASP는 transition2 이벤트로 계속된다. transition2에서 실행되는 동작들은 와인의 다양한 레벨들을 체크하고 이들을 필요에 따라 조정하는 것이다. 이러한 동작들은 총 산도, pH 등의 레벨들을 체크하고 조정하기 위해 다른 EASP에 의해 캡처될 수 있다. 마지막으로, 레벨들이 적절하게 조정될 때, 미세한 앙금을 제거하기 위한 EASP가 시작되고 일단 끝나면, EASP는 통 숙성 단계로 진행한다.

통 숙성 단계는 1년 이상까지 걸릴 수 있으므로, 와인 제조자는 "[control,transition2]"의 exitConditions 속성 값을 지정한다. 각각의 <transition> 리소스는 그 <eventState> 리소스와 연관되며, 예를 들어 eventState eid3으로부터의 transition2(296으로 라벨링됨)는 eventState eid7에 대한 이 transition2 리소스와 상이하다는 것을 이해해야 한다. 이 나가기 조건은 <easp> 리소스(280)의 제어 속성에 기반하고 와인을 맛보는 와인 제조자에 의해 결정된다. 와인 제조자는 <easp> 리소스(280)의 제어 속성을 명시적으로 변경함으로써 이 단계를 갑작스레 종료할 수 있다. 그렇지 않으면, 와인 제조자는 숙성 프로세스가 지정된 timeDuration에서 종료하게 할 수 있다. 그 다음, EASP는 정제 및 병에 채워 넣기의 마지막 단계로 계속된다. 정제 및 병에 채워 넣기 절차들은 3개의 주요 이벤트로 구성된다: transition1 리소스에서 정제 필터를 턴 온하는 것, transition2 리소스에서 정제 필터를 턴 오프하고 병에 채워 넣기 프로세스를 턴 온하는 것, 및 마지막으로, transition3 리소스에서 병에 채워 넣기 프로세스를 턴 오프하는 것이다. 이 참조는 eid3이 아니라 eid8에 대한 것이다. 이것은 transition2 및 transition3 리소스들에 적용된다.

OCF(Open Connectivity Forum) - OCF는 IoT 디바이스들이 서로 통신하기 위해 서비스 계층 기능들을 정의할 때 oneM2M과 유사한 다른 IoT 아키텍처이다. OCF(예를 들어, OIC 코어 사양, v1.1.0 [3])에서, 리소스들 자체는 CSE들 상에서 중앙적으로 디바이스 리소스들을 호스팅하는 oneM2M과 달리 OIC 서버들 상에서 국지적으로 호스팅된다. 그러나, OCF는 게이트웨이 디바이스로서 실현될 수 있는 OIC 중개자를 정의하였다. 도 12는 OCF에 의해 정의된 엔티티 역할들의 예를 도시한다. OIC 클라이언트는 OIC 중개자의 지원을 통해 OIC 서버에 요청을 한다. OIC 중개자는 복수의 디바이스 리소스들에 대한 액세스를 가질 수 있고, 그 결과, 본 명세서에 개시된 EASP 프로세스 기능을 이용할 수 있다. 따라서, 구성가능한 이벤트 및 동작 시퀀싱 시스템(210)은 본 명세서에 개시된 서비스들을 제공하기 위해 게이트웨이의 일부로서 통합될 수 있다. IoT 프로세스들이 정의되고 이들 디바이스들을 모니터링하고 제어하는데 이용될 수 있는 다양한 IoT 디바이스들 및 그 리소스들에 대한 액세스를 갖는다.

OCF는 장면들, 규칙들 및 스크립트들의 이용을 통해 작업들을 자동화하기 위한 메커니즘들을 정의한다. 이러한 리소스들은 이벤트 관리형 동작들을 제공하지만, 그 기능은 특정 이벤트들이 진정한 것인지를 검출하고, 이어서 일부 자동화된 작업들을 수행하기 위해 스크립트들을 실행하는 것만으로 현재 제한된다. 이러한 리소스들을 업데이트하는 것은 본 명세서에 개시된 EASP 프로세스 기능을 가능하게 하기 위해 꽤 많은 재작업을 수반할 것이다. 그 결과, 새로운 OIC 리소스들이 본 명세서에서 OCF 예들로서 도입될 것이다.

새로운 OCF 리소스 유형들은 표 10에 도시된 바와 같이 정의될 수 있다. 이러한 리소스 유형들은 도 3에 도시된 것과 유사하지만 OCF 사양 내에 맞도록 지정된 구조를 정의한다. 최상위 레벨에서는 oic.wk.easplist 리소스 유형이며, 이는 자식 oic.wk.easp 리소스들을 호스팅하는 컬렉션 리소스이다. 자식 oic.wk.easp 리소스들은 위에서 개시된 EASP 리소스와 동일하다. 마지막으로, oic.wk.eventState 리소스는 oic.wk.easp의 자식 리소스들이고 EASP 프로세스의 EventState 리소스를 나타낸다. 이어서, 전이 리소스는 아래에 개략적으로 설명되는 바와 같이 OCF 리소스 특성으로서 실현될 것이다. 개시된 리소스 유형들은 "oic.wk" 프리픽스를 이용하고, 대안 프리픽스 "oic.r"은 OIC 리소스 유형들을 지정하는데 또한 이용될 수 있다는 점에 유의한다. 유의할 다른 것은 후술하는 바와 같이 요청자에게 EASP 프로세스의 특수화된 표현을 제공하는 oic.if.easp 인터페이스의 도입이다. 새로운 리소스 유형들은 또한 다른 OCF 정의된 인터페이스들을 지원할 수 있지만, 이들은 간결성을 위해 열거되지 않는다.

<표 10>

표 11은 oic.wk.easplist 리소스에 대한 개시된 특성들을 보여준다. 대부분의 특성들은 OIC 컬렉션 리소스들을 지원하기 위해 제공된다. nf 특성은 컬렉션에 관한 상태 정보를 제공하고, 얼마나 많은 oic.wk.easp 리소스들(IoT 프로세스들)이 이 컬렉션에서 발견되는지를 나타낸다. 이 정보는 컬렉션을 관리하는데 이용될 수 있고, 또한 이벤트 및 동작 시퀀싱 시스템(210)의 부하를 결정할 수 있다.

<표 11>

표 12는 oic.wk.easp 리소스에 대한 개시된 특성들을 보여준다. 이러한 특성들은 전술한 바와 같은 <easp> 리소스(280)의 파라미터들을 나타낸다. 이러한 특성들은 위에서 지정된 바와 동일한 기능들을 갖는다.

<표 12>

표 13은 oic.wk.eventState 리소스에 대한 개시된 특성들을 보여준다. 이러한 특성들은 전술한 바와 같은 <eventState> 리소스의 파라미터들을 나타낸다. 이 경우에, 전이 파라미터는 oic.wk.eventState의 자식 리소스보다는 OIC 특성으로서 표현된다는 점에 유의한다. 이것은 또한 전이 리소스로서 상태 전이들을 결정하기 위한 동일한 기능들을 제공한다.

<표 13>

하나의 고유 OCF 특징은 OCF 리소스 내로의 뷰로서 정의되는 OCF 인터페이스들의 개념이다. OCF에서, 인터페이스는 그 리소스에 액세스할 때 어떤 유형들의 요청들 및 응답들이 허용되는지를 정의한다. 예를 들어, OCF oic.if.baseline 인터페이스는 검색 및 업데이트 요청들 모두가 리소스에 대해 이루어지는 것을 허용하고, 응답들은 메타 특성들을 포함하는 리소스의 전체 표현을 포함한다. 표 14는 OCF 인터페이스들의 리스트를 보여준다. 한편, oic.if.r 인터페이스는 리소스의 특성들을 검색하라는 것으로만 요청들을 제한한다. 이러한 인터페이스 개념을 이용하여, 요청에서 제공된 질의 스트링에 따라 상이한 응답들을 제공하는 것을 허용하기 위해 새로운 OCF 인터페이스 oic.if.easp가 생성될 수 있다. 이 인터페이스는 이후 디바이스가 리소스 관리자(214)의 동작에서 설명된 개시된 응답들, 즉 현재 표현, 현재 EASP 및 이벤트 상태, 및 전체 EASP 구조 중 하나를 회신하게 할 것이다. 추가 응답 데이터는 또한 이벤트 및 동작 시퀀싱 시스템(210)에 의해 요구되는 바와 같이 이 인터페이스에 의해 제공될 수 있다. 이들 특수화된 응답들을 제공하기 위해 새로운 oic.if.easp 인터페이스가 정의되어 표 14에 추가될 수 있다.

<표 14>

산업 공장 - 산업 공장에서, 조립 라인들은 특정 기능들을 수행하는 로봇들에 의해 운영된다. 최종 제품을 제조하기 위해 함께 시퀀싱된 복수의 스테이션들이 있다. 도 13은 함께 상호접속된 2개의 이러한 스테이션을 도시하며, 스테이션들(220)(스테이션(317) 및 스테이션(318))의 출력은 스테이션들(210)(스테이션(311)-스테이션(315))에 대한 입력이다. 스테이션(220)에 대한 스테이션들은 시간당 5개의 유닛의 속도로 출력할 수 있고, 스테이션(210)에 대한 스테이션들은 시간당 2개의 유닛의 속도로 입력들을 수신할 수 있다. 스테이션들은 생산성을 최대화하기 위해 로봇들이 유휴 상태로 유지되는 시간을 최소화하도록 조정된다.

공장은 본 명세서에 개시된 구성가능한 이벤트 및 동작 시퀀싱 시스템(210)을 구현하고, 도시된 스테이션들 각각을 제어하기 위해 EASP가 생성된다. 각각의 EASP 프로세스는 복수의 이벤트 상태들을 가지며, 이벤트 상태들은 원하는 속도로 각각의 스테이션 출력들을 보장하도록 지속시간 파라미터를 이용하여 제어된다. 이벤트 및 동작 시퀀싱 시스템(210)에 대한 관리자는 IoT 프로세스들 각각에 대한 완전한 액세스를 가지며, 필요에 따라 이들을 상호작용적으로 제어할 수 있다. 또한, 각각의 로봇은 그 동작의 진단들을 제공하고, 따라서 관리자는 각각의 스테이션의 출력을 모니터링할 수 있다.

스테이션(311)은 신뢰성 있게 동작하였지만 최근 고장들의 징후들을 나타내는 오래된 로봇을 포함할 수 있다. 하나의 시프트 동안, 스테이션(311)은 그 구성요소들 중 하나가 적절하게 동작하고 있지 않다는 진단 정보를 전송한다. 이에 응답하여, 관리자는 스테이션(311)의 EASP 리소스의 제어 파라미터를 "즉시 나가기"로 변경하라는 요청을 전송하여 스테이션을 중단시킨다. 이어서, 관리자는 스테이션(311)이 중단되는 것을 고려하여 더 느린 속도로 출력하도록 스테이션들(317) 및 스테이션(318)의 IoT 프로세스들을 재프로그래밍한다. 도 14는 스테이션(317) 및 스테이션(318)의 IoT 프로세스들 각각을 상호작용적으로 제어하기 위해 관리자에 의해 실행되는 호출 흐름을 도시한다.

도 14는 EASP 프로세스의 예시적인 상호작용 제어를 도시한다. 단계(331)에서, 관리자(321)는 스테이션(317)의 EASP 리소스(예를 들어, EASP 리소스(217))를 타겟으로 하는 업데이트 요청을 전송하여 EASP를 일시정지시킨다. 제어 파라미터는 이 경우에 '일시정지'로 설정된다. 단계(332)에서, 이벤트 및 동작 시퀀싱 시스템(210) 내에서, 리소스 관리자(214)는 구성가능한 이벤트 및 동작 시퀀싱 시스템(210)의 일부인 실행 유닛(216)에 신호를 전송하여 현재 이벤트 상태의 동작을 중지시킨다. 실행 유닛(216)은 이벤트 상태의 실행을 제어하고 있는 타이머를 정지시키고 수행될 수 있는 임의의 동작들을 중단시킬 수 있다. 단계(333)에서, 이벤트 및 동작 시퀀싱 시스템(210)은 EASP가 일시정지된 것을 나타내는 응답을 회신할 수 있다. 관리자(321)는 스테이션(318)의 EASP에 대해 단계(331) 내지 단계(333)를 반복할 수 있다. 단계(334)에서, 관리자(321)는 스테이션(317)의 EASP 리소스의 지속시간 파라미터들을 시간당 4개의 유닛의 속도로 출력하도록 조정한다. 관리자는 필요에 따라 복수의 EventState 리소스들(예를 들어, EventState 리소스(218))에 대한 이 요청을 수행한다.

도 14를 계속 참조하면, 단계(335)에서, 리소스 관리자(214)는 스테이션(317)의 EASP 리소스의 EventState 리소스들에 대한 적절한 변경들을 행한다. 현재 이벤트 상태에 대해, 리소스 관리자(214)는 그 변경을 실행 유닛(216)에 직접 시그널링할 수 있다. 대안적으로, 리소스 관리자(214)는 그 변경을 업데이트 엔진(213)에 전송하여 기존의 이벤트 상태를 업데이트할 수 있다. 비활성 EventState 리소스들의 경우, 리소스 관리자(214)는 대응하는 EventState 리소스의 데이터베이스(215)를 간단히 업데이트할 수 있다. 단계(336)에서, 이벤트 및 동작 시퀀싱 시스템(210)은 변경이 이루어졌다는 것을 나타내는 응답을 회신한다. 관리자는 스테이션(318)의 EASP에 대해 단계(334) 내지 단계(336)를 반복할 수 있다. 단계(337)에서, 모든 지속시간 파라미터들이 변경되면, 관리자는 스테이션(317)의 동작들을 재시작하라는 "재개" 요청을 전송한다. 이것은 제어 파라미터가 '재개'로 설정되는 요청을 전송하는 것을 수반할 수 있다. 단계(338)에서, 리소스 관리자(214)는 신호를 실행 유닛(216)에 전송하여 현재 이벤트 상태의 동작들을 재시작한다. 이때, 타이머는 생산 속도를 늦추는 단계(334) 내지 단계(336)에서 이루어진 변경을 반영할 것이다. 단계(339)에서, 이벤트 및 동작 시퀀싱 시스템(210)은 EASP가 재시작된 것을 나타내는 응답을 회신한다. 관리자는 스테이션(318)의 EASP에 대해 단계(337) 내지 단계(339)를 반복할 수 있다.

사용자 인터페이스 - 도 15는 구성가능한 이벤트 및 동작 시퀀싱 프레임워크(210)가 표 형태의 EASP 프로세스의 정보를 보여주기 위해 제공할 수 있는 예시적인 사용자 인터페이스를 도시한다. 여기서 이 표는 전술한 와인 제조 이용 사례에서의 eventStates를 도시하고 웹 인터페이스를 통해 제시될 수 있다. 이 표 내의 정보는 회신될 응답 데이터를 지정하기 위한 질의 인터페이스를 이용하여 이벤트 및 동작 시퀀싱 시스템(210)으로부터 검색될 수 있다. 이 경우, 이것은 EASP의 상태 및 현재 이벤트 상태뿐만 아니라 EASP 리소스 구조를 회신하도록 지정될 수 있다. 이 표 내에서, 현재 이벤트 상태는 eid5(볼드체)이다. 이 표는 컬러 코딩될 수 있다. 예를 들어, 기존 이벤트 상태들은 흑색일 수 있고, (EASP가 실행 중인 동안) 새롭게 추가된 이벤트 상태들은 연한 청색일 수 있다. currentStatus 속성에 대한 텍스트는 와인 제조자에게 빠른 시각적 표현을 제공하기 위해 컬러 코딩될 수 있다. 적색 텍스트는 만들어진 기존의 속성들의 EASP에 대한 현재의 업데이트들을 나타낼 수 있다.

<easp> 리소스가 생성되었으면, 이것은 미래의 이용을 위해 저장될 수 있고 다른 와인 유형들에 대해 조정될 수 있다. 와인 제조자는 상이한 발효 시간들을 이용하여 실험하고, 상이한 포도 품종들을 고려하여 필요에 따라 이벤트 상태들을 추가하거나 제거할 수 있다. 발효가 회분마다 다를 수 있기 때문에, 와인 제조자가 EASP의 동작들을 조정하는 능력은 가능한 최고 맛의 와인을 생산하는데 중요하다.

도 16은 본 명세서에서 논의된 방법들 및 시스템들에 기반하여 생성될 수 있는 예시적인 디스플레이(예컨대, 그래픽 사용자 인터페이스)를 도시한다. 디스플레이 인터페이스(901)(예를 들어, 터치 스크린 디스플레이)는 EASP 프로세스의 스냅샷 뷰를 제공할 수 있다. 디스플레이 인터페이스(902)의 제목은 EASP의 이름들 및 현재 이벤트 상태를 각각 보여준다. 제목 아래에는 현재 이벤트 상태가 강조된 전체 EASP 프로세스의 하이 레벨 흐름(903)이 있다. 디스플레이 인터페이스의 하단에는 EASP 프로세스(904) 및 현재 이벤트 상태(905) 모두에 대한 상태 정보가 있다. EASP 프로세스 상태(904)의 경우, 상세들 및 제어 버튼들은 사용자가 EASP 프로세스를 보고 가능하게는 업데이트할 수 있게 한다. 현재 이벤트 상태(905)의 경우, 사용자에게 현재 이벤트 상태로부터의 가능한 전이들을 보여주기 위해 모든 다음 전이들의 리스팅이 표시된다.

도 17a는 이벤트 및 동작 시퀀싱 시스템(210)과 연관된 하나 이상의 개시된 개념(예를 들어, 도 2 내지 도 15 및 수반하는 논의)이 구현될 수 있는 예시적인 기기간(M2M), 사물 인터넷(IoT) 또는 사물 웹(Web of Things)(WoT) 통신 시스템(10)의 도면이다. 일반적으로, M2M 기술들은 IoT/WoT에 대한 빌딩 블록들을 제공하고, 임의의 M2M 디바이스, M2M 게이트웨이 또는 M2M 서비스 플랫폼은 이러한 IoT/WoT는 물론이고 IoT/WoT 서비스 계층 등의 구성요소일 수 있다.

도 17a에 도시된 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 통신 네트워크(12)를 포함한다. 통신 네트워크(12)는 고정형 네트워크(예를 들어, 이더넷, 파이버, ISDN, PLC 등) 또는 무선 네트워크(예를 들어, WLAN, 셀룰러 등)일 수 있거나, 또는 이종 네트워크들 중 하나의 네트워크일 수 있다. 예를 들어, 통신 네트워크(12)는 음성, 데이터, 비디오, 메시징, 브로드캐스트 등과 같은 콘텐츠를 복수의 사용자들에게 제공하는 다중 액세스 네트워크들로 구성될 수 있다. 예를 들어, 통신 네트워크(12)는 CDMA(code division multiple access), TDMA(time division multiple access), FDMA(frequency division multiple access), OFDMA(orthogonal FDMA), SC-FDMA(single-carrier FDMA) 등과 같은 하나 이상의 채널 액세스 방법을 이용할 수 있다. 또한, 통신 네트워크(12)는 예를 들어, 코어 네트워크, 인터넷, 센서 네트워크, 산업용 제어 네트워크, 개인 영역 네트워크, 융합형 개인 네트워크(fused personal network), 위성 네트워크, 홈 네트워크, 또는 엔터프라이즈 네트워크와 같은 다른 네트워크들을 포함할 수 있다.

도 17a에 도시된 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 인프라스트럭처 도메인 및 필드 도메인을 포함할 수 있다. 인프라스트럭처 도메인은 엔드-투-엔드 M2M 배치(end-to-end M2M deployment)의 네트워크 측을 지칭하고, 필드 도메인은 보통 M2M 게이트웨이 후방에 있는 영역 네트워크들(area networks)을 지칭한다. 필드 도메인은 M2M 게이트웨이들(14) 및 단말 디바이스들(18)을 포함한다. 임의의 수의 M2M 게이트웨이 디바이스들(14)과 M2M 단말 디바이스들(18)이 원하는 대로 M2M/IoT/WoT 통신 시스템(10)에 포함될 수 있다는 점을 이해할 것이다. M2M 게이트웨이 디바이스들(14) 및 M2M 단말 디바이스들(18) 각각은 통신 네트워크(12) 또는 직접 무선 링크를 통해 신호들을 전송 및 수신하도록 구성된다. M2M 게이트웨이 디바이스(14)는 무선 M2M 디바이스들(예를 들어, 셀룰러 및 비-셀룰러)뿐만 아니라 고정형 네트워크 M2M 디바이스들(예를 들어, PLC)이 통신 네트워크(12) 또는 직접 무선 링크와 같은 오퍼레이터 네트워크들을 통해 통신하게 한다. 예를 들어, M2M 디바이스들(18)은 데이터를 수집하고, 그 데이터를 통신 네트워크(12) 또는 직접 무선 링크를 통해 M2M 애플리케이션(20) 또는 M2M 디바이스들(18)에 전송할 수 있다. M2M 디바이스들(18)은 또한 M2M 애플리케이션(20) 또는 M2M 디바이스(18)로부터 데이터를 수신할 수 있다. 또한, 데이터 및 신호들은 이하 설명되는 바와 같이 M2M 서비스 계층(22)을 통해 M2M 애플리케이션(20)에 전송될 수 있고 그로부터 수신될 수 있다. M2M 디바이스들(18) 및 게이트웨이들(14)은, 예를 들어 셀룰러, WLAN, WPAN(예를 들어, 지그비, 6LoWPAN, 블루투스), 직접 무선 링크, 및 유선을 포함하는 다양한 네트워크들을 통해 통신할 수 있다.

도 17b를 참조하면, 필드 도메인에서의 도시된 M2M 서비스 계층(22)은 M2M 애플리케이션(20), M2M 게이트웨이 디바이스들(14), M2M 단말 디바이스들(18)과 통신 네트워크(12)에 서비스들을 제공한다. M2M 서비스 계층(22)이 원하는 대로 임의의 수의 M2M 애플리케이션들, M2M 게이트웨이 디바이스들(14), M2M 단말 디바이스들(18), 및 통신 네트워크들(12)과 통신할 수 있다는 점을 이해할 것이다. M2M 서비스 계층(22)은 하나 이상의 서버, 컴퓨터 등에 의해 구현될 수 있다. M2M 서비스 계층(22)은 M2M 단말 디바이스들(18), M2M 게이트웨이 디바이스들(14) 및 M2M 애플리케이션들(20)에 적용되는 서비스 능력들을 제공한다. M2M 서비스 계층(22)의 기능들은 다양한 방식들로, 예를 들어, 웹 서버로서, 셀룰러 코어 네트워크에서, 클라우드에서 등으로 구현될 수 있다.

도시된 M2M 서비스 계층(22)과 유사하게, 인프라스트럭처 도메인에는 M2M 서비스 계층(22')이 존재한다. M2M 서비스 계층(22')은 인프라스트럭처 도메인에서의 M2M 애플리케이션(20') 및 하위 통신 네트워크(12')에 서비스들을 제공한다. M2M 서비스 계층(22')은 또한 필드 도메인에서의 M2M 게이트웨이 디바이스들(14) 및 M2M 단말 디바이스들(18)에 서비스들을 제공한다. M2M 서비스 계층(22')이 임의의 수의 M2M 애플리케이션들, M2M 게이트웨이 디바이스들 및 M2M 단말 디바이스들과 통신할 수 있다는 점을 이해할 것이다. M2M 서비스 계층(22')은 상이한 서비스 제공자에 의한 서비스 계층과 상호작용할 수 있다. M2M 서비스 계층(22')은 하나 이상의 서버, 컴퓨터, 가상 머신(예를 들어, 클라우드/컴퓨터/스토리지 팜들 등) 등에 의해 구현될 수 있다.

또한, 도 17b를 참조하면, M2M 서비스 계층(22 및 22')은 다양한 애플리케이션들과 버티컬들(verticals)이 활용할 수 있는 서비스 전송 능력들의 코어 세트를 제공한다. 이러한 서비스 능력들은 M2M 애플리케이션들(20 및 20')이 디바이스들과 상호작용할 수 있게 하고 데이터 수집, 데이터 분석, 디바이스 관리, 보안, 청구, 서비스/디바이스 발견 등과 같은 기능들을 수행할 수 있게 한다. 본질적으로, 이러한 서비스 능력들은 이러한 기능들을 구현하는 애플리케이션들의 부담을 없애고, 이에 따라 애플리케이션 개발을 단순화하고, 마케팅 비용과 시간을 감소시킨다. 서비스 계층(22 및 22')은 또한 서비스 계층(22 및 22')이 제공하는 서비스들과 관련하여 M2M 애플리케이션들(20 및 20')이 다양한 네트워크들(12 및 12')을 통해 통신하는 것을 가능하게 한다.

일부 예들에서, M2M 애플리케이션들(20 및 20')은 본 명세서에 개시된 바와 같이 이벤트 및 동작 시퀀싱 시스템(210)을 이용하여 통신하는 원하는 애플리케이션들을 포함할 수 있다. M2M 애플리케이션들(20 및 20')은, 이에 제한되는 것은 아닌, 운송, 건강 및 보건, 커넥티드 홈(connected home), 에너지 관리, 자산 추적, 그리고 보안 및 감시와 같은 다양한 산업들에서의 애플리케이션들을 포함할 수 있다. 전술한 바와 같이, M2M 서비스 계층, 디바이스들에 걸쳐 실행하는 것, 게이트웨이들, 및 시스템의 다른 서버들은, 예를 들어 데이터 수집, 디바이스 관리, 보안, 청구, 위치 추적/지오펜싱, 디바이스/서비스 발견, 및 레거시 시스템들의 통합과 같은 기능들을 지원하고, 이러한 기능들을 서비스들로서 M2M 애플리케이션들(20 및 20')에 제공한다.

본 출원의 이벤트 및 동작 시퀀싱 시스템은 서비스 계층의 일부로서 구현될 수 있다. 서비스 계층은 API들(application programming interfaces) 및 하위 네트워킹 인터페이스들의 세트를 통해 부가 가치의 서비스 능력들을 지원하는 미들웨어 계층이다. M2M 엔티티(예를 들어, 하드웨어 상에서 구현되는 디바이스, 게이트웨이 또는 서비스/플랫폼과 같은 M2M 기능 엔티티)는 애플리케이션 또는 서비스를 제공할 수 있다. ETSI M2M과 oneM2M 모두는 본 출원의 이벤트 및 동작 시퀀싱 시스템을 포함할 수 있는 서비스 계층을 이용한다. oneM2M 서비스 계층은 CSF들(Common Service Functions)(즉, 서비스 능력들)의 세트를 지원한다. CSF들 중의 한 세트의 하나 이상의 특정 유형의 인스턴스화는 CSE(Common Services Entity)라고 지칭되며, 이는 상이한 유형들의 네트워크 노드들(예를 들어, 인프라스트럭처 노드, 중간 노드, 애플리케이션 특정 노드) 상에서 호스팅될 수 있다. 또한, 본 출원의 이벤트 및 동작 시퀀싱 시스템은 서비스 지향 아키텍처(SOA) 또는 리소스 지향 아키텍처(ROA)를 이용하는 M2M 네트워크의 일부로서 구현되어, 본 출원의 이벤트 및 동작 시퀀싱 시스템과 같은 서비스들에 액세스할 수 있다.

본 명세서에 개시된 바와 같이, 서비스 계층은 네트워크 서비스 아키텍처 내의 기능 계층일 수 있다. 서비스 계층들은 HTTP, CoAP 또는 MQTT와 같은 애플리케이션 프로토콜 계층 위에 통상적으로 있으며 클라이언트 애플리케이션들에 부가 가치 서비스들을 제공한다. 서비스 계층은 또한 예를 들어 제어 계층 및 운송/액세스 계층과 같은 더 낮은 리소스 계층에서 코어 네트워크들에 인터페이스를 제공한다. 서비스 계층은 서비스 정의, 서비스 실행시간 인에이블먼트, 정책 관리, 액세스 제어, 및 서비스 클러스터링을 포함하는 복수 카테고리들의 (서비스) 능력들 또는 기능들을 지원한다. 최근에, 수개의 산업 표준 기관들, 예를 들어 oneM2M은 M2M 유형들의 디바이스들 및 애플리케이션들을 인터넷/웹, 셀룰러, 엔터프라이즈 및 홈 네트워크들과 같은 배치들에 통합하는 것과 연관된 도전들을 해결하기 위해 M2M 서비스 계층들을 개발해 왔다. M2M 서비스 계층은 애플리케이션들 또는 다양한 디바이스들에, CSE 또는 SCL이라고 지칭될 수 있는, 서비스 계층에 의해 지원되는, 위에서 언급된 능력들 또는 기능들의 수집 또는 그 세트에 대한 액세스를 제공할 수 있다. 일부 예들은, 이에 제한되는 것은 아닌, 다양한 애플리케이션들에 의해 흔히 이용될 수 있는 보안, 과금, 데이터 관리, 디바이스 관리, 발견, 공급 및 접속성 관리를 포함한다. 이러한 능력들 또는 기능들은 M2M 서비스 계층에 의해 정의되는 메시지 포맷들, 리소스 구조들 및 리소스 표현들을 이용하는 API들을 통해 이러한 다양한 애플리케이션들에 이용가능하게 된다. CSE 또는 SCL은, 하드웨어 또는 소프트웨어에 의해 구현될 수 있고, 다양한 애플리케이션들 또는 디바이스들(즉, 이러한 기능적 엔티티들 사이의 기능적 인터페이스들)에 노출되는 (서비스) 능력들 또는 기능들을 제공하여 이들이 이러한 능력들 또는 기능들을 이용하게 하는 기능적 엔티티이다.

도 17c는 예를 들어 (IoT 디바이스(242)를 포함할 수 있는) M2M 단말 디바이스(18) 또는 (도 5의 하나 이상의 구성요소를 포함할 수 있는) M2M 게이트웨이 디바이스(14)와 같은 예시적인 M2M 디바이스(30)의 시스템도이다. 도 17c에 도시된 바와 같이, M2M 디바이스(30)는 프로세서(32), 트랜시버(34), 전송/수신 요소(36), 스피커/마이크로폰(38), 키패드(40), 디스플레이/터치패드(42), 비이동식 메모리(44), 이동식 메모리(46), 전원(48), GPS(global positioning system) 칩셋(50), 및 다른 주변기기들(52)을 포함할 수 있다. M2M 디바이스(30)는 개시된 주제와 일관성을 유지하면서 전술한 요소들의 임의의 서브-조합을 포함할 수 있다는 점이 이해될 것이다. M2M 디바이스(30)(예를 들어, 이벤트 및 동작 시퀀싱 시스템(210), IoT 디바이스(242), IoT 요청자(241), 및 다른 디바이스들)는 이벤트 및 동작 시퀀싱 시스템을 위한 개시된 시스템들 및 방법들을 수행하는 예시적인 구현일 수 있다.

프로세서(32)는, 범용 프로세서, 특수 목적 프로세서, 기존의 프로세서, DSP(digital signal processor), 복수의 마이크로프로세서들, DSP 코어와 관련되는 하나 이상의 마이크로프로세서, 제어기, 마이크로제어기, ASIC들(Application Specific Integrated Circuits), FPGA(Field Programmable Gate Array) 회로들, 임의의 다른 유형의 집적 회로(IC), 상태 머신 등일 수 있다. 프로세서(32)는 M2M 디바이스(30)가 무선 환경에서 동작할 수 있게 하는 신호 코딩, 데이터 처리, 전력 제어, 입력/출력 처리 또는 임의의 다른 기능을 수행할 수 있다. 프로세서(32)는 전송/수신 요소(36)와 결합될 수 있는 트랜시버(34)와 결합될 수 있다. 도 17c가 프로세서(32)와 트랜시버(34)를 별도의 구성요소들로서 도시하고 있지만, 프로세서(32)와 트랜시버(34)는 전자 패키지 또는 칩 내에 함께 통합될 수 있다는 것을 이해할 것이다. 프로세서(32)는 애플리케이션 계층 프로그램들(예를 들어, 브라우저들) 또는 무선 액세스 계층(RAN) 프로그램들 또는 통신들을 수행할 수 있다. 프로세서(32)는 예를 들어, 액세스 계층 또는 애플리케이션 계층 등에서의 인증, 보안 키 일치 또는 암호화 동작들과 같은 보안 동작들을 수행할 수 있다.

전송/수신 요소(36)는 신호들을 M2M 서비스 플랫폼(22)에 전송하거나 또는 그로부터 신호들을 수신하도록 구성될 수 있다. 예를 들어, 전송/수신 요소(36)는 RF 신호들을 전송하거나 수신하도록 구성된 안테나일 수 있다. 전송/수신 요소(36)는 WLAN, WPAN, 셀룰러 등과 같은, 다양한 네트워크들 및 에어 인터페이스들을 지원할 수 있다. 일 예에서, 전송/수신 요소(36)는, 예를 들어, IR, UV 또는 가시광 신호들을 전송하거나 수신하도록 구성된 이미터/검출기일 수 있다. 또 다른 예에서, 전송/수신 요소(36)는 RF 및 광 신호들 모두를 전송 및 수신하도록 구성될 수 있다. 전송/수신 요소(36)는 무선 또는 유선 신호들의 임의의 조합을 전송하거나 수신하도록 구성될 수 있다는 점이 이해될 것이다.

또한, 전송/수신 요소(36)가 단일 요소로서 도 17c에 도시되지만, M2M 디바이스(30)는 임의의 수의 전송/수신 요소들(36)을 포함할 수 있다. 보다 구체적으로, M2M 디바이스(30)는 MIMO 기술을 이용할 수 있다. 따라서, 일 예에서, M2M 디바이스(30)는 무선 신호들을 전송 및 수신하기 위한 2개 이상의 전송/수신 요소(36)(예를 들어, 복수의 안테나들)를 포함할 수 있다.

트랜시버(34)는 전송/수신 요소(36)에 의해 전송될 신호들을 변조하고, 전송/수신 요소(36)에 의해 수신되는 신호들을 복조하도록 구성될 수 있다. 위에서 언급된 바와 같이, M2M 디바이스(30)는 멀티-모드 능력들을 가질 수 있다. 따라서, 트랜시버(34)는 M2M 디바이스(30)가, 예를 들어 UTRA 및 IEEE 802.11과 같은, 복수의 RAT들을 통해 통신할 수 있게 하는 복수의 트랜시버들을 포함할 수 있다.

프로세서(32)는 비이동식 메모리(44) 또는 이동식 메모리(46)와 같은 임의의 유형의 적절한 메모리로부터의 정보에 액세스하거나 거기에 데이터를 저장할 수 있다. 비이동식 메모리(44)는 RAM(random-access memory), ROM(read-only memory), 하드 디스크, 또는 임의의 다른 유형의 메모리 저장 디바이스를 포함할 수 있다. 이동식 메모리(46)는 SIM(subscriber identity module) 카드, 메모리 스틱, SD(secure digital) 메모리 카드 등을 포함할 수 있다. 다른 예들에서, 프로세서(32)는, 서버 또는 홈 컴퓨터 상에서와 같이, M2M 디바이스(30) 상에 물리적으로 위치되지 않는 메모리로부터의 정보에 액세스할 수 있고, 거기에 데이터를 저장할 수 있다. 프로세서(32)는 본 명세서에 설명된 예들 중 일부에서의 이벤트 및 동작 시퀀싱과 연관된 방법들 및 시스템들이 성공적이거나 성공적이지 않은지(예를 들어, 요청 등)에 응답하여 디스플레이 또는 표시기들(42) 상의 조명 패턴들, 이미지들, 또는 컬러들을 제어하고, 이벤트 및 동작 시퀀싱 시스템(210) 및 연관된 구성요소들의 상태를 다른 방식으로 표시하도록 구성될 수 있다. 디스플레이 또는 표시기들(42) 상의 제어 조명 패턴들, 이미지들 또는 컬러들은 본 명세서에서 도시되거나 논의된 도면들(예를 들어, 도 1 내지 도 15 등)에서의 구성요소들 또는 방법의 흐름들 중 임의의 것의 상태를 반영할 수 있다. 이벤트 및 동작 시퀀싱 시스템의 메시지들 및 절차들이 본 명세서에 개시되어 있다. 메시지들 및 절차들은 사용자들이 입력 소스(예를 들어, 스피커/마이크로폰(38), 키패드(40), 또는 디스플레이/터치패드(42))를 통해 이벤트 및 동작 시퀀싱 시스템 정보(예를 들어, EventState 리소스(218))를 요청하기 위한 인터페이스/API를 제공하도록 확장될 수 있다. 추가 예에서, 특히 디스플레이(42) 상에 표시될 수 있는, 이벤트 및 동작 시퀀싱 시스템 정보의 요청, 구성 또는 질의가 존재할 수 있다.

프로세서(32)는 전원(48)으로부터 전력을 수신할 수 있고, 전력을 M2M 디바이스(30) 내의 다른 구성요소들에 분배 또는 제어하도록 구성될 수 있다. 전원(48)은 M2M 디바이스(30)에 전력을 공급하기 위한 임의의 적절한 디바이스일 수 있다. 예를 들어, 전원(48)은 하나 이상의 건전지 배터리(예를 들어, 니켈-카드뮴(NiCd), 니켈-아연(NiZn), 니켈 금속 수소화물(NiMH), 리튬-이온(Li-ion) 등), 태양 전지들, 연료 전지들 등을 포함할 수 있다.

프로세서(32)는 또한 GPS 칩셋(50)과 결합될 수 있으며, 이는 M2M 디바이스(30)의 현재 위치에 관한 위치 정보(예를 들어, 경도 및 위도)를 제공하도록 구성된다. M2M 디바이스(30)는 본 명세서에 개시되는 정보와 일관성을 유지하면서 임의의 적절한 위치 결정 방법에 의해 위치 정보를 획득할 수 있다는 점이 이해될 것이다.

프로세서(32)는 다른 주변기기들(52)에 또한 결합될 수 있으며, 이러한 주변기기들은, 추가적인 특징들, 기능, 유선 또는 무선 접속성을 제공하는 하나 이상의 소프트웨어 또는 하드웨어 모듈을 포함할 수 있다. 예를 들어, 주변기기들(52)은 가속도계, 생체측정(예컨대, 지문) 센서들, 전자 나침반(e-compass), 위성 트랜시버, 센서와 같은 다양한 센서들, 디지털 카메라(사진 또는 비디오용), USB(universal serial bus) 포트 또는 다른 상호접속 인터페이스들, 진동 디바이스, 텔레비전 트랜시버, 핸즈프리 헤드셋, Bluetooth® 모듈, FM(frequency modulated) 무선 유닛, 디지털 음악 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저 등을 포함할 수 있다.

전송/수신 요소들(36)은, 센서, 소비자 전자제품, 스마트 워치 또는 스마트 의류와 같은 웨어러블 디바이스, 의료 또는 e헬스(eHealth) 디바이스, 로봇, 산업 장비, 드론, 자동차, 트럭, 기차 또는 비행기와 같은 운송수단 등의 다른 장치들 또는 디바이스들에 구현될 수 있다. 전송/수신 요소들(36)은, 주변기기들(52) 중 하나를 포함할 수 있는 상호접속 인터페이스와 같은 하나 이상의 상호접속 인터페이스를 통해 이러한 장치들 또는 디바이스들의 다른 구성요소들, 모듈들 또는 시스템들에 접속될 수 있다.

도 17d는 예를 들어 도 17a 및 도 17b의 M2M 서비스 플랫폼(22)이 구현될 수 있는 예시적인 컴퓨팅 시스템(90)의 블록도이다. 컴퓨팅 시스템(90)(예로서, M2M 단말 디바이스(18) 또는 M2M 게이트웨이 디바이스(14))은 컴퓨터 또는 서버를 포함할 수 있고 무슨 수단에 의하든 이러한 명령어들이 저장되거나 액세스되는 컴퓨터 판독가능한 명령어들에 의해 주로 제어될 수 있다. 이러한 컴퓨터 판독가능한 명령어들은 컴퓨팅 시스템(90)으로 하여금 작업을 수행하게 하도록 중앙 처리 유닛(CPU)(91) 내에서 실행될 수 있다. 많은 알려진 워크스테이션들, 서버들, 및 개인용 컴퓨터들에서, 중앙 처리 유닛(91)은 마이크로프로세서라고 지칭되는 단일-칩 CPU에 의해 구현된다. 다른 머신들에서, 중앙 처리 유닛(91)은 복수의 프로세서들을 포함할 수 있다. 코프로세서(81)는 추가적인 기능들을 수행하거나 CPU(91)를 보조하는, 주요 CPU(91)와는 별개인, 임의적인 프로세서이다. CPU(91) 또는 코프로세서(81)는 EASP 리소스 요청 메시지를 수신하는 것과 같이, 이벤트 및 동작 시퀀싱과 연관된 개시된 시스템들 및 방법들에 관한 데이터를 수신, 생성 및 처리할 수 있다.

동작에 있어서, CPU(91)는 명령어들을 패치, 디코딩, 및 실행하고, 컴퓨터의 주요 데이터 전송 경로, 시스템 버스(80)를 통해 다른 리소스들에 그리고 이들로부터 정보를 전송한다. 이러한 시스템 버스는 컴퓨팅 시스템(90)에서의 구성요소들을 접속하고 데이터 교환을 위한 매체를 정의한다. 시스템 버스(80)는 데이터를 전송하기 위한 데이터 라인들, 어드레스들을 전송하기 위한 어드레스 라인들, 및 인터럽트들을 전송하고 시스템 버스를 동작시키기 위한 제어 라인들을 통상적으로 포함한다. 이러한 시스템 버스(80)의 예는 PCI(Peripheral Component Interconnect) 버스이다.

시스템 버스(80)와 결합되는 메모리 디바이스들은 RAM(82) 및 ROM(93)을 포함한다. 이러한 메모리들은 정보가 저장되고 검색되게 하는 회로를 포함한다. ROM들(93)은 쉽게 수정될 수 없는 저장된 데이터를 일반적으로 포함한다. RAM(82)에 저장되는 데이터는 CPU(91) 또는 다른 하드웨어 디바이스들에 의해 판독되거나 또는 변경될 수 있다. RAM(82) 또는 ROM(93)에 대한 액세스는 메모리 제어기(92)에 의해 제어될 수 있다. 메모리 제어기(92)는 명령어들이 실행됨에 따라 가상 어드레스들을 물리적 어드레스들로 변환하는 어드레스 변환 기능을 제공할 수 있다. 메모리 제어기(92)는 시스템 내의 프로세스들을 격리하고 시스템 프로세스들을 사용자 프로세스들로부터 격리하는 메모리 보호 기능을 또한 제공할 수 있다. 따라서, 제1 모드에서 실행되는 프로그램은 그 자신의 프로세스 가상 어드레스 공간에 의해 매핑되는 메모리에만 액세스할 수 있고, 프로세스들 사이의 메모리 공유가 설정되지 않았다면 다른 프로세스의 가상 어드레스 공간 내의 메모리에 액세스할 수 없다.

또한, 컴퓨팅 시스템(90)은 CPU(91)로부터 프린터(94), 키보드(84), 마우스(95), 및 디스크 드라이브(85)와 같은 주변기기들로 명령어들을 통신하는 것을 담당하는 주변기기 제어기(83)를 포함할 수 있다.

디스플레이 제어기(96)에 의해 제어되는 디스플레이(86)는 컴퓨팅 시스템(90)에 의해 생성되는 시각적 출력을 표시하는데 이용된다. 이러한 시각적 출력은 텍스트, 그래픽들, 애니메이션 그래픽들, 및 비디오를 포함할 수 있다. 디스플레이(86)는 CRT 기반 비디오 디스플레이, LCD 기반 평면 패널 디스플레이, 가스 플라즈마 기반 평면 패널 디스플레이 또는 터치 패널로 구현될 수 있다. 디스플레이 제어기(96)는 디스플레이(86)에 전송되는 비디오 신호를 생성하는데 요구되는 전자 구성요소들을 포함한다.

또한, 컴퓨팅 시스템(90)은 컴퓨팅 시스템(90)을 도 17a 및 도 17b의 네트워크(12)와 같은 외부 통신 네트워크에 접속하는데 이용될 수 있는 네트워크 어댑터(97)를 포함할 수 있다.

본 명세서에서 설명된 시스템들, 방법들 및 프로세스들 중 임의의 것 또는 모두가 컴퓨터 판독가능한 저장 매체 상에 저장된 컴퓨터 실행가능한 명령어들(예를 들어, 프로그램 코드)의 형태로 구현될 수 있고, 명령어들은 컴퓨터, 서버, M2M 단말 디바이스, M2M 게이트웨이 디바이스 등과 같은 머신에 의해 실행될 때, 본 명세서에서 설명된 시스템들, 방법들 및 프로세스들을 수행 또는 구현한다는 것을 이해해야 한다. 구체적으로, 위에 설명된 단계들, 동작들 또는 기능들 중 임의의 것이 이러한 컴퓨터 실행가능한 명령어들의 형태로 구현될 수 있다. 컴퓨터 판독가능한 저장 매체는 정보의 저장을 위한 임의의 방법 또는 기술에서 구현되는 휘발성 및 비휘발성, 이동식 및 비이동식 매체 모두를 포함하지만, 이러한 컴퓨터 판독가능한 저장 매체는 신호들 자체를 포함하지 않는다. 본 명세서의 설명으로부터 명백한 바와 같이, 저장 매체는 법정 발명 대상인 것으로 해석되어야 한다. 컴퓨터 판독가능한 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, DVD(digital versatile disks) 또는 다른 광학 디스크 저장소, 자기 카세트들, 자기 테이프, 자기 디스크 저장소 또는 다른 자기 저장 디바이스들, 또는 원하는 정보를 저장하는데 이용될 수 있고 컴퓨터에 의해 액세스될 수 있는 임의의 다른 물리적 매체를 포함한다. 컴퓨터 판독가능한 저장 매체는 컴퓨터 프로그램을 저장할 수 있고, 컴퓨터 프로그램은 데이터 처리 유닛에 로딩가능하고, 컴퓨터 프로그램이 데이터 처리 유닛에 의해 실행될 때 데이터 처리 유닛이 방법의 단계들을 실행하게 하도록 적응될 수 있다.

본 개시내용의 주제의 바람직한 방법들, 시스템들 또는 장치들, 즉 이벤트 및 동작 시퀀싱과 연관된 방법들 및 시스템들을 설명함에 있어서, 도면들에 도시된 바와 같이, 특정한 용어가 명료성을 위해 사용된다. 그러나, 청구되는 주제는 그와 같이 선택되는 특정한 용어로 제한되는 것으로 의도되는 것이 아니며, 각각의 특정한 요소가 유사한 목적을 달성하기 위해 유사한 방식으로 동작하는 모든 기술적 등가물들을 포함하는 것으로 이해되어야 한다.

본 명세서에서 설명되는 다양한 기술들은 하드웨어, 펌웨어, 소프트웨어, 또는 적절한 경우, 이들의 조합들과 관련하여 구현될 수 있다. 이러한 하드웨어, 펌웨어, 및 소프트웨어는 통신 네트워크의 다양한 노드들에 위치되는 장치들에 존재할 수 있다. 이러한 장치들은 본 명세서에서 설명된 방법들을 수행하기 위해 단독으로 또는 서로 조합하여 동작할 수 있다. 본 명세서에서 사용되는 용어들 "장치", "네트워크 장치", "노드", "디바이스", "네트워크 노드" 등은 상호교환적으로 사용될 수 있다. 추가로, "또는"이라는 단어의 사용은 본 명세서에서 달리 제공되지 않는 한 일반적으로 포함적인 것으로 사용된다.

본 작성된 설명은 최상의 모드를 포함하는 본 발명을 개시하고, 또한 관련 기술분야의 임의의 통상의 기술자가 임의의 디바이스들 또는 시스템들을 제조하고 이용하고 임의의 통합된 방법들을 수행하는 것을 포함하여 본 발명을 실시할 수 있도록 하기 위해 예들을 이용한다. 본 발명의 특허가능한 범위는 청구항들에 의해 정의되며, 관련 기술분야의 통상의 기술자에게 떠오르는 다른 예들(예를 들어, 본 명세서에 개시된 예시적인 방법들 사이에서의 단계들의 스킵, 도 5 및 도 6과 같은 단계들의 결합 또는 단계들의 추가)을 포함할 수 있다. 이러한 다른 예들은, 이들이 청구항들의 문자 그대로의 표현과 상이하지 않은 구조적 요소들을 가지거나, 또는 이들이 청구항들의 문자 그대로의 표현과 실질적인 차이가 없는 등가의 구조적 요소들을 포함하면, 청구항들의 범위 내에 있는 것으로 의도된다.

본 명세서에는 EASP의 기능이 실현되는 시스템이 개시된다. IoT 디바이스들은 (도 3, 도 5, 도 9, 도 10, 도 11에 도시된 바와 같이) EASP, EventState, 및 전이 리소스들의 이용에 기반하여 EASP를 생성할 수 있다. 개시된 방법들 및 시스템들은 (도 8, 도 14에 도시된 바와 같이) 동작 중인 동안 EASP의 동작들의 업데이트를 허용한다. 표 1 내지 표 3 등과 같은 정보는 EASP를 생성하는데 이용될 수 있는 애플리케이션 프로그래밍 인터페이스로 고려될 수 있다.

복잡한 애플리케이션의 구성요소들을 정의하는 구성가능한 이벤트 및 동작 시퀀싱 IoT 시스템의 리소스들을 생성하라는 요청을 처리한다. 생성된 리소스들은 그 연관 파라미터들을 갖는 EASP, EventState 및 전이 리소스들이다.

구성가능한 이벤트 및 동작 시퀀싱 IoT 시스템이 실행될 수 있게 하고, 시스템은 EASP의 동작들을 관리할 것이다. 이것은 병렬로 실행될 수 있는 다른 EASP에 링크하는 것, EASP의 동작들에 영향을 주지 않고 시스템이 실행 중일 때 EASP 내의 리소스들을 업데이트하는 것, 및 EASP의 동작들의 상태를 요청자에게 제공하는 것을 포함한다. 또한, 개시된 시스템은 EASP 리소스에서 파라미터들(전제 조건들 및/또는 나가기 조건들)을 이용하여 복수의 EASP들을 함께 링크하는 능력을 갖는다. 이를 행하는 능력은 더 작은 구성요소들을 함께 링크함으로써 복잡한 IoT 애플리케이션들의 생성을 가능하게 한다.

EASP는 애플리케이션에 대한 동작들을 수행하도록 프로그래밍되며, 여기서 애플리케이션은 복수의 단계들(예를 들어, 모듈들)을 필요로 한다. 도 1에 도시된 와인 제조 애플리케이션은 와인을 제조하는 프로세스를 시작하기 위해 포도 꼭지를 따는 것으로 시작하는 많은 단계들을 포함한다. 이것이 EASP가 수행하도록 프로그래밍되는 것이다. 예를 들어, EASP는 한 번에 하나의 단계를 프로세스를 통해 시퀀싱하고 연관된 EASP 리소스들(예를 들어, 표 1, 표 2, 또는 표 3)을 갖는다. 다른 단계로의 전이는 검출된 이벤트에 의해 야기될 수 있다.

특히, 본 명세서에 설명된 바와 같은 방법들, 시스템들, 및 장치들은, 요청자로부터, 이벤트 및 동작 시퀀싱 프로세스 리소스(EASP 리소스)를 생성하라는 요청을 획득하는 것, 및 그 요청에 응답하여, EASP 리소스를 생성하는 것을 포함할 수 있는 사물 인터넷 시스템에서 구성가능한 이벤트 및 동작 시퀀싱을 위한 수단을 제공할 수 있고, 여기서 EASP 리소스는 다음과 같은 정보, 즉 EASP ID, 설명, EASP의 현재 상태, 제어 동작들, 전제 조건들, 나가기 조건들, EASP 내의 이벤트들의 수, EASP가 시작할 때의 초기 이벤트 상태, 또는 EASP의 최종 이벤트를 포함할 수 있다. EASP ID, 설명, EASP의 현재 상태, 제어 동작들, 전제 조건들, 나가기 조건들, EASP 내의 이벤트들의 수, EASP가 시작할 때의 초기 이벤트 상태, 또는 EASP의 최종 이벤트는 특정 파라미터에 대응한다. 방법, 시스템, 컴퓨터 판독가능한 저장 매체, 또는 장치는 필요에 따라 요청자에게 상태 정보의 전송을 가능하게 하기 위한 통신들을 유지하는 수단을 갖는다. 방법, 시스템, 컴퓨터 판독가능한 저장 매체 또는 장치는 현재의 EASP의 동작을 전제 조건들 또는 나가기 조건 파라미터들을 이용하여 다른 기존의 EASP들과 링크하기 위한 수단을 갖는다. 방법, 시스템, 컴퓨터 판독가능한 저장 매체, 또는 장치는 요청자로부터 EventState 리소스(예를 들어, 이벤트의 상태와 연관된 리소스)를 생성하라는 요청을 획득하기 위한 수단, 및 그 요청에 응답하여, EventState 리소스를 생성하기 위한 수단을 가지며, EventState 리소스는 다음과 같은 정보, 즉 현재 이벤트 상태에 이용되는 식별자, EventState의 설명, 이벤트 상태의 현재 상태, 이벤트 상태의 지속기간에 대한 설정 시간, 이벤트 상태의 조기 또는 비동기적 나가기를 허용하기 위해 현재 이벤트 상태를 종료하는 이벤트들, 이벤트 상태 전이 및 전이할 다음 EventState ID를 트리거링하는 이벤트들, 전이 이벤트 파라미터가 다른 이벤트 상태로 전이하도록 트리거링될 수 있는 때에 수행되는 동작들의 리스트, 또는 다음 EventState의 식별자를 포함할 수 있다. 현재 이벤트 상태에 이용되는 식별자, EventState의 설명, 이벤트 상태의 현재 상태, 이벤트 상태의 지속기간에 대한 설정 시간, 이벤트 상태의 비동기적 나가기를 허용하기 위해 현재 이벤트 상태를 종료하는 이벤트들, 이벤트 상태 전이 및 전이할 다음 EventState ID를 트리거링하는 이벤트들, 전이 이벤트 파라미터가 다른 이벤트 상태로 전이하도록 트리거링될 수 있는 때에 수행되는 동작들의 리스트, 또는 다음 EventState의 식별자는 특정 파라미터에 대응한다. 방법, 시스템, 컴퓨터 판독가능한 저장 매체, 또는 장치는 필요에 따라 요청자에게 상태 정보의 전송을 가능하게 하기 위한 통신들을 유지하는 수단을 갖는다. 방법, 시스템, 컴퓨터 판독가능한 저장 매체, 또는 장치는 EASP가 능동인 동안 EASP의 동작들에 영향을 주지 않고 EASP에 새로운 동적으로 추가된 EventState 리소스들, 또는 기존의 EventState 리소스들에 대한 변경들이 통합될 수 있는지를 결정하기 위한 수단을 갖는다. (단계들의 제거 또는 추가를 포함한) 이 단락 및 이하의 단락들에서의 모든 조합들이 상세한 설명의 다른 부분들과 일관되는 방식으로 고려된다.

방법, 시스템, 컴퓨터 판독가능한 저장 매체, 또는 장치는, 요청자로부터, 전이 리소스를 생성하라는 요청을 획득하기 위한 수단, 및 그 요청에 응답하여, 전이 리소스를 생성하기 위한 수단을 가지며, 전이 리소스는 다음과 같은 정보, 즉 이벤트 상태 전이를 야기하는 이벤트, 이벤트의 발생의 결과로서 실행될 수 있는 동작, 또는 전이할 다음 이벤트 상태를 포함할 수 있다. 이벤트 상태 전이를 야기하는 이벤트, 이벤트의 발생의 결과로서 실행될 수 있는 동작, 또는 전이할 다음 이벤트 상태는 특정 파라미터에 대응한다. 방법, 시스템, 컴퓨터 판독가능한 저장 매체, 또는 장치는 필요에 따라 요청자에게 상태 정보의 전송을 가능하게 하기 위한 통신들을 유지하는 수단을 갖는다. 방법, 시스템, 컴퓨터 판독가능한 저장 매체, 또는 장치는 EASP가 능동적으로 실행되는 동안 EASP의 동작들에 영향을 주지 않고 EASP에 새로운 동적으로 추가된 전이 리소스들, 또는 기존의 전이 리소스들에 대한 변경들이 통합될 수 있는지를 결정하기 위한 수단을 갖는다. 방법, 시스템, 컴퓨터 판독가능한 저장 매체 또는 장치는 요청자로부터, 이벤트 및 동작 시퀀싱 프로세스 리소스(EASP 리소스)를 생성하라는 요청을 획득하기 위한 수단, 및 그 요청에 응답하여, EASP 리소스를 생성하기 위한 수단을 가지며, 여기서 EASP 리소스는 적용가능한 동작들에 이벤트들을 링크함으로써 애플리케이션의 더 작은 구성요소들에의 복잡한 사물 인터넷 애플리케이션을 정의하고, EASP 리소스는 다음과 같은 정보, 즉 EASP ID, 설명, EASP의 현재 상태, 제어 동작들, 전제 조건들, 나가기 조건들, EASP 내의 이벤트들의 수, EASP가 시작할 때의 초기 이벤트 상태, 또는 EASP의 최종 이벤트를 포함할 수 있다. (단계들의 제거 또는 추가를 포함한) 이 단락 및 이하의 단락들에서의 모든 조합들이 상세한 설명의 다른 부분들과 일관되는 방식으로 고려된다.

방법, 시스템, 컴퓨터 판독가능한 저장 매체, 또는 장치는 애플리케이션에 대한 복수의 이벤트 상태 리소스들 중 제1 이벤트 상태 리소스를 생성하라는 요청을 획득하기 위한 수단 - 이벤트는 수행될 동작을 트리거링하는 사물 인터넷 시스템에서의 조건임 -, 그 요청에 응답하여, 이벤트 상태 리소스를 생성하기 위한 수단 - 이벤트 상태 리소스는 이벤트의 상태의 현재 상태, 및 상태의 지속기간에 대한 시간의 양을 포함하는 리소스임 - 을 갖는다. 방법, 시스템, 컴퓨터 판독가능한 저장 매체, 또는 장치는 애플리케이션에 대한 제2 이벤트 상태 리소스를 추가하라는 요청을 수신하기 위한 수단, 제2 이벤트 상태 리소스를 추가하라는 요청에 기반하여, 제1 이벤트 상태 리소스를 분석하기 위한 수단, 및 제1 이벤트 상태 리소스의 분석에 기반하여, EASP가 능동적으로 실행되는 동안 EASP의 동작들에 부정적인 영향을 주지 않고 EASP에 제2 이벤트 상태 리소스가 통합될 수 있는 때를 결정하기 위한 수단을 갖는다. 방법, 시스템, 컴퓨터 판독가능한 저장 매체, 또는 장치는 애플리케이션에 대한 복수의 이벤트 상태 리소스들 중 제2 이벤트 상태 리소스를 업데이트하라는 요청을 수신하기 위한 수단, 제2 이벤트 상태 리소스를 업데이트하라는 요청에 기반하여, 제1 이벤트 상태 리소스를 분석하기 위한 수단, 및 제1 이벤트 상태 리소스의 분석에 기반하여, EASP가 능동적으로 실행되는 동안 EASP의 동작들에 부정적인 영향을 주지 않고 EASP에 제2 이벤트 상태 리소스가 업데이트될 수 있는 때를 결정하기 위한 수단을 갖는다. 제1 이벤트 상태 리소스는 제1 전이 리소스를 포함할 수 있다. (단계들의 제거 또는 추가를 포함한) 이 단락 및 이하의 단락들에서의 모든 조합들이 상세한 설명의 다른 부분들과 일관되는 방식으로 고려된다.

특히, 본 명세서에 설명된 바와 같은 방법들, 시스템들, 및 장치들, 컴퓨터 판독가능한 매체들은 애플리케이션에 대한 복수의 이벤트 상태 리소스들 중 제1 이벤트 상태 리소스를 생성하라는 요청을 획득하는 것, 및 그 요청에 기반하여, 이벤트 상태 리소스를 생성하는 것을 위한 수단을 포함할 수 있는 시스템에서의 구성가능한 이벤트 및 동작 시퀀싱을 위한 수단을 제공할 수 있고, 이벤트 상태 리소스는 애플리케이션의 이벤트의 상태와 연관된 리소스(예를 들어, 와인 제조 프로세스에서의 발효 단계와 같은, 애플리케이션의 전체 프로세스에서의 모듈 또는 단계)일 수 있고, 이벤트(예를 들어, 검출된 타이머, 온도 판독 등)는 수행될 동작을 트리거링하는 검출된 조건일 수 있고, 제1 이벤트 상태 리소스는 이벤트의 상태의 현재 상태 및 전이 파라미터(예를 들어, 표 3의 정보를 포함하는 속성 또는 리소스 등)를 포함하는 리소스일 수 있다. 방법, 시스템, 컴퓨터 판독가능한 저장 매체, 또는 장치는 애플리케이션에 대한 제2 이벤트 상태 리소스를 추가 또는 업데이트하라는 요청을 수신하기 위한 수단, 제2 이벤트 상태 리소스를 추가 또는 업데이트하라는 요청에 기반하여, 제1 이벤트 상태 리소스를 분석하기 위한 수단, 및 제1 이벤트 상태 리소스의 분석에 기반하여, EASP가 능동적으로 실행될 수 있는 동안 EASP의 동작들에 부정적인 영향을 주지 않고 (대응하는 단계 또는 모듈을 포함할 수 있는) EASP에 제2 이벤트 상태 리소스가 통합될 수 있는 때를 결정하기 위한 수단을 갖는다. 이벤트 상태 리소스는 이벤트의 현재 상태의 나가기를 허용하기 위해 이벤트의 현재 상태를 종료하는 이벤트의 표시를 포함할 수 있다. 시스템 등은 전이 리소스를 생성하라는 요청을 획득하기 위한 수단을 포함할 수 있고, 여기서 전이 리소스는 제2 이벤트 상태 리소스와 연관될 수 있다. 제1 이벤트 상태 리소스는 전이할 다음 이벤트 상태의 식별자(예를 들어, 도 15)를 포함할 수 있다.

Claims (15)

1. 사물 인터넷 시스템에 대해, 애플리케이션 프로그래밍 인터페이스들(API들)의 세트를 통해 복수의 애플리케이션에 서비스 능력들을 제공하는 서비스에서 구성가능한 이벤트 및 동작 시퀀싱 프로세스(EASP)를 위한 장치로서, 상기 서비스는 애플리케이션 프로토콜 계층 위의 미들웨어로서 지원되고, 상기 장치는,
   프로세서; 및
   상기 프로세서와 결합된 메모리를 포함하고,
   상기 메모리는 상기 프로세서에 의해 실행될 때, 상기 프로세서로 하여금 동작들을 수행하게 하는 실행가능한 명령어들을 포함하고, 상기 동작들은,
   애플리케이션에 대한 상기 서비스의 복수의 이벤트 상태 리소스들 중 제1 이벤트 상태 리소스를 생성하라는 요청을 획득하는 것 - 이벤트 상태 리소스는 상기 애플리케이션의 이벤트의 상태와 연관된 리소스이고, 상기 이벤트는 수행될 동작을 트리거링하는 검출된 조건임 -; 및
   상기 요청에 응답하여, 상기 이벤트 상태 리소스를 생성하는 것
   을 포함하며,
   상기 제1 이벤트 상태 리소스는,
   상기 이벤트 상태 리소스의 식별자,
   상기 이벤트의 상태의 현재 상태 - 상기 현재 상태는 상기 이벤트의 완료의 정도를 나타내는 파라미터들을 포함함 -,
   전이 파라미터 - 상기 전이 파라미터는 상기 검출된 조건에 기반하여 전이할 다음 이벤트 상태 리소스의 식별자를 포함함 -, 및
   동작 파라미터 - 상기 동작 파라미터는 상기 검출된 조건에 기반하여 수행될 하나 이상의 동작을 포함함 -
   를 포함하는 리소스인, 장치.
2. 제1항에 있어서,
   추가로 동작들은,
   상기 애플리케이션에 대한 제2 이벤트 상태 리소스를 추가하라는 요청을 수신하는 것;
   상기 제2 이벤트 상태 리소스를 추가하라는 상기 요청에 기반하여, 상기 제1 이벤트 상태 리소스를 분석하는 것; 및
   상기 제1 이벤트 상태 리소스의 상기 분석에 기반하여, 상기 EASP가 능동적으로 실행되는 동안 상기 EASP의 동작들에 부정적인 영향을 주지 않고 상기 EASP에 상기 제2 이벤트 상태 리소스가 통합될 수 있는 때를 결정하는 것
   을 포함하는, 장치.
3. 제1항에 있어서,
   추가로 동작들은,
   상기 애플리케이션에 대한 상기 복수의 이벤트 상태 리소스들 중 제2 이벤트 상태 리소스를 업데이트하라는 요청을 수신하는 것;
   상기 제2 이벤트 상태 리소스를 업데이트하라는 상기 요청에 기반하여, 상기 제1 이벤트 상태 리소스를 분석하는 것; 및
   상기 제1 이벤트 상태 리소스의 상기 분석에 기반하여, 상기 EASP가 능동적으로 실행되는 동안 상기 EASP의 동작들에 부정적인 영향을 주지 않고 상기 EASP에 상기 제2 이벤트 상태 리소스가 업데이트될 수 있는 때를 결정하는 것
   을 포함하는, 장치.
4. 제1항에 있어서,
   상기 이벤트 상태 리소스는 상기 이벤트의 현재 상태의 나가기를 허용하기 위해 상기 이벤트의 현재 상태를 종료하는 이벤트의 표시를 포함하는, 장치.
5. 삭제
6. 제1항에 있어서,
   추가로 동작들은 전이 리소스를 생성하라는 요청을 획득하는 것을 포함하고, 상기 전이 리소스는 제2 이벤트 상태 리소스와 연관되는, 장치.
7. 삭제
8. 사물 인터넷 시스템에 대해, 애플리케이션 프로그래밍 인터페이스들(API들)의 세트를 통해 복수의 애플리케이션에 서비스 능력들을 제공하는 서비스에서 구성가능한 이벤트 및 동작 시퀀싱 프로세스(EASP)를 위한 방법으로서, 상기 서비스는 애플리케이션 프로토콜 계층 위의 미들웨어로서 지원되고, 상기 방법은,
   애플리케이션에 대한 상기 서비스의 복수의 이벤트 상태 리소스들 중 제1 이벤트 상태 리소스를 생성하라는 요청을 획득하는 단계 - 이벤트 상태 리소스는 상기 애플리케이션의 이벤트의 상태와 연관된 리소스이고, 상기 이벤트는 수행될 동작을 트리거링하는 검출된 조건임 -; 및
   상기 요청에 응답하여, 상기 이벤트 상태 리소스를 생성하는 단계
   를 포함하며,
   상기 제1 이벤트 상태 리소스는,
   상기 이벤트 상태 리소스의 식별자,
   상기 이벤트의 상태의 현재 상태 - 상기 현재 상태는 상기 이벤트의 완료의 정도를 나타내는 파라미터들을 포함함 -,
   전이 파라미터 - 상기 전이 파라미터는 상기 검출된 조건에 기반하여 전이할 다음 이벤트 상태 리소스의 식별자를 포함함 -, 및
   동작 파라미터 - 상기 동작 파라미터는 상기 검출된 조건에 기반하여 수행될 하나 이상의 동작을 포함함 -
   를 포함하는 리소스인, 방법.
9. 제8항에 있어서,
   상기 애플리케이션에 대한 제2 이벤트 상태 리소스를 추가하라는 요청을 수신하는 단계;
   상기 제2 이벤트 상태 리소스를 추가하라는 상기 요청에 기반하여, 상기 제1 이벤트 상태 리소스를 분석하는 단계; 및
   상기 제1 이벤트 상태 리소스의 상기 분석에 기반하여, 상기 EASP가 능동적으로 실행되는 동안 상기 EASP의 동작들에 부정적인 영향을 주지 않고 상기 EASP에 상기 제2 이벤트 상태 리소스가 통합될 수 있는 때를 결정하는 단계
   를 더 포함하는, 방법.
10. 제8항에 있어서,
    상기 애플리케이션에 대한 상기 복수의 이벤트 상태 리소스들 중 제2 이벤트 상태 리소스를 업데이트하라는 요청을 수신하는 단계;
    상기 제2 이벤트 상태 리소스를 업데이트하라는 상기 요청에 기반하여, 상기 제1 이벤트 상태 리소스를 분석하는 단계; 및
    상기 제1 이벤트 상태 리소스의 상기 분석에 기반하여, 상기 EASP가 능동적으로 실행되는 동안 상기 EASP의 동작들에 부정적인 영향을 주지 않고 상기 EASP에 상기 제2 이벤트 상태 리소스가 업데이트될 수 있는 때를 결정하는 단계
    를 더 포함하는, 방법.
11. 제8항에 있어서,
    상기 이벤트 상태 리소스는 상기 이벤트의 현재 상태의 나가기를 허용하기 위해 상기 이벤트의 현재 상태를 종료하는 이벤트의 표시를 포함하는, 방법.
12. 삭제
13. 제8항에 있어서,
    전이 리소스를 생성하라는 요청을 획득하는 단계를 더 포함하고, 상기 전이 리소스는 제2 이벤트 상태 리소스와 연관되는, 방법.
14. 삭제
15. 컴퓨터 프로그램을 저장하는 컴퓨터 판독가능한 저장 매체로서,
    상기 컴퓨터 프로그램은 데이터 처리 유닛에 로딩가능하고, 상기 컴퓨터 프로그램이 상기 데이터 처리 유닛에 의해 실행될 때 상기 데이터 처리 유닛으로 하여금 제8항 내지 제11항, 및 제13항 중 어느 한 항에 따른 방법의 단계들을 실행하게 하도록 적응되는, 컴퓨터 판독가능한 저장 매체.

Images