見出し画像

【IoT】「通知」を深掘りする

通知って案外奥深い。

IoTシステムを構築する中で、最近このように思っています。IoTデバイスによって得られた現場の異常(例えば、設備異常など)に素早く気づき、現場を動かすためには、「通知」の仕組みが有用です。この通知を実装する上で、通知先が数ヶ所だったり、通知条件がシンプルであればよいのですが、通知先が数10ヶ所や数100ヶ所になったり、より複雑な条件で通知したくなった場合、通知についてあれやこれや考える必要があります。

この記事では、私自身が実際にIoTシステムを構築する中で直面した事例を元に、「通知」を深掘りして考えてみたいと思います。


どのような条件時に通知がほしいか?

私自身が直面した事例は、設備異常監視に関わる通知です。主な要件は下記の通りです。設備を管理されている方は、似たような現場があるのではないでしょうか。
・設備異常を検知するためのIoTデバイスが、現場に設置されている
・このIoTデバイスは、定期的に設備状態(0:正常、1:正常)を取得している
・設備状態情報が、SORACOMの通信を用いて定期的にクラウドに送信される
・各現場には合計約100台の設備があり、各設備の管理者(ユーザー)ごとに通知したい

また、通知がほしい条件は以下の通りです。
・設備異常時に通知したい!
・設備復帰時にも通知したい!
・IoTデバイス自体の不具合監視のため、一定期間通信がない場合通知したい!

これら3つを、①設備異常時、②設備復帰時、③一定期間通信がない時、と定義し、深掘りします。

通知判断タイミングと通知条件を整理する

先程の、①設備異常時、②設備復帰時、③一定期間通信がない時、それぞれにおいて、通知判断タイミング(When)と、通知条件(What)を整理しました。下の表をご覧ください。なお、模式図列のグラフにおいて、横軸が時間、縦軸が設備状態であり、0が正常、1が異常です。

まずは、「①設備異常時」の通知を考えます。この場合、設備状態データ受信時に、「設備状態=異常であれば通知する」という通知条件を設定をすれば、通知が可能です。時間の概念が不要で、非常にシンプルです!まずは、ここから実装することをおすすめします。

次に、「②設備復帰時」の通知を考えます。この場合、設備状態データ受信時に、「今回設備状態=正常、かつ前回設備状態=異常であれば通知する」という通知条件設定が必要となります。ここでのポイントは、前回の設備状態情報が必要になる点です。前回の設備状態情報、つまり過去のデータが必要となるため、どこかに過去データを保存しておき、その保存データを読み取る必要がでてきます。

最後に、「③一定期間通信がない時」の通知を考えます。この場合、過去データをどこかに保存しておき、「現在時刻ー前回通信時の時刻>●●hrであれば通知する」という通知条件設定すれば、実現できそうです。問題は、どのタイミングでこの通知条件判断するか、ということです。③の場合、データが受信されないので、データ受信時に判断するということができません。よって、定期的に(例えば毎朝8時に)通知判断する必要がでてきます。定期的に通知判断する仕組みをつくることがポイントです。

ここまで、3つの場合に分けて、通知判断タイミング(When)と、通知判断条件(What)を整理してきました。次は、どのような仕組みで通知するか(How)を考えます。

通知方法(通知先が数ヶ所の場合)

まず、通知先が数ヶ所の場合を考えます。IoTシステムを構築する上で、最初は数台からスタートすると思いますので、多くはこの通知方法で解決できると思います。通知先が数ヶ所の場合、SORACOMの通知判断サービスを使うのが最もシンプルで簡単です。以下に、全体構成図を示します。

数台のIoTデバイスから送信されるデータを、SORACOMのクラウドに送信します。詳細は省きますが、Unified Endpointという送り先に送信しておくことがポイントの一つです。デバイスからのデータを、データ収集サービスであるSORACOM Harvestを使って収集します。収集データを、可視化/通知判断サービスであるSORACOM Lagoonに渡します。SORACOM Lagoonを用いれば、可視化に加え、通知条件設定が可能です。しかも、上述した①設備異常時、②設備復帰時、③一定期間通信がない時、の3つの通知条件をマウス操作で設定できます。先程の図では、通知手段として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のスケジュール設定について


この記事が気に入ったらサポートをしてみませんか?