(レポート)MBL313: 新機能!AWS IoT Deep Dive: ハードウェアKits、Deivces SDK、プロトコルなどを理解する #reinvent

2015.10.19

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、せーのです。Re:Invent 2015のセッションレポートも佳境に入ってきました。 今回は2日目の夕方に行われたAWS IoTのDeep Diveセッションについてレポート致します。

こちらは既にYoutubeにてセッションの様子がアーカイブされていますのでそちらも合わせてご覧になって下さい。

AWS IOSは幾つものデバイスをセキュアにつなげることができる。 デバイス1つから何百万デバイスまでOK。 オンラインで購入できるスターターキットを使えばより簡単にIoTを始められる。

セキュリティについて

mbl313_0

IoTで求められるセキュリティー

  • 強い認証
  • きめ細かい認可
  • セキュアな相互通信

強い認証 / きめ細かい認可

MBL313_1

このデバイスは自分のデバイスなのか、他人のなのか、自分のデバイスをどう加えるかという部分。 セキュリティは最も優先事項が高い項目。 求められるのは「きめ細かく」「最小権限の」認可アクセスコントロールである。 そのためにはホワイトリストが望ましい。

まずAWS IoTではきめ細かい認証としてX509認証とTLS2.1をベーシックとして全てのデバイスの認証に使用し、自身のプライベート鍵でのみ通信出来るようになっている。 ユーザーは自分で暗号化を伴ったラッパーモジュールを使ってデバイス自身に鍵を保存、管理することができる。 ポイントはあらゆるCredentialsをデバイスのなかに持たない、ということだ 証明書はリモートでコマンドひとつで無効にすることができる。

セキュアな相互通信

MBL313_2

TLS1.2はデバイスとサービスのセキュアな相互通信を可能にする。 これらのセキュリティ実装はSDKから簡単にすることができる。TLSのサンプルライブラリはCで書かれたものが配布されている。

プロトコルについて

今IoTではMQTTがプロトコルとしてはデファクトスタンダードになっている。 第二の方法としてデバイスとサービスをプログラマブルにつなぐ手段としてDevice Shadowという方法を作った。

MQTT

MQTTはとても軽く、バッテリーにも優しい。ここで事例を見てみよう。BMWの事例だ。

MBL313_3

車の各デバイスからメッセージがトピックに向かって投げられる。 どの車か、という情報はサブトピックに入っている。 一方でサービスは街の全ての車からメッセージをハッシュ値として受け取る。

QoS

AWS IoTではQoS 0とQoS 1をサポートする。

MBL313_4

QoS 0ではエンドツーエンドでみるとメッセージをロストした場合はロストしたままである。履歴上もロストしたことは気にしない。 QoS 1では更に良くなり届かなかったパケットがあった場合は再送信してくれる。 MQTTにはkeep-aliveという属性もあり、メッセージの前後でFakeとなるTCP通信を切り落としてくれる。MQTT Keep-Aliveは実際はメッセージ送信の前後を見ているので、デバイスが実際につながっているかどうかを確認することができる。ユーザーはメッセージのやり取りをどれくらい頻繁に行うかコントロールすることができる。

Shadows

Shadowsは開発者にとってとても簡単にデバイスの状態を表現できる仕組みだ。Shadowはプログラマブルなデバイスの表現として保管されており、デバイスから現在の状態をdesiredに送信し、デバイスがつながった時にはデバイスの状態をアップデートして現在の状態にはバキュームをかける。通信方法はHTTP RestとMQTT。デバイスが再び接続された時にはdeltaを取得しアップデートする。deltaはdesiredとreportedの差であり、desiredがonになるとdeltaもonになる。 例えば右の例でいえばdesiredはcolorがREDだがreportedはランプの色がGREENとなっている。従ってdeltaはその違いを取得してREDとなる。versionはデバイスの管理バージョンとなっている。

mbl313_6

shadowsは2つのtopicを作る。一つはpublishでget/update/deleteを投げる。デバイスはshadowに向かって通信を投げ、戻り値としてaccepted/rejected/deltaを受け取る。deltaはデバイスがランプをGREENからREDに変える決断をする要素となる。これらをMQTTを使ってメッセージングする。

ユースケース

それではどのように使うのか見てみよう。モバイルからAWS IoTに対して「エンジンをONにしろ」とメッセージを投げる。エンジンコントロールは「俺は今OFFだよ」と現在の状態をShadowsに投げる。そうするとShadowsは「いやいや、お前はONにしてくれ」とエンジンコントロールに戻り値を送る。エンジンコントロールは「OK、ONにしたよ」と戻り値を返す。

mbl313_7

SDK

Starter KitとAWS IoT SDKを使えば簡単にIoTが始められる。SDKは三種類用意した。まずはArduino。これはYun用だ。続いてnode.jsこれはエンベッドされたLinux、例えばLaspberry PiやDragon Boardなどで使える。Cはもう少し複雑なデバイス用だ。例えばバッテリーで動くデバイスやウェアラブルデバイスなどだ。

Arduino

Arduino IDEは一般的なIDEが使える。SDKを通してOSのマイクロプロセッサに簡単に信号が渡る。簡単にハードウェアを制御でき、TLS the MQTT等の重労働もSDKのランタイムが動くことによってマイクロプロセッサへの通信やスケッチを有効に行う。

mbl313_8

(ここでArduinoのDemo)

node.js

node.js SDKはJavaScriptという高次元の読みやすい言語にも関わらず簡単にIoTを制御できる。6時にインストールを開始したら6時10分にはもうライブラリのインストールは終わっている。 この例は2秒毎に発信する、というとても簡単なサンプルだ。

mbl313_9

(ここでnode.jsのDemo)

C

C SDKはもう少し深い、バッテリーを使ったデバイスやウェアラブルデバイスに使用する。想定しているのは既にCで書かれているコントローラーにポイントを追加するような場合だ。 C SDKはLinuxやOS10に載っているPOSIXポートを使ってコードを送る。従ってC SDKをダウンロードするとLinuxやMacですぐに始められる。memory allocationやmallocはない。全てのリソースは予め定義可能だ。なのでどのくらいの大きさになるかを決められる。

(ここでCのDemo)

地震監視Demo

ここでDemoを披露する。使うデバイスは3つ。Marvel MW300とmediatech LinkIt OneとArduino Yun Boardだ。3つとも同じデータがAWS IoTに送られる。RulesエンジンはそこからまずすべてのMQTTメッセージデータをダッシュボード表示用にKinesisに送る。Elastic Beanstalkには簡単にKinesisのデータを表示するようのKinesisアプリが揃っている。 次のRuleは5Gを超える地震波形を検知すると連絡して欲しいと思う。Amazon SNSは私の電話に通知してくれる。 また同じRuleで5Gを超えるとLambda Functionがキックされる。物理的なアラームが欲しい。ここにあるのはIntel Edisonのボードだ。これにはリレースイッチがついていて、たいへんやかましいアラームランプが取り付けてある。Lambda Functionはアラームの状態をShadowにむけてアップデートし、EdisonはShadowからdeltaを取得して実際のアラームを点ける。アラームは3秒だけ鳴り、その後またOFFになる。

mbl313_10

(ここでDemo)

まとめ

いかがでしたでしょうか。それぞれのSDKの使いみちとサンプルデモ、そしてIoTの典型的な使い方のDemoととても実践的な内容でした。 こちらを参考にスターターキットを買ってAWS IoTを初めて見るのもいいですね。