ファクトリ フロア のタスク

  • [アーティクル]

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 に同時に接続する場合は、「製造準備 タスクの工場現場のタスク用機器 」を参照してください。

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

大事な

Azure Sphere SDK では、Windows でのみ複数の接続デバイスとの通信がサポートされています。 Linux を使用している場合は、1 つの接続デバイスとの通信のみがサポートされます。 ただし、複数の Linux 仮想マシン (VM) を使用して、それぞれに 1 つの USB ポートがマップされ、複数の Azure Sphere デバイスと同時に通信する複数の Linux インスタンスを持つ 1 台の PC を使用できます。

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

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

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

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

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

  • IP アドレス — IP アドレスは、FTDI ベースのデバイス インターフェイスが PC に接続されている場合に割り当てられます。応答性の高いデバイスが存在することを示していません。 別の Azure Sphere デバイスがインターフェイスに接続されている場合でも、FTDI ベースのデバイス インターフェイスが PC に接続されている間、IP アドレスは保持されます。 ただし、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 の更新の 準備」を参照してください。 製造サンプルには、並列マルチデバイス復旧を実行するサンプル スクリプトが含まれています。

az sphere device recover コマンドを発行することで、Azure Sphere デバイス上の OS を更新できます。 パラメーターを --images 使用して、特定の回復イメージをインストールします。

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

メモ

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

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

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

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

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

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

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

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

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

ツールを使用した PC インターフェイス

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

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

  • az sphere device sideload deploy を使用してイメージを読み込み、運用環境で署名されたイメージ ファイルの名前とパスに置き換えます<file-path>。

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

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

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

メモ

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

機能テストを実行する

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

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

機能テスト フロー

無線周波数 (RF) のテストと調整を実行する

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

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

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

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

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

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

例： リージョン "DE" (ドイツ) の Wi-Fi チャネルを選択するように Azure Sphere OS に指示するには、0x44=D および 0x45=E をアドレス 0x36 と 0x37 の e ヒューズにプログラムします。 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 Media Access Control (MAC) アドレスなどの無線構成オプションが正しく設定されていることを確認します。 RF 設定ツールのドキュメントには、このツールの使用に関する詳細が記載されています。

通信 Wi-Fi 確認する

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

デバイスを Wi-Fi アクセス ポイントに接続するには、 クイック スタート (CLI) タブの指示に従います。 複数のデバイスが PC に接続されている場合は、az sphere device wifi show-status コマンドと az sphere device wifi add コマンドに パラメーターを含める--device必要があります。 複数の接続された デバイスで az sphere 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 パススルー モードがサポートされていますが、インターネット接続に W5500 を使用する場合、Azure Sphere では 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

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

無線をテスト モードにし、構成の e ヒューズ Wi-Fi 設定するなど、機密性の高い製造操作には、Azure Sphere チップを含むデバイスのエンド ユーザーはアクセスできません。 Azure Sphere デバイスの 製造状態 により、これらの機密性の高い操作へのアクセスが制限されます。

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

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

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

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

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

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

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

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

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

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

メモ

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

大事な

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