【IoT】「通知」を深掘りする
通知って案外奥深い。
IoTシステムを構築する中で、最近このように思っています。IoTデバイスによって得られた現場の異常（例えば、設備異常など）に素早く気づき、現場を動かすためには、「通知」の仕組みが有用です。この通知を実装する上で、通知先が数ヶ所だったり、通知条件がシンプルであればよいのですが、通知先が数10ヶ所や数100ヶ所になったり、より複雑な条件で通知したくなった場合、通知についてあれやこれや考える必要があります。
この記事では、私自身が実際にIoTシステムを構築する中で直面した事例を元に、「通知」を深掘りして考えてみたいと思います。
どのような条件時に通知がほしいか？
私自身が直面した事例は、設備異常監視に関わる通知です。主な要件は下記の通りです。設備を管理されている方は、似たような現場があるのではないでしょうか。
・設備異常を検知するためのIoTデバイスが、現場に設置されている
・このIoTデバイスは、定期的に設備状態（0:正常、1:正常）を取得している
・設備状態情報が、SORACOMの通信を用いて定期的にクラウドに送信される
・各現場には合計約100台の設備があり、各設備の管理者（ユーザー）ごとに通知したい
また、通知がほしい条件は以下の通りです。
・設備異常時に通知したい！
・設備復帰時にも通知したい！
・IoTデバイス自体の不具合監視のため、一定期間通信がない場合通知したい！
これら３つを、①設備異常時、②設備復帰時、③一定期間通信がない時、と定義し、深掘りします。
通知判断タイミングと通知条件を整理する
先程の、①設備異常時、②設備復帰時、③一定期間通信がない時、それぞれにおいて、通知判断タイミング（When）と、通知条件（What）を整理しました。下の表をご覧ください。なお、模式図列のグラフにおいて、横軸が時間、縦軸が設備状態であり、0が正常、1が異常です。
まずは、「①設備異常時」の通知を考えます。この場合、設備状態データ受信時に、「設備状態＝異常であれば通知する」という通知条件を設定をすれば、通知が可能です。時間の概念が不要で、非常にシンプルです！まずは、ここから実装することをおすすめします。
次に、「②設備復帰時」の通知を考えます。この場合、設備状態データ受信時に、「今回設備状態＝正常、かつ前回設備状態＝異常であれば通知する」という通知条件設定が必要となります。ここでのポイントは、前回の設備状態情報が必要になる点です。前回の設備状態情報、つまり過去のデータが必要となるため、どこかに過去データを保存しておき、その保存データを読み取る必要がでてきます。
最後に、「③一定期間通信がない時」の通知を考えます。この場合、過去データをどこかに保存しておき、「現在時刻ー前回通信時の時刻＞●●hrであれば通知する」という通知条件設定すれば、実現できそうです。問題は、どのタイミングでこの通知条件判断するか、ということです。③の場合、データが受信されないので、データ受信時に判断するということができません。よって、定期的に（例えば毎朝8時に）通知判断する必要がでてきます。定期的に通知判断する仕組みをつくることがポイントです。
ここまで、３つの場合に分けて、通知判断タイミング（When）と、通知判断条件（What）を整理してきました。次は、どのような仕組みで通知するか（How）を考えます。
通知方法（通知先が数ヶ所の場合）
まず、通知先が数ヶ所の場合を考えます。IoTシステムを構築する上で、最初は数台からスタートすると思いますので、多くはこの通知方法で解決できると思います。通知先が数ヶ所の場合、SORACOMの通知判断サービスを使うのが最もシンプルで簡単です。以下に、全体構成図を示します。
数台のIoTデバイスから送信されるデータを、SORACOMのクラウドに送信します。詳細は省きますが、Unified Endpointという送り先に送信しておくことがポイントの一つです。デバイスからのデータを、データ収集サービスであるSORACOM Harvestを使って収集します。収集データを、可視化／通知判断サービスであるSORACOM Lagoonに渡します。SORACOM Lagoonを用いれば、可視化に加え、通知条件設定が可能です。しかも、上述した①設備異常時、②設備復帰時、③一定期間通信がない時、の３つの通知条件をマウス操作で設定できます。先程の図では、通知手段としてLINEを用いていますが、SlackやEmail等も設定可能です。まずは、この方法で通知条件を設定し、実運用することをおすすめします。
通知方法（通知先が数10ヶ所以上の場合）
問題は、IoTデバイス数が数10台を超え、通知先が数10ヶ所以上になった時です。このように規模が大きくなってきた場合、SORACOM Lagoonでも実装できなくはないのですが、コストがかかったり、運用の手間が増えたりと、やっかいな問題が出てきます。この問題を解決するため、Amazon/Microsoft/Googleなどが展開しているメガクラウドサービスの活用が有用です。私は、この設備異常監視を通し、初めてメガクラウドサービスを使いました。どの会社のクラウドサービスを選べばよいのかわかりませんでしたが、Web上に情報量が多いサービスのほうが何かと良いだろうと思い、私はAmazonのAmazon Web Services（AWS）を使うことにしました。また、AWSを用いた通知判断方法にも、色々とやり方があるようなのですが、今回は、最も情報量の多かったAWS Lambdaを中心に構成することとしました。
①設備異常時の通知方法
まずは、「①設備異常時」の通知方法を考えます。以下が全体構成図です。
通知判断を、SORACOM Lagoonから、AWS Lambdaに変更しています。AWS Lambdaは、クラウド上でプログラムを実行できるサービスであり、Lambda上に通知判断プログラムを書けば、数10ヶ所以上への通知を実現できます。SORACOMからAWS Lambdaにデータを渡すため、データ転送サービスであるSORACOM Funkを用います。SORACOM Funkを用い、simID/deviceIDデータと設備状態データを、AWS Lambdaに転送します。これらのデータを受けたAWS Lambdaは、「設備状態＝正常or異常」を判断し、異常であればLINE Notify等で通知します。
この構成を実現する上でハマったのは、
・SORACOM FunkからAWSに転送されるデータフォーマット
・AWSの認証の概念（IAMロールとIAMポリシーを理解する必要あり）
でした。Funkからのデータフォーマットに関しては別の記事ににまとめたいと思っています。
②設備復帰時の通知方法
次に、「②設備復帰時」の通知方法を考えます。以下が全体構成図です。
設備復帰時の通知を実現するには、設備状態データ受信時に、「今回設備状態＝正常、かつ前回設備状態＝異常であれば通知する」というプログラムを実行する必要があります。前回の設備状態情報、つまり過去のデータが必要となるということがポイントです。過去データの保存やデータ取り出しのため、Amazon DynamoDBというサービスを利用します。Lambda内に、受信データをDynamoDBに保存するプログラムを追加することで、Lambdaで前回の設備状態情報を取得することができるようになります。なお、DynamoDBにデータを保存する上で、データを一意に識別するための識別子（プライマリーキー）を設定する必要があるため、識別子（パーティションキー）をsimID/deviceID、識別子枝番（ソートキー）をデータ受信時刻としました。
③一定期間通信がない時の通知方法
最後に、「③一定期間通信がない時」ときの通知方法を考えます。以下が全体構成図です。
一定期間通信がない時に通知したい場合、「現在時刻ー前回通信時の時刻＞●●hrかどうか」を判断し、条件を満たすデバイスがあれば通知する、といったLambda関数を、定期的に（例えば毎朝8時に）実行する必要があります。前回通信時の時刻の取得に関しては、②で設定したDynamoDBから、取り出すことができます。一方、定期的なLambda実行に関しては、Lambda単体では実現できないため、任意時刻にLambda関数を実行させることができるAmazon EventBridgeというサービスを用います。このように、AWS Lambda、Amazon DynamoDB、Amazon EventBridgeという3つサービスを組み合わせることで、③一定期間通信がない時に通知する、を実現できます。
まとめと今後の課題
ここまで、①設備異常時、②設備復帰時、③一定期間通信がない時、における通知方法について考えてきました。色々いじってみて、私自身がAWSに慣れていないこともありますが、SORACOM内で通知の構成を完結させる方がよっぽど楽だなぁと感じました。
ただ、AWSを活用することで他にも色々と応用ができそうなので、引き続きAWSを活用してみたいと思っています。設備異常監視を通し、初めてAWSを触りましたが、AWS Lambdaさえ突破すれば、Lambdaを起点に周辺サービスが見えてくると感じました。また、ChatGPTを使えば、Lambdaに記述するプログラム作成も案外できます。まだAWSを使われたことがない方は、まずはLambdaを突破することから始めると良いかも知れません。
今回、通知方法として、AWS Lambdaを核とした仕組みを採用しました。色々と調べていると、AWS IoT Coreというサービスを用いても通知を実装できるようです。今後は、AWS IoT Coreも試してみて、メリット・デメリットを比較検討したいと思っています。
参考
Unified Endpointについて
SORACOM Lagoonについて
Funk→AWS Lambda→LINE Notifyでの通知について
Amazon EventBridgeのスケジュール設定について
この記事が気に入ったらサポートをしてみませんか？