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
   

   View Slide

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

   View Slide

3. 3
   1. 背景と課題
   

   View Slide

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.を参考に筆者が作成
   

   View Slide

5. クラウド層
   エッジ層
   デバイス層
   5
   1. 背景と課題
   課題① プログラミング言語や通信プロトコルの選択肢が多様である
   ①各層をどのような言語で設
   計・実装するか
   ● 各層は，それぞれに設計・
   実装言語への要求内容が
   異なる
   ● 一方で，言語が異なると学
   習コストがそれぞれに対し
   てかかる
   ②各層間の通信プロトコルに
   何を用いるか
   ● 左記で選択した言語で扱
   いやすいプロトコルである
   ことが望ましい
   ● また，セキュリティを担保で
   きることも必須
   

   View Slide

6. クラウド層
   エッジ層
   デバイス層
   6
   1. 背景と課題
   課題② データフローの種別が多様かつ双方向性を持つ
   ①デバイス層からどのように
   データを収集するか
   ● どの層がデータ取得の起
   点になるかはシステム要
   件によって異なる
   ● また、定期的に取得する
   か、必要に応じて取得する
   かも要件次第
   ②通信の双方向性をどう実
   現するか
   ● デバイス層の上位層から
   のアクチュエーション指示
   を可能にする
   ● 双方向なデータフローが必
   要になる
   データの出所
   

   View Slide

7. デバイス層 エッジ層 クラウド層
   7
   1. 背景と課題
   課題③ IoTシステムの全体を通じたデータフローの見通しが悪くなる
   ① 課題②で述べたデータ取得方式＋双方向ネットワークの定義
   ② エッジ層におけるデータ処理の記述（データに対する整形，加工，拡張等）
   各層でバラバラに定義すると，複雑かつ全体の見通しがきかない記述になってしまう．
   3層間におけるデータフローを記述するために必要な要素
   

   View Slide

8. 1. 背景と課題
   8
   本研究の目的は，前述した3つの課題すべてを解決する手法を提案すること
   課題 提案
   ①
   プログラミング言語や通信プロトコルの選
   択肢が多様である
   3層を同一のプログラミング言語と通信プ
   ロトコルを用いて統合的に設計・実装でき
   る手法
   ②
   データフローの種別が多様かつ双方向性
   を持つ
   push，pull，demand方式のいずれにも
   対応し，使い分けられる基盤
   ③
   IoTシステムの全体を通じたデータフロー
   の見通しが悪くなる
   3層からなるデータフローを一望のもとに
   把握できる記法
   

   View Slide

9. 9
   2. 関連研究
   

   View Slide

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.
    課題① プログラミング言語や通信プロトコルの選択肢が多様である
    対応する課題
    

    View Slide

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方式，双方向通信
    を実現すること自体は可能
    課題② データフローの種別が多様かつ双方向性を持つ
    対応する課題
    

    View Slide

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システムの全体を通じたデータフローの見通
    しが悪くなる
    対応する課題
    

    View Slide

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層を統合する
    実装は不可
    

    View Slide

14. 14
    3. 提案手法
    

    View Slide

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通信とクライアント証明書認証で各層を繋ぐことでセキュアな通信んを実現
    

    View Slide

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

    View Slide

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}
    単一のプロセッサ
    順次適用する複数のプロセッサ
    並列適用する複数のプロセッサ
    方向
    ~>
    <~>
    データフローは単方向
    データフローは双方向
    

    View Slide

18. 18
    4. 評価
    

    View Slide

19. 19
    4. 評価
    評価① 提案手法を用いて実用的なIoTシステムを構築できることを示した(1/2)
    提案① 3層を同一のプログラミング言語と通信プロトコルを用いて統合的に設計・実装できる手法
    対応する提案
    部屋1
    部屋2
    LAN
    エッジ層
    デバイス層
    デバイス層
    住居
    WAN
    センシング
    - CO2濃度
    - 気圧
    - 湿度
    クラウド層
    - 可視化
    - 分析
    - アクチュエーション指
    示の実行
    外部API
    - 追加情報の付与
    (例：雨量等)
    利用者
    - 状況の把握
    - 状況に応じた行動
    (例：窓を開ける)
    Pratipad経由
    の通信
    (mTLS通信)
    - データ取集
    - 加工
    - 情報の追加
    ･･･ Elixirで動作 クラウド層からのアクチュエーション指示に基づき，LEDが点灯（「窓を開けろ！」のサイン）
    

    View Slide

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
    ※ 実験環境のネットワークの都合上，パブリックク
    ラウドを用いることができなかったため代用
    

    View Slide

21. 21
    4. 評価
    評価② 3つのデータ取得方式と双方向性対応で広い要件を満たせることを示した
    データフロー記述(提案③)と各層で利用するプロトコルの変更のみで以下を容易に使い分けられる．
    提案② push，pull，demand方式のいずれにも対応し，使い分けられる基盤
    対応する提案
    課題 概要 利点
    Push方式 デバイスが取得可能なセンサーデータを余すことなく送信でき
    る
    デバイス層において取得したデータの時間分解能の高さが求
    められる場合
    Pull方式 クラウド層が提供するユーザー向けのアプリケーションに必要
    なだけのデータを取得できる
    ユーザーへ提供するサービ スレベルに応じてデータの流量を
    制御できることが求められる場合
    Demand方式 データ処理を行うエッジ層の余力に応じてデータフローの流量
    を制御しつつデータを取得できる
    リソース制約のもとでの高い可用性が求められる場合
    双方向性 上述のいずれの方式についても双方向通信が可能
    要件の変更を見据えて，容易に双方向性に対応できる方式を
    用いることが可能
    

    View Slide

22. 22
    4. 評価
    評価③ 3層におけるデータフローパターン
    を全て記述できることを示した
    ● 3つのデータ取得方式に双方向性を加えた
    データフローのパターンは5種類※．そのため
    ，提案手法ですべて記述可能（右上図）
    ● エッジ層におけるプロセッサーの記述につい
    ても，あり得る4パターンをすべて記述可能
    （右下図）
    提案③ 3層からなるデータフローを一望のも
    とに把握できる記法
    対応する提案
    ※ クラウド層からデバイス層へ送信指示を行うPull方式では，単方向は定義上存在しないため．
    

    View Slide

23. 23
    5. おわりに
    

    View Slide

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

    View Slide

25. 5. おわりに
    25
    課題と今後の展望
    インテリジェントなIoTシステムを構築するための基盤として，本研究を発展させたい．
    ● 提案手法を大規模なシステムに応用可能なパフォーマンス改善と定量評価
    ● 各層の実装に対する開発者による変更を，効率的かつ安全に適用できること
    ● デバイス層における推論のために，クラウド層で学習したモデルの効率的な配備
    今後の展望
    ● 提案手法に対する定量的な評価（システム要件に対するパフォーマンス等）
    ● 提案手法のような統合的な手法が，現実の
    IoTシステムの複雑さをカバーし得るか
    課題
    

    View Slide