次の方法で共有

Azure Sphere を使用したダウンストリーム OTA の更新

  • [アーティクル]

多くの Azure Sphere ソリューションには、完全な IoT ソリューションの一部として、Azure Sphere 認定 MCU とその他のプロセッサの両方が組み込まれています。 これらの他のプロセッサには、通常のファームウェア更新プログラムが必要です。 このガイドでは、Azure Sphere を使用してダウンストリーム OTA 更新プログラムを有効にする方法について説明します。

特定のアプリケーション シナリオに応じて、これを実現するさまざまな方法があります。 各ソリューションには共通のフローがあります。

  1. ファームウェアの更新をトリガーします。
  2. ファームウェアの更新プログラムを取得します。
  3. 中間ダウンロードの場所を決定します。
  4. ファームウェアを検証し、ダウンストリーム プロセッサを更新します。

ステージ 1: ファームウェアの更新をトリガーする

問題: ファームウェアの更新プロセスはどのように開始されますか?

オプション:

  • 各 Azure Sphere アプリのバージョンは、ダウンストリーム ファームウェア バージョンに関連付けられています。

    • 説明: Azure Sphere アプリが起動すると、サポートされているファームウェアバージョンがダウンストリーム プロセッサにデプロイされたバージョンと比較されます。 バージョンが一致しない場合は、更新が必要です。
    • Pros: Azure Sphere アプリとファームウェア バージョンの間で定義されたサポート コントラクト。 また、既存の Azure Sphere アプリの更新プロセスを活用します。
    • Cons: Azure Sphere アプリの変更がない場合でも、ファームウェアの更新をトリガーするように Azure Sphere アプリを更新する必要があります。 また、更新の進行状況の監視を追加する必要があります。

  • Azure IoT Hub デバイス管理ファームウェアの更新:

    • 説明: ファームウェアの更新の準備ができたら、IoT Solution オペレーターは、更新されたファームウェアを使用して新しいデバイス管理構成を作成します。 Azure Sphere アプリケーションはファームウェアの更新要求を受け取り、更新を開始できます。
    • Pros: 更新プログラムを定義、トリガー、監視するための簡単な管理ソリューション。
    • Cons: Azure IoT Hub を使用する必要があります。他のクラウド エンドポイントはサポートされていません。

  • 個別のファームウェア チェック (カスタム ソリューション):

    • 説明: カスタム ファームウェア チェックを Azure Sphere アプリケーションにビルドします。 定義されたエンドポイントで新しいバージョンが検出された場合は、定期的に更新を開始します。
    • Pros: ファームウェアをダウンロードするために、任意のクラウド エンドポイントと連携します。
    • Cons: 更新プロセスの監視を追加する必要があります。 カスタムビルドソリューションなので、既存の更新経路を利用しません。

推奨される解決策: Azure Sphere アプリの更新プログラムを使用してダウンストリーム プロセッサの更新プログラムをトリガーする場合は、この方法をお勧めします。 このソリューションにより、Azure Sphere とダウンストリーム ファームウェアのバージョンが常に一致し、更新プログラムをトリガーするために別のシステムを構築する必要はありません。 それ以外の場合、アプリケーションが既に Azure IoT Hub を使用している場合は、IoT デバイス管理が推奨されるソリューションです。それ以外の場合は、カスタム ソリューションが必要です。

例:

ステージ 2: ファームウェアの更新プログラムを取得する

問題: Azure Sphere MT3620 の メモリ制約 を使用してファームウェアをダウンロードする方法

オプション:

  • MT3620 にデプロイされたイメージ パッケージにダウンストリーム ファームウェアを含めます。 これは、ダウンストリーム イメージを含む MT3620 ソフトウェアの合計サイズが、 ドキュメント化されたフラッシュ制限を超えていない場合に可能です。

  • たとえば、Azure Blob Storage を使用して、ホストされている場所からファームウェアをダウンロードします。 MT3620 の RAM 制限 によってイメージ全体が RAM にダウンロードされない可能性があるため、ファームウェアをチャンクでダウンロードする必要がある場合があります。 信頼されたファームウェアのみがダウンロードされ、ダウンストリーム プロセッサに適用されるように、たとえば HTTPS を使用して、ファームウェアのダウンロードに使用されるサーバーを検証することが重要です。 この場合、Azure Sphere アプリの更新中にデバイスをオンラインにすることはできますが、新しいアプリが新しいダウンストリーム ファームウェアをダウンロードする前にオフラインになる可能性があることに注意してください。 これがユース ケースの可能性がある場合は、Azure Sphere アプリと古いダウンストリーム ファームウェア バージョンの間の互換性を維持することが重要です。

推奨される解決策: ファームウェア イメージが Azure Sphere イメージ パッケージのフラッシュ制限に収まり、ダウンストリームの更新が必要なたびに MT3620 ソフトウェアを更新できる場合は、ダウンストリーム イメージを MT3620 イメージ パッケージに含することをお勧めします。 それ以外の場合は、ホストされている場所からファームウェア イメージをダウンロードする必要があります。

例:

ステージ 3: 中間ダウンロード場所を決定する

問題: この問題は、Azure Sphere イメージ パッケージに組み込まれているファームウェア イメージを使用していない場合、およびダウンロードされたファームウェアが MT3620 で使用可能な RAM より大きい場合にのみ関連します。

オプション:

  • Azure Sphere に接続されている外部フラッシュ。
  • ダウンストリーム MCU または PC ストレージ。

ダウンロードしたファームウェアを保存する場所に対する正しい答えや間違った答えはありません。 この選択は、ハードウェアのセットアップとコストによって異なります。 最適なオプションは何ですか? Azure Sphere デバイスに外部フラッシュ メモリをアタッチするか、ファームウェアの更新プログラムを受信するのに十分なストレージを備えたダウンストリーム プロセッサを選択することを検討してください。

推奨される解決策: セットアップに最適なオプションを選択します。

例:

ステージ 4: ファームウェアを検証し、ダウンストリーム プロセッサを更新する

問題: ファームウェアの更新プログラムを検証してダウンストリーム プロセッサに適用する方法

Options: すべてのプロセッサに異なるソリューションがあります。 ほとんどのプロセッサ製造元には、デバイスでファームウェア更新プログラムを実行する方法を示すサンプルがあり、特定のソリューションのベスト プラクティスに従う必要があります。 ファームウェアのダウンロードと更新は、更新を開始する前にファームウェアを検証するために整合性チェックを実行する必要があります。

推奨される解決策: プロセッサごとに異なります。 プロセッサの製造元のサンプルを参照してください。

例: ExternalMcuUpdate リファレンス ソリューション MT3620 の UART インターフェイスを介してノルディック nRF52 を更新する方法を示します。