次の方法で共有

無線での更新について

  • [アーティクル]

重要

これは Azure Sphere (レガシ) のドキュメントです。 Azure Sphere (レガシ) は 2027 年 9 月 27 日に 再提供されておりユーザーは現時点で Azure Sphere (統合) に移行する必要があります。 TOC の上にある Version セレクターを使用して、Azure Sphere (統合) のドキュメントを表示します。

更新プログラムは、新たに更新可能なセキュリティのプロパティを具体化するため、Azure Sphere セキュリティ モデルの重要な部分。 更新プログラムが定期的に実行されるようにすることで、デバイスの 7 プロパティ 準拠を維持できます。 Azure Sphere デバイスは、電源が入った後、またはリセット ボタンが押された後にインターネットに初めて接続したときに、更新プログラムを確認します。 その後、定期的にチェックが行われます (現在は 20 時間)。

更新プログラムには、前提条件の更新、OS 更新プログラム、展開更新プログラムの 3 種類があります。 前提条件の更新プログラムを使用して、更新プロセス自体が依存しているコンポーネント (現在は信頼されたキー ストア (TKS) と証明書ストア) が最新であることを確認します。 TKS は、ダウンロードしてインストールするイメージを認証するために使用され、証明書ストアはインターネット接続を検証します。 OS 更新プログラムは、アプリケーションが実行される通常のオペレーティング システムを含め、デバイス上の Microsoft が提供するソフトウェアだけでなく、プルトン サブシステムやセキュリティ モニターなどの下位レベルのファームウェアも対象とします。 展開の更新プログラムは、独自のソフトウェア (高度でリアルタイムに対応するアプリケーションとボード構成イメージ (存在する場合)) を対象としています。 前提条件と OS の更新プログラムは Azure Sphere によって管理されます。アプリケーションの更新は、組織によって作成された デプロイ に基づいて Azure Sphere によって調整されます。

任意のデバイスが前提条件または OS の更新プログラムを受け取るには、次の手順を実行します。

  • インターネットに接続されている必要がある。
  • ネットワーク要件 は適切に構成する必要があります。

デバイスがアプリケーションとボードの構成イメージを更新するには、次の手順を実行します。

特定のデバイス グループ内のすべてのデバイスについて、そのデバイス グループを対象とする展開は、それらのデバイスをイメージングするための信頼できるソースと見なされます。 展開に存在しないデバイス上のイメージはすべて、デバイスから削除されます。 Azure Sphere OS 21.04 の 1 つの例外は、ボード構成イメージが新しいボード構成イメージに置き換えられない限り削除されないことです。

デバイスの更新チェックは、次の 3 種類の更新プログラムに対応する 3 つのフェーズで行われます。

  • 最初のフェーズでは、Azure Sphere は TKS と証明書ストアの現在のバージョンを一覧表示するマニフェストを取得します。 デバイス上の TKS と証明書ストアが最新の状態である場合、更新は 2 番目のフェーズで続行されます。 そうでない場合は、現在のイメージがダウンロードされてインストールされます。
  • 2 番目のフェーズでは、Azure Sphere は、さまざまな OS コンポーネント イメージの現在のバージョンを一覧表示するマニフェストを取得します。 デバイス上のイメージが古い場合、現在のイメージは ロールバック イメージと共にダウンロードされます。これは 更新プロセスが失敗した場合にデバイスを既知の正常な状態にロールバックするために使用できます。 OS イメージとロールバック イメージがダウンロードされ、デバイス上のステージング領域に格納された後、OS イメージがインストールされ、デバイスが再起動されます。
  • 3 番目のフェーズでは、デバイス グループがデプロイの更新プログラムを受け入れているかどうかが Azure Sphere によって確認されます。 OS の更新と同様に、アプリケーションのロールバック イメージも必要に応じてステージングされます。 アプリケーション イメージとロールバック イメージがダウンロードされ、ステージング領域に格納された後、アプリケーション イメージがインストールされます。

ロールバックの更新

更新プロセスの各部分には、ロールバック オプションが含まれています。 前提条件の更新では、ロールバック イメージは単に更新前の状態のバックアップです。 更新に失敗すると、更新前の状態が復元されます。

任意のレベルでロールバックすると、すべての上位レベルでロールバックが強制されます。ファームウェア イメージの起動に失敗した場合は、ファームウェアパーティションとアプリケーション パーティションの両方がロールバックされます。

OS の更新では、署名検証エラーまたはランタイムの問題によってロールバックがトリガーされる可能性があります。 署名検証エラーが発生した場合、イメージの修正が試行されます。これが失敗した場合は、完全なロールバックがトリガーされます。 完全ロールバックでは、OS とアプリケーションの両方に対してステージングロールバック イメージがインストールされます。

OS の更新プログラムと展開には独立したリリース サイクルがあるため、OS 更新プログラム間で複数の展開を行うことができます。 このような場合は、展開のロールバック ターゲットが最新のデプロイではなく、最後の OS 更新時のデプロイであることに注意することが重要です。 これにより、OS とアプリケーションがロールバック状態で連携します。

中断された更新

停電や接続の喪失などによって更新が中断された場合、更新プログラムの種類ごとに次の 4 つのシナリオが考えられます。

  • イメージの完全なセットが正常にダウンロードされ、ステージングされたが、まだインストールされていない場合は、電源が復元されたときにインストールが完了します。
  • 一部のイメージがダウンロードされ、ステージングされていない場合、更新プログラムは不足しているイメージのダウンロードを続行し、インストールに進みます。
  • ダウンロードの完了後にインストール中に更新プログラムが中断された場合、起動時にインストールが再開されます。
  • イメージが完全にダウンロードされていない場合は、電源が復元されたときに更新プロセスが新たに開始されます。インストールする準備は何もないためです。

電源停止シナリオでの更新

Azure Sphere では、バッテリ寿命を節約するためにデバイスを長期間電源を切ることができる低電力シナリオがサポートされています。 このようなシナリオでは、デバイスが定期的に更新プログラムをチェックできるようにすることが重要です。 Power Down サンプル アプリケーションでは、デバイスが定期的に起動して OS とアプリの更新プログラムを確認できるようにしながら、電力消費量を適切に削減する方法を示します。

遅延更新プログラム

重要なタスクが更新によって中断されないようにするために、高度なアプリケーションには、 既定の更新プログラムを組み込むことができます。 この機能により、アプリケーションは重要なタスクを完了し、更新を続行できるようにシャットダウンの準備を行うことができます。 DeferredUpdate サンプルは、このような遅延更新を実装する方法を示しています。