KOBESOFT | 組み込み・IoT開発

量産・品質・認証

フィールド更新

出荷後の機器を更新して改善する。

概要

フィールド更新（Field Update）とは、製品の出荷後に設置済みの機器のソフトウェア・ファームウェアを更新する機能・運用の総称です。組み込み・IoT機器の文脈ではOTA（Over-The-Air）アップデートとも呼ばれ、無線通信を通じてリモートでファームウェアを書き換える仕組みを指します。

フィールド更新の目的は多岐にわたります。

  • バグ修正: 出荷後に発覚したソフトウェア不具合の修正
  • セキュリティパッチ: 脆弱性への対応
  • 機能追加: 新機能のソフトウェアアップデートによる追加
  • 設定変更: 動作パラメータの更新（閾値・通信設定等）
  • 認定対応: 規制変更に伴うソフトウェア修正

フィールド更新機能のない機器は、出荷後の脆弱性修正・不具合修正に訪問修理が必要となり、運用コストが大幅に増加します。特にIoTデバイスは数千〜数百万台規模で展開されることがあり、全台を訪問修理することは現実的ではありません。一方でフィールド更新自体がセキュリティリスクにもなりえるため、OTAセキュリティ・ファームウェア署名・セキュアブートとの組み合わせが不可欠です。

歴史・背景

フィールド更新の概念は1980〜90年代のPCアップデート（フロッピー・CD-ROM配布）から始まりましたが、組み込み機器へのOTA展開が本格化したのは2000年代の携帯電話（フィーチャーフォン）時代からです。

2007年のiPhoneリリースは組み込み機器のファームウェアアップデートを「製品価値の継続的向上」という観点で大きく変えました。スマートフォンのOSアップデートにより、出荷後の機器が数年間にわたって新機能を獲得するビジネスモデルが確立されました。

2010年代のIoT普及に伴い、センサー・ゲートウェイ・産業機器へのOTA展開が拡大しました。MQTT・CoAP等のIoT向けプロトコルとAWS IoT・Azure IoT Hub等のクラウドプラットフォームがOTAのインフラを提供するようになりました。

2020年代には車載OTA（SOTA: Software Over-The-Air / FOTA: Firmware Over-The-Air）が普及し、テスラ等の電気自動車が走行中もリモートでソフトウェアを更新するモデルが定着しました。セキュリティ観点からも、製品の「出荷後のセキュリティ維持責任」が製造業者に求められるようになり、フィールド更新はIoT機器の必須機能となりました。

技術仕様

OTAアップデートの方式

方式説明適用場面
フルイメージアップデートファームウェア全体を書き換える大幅な変更・確実性重視
差分アップデート変更分のみを転送（delta update）低帯域・バッテリー節約
モジュール別アップデート特定機能モジュールのみ更新マルチコアMCU・複合機器
設定データ更新パラメータ・証明書のみ更新頻繁な設定変更

デュアルバンク構成（A/Bアップデート）

フィールド更新で最も重要な設計原則は「更新失敗時のロールバック保証」です。デュアルバンク（A/Bパーティション）構成が標準的なアプローチです。

フラッシュメモリ構成例（デュアルバンク）:

アドレス空間:
┌─────────────────────────────┐
│ ブートローダー（不変）        │ 0x00000000〜0x0000FFFF (64KB)
├─────────────────────────────┤
│ ファームウェア バンクA（現在） │ 0x00010000〜0x0008FFFF (512KB)
├─────────────────────────────┤
│ ファームウェア バンクB（更新） │ 0x00090000〜0x0010FFFF (512KB)
├─────────────────────────────┤
│ フラグ領域（起動バンク指定）  │ 0x00110000〜0x0011FFFF (64KB)
├─────────────────────────────┤
│ アプリデータ領域              │ 0x00120000〜0x001FFFFF (896KB)
└─────────────────────────────┘

更新フロー:
1. バンクBに新ファームウェアをダウンロード
2. 署名検証・整合性確認（SHA-256・RSA署名）
3. フラグ領域を「次回バンクBで起動」に設定
4. 再起動 → ブートローダーがバンクBを起動
5. バンクB起動成功 → フラグを「バンクBが正常」に更新
   (失敗した場合: ブートローダーがバンクAにロールバック)

OTAプロトコルスタック

HTTP/HTTPS ベースのOTA

// ESP-IDF (ESP32) OTA 実装例
#include "esp_ota_ops.h"
#include "esp_http_client.h"

void perform_ota_update(const char *update_url) {
    esp_http_client_config_t http_config = {
        .url = update_url,
        .cert_pem = server_cert_pem,  // TLS証明書
        .timeout_ms = 5000,
    };
    
    esp_ota_handle_t ota_handle = 0;
    const esp_partition_t *update_partition = 
        esp_ota_get_next_update_partition(NULL);
    
    // OTA書き込み開始
    esp_err_t err = esp_ota_begin(update_partition, 
                                   OTA_WITH_SEQUENTIAL_WRITES, 
                                   &ota_handle);
    if (err != ESP_OK) {
        ESP_LOGE(TAG, "OTA開始失敗: %s", esp_err_to_name(err));
        return;
    }
    
    // HTTP でファームウェアをダウンロードしながら書き込み
    esp_http_client_handle_t client = 
        esp_http_client_init(&http_config);
    esp_http_client_open(client, 0);
    
    char buf[1024];
    int data_read;
    while ((data_read = esp_http_client_read(client, buf, 
                                              sizeof(buf))) > 0) {
        err = esp_ota_write(ota_handle, buf, data_read);
        if (err != ESP_OK) break;
    }
    
    esp_http_client_cleanup(client);
    
    // OTA完了・検証
    err = esp_ota_end(ota_handle);
    if (err == ESP_OK) {
        esp_ota_set_boot_partition(update_partition);
        ESP_LOGI(TAG, "OTA成功: 再起動します");
        esp_restart();
    } else {
        ESP_LOGE(TAG, "OTA失敗: %s", esp_err_to_name(err));
    }
}

MQTT ベースのOTA

AWS IoT Core・Azure IoT Hub等のクラウドプラットフォームはMQTT経由でOTAジョブを配信するサービスを提供します。

MQTT OTA フロー（AWS IoT Jobs）:
1. クラウド側: OTAジョブ作成（更新対象デバイス・FW URLを指定）
2. デバイス: $aws/things/{thingName}/jobs/notify をサブスクライブ
3. クラウド→デバイス: ジョブ通知（MQTTメッセージ）
4. デバイス: FW URL（署名付きS3 URL等）からHTTPSでダウンロード
5. デバイス: 書き込み完了後、ジョブ結果を MQTT でレポート
6. クラウド: フリート全体の進捗を[フリート管理](/embedded/glossary/fleet-management/)ダッシュボードで確認

差分アップデート（Delta Update）

大容量ファームウェアを低帯域（LoRaWAN・NB-IoT等）で更新する場合、差分アップデート（バイナリ差分）が有効です。

差分アップデートの仕組み:
1. サーバー: bsdiff等で旧FWと新FWの差分ファイルを生成
   （全体1MB → 差分20KB程度になることも）
2. デバイス: 差分ファイルをダウンロード
3. デバイス: 旧FW（フラッシュ上）と差分から新FWを再構成（bspatch）
4. デバイス: 再構成した新FWを検証・書き込み

転送量の削減例:
- フルイメージ: 512KB
- 差分イメージ: 20〜50KB（バグ修正・マイナー変更の場合）
→ LoRaWAN（DR5: 3.9kbps）での転送時間: 512KB → 約18分 / 50KB → 約1.7分

動作原理

更新プロセスの信頼性確保

フィールド更新の最大のリスクは「更新中断による文鎮化（Brick）」です。これを防ぐための設計原則を示します。

原子性の保証 ファームウェア書き込みは「完全に書き込まれた状態」または「全く書き込まれていない状態」のいずれかのみが有効な状態となるよう設計します。書き込み途中の不完全な状態で起動しないよう、書き込み完了後にのみ起動フラグを更新します。

ウォッチドッグによる障害検出 ウォッチドッグタイマーを使用して、新ファームウェアが正常に起動・動作したことを確認します。起動後の自己診断に失敗した場合、ウォッチドッグがリセットをかけ、ブートローダーが旧バージョンにロールバックします。

// 起動後の自己診断とOTA確定
void app_startup_check(void) {
    // 前回がOTAアップデート後の初回起動かを確認
    if (is_ota_pending_verification()) {
        // 自己診断テスト実施
        bool health_ok = run_selftest();
        bool comm_ok = test_server_connectivity();
        
        if (health_ok && comm_ok) {
            // 新ファームウェアを「確定」として記録
            confirm_ota_update();
            report_ota_success_to_server();
        } else {
            // 自己診断失敗 → 旧バージョンにロールバック
            rollback_to_previous_firmware();
            esp_restart();  // 旧バージョンで再起動
        }
    }
    // ウォッチドッグ起動（定期的にキック）
    start_watchdog_timer(30000);  // 30秒タイムアウト
}

低電力デバイスでのOTA

ディープスリープで動作するIoTデバイスのOTAは、通常の更新手順が適用できません。電池で動作するデバイスのOTA戦略として以下があります。

  • スリープ解除タイミングでの更新確認: 定期的な接続時に更新の有無を確認し、更新がある場合はスリープを保留して更新を実施する
  • メンテナンスウィンドウの設定: 深夜等の利用が少ない時間帯に更新を実施する
  • 段階的ロールアウト: フリート全体の一部（例: 10%→30%→100%）に順次配信し、問題が発生した場合に早期に停止する

用途・ユースケース

スマートメーターのフィールド更新

電気・ガス・水道のスマートメーターは数百万台規模で展開されており、全台への訪問更新は不可能です。LTE-M・Wi-SUN経由のOTAが標準装備となっており、計量法への対応や省エネ改善をフィールドアップデートで実現します。更新には計量法上の「検定」が必要な場合があり、認証機関との連携が必要です。

産業用機械のフィールド更新

製造装置・工作機械のPLC・組み込みコントローラへのフィールド更新では、稼働中の機械の停止を最小化するために「ホットスワップ可能な更新」が求められます。OPC UAプロトコルを通じた安全な更新確認と、工場の計画メンテナンス窓に合わせた更新スケジューリングが重要です。

車載ソフトウェアのOTA

車両のECU（電子制御ユニット）へのOTAは AUTOSAR・UNECE WP.29 規制に準拠する必要があります。更新中の車両の安全を確保するため、走行中は非安全関連のECUのみ更新可能、安全関連ECUは停車・エンジン停止時のみ更新という制御が必要です。

実装・開発のポイント

OTAセキュリティ設計

フィールド更新はセキュリティリスクでもあります。悪意あるファームウェアを書き込まれると機器全体を制御される危険があります。

  • ファームウェア署名: RSA-2048 または ECDSA P-256 でファームウェアに署名し、デバイス側で署名を検証する
  • セキュアブート: ブートローダーが検証済みファームウェアのみを起動する
  • TLS/DTLS: ダウンロード通信を暗号化し、中間者攻撃を防ぐ
  • バージョン管理: ダウングレード攻撃防止のために最小バージョン番号（セキュリティバージョン番号）を管理する

フリート管理との統合

大規模IoTデプロイメントでは、OTAとフリート管理を統合した運用が必要です。更新の進捗（成功・失敗・未更新）をリアルタイムで把握し、失敗デバイスを自動的に特定・対応します。

他技術との比較

更新方式通信帯域コストリスク適用場面
OTA（無線）要（数KB〜数MB）低（通信費のみ）更新失敗リスクIoT・スマートフォン
有線OTA（USB/UART）不要低低製造ライン・サービス
訪問更新不要非常に高（人件費）最低物理アクセス必須機器
自動更新（CI/CD）要低ステージング検証で低減大量デプロイ

関連用語

OTA（無線アップデート） ファームウェア OTAセキュリティ ファームウェア署名 量産（マスプロダクション） フリート管理 MQTT CoAP HTTP / HTTPS TLS / DTLS セキュアブート マイコン（MCU） フラッシュメモリ ブートローダー ディープスリープ LTE-M（Cat-M1） NB-IoT LoRaWAN

参考リンク

NIST SP 800-193 プラットフォームファームウェア耐性ガイド GSMA IoT Security Guidelines
用語辞典トップへ戻る