Vol.2021-SE-207 No.32
2021/3/2

情報処理学会研究報告
IPSJ SIG Technical Report

IoT デバイス内アプリケーションの開発効率向上のために
コードの変更を動的に適用する方式の提案と実装
栗林 健太郎1,2,a)

山崎 進3

力武 健次4,1

丹 康雄2

概要：IoT デバイスは多様な用途において増え続け，2030 年にはその数が 1250 億に達すると見込む調査報
告がある．増え続ける多様な需要を満たすためには，IoT デバイスの開発効率の向上が必要であり，そのための開発プラットフォームが多数現れている．IoT デバイス内アプリケーションの開発において，開発者によるコードの変更を適用することで生じる動作の変更が意図した通りであるかどうかを確認するためには，変更内容をターゲットとなるデバイスへ適用し実際に動作させる必要がある．既存方式では，更新
内容の生成および適用に加えて，デバイスの再起動に時間を要するため，迅速な開発サイクルの実現が困難である．本研究では，先行研究に基づきコードの変更をデバイスへ適用する方式について（1）ファーム
ウェアイメージの全体を適用する方式，（2）ファームウェアイメージの差分を適用する方式，（3）アプリ
ケーションコードを動的に適用する方式の 3 つに分類した．その上で，開発効率の向上を目的として（3）を動的な性質を持つ言語によって実装し得る方式として位置づけ直して提案するとともに実装し，各方式について更新に要する時間を比較検討した．その結果，提案方式は既存方式に比べて更新に要する時間が95%短くなった．

A Method to Realize a Rapid Development Cycle of IoT Applications
by Dynamically Applying Local Code Changes to the Devices
Kentaro Kuribayashi1,2,a)

Susumu Yamazaki3

Kenji Rikitake4,1

Yasuo Tan2

Abstract: Software development eﬃciency should be improved to meet the ever-increasing demand for IoT
devices, which is expected to reach 125 billion by 2030. Application of the code changes to the target devices
and running the code on the devices are necessary to check whether the behavioral changes caused by thecode changes by the software developers in IoT applications are as intended. The existing method takes timeto generate and apply the updated contents and restart the device, making it diﬃcult to realize a rapid development cycle. In this study, we have classiﬁed the methods of the code changes application to the devices
into three categories based on the previous research: (1) rewriting the entire ﬁrmware image; (2) updating
by applying the diﬀerences in the ﬁrmware image; and (3) applying the application code dynamically. To
improve the development eﬃciency, we proposed and implemented the third method as it can be implemented
by a language with dynamic characteristics, and compared the time required to update each method. Our
research results show that the proposed method reduces the required time for updating by 95% compared tothe existing method.

1

2

3

4

GMO ペパボ株式会社 ペパボ研究所
Pepabo R&D Institute, GMO Pepabo, Inc., Fukuoka City,
Fukuoka 810-0001, Japan
北陸先端科学技術大学院大学
Japan Advanced Institute of Science and Technology, Nomi
City, Ishikawa 923-1292, Japan
北九州市立大学
University of Kitakyushu, Kitakyushu City, Fukuoka
808–0135, Japan
力武健次技術士事務所ⓒ 2021 Information Processing Society of Japan

1. はじめに
IoT デバイスは年々増え続け，2030 年にはその数が 1250
億に達すると見込む調査報告がある [1]．また同調査報告a)Kenji Rikitake Professional Engineer’s Oﬃce, Setagaya City,
Tokyo 156-0045 Japan
antipop@pepabo.com

1Vol.2021-SE-207 No.32
2021/3/2

情報処理学会研究報告
IPSJ SIG Technical Report

は，スマートホーム機器のような家庭での利用はもとより，医療用途や製造業等における産業用途，エネルギーやモビリティに関わる社会インフラ基盤にいたるまで，多岐にわたる領域において IoT の活用が進むとしている．それらの表 1 IoT デバイスを構成するハードウェアおよびソフトウェア，それらに対応するプラットフォームの整理

Table 1 Organization of the hardware and software that makeup IoT devices and the platforms that support them.

増え続ける多様な IoT デバイスの需要を満たすためには，

Components

開発者が IoT デバイスを開発する効率を向上させることがSensors必要である．

Actuators
Hardwareハードウェアおよびソフトウェアの両面にわたる開発効

Microprocessors
Power Supply

多数現れている．ESP8688（およびその後継の ESP32）に

IoT Applications

よる開発キット [2]，Arduino [3]，Raspberry Pi [4]，Beagle

Network Protocol Stackのプラットフォームは，ハードウェア開発効率向上のた[2–6]

Network Interfaces

率の向上のため，IoT デバイスの開発プラットフォームがBone [5]，NVIDIA Jetson [6] 等がその例である．それら

Platforms

SoftwareOperating System

[7–9]
—

Hardware Drivers

め，マイクロプロセッサや電源とともに，センシングやア
クチュエーションのための様々な規格に対応する入出力イなるためである．さらに，IoT アプリケーションのプロト

ンタフェイスや，Wi-Fi や Bluetooth モジュールといったタイピング時や開発時には，小規模な変更による頻繁な更ネットワークインタフェイスを提供している．ソフトウェ

新を必要とする．そのため，IoT アプリケーションの開発

ア開発効率向上のため，開発元やオープンソースソフト

効率の向上を実現するには，開発者によるコードの変更をウェア（OSS）等により Arduino IDE [7]，ESP-IDF [8]，効率的にデバイスへ適用することが課題となる．

Platform.io [9] といった統合的な開発環境が提供されてお開発者によるコードの変更をデバイスへ適用する方式にり，また，それらは開発者によるコードの変更を有線ある

ついては，これまで多くの先行研究が行われている．[15,16]

いは無線ネットワークを経由して行える OTA（over-the-は，コードの変更をデバイス上へ適用する方式を，書き換

air）による更新機能を備えている．上述した IoT デバイ

え対象に基づき（1）IoT アプリケーションの実装に用いらスを構成するハードウェアおよびソフトウェア，それられるスクリプト言語の特性を利用した動的なコード書き換に対応する開発プラットフォームを表 1 の通り整理できえ，（2）デバイス上で動作する仮想機械内で実行されるコー

る [10, p.180]*1 ，[11]*2 ．

ドの書き換え，（3）デバイス上のファームウェアイメージ

表 1 に示した IoT アプリケーションの開発には，パーソの書き換え，（4）デバイス上のネイティブコードへの動的

ナルコンピュータ向けのアプリケーションや Web アプリ

リンクの書き換えの 4 つに分類している．また，コードのケーション等の開発とは異なる困難さがある．パーソナル

変更をデバイスへ適用する状況について [15] は，デバイス

コンピュータ向けのアプリケーション開発においては，開の配備前における開発・検証，および，デバイスの配備後発者の使用するホストとターゲットとなるホストのプラッ

における機能追加・更新・拡張の 2 つに分類しており，そトフォームおよびアーキテクチャが同一である場合，開発

れぞれについて更新頻度を整理している．それらの先行研者の使用するホスト上で動作確認を行える．また，Web ア

究は，利用可能なネットワーク帯域，ハードウェアスペッ

プリケーション開発においては，開発者の使用するホスト

ク，電源容量・確保において制約の厳しい IoT デバイスにとターゲットとなるホストのプラットフォームやアーキテ

対して，いかにして安全かつ効率のよい更新が可能である

クチャが異なったとしても，VirtualBox [13] や Docker [14]かを主たる課題としている．そのため，上述の（1）および等の仮想化技術を用いることで，開発者のホスト内で動作（2）についてはそれらの制約のもとでの実現は困難である確認を完結する手法が発展している．一方で，IoT アプリ

として，検討対象外としている [15, 16]．また，更新の目

ケーションの開発においては，開発者が変更したコードの的をデバイスの配備後におけるセキュリティ対策，バグ修

動作を確認するためには，なんらかの方法で変更内容を

正，機能拡張においているため，本研究が課題とする IoT

ターゲットとなるデバイスへ適用し，IoT アプリケーショ

アプリケーション開発効率の向上は目的とされていない．

ンの動作を変更する必要がある．ターゲットとなるマシン

本研究では，IoT アプリケーションの開発効率の向上とのプラットフォームやアーキテクチャに加えて，操作対象いう観点から，先行研究におけるコードの変更をデバイスとなるハードウェア構成が開発者の使用するホストとは異へ適用する方式を，書き換え対象に基づき（1）ファーム
ウェアイメージの全体を適用する方式，（2）ファームウェ*1*2

ハードウェアを構成する要素として電源を [10] の定義に加えた．
IoT の文脈では，IoT アプリケーションはエンドユーザ向けのア
プリケーションを指す [12] が，本研究では [11] に従い IoT デバ
イス内アプリケーションを IoT アプリケーションと呼称する．

ⓒ 2021 Information Processing Society of Japan

アイメージの差分を適用する方式，（3）アプリケーション
コードを動的に適用する方式の 3 つに分類し直す．ファームウェアイメージの書き換えに基づく更新について，差2

Vol.2021-SE-207 No.32
2021/3/2

情報処理学会研究報告
IPSJ SIG Technical Report分による効率的な更新を実現する研究が進んでいる [17]．
そのため，全体を更新する方式を（1），差分を更新する方式を（2）として 2 つに分けて検討することが妥当である．

IoT アプリケーションの開発効率を向上を目的として，前述の IoT デバイスの開発プラットフォームを用いたプロト
タイピングが広く行われている．それらのプラットフォー
ムは，開発者によるコードの変更をデバイスへ迅速に適用するために，有線あるいは無線ネットワークを経由したアップデートの方法を提供している．また，Raspberry

Pi や Beagle Bone，NVIDIA Jetson などのように，Linux
ベースのファームウェアが動作するハードウェアスペッ
クを備えたプラットフォームも存在している．IoT アプリ
ケーションのプロトタイピング時や開発時においては，スを実現できた．
本研究の貢献は以下の通りである．

( 1 ) IoT アプリケーションの開発効率の向上を目的とした場合，動的言語によるアプリケーションを構成するコードの動的な変更が有効であることを示した．

( 2 ) 提案方式の実装を行い，ファームウェアイメージを更新する方式と比較した上で，更新に要する時間の短縮という定量的な指標において優位性を示した．

( 3 ) 本研究の示した結果が，IoT デバイスの開発プラットフォームにとって IoT アプリケーションを構成するコードの動的な書き換えをサポートすることが優位性となることの示唆となった．

クリプト言語や仮想機械上で動作する言語のような，ネイ本論文の構成を述べる．2 章で，開発者によるコードのティブコードと比較してリソースを相対的に多く要求する

変更をデバイスへ適用する方式について先行研究に基づき言語を用いることは，開発効率の向上への寄与を目的とし検討し，課題を述べる．3 章で，既存方式の課題を解決すて許容可能である．そのため，更新対象としての IoT アプ

る提案方式について述べる．4 章で提案手法について実験

リケーションを構成するコードは，ネイティブコードはもに基づく評価を行い，5 章でまとめる．

とより，スクリプト言語や仮想機械上で動作する言語による動的な性質を持つコードであっても，同等の機能を果た

2. 本研究の背景

すとみなせる．よって，IoT アプリケーションの開発効率

本章では，本研究の背景について述べる．はじめに，2.1の向上という観点からは，アプリケーションのコードの変節で先行研究について検討する．次に，2.2 節で本研究の更をデバイスへ動的に適用する方式を，上述の方式（3）に観点について述べる．最後に，2.3 節で本研究の観点に基まとめて検討することが妥当である．

づいて開発者によるコードの変更をデバイスへ適用する方

本研究は，IoT アプリケーションの開発効率の向上を目

式を整理する．

的とした，開発者によるコードの変更を IoT アプリケー
ションを構成するコードに対して動的に適用する方式につ2.1 先行研究

いて提案する．また，先行研究における，デバイスの配備後

IoT デバイスは，一度配備された後も継続的にソフトという強い制約下での更新方式という観点においては十分

ウェアの更新が必要である．また，更新に際しては IoT デには検討されてこなかった，スクリプト言語や仮想機械上バイスのリソース制約の厳しさが課題となる．[20] は，IoTで動作する言語による動的な性質を持つコードを用いて提デバイスの製品ライフサイクルを初期・中期・後期の 3 段案方式を実装する．具体的には，開発者により変更された階に分類した上で，各段階において有効なセキュリティ対

IoT アプリケーションを部分的に構成するコードを，ファー策についてまとめている．IoT デバイスのソフトウェア更ムウェアイメージの生成を行うことなくネットワークを経

新は製品ライフサイクルの全段階を通して必要であると由してデバイスに適用した上で IoT アプリケーションの更し，リソース制約の厳しい IoT デバイスに対していかにし新を行う．提案方式の実装には，Elixir [18] を用いる．IoTて効率的かつ安全に更新を実行できるかという観点で先行デバイスの開発プラットフォームである Nerves [19] は，仮研究を検討している．[21] は，Wireless Sensor Networks

想機械上で動作する Elixir を開発言語として採用しているを構成するデバイスへのソフトウェア更新について，広範ため，提案方式を仮想機械上で動作する言語を用いて実現なサーベイを行った．デバイスのデプロイ後のフェーズにできることに加えて，デバイス上のファームウェアイメー

着目し，フィールドに配置された，直接はアクセスできな

ジの全体および差分による更新に対応しているため，本研

い多数のデバイスに対するソフトウェア更新を可能とする究の整理した方式を網羅できるからである．検証に際して様々なプロトコルを検討している．[11] は，IoT デバイス

は，デバイス上のファームウェアイメージの書き換えを全のソフトウェア更新のプロセスを更新内容の検証，および，体として行う方式と部分的に行う方式とをベースラインと更新内容の配布の 2 つのフェーズに分類した上で，リソーして，更新に要する時間を提案方式の実装と比較検討した．

ス制約の厳しい IoT デバイスに対してはエネルギー消費量

その結果，既存方式がそれぞれ 66.88 秒，70.63 秒であっのより少ない方式が有効であることを示している．

たのに対して，提案方式では 3.30 秒で開発者によるコード

上記を背景に，開発者によるコードの変更をデバイスへの変更をデバイスへ適用することができ，95%の速度向上

適用する方式について様々な提案がなされている．Rucke-ⓒ 2021 Information Processing Society of Japan3

Vol.2021-SE-207 No.32
2021/3/2

情報処理学会研究報告
IPSJ SIG Technical Reportbusch らは，[15, 16] においてコードの変更をデバイス上へする先行研究の積み重ねから，ファームウェアイメージに適用する方式を，書き換え対象に基づき（1）IoT アプリ

よる更新については全体と差分による方式に分けることがケーションの実装に用いられるスクリプト言語の特性を利妥当であると考える．その結果，方式を以下の 3 つに分類用した動的なコード書き換え，（2）デバイス上で動作する

する．

仮想機械内で実行されるコードの書き換え，（3）デバイス
上のファームウェアイメージの書き換え，（4）デバイス上のネイティブコードへの動的リンクの書き換えの 4 つに分類している．このうち（3）の方式は，更新対象となる( 1 ) ファームウェアイメージの全体を適用する方式( 2 ) ファームウェアイメージの差分を適用する方式( 3 ) アプリケーションコードを動的に適用する方式

ファームウェアのサイズが他の方式と比較して大きいこ[23] は，IoT デバイスの開発に用いられているボードを網とから，ネットワーク経由での更新内容の転送に時間を要

羅的に総覧した上で，それらをスペックに応じて Low-end，し，デバイスへの適用において電力をより多く消費する．

Middle-end，High-end の 3 つに分類している．製品化さそのため [17, 22] は，（3）の方式による更新を効率化する

れた IoT デバイスの実装に際しては，デバイスの用いられために，ファームウェアイメージの生成プロセスをソースる環境の制約やコストによって Low-end から Middle-end

コードレベルでの類似性の向上，および，ファームウェアのハードウェアが選ばれたとしても，開発環境としては，イメージの差分生成のアルゴリズムの改善の 2 つの観点でたとえば Raspberry Pi のような High-end に分類される

整理し，[22] はファームウェアイメージの差分のサイズをハードウェアを用いることは可能である．また，IoT アプ

従来方式よりも縮小する方式を提案している．

リケーションのプロトタイピング時や開発時においては，
スクリプト言語や仮想機械上で動作する言語のような，ネ2.2 本研究の観点

イティブコードと比較してリソースを相対的に多く要求す本研究は，IoT アプリケーションの開発効率の向上といる言語を用いることは，開発効率の向上への寄与を目的とう観点から，開発者によるコードの変更をデバイスへ適して許容可能である．そのため，更新対象としての IoT ア

用する方式を検討する．上記で検討した先行研究は，利用プリケーションを構成するコードは，ネイティブコードは可能なネットワーク帯域，ハードウェアスペック，電源容

もとより，スクリプト言語や仮想機械上で動作する言語に量・確保等において制約の厳しい IoT デバイスに対して，

よる動的な性質を持つコードであっても，開発時においていかにして安全かつ効率のよいソフトウェア更新が可能では同等の機能を果たすとみなせる．よって，本研究におけあるかを主たる課題としている．そのため，上述の開発者

る IoT アプリケーションの開発効率の向上という観点からによるコードの変更をデバイスへ適用する方式を提案しは，アプリケーションのコードの変更をデバイスへ動的にた [15, 16] は，方式（1）および（2）について，それらの適用する方式を，上述の方式（3）にまとめて検討すること研究が対象とする強い制約の課されたデバイスにおいてはが妥当である．

実現困難であるとして，検討対象外としている．前述の通り [20] は，IoT デバイスのライフサイクル全体を通した3. 提案方式と実装

ソフトウェア更新が必要であることを述べている．また，本章では，提案方式とその実装について述べる．はじめ

コードの変更をデバイスへ適用する状況について [15] は，に，3.1 節で提案方式について述べる．次に，3.2 節で提案

デバイスの配備前における開発・検証，および，デバイス方式の実装について述べる．

の配備後における機能追加・更新・拡張の 2 つに分類しており，それぞれについて更新頻度を整理している．しかし，

3.1 提案方式

それらの先行研究はソフトウェア更新の主たる目的をデバ

本研究は，IoT アプリケーションの開発時における開発

イスの配備後におけるセキュリティ対策，バグ修正，機能効率の向上を目的とした，開発者によるコードの変更を拡張等に置いているため，IoT アプリケーション開発効率

IoT アプリケーションを構成するコードに対して動的に適の向上を目的とするソフトウェア更新の方式については検用する方式について提案する．先行研究においても，2.3 節

討されていない．そのため，本研究の観点においては先行で見た通り，アプリケーションコードを動的に適用する方研究に加えてさらなる検討を要する．

式自体は提案されてきた．しかし，その目的はデバイスの配備後という制約下での更新方式という観点が主であり，2.3 方式の整理

開発効率の向上という観点は検討されてこなかった．ま本研究では，上述した IoT アプリケーションの開発効率

た，利用可能なネットワーク帯域，ハードウェアスペック，の向上という観点から，先行研究の提案した方式を整理し電源容量・確保等において制約の厳しい IoT デバイスにお直す．先行研究における（1）から（4）の方式について，

いては，必要とするリソースが相対的に大きくなるスクリ（1）（2）および（4）をひとつにまとめる．また，（3）に関

プト言語や仮想機械上で動作する言語のような動的な性質ⓒ 2021 Information Processing Society of Japan4

Vol.2021-SE-207 No.32
2021/3/2

情報処理学会研究報告
IPSJ SIG Technical Reportを持つ言語は検討外とされてきた．本研究では，IoT アプ
リケーションのプロトタイピング時や開発時という状況を前提とすることで，開発効率の向上のためにハードウェア
を比較的自由に選択した上でリソース要求の大きな言語を用いることができる方式として，アプリケーションコード
を動的に適用する方式を提案し，その有用性を主張する．
図 1 は，2.3 節で整理した（1）ファームウェアイメージの全体を適用する方式，および，（2）ファームウェアイメー
ジの差分を適用する方式の処理の流れを示している．まず，開発者によるコードの変更に基づき，新たなファーム
ウェアイメージを生成するフェーズが実行される．ファームウェアイメージの全体であるか差分であるかの違いはあるが，ビルドフェーズがあること自体は変わらない．次に，ファームウェアイメージをデバイスへ送信し適用するフェーズが実行される．ここでは，ネットワークを経由して送信することを前提としている．最後に，新しいファー

図 2 提案方式のシーケンス図

Fig. 2 Sequnce diagram of the proposed method

ムウェアイメージをロードするためにデバイスが再起動するフェーズが実行される．

3.2 実装図 2 は，提案方式の処理の流れを示している．開発者に提案方式の実装には，プログラミング言語として Elixir

よるコードの変更に基づき，IoT アプリケーションを実行[18] を ，IoT デ バ イ ス の 開 発 プ ラ ッ ト フ ォ ー ム と し てするランタイムに対してコードを送信した上で，デバイス

Nerves [19] を用いる．Elixir は動的型付けの関数型言語で上で動作する IoT アプリケーションを動作させたまま変更

あり，大規模な並行プロセス動作を可能にするため，同様されたコードを適用することで，アプリケーションの更新の目的で開発された言語システムである Erlang/OTP [24]を行う．図 1 とは異なり，コードを逐次的に送信・適用すの動作する仮想機械 Erlang VM 上で動作するよう設計さるため，ファームウェアイメージのようなひとまとまりのれている．Nerves は，Elixir を Erlang VM 上で動作する

成果物を生成・送信するフェーズは存在しない．また，IoTのに必要十分なサイズの Linux によるファームウェアを提アプリケーションを実行するランタイムにおけるコードの供するプラットフォームであり，Raspberry Pi や Beagle

適用であるため，IoT デバイス自体の再起動を要しない．

Bone 等を用いて IoT デバイスのプロトタイピングや開発を迅速に行える仕組みを提供している．また，仮想機械上で動作する Elixir を開発言語として採用しているため，ア
プリケーションコードを動的に適用する方式を実現できる．さらに，ファームウェアイメージの全体を適用する方式に加えてファームウェアイメージの差分を適用する方式にも対応しているため，本研究の整理した方式を網羅できる．以上の理由から，本研究では Elixir と Nerves を用いて開発した IoT アプリケーションを対象に，開発者による
コードの変更をデバイスに対して動的に適用する方式を実装した．
プログラミング言語 Elixir の実行基盤となる仮想機械である Erlang VM は，実行時にオブジェクトコードを動的に置き換えることができる機能を提供している [25]．コードの置き換えは，Erlang VM 上で動作するノードと呼ばれるプロセスを通じて行われる．ノードは遠隔手続き呼び出し（RPC: Remote Procedure Call）に対応しており，遠隔のホスト上で動作するノード上に対して RPC を実行す

図 1 既存方式のシーケンス図ることで，そのホスト上の Erlang VM への操作を実行でFig. 1 Sequence diagram of the existing methods

きる．その機能を用いて，本実装では IoT デバイス上で動作するアプリケーションの動作を変更するためのコードⓒ 2021 Information Processing Society of Japan5

Vol.2021-SE-207 No.32
2021/3/2

情報処理学会研究報告
IPSJ SIG Technical Reportの適用を実現する．具体的には，RPC を通じて Elixir から Erlang の code:load_binary/3 関数をモジュール名，

表 2

方式（1）および（2）における更新のフェーズと計測方法

Table 2 Update phases of the method (1) and (2) and themeasurement methods.

ファイル名，オブジェクトコードのバイナリを引数として呼び出すことで，Erlang VM 上にロードされたコードを置

Phase

Measurement Methods

き換える．

1. Firmware Build (full/patch)time command

2. Firmware Deployment

time command

3. Device Reboot

ping command

4. Application Reboot

ncat command

本実装では，IoT デバイス上で動作する Erlang VM 内で動作するノードへ開発者の用いるホストから接続し，上述の RPC を通じて Erlang VM 上で動作するコードの置き換えを行う．Erlang VM 上で動作するオブジェクトコー

（2）については mix firmware.patch コマンドを用いてドの置き換えが起こった際，古いコードには old，新しいファームウェアイメージを生成し，mix update コマンド

コードには current というラベルが付され区別される．そを用いてデバイスへの配備を行う．（3）については，3.2 節の状況で，再度コードの置き換えが起こると，old のコーで述べた実装を用いる．

ドは破棄され current のコードが old となるとともに，破それぞれの方式を比較するための指標として，開発者に棄されたコードを参照しているプロセスは強制的に実行終よるコードの変更をデバイスに適用した上で，IoT アプリ

了される [25]．本実装では，開発者によるコードの変更がケーションが変更を取り込んだ状態で動作するまでに要す

確実に適用されるよう，連続して 2 回の適用を行っている．

る時間を用いる．更新対象の IoT アプリケーションとしまた，本報告の執筆時点においては，ファイルの更新時刻て，TCP ソケット経由でクライアントから受け取った文字や内容を考慮しない実装となっているため，開発者が開発列をそのまま返却するサーバ（いわゆる Echo サーバ）をの対象とするファイルすべて（具体的には，開発者が直接実装し，IoT デバイス上で動作させる．コードを更新したの開発対象とする lib/ディレクトリ以下に置かれる Elixir

際，（1）および（2）についてはデバイスの再起動に加えてのコードを含むファイル）を更新対象とする実装になって

IoT アプリケーションの起動が発生し，その間は IoT アプ

いる．そのため，本実装によるコードの適用後には，開発

リケーションはもとよりデバイスへの通信も遮断される．
，

対象となるコードによって生成された Erlang VM 上のプ

一方で，（3）については，前述の通り IoT アプリケーショ

ロセスの再起動が発生する．

ンが動作する Erlang VM 上のプロセスの再起動が発生す

なお，実装については GitHub 上のリポジトリ*3 ，およるが，デバイスの再起動は発生しないためデバイスへの通び，Elixir のライブラリリポジトリである Hex*4 でオープ

信に関しては影響がない．しかしその場合でも，IoT アプ

ンソースソフトウェア（OSS）として公開している．

リケーションが TCP 接続を要する実装である場合，更新

4. 実験と評価の間は対象アプリケーションとの通信が遮断される．そのため，コードの変更を適用した後に再び IoT アプリケー

本章では，提案方式について実験に基づき既存方式と比ションと TCP 通信が確立することをもって，いずれの方較検討することで評価する．はじめに，4.1 節で実験の対式においても動作が再開したとみなすことが，評価の条件

象と方法について述べる．次に，4.2 節で既存方式と提案をそろえるという観点で妥当である．そのため，IoT アプ

方式について実験した結果を示す．最後に，4.3 で評価結

リケーションのレベルで通信するオーバーヘッドの少ない果についての発展的な議論を述べる．

機能として Echo サーバを実装し，実験に用いる．
評価指標とした，開発者によるコードの変更をデバイス

4.1 対象と方法に適用した上で，IoT アプリケーションが変更を取り込ん

本章における実験は，2 章で検討した既存方式と 3 章でだ状態で動作するまでに要する時間は，方式（1）および検討した提案方式とを対象に行う．それぞれ以下の通りで（2）については表 2 の通り，方式（3）については表 3 のあり，（3）が提案方式である．

通り内訳を分解できる．また，それぞれのフェーズにかか( 1 ) ファームウェアイメージの全体を適用する方式( 2 ) ファームウェアイメージの差分を適用する方式( 3 ) アプリケーションコードを動的に適用する方式（1）および（2）については，IoT アプリケーションの実る時間を計測する方法についても記載した．また，実験に用いた環境は，開発用のホストおよび IoT デバイスについて，それぞれ表 4 の通りである．

4.2 実験結果装に用いた Nerves が提供する機能を用いてコードの変更

4.1 節で述べた対象と方法に基づき，既存方式と提案方を適用する．（1）については mix firmware コマンドを，式について，開発者によるコードの変更がデバイスに適用*3*4

https://github.com/kentaro/mix_tasks_upload_hotswap
https://hex.pm/packages/mix_tasks_upload_hotswapⓒ 2021 Information Processing Society of Japan

され，IoT アプリケーションが変更を取り込んだ状態で動作するまでに要する時間を計測した．その結果は，表 5 の6

Vol.2021-SE-207 No.32
2021/3/2

情報処理学会研究報告
IPSJ SIG Technical Report
表 3 方式（3）における更新のフェーズと計測方法のコードの依存関係を考慮することなくコードの動的な置

Table 3 Update phases of the method (2) and the measure-

き換えを行うため，更新対象のコード間に複雑な依存関係

ment methods.

がある場合は，不整合を起こす可能性があると考えられる．

Phase

Measurement Methods

また，本実装では IoT アプリケーションが依存する外部モ

1. Code Deployment

time command

ジュールの追加・更新・削除には対応していないため，依2. Application Reboot

ncat command

存モジュールに関するコードの変更は適用されない．ただし，不整合が起きたり依存モジュールに関する変更があっ

表 4 実験環境

Table 4 Experiment Environment

Dev Host

IoT Device

たりした場合でも，ファームウェアイメージを更新することで容易に対応できる．また，プロトタイピング時や開発

Item

Speciﬁcation

時のように小規模な変更を頻繁に適用する状況において，Model

MacBook Pro 13-inch, 2018

提案方式によって開発効率を向上できることは実験結果かCPU

2.7 GHz Quad-Core Intel Core i7

Memory16 GB 2133 MHz LPDDR3

Model

Raspberry Pi 3 Model B

Network

Wired LAN

提案方式の一般性について確認する．提案方式は，本研

Platform

Nerves 1.7.2

究で用いたものとは異なる言語によっても実装可能である

ら確かであるため，提案方式の有効性を損なう問題ではな
いと考える．

と考えられる．本研究は IoT アプリケーションの開発効通りである．また，各方式における更新対象となったファ率の向上を目的としているため，プロトタイピング時や開イルサイズを表 6 に示した．

発時における利便のために，相対的にスペックの高い開発

開発者によるコードの変更を IoT デバイスに適用し，IoT

プラットフォームを利用可能であることが前提である．そアプリケーションが変更を取り込んだ状態で動作するまでのため，ネイティブコードを直接実行する場合にくらべ相に要した時間は，方式（1）では合計で 66.88 秒，方式（2）対的にリソースを多く要求する Erlang VM のような仮想では 70.63 秒であったのに対し，提案方式である（3）で機械による実行環境を利用可能である．よって，同様に他は 3.30 秒であり，提案方式が既存方式より短かった．方式の仮想機械を前提とした実行基盤を持つ言語を用いても，（1）および（2）はファームウェアイメージの生成，デバ

提案方式について実装が可能であると考えられる．また，イスへの適用，IoT デバイスの再起動のそれぞれにおいて

Erlang VM を用いる言語自体の IoT デバイスにおける利時間を要しており，提案方式はそれらの時間を要する処理用可能性についても，プロトタイピング時や開発時にとどを必要としないため優位であることが確かめられた．方式

まらない適用が可能である見込みがある．Nerves の開発元

（2）は更新対象のファイルサイズが（1）の 7 分の 1 である

では実運用を前提とした開発を行っており，実際に利用事にも関わらず，ファームウェアイメージの差分の生成およ例も報告されている [26]．また，[27] は AtomVM というび適用に方式（1）よりも時間を要している．
（1）と違ってIoT デバイス上で動作することに特化した Erlang VM を

差分を生成すること，および，差分に基づく適用を実行す

開発しており，[23] が Middle-end と分類する ESP8266 のることにオーバーヘッドが存在するからであると考えられ後継である ESP32 上で動作する．よって，今後，提案方る．また，方式（3）に関する Application Reboot につい式が配備後のデバイスに対しても適用できる可能性もあるては，計測できなかった．更新対象の Echo サーバは更新と期待できる．

の実行時に新しいコードを読み込んで再起動するが，本実

5. おわりに験によっては起動中の通信が遮断された状態を捉えられない速度で起動が完了したためである．
なお，実験のプロトコルおよび結果に関する詳細はGitHub 上のリポジトリ*5 で公開している．

本研究は，IoT アプリケーションの開発効率の向上という観点から，開発者によるコードの変更をデバイスへ適用する方式を提案し実装した．先行研究に基づき方式を整理した上で，提案方式と既存方式とを実験により比較検討し4.3 議論た．そのた結果として，開発者によるコードの変更を IoT

4.2 節で検討した実験結果により，提案方式が開発者によ

デバイスに適用し，IoT アプリケーションが変更を取り込るコードの変更を適用する速度を向上させることで，IoTんだ状態で動作するまでに要した時間について，提案方式

アプリケーションの開発効率の向上が見込めることを確認

は 95%の改善を実現できた．IoT アプリケーションのプロ

できた．一方で，提案方式の実装については議論の余地がトタイピング時や開発時においては小規模な変更を頻繁残されている．実験に用いた提案方式の実装は，変更対象に適用することから，提案方式が実現した改善結果は IoT*5

https://github.com/kentaro/
ipsj-sigse207-paper-experimentsⓒ 2021 Information Processing Society of Japan

アプリケーションの開発効率の向上に大きく寄与するものと考える．このことから，IoT デバイスの開発プラット

7

Vol.2021-SE-207 No.32
2021/3/2

情報処理学会研究報告
IPSJ SIG Technical Report
表 5

各方式によるコードの更新に要した時間の比較（単位：秒）

Table 5 Time comparison of code application between the existing methods and the
proposed methods (in sec.).
MethodFirmwareFirmwareCode

DeviceApplication

Build

Deployment

Deployment

RebootReboot

29.45

14.49

—

22.51

0.63

66.88

100

(2) Firmware Update (patch)

30.09

17.46

—

22.54

0.54

70.63

105

—

—

3.30

—

N/A

3.30

5

∗

Ratio column shows the ratios when the total time of the method (1) is set to 100.

表 6

各方式における更新対象ファイルのサイズ

Table 6 Size of the target ﬁles to deploy.
MethodSize(1) Firmware Update (full)42MB(2) Firmware Update (patch)

6MB(3) Proposed Method

12KB

[13]
[14]

[15]

フォームにとって，提案方式が示した IoT アプリケーショ
ンを構成するコードの動的な書き換えをサポートすることは，競争優位性となり得ると考えられる．その意味においても，本研究の意義を評価できると考える．

[16]

参考文献

[2]

[3]
[4]

[5]

[6]

[7]
[8]

[9]
[10]

[11]

[12]

Ratio∗(1) Firmware Update (full)(3) Proposed Method

[1]

Total

IHS Markit. The internet of things: a movement, nota market. https://cdn.ihs.com/www/pdf/IoT_ebook.
pdf, 2017. Accessed: 2021-2-2.
Development Boards — Espressif Systems. https://www.espressif.com/en/products/devkits. Accessed:
2021-1-24.
Arduino. https://www.arduino.cc/. Accessed: 20211-24.
The Raspberry Pi Foundation. Teach, learn, and makewith raspberry pi. https://www.raspberrypi.org/.
Accessed: 2021-1-24.
Beagleboard.org - community supported open hardware
computers for making. https://beagleboard.org/.
Accessed: 2021-1-24.
Nvidia embedded systems for next-gen autonomousmachines.
https://www.nvidia.com/en-us/
autonomous-machines/embedded-systems/. Accessed:
2021-2-2.
Software — arduino. https://www.arduino.cc/en/
software. Accessed: 2021-2-2.
Esp-idf programming guide - esp32 - esp-idf programming guide latest documentation.
https://docs.
espressif.com/projects/esp-idf/. Accessed: 20212-2.
Real-time bidding platform — ssp, dsp solutions - platform.io. https://platform.io/. Accessed: 2021-2-2.
Lee, Edward Ashford and Seshia, Sanjit A. Introduction to Embedded Systems, A Cyber-Physical Systems
Approach, Second Edition. MIT Press, 2017.
J Bauwens, P Ruckebusch, S Giannoulis, I Moerman,
and E D Poorter. Over-the-air software updates in theinternet of things: An overview of key principles. IEEE
Commun. Mag., Vol. 58, No. 2, pp. 35–41, February
2020.
Sharu Bansal and Dilip Kumar. Iot ecosystem: A surveyⓒ 2021 Information Processing Society of Japan

[17]

[18]
[19]
[20]

[21]

[22]

[23]

[24]
[25]

[26]
[27]

on devices, gateways, operating systems, middleware andcommunication. Int. J. Wireless Inf. Networks, Vol. 27,
No. 3, pp. 340–364, September 2020.
Oracle vm virtualbox. https://www.virtualbox.org/.
Accessed: 2021-1-24.
Empowering App Development for Developers —Docker. https://www.docker.com/. Accessed: 20211-24.
Peter Ruckebusch, Eli De Poorter, Carolina Fortuna,
and Ingrid Moerman. Gitar: Generic extension forinternet-of-things architectures enabling dynamic updates of network and application modules. Ad Hoc Networks, Vol. 36, pp. 127–151, January 2016.
Peter Ruckebusch, Spilios Giannoulis, Ingrid Moerman,
Jeroen Hoebeke, and Eli De Poorter. Modelling the energy consumption for over-the-air software updates in lpwan networks: Sigfox, lora and ieee 802.15.4g. Internetof Things, Vol. 3-4, pp. 104–119.
Konstantinos Arakadakis, Pavlos Charalampidis, Antonis Makrogiannakis, and Alexandros Fragkiadakis.
Firmware over-the-air programming techniques for iot
networks – a survey. September 2020.
The elixir programming language.
https://elixir-lang.org/. Accessed: 2021-1-17.
Nerves platform. https://www.nerves-project.org/.
Accessed: 2021-1-11.
Narges Yousefnezhad, Avleen Malhi, and Kary Främling.
Security in product lifecycle of iot devices: A survey.
Journal of Network and Computer Applications, Vol.
171, p. 102779, December 2020.
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.
Ondrej Kachman, Marcel Balaz, and Peter Malik. Universal framework for remote ﬁrmware updates of lowpower devices. Comput. Commun., Vol. 139, pp. 91–102,
May 2019.
M O Ojo, S Giordano, G Procissi, and I N Seitanidis. A
review of low-end, middle-end, and high-end iot devices.
IEEE Access, Vol. 6, pp. 70528–70554, 2018.
Erlang programming language. https://www.erlang.
org/. Accessed: 2021-1-24.
Chapter 14:
Compilation and code loading.
https://erlang.org/doc/reference_manual/code_loading.html. Accessed: 2021-1-18.
Case studies.
https://www.nerves-project.org/
case-studies. Accessed: 2021-1-24.
Davide Bettio.
Atomvm.
https://github.com/
bettio/AtomVM. Accessed: 2021-1-19.

8