この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
CX事業本部の佐藤智樹です。
本企画は、弊社チームIoTメンバーが初心に返ってIoTサービスについて学びなおし、解説してみようというものです。本記事では、IoTデバイスのイベントをAWS側で効率よく検知しアクションできる『AWS IoT Events』について紹介します。
内容としては基本的な構成要素や機能にフォーカスして紹介いたします。役に立つユースケースや利点などは以前に以下の記事で紹介したのでユースケースが気になる場合は先にこちらをご確認ください。
AWS IoT Events の概要
AWS IoT のアーキテクチャの中で「Data Service」にあたるサービスです。
引用：AWS IoT の仕組み
以下公式からの紹介文の引用です。
AWS IoT Eventsは、IoT センサーおよびアプリケーションからのイベントを検出して応答します。イベントとは、移動信号を使用して照明を活性化させた動き検出器や防犯カメラなど、予想以上に複雑な状況を特定するデータのパターンです。AWS IoT Events、複数の IoT センサーやアプリケーションからのデータを継続的に監視し、AWS IoT Core、IoT SiteWise、DynamoDB などの他のサービスと統合することで、早期検出と独自の洞察を実現します。
上記にあるようにデバイスの状態を検知するためのサービスです。
AWS IoT Events の利点
IoTサービスで使用するデバイスは多くの場合処理能力が高くないものが多く、現在のセンサーの値の通知は可能ですが状態を判定して通知するのは難しい場合も多くあります。例えば温度センサーで今の温度が何度かという通知は可能だが、直近のデータから異常な温度になっているかなどの判定はPLCなどに細かくロジックを組み込む必要があります。
上記の例やさらに複雑な状態を定義して管理する場合、エッジデバイス側で実装することは難しくクラウド側の場合はLambdaなどで実装するためステートマシンの実装が必要になります。ただステートマシンの実装はなかなか負荷が高く、独自に作ることでさらにバグを埋め込む可能性も高くなります。
そこで IoT Events を使えばGUIベースでステートマシンを簡単に実装に組み込むことができます。また、CloudFormationやAWS CDKを使ったコード管理なども簡単にできます。ステートマシンとの関係については以下のブログが詳細に書かれているので参考になります。
次章では上記を簡単に実装するためにどのような機能が IoT Events に含まれているのか紹介していきます。
機能の紹介
探索機モデル(検出器モデル)
探索機モデルはステートマシンを管理するためのモデルを定義するものです。公式ドキュメントには探知器モデルや検出器モデルなどの名前で記載されています。探索機モデルはGUI上では以下の3つで構成されます。それぞれの細かい設定以降に記載します。
開始位置
名前の通り探知器モデルがデータを受信した際に、どの状態から開始するか指定するためのものです。上の図ではline-startが対象になるように選択されています。ここに到達すると探知器（コンソール上のコメントでは探知器インスタンス)が作成されます。イベント自体はAWS CLI、もしくはIoT CoreのIoT RuleやIoT AnalyticsからIoT Eventsに向けて送信することができます。
状態
ライトのON/OFFやデバイスの異常/正常などの状態を管理します。状態には3つのイベントがあります。以下のイベントの中にアクションを組み込むことで細かい処理を実装することができます。それぞれのイベントの中でアクションとアクションを実行するかの「イベントの条件」が設定できます。条件については遷移条件内の評価式と構文は同じなのでそちらで記載します。
- OnEnter: 対象の状態に遷移したタイミングで実行
- OnInput: 対象の状態であるときにデータを受信すると実行
- OnExit: 対象の状態から別の状態に遷移する場合に実行
遷移条件
次の状態に遷移するための条件や評価式を判定する際のアクション設定ができます。以下の画像右下のグレー部分が実際の評価式に当たります。実装としては、以前にきたデータ$variable.previosLineEndTimeと今回受信したデータ$input.lineInput.lineEndTimeが異なれば状態が遷移します。
アクション
別のAWSサービスへの連携や変数の保存、タイマー作成などを行うことができます。状態と遷移条件に設定します。変数は直近の状態を保持して条件分岐したい場合に有効活用できます。タイマーは開始・停止・リセットが設定でき一定時間以上イベント受信がない場合タイマーのタイムアウトを検知して死活監視などができます。別のAWSサービスには以下のサービスが連携先に対応しています。
- DynamoDB
- IoT Topic(Rule)
- IoT Events
- Kinesis Firehose
- SNS
- SQS
探索機(ディテクター)
IoT Eventsの探索機モデルでデータを受信した場合に作成されます。デバイスと1:1対応になるように作成します。デバイスが1つしかない場合は、IoT Eventsを発行する際の「探知器生成メソッド」で「単一の探索機を作成する」を選択すると単一で生成されます。具体的には以下のように表示されます。
「一意のキーごとに探索機を作成する」を選択するとデバイスごとに個別の探索機が生成されます。具体的には以下のような表示になります。
ディテクターの評価方法
ディテクターの条件式の評価順は2種類あります。「バッチ評価」と「シリアル評価」です。こちらの評価順についてはGUIコンソール上に書かれている通りです。
書かれている通りではあるのですが、具体的に評価式ごとにどう処理順が変わるのかはわかりづらいです。もし詳細が気になる方がいる場合は、以下の IoT Events の BlackBelt の動画(28:10~)を見ることをお勧めします。資料だけでは得られない詳細な内容が語られています。
デバッグ
最後に簡単なデバッグ方法を紹介します。GUIコンソール上で構築している場合は、「分析を実行」ボタンを押すことでアクション設定や条件式の空欄、型チェックなどを行ってくれます。AWS CLIやAWS CloudFormartionなどから探知機モデルを更新する場合も同様に分析が適応されます。
最近日本語の公式ブログでも紹介されました。以下のブログでは型チェックについて触れられています。
条件式の細かい境界値のチェックやタイマーの動作確認などは上記の方法では対応していません。なのでロジックをテストしたい場合はGUIコンソール上でテストデータを流して実行するか、IoT Ruleからデータを実際に流すテストコードを書くことで実施できます。こちらは今後記事でテストコードの書き方を紹介したいと思います。
所感
少し前に色々使っていたのですが、細かい機能についての紹介はあまり記事が多くなかったので改めて紹介してみました。どなたかの理解のお役に立てば幸いです。
3
