IoT設備異常通知システムの改善点（AWS周り）
現状、IoTデバイスを用いた設備異常通知／設備復帰通知の仕組みを構築していますが、実運用上、改善したい点がいくつか出てきました。本記事では、改善点を洗い出します（解決策は今後の記事で）。
1. 現状のIoTシステム
まず、現状の設備異常通知／設備復帰通知システムを整理します。
現状、各設備にIoTデバイスを取り付け、IoTデバイスで取得した設備状態（0:正常、1:異常）を、SORACOM通信回線を用い、SORACOMのクラウドに飛ばしています。
この事例では、複数の設備があり、かつ各設備の維持管理者が異なるため、設備毎に通知先（LINE通知先）を設定する必要があります。シンプルな異常通知の場合は、SORACOMのサービス内で通知が可能です。一方、このように少し複雑な通知条件の場合、AWS等のクラウドサービスを用いたほうが優位性があります。
SORACOMのデータ転送サービスであるSORACOM Funkを用い、AWS Lambdaにデータを転送し、Lambda関数と過去データ保存用DynamoDBを用い、設備異常／設備復帰を判断します。判断結果に応じ、各設備の維持管理者にLINE Notifyを用いたLINE通知を行います。
2023年11月に初めてAWSを使い始め、運用してきましたが、1年弱たち、色々と改善したい点が出てきました。2024年9月に高知県でAWSのユーザー会が開催されることもあり、AWSに関連する課題を整理します。
2. 【課題1】マスターデータのメンテナンス性向上
IoTデバイスの紐づくIDをsimIDとし、simIDに紐づく設備IDとLINE tokenがあるとします。現状、これらのマスターデータを、Lambda関数内に貼り付けていますが、メンテナンス性が非常に悪いです。。Excelの表みたいに、わかりやすい表現方法で保存したい。
以前、AppSheetと DynamoDBを連動させると良いと教えて頂いたのにも関わらず、まだ実装できておらず。。近々実装したいと思っています。
3. 【課題2】過去データの保存先はDynamoDBかS3か
設備異常の定義は、前回設備状態が正常、かつ現在設備状態が異常としています。また設備復帰の定義は、前回設備状態が異常、かつ現在設備状態が正常としています。
つまり、IoTデバイスからの設備状態取得時刻での設備状態だけでなく、前回データ（＝過去データ）をどこかに保存し、前回データを参照する必要があります。この前回データをどこに保存すればいいのでしょうか。
現状、DynamoDBに保存していますが、S3にも保存することができます。この使い分けを、イマイチ腹落ちして理解できておらず。AWSのサービスは非常に多岐にわたっており、複数の手段系があるのですが、その手段系の使い分けがわからないことが多いです。こららをある程度理解した上で、実装できるようになりたいです。
4. 【課題3】取り溜めたデータを可視化したい
過去データを、DynamoDB（今後、場合によってはS3に変更）に溜めていますが、このデータを活用できていません。データ活用を前提に、まずは可視化してみたいのですが、どうやって可視化すればいいのか調べられていません。今後の課題です。
5. まとめと今後の課題
現状の課題を3つ洗い出しました。
実運用の中で、気づくことが色々とあります。
2024年9月にAWSのユーザー会とSORACOMのユーザー会の共催イベントがありますので、 この日をターゲットに課題を深堀りし、不明点をお尋ねしたいと思っています。
参考文献
・AppSheetとDynamoDBを連動させることができる
・2024年9月7日開催の、JAWS UGとSORACOM UG四国の共催イベント