IoTシステムの双方向データフローにおける設計と実装の複雑さを解消する手法の提案 / Proposal to Eliminate the Complexity of Design and Implementation in The Bidirectional Dataflow of IoT Systems

Transcript

1. IoTシステムの双方向データフローにおける設 計と実装の複雑さを解消する手法の提案 栗林健太郎（GMOペパボ / 北陸先端科学技術大学院大学） 三宅悠介（GMOペパボ） 力武健次（GMOペパボ / 力武健次技術士事務所） 篠田陽一（北陸先端科学技術大学院大学）

   発表者: 栗林健太郎 第14回インターネットと運用技術シンポジウム(2021.11.25-26) 1

2. 2 目次 1. 背景と課題 2. 関連研究 3. 提案手法 4. 評価

   5. おわりに

3. 3 1. 背景と課題

4. Application Network Perception Application Middleware Processing Transport Perception クラウド層 エッジ層

   デバイス層 3層モデル 5層モデル 本研究の 想定するモデル - 物理空間上のデータのセンシングと上位 層への送信 - 上位層からの指示に基づく物理空間への アクチュエーション - データに対する各種の処理（整形，加 工，拡張等） - デバイス層に近い場所での計算処理 - データの分析と情報の生成 - IoTシステムのユーザへのサービス提供 - 物理空間上のデバイスへのアクチュエー ション指示 4 1. 背景と課題 IoTシステムはデバイス層，エッジ層，デバイス層の3層構造を採る 図の出典：Bansal, Sharu, and Dilip Kumar. 2020. “IoT Ecosystem: A Survey on Devices, Gateways, Operating Systems, Middleware and Communication.” International Journal of Wireless Information Networks 27 (3): 340–64.を参考に筆者が作成

5. クラウド層 エッジ層 デバイス層 5 1. 背景と課題 課題① プログラミング言語や通信プロトコルの選択肢が多様である ①各層をどのような言語で 設計・実装するか

   • 各層は，それぞれに設 計・実装言語への要求内 容が異なる • 一方で，言語が異なると 学習コストがそれぞれに 対してかかる ②各層間の通信プロトコル に何を用いるか • 左記で選択した言語で扱 いやすいプロトコルであ ることが望ましい • また，セキュリティを担 保できることも必須

6. クラウド層 エッジ層 デバイス層 6 1. 背景と課題 課題② データフローの種別が多様かつ双方向性を持つ ①デバイス層からどのよう にデータを収集するか

   • どの層がデータ取得の起 点になるかはシステム要 件によって異なる • また、定期的に取得する か、必要に応じて取得す るかも要件次第 ②通信の双方向性をどう実 現するか • デバイス層の上位層から のアクチュエーション指 示を可能にする • 双方向なデータフローが 必要になる データの出所

7. デバイス層 エッジ層 クラウド層 7 1. 背景と課題 課題③ IoTシステムの全体を通じたデータフローの見通しが悪くなる ① 課題②で述べたデータ取得方式＋双方向ネットワークの定義

   ② エッジ層におけるデータ処理の記述（データに対する整形，加工，拡張等） 各層でバラバラに定義すると，複雑かつ全体の見通しがきかない記述になってしまう． 3層間におけるデータフローを記述するために必要な要素

8. 1. 背景と課題 8 本研究の目的は，3つの課題すべてを解決する手法を提案すること 課題 提案 ① プログラミング言語や通信プロトコル の選択肢が多様である 3層を同一のプログラミング言語と通

   信プロトコルを用いて統合的に設計・ 実装できる手法 ② データフローの種別が多様かつ双方向 性を持つ push，pull，demand方式のいずれに も対応し，使い分けられる基盤 ③ IoTシステムの全体を通じたデータフ ローの見通しが悪くなる 3層からなるデータフローを一望のも とに把握できる記法

9. 9 2. 関連研究

10. 10 2. 関連研究 課題①に対する関連研究の検討と整理 ①各層をどのような言語で設計・実装するか ②各層間の通信プロトコルに何を用いるか 単一の言語と通信プロトコルのよってIoTシステムを統合 的に設計・実装できる取り組みとしてTinyLink2.0，お よび，Cross-site Edge

    Framework（CEF，右図）があ る TinyLink2.0: Guan, G., et.al.. “TinyLink 2.0: Integrating Device, Cloud, and Client Development for IoT Applications.” MobiCom2021. CEF: Nakata, Y., et.al.. “Cross-Site Edge Framework for Location-Awareness Distributed Edge-Computing Applications.” MobileCloud2020. 右図の出典：上記CEFの論文 IoTシステムのアプリケーション層で用いられるプロトコ ル：HTTP，CoAP，MQTT，AMQP，XMPP，DDS Al-Masri, E., et.al.. “Investigating Messaging Protocols for the Internet of Things (IoT).” IEEE Access 8: 94880–911. 課題① プログラミング言語や通信プロトコルの選択肢が多様である 対応する課題

11. 11 2. 関連研究 課題②に対する関連研究の検討と整理 図の出典：Mitra, K., et.al.. “Context-Aware IoT-Enabled Cyber-Physical

    Systems: A Vision and Future Directions”, pp. 1–16, Springer International Publishing (2020).などを参考に筆者が作成 デバイス層 エッジ層 クラウド層 ① Push方式 ② Pull方式 ① デバイス層がデータを送信 ① デバイス層へデータ送信を要求 ② 要求に応じて上位層へデータ送信 ③ Demand方式 ① デバイス層へデータ送信を要求 ② 要求に応じて上位層へデータ送信 ①データ取得方式 ②通信の双方向性 どの方式でも通信は双方向性を持ち得る MQTT等のPub-Sub方式で は，組み合わせによって pushおよびpull方式，双方 向通信を実現すること自体 は可能 課題② データフローの種別が多様かつ双方向性を持つ 対応する課題

12. 12 2. 関連研究 課題③に対する関連研究の検討と整理 右図の出典：上記DDF/D-NRの論文 見通しの良いデータフローの記述 Node-Redは，IoTシステムにおけるデータフローをビ ジュアルプログラミングによって見通しの良い形で実装 するためのWebアプリケーション． Node-Redを拡張したDistributed

    DataFlow(DDF、右 上図)，および，Distributed Node-Red（D-NR、右下 図）は，IoTシステム全体におけるデータフローを記述可 能とすることで，Node -Redの課題を解消する． Node-Red: “Node-RED.” https://nodered.org/. DDF/D-NR: Giang, N., et.al.. “Developing IoT Applications in the Fog: A Distributed Dataflow Approach.” IOT2015. 課題③ IoTシステムの全体を通じたデータフローの 見通しが悪くなる 対応する課題

13. 13 2. 関連研究 本研究の目的は，3つの課題すべてを解決する手法を提案すること 課題 関連研究による解決 本研究の目的 ① プログラミング言語や通信プ ロトコルの選択肢が多様であ

    る TinyLink2.0，CEF 課題1のみなら有力な解決策 3つの課題をすべて解決する 手法を提案する ② データフローの種別が多様か つ双方向性を持つ TinyLink2.0，CEF，DDF/D- NR push, pull, 双方向性を実現可能 (Websocket, Pub-Sub)ではあるが demand方式に対応していない ③ IoTシステムの全体を通じた データフローの見通しが悪く なる Node-Red，DDF/D-NR ただし，Node-Redは3層を統合す る実装は不可

14. 14 3. 提案手法

15. 15 3. 提案手法 提案① 3層を同一のプログラミング言語と通信プロトコルを用いて統合的に設計・実装できる手法 ※ Pratipadは筆者らが開発したフレームワークである． 課題① プログラミング言語や通信プロトコルの選択肢が多様である 対応する課題

    デバイス層 エッジ層 クラウド層 プログラミング言語 通信プロトコル Elixir Nerves https://www.nerves- project.org/ Pratipad※ https://github.com/ kentaro/pratipad/ Phoenix https:// phoenixframework.org フレームワーク 分散Erlangネットワークプロトコル Elixirの実行基盤であるErlang/OTPが提供する言語組み込みのプロトコル さらに，TLS通信とクライアント証明書認証で各層を繋ぐことでセキュアな通信 んを実現

16. 16 3. 提案手法 提案② push，pull，demand方式のいずれにも対応し，使い分けられる基盤 課題② データフローの種別が多様かつ双方向性を持つ 対応する課題

17. 17 3. 提案手法 提案③ 3層からなるデータフローを一望 のもとに把握できる記法 課題③ IoTシステムの全体を通じたデー タフローの見通しが悪くなる 対応する課題

    Push <~> P1 <~> P2 <~> P3 <~> Output defmodule P1 do alias Pratipad.Processor use Processor @impl GenServer def init(initial_state) do %{:ok, initial_state) end @impl Processor def process(message, state) do # do something with the message end end データフロー定義 プロセッサ定義 種別 記法 概要 入力 Push Pull Demand Pushモード Pullモード Demandモード 処理 P [P1, P2, …, PN] {P1, P2, …, PN} 単一のプロセッサ 順次適用する複数のプロセッサ 並列適用する複数のプロセッサ 方向 ~> <~> データフローは単方向 データフローは双方向

18. 18 4. 評価

19. 19 4. 評価 評価① 提案手法を用いて実用的なIoTシステムを構築できることを示した(1/2) 提案① 3層を同一のプログラミング言語と通信プロトコルを用いて統合的に設計・実装できる手法 対応する提案 部屋1 部屋2

    LAN エッジ層 デバイス層 デバイス層 住居 WAN センシング - CO2濃度 - 気圧 - 湿度 クラウド層 - 可視化 - 分析 - アクチュエーショ ン指示の実行 外部API - 追加情報の付与 (例：雨量等) 利用者 - 状況の把握 - 状況に応じた行動 (例：窓を開ける) Pratipad経由 の通信 (mTLS通信) - データ取集 - 加工 - 情報の追加 ･･･ Elixirで動作 クラウド層からのアクチュエーション指示に基づき，LEDが転倒（「窓を開けろ！」のサイン）

20. 20 4. 評価 評価① 提案手法を用いて実用的なIoTシステムを構築できることを示した(2/2) 提案① 3層を同一のプログラミング言語と通信プロトコルを用いて統合的に設計・実装できる手法 対応する提案 層の種別 システム要件

    実装（言語はすべてElixir） セキュリティ デバイス層 室内環境(CO2濃度，温度，湿度，気 圧)の計測とエッジ層への送信. クラウド層からのアクチュエーション 指示によって，利用者に通知 Raspberry Pi Zero W Nerves(Linuxベース) 通信経路はTLSにより暗 号化した 各層間の通信における認 証にはクライアント証明 書を用いた エッジ層 送信されたデータに対して，外部API を活用して雨量情報を付与したのち， クラウド層へ送信． iMac(24inch, M1, 2021) macOS クラウド層 送信されたデータに基づき，窓を開け るべきかどうかを判断（CO2濃度が一 定以上で雨量が一定いかの場合）し， デバイス層へ通知． Raspberry Pi 4 Model B Raspberry Pi OS ※ 実験環境のネットワークの都合上，パブリッ ククラウドを用いることができなかったため代 用

21. 21 4. 評価 評価② 3つのデータ取得方式と双方向性対応で広い要件を満たせることを示した データフロー記述(提案③)と各層で利用するプロトコルの変更のみで以下を容易に使い分けられる． 提案② push，pull，demand方式のいずれにも対応し，使い分けられる基盤 対応する提案 課題

    概要 利点 Push方式 デバイスが取得可能なセンサーデータを余すことなく送 信できる デバイス層において取得したデータの時間分解能の高さ が求められる場合 Pull方式 クラウド層が提供するユーザー向けのアプリケーション に必要なだけのデータを取得できる ユーザーへ提供するサービ スレベルに応じてデータの流 量を制御できることが求められる場合 Demand方式 データ処理を行うエッジ層の余力に応じてデータフロー の流量を制御しつつデータを取得できる リソース制約のもとでの高い可用性が求められる場合 双方向性 上述のいずれの方式についても双方向通信が可能 要件の変更を見据えて，容易に双方向性に対応できる方 式を用いることが可能

22. 22 4. 評価 評価③ 3層におけるデータフローパター ンを全て記述できることを示した • 3つのデータ取得方式に双方向性を加え たデータフローのパターンは5種類であ り，提案手法ですべて記述可能（pull方

    式では単方向は存在しない．右上図） • エッジ層におけるプロセッサーの記述 についても，あり得る4パターンをすべ て記述可能（右下図） 提案③ 3層からなるデータフローを一望 のもとに把握できる記法 対応する提案

23. 23 5. おわりに

24. 5. おわりに 24 本研究のまとめ 課題 提案 評価 ① プログラミング言語や通信 プロトコルの選択肢が多様

    である 3層を同一のプログラミング 言語と通信プロトコルを用 いて統合的に設計・実装で きる手法 提案手法を用いて実用的な IoTシステムを構築できるこ とを示した ② データフローの種別が多様 かつ双方向性を持つ push，pull，demand方式の いずれにも対応し，使い分 けられる基盤 3つのデータ取得方式と双方 向性対応で広い要件を満た せることを示した ③ IoTシステムの全体を通じた データフローの見通しが悪 くなる 3層からなるデータフローを 一望のもとに把握できる記 法 3層におけるデータフローの パターンを全て記述できる ことを示した 背景: IoTシステムはデバイス層，エッジ層，デバイス層の3層構造を採る．

25. 5. おわりに 25 課題と今後の展望 IoTプラットフォームを構築し得る内容に，本研究を発展させたい． • クライアント証明書をデバイスへ効率的に配布できること • 各層の実装に対する変更の効率的かつ安全に適用できること •

    不特定多数の利用者に対してマルチテナントな基盤の提供が可能となること 今後の展望 • 提案手法に対する定量的な評価（システム要件に対するパフォーマンス等） • 提案手法のような統合的な手法が，現実のIoTシステムの複雑さをカバーし得るか 課題

26. 26 Thank You! 発表は以上です