IoT 장치 AWS IoT Events 모니터링에 사용 - AWS IoT Events

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

IoT 장치 AWS IoT Events 모니터링에 사용

를 AWS IoT Events 사용하여 장치 또는 프로세스를 모니터링하고 중요한 이벤트를 기반으로 조치를 취할 수 있습니다. 이렇게 하려면 다음 기본 단계를 따르십시오.

입력 생성

디바이스와 프로세스가 원격 측정 데이터를 AWS IoT Events로 보낼 방법이 있어야 합니다. 이를 통해 메시지를 AWS IoT Events에 입력으로 전송합니다. 다음과 같은 여러 방법으로 메시지를 입력으로 보낼 수 있습니다.

  • BatchPutMessage오퍼레이션을 사용하세요.

  • iotEvents rule-actionAWS IoT Core 규칙 엔진으로 정의합니다. rule-action은 입력의 메시지 데이터를 AWS IoT Events로 전달합니다.

  • AWS IoT Analytics에서는 CreateDataset작업을 사용하여 데이터 세트를 생성합니다contentDeliveryRules. 이 규칙은 데이터 세트 내용이 자동으로 전송되는 AWS IoT Events 입력을 지정합니다.

  • AWS IoT Events 검출기 모델 onExit 또는 transitionEvents 이벤트의 iotEvents동작을 정의합니다. onInput 작업을 시작한 이벤트와 감지기 모델 인스턴스에 대한 정보가 지정된 이름을 사용하여 시스템에 입력으로 피드백됩니다.

디바이스가 이러한 방식으로 데이터를 전송하기 전에 하나 이상의 입력을 정의해야 합니다. 이렇게 하려면 각 입력에 이름을 지정하고 입력이 모니터링하는 수신 메시지 데이터의 필드를 지정하십시오. AWS IoT Events 여러 소스에서 JSON 페이로드 형태로 입력을 수신합니다. 각 입력을 자체적으로 처리하거나 다른 입력과 결합하여 더 복잡한 이벤트를 감지할 수 있습니다.

감지기 모델 생성

상태를 사용하여 감지기 모델(디바이스 또는 프로세스의 모델)을 정의합니다. 각 상태에 대해 수신되는 입력을 평가하여 중요 이벤트를 탐지하는 조건부(부울) 논리를 정의합니다. 이벤트가 감지되면 다른 서비스를 사용하여 상태를 변경하거나 사용자 지정 또는 사전 정의된 작업을 시작할 수 있습니다. AWS 특정 상태가 시작 또는 종료할 때 또한 선택적으로 특정 조건이 충족될 때 작업을 시작하는 추가 이벤트를 정의할 수 있습니다.

이 자습서에서는 모델이 특정 상태에 진입하거나 종료할 때 Amazon SNS 메시지를 액션으로 전송합니다.

디바이스 또는 프로세스 모니터링

여러 디바이스 또는 프로세스를 모니터링하는 경우 각 입력에 특정 디바이스를 식별하거나 입력의 출처를 처리하는 필드를 지정합니다. (keyCreateDetectorModel 필드 참조.) 새 장치가 식별되면(key로 식별되는 입력 필드에 새 값이 표시됨) 감지기가 생성됩니다. (각 감지기는 감지기 모델의 인스턴스입니다.) 그러면 새 감지기는 해당 감지기 모델이 업데이트되거나 삭제될 때까지 해당 디바이스에서 오는 입력에 계속 응답합니다.

단일 프로세스를 모니터링하는 경우 여러 디바이스 또는 하위 프로세스가 입력을 보낸다 하더라도 고유한 식별 key 필드를 지정하지 마십시오. 이 경우 첫 번째 입력이 도착하면 단일 감지기(인스턴스)가 생성됩니다.

메시지를 감지기 모델에 입력으로 전송

디바이스에서 메시지를 보내거나 AWS IoT Events 감지기의 입력으로 처리하는 몇 가지 방법이 있습니다. 이 경우 메시지에 대해 추가 형식 지정을 수행하지 않아도 됩니다. 이 자습서에서는 AWS IoT 콘솔을 사용하여 메시지 데이터를 AWS IoT Events전달하는 AWS IoT Core 규칙 엔진용 AWS IoT Events 조치 규칙을 작성합니다. 이렇게 하려면 입력을 이름으로 식별해야 합니다. 그런 다음 AWS IoT 콘솔을 사용하여 입력으로 전달되는 일부 메시지를 계속 생성합니다. AWS IoT Events

감지기 모델에 어떤 상태가 필요한지 어떻게 알 수 있나요?

감지기 모델의 상태를 결정하려면 취할 수 있는 조치를 먼저 결정하십시오. 예를 들어, 자동차가 휘발유를 사용하는 경우 여행을 시작할 때 연료 게이지를 보고 연료 충전이 필요한지 확인합니다. 여기서 한 가지 조치를 취할 수 있습니다. 운전자에게 “연료를 충전하십시오”라고 말하는 것입니다. 감지기 모델에는 “자동차에 연료가 필요하지 않음”과 “자동차에 연료가 필요함”이라는 두 가지 상태가 필요합니다. 일반적으로 가능한 각 동작에 대해 하나의 상태를 정의하고, 조치가 필요하지 않은 경우를 위한 상태를 하나 더 정의하려고 합니다. 이 방법은 작업 자체가 더 복잡한 경우에도 적용됩니다. 예를 들어 가장 가까운 주유소 또는 가장 저렴한 주유소의 위치 정보를 찾아보고 포함할 수 있지만, 이는 “연료를 충전하십시오”라는 메시지를 보낼 때 이렇게 합니다.

다음으로 전환할 상태를 결정하려면 입력 내용을 살펴보십시오. 입력에는 어떤 상태로 전환되어야 하는지 결정하는 데 필요한 정보가 들어 있습니다. 입력을 만들려면 디바이스나 프로세스에서 보낸 메시지에서 결정을 내리는 데 도움이 되는 필드를 하나 이상 선택합니다. 이 예시에서는 현재 연료 수준(“연료 비율”)을 알려주는 입력이 하나 필요합니다. 자동차가 여러 개의 서로 다른 필드를 포함하는 서로 다른 메시지를 여러 개 보내고 있을 수 있습니다. 이 입력을 생성하려면 메시지와 현재 연료 게이지 수준을 보고하는 필드를 선택해야 합니다. 이동하려는 거리(“목적지까지의 거리”)를 하드코딩하여 단순하게 만들 수 있습니다. 즉, 평균 이동 거리를 사용할 수 있습니다. 입력값을 바탕으로 계산을 할 수 있습니다(연료 비율이 몇 갤런으로 환산되나요? 보유한 갤런과 평균 “갤런당 마일”을 감안하면 평균 이동 거리가 주행 가능 거리보다 길까요?). 이러한 계산을 수행하고 이벤트에서 메시지를 전송합니다.

지금까지는 두 개의 상태와 한 개의 입력이 있습니다. 첫 번째 상태에는 입력을 기반으로 계산을 수행하고 두 번째 상태로 이동 여부를 결정하는 이벤트가 필요합니다. 이는 전환 이벤트입니다. (transitionEvents가 상태의 onInput 이벤트 목록에 있습니다. 첫 번째 상태에서 입력을 받은 후, 이벤트의 condition이 충족되면 이벤트가 두 번째 상태로 전환됩니다.) 두 번째 상태에 도달하면 해당 상태로 전환되는 즉시 메시지가 전송됩니다. (onEnter 이벤트를 사용합니다. 두 번째 상태로 전환되면 이 이벤트가 메시지를 보냅니다. 다른 입력이 도착할 때까지 기다릴 필요가 없습니다.) 다른 유형의 이벤트도 있지만 여기까지가 간단한 예시입니다.

다른 유형의 이벤트는 onExitonInput입니다. 입력이 수신되고 조건이 충족되는 즉시 onInput 이벤트는 지정된 작업을 수행합니다. 작업이 현재 상태를 종료하고 조건이 충족되면 onExit 이벤트는 지정된 작업을 수행합니다.

놓친 것이 있나요? 네, 어떻게 하면 첫 번째 상태 “자동차에 연료가 필요하지 않음”으로 돌아갈 수 있을까요? 연료 탱크를 가득 채우면 입력란에 탱크가 가득 찼다고 표시됩니다. 두 번째 상태에서는 (두 번째 상태의 onInput: 이벤트에서) 입력이 수신될 때 발생하는 첫 번째 상태로의 전환 이벤트가 필요합니다. 원하는 곳으로 갈 수 있을 만큼 연료가 충분하다는 계산이 나오면 다시 첫 번째 상태로 전환해야 합니다.

이것이 기본입니다. 일부 감지기 모델은 가능한 동작뿐만 아니라 중요한 입력을 반영하는 상태를 추가하여 더 복잡해집니다. 예를 들어 온도를 추적하는 감지기 모델에는 “정상”, “고온”, “잠재적 문제”의 세 가지 상태가 있을 수 있습니다. 온도가 특정 수준 이상으로 올라갔지만 아직 너무 뜨거워지지 않은 경우 잠재적 문제 상태로 전환됩니다. 이 온도로 15분 이상 유지되지 않으면 경보를 보내고 싶지 않을 것입니다. 그 전에 온도가 정상으로 돌아오면 감지기는 정상 상태로 다시 전환됩니다. 타이머가 만료되면 감지기가 너무 뜨거워진 상태로 전환되어 경보를 보내므로 주의해야 합니다. 변수와 더 복잡한 이벤트 조건 세트를 사용하여 동일한 작업을 수행할 수 있습니다. 하지만 실제로는 다른 상태를 사용하여 계산 결과를 저장하는 것이 더 쉬운 경우가 많습니다.

감지기 인스턴스가 하나 필요한지 아니면 여러 개가 필요한지 어떻게 알 수 있습니까?

필요한 인스턴스 수를 결정하려면 “무엇을 알고 싶은가요?”라고 스스로 질문하십시오. 오늘 날씨가 어떤지 알고 싶다고 가정해 봅시다. 비가 오나요(상태)? 우산을 써야 하나요(작업)? 온도를 알려주는 센서, 습도를 알려주는 센서, 기압, 풍속, 강수를 알려주는 센서를 사용할 수 있습니다. 하지만 이러한 모든 센서를 함께 모니터링하여 날씨 상태(비, 눈, 흐린 날씨, 맑음)와 적절한 작업(우산 챙기기 또는 자외선 차단제 바르기)을 파악해야 합니다. 센서 수가 많더라도 하나의 감지기 인스턴스가 날씨 상태를 모니터링하고 취해야 할 작업을 알려주는 것이 좋습니다.

하지만 해당 리전의 일기 예보관이라면 리전 곳곳의 다양한 위치에 이러한 센서 그룹이 여러 개 있을 수 있습니다. 각 지역의 사람들은 해당 지역의 날씨가 어떤지 알아야 합니다. 이 경우 여러 개의 감지기 인스턴스가 필요합니다. 각 위치의 각 센서가 보고하는 데이터에는 key 필드로 지정한 필드가 포함되어야 합니다. 이 필드를 사용하면 AWS IoT Events 가 해당 영역에 대한 감지기 인스턴스를 만든 다음, 해당 감지기 인스턴스가 도착할 때마다 이 정보를 해당 감지기 인스턴스로 계속 라우팅할 수 있습니다. 날씨 때문에 머리 스타일을 망치거나 얼굴이 타는 일은 더 이상 없습니다!

기본적으로 모니터링해야 할 한 개의 상황(프로세스 또는 위치 한 개)이 있다면 한 개의 감지기 인스턴스가 필요합니다. 모니터링해야 할 상황(위치, 프로세스)이 많은 경우 여러 개의 감지기 인스턴스가 필요합니다.