工場現場のタスク

重要

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

Azure Sphere ハードウェアを組み込んだ接続デバイスの製造には、出荷用のデバイスを準備するための次の工場現場のタスクが含まれます。

• 各 Azure Sphere チップを工場フロアの PC に接続する
• デバイスの詳細を取得し、後で使用できるように記録する
• 必要に応じて Azure Sphere OS を更新する
• 必要に応じて、信頼されたキーストアを更新します
• デバイスへのソフトウェアの読み込み
• 機能テストを実行して製品の正しい操作を確認する
• 無線周波数 (RF) テストとキャリブレーションの実行
• Wi-Fi 通信の確認
• イーサネット用のデバイスの構成
• 出荷のための Azure Sphere デバイスの最終処理

最初にチップを PC に接続し、デバイスの詳細を 2 番目に取得し、最後にデバイスを最終処理する必要がありますが、他のタスクは製造環境に適した任意の順序で実行できます。

重要

工場現場のタスクを遅延なく完了できるように、いくつかの準備を行う必要があります。 準備には、工場フロアの PC およびその他の必要な機器のセットアップと、必要な PC ソフトウェア ツールのインストールが含まれます。 スムーズな製造プロセスを準備するために行う必要があるすべてのタスクについては、「 製造プロセスの準備に関する説明があります。

各 Azure Sphere チップを工場フロアの PC に接続する

製造時に、各 Azure Sphere チップを工場フロアの PC に接続する必要があります。 複数の Azure Sphere デバイスを 1 台の PC に同時に接続する場合は、製造準備タスクの 工場のタスクの前提条件 を参照してください。

ほとんどの工場現場のタスクには、 azsphere device コマンドが含まれます。 PC に複数のデバイスが接続されている場合は、azsphere device コマンドを適用するデバイスを指定する必要があります。これには、デバイスの IP アドレスまたはデバイスの接続パスに設定された --device パラメーターを含めます。 --device パラメーターを省略し、複数のデバイスが接続されている場合、コマンドは失敗します。 IP アドレスまたは接続パスを取得するには、 デバイスの詳細の取得を参照してください。

重要

Azure Sphere 23.05 SDK リリース以降のリリースでは、Windows および Linux 上の複数の接続デバイスとの通信がサポートされています。

デバイスの詳細を取得する

会社が製造製品に組み込む各 Azure Sphere チップのデバイス ID を記録する必要があります。 クラウド構成タスクのデバイス ID が必要です。

工場の PC に複数のデバイスが接続されている場合は、後で工場現場のタスクで使用するために、接続されているデバイスの IP アドレスまたは接続パスも記録する必要があります。 「 各 Azure Sphere チップを接続するで説明されているように、複数の接続デバイスがある場合にターゲット デバイスを指定するには、IP アドレスまたは接続パスが必要です。

接続されているデバイスのデバイス ID、IP アドレス、接続パスを取得するには、 azsphere device list-attached コマンドを使用します。 次の説明では、デバイス ID、IP アドレス、接続パスに関する基本的な詳細を示します。

• デバイス ID — シリコン製造元は、デバイス ID を作成し、チップに格納して、Microsoft に登録します。 このデバイス登録によって、Microsoft ではすべての Azure Sphere チップを認識し、接続デバイスには正当なチップのみが使用できることを保証します。

• IP アドレス—IP アドレスは FTDI ベースのデバイス インターフェイスが PC に接続されるとき割り当てられます;応答デバイスが存在することを示していません。 IP アドレスは、別の Azure Sphere デバイスがインターフェイスに接続されても、FTDI ベースのデバイス インターフェイスが PC に接続されている間、保持されます。 ただし、PC の再起動後、IP アドレスが変わる場合があります。 最初に接続する FTDI ベースのデバイス インターフェイスには、アドレス 192.168.35.2 が割り当てられます。 すべてのデバイスに IP アドレスが割り当てられるため (応答性が低い場合でも)、IP アドレスを使用して、復旧が必要なデバイスを特定できます。

• 接続パス— 接続パスは、USB 接続を識別する FTDI ロケーション ID です。 FTDI ベースのデバイス インターフェイスが同じ USB ハブ上の同じ USB ポートに接続され、PC 上の同じポートに接続されている間、場所 ID は保持されます。 そのため、再起動後も保持されます。 ただし、PC とデバイスの間の接続に変更があると、デバイスで接続パスに変更が発生する可能性があります。 IP アドレスと同様、別の Azure Sphere デバイスが FTDI インターフェイスに接続されてもこれは変わりません。

Azure Sphere OS を更新する

すべての Azure Sphere チップは、Azure Sphere OS がシリコンの製造元から出荷されるときに読み込まれます。 サプライヤーから入手できるチップ上の Azure Sphere OS のバージョンと、アプリケーションの OS バージョンの要件によっては、接続デバイスの製造中に Azure Sphere OS を更新する必要があります。 OS を更新するには、PC に既に存在する必要がある特定の回復イメージをインストールします。 製造準備タスクの OS の更新についてはPrepare を参照してください。 製造サンプルには、並列マルチデバイス復旧を実行するサンプル スクリプトが含まれています。

azure Sphere デバイスの OS を更新するには、 azsphere device recover コマンドを発行します。 特定の回復イメージをインストールするには、 --images パラメーターを使用します。

azsphere device recover --images <path-to-images> [--device <IP-address or connection-path>]

Note

複数のデバイスが PC に接続されている場合は、ip アドレスまたは接続パスでターゲット デバイスを識別する --device パラメーターを含めます。 詳細については、「 各 Azure Sphere チップを工場の PC に接続する を参照してください。

信頼されたキーストアを更新する

デバイスにソフトウェアを読み込むための前提条件として、デバイス上の信頼されたキーストアを更新する必要があります。 これは、デバイス上の OS がソフトウェアより古い場合にのみ必要です。また、AS3 によって使用される Azure Sphere イメージ署名キーが、公開されている OS と実稼働署名されているソフトウェアの間で更新された場合にのみ必要です。 この手順を回避し、製造時間を短縮するには、製造時に使用している OS バージョンを更新することを検討してください。

次のセクションの手順に従ってソフトウェアを読み込もうとすることで、信頼できるキーストアの更新が必要かどうかを簡単に判断できます。 読み込みに成功した場合は、信頼されたキーストアを更新する必要はありません。 Internal device error: Image not trusted by deviceで始まるメッセージで読み込みに失敗した場合は、古い信頼されたキーストアが原因です。

信頼されたキーストアを更新するには、 最新の信頼されたキーストア ファイルを取得する必要があります。 次に、製造スクリプトの一部として、 azsphere device sideload deploy コマンドを使用して、アプリケーション ソフトウェアを読み込む前に更新された信頼されたキーストアを読み込み、 <path-to-trusted-keystore.bin> を信頼されたキーストア ファイルのパスに置き換えます。

Azure Sphere CLI

azsphere device sideload deploy --image-package <path-to-trusted-keystore.bin> [--device <IP-address or connection-path>]

Azure Sphere クラシック CLI

azsphere device sideload deploy --imagepackage <path-to-trusted-keystore.bin> [--deviceip <IP-address> | --devicelocation <connection-path>]

Note

Azure Sphere クラシック CLI は廃止されます。 Azure Sphere (Integrated) を使用することをお勧めします。

デバイス ソフトウェアを読み込む

ボード構成イメージ、テスト アプリケーション、運用アプリケーションのいずれであっても、読み込むすべてのソフトウェアは、運用署名されている必要があります。 テスト用に一時的なアプリケーションを読み込む場合は、テストの完了後に削除する必要があります。

製造準備タスクの「 運用環境で署名されたイメージを取得する」で説明されているように、工場現場のプロセス中に必要なすべての生産署名付きイメージは、プロセスを開始する前に工場の床の PC に保存する必要があります 。

製造中、Azure Sphere デバイスには、デバッグを可能にするアプリケーション開発機能など、特別なデバイス機能は不要です。 個々のデバイスに機能を追加することで、デバイスのセキュリティが低下し、インターネット接続が必要になります。通常、このようなことは工場の現場では望ましくありません。

工場内のデバイスにソフトウェアを読み込むか、テストの完了後にデバイスから一時ソフトウェアを削除するには、次のように azsphere device sideload コマンドを使用します。

• azsphere device sideload deploy を使用してイメージを読み込み、<file-path>を実稼働署名付きイメージ ファイルの名前とパスに置き換えます。

  Azure Sphere CLI

  azsphere device sideload deploy --image-package <file-path> [--device <IP-address or connection-path>]
  

  Azure Sphere クラシック CLI

  azsphere device sideload deploy --imagepackage <file-path> [--deviceip <IP-address> | --devicelocation <connection-path>]
  

  Note

  Azure Sphere クラシック CLI は廃止されます。 Azure Sphere (Integrated) を使用することをお勧めします。

---

• azsphere device sideload delete を使用して一時イメージを削除し、<component-id>を削除するイメージのコンポーネント ID に置き換えます。

  Azure Sphere CLI

  azsphere device sideload delete --component-id <component-id> [--device <IP-address or connection-path>]
  

  Azure Sphere クラシック CLI

  azsphere device sideload delete --componentid <component-id> [--deviceip <IP-address> | --devicelocation <connection-path>]
  

  Note

  Azure Sphere クラシック CLI は廃止されます。 Azure Sphere (Integrated) を使用することをお勧めします。

---

Note

複数のデバイスが PC に接続されている場合は、ip アドレスまたは接続パスでターゲット デバイスを識別する --device パラメーターを含めます。 詳細については、「 各 Azure Sphere チップを工場の PC に接続する を参照してください。

機能テストを実行する

機能テストは、製品が正しく動作することを確認するために必要です。 製造準備タスクの一部として機能テスト用に開発したアプリケーションを実行します。 機能テストについては、 Develop アプリケーションを参照してください。

機能テストでテスト対象のチップとの通信が必要な場合は、MT3620 周辺 UART (ISU0、ISU1、ISU2、または ISU3) を、独自の設計の適切な回路を介して工場の PC または外部テスト機器に接続します。

無線周波数 (RF) テストとキャリブレーションを実行する

Azure Sphere チップは、Wi-Fi を使用してソフトウェア更新プログラムを受信し、インターネットと通信する場合があります。 製品が Wi-Fi を使用していて、チップダウン設計または RF 認定 されていないモジュール 組み込まれる場合は、各デバイスに対して RF テストとキャリブレーションを実行する必要があります。 このタスクに必要な機器とツールについては、製造準備タスクの「 RF テストとキャリブレーション用のソフトウェア で説明されています。

RF ツール パッケージには、テスト中に使用するユーティリティと C API ライブラリが含まれています。 C API ライブラリを使用して、製品固有の RF 設定を電子ヒューズでプログラミングできます。 たとえば、電子ヒューズは、アンテナと周波数を構成し、最適なパフォーマンスを得るためにデバイスをチューニングし、Wi-Fi チャネルを有効にするようにプログラムされます。 RF ツールの使用方法については、「RF testing tools」(RF テスト ツール) トピックを参照してください。

電子ヒューズをプログラムしてWi-Fiチャンネルを有効にする

Azure Sphere OS は、MT3620 e ヒューズにプログラムされたリージョン コードに基づいて、オフセット アドレス0x36および0x37で Wi-Fi チャネルを選択します。 MT3620 の電子ヒューズの詳細については、 MT3620 E ヒューズコンテンツ ガイドライン Mediatek ドキュメントを参照してください。

リージョン コードは 2 文字の ASCII コードです。 Azure Sphere OS では、e ヒューズのリージョン コード設定を使用して、 Linux ワイヤレス規制データベース内のリージョンを検索し そのリージョンで許可されているチャネルを選択します。 e ヒューズにリージョン コードがプログラムされていない場合、その場合、e ヒューズは 0x00 0x00 に設定されたままです。または文字 "00" がプログラムされている場合、OS は既定ですべてのリージョンで一般的に許可される保守的なチャネル セットに設定されます。 リージョン "00" で許可されるチャネルは、Linux ワイヤレス規制データベースで指定されています。

e-fuses のリージョン コード設定は、デバイスが使用される国と一致する必要はありません。 製造元は、操作のリージョンに対して許可されている一連のチャネルにマップする任意のリージョン コードを選択できます。 多くの場合、異なる地域や国では、類似の規制または同一の規制が採用されており、地域コードを同じ意味で使用できます。

例: リージョン "DE" (ドイツ) の Wi-Fi チャネルを選択するように Azure Sphere OS に指示するには、0x44=D および 0x45=E をアドレス0x36および0x37の電子ヒューズにプログラムします。 Linux ワイヤレス規制データベースから抜粋したドイツで許可されているチャネルを次に示します。 欧州連合 (EU) のほとんどの国では、同じチャネル セットが許可されています。

country DE: DFS-ETSI
        (2400 - 2483.5 @ 40), (100 mW)
        (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
        (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
        (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
        # short range devices (ETSI EN 300 440-1)
        (5725 - 5875 @ 80), (25 mW)
        # 60 GHz band channels 1-4 (ETSI EN 302 567)
        (57000 - 66000 @ 2160), (40)

RF 構成を確認する

RfSettingsTool を使用して、ターゲット送信電力、地域コード、Wi-Fi メディア アクセス制御 (MAC) アドレスなどの無線構成オプションが正しく設定されていることを確認します。 RF 設定ツールのドキュメントには、このツールの使用方法が詳しく説明されています。

Wi-Fi 通信を確認する

製品アプリケーションが Wi-Fi 経由で通信できることを確認するには、Wi-Fi アクセス ポイントに接続することを検討してください。 チップがインターネット対応のアクセス ポイントに接続すると無線の更新が発生する可能性があるため、Wi-Fi 接続にインターネット アクセスがないことを確認します。

デバイスを Wi-Fi アクセス ポイントに接続するには、 Quickstart (CLI タブ) の指示に従います。 複数のデバイスが PC に接続されている場合は、azsphere device wifi show-status コマンドと azsphere device wifi add コマンドに --device パラメーターを含める必要があります。 複数のデバイスが接続された azsphere device コマンドの使用の詳細については、「 各 Azure Sphere チップを工場フロアの PC に接続するを参照してください。

Wi-Fi テストの後、テストに使用される Wi-Fi アクセス ポイントをチップから削除して、お客様に表示されないようにする必要があります。 デバイスの回復により、チップからすべての Wi-Fi 構成データが削除されます。

デバイスをイーサネット用に構成する

Azure Sphere デバイスはイーサネット経由で通信できます。 このデバイスには、イーサネット経由の通信用の外部イーサネット アダプターとボード構成イメージが必要です。

イーサネット用に Azure Sphere デバイスを構成するには、「イーサネット アダプターの接続」の説明に従って、イーサネット アダプターを Azure Sphere デバイス 接続します。

Azure Sphere オペレーティング システムでは、2 つのイーサネット デバイスがサポートされています。

1. マイクロチップ ENC28J60。 これは 10Base-T (10 mbps) アダプターです。 半二重速度の LED インジケーターを使用するか、全二重速度の LED インジケーターなしで配線できます。 表示された開発キットは、半二重操作用にワイヤードされています。
2. Wiznet W5500. これは 100Base-TX (100mpbs) アダプターです。 統合 TCP/IP スタックと NIC パススルー モードがサポートされていますが、Azure Sphere ではインターネット接続に W5500 を使用する場合にのみ NIC パススルーがサポートされます。 バス帯域幅の制限により、MT3620 デバイスでは 100 mbps の完全な速度を実現できない場合があります。

「 デバイス ソフトウェアの読み込み」で説明されているように、ボード構成が読み込まれ、デバイスが再起動されると、イーサネット インターフェイスが自動的に有効になります。 既定では、すべてのインターフェイスが動的 IP アドレスを使用します。

Azure Sphere デバイスの最終処理

最終処理で、Azure Sphere デバイスがセキュリティで保護され、顧客に出荷できる状態であることを確認します。 デバイスの出荷前に最終処理を実行する必要があります。 最終処理には以下が含まれます。

• 適切なシステム ソフトウェアと実稼働アプリケーションがインストールされ、RF ツールが無効になっていることを確認する出荷準備チェックを実行する。

• RF 構成および調整ツールをロックアウトして、セキュリティ侵害を防止するために、デバイスの製造状態を設定する。

発送準備完了のチェックを実行する

Azure Sphere デバイスを含む製品を出荷する前に、発送準備完了のチェックを実行することが重要です。 製造状態ごとに異なるチェックを実行する必要があります。 発送準備完了のチェックでは、次のことを確認します。

• デバイスの製造状態は、製造のその段階に対して正しく設定されます。
• デバイス上の Azure Sphere OS が有効であり、予想されるバージョンです。 これは、DeviceComplete 状態になっていないデバイスについてのみ確認できます。
• デバイス上のユーザー指定のイメージは、想定されるイメージの一覧と一致します。 これは、DeviceComplete 状態になっていないデバイスについてのみ確認できます。
• デバイスに予期しない Wi-Fi ネットワークが構成されていません。 これは、DeviceComplete 状態になっていないデバイスについてのみ確認できます。
• デバイスに特別な機能証明書が含まれていません。 MT3620 ベースのデバイスの場合、これは空の状態ではないデバイスでのみ確認できます。

デバイスの製造状態によってデバイスの 能力 が決定されるため、製造の段階ごとに異なるチェックが必要です。

実行するチェックは、モジュールと接続されているデバイスのどちらを設計しているかによっても異なります。 たとえば、モジュールの製造元は、モジュールの顧客が追加の無線テストと構成を実行できるように、チップを空の製造状態のままにすることができます。

device_ready.pyを使用してチェックを実行する

製造サンプル パッケージには、各製造状態に応じて上記のチェックを実行する device_ready.py と呼ばれるツールが含まれています。 デバイスに関連する各製造状態に対して実行する必要があります。

次の表に、device_ready.py スクリプトが受け取るパラメーターを示します。

パラメーター	説明
--expected_mfg_state	チェックする製造状態を決定し、実行するテストを制御します。 このパラメーターが指定されていない場合、既定では "DeviceComplete" になります。 デバイスの製造状態がこの値と異なる場合、チェックは失敗します。
--images	チェックを成功させるためにデバイスに存在する必要があるイメージ ID (GUID) の一覧を指定します。 このリストは、スペースで区切られたイメージ GUID で構成されます。 指定しない場合、このパラメーターは既定で空のリストに設定されます。 デバイスにインストールされているイメージ ID の一覧がこの一覧と異なる場合、チェックは失敗します。 このチェックでは、(コンポーネント ID ではなく) イメージ ID をチェックすることで、コンポーネントの特定のバージョンが存在することを確認します。
--os	Azure Sphere OS のバージョンの一覧を指定します。 指定しない場合、このパラメーターは既定で空のリストに設定されます。 デバイスに存在する OS バージョンがこの一覧にない場合、このチェックは失敗します。
--os_components_json_file	OS の各バージョンを定義する OS コンポーネントを一覧表示する JSON ファイルへのパスを指定します。 MT3620 ベースのデバイスの場合、このファイルには mt3620an.json という名前が付けられます。 download_os_list.py ツールを使用して、最新バージョンをダウンロードします。
--azsphere_path	azsphere.exe ユーティリティへのパスを指定します。 指定しない場合、このパラメーターは既定で Windows 上の Azure Sphere SDK の既定のインストール場所になります。 このパラメーターは、Azure Sphere SDK が既定の場所にインストールされていない場合にのみ使用します。
--help	コマンド ライン ヘルプを表示します。
--verbose	追加の出力の詳細を提供します。

次の例は、次の引数を持つ device_ready.py ツールの実行例です。

• --os 22.07
• --os_components_json_file mt3620an.json
• --expected_mfg_state Module1Complete

device_ready.py --os 22.07 --os_components_json_file mt3620an.json --expected_mfg_state Module1Complete
Checking device is in manufacturing state Module1Complete...
PASS: Device manufacturing state is Module1Complete
Checking capabilities...
PASS: No capabilities on device
Checking OS version...
PASS: OS '22.07' is an expected version
Checking installed images...
PASS: Installed images matches expected images
Checking wifi networks...
PASS: Device has no wifi networks configured
------------------
PASS

デバイスの製造状態を設定する

テスト モードで無線接続を有効にする、Wi-Fi 構成の電子ヒューズを設定するなど、機密性の高い製造処理には、Azure Sphere チップを搭載したデバイスのエンド ユーザーからアクセスできないようにする必要があります。 Azure Sphere デバイスの "製造状態" で、このような機密性の高い操作へのアクセスを制限します。

3 つの製造状態は次のとおりです。

• Blank。 Blank 状態では、チップの製造操作は制限されません。 Blank状態のチップはRFテストモードに入ることができ、電子ヒューズをプログラムすることができます。 チップがシリコン工場から出荷されると、 Blank 製造状態になります。

• Module1Complete。 Module1Complete製造状態は、ユーザーが最大送信電力レベルや許容周波数などの無線構成設定に対して行うことができる調整を制限するように設計されています。 RF コマンドは、 Module1Complete が設定されるまで使用できます。 無線ハードウェアに関する規制ポリシーを満たすために、これらの設定へのエンドユーザーのアクセスを制限することが必要になる場合があります。 この設定は、主に、無線機能パラメーターをテストおよび調整する必要がある製造元に影響します。

  無線のテストと調整が完了した後、この製造状態を設定することをお勧めします。設定後、RF コマンドは使用できません。 Module1Complete状態は、近くにある無線およびその他のワイヤレス デバイスの適切な動作を中断する可能性のある変更からデバイスを保護します。

• DeviceComplete。 DeviceComplete製造状態により、完成品の製造元は、現場に展開されているデバイスを変更から保護できます。 デバイスが DeviceComplete 状態になったら、ソフトウェアの読み込みと構成タスクを実行するたびに、デバイス固有の機能ファイルを使用する必要があります。 fieldservicing機能を使用すると、実稼働署名付きイメージをサイドロードできますが、削除することはできません。 appdevelopment機能を使用すると、イメージのサイドローディングと削除の両方を行えます。

  DeviceCompleteより大きなシステムの一部として使用できる未完成のデバイスまたはモジュール (Wi-Fi モジュール、開発ボードなど) には設定しないでください。この状態では、生産ライン テスト、ソフトウェア インストール、構成などの製造アクティビティが制限されます。 多くの CLI コマンドは、 DeviceComplete が設定された後に使用できないため、この状態を設定する前に、特定の発送準備完了チェックを実行する必要があります。 制限付きコマンドは、fieldservicing 機能などのデバイス機能を使用して再び有効にすることができますが、要求したデバイスに対してのみ有効にできます。そのため、クラウド接続が必要なため、これは工場の環境での使用には適していません。

次の表は、各製造状態に存在するデバイスの機能をまとめたものです。

製造状態	デバイスの機能
空白	enableRfTestMode、 fieldServicing、および「 Device capabilities」で説明されているように、サイドロードまたは操作で渡されるもの。
Module1Complete	fieldServicing と、 Device の機能で説明されているように、サイドロードまたは操作で渡されたもの。
DeviceComplete	Device の機能で説明されているように、サイドロードまたは操作で渡される操作だけです。

製造が完了したら、 azsphere device manufacturing-state update コマンドを使用して、 DeviceComplete 状態を設定します。

Azure Sphere CLI

azsphere device manufacturing-state update --state <desired-state> [--device <IP-address or connection-path>]

Azure Sphere クラシック CLI

azsphere device manufacturing-state update --state <desired-state> [--deviceip <IP-address> | --devicelocation <connection-path>]

Note

Azure Sphere クラシック CLI は廃止されます。 Azure Sphere (Integrated) を使用することをお勧めします。

Note

複数のデバイスが PC に接続されている場合は、ip アドレスまたは接続パスでターゲット デバイスを識別する --device パラメーターを含めます。 詳細については、「 各 Azure Sphere チップを工場の PC に接続する を参照してください。

重要

チップを DeviceComplete 状態に移動することは永続的な操作であり、元に戻すことはできません。 チップが DeviceComplete 状態になると、RF テスト モードに入ることはできません。電子ヒューズの設定は調整できません。また、Wi-Fi 設定、オペレーティング システムの更新プログラム、およびインストールされているアプリケーションは、デバイスを要求してデバイス機能を使用しないと変更できません。 障害分析シナリオなど、デバイスの機能が再び有効にならない個々のチップで機能を再度有効にする必要がある場合は、Microsoft にお問い合わせください。