IoTシステムの双方向データフローにおける設計と実装の複雑さを解消する手法の提案 / Master's Thesis Examination

北陸先端科学技術大学院大学博士前期課程修士論文審査会（2022年2月6日14時55分〜15時20分）

（続き）双方向データフローに基づくインテリジェントなIoTシステムを実現するための研究
https://speakerdeck.com/kentaro/my-research-plan-for-the-doctoral-course?slide=11

Transcript

1. IoTシステムの双方向データフローにおける設計 と実装の複雑さを解消する手法の提案 栗林健太郎（2030006）北陸先端科学技術大学院大学博士前期課程 修士論文審査会（2022年2月6日14時55分〜15時20分） 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/prat ipad/ 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種類※．そのため ，提案手法ですべて記述可能（右上図） • エッジ層におけるプロセッサーの記述につい ても，あり得る4パターンをすべて記述可能 （右下図） 提案③ 3層からなるデータフローを一望のも とに把握できる記法 対応する提案 ※ クラウド層からデバイス層へ送信指示を行うPull方式では，単方向は定義上存在しないため．
23. 23 5. おわりに
24. 5. おわりに 24 本研究のまとめ 課題 提案 評価 ① プログラミング言語や通信プロ トコルの選択肢が多様である 3層を同一のプログラミング言 語と通信プロトコルを用いて統 合的に設計・実装できる手法 提案手法を用いて実用的な IoTシステムを構築できること を示した ② データフローの種別が多様か つ双方向性を持つ push，pull，demand方式のい ずれにも対応し，使い分けら れる基盤 3つのデータ取得方式と双方 向性対応で広い要件を満たせ ることを示した ③ IoTシステムの全体を通じた データフローの見通しが悪くな る 3層からなるデータフローを一 望のもとに把握できる記法 3層におけるデータフローのパ ターンを全て記述できることを 示した 背景: IoTシステムはデバイス層，エッジ層，デバイス層の 3層構造を採る．
25. 5. おわりに 25 課題と今後の展望 インテリジェントなIoTシステムを構築するための基盤として，本研究を発展させたい． • 提案手法を大規模なシステムに応用可能なパフォーマンス改善と定量評価 • 各層の実装に対する開発者による変更を，効率的かつ安全に適用できること • デバイス層における推論のために，クラウド層で学習したモデルの効率的な配備 今後の展望 • 提案手法に対する定量的な評価（システム要件に対するパフォーマンス等） • 提案手法のような統合的な手法が，現実の IoTシステムの複雑さをカバーし得るか 課題