BluetoothモジュールにおけるOTAの必要性
フィールドでのOTA（Over-the-Air）ファームウェアアップデートは、展開されたBluetoothモジュールにとってもはや任意ではありません。センサーキャリブレーションのバグ、プロトコルスタックの脆弱性、または新機能の要件が数万台のフィールドユニットに影響を与える可能性があります。OTAなしでは、物理的なリコールまたは現地サービスしか選択肢がありません。
NordicのDFU（Device Firmware Update）over BLEは、nRF52シリーズモジュールで最も広く展開されているOTAメカニズムです。本稿では、アーキテクチャ、実装選択肢、および本番展開前に理解すべき障害モードを解説します。
OTAアーキテクチャ：ブートローダーとアプリケーション領域
| 領域 | 典型的なサイズ | 内容 |
|---|---|---|
| MBR | 4 KB | エントリーポイント |
| ブートローダー | 24–32 KB | DFUロジック、署名検証 |
| SoftDevice | ~140 KB | Nordic S132/S140 |
| アプリケーション | 残りフラッシュ | ユーザーファームウェア |
| DFUステージングエリア | ~アプリと同サイズ | 受信イメージバッファ |
シングルバンク vs デュアルバンクDFU
デュアルバンク（推奨）：受信イメージを別のフラッシュバンクに保存。ダウンロード中も既存アプリが動作継続。完全なイメージ受信・検証後にバンクをスワップ。中断しても旧ファームウェアが保持される。
シングルバンク：ブートローダーがアプリ領域を消去して直接書き込む。フラッシュ容量ペナルティなし。ただし電力喪失時にデバイスがブリックする可能性がある。
イメージ署名とセキュリティ
署名なしOTAはセキュリティ上のリスクです。NordicのセキュアブートローダーはECDSA-p256署名を使用します。更新パッケージ（.zip）は秘密鍵で署名され、ブートローダーに組み込まれた対応する公開鍵のみが検証できます。
重要な点：製造時にブートローダーフラッシュ領域をロック（APPROTECT）し、公開鍵やブートローダーコードの読み取りを防止してください。
DFUパッケージ構造
{
"manifest": {
"application": {
"init_packet_data": {
"fw_version": 3,
"hw_version": 52,
"sd_req": [0x0101], // 必要なSoftDeviceバージョン
"type": "application"
}
}
}
}
sd_reqを設定することで、互換性のないSoftDeviceバージョンへのファームウェア適用を防止できます。
障害モード分析
| 障害モード | 根本原因 | 対策 |
|---|---|---|
| 更新中の電力喪失 | バッテリー消耗 | 開始前にバッテリー残量確認；デュアルバンク使用 |
| 接続切断 | 干渉、距離 | DFUプロトコルは再開をサポート |
| バージョンダウングレード | 古いファームウェアの誤展開 | fw_versionを単調増加させる |
まとめ
OTAファームウェアアップデートは、1年以上フィールドで動作することが期待されるBluetoothモジュール展開にとって重要な機能です。テストカバレッジへの投資が最も重要です。ラボでは動作するが10m範囲、低バッテリー、または接続切断で失敗するOTAメカニズムは本番対応していません。