SORACOM Conference Discovery 2017 | E2. IoTデバイス・デザインパターン ベストプラクティス
•
1 recomendación•1,921 vistas
スピーカー 株式会社ソラコム テクノロジー・エバンジェリスト／事業開発マネージャー 松下 享平 セッション概要 IoTの主役「デバイス」。このIoTデバイスを用いたシステムアーキテクチャ設計を行う際に発生する典型的な問題と、それに対する解決策や設計方法、およびデバイスの配置、利用するプロトコル、そしてデータの設計まで踏み込んでご紹介します。
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a SORACOM Conference Discovery 2017 | E2. IoTデバイス・デザインパターン ベストプラクティス
Similar a SORACOM Conference Discovery 2017 | E2. IoTデバイス・デザインパターン ベストプラクティス (20)
Más de SORACOM,INC
Más de SORACOM,INC (20)
SORACOM Conference Discovery 2017 | E2. IoTデバイス・デザインパターン ベストプラクティス
- 2. Platinum Gold Silver Thanks to our Sponsors LPWA
- 4. 自己紹介 松下 享平 (まつした こうへい) • 静岡県民 • 前職は東証二部ハードウェア・メーカーで IoT事業のコーディネート • 2017年3月より「テクノロジー・エバンジェリスト」 • IoTエンジニア養成読本 共同著者 • 好きなソラコムサービス • SORACOM Air メタデータサービス • SORACOM Funnel • SORACOM Air for LoRaWAN • Facebook, Twitter: ma2shita
- 6. 今日持ち帰っていただけること デバイスとクラウド間における •IoTデバイス・デザインパターン • データ集約、デバイス保守それぞれにおけるパターン • 採用メリットと条件・注意点 •伝送プロトコル、データフォーマット • 目的を達成するプロトコル・データフォーマットの採用 •運用後のデバイス稼働ヘルスチェック • 機器の死活監視だけでなくデータに着目したモニタリング
- 7. 本セッションで紹介するSORACOMサービ ス SORACOMのグローバルなインフラ 120以上の国・地域で利用可能 ライブラリ & SDKs CLI, Ruby, Swift Web インターフェース User Console データ転送支援 SORACOM Beam クラウドアダプタ SORACOM Funnel データ収集・蓄積 SORACOM Harvest プライベート接続 SORACOM Canal デバイスLAN SORACOM Gate IoT向けデータ通信 SORACOM Air Cellular (2G, 3G, LTE) / LPWA (LoRaWAN, Sigfox) 専用線接続 SORACOM Direct 仮想専用線 SORACOM Door API Web API, Sandbox データ通信 ネットワーク アプリケーション インターフェース 認証サービス SORACOM Endorse デバイス管理 SORACOM Inventory 透過型 トラフィック処理 SORACOM Junction
- 9. IoTデバイス・デザインパターン データ集約 •ダイレクト集約パターン •ゲートウェイ集約パター ン •LPWA集約パターン デバイス保守 •シェアドネット保守パ ターン •バックネット保守パター ン
- 10. 課題 インターネット接続環境が無くとも、デバイスを設 置し データの収集を行いたい • 設置環境フリーなサービスやソリューション構築 • イベント時の一時的な設置 • 既設線利用における他部門との調整
- 11. ダイレクト集約パターン デバイス自身が直接クラウドとの通信を行 う シーン • 設置環境に不確定要素が多いが、通信を確保した い 条件・注意点 • セルラー通信モデム搭載デバイスが必須 • バッテリー消費や電源運用を考慮 • クラウド接続に必要な接続情報や認証情報をデバ イスに保管する必要がある デバイス クラウド <長距離通信> セルラー
- 12. ダイレクト集約パターン 活用できるSORACOMサービス 設置環境を選ばない接続性 SORACOM Air for セルラー 日本向け Air SIM / グローバル向け Air SIM 接続情報や認証情報のオフロード SORACOM Beam / Funnel バッテリー節約や通信量削減 SORACOM Beam + UDP デバイス クラウド <長距離通信> セルラー
- 13. 設置環境を選ばない接続性 SORACOM Air for セルラーのカバレッジ 120ヵ国以上 (2017/7/5現在) https://soracom.jp/services/air/cellular/price_global/
- 14. 接続情報や認証情報等のオフロード デバイス開発の課題 • システムAに対する設定の保存 接続先情報 ID/パスワード • 暗号化実装 オンプレ システムA クラウド システムB インターネット • 保存領域の準備 • 変更が困難 • セキュリティリスク
- 15. 接続情報や認証情報等のオフロード SORACOM Beam ― データ転送支援 SORACOM Funnel ― クラウドアダプタ 本来デバイスに実装するべき接続先設定や暗号化等を SORACOMへオフロード(負荷を移動) インターネット LoRaWAN, Sigfoxの場合 送信先設定すら不要 オンプレ システムA クラウド システムB SORACOM Beam SORACOM Funnel beam.soracom.io funnel.soracom.io へ送信する実装のみでOK SORACOM BeamやFunnel上に • 接続設定 (認証情報や接続先) • 暗号化 / プロトコル変換 を保管
- 16. ダイレクト集約パターンのデバイス開発 Mini PCIeセルラー通信モジュール UC20-G (3G) / EC21-J (LTE) • 技適取得済み • UART I/F & ATコマンドで操作可能 • 1個から注文OK • 3980円 (税別・送料別) ～ ※開発ボード +アンテナ付きキットが 別売あり SORACOMコンソー ルより注文できます
- 17. 課題 インターネットへの接続機能が無いデバイスの データ収集を行いたい • BLE等の省電力プロトコル採用センサーデバイス • レガシーデバイス • RS-232C/485(Modbus)等 • SDカードスロットしかない！?
- 18. ゲートウェイ集約パターン 長距離通信機能を持つゲートウェイを設置 デバイスとは近距離通信、クラウドとは長距離通信を 利用 シーン • デバイスにセルラー通信機能を入れられないが クラウド通信を行いたい • エッジコンピューティングでデータへ価値付与や 応答速度を向上させたい 条件・注意点 • クラウド通信が可能なゲートウェイが必須 • ゲートウェイ自体には、ダイレクト集約パターンと同様の 注意点が適用される • デバイス⇔ゲートウェイ間は100m程度を目安 • ゲートウェイ集約可能なデバイス数やプロトコル クラウド ゲートウェイ <近距離通信> Wi-Fi, BLE, EnOcean, NFC, Sub-G Ethernet, RS-232C/422/485 <長距離通信> セルラー
- 20. ゲートウェイ集約パターン 活用できるSORACOMサービス 構成情報をクラウドで SORACOM Air メタデータサービス 盗難や紛失に備える SORACOM Beam / Funnel SORACOM Air IMEIロック クラウド ゲートウェイ <近距離通信> Wi-Fi, BLE, EnOcean, NFC, Sub-G Ethernet, RS-232C/422/485 <長距離通信> セルラー
- 21. 構成情報をクラウドで SORACOM Air メタデータサービス http://metadata.soracom.io/v1/(subscriber|userdata) で自分自身のSIM情報や、SORACOMコンソール上で設定した文字列を参照できる $ curl metadata.soracom.io/v1/subscriber { "imsi": "440XXXXXXXXXX73", "ipAddress": "10.XXX.XXX.XXX", "type": "s1.fast", … } $ curl metadata.soracom.io/v1/userdata This is USER-DATA in SORACOM e.g.) - SSH Public key - Bootstrap bash script
- 22. 構成情報をクラウドで SORACOM Air メタデータサービス http://metadata.soracom.io/v1/(subscriber|userdata) で自分自身のSIM情報や、SORACOMコンソール上で設定した文字列を参照できる • 起動時・定時実行のスクリプト配布 • 初回起動時の自己構成 • SSH公開鍵、EncFS等の暗号化ファイルシステムの共通鍵 • プログラムの構成情報の配布
- 24. ゲートウェイ ルーター 通信モジュール モバイル/ドングル 車載デバイス カメラ/特殊デバイス ソラコム認定デバイス – 80種類以上
- 26. LPWA集約パターン LPWAによる通信 シーン • 「デバイスは設置するだけで」を実現したい • バッテリー駆動でも数か月～数年稼働させたい • ゲートウェイ/基地局までの無線通信区間の費用を 安く上げたい 条件・注意点 • LPWA通信機能がデバイスに必須 • リアルタイム性に乏しい、利用可能なペイロード サイズが少ない • バイナリで送信されたペイロードの展開 • LPWAゲートウェイ/基地局に起因する確認事項 • LoRaWAN: ゲートウェイの設置場所や費用 • Sigfox: カバーエリア • 消費電力が大きいセンサーを取り付ける場合の 電力設計(GPS等) クラウド LPWA ゲートウェイ 基地局 <LPWA通信> LoRaWAN, Sigfox <長距離通信> セルラー
- 27. LPWA集約パターン 活用できるSORACOMサービス LPWAサービス SORACOM Air for LoRaWAN SORACOM Air for Sigfox データペイロードの展開 バイナリパーサー クラウドやアプリケーション開発の省力化 SORACOM Beam / Funnelクラウド LPWA ゲートウェイ 基地局 <LPWA通信> LoRaWAN, Sigfox <長距離通信> セルラー NEW NEW
- 28. LPWAデバイス SORACOM Air for Sigfox NEW Sens’it オプテックス株式会社 ドライ コンタクト コンバーター Sigfox Shield for Arduino SORACOMコンソールで 注文可能 SORACOMコンソールで 注文可能 SORACOM Air for LoRaWAN STマイクロエレクトロニクス STM32L0 Discovery kit LoRa (B-L072Z-LRWAN1) MultiTech MultiConnect® mDot™ 株式会社Braveridge BVMLRS923N52S SORACOMコンソールで 注文可能 SORACOMコンソールで 注文可能 Arduino UNO R3向け LoRaWANシールド AL-050 株式会社GISupply LT-100
- 29. データペイロードの展開 バイナリパーサー クラウド側 データ展開の手間軽減 { "distance": 19, "sensor_id": 2 } 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0bit 0byte 0 ~ 31 (e.g. 物体までの距離) 0~7 (e.g. センサーID) BIN 1 0 0 1 1 0 1 0 NEW distance:0:uint:5:7 sensor_id:0:uint:3:2 デバイス側 ペイロード節約、CPU負荷低減
- 30. 課題 SORACOM Airでつながっているデバイスに 外から “安全” にアクセスして制御したい
- 31. シェアドネット保守 パターン データ送受信と保守の回線を共用 シーン • シンプルかつ安価な管理を行いたい 条件・注意点 • データ送受信トラフィックの状況によっては保守 できなくなるケースあり • 信頼できないネットワークにおいてはアンチパ ターンと同等になるため、閉域網内を強く推奨 デバイス クラウド データ 保守時 デバイス ゲートウェイ 保守時
- 32. バックネット保守 パターン セルラー通信を保守の回線として利用 シーン • トラフィックに左右されない確実な保守回線を用 意したい • すでに運用中システム対して保守の仕組みを後か ら組み込みたい • LPWAなどの細い回線、信頼できないネットワー クを経由する等、データ回線を保守に利用できな い場合 条件・注意点 • データ回線のほか保守回線の費用が必要 デバイス クラウド データ デバイス ゲートウェイ 保守時 保守時
- 33. MQTT Subscribeによるリモートメンテナン ス 接続はデバイス側からが起点 • デバイス起動時や切断検出時における接続維持処理が必須 MQTT::Client.connect(CONNECT_PARAMS) do |c| c.get("cmd_topic/my_device") do |_, msg| case msg when "report" `send_to_report` when "reboot" `shutdown -r now` end ゲートウェイ デバイス MQTT/MQTTS MQTT MQTTS SORACOM Beam mqtt_pub "report" mqtt_pub "reboot" クラウド Azure IoT Hub MQTT Broker AWS IoT GCP IoT Core
- 34. クラウドからのリモートメンテナンス SORACOM Gate VPG Canal (Amazon VPC) Direct (専用線) Door (VPN) VXLAN Gate接続サーバ L2サブネット SORACOM Gate 10.x.x.A 10.x.x.B 10.x.x.Z VPG NAPT デバイス側 クラウド側 ssh等
- 35. SORACOM Air / IPアドレスの特定 SORACOM管理コンソールから $ soracom subscribers list --serial-number-filter DXXXX0 | jq -r .[].ipAddress 10.XXX.XXX.XXX soracom-cli (API)から
- 36. SORACOM Inventory • OMA LightweightM2M(LwM2M)をベースにした デバイス管理フレームワークを提供するサービス • SORACOM Airと連携した、デバイスの自動登録機能を提供 Inventory クライアント Inventory サーバ LwM2M NEW
- 38. アンチパターン グローバルIPアドレスによるリモート保守 • デバイスにサーバ並みのセキュリティを 施す必要あり • フィルタリング • DDoSアタック対策 • グローバルIP割り当て可能なMVNO限定 • グローバルIP≠固定IP • IP確認に外部サービスが必要な ケース • オプション料金の場合も 簡単ではあるが、運用コストが高い クラウド グローバルIP
- 40. 課題 データサイズは極力小さく でも、クラウド側でのデータの扱いは容易なものにし たい • LoRaWAN, Sigfox等のLPWAにおけるペイロード設計 • SORACOM Air for セルラー “Low Data Volume”
- 41. プロトコルヘッダサイズ HTTP MQTT TCP UDP 最小ヘッダサイズ 50 2 ― ― L4ヘッダサイズ 20 20 20 8 計 70 22 20 8 http://ossforum.jp/jossfiles/05_03_application.pdf 単位: byte ※TLS(DTLS)の場合はKbyte単位で増加 1分に1回のデータ送信 (ヘッダのみ) HTTP: 60秒 × 24時間 × 30日 × 70byte = 約3.0MB / 月 UDP: 60秒 × 24時間 × 30日 × 8byte = 約0.3MB / 月
- 42. SORACOM Air for セルラー Low Data Volume https://blog.soracom.jp/blog/2017/05/22/how-to-buy-and-use-lowdatavolume/ 数バイト/日 のユースケース 0.4USD/month ~ =約45円/月 ~ 通信量 (KiB/月) 通信料金(円/月)
- 43. LPWAペイロードサイズ LoRaWAN Sigfox ペイロードサイズ (1送信) 11 ~ 242 byte 12 byte
- 44. ペイロードフォーマットによるサイズと課 題 デバイス側 ペイロード節約、CPU負荷低減 クラウド側 データの展開の手間 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0bit 0byte 0 ~ 31 (e.g. 物体までの距離) 0~7 (e.g. センサーID) BIN 1 0 0 1 1 0 1 0 デバイス側 ペイロードサイズ、コーディング量やCPU負荷 クラウド側 データの利便性 { "distance": 19, "sensor_id": 2 } 29 byte 1 byte バイナリフォーマット テキストベースフォーマット (JSON等)
- 46. プロトコル選定の課題 モノ センサー、デバイス クラウド アプリケーション • クラウドが受け付けられるプロトコルを優先的に採用 • HTTPやMQTTといったTCPベースのL7プロトコル • DCからクラウドまでのセキュリティを確保するためにTLSが必 須 • Kbyte単位でのデータサイズ増 • デバイス⇔DC間は本来必要が無い セキュア セキュアでない DC基地局 この区間のために デバイスでTLSが必要 HTTP REST等
- 47. プロトコル選定 モノ センサー、デバイス クラウド アプリケーション • クラウドの受信可能プロトコル制約が無くなる • SORACOM Beam / Funnel が変換してくれる • UDPですら選択肢に入れられる • セキュアでない区間のセキュリティを確保はSORACOM Beam / Funnelが負 担 • デバイスでのTLS化は一切不要 セキュア セキュアでない 基地局 SORACOM Beam SORACOM Funnel 簡素なプロトコル が利用可能
- 48. セルラーネットワークにおけるUDPの信頼 性 NTT DOCOMO テクニカル・ジャーナル Vol.19 No.1 高速・大容量・低遅延を実現するLTEの無線方式概要 ＮＴＴドコモ 無線アクセス開発部 大久保尚人 ウメシュアニール 岩村幹夫 新博行 P17 図9 より https://www.nttdocomo.co.jp/binary/pdf/corporate/technology/rd/technical_journal/bn/vol19_1/vol19_1_011jp.pdf DC基地局デバイス 下位レイヤにて再送等の信頼性が確保 実際のデータ 基地局⇔DC間が UDP伝送
- 49. UDP選択指針 •ペイロードサイズが1472オクテットに収まる • フラグメント処理をする場合はTCPベースプロトコルを •サーバからのレスポンスが不要 • UDPでもレスポンスは受けられるが、確実性を求めるなら ばTCPベースプロトコルを •SORACOM BeamやSORACOM Funnelが利用できる • SORACOM Beamはレスポンスを省略するオプションあり → 下りのデータサイズ削減に寄与
- 50. ペイロード設計 項目 取りうる値 センサーID 0 ~ 3 物体までの距離 (cm) 0 ~ 30 [3,30] 6 byte JSON 0x92031F MessagePack 3 byte 独自フォーマット 1 byte • クラウド側で扱いやすい • デバイスによっては生成コストが高い • クラウド・デバイス双方で そこそこ扱いやすい • 徹底した削減までとはいかない • デバイスでの生成コストが低い • クラウドでの扱いが極めて困難 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0bit 0 ~ 30 (幅的には31まで) 0~3 (幅的には7まで) 0 1 2 3
- 51. データペイロードの展開 バイナリパーサー クラウド側 データ展開の手間軽減 { "distance": 19, "sensor_id": 2 } 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0bit 0byte 0 ~ 31 (e.g. 物体までの距離) 0~7 (e.g. センサーID) BIN 1 0 0 1 1 0 1 0 NEW distance:0:uint:5:7 sensor_id:0:uint:3:2 デバイス側 ペイロード節約、CPU負荷低減
- 53. モニタリング種別 ハードウェア/OS、ネットワークの動作状況 正常 障害発生 プログラムの動作状況 正常 検知が容易 検知が容易 障害発生 プロセス自体のクラッシュは 検知が可能 プロセスは動いているが データが送信に失敗 検知が容易 ※ハードウェア/OSに障害があれ ば、プログラムにも障害が発生 する 様々な手法が すでに存在 モニタリングが難しい
- 54. “データ”に着目したモニタリング手法 • モニタリングミドルウェアの利用 • Zabbixの nodata関数 • ストリーミングデータ・リアルタイム 分析 • Stream Analytics、Kinesis Analytics → ウィンドウ関数、JOIN等 • 特徴量分析による欠損値補完 • パケット・インスペクション • SORACOM Junction トラフィックの統計情報、 パケットミラーリングを利用した分析や アラートトリガー Azure Stream Analytics クエリ SELECT t1.time, t1.dspl AS SensorName INTO output FROM InputStream t1 TIMESTAMP BY time LEFT OUTER JOIN InputStream t2 TIMESTAMP BY time ON t1.dspl=t2.dspl AND DATEDIFF(second,t1,t2) BETWEEN 1 and 5 WHERE t2.dspl IS NULL https://docs.microsoft.com/ja-jp/azure/stream-analytics/stream-analytics-get-started- with-azure-stream-analytics-to-process-data-from-iot-devices NEW
- 55. まとめ • IoTデバイス・デザインパターン • データ集約、デバイス保守で課題とパターンが決まっている • 採用メリットと条件・注意点に気を付ける • 伝送プロトコル、データフォーマット • 目的を達成するプロトコル・データフォーマットの採用 • デバイス側・クラウド側双方協力し合って設計を行う • デバイス側 = バイナリ、クラウド側 = JSON • 運用後のデバイス稼働ヘルスチェック • 死活監視だけでなくデータに着目したモニタリングを実施 用途に合ったサービス選定を！