IoT機器が普及する今、製品を遠隔で最新状態に保つOTA（Over-The-Air）は、セキュリティ維持や利便性向上のための必須要件となりました。しかし、その実現には通信プロトコルから最新の法規制対応まで、検討すべき事項が多岐にわたります。

　中でも設計者を悩ませるのが、「どのようなシステム構成でOTAを実現するか」という点ではないでしょうか。本記事では、OTAの全体像を整理しつつ、特にその根幹となるメモリ構成や更新方式の選び方について詳しく解説します。

• 
  
  

  OTA（Over The Air）とは？車が自動アップデートする仕組みや事例

  

  OTAの活用事例やメリットはこちら！

• 
  
  

  OTA導入のガイドブック！更新プロセスから構成要素まで徹底解説

  

  OTAの基本プロセスやシステム構成はこちら！

1. OTAの全体構成とアップデート手順

　OTAを実現するためには、単に「通信ができる」だけでなく、クラウドサーバからエッジデバイスまでを繋ぐ複数の構成要素が連携する必要があります。まずは、その全体像を見ていきましょう。

1-1. OTAを構成する主要な要素と役割

　OTAのシステム構成は、以下の図のように「クラウドサーバ」「無線通信モジュール」「メインMCU（マイコン）」の大きく3つのセクションで成り立っています。

　これらの構成に加え、製品の仕様や運用要件によっては以下のハードウェアを追加するケースがあります。ここでは、どのような場合に追加が必要になるのか、その判断基準を整理します。

1-2. OTAアップデートの実行フロー

　では、実際のOTAアップデートがどのようなプロセスで進むのか、「サブMCUが更新対象となる場合」を例に、3つのフェーズに分けて確認していきましょう。

　※FW：ファームウェア

フェーズ1：更新開始の通知 & 確認

　まず、クラウドサーバからメインMCUに対してOTA開始の通知を送ります。通知を受けたメインMCUは、製品側（サブMCU）に対して更新の可否を確認します。 ここでは、システムが更新を受け入れられる状態にあるか、バッテリー残量や必要なリソースが確保されているかといった前提条件をチェックし、確実なアップデートのための準備を整えます。

フェーズ2：更新ファームウェアを転送 & 検証

　準備が整うと、実際のファームウェアデータの転送が始まります。 大容量のファームウェアを一度に送信すると通信エラーのリスクが高まるため、小さなブロックに分割して送信することで通信の安定性を高めます。

　また、各ブロックを受信するごとにデジタル署名の検証を行い、データが改ざんされていないか、欠落なく届いているかを厳格にチェックします。

フェーズ3：更新の適用

　すべてのデータ転送と検証が完了した後、メインMCUからサブMCUへ更新処理の指示を出します。 これにより、サブMCU側でリセットや書き換え処理が行われ、最終的に新しいファームウェアでの動作が開始されます。

　構成によっては、メインMCUが受信したファームウェアを一度、外付けフラッシュメモリへバッファリングし、その後にメインMCUとサブMCU間で分割転送を行うパターンもあります。これにより、通信環境が不安定な場合でも、より安全に更新プロセスを進めることが可能になります。

2. ファームウェアアップデート方式の比較

　ファームウェアをアップデートする際、MCUのメモリをどう分割・管理するかには、主に3つのパターンがあります。それぞれの方式にはコストや安全性における一長一短があるため、製品の要件（メモリ容量や許容できるダウンタイムなど）に応じて最適なものを選択する必要があります。

　※FW：ファームウェア

　具体的な方式の解説に入る前に、これらすべての基盤となる「ブートローダ」の役割を整理しておきましょう。

2-1. ブートローダの基本機能

　一般に「ブート（boot）」とは「bootstrap（自力で立ち上がる）」の略であり、ストレージからメインプログラムをメモリへ読み込む処理を指します。 マイコン開発におけるブートローダは、電源投入時に最初に実行されるプログラム領域（リセットベクタ）であり、OTAにおいては「アプリケーション領域の正当性検証」や「ファームウェアの更新処理」を実行する、極めて重要な役割を持っています。

2-2. 各アップデート方式の詳細

　それでは3つの方式について、それぞれ「正常フロー」と「異常パターン」を詳しく見ていきましょう。

①シングルバンク半面更新　

　フラッシュメモリを「更新前ファームウェア用の領域（メイン面）」と「更新ファームウェア用の領域（バッファ面）」に分割して管理する方式です。

　実行領域とは別の領域を持つため異常発生時も元の状態で復旧できるメリットがありますが、アプリ実行中に書き換えができず、使用可能なメモリ容量が実質半分になるというデメリットがあります。

• 正常フロー

　※FW：ファームウェア

図4. シングルバンク半面更新 正常フロー

　①外部から更新ファームウェアを受け取り、バッファ面に書き込みます。

　②バッファ面に書き込んだ更新ファームウェアの署名情報等の検証を行い、正しいファームウェアであることを確認します。

　③ソフトウェアリセット後、ブートローダが起動し、再度バッファ面の更新ファームウェアの正当性を確認後、メイン面へファームウェアのコピーを行います。

　④次回のファームウェア更新に備えてバッファ面を消去します。

　⑤メイン面へコピーした更新ファームウェアを検証後、新しく更新されたファームウェアで動作します。（セキュアブート）

• 
  異常パターン

　※FW：ファームウェア

図5. シングルバンク半面更新 異常パターン

　この方式では、書き込み中や検証時に電源遮断などの予期せぬトラブルが発生しても、常にメイン面かバッファ面のいずれかに有効なファームウェアが存在します。そのため、対象製品が起動不能になるリスクを回避し、即座に元の状態でシステムを復旧させることが可能です。正常に再起動した後は、再びクラウドサーバからデータをダウンロードし、ファームウェアのアップデートを最初からやり直すことができるため、運用の継続性も確保されています。

②シングルバンク全面更新

　フラッシュメモリの全域を1つのファームウェア格納領域として使用し、ファームウェアの更新時にその領域を全面的に書き換える方式です。

　ROM容量が小さなMCUでもOTAを実現できるメリットがありますが、更新前のプログラムを保持できないため、書き換え失敗時のリスクが高いというデメリットがあります。

• 正常フロー

　※FW：ファームウェア

図6. シングルバンク全面更新 正常フロー

　①外部から更新ファームウェアを受け取り、メイン面の更新前ファームウェアを消去します。

　②更新ファームウェアをメイン面に書き込みます。

　③メイン面に書き込んだ更新ファームウェアの署名情報等の検証を行い、正しいファームウェアであることを確認します。

　④ソフトウェアリセット後、ブートローダが起動し、メイン面の更新ファームウェアの正当性を確認後、新しく更新されたファームウェアで動作します。（セキュアブート）

• 
  異常パターン

　※FW：ファームウェア

図7. シングルバンク全面更新 異常パターン

　更新中にトラブルが起きると、一時的に「動くプログラムがどこにもない」状態になります。しかし、ブートローダさえ無事であれば、再度ファームウェアのアップデートが可能です。

③デュアルバンク更新

　メモリ領域を2つの独立した「バンク」に分割し、それぞれ独立して動作させる方式です。

　アプリを動作させたまま裏側で書き換えできるため稼働停止時間を最小化できるメリットがありますが、専用のハードウェア機能を備えた高機能なMCUが必要になるというデメリットがあります。

• 正常フロー

　※FW：ファームウェア

図8. デュアルバンク更新 正常フロー

　①外部から更新ファームウェアを受け取り、バッファ面に書き込みます。

　②バッファ面に書き込んだ更新ファームウェアの署名情報等の検証を行い、正しいファームウェアであることを確認します。

　③ソフトウェアリセット後にブートローダが起動し、メモリマップを切り替える処理（バンクスワップ）を行います。

　④メイン面の更新ファームウェアの正当性を確認し、次回更新に備えてバッファ面を消去します。

　⑤新しく更新されたファームウェアで動作します。（セキュアブート）

• 異常パターン

　※FW：ファームウェア

図9. デュアルバンク更新 異常パターン

　どのタイミングで異常が発生しても、常にいずれかのバンクに有効なファームウェアが保持されているため、確実に更新前の状態へ復帰できる非常に安全な設計です。

3. 実機PoCで見るOTAアップデート（デモ動画）

　ここまでOTAによるアップデート手順や方式を解説してきましたが、「実際にエッジデバイスがどう動くのかイメージが湧かない」という方も多いのではないでしょうか。そこで、エアコン（室内機・室外機）をモデルにした実機PoC環境でのデモ動画をご用意しました。ぜひご覧ください。

4. まとめ

　本記事では、OTAアップデートの全体構成から、各ファームウェアアップデート方式の比較、そして実機での挙動をご紹介しました。

　OTAの実現において、MCUのスペックや運用目的に合わせて、最適なアップデート方式を選択することが重要です。これらを設計段階から検討することで、製品出荷後も迅速な不具合対応や新機能の追加が可能になり、製品の価値を長く保つことができます。

　本記事の内容が、皆様のプロジェクトにおけるOTAシステム構築のヒントになれば幸いです。

（編集者：内田 将之）