Matter Over-The-Air(OTA)は、Matterファブリック内のMatterデバイスがファームウェアを更新できるようにするプロセスです。Matter仕様では、セキュリティ上の理由から、各デバイスがファームウェア更新の方法を実装することが求められています。Matterは独自の便利なファームウェア更新メカニズムを規定していますが、サポートは任意であり、デバイスはカスタムソリューションを含む他の方法を使用することができます。カスタムソリューションは、Matter OTAの代わりに、またはそれと併用して使用できます。
Matter OTAプロセスには、以下の役割が関与します。
ファームウェアを更新するすべてのMatterデバイス。この役割は、OTA Software Update Providerクラスタのクライアント役割と、OTA Software Update Requestorクラスタのサーバー役割を実装するOTA Requestorデバイスタイプに対応します。
OTA Requestorは、リソースが制約された組み込みデバイスなどのMatterアクセサリに実装されるのが一般的です。
OTAアップデート用のイメージを提供するデバイス。この役割は、OTA Software Update Providerクラスタのサーバー役割と、オプションでOTA Software Update Requestorクラスタのクライアント役割を実装するOTA Providerデバイスタイプに対応します。
ファブリック上のどのデバイスも、インターネットまたはソフトウェアイメージへのリンクを含むデータベースへのアクセス権がある限り、この役割を担うことができます。通常、これらはエコシステムプロバイダーのスマートホームハブのような、より多くのリソースを持つデバイスです。
これは通常、ソフトウェアイメージを作成するベンダーによって設定されたサーバーです。ソフトウェアイメージのURIに関する情報は、通常、Matter Distributed Compliance Ledger(DCL)で提供されます。DCLは、Matterプロジェクトのすべての貢献者に開かれた暗号的に安全なデータベースです。これは、ベンダーとそのデバイスモデルのコンプライアンスステータスに関する情報、および検証されたCSAメンバーへのベンダーデバイスメタデータの提供のための信頼できる情報源として機能します。
OTAプロセスの承認を提供します。一部のOTA Requestorは、GUIやネットワークハブを使用して、OTAアップデートの適用について直接ユーザーに承認を求めることができます。直接尋ねることができない場合、承認リクエストはOTA Providerに委任できます。
次の図は、OTAプロセスにおける関係者間の関係を示しています。
ソフトウェアイメージの転送には、Matterは独自の内部Bulk Data Exchange(BDX)プロトコルを使用します。その主な目的は、Matterノード間でのデータ交換を容易にすることです。
このプロトコルは、Trivial File Transfer Protocol(TFTP)に基づいています。BDXは、転送されるファイルが特定の形式である必要はありませんが、ファイルに任意のメタデータを添付することができます。OTA転送に使用される場合、OTA Providerはbdx://<node-id>/<file-name>形式を使用してOTA RequestorにURIを送信します。ここで、<node-id>はイメージを受信するOTA RequestorのNode IDに対応し、<file-name>はノード上のソフトウェアイメージファイルを一意に識別する任意のファイルパスです。
Matter OTAプロセスを可能にするには、OTA RequestorとOTA Providerが同じファブリックのメンバーである必要があります。OTA Requestorは、OTA Providerの存在を認識している必要があり、検出メカニズムを使用して利用可能なOTA Providerに関する情報を取得します。検出プロセスは、OTA ProviderがDNSサービスを公開しているため、DNSを使用して行われます。
OTA Providerの選択後、OTA Requestorはソフトウェアイメージを照会し、可用性に応じて、OTA Providerはそれを即座に送信するか、バックグラウンドでインターネットからイメージをダウンロードするために操作を遅延させることを通知します。
次のチャートは、Matter OTAプロセスの簡略化された概要を示しています。

nRF Connect SDKでMatterアプリケーションをビルドする場合、Matter OTAイメージはビルド出力ファイルの1つです。ソフトウェアイメージのデフォルトの場所は、ビルドディレクトリ内のmatter.otaです。ソフトウェアイメージのPayloadフィールドには、ビルドプロセスの別の出力ファイルであるdfu_multi_image.binファイルが含まれています。
dfu_multi_image.binファイルは、CBOR(Concise Binary Object Representation)形式のマニフェストと、ユーザーが選択した更新コンポーネントのコレクションを含むアーカイブファイルです。CBORマニフェストには、含まれる更新コンポーネントの識別子とサイズが含まれており、ユーザーがアーカイブを正常に展開できるようになっています。デフォルトの更新コンポーネントは、すべてのMCUコアのファームウェアイメージです。
Matter OTAファームウェアアップデートプロセス中、ダウンロードされたMatter OTAイメージは、DFU multi-imageおよびDFU targetライブラリを使用して、外部または内部の不揮発性メモリ(NVM)に保存されます。DFU multi-imageライブラリは、CBORヘッダーの解析にzcborを使用します。ソフトウェアイメージの適用には、新しいファームウェアをインストールするMCUbootブートローダーの再起動が必要です。
OTA Providerの役割は通常、スマートハブデバイスまたはモバイルアプリケーションに実装されており、一部の商用エコシステムでサポートされています。ただし、開発目的では、通常、開発ツールを使用する方が便利です。
MatterプロジェクトはOTA Providerの役割を実行するための開発ツールを提供しており、CHIP Toolと同様に、LinuxがインストールされたPC上でビルドおよび実行できます。
ソースファイルから手動でOTA Providerをビルドするか、Nordicの開発者が準備したMatter nRF Connect releasesからビルド済みツールパッケージをダウンロードできます。時間を節約するために、ビルド済みバイナリファイルを取得することをお勧めします。
お使いのnRF Connect SDKバージョンに対応するGitHubタグのアーティファクトを使用して、パッケージがお使いのnRF Connect SDKバージョンと互換性があることを確認してください。
このレッスンの演習セクションで、OTA Providerツールのダウンロードとセットアップ方法を学習します。