IoTシステム開発の複雑さを低減するための統合的アーキテクチャ

「IoTシステム開発の複雑さを低減するための統合的アーキテクチャ」

北陸先端科学技術大学院大学博士後期課程
博士論文公聴会（2025年2月9日10時00分〜11時30分）

Transcript

1. IoTシステム開発の複雑さを低減するための 統合的アーキテクチャ 栗林健太郎（2240006） 北陸先端科学技術大学院大学博士後期課程 博士論文公聴会（2025年2月9日10時00分〜11時30分） 1
2. 目次 1. 序論 2. 関連研究 3. 技術的統合性の導入 4. 動的な可変性の導入 5. 構成的統合性の導入 6. 結論
3. 3 1. 序論
4. 1. 序論 -　IoTシステムが異種混合的であることは，デバイス の種類，データ形式，通信方法など，様々な要因から なる [Qiu 2018]． -　そのような性質を持つIoTシステムを構成するネッ トワークの相互運用性を担保することは困難である [Parmar 2022]． -　多様な性質が潜在的な脆弱性を生み出すため，セ キュリティ上の懸念が生じ得る [choudhary 2019]． IoTシステムは異種混合的（heterogenious） な構成が当然視されてきた 右図の出典：Qiu 2018
5. 1. 序論 一方で，情報システムの歴史において，多様な構成を前提としたとしても統合的に 開発可能な手法は長年追い求められてきた目標であった 年代 名称 対象 1960年代 System/360 ハードウェア 1970年代 C言語 ハードウェア，OS 1990年代 Java ハードウェア，OS 2010年代 React Native 実行環境（*） 2010年代 Flutter 同上 2010年代 WebAssembly 同上 * ここでいう「実行環境」とは，種々の OS上で動作するアプリケーションランタイムをいう．具体的には，モバイルアプリやブラウザ上のアプリケー ションコードの実行環境を指す．
6. 1. 序論 本研究の動機：統合的に開発可能な手法を導入しようとしてきた試みを引き継ぎ， 異種混合性が当然と考えられてきたIoTシステムにおいても実現したい デバイス層 エッジ層 クラウド層 デバイスクラスタ モバイル端末 モビリティ 単一言語の例としてのプログラミング言語 Elixirと，柔軟性を導入するための役割を 果たすWebAssembly * 高瀬英希「関数型言語 ElixirのIoTシステム開発への展開」 p.5, p.20 https://www.slideshare.net/slideshow/elixiriot-244043098/244043098 を参考に作図した
7. 1. 序論 IoTシステムに対して統合性を導入する上での課題を以下の3つに整理する 課題1 IoTシステム全体を一貫して開発するための技術基盤をどのように構築できるか．特に，アプリケーションを 開発するプログラミング言語，各層間の通信に用いるプロトコルとして何を選択するかが論点となる． IoTシステム全体を統合的に開発するための技術基盤 課題2 課題1に述べた統合的な技術基盤を効果的に実現しつつ，同時に，システムを状況やニーズへの変化に対 していかにして柔軟に対応させるか．そのためには，アプリケーションを部分的かつ動的に変更できること が必要となる． IoTシステムの柔軟性を向上するための動的に可変な性質 課題3 課題1に述べた統合的な技術基盤を用いつつ，その統合性を損なうことなく，急速に進展する技術革新をい かに柔軟に取り入れられるか．柔軟に取り入れられつつも，統合性を維持することと柔軟性とを両立できる 構成が必要となる． 新技術へ迅速に対応するための柔軟な構成
8. 1. 序論 本研究の目的：IoTシステム開発の複雑さを低減する．そのために統合的に開発可 能なアーキテクチャを提案する IoTシステム開発の複雑さを低減する 本研究全体を貫く⽬的 ①技術的統合性 ②動的な可変性 ③構成的統合性 課題1 課題2 課題3 ⽬的を実現する上での3つの切り⼝
9. Hardware 9 1. 序論 本研究の目的：IoTシステムを統合的に開発可能なアーキテクチャを提案する OS プロシージャ デバイス層 ハードウェア エッジ層 クラウド層 コア ロジック アプリケーション Hardware OS プロシージャ ハードウェア コア ロジック アプリケーション ① 技術的統合性 通信 通信 ③ 構成的統合性 ② 動的な可変性 Hardware OS プロシージャ ハードウェア コア ロジック アプリケーション
10. 1. 序論 ① 技術的統合性：各層を通じて単一の実装言語，通信プロトコルを用いる Hardware OS プロシージャ デバイス層 ハードウェア エッジ層 クラウド層 コア ロジック アプリケーション Hardware OS プロシージャ ハードウェア コア ロジック アプリケーション 技術的統合性 通信 通信 Hardware OS プロシージャ ハードウェア コア ロジック アプリケーション ① IoTシステムの各 層を構成するアプリ ケーションを単一の 言語によって実装す る ② 各層の通信に左記で選択した言語がサポートするセキュアなプロトコルを用いる
11. Hardware 11 1. 序論 ② 動的な可変性：アプリケーションを部分的に更新し動作を変更可能にする OS プロシージャ デバイス層 ハードウェア エッジ層 クラウド層 コア ロジック アプリケーション Hardware OS プロシージャ ハードウェア コア ロジック アプリケーション 通信 通信 ② 動的な可変性 Hardware OS プロシージャ ハードウェア コア ロジック アプリケーション ① 開発時における 開発者のコード変更 を動的に適用可能 にする ② 新技術を柔軟に取り入れられるようアプリケーションを部分的に別の汎用的技術で構成する
12. Hardware 12 1. 序論 ③ 構成的統合性：技術的統合性を維持しつつ可変性を導入する構成を実現する OS プロシージャ デバイス層 ハードウェア エッジ層 クラウド層 コア ロジック アプリケーション Hardware OS プロシージャ ハードウェア コア ロジック アプリケーション 通信 通信 ③ 構成的統合性 Hardware OS プロシージャ ハードウェア コア ロジック アプリケーション ① 各層間のアプリケーション実行基盤を同一の構成にする ② 同一のコード変更することなしに各層間で実行可能にする
13. 本論文の構成：3つの課題の解決策としての統合的アーキテクチャを提案する 1. 序論 13 関連研究：本研究の位置付けとDynamic Isomorphic IoT System Architectureの導⼊ 技術的統合性の導⼊ 動的な可変性の導⼊ 構成的統合性の導⼊ 結論：本研究の成果，社会的意義，⼀般的な適⽤可能性，今後の展望 2章 6章 3章 4章 5章 提案⼿法 IoTシステム全体を，単⼀のプログラミング⾔語で統合的に設計‧開発することを可能と するデータフロー基盤を提案‧実装する． IoTシステムの開発に⽤いられるElixirによって実装されるIoTデバイスの開発効率向上のた め，開発者によるコードの変更を動的に適⽤できる⼿法を提案‧実装する． 単⼀の⾔語による開発に起因する機能⾯での不⾜に対して，技術的統合性を可能な限り損 なうことなく多様な技術を取り込むことが可能なアーキテクチャを提案‧実装する．
14. 14 2. 関連研究
15. 15 2.1. 課題1における関連研究
16. 2. 関連研究 【再掲】IoTシステムに対して統合性を導入する上での3つの課題 課題1 IoTシステム全体を一貫して開発するための技術基盤をどのように構築できるか．特に，アプリケーションを 開発するプログラミング言語，各層間の通信に用いるプロトコルとして何を選択するかが論点となる． IoTシステム全体を統合的に開発するための技術基盤 課題2 課題1に述べた統合的な技術基盤を効果的に実現しつつ，同時に，システムを状況やニーズへの変化に対 していかにして柔軟に対応させるか．そのためには，アプリケーションを部分的かつ動的に変更できること が必要となる． IoTシステムの柔軟性を向上するための動的に可変な性質 課題3 課題1に述べた統合的な技術基盤を用いつつ，その統合性を損なうことなく，急速に進展する技術革新をい かに柔軟に取り入れられるか．柔軟に取り入れられつつも，統合性を維持しつつも柔軟性を両立できる構 成が必要となる． 新技術へ迅速に対応するための柔軟な構成
17. 2. 関連研究 さらに，課題1を効果的に解決するために以下の3つの副課題に細分化する 課題1 IoTシステム全体を統合的に開発するための技術基盤 副課題1 IoTシステム全体を構築可能なプログラミング言語としてどの言 語を選択するか 副課題2 選択したプログラミング言語によって多様かつ双方向性をもつ データ取得方式に対応できるか 副課題3 IoTシステムの階層的なアーキテクチャにおけるデータフローを 見通しよく扱えるか
18. Application Network Perception Application Middleware Processing Transport Perception クラウド層 エッジ層 デバイス層 3層モデル 5層モデル 本研究の 想定するモデル - 物理空間上のデータのセンシングと上位層へ の送信 - 上位層からの指示に基づく物理空間へのアク チュエーション - データに対する各種の処理（整形，加工，拡 張等） - デバイス層に近い場所での計算処理 - データの分析と情報の生成 - IoTシステムのユーザへのサービス提供 - 物理空間上のデバイスへのアクチュエーショ ン指示 18 2. 関連研究 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.を参考に筆者が作成
19. 19 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. 副課題① プログラミング言語や通信プロトコルの選択肢が多様である 対応する副課題
20. 20 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方式，双方向通信 を実現すること自体は可能 副課題② データフローの種別が多様かつ双方向性を持つ 対応する副課題
21. 21 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システムの全体を通じたデータフローの見 通しが悪くなる 対応する副課題
22. 22 2. 関連研究 解決方針：前述した3つの副課題すべてを解決する手法を提案する 副課題 関連研究による解決 解決方針の位置付け ① プログラミング言語や通信プロ トコルの選択肢が多様である TinyLink2.0，CEF 副課題1のみなら有力な解決策 3つの副課題をすべて解決し課 題1に対する解決方針を実現で きる手法を提案する ② データフローの種別が多様かつ 双方向性を持つ TinyLink2.0，CEF，DDF/D-NR push, pull, 双方向性を実現可能 (Websocket, Pub-Sub)ではあるが demand方式に対応していない ③ IoTシステムの全体を通じた データフローの見通しが悪くな る Node-Red，DDF/D-NR ただし，Node-Redは3層を統合する 実装は不可
23. 23 2.2. 課題2における関連研究
24. 2. 関連研究 【再掲】IoTシステムに対して統合性を導入する上での3つの課題 課題1 IoTシステム全体を一貫して開発するための技術基盤をどのように構築できるか．特に，アプリケーションを 開発するプログラミング言語，各層間の通信に用いるプロトコルとして何を選択するかが論点となる． IoTシステム全体を統合的に開発するための技術基盤 課題2 課題1に述べた統合的な技術基盤を効果的に実現しつつ，同時に，システムを状況やニーズへの変化に対 していかにして柔軟に対応させるか．そのためには，アプリケーションを部分的かつ動的に変更できること が必要となる． IoTシステムの柔軟性を向上するための動的に可変な性質 課題3 課題1に述べた統合的な技術基盤を用いつつ，その統合性を損なうことなく，急速に進展する技術革新をい かに柔軟に取り入れられるか．柔軟に取り入れられつつも，統合性を維持しつつも柔軟性を両立できる構 成が必要となる． 新技術へ迅速に対応するための柔軟な構成
25. 25 2. 関連研究 Over-the-Air（OTA）によるコードの更新方式が広く研究されてきた IoTデバイスに対するコードの更新のために Over-the-Air（OTA）による方式が広く研究された きた [右上図，Bauwens 2020]，[右下表 Ruckebusch 2018]． OTAを実現する上での課題： - IoTデバイスは直接的にアクセスすることが難しい 場所に配置されることも多いため，リモートからの 更新と検証が可能である必要がある[Brown 2013]． - IoTデバイスは，一度配備された後も継続的にアプ リケーションの更新が必要である．一方で，電源容 量や確保，ハードウェアスペック，ネットワーク帯域 等において制約の厳しい環境下で動作を継続する 必要がある[Yousefnezhad 2020]．
26. 2. 関連研究 - 先行研究は，開発者によるコードの変更をIoTデバイスに適用する方式として，以下の表の 通り整理している（[Ruckebusch 2016，2018]より筆者がまとめた）． - 前述の通り，ハードウェアやネットワーク制約の強いIoTデバイスの実環境への配備後の更 新方式に着目しているため，動的言語による方式を採用不可としている． 実環境配備後のデバイスへのOTAには動的言語は不向きであるとされてきた 更新対象 概要 採用可否 スクリプト言語によるコード スクリプト言語の持つ動的な性質を利用して，旧いコードを開発者 による変更後の新しいコードで置き換える． ✕ 仮想機械で動作する言語によるコード 仮想機械で動作する言語の持つ動的な性質を利用して，旧いコー ドを開発者による変更後の新しいコードで置き換える． ✕ ファームウェアイメージ アプリケーションコードを埋め込んだファームウェアイメージを入れ 替えることで，開発者による変更後の新しいコードを適用する． ◯ ネイティブコードへの動的リンク 開発者による変更後の新しいコードをネイティブコードとして配置し ，既存のコードのリンク先を動的に書き換える． ◯
27. 2. 関連研究 - Raspberry PiやBeagle Bone等のような相対的に高性能なハードウェアを用いるこ とが可能である前提をおけば，動的な性質を持つプログラミング言語を利用可能である． - ファームウェアイメージを全体・差分を更新する方式に分割する（下表①，②）． - コードの動的な更新についてはコードの形式に関わらず同一であるとみなせるため，統合 して扱い（下表③），この方式を解決方針として実現することを目指す． 解決方針：相対的に高性能なハードウェアの利用を前提に③の方式を実現する 更新対象 操作 本研究による方式の整理 ファームウェアイメージ 分割 ① ファームウェアイメージの全体を適用する方式 ② ファームウェアイメージの差分を適用する方式 スクリプト言語によるコード 統合 ③ アプリケーションコードを動的に適用する方式 仮想機械で動作する言語によるコード ネイティブコードへの動的リンク WebAssemblyバイナリ（次節で扱う）
28. 28 2.3. 課題3における関連研究
29. 2. 関連研究 【再掲】IoTシステムに対して統合性を導入する上での3つの課題 課題1 IoTシステム全体を一貫して開発するための技術基盤をどのように構築できるか．特に，アプリケーションを 開発するプログラミング言語，各層間の通信に用いるプロトコルとして何を選択するかが論点となる． IoTシステム全体を統合的に開発するための技術基盤 課題2 課題1に述べた統合的な技術基盤を効果的に実現しつつ，同時に，システムを状況やニーズへの変化に対 していかにして柔軟に対応させるか．そのためには，アプリケーションを部分的かつ動的に変更できること が必要となる． IoTシステムの柔軟性を向上するための動的に可変な性質 課題3 課題1に述べた統合的な技術基盤を用いつつ，その統合性を損なうことなく，急速に進展する技術革新をい かに柔軟に取り入れられるか．柔軟に取り入れられつつも，統合性を維持しつつも柔軟性を両立できる構 成が必要となる． 新技術へ迅速に対応するための柔軟な構成
30. 30 2. 関連研究 コード変更の適用は，多階層からなるIoTシステム全体を通 じて適用可能な手法が必要である - 前節では，開発時に着目してIoTデバイスに対するコード変更の 動的な更新手法について整理した． - 一方で，現在のIoTシステムは，右図に例示する通り，一般に多階 層からなるシステムとして構成される [右図，Bansal 2020]. - そのため，昨今のクラウド／エッジコンピューティングの隆盛を前 提に，デバイス層のみならず，システム全体を通じて適用可能な 手法を検討する必要がある．
31. 31 2. 関連研究 WebAssemblyを用いたコード変更の動的な更新手法が有力な選択肢として研 究が進められつつある - アプリケーションの処理の一部をWasmとして 組み合わせ，その部分のみを動的な更新対象 にする研究が行われている． - 例えば，デバイス内の処理の一部を開発機から コードを動的に更新する実装が提案されてい る [右図，Koren 2021]. - 当該研究には，整数型・浮動小数点型といった ごくプリミティブな値の受け渡ししか想定され ていない限界がある．
32. 32 2. 関連研究 Wasmのポータブルな性質を活用したIsomorphic（同型）なアーキテクチャによ り，動的な可変性と統合性を両立し得る - 単にWasmを代替的に用いるだけでは，IoTシス テムとしての統合性が損なわれかねない． - そこで，ポータブルなWasmの性質を活用し，多階 層のIoTシステムを統合的に設計可能な Isomorphic IoT Systemというアーキテク チャが有力な候補として浮上する [Mikkonen 2021]． - 一方で，当該研究はアーキテクチャのコンセプトを 示すのみで，具体的な実装に欠ける．
33. 33 2. 関連研究 解決方針：構成的統合性の導入により，動的な可変性と技術的統合性を可能な限り 両立するアーキテクチャを提案する 動的な可変性 技術的統合性 ⚠ 単一の技術の導入によって，その技術 外で生じた新技術の柔軟な取り込みが阻 害されかねない． ⚠ 単に可変性を導入するのみでは，シス テムが場当たり的なパッチワークになりか ねない． ✅ ポータブルなWasmを部分的に組み込 むことで，新技術の取り込みを Wasmに よって実現可能にしつつ，技術的複雑性 を抑制する． ✅ 階層を通じて同一の構成とコードベー スを用いることで，Wasm部分を動的に更 新可能にしつつ，統一的な設計指針を与 える． 構成的統合性
34. 34 2.4. 本研究の位置付け
35. 2. 関連研究 本研究の位置付け：統合性と柔軟性とを両立するアーキテクチャを提案する 技術的統合性 動的な可変性 構成的統合性 Dynamic Isomorphic IoT System Architecture 課題1 課題2 課題3 統合性と柔軟性の両⽴ 柔軟性と統合性の両⽴ 統合性と柔軟性をかねそなえる提案
36. 2. 関連研究 Dynamic Isomorphic IoT System Architectureとは何か？ Dynamic Isomorphic IoT System Architecture Dynamic（動的）とは？ IoTシステムを構成するアプリケーショ ンのコードを，アプリケーション全体を 再起動することなしに部分的に変更する ことで，その動作を変化させられること Isomorohic（同型）とは？ IoTシステムの各層においてアプリケー ションの実⾏環境として共通の構成を⽤ いることで，各層を通じて同⼀のコード ベースを⽤いてアプリケーションを構築 および実⾏すること この2つの性質により技術的統合性を導⼊しつつ変化に対して柔軟なアーキテクチャとなる
37. 37 3. 技術的統合性の導入
38. 38 3.1. 背景と課題
39. クラウド層 エッジ層 デバイス層 39 3. 技術的統合性の導入 副課題① プログラミング言語や通信プロトコルの選択肢が多様である ①各層をどのような言語で 設計・実装するか • 各層は，それぞれに設計・ 実装言語への要求内容が 異なる • 一方で，言語が異なると学 習コストがそれぞれに対し てかかる ②各層間の通信プロトコル に何を用いるか • 左記で選択した言語で扱 いやすいプロトコルである ことが望ましい • また，セキュリティを担保で きることも必須
40. クラウド層 エッジ層 デバイス層 40 3. 技術的統合性の導入 副課題② データフローの種別が多様かつ双方向性を持つ ①デバイス層からどのように データを収集するか • どの層がデータ取得の起 点になるかはシステム要 件によって異なる • また、定期的に取得する か、必要に応じて取得する かも要件次第 ②通信の双方向性をどう実 現するか • デバイス層の上位層から のアクチュエーション指示 を可能にする • 双方向なデータフローが必 要になる データの出所
41. デバイス層 エッジ層 クラウド層 41 3. 技術的統合性の導入 副課題③ IoTシステムの全体を通じたデータフローの見通しが悪くなる ① 副課題②で述べたデータ取得方式＋双方向ネットワークの定義 ② エッジ層におけるデータ処理の記述（データに対する整形，加工，拡張等） 各層でバラバラに定義すると，複雑かつ全体の見通しがきかない記述になってしまう． 3層間におけるデータフローを記述するために必要な要素
42. 3. 技術的統合性の導入 42 本章の目的は，前述した3つの副課題すべてを解決する手法を提案すること 副課題 提案 ① プログラミング言語や通信プロトコルの選 択肢が多様である 3層を同一のプログラミング言語と通信プ ロトコルを用いて統合的に設計・実装でき る手法 ② データフローの種別が多様かつ双方向性 を持つ push，pull，demand方式のいずれにも 対応し，使い分けられる基盤 ③ IoTシステムの全体を通じたデータフロー の見通しが悪くなる 3層からなるデータフローを一望のもとに 把握できる記法
43. 43 3.2. 提案手法
44. 44 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通信とクライアント証明書認証で各層を繋ぐことでセキュアな通信んを実現
45. 45 3. 技術的統合性の導入 提案② push，pull，demand方式のいずれにも対応し，使い分けられる基盤 副課題② データフローの種別が多様かつ双方向性を持つ 対応する副課題
46. 46 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} 単一のプロセッサ 順次適用する複数のプロセッサ 並列適用する複数のプロセッサ 方向 ~> <~> データフローは単方向 データフローは双方向
47. 47 3.3. 評価
48. 48 3.3.1. 有効性の評価
49. 49 3. 技術的統合性の導入 評価① 提案手法を用いて実用的なIoTシステムを構築できることを示した(1/2) 提案① 3層を同一のプログラミング言語と通信プロトコルを用いて統合的に設計・実装できる手法 対応する提案 部屋1 部屋2 LAN エッジ層 デバイス層 デバイス層 住居 WAN センシング - CO2濃度 - 気圧 - 湿度 クラウド層 - 可視化 - 分析 - アクチュエーション指 示の実行 外部API - 追加情報の付与 (例：雨量等) 利用者 - 状況の把握 - 状況に応じた行動 (例：窓を開ける) Pratipad経由 の通信 (mTLS通信) - データ取集 - 加工 - 情報の追加 ･･･ Elixirで動作 クラウド層からのアクチュエーション指示に基づき，LEDが点灯（「窓を開けろ！」のサイン）
50. 50 3. 技術的統合性の導入 評価① 提案手法を用いて実用的な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 ※ 実験環境のネットワークの都合上，パブリックク ラウドを用いることができなかったため代用
51. 51 3. 技術的統合性の導入 評価② 3つのデータ取得方式と双方向性対応で広い要件を満たせることを示した データフロー記述(提案③)と各層で利用するプロトコルの変更のみで以下を容易に使い分けられる． 提案② push，pull，demand方式のいずれにも対応し，使い分けられる基盤 対応する提案 課題 概要 利点 Push方式 デバイスが取得可能なセンサーデータを余すことなく送信でき る デバイス層において取得したデータの時間分解能の高さが求 められる場合 Pull方式 クラウド層が提供するユーザー向けのアプリケーションに必要 なだけのデータを取得できる ユーザーへ提供するサービ スレベルに応じてデータの流量を 制御できることが求められる場合 Demand方式 データ処理を行うエッジ層の余力に応じてデータフローの流量 を制御しつつデータを取得できる リソース制約のもとでの高い可用性が求められる場合 双方向性 上述のいずれの方式についても双方向通信が可能 要件の変更を見据えて，容易に双方向性に対応できる方式を 用いることが可能
52. 52 3. 技術的統合性の導入 評価③ 3層におけるデータフローパター ンを全て記述できることを示した • 3つのデータ取得方式に双方向性を加えた データフローのパターンは5種類※．そのた め，提案手法ですべて記述可能（右上図） • エッジ層におけるプロセッサーの記述につ いても，あり得る4パターンをすべて記述可 能（右下図） 提案③ 3層からなるデータフローを一望のも とに把握できる記法 対応する提案 ※ クラウド層からデバイス層へ送信指示を行うPull方式では，単方向は定義上存在しないため．
53. 53 3.3.2. 適用可能性の評価
54. 3. 技術的統合性の導入 - 提案手法を適用して実用的な規模のIoTシステムを構築するためには，提案手法がその実現に耐え得る 性能を発揮できるか否かについても示す必要がある． - そこで，提案手法の適用可能性を評価するために，性能に関する比較実験を行う． - データ送信のスループット（pull方式はスループットの速さを求める方式ではないため，pushおよ びdemand方式のみを対象とする．） - CPUおよびメモリ使用率 - 実験環境は，右表の通りである． - デバイス層：デバイス群をエミュレート　　　　　　　　　　　　　　　　　　　　　　　　　するElixirプロセスを多 数立ち上げるホスト - エッジ層，クラウド層：Raspberry Piおよび　　　　　　　　　　　　　　　　　　　　　　　Googleクラウドの 一般的なインスタンス 提案手法で実用規模のIoTシステムを構築可能な性能を持つかどうかを評価する
55. 3. 技術的統合性の導入 - デバイス層と見立てたホスト上では，デバイス群 をシミュレートするメッセージ送信用のElixirプロ セスを複数起動する．そして実験ごとにその数を 10，100，1000，5000と増加させる． - メッセージの送信タイミングは，1秒に1回送信が 行われる程度に調整して設定する（pushと demandとではメッセージ送信の発生要因が異 なることから，厳密には一致しない）． - エッジ層では，メッセージをクラウド層に受け渡す 処理のみを行う． - 実験時間はそれぞれ10分間とする． データを送信するデバイス群を増加させながら各方式での処理性能を計測する Pratipad デバイス層 エッジ層 クラウド層 それぞれのデバイスから1秒ごとにメッ セージを送信 秒間スループットの最大値はプロセス 数と等しくなる push方式 Pratipad エッジ層の1秒間の最大処理量をプロ セス数と同数に設定 秒間スループットの最大値はプロセス 数とほぼ等しくなる demand方式 送信要求 送信 送信
56. 3. 技術的統合性の導入 - いずれの実験においても，総メッセージ数は実験で設定したプロセス数に10×60（10分間）を乗じた 値の近傍であり，スループットは実験で設定したプロセス数の増加に比例している - demand方式では5,000プロセスでは動作が不安定となり計測ができなかった - push方式においては5,000プロセスまで，demand方式においては1,000プロセスまでの，1プロ セスあたり1秒に1回程度のメッセージ送信を処理可能であることが示された． 提案手法は，本実験設定において1,000台規模のデバイス数からなるIoTシステ ムを構築可能なスループットを処理可能である
57. 3. 技術的統合性の導入 - CPU，メモリ使用率はいずれも安定している． - 100プロセスの場合にdemand方式のCPU使 用率がpush方式に比べて低い．demand方式 にはデータ処理を行うエッジ層の余力に応じて データフローの流量を制御しつつデータを取得で きる利点があるからである． - 1,000プロセスの場合のメモリ使用率は ，demand方式がpush方式よりも高い． demand方式が一定程度メッセージをデータフ ロー内にバッファリングする方式であることによ る 提案手法は，本実験設定において1,000台規模のデバイス数からなるIoTシステ ムをCPU，メモリ使用率ともに安定して処理可能である
58. 58 3.4. 本章のまとめ
59. 59 3. 技術的統合性の導入 本章の貢献 - 多階層からなるIoTシステムを，単一の技術によって実現可能な技術基盤を提案・実装することで，技術的 統合性を導入した． - 提案手法を用いて実用的な IoTシステムを実装し，定量評価を行うことで，提案手法の有効性と適用可能性 が十分あることについて定性・定量の両面から示した． 今後の展望 - デバイス層を実装するコードの変更内容を含むデータを，提案手法を用いて配布可能にする． - システム運用負荷軽減のため，デバイス層へクライアント証明書を配布・管理する機構を備える．
60. 60 4. 動的な可変性の導入
61. 61 4.1. 背景と課題
62. 62 4. 動的な可変性の導入 技術的統合性を維持しつつ変化に対して柔軟に対応可能な手法が必要である 前章で， IoTシステムを単一のプログラミング言語で開発可能な技術基盤を提案・実装した 一方で，技術的統合性により IoTシステムが状況の変化に対応することが困難になり得る 前章で導入した技術的統合性を維持しつつ，変化に対して柔軟に対応可能な手法として， IoTアプリ ケーションに対するコード変更の，部分的かつ動的な適用手法を提案する． 本章では，IoTデバイスの開発時におけるコード変更の適用手法について検討することで，そのこと がIoTシステム開発の効率化に資することを示す． ✅ ⚠
63. 63 4. 動的な可変性の導入 本章では，IoTシステムの構成要素であるIoTデバイス内アプリケーションの開発 効率向上のためのコード適用手法を検討する - IoTデバイスを構成するソフトウェアは右図の通り である [Bauwens 2020]．本章で検討の対象と するのは，図右上囲みのIoTアプリケーション部分 である． - IoTの文脈では，IoTアプリケーションはエンドユー ザ向けのアプリケーションを指すことが多いが，こ こではIoTデバイス内アプリケーションをIoTアプリ ケーションと呼ぶ． この部分が対象
64. 4. 動的な可変性の導入 - IoTデバイスは固有のハードウェアを用いるため，開発した内容を検証するには実デバイス へのコード変更の適用プロセスが必須となる． - コード変更を動的に適用可能とすることで，IoTアプリケーションの開発効率を向上した い． コード変更をデバイスへ動的に適用可能にすることで開発効率を向上させる コードの 開発 デバイスへの 適用 動作検 証 IoTデバイス開発のイテレーション この手順を効率化したい
65. 65 4.2. 提案と実装
66. 4. 動的な可変性の導入 - 先行研究においては，リソース制約の強い状況におけるデバイスの配備後の適用を課題としているため ，下記の③については十分に検討されてこなかった． - 本章では，先行研究では扱われてこなかったスクリプト言語や仮想機械による言語を用いる方法を含め ，IoTアプリケーションの開発効率の向上を目的とした③の方式をあらためて提案する． 前章の技術的統合性の導入において採用した動的言語を用いることで，コード変 更のIoTデバイスへの動的な適用を実現する 更新対象 操作 本研究による方式の整理 ファームウェアイメージ 分割 ① ファームウェアイメージの全体を適用する方式 ② ファームウェアイメージの差分を適用する方式 スクリプト言語によるコード 統合 ③ アプリケーションコードを動的に適用する方式 仮想機械で動作する言語によるコード ネイティブコードへの動的リンク WebAssemblyバイナリ（次節で扱う）
67. 4. 動的な可変性の導入 - 前述の方式①および②におけるコード変更の適 用プロセスのシーケンスを，右図の通り示す - 右図1：開発者は，変更したコードから新たな ファームウェアをビルドする - 右図2：1でビルドしたファームウェアをIoTデバイ スへ送信・適用する - 右図3：IoTデバイスは，新たなファームウェアに よってデバイスを再起動し，さらにアプリケーショ ンを起動する 前述の方式①および②におけるコード変 更の適用プロセスのシーケンス
68. 4. 動的な可変性の導入 - 提案方式③におけるコード変更の適用プロセス のシーケンスを，右図の通り示す - 右図1：コードの変更は開発者が逐次的にIoTデ バイスに送信・適用する - 右図2：変更されたコードに関わるアプリケー ションの構成要素（ここではプロセス）を再起動 する - 前ページの方式と異なり，デバイスの再起動は 必要ない． 提案方式③におけるコード変更の適用プ ロセスのシーケンス
69. 4. 動的な可変性の導入 - 提案方式の実装には，前章で提案・実装した技術基盤で採用したプロ グラミング言語のElixirと，IoTデバイスの開発プラットフォームの Nervesを用いた． - Elixirは大規模な並行プロセスを可能とするErlang/OTPの仮想機 械で動作する言語である． - Nervesは，Elixirを同VM上で動作するのに必要十分に小さな Linuxによるファームウェアを提供するプラットフォームである． - 前章での技術選択は，技術的統合性を維持しつつ，動的な可変性を 導入する上でも効果的であるといえる． 前章で提案・実装した技術基盤で採用したプログラミング言語およびIoTデバイス 開発プラットフォームにより提案手法が実現可能となった
70. Erlang VM 4. 動的な可変性の導入 - Elixirの実行基盤となるErlang/OTPの仮想機械（Erlang VM）は，hotswapと呼ばれる実行時にオブジェクトコードを動 的に置き換えられる機能を提供している． - コードの置き換えは，Erlang VM上で動作するノードと呼ばれ るプロセスを通じて行われる．ノードは遠隔手続き呼び出し （RPC）に対応している． - 遠隔のホスト上（この場合はIoTデバイス）で動作するノードに対 して，旧いコードを新しいコードに置き換えるRPCを実行するこ とで，開発者によるコードの変更をIoTデバイスへ適用した． Erlang VMの提供するコードを動的に置き換えられる機能を用いて，開発者によ るコード変更のIoTデバイスへの動的な更新手法を実装した Hardware Hardware＋OS Erlang VM ノード IoTデバイス ノード 開発者のマシン RPCを通じたコード変更の適用 アプリ内 コード 置き換え
71. 71 4.3. 評価
72. 4. 動的な可変性の導入 - それぞれの方式を比較するための指標として，コードの変更を デバイスに適用した上で，IoTアプリケーションが変更を取り込 んだ状態で動作するまでに要する時間を用いた． - コードの変更を適用する対象となるIoTアプリケーションとし て，TCPソケット経由でクライアントから受け取った文字列をそ のまま返却する，いわゆるEchoサーバを実装して用いた． - 前述の通り，デバイス再起動の有無に関わらず，IoTアプリケー ション自体の通信が再開するまでの時間を指標として計測する ためである． コード変更をデバイスに適用してサービス再開するまでの時間を計測する ビルド デプロイ OS再起動 アプリ 起動 デプロイ プロセス 再起動 方式①，② 提案方式③ この差を 比較する
73. 4. 動的な可変性の導入 - それぞれの方式について，コード変更の適用にお けるフェーズごとに，右表の通りそれぞれ対応す るコマンドを用いて時間を計測した - pingコマンドおよびncatコマンドについては ，IoTデバイスやアプリケーションへの接続が遮断 されている間は繰り返し実行し，接続が確立され るまでの時間を計測した - 上記の時間を足し合わせることで，コード変更が 適用されアプリケーションのサービスが再開され るまでの所要時間とする コード変更をデバイスに適用するフェーズごとに所要時間を計測する
74. 4. 動的な可変性の導入 - 実験結果は，下表の通りである．提案方式（3）が最も速く，計測した指標において（1）と比較して95% の改善が見られた． - 提案方式（3）のApplication Rebootは，数msec以下であるため本実験では計測できなかった． - 方式（2）については，差分を適用する過程にボトルネックがあり，むしろ遅くなってしまったと考えられ る（通信量が抑えられるメリットはある）． 動的な更新方式がファームウェアアップデートと比較して速いことを示した
75. 4. 動的な可変性の導入 - 提案方式の実装は，変更対象のアプリケーションコード全体の依存関係を考慮することなく動的な書き 換えを行っている．そのため，コード間に複雑な依存関係がある場合は，不整合を起こす可能性がある． しかしその場合はファームウェアを更新することで容易に復旧可能である． - 提案方式および実装の一般性については，IoTアプリケーションの開発効率向上を前提に相対的にス ペックの高いハードウェアを用いることができるため，本実装とは別の言語を用いても実現可能である と思われる． - また，[AtomVM]と呼ばれるErlang VM互換のVMを開発することで，より低スペックのハードウェア で動作させる取り組みも進みつつあるため，将来的により適用可能性が広がり得る． 提案方式は動的な可変性の導入によるIoTデバイス開発効率の向上に寄与すると 考えられ，また，その一般的適用可能性は今後さらに広がり得る
76. 76 4.4. 本章のまとめ
77. 77 4. 動的な可変性の導入 本章の貢献 - IoTアプリケーションの開発効率の向上を目的とした，開発者によるコードの変更を動的に適用する方式の 提案と実装を行った． - 先行研究に基づいて方式を整理した上で，提案方式と既存方式とを実験により比較検討した． - その結果として，IoTアプリケーションへのコード変更の適用に要する時間について，提案方式の実装は 95% の改善を実現できた． 今後の展望 - 提案方式は，一般的な動的言語によっても実現可能であり，今後デバイスの高度化が進むにつれて IoTデ バイスの開発プラットフォームにとって優位性となり得る． - 次章では，IoTデバイス開発時にとどまらないより一般的なコード変更の動的な適用手法について検討す る．
78. 78 5. 構成的統合性の導入
79. 79 5.1. 背景と課題
80. 80 5. 構成的統合性の導入 動的な可変性を持ちつつ技術的統合性を損ねない設計指針が必要である 前章で，開発時のコードの動的更新手法が提案され動的な可変性が部分的に導入された 統合性と柔軟性（動的な可変性＋新技術の取り込みやすさ）を両立する必要がある ① 開発時のみならず，多階層からなる IoTシ ステム全体を見据えた動的な更新手法がさら に探求される必要がある． → より一般的なコードの動的更新手法 ✅ ⚠ ② 技術的統合性を維持しつつ，可変性や新 技術の取り込みが容易になるような設計指針 が必要である． → 統合性と柔軟性を両立可能な設計指針
81. 81 5. 構成的統合性の導入 統合性と柔軟性を維持できるアーキテクチャを実現する上で，WebAssemblyが 有力な要素となる ポイント1：Wasmをアプリケーションに組み込むことで解決し得る 先行研究において下表の通り動的なコード更新手法について検討されてき たが，Wasmによる方式は見過ごされてきた [Ruckebusch 2018]． ポイント2: ポータブルなWasmの利用は多階層IoTシステムに適合する 動的なコード更新手法は，IoTデバイスの更新のみならず，IoTシステム全体 を通じて適用可能な方法が求められる [右図，Mikkonen 2021]． Wasmのポータブルな仕様がこのアーキテクチャを可能にし得る．
82. 82 5. 構成的統合性の導入 各層にWasm組み込むことで，技術的統合性を可能な限り損ねずにIoTシステム 全体に適用可能なコード変更の動的に更新可能なアーキテクチャを提案する IoTアプリケーションにWasmを組み込むことで，アプリ ケーション全体を再起動することなく，コードの変更を部 分的かつ動的に更新することができる． 上記の構成を前提に，各層を通じて同一のWasmバイナ リを用いることで，同一の処理をIoTシステム全体を通じ て実行可能にする．そのことで，技術的統合性を可能な限 り損なわずに，新技術を取り込むことができる． 課題1：より一般的なコードの動的更新手法 課題2：統合性と柔軟性を両立可能な設計指針 提案1：動的なIoTアプリケーション Wasmによるコード変更の動的な更新 提案2：同型なIoTシステム IoTシステム全体を通しての設計指針 デバイス エッジ クラウド デバイス ビルド サーバ コード変更を新たなWasmバイナリ として動的に更新する
83. 83 5.2. 提案と実装
84. Hardware 84 5. 構成的統合性の導入 Wasmを用いた動的なIoTアプリケーション：IoTシステムの各層を，アプリケー ションのコア機能とWasmランタイムによる補助的な部分とで構成する Hardware OS Application runtime Core application Wasm runtime Application IoTアプリケーションのコア となる箇所を示す． 典型的には，アプリケーショ ンコードを含むOSと一体と なるファームウェアとして静 的にデプロイされる． アプリケーションの部分的 な処理を実装するWasmで 動作する箇所． アプリケーション上で動作 するWasmランタイムによ り，Wasmによるコードが 実行される．また，その部分 のみ動的に更新が可能であ る．
85. 85 提案手法をElixir，Nerves，そして筆者が開発したコア機能内にWasmランタイ ムを組み込み部分的処理を実現可能なライブラリWasmtubeで実装する 5. 構成的統合性の導入 Hardware Raspberry Pi 4 Linux Elixir on Erlang VM Elixir app Wasm runtime Application Nervesは，IoT開発向け にカスタマイズされた Linux環境を提供するプ ラットフォームであり ，Erlang VMを利用して 作られている． Nerves, Nerves Project https://nerves-project.org/ Wasmtube Wasmtubeは筆者が開発 したライブラリで，Elixirに よるアプリケーションのコア 機能とWasmランタイムと をつなぐ役割を果たす． Elixirの実行基盤である Erlang VM上でWasmラ ンタイムを動作させ，Elixir アプリケーションから関数 呼び出しを通じて，Wasm で実装された処理を実行さ せることができる．
86. 86 Wasmtubeを用いた提案手法の動作フロー（1/2） 5. 構成的統合性の導入 1. OSがアプリケーションを起動 2. アプリがWasmtubeを起動 3. WasmtubeがWasmバイナリを読 み込む 4. Wasmtubeが読み込んだWasmを 用いてサンドボックスを作成 5. その時，サンドボックスに閉じた線型 メモリが作成される 6. 初期化処理の終了
87. 87 Wasmtubeを用いた提案手法の 動作フロー（2/2） 5. 構成的統合性の導入 7. アプリケーションからWasmで実装された処理を 関数として呼び出す 8. Wasmtubeは引数の値をWasmサンドボックス のメモリに書き出す 9. Wasmtubeは処理の実行をWasmへ移譲 10. Wasmサンドボックス内でメモリから引数デー タが読み込まれる 11. 引数を元にWasmで実装された処理が実行さ れる 12. 返り値をメモリに書き込む 13. Wasmtubeへ実行が戻る 14. Wasmtubeが結果をメモリから読み出す 15. アプリへ処理を戻す
88. Hardware 88 5. 構成的統合性の導入 Wasmを用いた同型なIoTシステム：前述のWasmを用いた動的なIoTアプリ ケーションをIoTシステムの各層を通じて同じく用いる設計指針 FreeRTOS, Linux, etc. App(C/C++, Rust, Elixir, etc.) Wasm runtime デバイス層 ESP32, Raspberry Pi, etc. Hardware iOS, Android, etc. App(Swift, Kotolin Flutter, Elixir, etc.) モバイルデバイス iPhone, Android, etc Hardware Linux, etc. App(C/C++, Rust, Elixir, etc.) エッジ層 Raspberry Pi, Baremetal, etc. Hardware Linux, etc. App(Node.js, Python, Elixir, etc.) クラウド層 Virtual Machine, Container, etc. Wasm runtime Wasm runtime Wasm runtime 同一のWasmバイナリが各層を通じてデプロイ，実行される Bridging library Bridging library Bridging library Bridging library
89. 89 Wasmを用いた部分的かつ動的な コード変更フロー 5. 構成的統合性の導入 1. 開発者はコード変更を新たなWasmバイ ナリとしてデプロイ 2. OSはファイルの更新をLinuxなら inotify(2)システムコールで検知し ，Wasmubeに通知 3. Wasmtubeは新しいWasmバイナリを 再読み込み 4. そして，古いサンドボックスを破棄 5. 新しいWasmでサンドボックスを再作成
90. 90 提案手法のWasmを用いた動的・同型なIoTシステムを，機械学習モデルを用いた実用的な システムとして実装する 5. 構成的統合性の導入 Hardware Hardware, OS, language, app Wasm runtime Hardware Hardware, OS, language, app Wasm runtime デバイス層 その他の層 機械学習モデルをWasmバイナリへとコンパイルするビルドパイプライン 前述の更新フロー
91. 91 5.3. 評価
92. 92 5. 構成的統合性の導入 Wasmへの処理の移譲による処理のオーバーヘッドは許容可能な範囲に留まる 実験方法 アプリケーションにWasmによる処理を組み込むことで 発生し得るオーバーヘッドを，Wasmを組み込んだ場合と そうでない場合とを比較することで計測する． 実験結果 Elixirのみで実装された処理と，Wasmへ同じ処理を移 譲した場合とでは，約200μs程度の処理のオーバーヘッ ドが起こることがわかった． 考察 提案手法によってもたらされるWasm呼び出しのオーバーヘッドは，特にこの後に実験する機械学習のような処理と比較 すると，相対的に非常に小さい．この程度の遅延が許容可能なIoTシステムであれば，部分的かつ動的にコードの更新が適 用可能であるメリットを選択可能であると考えられる．
93. 93 5. 構成的統合性の導入 Wasmを用いた同型なIoTシステムによって現実的なシステムを設計可能である 実験方法 IoTシステムの各層においてWasmバイナリ化された画 像認識モデルを実行し，処理にかかる時間を計測する． 実験結果 MobileNetV2の平均実行時間は，各層における実験環 境において最もスペックの低い，デバイス層を実装した Raspberry Pi 4上で588.69msであった． 考察 提案手法では各層を通じて単一のコードベースに基づくWasmバイナリを用いて画像認識を行う機械学習システムを実装 した．最も非力なデバイス層においても1FPS程度の処理速度が仕様上許容されるシステムであれば，Wasmを用いた同 型なIoTシステムが現実的なシステムを設計する上で有用であることが示された．
94. 94 5.4. 本章のまとめ
95. 95 5. 構成的統合性の導入 本章の貢献 1. Wasmを用いた動的・同型なIoTシステムの設計指針を提案・実装することで，構成的統合性を導入した 2. 設計指針を示すだけでなく，具体的かつ実用的なIoTシステムとして，広く利用されている機械学習モデ ルを用いたシステムを実装した 3. 定量的な評価を行うことで，現実的なIoTシステムを設計・実装する上で，提案手法が有用であることを 示した． 今後の展望 - 機械学習モデルをElixirで実装しWasmバイナリにコンパイルすることで，Wasmレベルだけでなく実装 言語レベルでも同型性を実現することが考えられる． - そのことで，より統合的なIoTシステムの実現が可能となる．
96. 96 6. 結論
97. 6. 結論 本研究の成果：Dynamic Isomorphic IoT System Architectureを提案し た 技術的統合性の導⼊ 動的な可変性の導⼊ 構成的統合性の導⼊ Dynamic Isomorphic IoT System Architectureの提案 提案1 提案2 提案3 統合性と柔軟性の両⽴ 柔軟性と統合性の両⽴ 本研究の成果 IoTシステム開発の複雑さを低減する 本研究全体を貫く⽬的 3章 4章，5章 5章
98. 98 6. 結論 一般的な適用可能性 本研究が提案したアーキテクチャは，具体的な実装に使用したElixirやErlang分散ネットワークを用いずと も，他の言語によっても実装可能である．さらに，Wasmによる拡張は，IoTシステムへの多数の言語による 機能の組み込みが可能となる汎用性を持っている． 社会的な意義 IoTシステムがますます活用されていくだろう今後において，異種混合性を当然視していたIoTシステム開 発に対してもたらし得る開発効率の向上や保守性の向上は，持続可能で柔軟性の高いIoT社会の実現に貢 献し得ると考える． 今後の展望 特にリソースの限られた環境においても有用である有用であるような軽量化や最適化をほどこすこと，動的 なコード変更が惹起し得る実行面・セキュリティ面での安全性をいかにして担保することを通じて，上記した 一般的な適用可能性について具体的に示していきたい．
99. 99 参照文献
100. 文献リスト（本スライドで直接参照したもののみ掲載） [AtomVM] Bettio, Davide. “AtomVM.” https://github.com/bettio/AtomVM. [Bansal 2020] S. Bansal et al., “Iot ecosystem: A survey on devices, gateways, operating systems, middleware and communication,” Int. J. Wireless Inf. Networks, vol. 27, no. 3, pp. 340–364, Sep. 2020. [Bauwens 2020] Bauwens, J., P. Ruckebusch, S. Giannoulis, I. Moerman, and E. D. Poorter. 2020. “Over-the-Air Software Updates in the Internet of Things: An Overview of Key Principles.” IEEE Communications Magazine 58 (2): 35–41. [Brown 2013] Stephen Brown and Cormac J Sreenan. Software updating in wireless sensor networks: A survey and lacunae. Journal of Sensor and Actuator Networks, Vol. 2, No. 4, pp. 717–760, November 2013. [Koren 2021] I. Koren, “A Standalone WebAssembly Development Environment for the Internet of Things,” in Web Engineering. Springer International Publishing, 2021, pp. 353–360. [Mikkonen 2021] T. Mikkonen et al., “Isomorphic Internet of Things Architectures With Web Technologies,” Computer, vol. 54, no. 7, pp. 69–78, Jul. 2021. [Ruckebusch 2016] Peter Ruckebusch, Eli De Poorter, Carolina Fortuna, and Ingrid Moerman. Gitar: Generic extension for internet-of-things architectures enabling dynamic updates of network and application modules. Ad Hoc Net- works, Vol. 36, pp. 127–151, January 2016. [Ruckebusch 2018] P. Ruckebusch et al., “Modelling the energy consumption for over-the-air software updates in LPWAN networks: SigFox, LoRa and IEEE 802.15.4g,” Internet of Things, vol. 3-4, pp. 104–119.