アップデート中断時の更新プロセスの記録によるサーバーからのファイル再受信時の重複排除

IoT デバイスは継続的な運用維持のためにバグの修正や, 機能の追加を目的としたアップデートが必要不可欠である. しかし, アップデート中に, 例えばネットワーク障害によりデバイスとのネットワーク接続が切断されると更新プロセスが中断され, 一部のプログラムのみ更新が適用された不完全な状態に陥る.この状況において, 更新プロセスを最初から実行する方法では, 更新に要する時間が延長され, ネットワーク帯域やエネルギーの浪費を招く. 本稿では, サーバーとIoT デバイス間のネットワーク接続が切断されることにより更新が中断された際, デバイスの更新プロセスの記録を行う事による中断された箇所から更新を再開する手法を提案した. サーバー側ではIoT デバイスごとの送信したファイル名を記録, IoT デバイス側では更新プロセス中で実行している関数名や更新中のアップデートファイル名をテキストフォーマット形式のファイルに記録する. この記録された関数名と更新ファイル名をもとに, デバイスが復旧した際に中断された箇所から更新を再開することが可能となる. 評価実験ではアップデートの途中でIoT デバイスに強制的に再起動を行い, 通信障害によりサーバーとの通信を中断し, 更新が途切れる状況を再現した. 提案の適用前と適用後で, 最初から更新を行う場合に要する時間を比較した. 実験では, 1 台のIoT デバイスに4 つの更新ファイルを順次送信し, 各ファイルで10 回ずつ中断を発生させた結果を平均値として算出した. 送信したのは, main.py の約7.67[KB], Sensor.py の約2.03[KB], Module.py の約4.02[KB], Setting.pyの約0.14[KB] の4 つのファイルである. main.py での中断時における更新時間は, 提案の適用前で約2.9秒, 適用後で約4.2 秒となり, 約45[%] 増加した. Sensor.py での中断時における更新時間は, 提案の適用前で約4.7 秒, 適用後で約4.5 秒となり, 約6[%] 短縮された. Module.py での中断における更新時間は, 提案の適用前で約4.9 秒, 適用後で約4.7 秒となり, 約6[%] 短縮された. Setting.py での中断時における更新時間は, 提案の適用前で約4.9 秒, 適用後で約4.4 秒となり, 約11[%] 短縮された. アップデートが中断なく正常に行われる場合での更新時間は通常の更新で約2.0 秒, 提案を含んだ更新で約4.7 秒となり, 約138[%]増加した. 更新に要する時間が増加した理由は, 提案ソフトウェアの処理が実行されたためである. ...