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

第14回インターネットと運用技術シンポジウム（IOTS 2021)
https://www.iot.ipsj.or.jp/symposium/iots2021-program/

Transcript

1. IoTシステムの双方向データフローにおける設
   計と実装の複雑さを解消する手法の提案
   栗林健太郎（GMOペパボ / 北陸先端科学技術大学院大学）
   三宅悠介（GMOペパボ）
   力武健次（GMOペパボ / 力武健次技術士事務所）
   篠田陽一（北陸先端科学技術大学院大学）
   発表者: 栗林健太郎
   第14回インターネットと運用技術シンポジウム(2021.11.25-26)
   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/pratipad/
    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種類であ
    り，提案手法ですべて記述可能（pull方
    式では単方向は存在しない．右上図）
    ● エッジ層におけるプロセッサーの記述
    についても，あり得る4パターンをすべ
    て記述可能（右下図）
    提案③ 3層からなるデータフローを一望
    のもとに把握できる記法
    対応する提案
    

    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

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

    View Slide