Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Azure IoT Hubのススメ ~デバイス管理編~

motoriderse
February 06, 2018

Azure IoT Hubのススメ ~デバイス管理編~

2017/8/26
IoTに限らず遠隔地にあるクライアント(デバイス)を管理することは大変です。本セッションでは実戦で想定されるシナリオに対しIoT Hubに備わる管理機能でどう対応するか等を実務経験を踏まえながら解説します。

motoriderse

February 06, 2018
Tweet

More Decks by motoriderse

Other Decks in Programming

Transcript

  1. おさらい(よく出る用語集)  デバイス  IoT Hubに接続するPC的なもの(なんでもいい)  サービス  バックエンドの管理などのこと

     C2D  Cloud To Device の略  D2C  Device To Cloud の略  IDレジストリ  デバイスの識別情報を保管しておくところ  デバイスツイン  デバイス管理用のプロパティ
  2. 該当する機能は大きく分けて二つ  デバイスの状態情報を操作する。(日本語訳がこうなので。。。)  デバイスIDを指定する。(1台分だけ)  デバイスIDを指定しない。(1000台まで取得可能) 条件指定は出来ない為、1001台目以降は一覧取得できない。。。 ⇒SDKの仕様ではなくIoT Hubの仕様。(意味不明)

     認証関連もここに含まれる。  デバイスツイン(JSON型)にCRUD操作とクエリ発行が可能。  クエリも投げられる。  メタデータはいじれない。  上記の状態情報とは別物。(わかりにくい)  違いがわかりにくい。
  3. デバイスの状態情報とやらを覗いてみる  デバイス取得用メソッド クライアントのソケット開閉状態で ConnectedとDisconnectedが リアルタイムで切り替わるので便利。 Azureのドキュメントには 開発時以外は参照しないでと書いてあります。 理由はこのクラスにはクエリが実行できないから。 

    デバイスクラス 1000まで! ページングも無い メモ的に自由な文字列が保存できる。 例)撤去のため停止、など Disableにするとデバイスが持つ認証情報が 有効であってもコネクションが張れなくなる。
  4. デバイスツインとは  簡易DocumentDBのようなもの。  JSON型  XML DBと比べて軽くてクエリがシンプル。  xpathとかxqueryとか面倒だった。。。

     デバイス側、サービス側とで権限などが異なる。  どこがどう違うのかをしっかり理解して設計する必要がある。  JSON配列は保存できない。  どうしてもやりたければサイズ制限内でうまくやるしかない。  楽観的実行制御を使用。  デバイスから見たとき、競合相手がいないので意識することはないが サービス側は複数人が触る可能性があるため注意が必要。
  5. 各項目の使い方とか •その名の通り、一般的な「タグ」の解釈で良い。 •階層化も可能。 •デバイスからは見えない為、デバイスに必要となる情報はここに入れない。 •デバイスへの変更通知も無いため、好きなタイミングで変更できる。 Tags •サービスがデバイスの構成を同期するため使用する。 例)送信間隔:5分など •デバイスからは読み取り専用な為、安全。 •プロパティの変更はリアルタイムで通知される。(イベントが発火する)

    Desired •デバイスがサービスと状態を同期するために使用する。 例)”起動時刻”:”HH:mm:ss”, ”アップデート”:”ダウンロード済み” •プロパティの変更はリアルタイムで通知される。(イベントが発火する) •サービス側ではクエリを発行し状態を確認する。 例)SELECT * FROM DEVICES WHERE properties.reported.updateStatus = ‘downloaded’ Reported
  6. クエリの基本  FROM句は「devices」固定。  オブジェクト型なのでSELECT句、WHERE句ともに「◦◦. ◦◦ 」と書く。 SELECT tags.location.region FROM

    devices WHERE tags.location.plant = ‘Redmond43’  AS,IN,GROUP BY も使える。  関数もある。 一般的な集計関数(sum,maxなど)、文字列操作(CONCAT,SUBSTRING) などなど
  7. デバイスへの通知は3パターン  C2Dメッセージを送信する。  受信側はメッセージを解析して何か処理を行う。  メッセージをいつ受信して、いつ実行するかはわからない。(非同期)  受信完了通知があるため、未受信、受信したが失敗、などが検知可能。 

    Desired Propertyを更新する。  こいつの基本用途はConfigのため、候補外。  ダイレクトメソッドを使う。  デバイス側に予めメソッドを実装しておく必要がある。  サービス側はメソッド名を引数に実行する為、名前を知っておく必要がある。  デバイス側でコネクションが生きていれば即座に実行される。(同期)  裏を返せばネットワーク断、電源断だと受信すらされない。  なんらかの問題が発生した場合、すぐにわかる。
  8. アプリのアップデート Azureドキュメントの目次を見るとファームアップデートとあるが 機能としては用意されていない。 いろんなものの合わせ技で実現する。  アップデート用のダイレクトメソッドを実装しておく。  Blobへファイルをアップロードする。  このファイルのSAS(Shared

    Access Signatures)を作成する。  ダイレクトメソッドの引数にSASを渡し、実行する。  アップデートに時間がかかる場合は戻り値を先に返しておき、 状況はReported Propertyを逐次更新する。 Download開始 ⇒ Download終了 ⇒ Update開始 ⇒ Update終了
  9. おまけ  Blobへのファイルアップロードが簡単。  デバイス側のConfigにBlobのURLやKeyを持つ必要がない。  Azure側でIot HubとBlobコンテナの紐づけをしておくだけ。  binフォルダ覗かれても安心。

     以下のようなケースで使う。  1回のメッセージサイズの制限に引っ掛かり普通のメッセージでは送れない。  ダイレクトメソッドの戻り値も同様。  1日に受信するメッセージが多すぎてお金がかかりすぎる。  データをファイルへまとめて保存し、アップロードする。  但し、リアルタイムに必要のないデータに限る。
  10. まとめ  一覧画面などで見たい。  属性を付与して管理したい。  マスタ的なもの。(住所や所属に関する情報など)  属性値でフィルタリングして画面に表示。 ⇒デバイスツイン

     稼働状況を知りたい。 ⇒ハートビート、Reported Property  遠隔操作をしたい。 ⇒ダイレクトメソッド、C2Dメッセージ  定期または定時などでデバイスへ指示を送りたい。 ⇒JOBスケジューラ  クライアントアプリをアップデートしたい。 ⇒ダイレクトメソッド、 Reported Property等の合わせ技