Azure IoT Hubのススメ ～デバイス管理編～ ２０１７/８/２６

    

本日のお題 IoTに限らず遠隔地にあるクライアント（デバイス）を管理する ことは大変です。  障害が発生したからといって簡単には行けない。（僻地だからこその遠 隔操作機能）  同時多発テロ的に障害が発生した場合、保守員がいくらいても足りない。 本セッションでは実戦で想定されるシナリオに対し IoT Hubに備わる機能でどう対応するか等を 実務経験を踏まえながら解説します。

管理面での主なユースケース 一覧画面などで見たい。  属性を付与して管理したい。  マスタ的なもの。（住所や所属に関する情報など）  属性値でフィルタリングして画面に表示。 稼働状況を知りたい。 遠隔操作をしたい。 定期または定時などでデバイスへ指示を送りたい。 クライアントアプリをアップデートしたい。

おさらい（よく出る用語集）  デバイス  IoT Hubに接続するPC的なもの（なんでもいい）  サービス  バックエンドの管理などのこと  C2D  Cloud To Device の略  D2C  Device To Cloud の略  IDレジストリ  デバイスの識別情報を保管しておくところ  デバイスツイン  デバイス管理用のプロパティ

AZUREのドキュメントを読む際の注意点  日本語訳ページを読むと原文とニュアンスが違うので注意すること！！！  日本人の感覚からするとIdentityをIDと略されちゃうと別物に感じる。  個人的な意訳としては「識別情報の登録先（保管先）」ですかね。  なるべく原文を読みましょう！

管理視点での主なユースケース 一覧画面などで見たい。  属性を付与して管理したい。  マスタ的なもの。（住所や所属に関する情報など）  属性値でフィルタリングして画面に表示。 稼働状況を知りたい。 遠隔操作をしたい。 定期または定時などでデバイスへ指示を送りたい。 クライアントアプリをアップデートしたい。

該当する機能は大きく分けて二つ  デバイスの状態情報を操作する。（日本語訳がこうなので。。。）  デバイスIDを指定する。（１台分だけ）  デバイスIDを指定しない。（1000台まで取得可能） 条件指定は出来ない為、1001台目以降は一覧取得できない。。。 ⇒SDKの仕様ではなくIoT Hubの仕様。（意味不明）  認証関連もここに含まれる。  デバイスツイン（JSON型）にCRUD操作とクエリ発行が可能。  クエリも投げられる。  メタデータはいじれない。  上記の状態情報とは別物。（わかりにくい）  違いがわかりにくい。

デバイスの状態情報とやらを覗いてみる  デバイス取得用メソッド クライアントのソケット開閉状態で ConnectedとDisconnectedが リアルタイムで切り替わるので便利。 Azureのドキュメントには 開発時以外は参照しないでと書いてあります。 理由はこのクラスにはクエリが実行できないから。  デバイスクラス 1000まで！ ページングも無い メモ的に自由な文字列が保存できる。 例）撤去のため停止、など Disableにするとデバイスが持つ認証情報が 有効であってもコネクションが張れなくなる。

デバイスツインとは  簡易DocumentDBのようなもの。  JSON型  XML DBと比べて軽くてクエリがシンプル。  xpathとかxqueryとか面倒だった。。。  デバイス側、サービス側とで権限などが異なる。  どこがどう違うのかをしっかり理解して設計する必要がある。  JSON配列は保存できない。  どうしてもやりたければサイズ制限内でうまくやるしかない。  楽観的実行制御を使用。  デバイスから見たとき、競合相手がいないので意識することはないが サービス側は複数人が触る可能性があるため注意が必要。

デバイスツインの構成 デバイスからは見えない  変更通知機能がある。

JSONのサンプル Tags Desired Reported

各項目の使い方とか •その名の通り、一般的な「タグ」の解釈で良い。 •階層化も可能。 •デバイスからは見えない為、デバイスに必要となる情報はここに入れない。 •デバイスへの変更通知も無いため、好きなタイミングで変更できる。 Tags •サービスがデバイスの構成を同期するため使用する。 例）送信間隔：5分など •デバイスからは読み取り専用な為、安全。 •プロパティの変更はリアルタイムで通知される。（イベントが発火する） Desired •デバイスがサービスと状態を同期するために使用する。 例）”起動時刻”：”HH:mm:ss”, ”アップデート”：”ダウンロード済み” •プロパティの変更はリアルタイムで通知される。（イベントが発火する） •サービス側ではクエリを発行し状態を確認する。 例）SELECT * FROM DEVICES WHERE properties.reported.updateStatus = ‘downloaded’ Reported

クエリの基本  FROM句は「devices」固定。  オブジェクト型なのでSELECT句、WHERE句ともに「○○. ○○ 」と書く。 SELECT tags.location.region FROM devices WHERE tags.location.plant = ‘Redmond43’  AS,IN,GROUP BY も使える。  関数もある。 一般的な集計関数（sum,maxなど）、文字列操作（CONCAT,SUBSTRING） などなど

管理視点での主なユースケース 一覧画面などで見たい。  属性を付与して管理したい。  マスタ的なもの。（住所や所属に関する情報など）  属性値でフィルタリングして画面に表示。 稼働状況を知りたい。 遠隔操作をしたい。 定期または定時などでデバイスへ指示を送りたい。 クライアントアプリをアップデートしたい。

ハートビートを送る  定期的にD2Cメッセージを送信する。  流れとしては、タイマー作成⇒イベント発火⇒メッセージ送信 ※タイマー省略 そもそもデータの送信間隔が短い（1分以内とか）場合はサービス側でメッセージを飛ばし てないデバイスを抽出するのもよい。 JSONシリアライズ 匿名型である必要はない SDKのイケてないとこ…

Reported Propertyをハートビートの代用にする  メッセージの場合、捌きと解析が必要になる。  StreamAnalyticsは高いしロジック作りこむのも面倒。  Reported Propertyの場合ならクエリ投げるだけで確認出来る。  パターンとしてタイマーで更新、何か実行するたびに更新が考えられる。 ※中略  過去１０分以内の更新を検索する場合

管理視点での主なユースケース 一覧画面などで見たい。  属性を付与して管理したい。  マスタ的なもの。（住所や所属に関する情報など）  属性値でフィルタリングして画面に表示。 稼働状況を知りたい。 遠隔操作をしたい。 定期または定時などでデバイスへ指示を送りたい。 クライアントアプリをアップデートしたい。

デバイスへの通知は3パターン  C2Dメッセージを送信する。  受信側はメッセージを解析して何か処理を行う。  メッセージをいつ受信して、いつ実行するかはわからない。（非同期）  受信完了通知があるため、未受信、受信したが失敗、などが検知可能。  Desired Propertyを更新する。  こいつの基本用途はConfigのため、候補外。  ダイレクトメソッドを使う。  デバイス側に予めメソッドを実装しておく必要がある。  サービス側はメソッド名を引数に実行する為、名前を知っておく必要がある。  デバイス側でコネクションが生きていれば即座に実行される。（同期）  裏を返せばネットワーク断、電源断だと受信すらされない。  なんらかの問題が発生した場合、すぐにわかる。

C2Dメッセージのサンプル  送信側  受信側

ダイレクトメソッドのサンプル  デバイス側  ダイレクトメソッドの引数、戻り値は固定  ダイレクトメソッドを登録

ダイレクトメソッドのサンプル  サービス側  注意点  デバイスからの戻り値（JSON）には2000バイトまでの制限がある。

ダイレクトメソッドのおまけ  デバイスクライアントをWindowsServiceで実装する。  実行ユーザーをLocalSystemにし、sc createする。  コマンドプロンプトを実行するダイレクトメソッドを実装する。  これで大概のことが出来るｗ

管理視点での主なユースケース 一覧画面などで見たい。  属性を付与して管理したい。  マスタ的なもの。（住所や所属に関する情報など）  属性値でフィルタリングして画面に表示。 稼働状況を知りたい。 遠隔操作をしたい。 定期または定時などでデバイスへ指示を送りたい。 クライアントアプリをアップデートしたい。

ジョブ機能を使う 実行日時をしていしてダイレクトメソッド、ツインの更新、デ バイス全体のexport/importが可能。 クエリを使用して対象デバイスを絞ることも可能。 Freeプランの場合は１つまでしか作れない。  ジョブが終わるまでは次が作成出来ない。 過去のジョブが閲覧可能（期限はある）なため、 定期的に保存しておけば監査ログにもなる。  普通にダイレクトメソッドを呼ぶよりもジョブのほうが 運用面を考えると適している。

管理視点での主なユースケース 一覧画面などで見たい。  属性を付与して管理したい。  マスタ的なもの。（住所や所属に関する情報など）  属性値でフィルタリングして画面に表示。 稼働状況を知りたい。 遠隔操作をしたい。 定期または定時などでデバイスへ指示を送りたい。 クライアントアプリをアップデートしたい。

アプリのアップデート Azureドキュメントの目次を見るとファームアップデートとあるが 機能としては用意されていない。 いろんなものの合わせ技で実現する。  アップデート用のダイレクトメソッドを実装しておく。  Blobへファイルをアップロードする。  このファイルのSAS（Shared Access Signatures）を作成する。  ダイレクトメソッドの引数にSASを渡し、実行する。  アップデートに時間がかかる場合は戻り値を先に返しておき、 状況はReported Propertyを逐次更新する。 Download開始 ⇒ Download終了 ⇒ Update開始 ⇒ Update終了

おまけ  Blobへのファイルアップロードが簡単。  デバイス側のConfigにBlobのURLやKeyを持つ必要がない。  Azure側でIot HubとBlobコンテナの紐づけをしておくだけ。  binフォルダ覗かれても安心。  以下のようなケースで使う。  1回のメッセージサイズの制限に引っ掛かり普通のメッセージでは送れない。  ダイレクトメソッドの戻り値も同様。  1日に受信するメッセージが多すぎてお金がかかりすぎる。  データをファイルへまとめて保存し、アップロードする。  但し、リアルタイムに必要のないデータに限る。

まとめ  一覧画面などで見たい。  属性を付与して管理したい。  マスタ的なもの。（住所や所属に関する情報など）  属性値でフィルタリングして画面に表示。 ⇒デバイスツイン  稼働状況を知りたい。 ⇒ハートビート、Reported Property  遠隔操作をしたい。 ⇒ダイレクトメソッド、C2Dメッセージ  定期または定時などでデバイスへ指示を送りたい。 ⇒JOBスケジューラ  クライアントアプリをアップデートしたい。 ⇒ダイレクトメソッド、 Reported Property等の合わせ技

最後に  前回までのセッションを踏まえてIoT Hub単体の使い方は以上になります。  ここから先はデータの蓄積、分析、ML、AI、BI等に広がっていきます。  IoTをソリューションとして見たとき、ゴールはまだ先にある。  IoT Hubは安価で手軽に双方向通信基盤が作れるため、所謂IoT以外のシー ンでも是非活用していただければと思います。