KOBESOFT | 組み込み・IoT開発

IoTプロトコル

OTA（無線アップデート）

無線経由でファームを更新する仕組み。

概要

OTA（Over-The-Air update、無線ファームウェアアップデート）は、有線接続なしに無線通信（Wi-Fi、Bluetooth、セルラーなど）を経由してデバイスのファームウェアやソフトウェアを更新する仕組みです。工場出荷後に現地設置されたIoTデバイスのバグ修正・機能追加・セキュリティパッチを、物理的なアクセスなしに実施できることから、現代のIoTシステムに不可欠な機能となっています。

OTAはスマートフォン（Android/iOSのソフトウェア更新）が一般的に知られていますが、組み込み機器ではより複雑な制約があります。

  • RAMは数十KB〜数MB程度で、ファームウェア全体をRAMに展開できない
  • 書き込み中に電源断が起きても「文鎮化（brick）」しない耐障害性が必要
  • 通信途中でのデータ改ざんを検証するセキュリティ機構が必要
  • 更新失敗時にロールバックできる設計が必要

これらの要件から、OTAは単純なファイルダウンロードではなく、ブートローダーとの連携・フラッシュパーティション設計・デジタル署名検証など、システム全体を考慮した設計が必要です。

歴史・背景

OTAの概念はスマートフォン以前から存在し、1990年代の携帯電話（GSM規格）でSIMカードのプロビジョニングに使われていました（OTA-SIM）。2000年代にはスマートフォンのOS更新がOTAで行われるようになりました。

IoT機器へのOTA展開は2010年代に本格化しました。きっかけの一つは2016年のMiraiボットネット事件です。デフォルトパスワードのままのIoTカメラが大規模なDDoS攻撃に悪用され、業界全体でセキュリティパッチを迅速に配布する必要性が認識されました。

2019年以降、IETFはSUIT（Software Updates for Internet of Things）ワーキンググループでOTAの標準化を推進し、RFC 9019（アーキテクチャ）、RFC 9124（マニフェスト情報モデル）、RFC 9397（SUITマニフェスト形式）が策定されました。ESP-IDF、Zephyr RTOS、Mbed OSなど主要な組み込みフレームワークがOTAを標準機能として提供しています。

技術仕様

デュアルバンク（A/B）パーティション構成

最も安全なOTA設計は、ファームウェア領域を2つに分割するデュアルバンク方式です。

フラッシュメモリレイアウト（ESP32の例）:
┌──────────────────────────────────────────┐
│ Bootloader（0x1000〜）                   │ ← 変更しない
├──────────────────────────────────────────┤
│ パーティションテーブル（0x8000）          │
├──────────────────────────────────────────┤
│ NVS（設定保存）                          │
├──────────────────────────────────────────┤
│ OTA Data（どちらのバンクを起動するか）    │
├──────────────────────────────────────────┤
│ OTA 0（バンクA：現在実行中のファーム）    │ ← 現在起動中
├──────────────────────────────────────────┤
│ OTA 1（バンクB：新ファーム書き込み先）    │ ← ここに書く
└──────────────────────────────────────────┘

OTAプロセス:

  1. バンクB（OTA 1）に新ファームウェアを書き込む
  2. 書き込み完了後、チェックサム/署名を検証
  3. OTA Dataパーティションに「次回はバンクBから起動」を記録
  4. 再起動
  5. ブートローダーがバンクBから起動
  6. 起動成功確認後、「バンクBが有効」を確定（コミット）
  7. 起動失敗の場合はバンクAにロールバック

セキュリティ要件

要件実装方法
通信経路の暗号化HTTPS/TLS 1.2以上
ファームウェアの完全性SHA-256ハッシュ検証
ファームウェアの正真性RSA/ECDSA デジタル署名
ダウングレード防止バージョン番号の単調増加チェック
改ざん検知セキュアブート（Secure Boot）

SUITマニフェスト

IETFのSUIT仕様では、ファームウェアの配布情報を「マニフェスト」として定義します。

{
  "suit-manifest-version": 1,
  "suit-manifest-sequence-number": 42,
  "suit-common": {
    "suit-components": [[{"bstr": "firmware.bin"}]],
    "suit-shared-sequence": [
      {"suit-directive-override-parameters": {
        "suit-parameter-vendor-identifier": "...",
        "suit-parameter-class-identifier": "..."
      }}
    ]
  },
  "suit-install": [
    {"suit-directive-fetch": null},
    {"suit-condition-image-match": null}
  ],
  "suit-integrated-payload": {
    "firmware.bin": "https://update.example.com/fw/v2.0.bin"
  }
}

動作原理

ESP32でのOTA実装フロー

#include "esp_ota_ops.h"
#include "esp_http_client.h"
#include "esp_https_ota.h"

// 証明書（HTTPSサーバー検証用）
extern const uint8_t server_cert_pem_start[] asm("_binary_ca_cert_pem_start");

void ota_task(void *pvParameter) {
    ESP_LOGI(TAG, "OTA開始");
    
    esp_http_client_config_t http_config = {
        .url = "https://ota.example.com/firmware/latest.bin",
        .cert_pem = (const char *)server_cert_pem_start,
        .timeout_ms = 10000,
        .keep_alive_enable = true,
    };
    
    esp_https_ota_config_t ota_config = {
        .http_config = &http_config,
    };
    
    // OTA実行（ダウンロード→書き込み→検証を一括実施）
    esp_err_t ret = esp_https_ota(&ota_config);
    
    if (ret == ESP_OK) {
        ESP_LOGI(TAG, "OTA成功。再起動します");
        esp_restart();
    } else {
        ESP_LOGE(TAG, "OTA失敗: %s", esp_err_to_name(ret));
    }
    
    vTaskDelete(NULL);
}

// アプリ起動時の確認処理
void app_main(void) {
    // OTA後の起動確認（これをしないとロールバックされる）
    esp_ota_img_states_t ota_state;
    const esp_partition_t *running = esp_ota_get_running_partition();
    
    if (esp_ota_get_state_partition(running, &ota_state) == ESP_OK) {
        if (ota_state == ESP_OTA_IMG_PENDING_VERIFY) {
            // 正常起動を確認
            if (check_app_valid()) {
                esp_ota_mark_app_valid_cancel_rollback();
                ESP_LOGI(TAG, "OTA検証OK: アップデート確定");
            } else {
                esp_ota_mark_app_invalid_rollback_and_reboot();
            }
        }
    }
}

デルタアップデート

フラッシュ容量が小さい機器向けに、差分（デルタ）のみ送信する方式もあります。

従来OTA: 512KB（フルファームウェア）を送信
デルタOTA: 50KB（差分パッチ）のみ送信
→ 通信量90%削減、省電力

デルタ生成ツールにはbsdiff、janpatch（組み込み向け）などがあります。

# PCでデルタパッチ生成
bsdiff firmware_v1.0.bin firmware_v2.0.bin firmware_v1_to_v2.patch

# デバイス側でパッチ適用
bspatch firmware_v1.0.bin firmware_v2.0.bin firmware_v1_to_v2.patch

FOTA（Firmware OTA）vs SOTA（Software OTA）

種別対象例
FOTAマイコンのファームウェアESP32のアプリケーション
SOTALinuxのパッケージ/コンテナRaspberry PiのDEB更新
COTA設定のみパラメータ変更（ファーム更新不要）

用途・ユースケース

大規模デプロイ（スマートメーター）

電力会社が数万台のスマートメーターに一斉パッチを配布する場合、MQTTを通じてOTAをトリガーします。

# MQTTでOTAトリガーを配信
import paho.mqtt.client as mqtt

client = mqtt.Client()
client.connect("iot-broker.example.com", 1883)

# 全メーターにOTA通知を送信
ota_command = json.dumps({
    "action": "ota_update",
    "version": "2.1.0",
    "url": "https://ota.example.com/meter/fw_v2.1.0.bin",
    "sha256": "a1b2c3d4...",
    "signature": "BASE64_ECDSA_SIGNATURE"
})

client.publish("meters/+/cmd/ota", ota_command, qos=1, retain=False)

ローリングアップデート

一度にすべてのデバイスを更新するリスクを避け、段階的に展開します。

# デバイスグループを分けて段階展開
update_groups = [
    ("canary", 0.01),   # まず1%のデバイスで試験
    ("early", 0.10),    # 問題なければ10%に展開
    ("standard", 0.50), # 50%に展開
    ("all", 1.00),      # 全台展開
]

for group_name, ratio in update_groups:
    deploy_to_group(group_name, ratio, firmware_version="2.1.0")
    success_rate = monitor_health(group_name, duration_hours=24)
    
    if success_rate < 0.99:
        rollback_group(group_name)
        raise Exception(f"{group_name} グループで問題発生。ロールバック")
    
    print(f"{group_name}: {success_rate:.1%} 成功 → 次フェーズへ")

セキュアブートとの連携

ESP32のセキュアブートV2では、公開鍵をefuseに焼き付け、署名なしファームウェアの起動を拒否します。

1. 開発者が秘密鍵で署名:
   espsecure.py sign_data --keyfile private_key.pem \
     --version 2 --output firmware_signed.bin firmware.bin

2. デバイスがeSECURE BOOT有効の場合:
   ブートローダーが公開鍵でファームウェアの署名を検証
   → 検証失敗 → 起動拒否
   → 検証成功 → 起動許可

実装・開発のポイント

OTAサーバーの設計

# FastAPIで簡易OTAサーバーを実装
from fastapi import FastAPI, HTTPException
from fastapi.responses import FileResponse
import hashlib

app = FastAPI()

@app.get("/firmware/check")
async def check_update(device_version: str, device_model: str):
    """バージョン確認エンドポイント"""
    latest = get_latest_version(device_model)
    
    return {
        "current_version": device_version,
        "latest_version": latest.version,
        "update_required": latest.version != device_version,
        "download_url": f"https://ota.example.com/firmware/{latest.filename}",
        "sha256": latest.sha256,
        "size_bytes": latest.size
    }

@app.get("/firmware/{filename}")
async def download_firmware(filename: str):
    """ファームウェアダウンロードエンドポイント"""
    filepath = f"/var/firmware/{filename}"
    if not os.path.exists(filepath):
        raise HTTPException(status_code=404)
    
    return FileResponse(
        filepath,
        media_type="application/octet-stream",
        headers={"Content-Disposition": f"attachment; filename={filename}"}
    )

よくある失敗とその対策

問題原因対策
OTA中に電源断予期せぬ停電デュアルバンクでロールバック
メモリ不足でOTAできないRAM不足チャンク書き込み、スワップ領域
証明書期限切れCA証明書の有効期限証明書バンドル更新機能を実装
ダウングレード攻撃バージョン確認なし単調増加カウンター（antirollback）
電波不安定による部分DLWi-Fi切断レジューム（Range: bytes=N-）対応

Raspberry PiでのOTA（Linux）

#!/bin/bash
# Raspberry Pi での OTA スクリプト

VERSION_URL="https://ota.example.com/rpi/latest_version"
CURRENT_VERSION=$(cat /etc/firmware_version)
LATEST_VERSION=$(curl -s $VERSION_URL)

if [ "$CURRENT_VERSION" != "$LATEST_VERSION" ]; then
    echo "アップデートあり: $CURRENT_VERSION → $LATEST_VERSION"
    
    # 署名付きパッケージをダウンロード
    wget -O /tmp/update.tar.gz.sig \
        "https://ota.example.com/rpi/update_${LATEST_VERSION}.tar.gz.sig"
    wget -O /tmp/update.tar.gz \
        "https://ota.example.com/rpi/update_${LATEST_VERSION}.tar.gz"
    
    # 署名検証
    openssl dgst -sha256 -verify /etc/ota_public_key.pem \
        -signature /tmp/update.tar.gz.sig /tmp/update.tar.gz
    
    if [ $? -eq 0 ]; then
        tar -xzf /tmp/update.tar.gz -C /tmp/
        /tmp/install.sh
        echo $LATEST_VERSION > /etc/firmware_version
        reboot
    fi
fi

他技術との比較

項目OTA手動書き込みJTAG書き込み
物理アクセス不要必要必要
大規模展開◎××
セキュリティ○（実装次第）◎◎
確実性○◎◎
コスト低（運用コスト削減）高（人件費）高（設備）
文鎮化リスクあり（対策要）低低

ブートローダーとの連携設計が正しく行われていれば、OTAは最も効率的なファームウェア配布手段です。フラッシュメモリの書き換え寿命（ウェアレベリング）も考慮し、ウェアレベリング対応のファイルシステムと組み合わせることが推奨されます。

関連用語

MQTT HTTP / HTTPS ブートローダー フラッシュメモリ ESP32 FreeRTOS U-Boot ウェアレベリング

参考リンク

RFC RFC 9019: A Firmware Update Architecture for Internet of Things RFC RFC 9124: A Manifest Information Model for Firmware Updates in IoT Devices ESP-IDF OTA ドキュメント Mbed TLS（TLS/証明書ライブラリ） SUIT マニフェスト（IETF）
用語辞典トップへ戻る