AWS IoT Events を使用して IoT デバイスをモニタリングする

AWS IoT Events を使用してデバイスまたはプロセスをモニタリングし、重要なイベントに基づいてアクションを実行できます。これを行うには、次のベーシックなステップに従います。

入力を作成する

デバイスとプロセスがテレメトリデータを AWS IoT Eventsに取り込む方法が必要です。これを行うには、 AWS IoT Eventsへの入力としてメッセージを送信します。いくつかの方法で入力としてメッセージを送信できます。

• BatchPutMessage オペレーションを使用します。

• AWS IoT Core ルールエンジンの iotEvents ルールアクションを定義します。ルールアクションは、入力から AWS IoT Eventsにメッセージデータを転送します。

• で AWS IoT Analytics、 CreateDatasetオペレーションを使用して でデータセットを作成しますcontentDeliveryRules。これらのルールは、データセットの内容が自動的に送信される AWS IoT Events 入力を指定します。

• AWS IoT Events ディテクターモデルの onInput、、onExitまたは transitionEventsイベントでiotEventsアクションを定義します。ディテクターモデルインスタンスとアクションを開始したイベントに関する情報は、指定した名前の入力としてシステムにフィードバックされます。

デバイスがこの方法でデータの送信をスタートする前に、1 つ以上の入力を定義する必要があります。これを行うには、各入力に名前を付け、入力がモニタリングする受信メッセージデータ内のフィールドを指定します。 は、入力をJSONペイロード形式で多くのソースから AWS IoT Events 受け取ります。各入力は、単独で操作することも、他の入力と組み合わせて、より複雑なイベントを検出することもできます。

ディテクターモデルを作成する

状態を使用して、ディテクターモデル (機器またはプロセスのモデル) を定義します。状態ごとに、重要なイベントを検出するために着信入力を評価する条件付き　(ブール) ロジックを定義します。イベントが検出されると、 状態を変更したり、他の AWS サービスを使用してカスタムビルドまたは事前定義されたアクションを開始したりできます。状態に入るときまたは状態を出るとき、およびオプションで条件が満たされたときにアクションを開始する追加のイベントを定義できます。

このチュートリアルでは、モデルが特定の状態に出入りするときに、アクションとして Amazon SNS メッセージを送信します。

デバイスまたはプロセスをモニタリングする

複数のデバイスまたはプロセスをモニタリングしている場合は、入力元の特定のデバイスまたはプロセスを識別するフィールドを各入力に指定します。(CreateDetectorModel の key フィールドを参照してください。) 新しいデバイスが識別されると (key によって識別される入力フィールドに新しい値が表示されます)、ディテクターが作成されます。(各ディテクターは、ディテクターモデルのインスタンスです。) 次に、新しいディテクターは、ディテクターモデルが更新または削除されるまで、そのデバイスからの入力に応答し続けます。

単一のプロセスをモニタリングしている場合 (複数のデバイスまたはサブプロセスが入力を送信している場合でも)、一意の識別 key フィールドを指定しません。この場合、最初の入力が到着したときに単一のディテクター (インスタンス) が作成されます。

ディテクターモデルへの入力としてメッセージを送信します

デバイスまたはプロセスからディ AWS IoT Events テクターへの入力としてメッセージを送信するには、メッセージに追加のフォーマットを実行する必要がない方法がいくつかあります。このチュートリアルでは、 AWS IoT コンソールを使用して、メッセージデータを に転送するルールエンジンのAWS IoT Events アクション AWS IoT Core ルールを記述します AWS IoT Events。これを行うには、入力を名前で識別します。その後、 AWS IoT コンソールを使用して、 への入力として転送されるメッセージを生成します AWS IoT Events。

ディテクターモデルに必要な状態をどのようにして知ることができますか？

ディテクターモデルが持つべき状態を決定するには、最初に実行できるアクションを決定します。例えば、自動車がガソリンで走行している場合、旅行をスタートするときに燃料計を見て、燃料を補給する必要があるかどうかを確認します。ここに 1 つのアクションがあります:「ガスを取りに行く」ようにドライバーに伝えます。ディテクターモデルには、「車は燃料を必要としない」と「車は燃料を必要とする」の 2 つの状態が必要です。一般に、可能なアクションごとに 1 つの状態を定義し、さらにアクションが不要な場合にもう 1 つの状態を定義する必要があります。これは、アクション自体がより複雑な場合でも機能します。例えば、最寄りのガソリンステーションの場所や最も安い料金に関する情報を調べて含めることができますが、これは「ガソリンを取りに行く」というメッセージを送信するときに行います。

次に入る状態を決定するには、入力を確認します。入力には、どの状態にするかを決定するために必要な情報が含まれています。入力を作成するには、デバイスまたはプロセスによって送信されるメッセージ内の 1 つ以上のフィールドを選択して、決定に役立てます。この例では、現在の燃料レベル (「フルパーセント」) を示す 1 つの入力が必要です。おそらくお客様の車はいくつかの異なるメッセージを送っていて、それぞれがいくつかの異なるフィールドを持っています。この入力を作成するには、現在のガスゲージレベルを報告するメッセージとフィールドを選択する必要があります。移動しようとしている旅行の長さ (「目的地までの距離」) は、物事を単純にするためにハードコーディングすることができます。平均的な旅行の長さを使うことができます。入力に基づいていくつかの計算を行います (そのパーセントが完全に変換されるのは何ガロンですか？これは、ガロンと平均「ガロンあたりのマイル」を考慮して、移動できるマイルよりも長い平均旅行距離です)。これらの計算を実行し、イベントでメッセージを送信します。

これまでのところ、2 つの状態と 1 つの入力があります。入力に基づいて計算を実行し、2 番目の状態に進むかどうかを決定する最初の状態のイベントが必要です。それは移行イベントです。 (transitionEvents は状態の onInput イベントリストにあります。この最初の状態で入力を受信すると、イベントの condition が満たされると、イベントは 2 番目の状態への移行を実行します。) 2 番目の状態に達すると、状態に入るとすぐにメッセージを送信します。(onEnter イベントを使用します。2 番目の状態に入ると、このイベントはメッセージを送信します。別の入力が到着するのを待つ必要はありません。) 他の種類のイベントもありますが、簡単な例として必要なのはそれだけです。

他のタイプのイベントは onExit と onInput です。入力を受け取り、条件が満たされるとすぐに、onInput イベントは指定されたアクションを実行します。オペレーションが現在の状態を終了し、条件が満たされると、onExit イベントは、指定されたアクションを実行します。

何か足りないものはありますか？ はい、どうすれば最初の「車は燃料を必要としない」状態に戻ることができますか？ ガスタンクを満たした後、入力は満タンを示します。2 番目の状態では、入力が受信されたときに発生する最初の状態に戻る移行イベントが必要です (2 番目の状態の onInput: イベント)。計算により、目的の場所に到達するのに十分なガスがあることが示された場合は、最初の状態に戻るはずです。

それが基本です。一部のディテクターモデルは、可能なアクションだけでなく、重要な入力を反映する状態を追加することにより、より複雑になります。例えば、温度を追跡するディテクターモデルに、「正常」状態、「高温」状態、「潜在的な問題」状態の 3 つの状態があるとします。温度が特定のレベルを超えると、潜在的な問題の状態に移行しますが、まだ熱くなりすぎていません。この温度に 15 分以上留まらない限り、アラームを送信したくありません。それ以前に温度が正常に戻ると、ディテクターは正常状態に戻ります。タイマーが時間切れになると、ディテクターは高すぎる状態に移行し、アラームを送信しますが、注意が必要です。可変とより複雑なイベント条件のセットを使用して、同じことを行うことができます。ただし、多くの場合、別の状態を使用して、実際には計算結果を保存する方が簡単です。

ディテクターのインスタンスが 1 つ必要か、それとも複数必要かをどのようにして知ることができますか？

必要なインスタンスの数を決定するには、「何を知りたいですか？」と自問してください。今日の天気を知りたいとしましょう。雨が降っていますか (状態)？ 傘をさす必要がありますか (アクション)？ 温度を報告するセンサー、湿度を報告するセンサー、気圧、風速と風向、降水量を報告するセンサーを使用できます。ただし、これらすべてのセンサーを一緒にモニタリングして、天気の状態 (雨、雪、曇り、晴れ) と適切なアクション (傘をさすか日焼け止めを塗る) を判断する必要があります。センサーの数にかかわらず、1 つのディテクターインスタンスで天気の状態をモニタリングし、実行するアクションを通知する必要があります。

ただし、お住まいのリージョンの天気予測をしている場合は、そのようなセンサーアレイの複数のインスタンスが、リージョン全体のさまざまな場所に配置されている可能性があります。各場所の人々は、その場所の天気がどのようなものかを知る必要があります。この場合、ディテクターの複数のインスタンスが必要です。各場所の各センサーによって報告されるデータには、key フィールドとして指定したフィールドが含まれている必要があります。このフィールドにより、 AWS IoT Events はエリアのディテクターインスタンスを作成し、到着し続けるときにこの情報をそのディテクターインスタンスに送信を続けることができます。髪を荒らしたり、鼻を日焼けさせたりする必要はもうありません！

基本的に、モニタリングする状況が 1 つ (1 つのプロセスまたは 1 つの場所) ある場合は、1 つのディテクターインスタンスが必要です。モニタリングする状況 (場所、プロセス) が多い場合は、複数のディテクターインスタンスが必要です。