はじめに

こちらのイベントに参加してきたのでそれについてまとめます。(久しぶりに自分の仕事と関係ありそうな内容を聞きに行ったなあ。。。)

JAWS-UG（AWS Users Group – Japan）とはその名前の通りAWSの日本ユーザーグループのようです。AWSは様々なクラウドサービスを展開していますが、今回は「AWS IoT」についての勉強会でした。

イベント詳細・タイムテーブルなどはイベントページを参照してもらうことにして、以下から各セッションについてのメモ書きを残します。内容が多かったので、箇条書きメモっぽくなって記事らしい内容にはなりませんでした。。。

AWS IoT サービスこの1年の進化 (AWSJ 亀田さん)

以下に紹介されたサービスについて書きます。といっても詳細についてはメモしきれてません。

AWS IoT core

AWS IoTを使う用途は主に2つ

データ収集
リモート制御

AWS IoT以外にもAmazonにはAmazon Kinesisというサービスもサポートしている

AWS IoT
- HTTP, MQTT, WebSocketをサポート
- 双方向制御ができる
- クライアント証明書をサポート
- 値段高め
Amazon Kinesis
- HTTPのみをサポート
- 専用ライブラリが必要
- データストリーム

AWS IoT Device Management

AWS IoT coreでできることは各デバイスに証明書を与えることであるが、このサービスでは複数のデバイスをまとめて制御可能。AWS IoT Testerでテスト可能。

AWS IoT Analytics

IoTデータの収集・前処理・拡張・保存・分析・可視化を可能にするサービス。ストレージに保存したデータに対して分析が可能であり、リアルタイムでの分析は不可。

AWS IoT SiteWise

工場。農場からの大量のデータをストレージに貯めるためのサービス。収集したデータをアセット単位・プロセス単位で処理が可能。

Amazon Free RTOS

マイクロコントローラ向きのIoT operating systemを提供するサービス。

AWS IoT Greengrass

Edgeデバイスのためのサービス。Greengrass Coreをインストールしたデバイスをゲートウェイのソフトウェアから操作することでクラウドベースでの管理が可能になる。

まとめ

それぞれにリンクを貼ったので詳細はそれぞれのドキュメントを参照してください。一口にAWS IoTといっても様々なサービスがあったことを今回初めて知りました。個人的に気になったのはFreeRTOSですね。

AWS IoTサービスの理解の深化と真価 (AWSJ 市川さん)

ここで紹介されたサービスは2つです。

AWS Things Qraph
AWS IoT Events

AWS Things Graph

NodeREDのようなGUI操作で複数デバイスとサービスの接続を記述することで、視覚的にワークフローを制御することができる。デバイスとサービスは、モデルと呼ばれる再利用可能な構築済みコンポーネントとして表され、プロトコルやインターフェイス等の低レベルの詳細は表示されず、モデルを統合して複雑なワークフローを作成することも簡単に行える（サイトの説明抜粋）。モデルの定義はGraphQLによる記述が必要。

AWS IoT Events

AWS IoT core・AWS IoT Analyticsからのデータを継続的に監視するステートフルなイベントの管理が可能。ユースケースとして、複数のデータを監視して複雑なイベントの管理をしたい場面に使える。また、大量なデータに含まれるノイズに対する処理（何回通知したら警告みたいな処理）が可能になり、サーバに通知する無駄な通信を減らすことができる。注意点は以下の2点

オートセーブの機能がないので定期的にPublishすることが必須
一定期間データが来ないと保存されていたデータとモデルが削除される

まとめ

両者とも新しく提供されたサービス(2019年時点)なので、ぜひリンク先でチェックしておくと良いかもしれません。AWS IoT Events・AWS Things GraphともにGUIベースになっているので直感的な記述ができそうだなと感じました。

IoTのつくり方～おさえておくと捗るモロモロ (JAWS UG IoT専門支部運営青木さん)

IoTシステムの基本構成から各要素についての解説をメモ。

IoTデバイス

ここで重要になるのは電源。

データの特性

定期的に収集されるデータ
- 連続して投げられるもの
離散的に発生するデータ
- あるイベントにのみ発生する

エリアネットワークのプロトコル問題

例えばWifiとXBeeはチャンネルがかぶっているので同時に通信することが難しい。

ゲートウェイ

データのどこでタイムスタンプを付与するか。

センサ
- 実際にデータを取得した時間が取得できる
- 時計同期の実装が必要
ゲートウェイ
- 一括管理が可能
- 誤差あり

ゲートウェイにどこまでのスペックをもたせるかを考える。あえてゲートウェイを採用しないケースもある

広域通信網

LPWA・3Gなど様々な方式がある

IoTサーバ

コストと安定した運用のために使えるマネジメントサービスは積極的に取り入れる。やれるところからマイクロシステムの疎結合にする。

さいごに

完全にメモ書きな内容になりました。なにか補足・指摘ありましたら編集リクエストください。