IoT Core 製造ガイド

Note

以前のバージョンについては、「v5.x 向け IoT Core 製造ガイド」を参照してください。

Windows 10 IoT Core を実行するデバイスの一括生成を検討している場合は、 Windows ADK IoT Core アドオンを使用して、新しいデバイスにすばやくフラッシュできるイメージを作成します。

デバイスにすばやくアクセスして変更するためのツールを含むテスト イメージを作成できます。 テスト イメージは以下に適しています。

• 新しいデバイス設計を試している開発者、ハードウェア ベンダー、製造元 (OEM)。
• ネットワークがないかネットワークが制御された環境で実行するように設計されたデバイスを作成している愛好家と組織。

更新プログラムをまだ受信しているときにパブリックまたは企業ネットワークのセキュリティを向上させることができる製品イメージを作成できます。

アプリ、設定、ハードウェア構成、ボード サポート パッケージ (BSP) などのカスタマイズを追加できます。

OEM スタイルのイメージの場合は、カスタマイズをパッケージ (.cab) ファイルにラップします。 パッケージを使用すると、OEM、ODM、開発者、Microsoft が連携して、相互の作業を損なうことなく、デバイスにセキュリティと機能の更新プログラムを提供できます。

Windows 10ロケーション サービスを備えた IoT Core デバイスは、お客様がどこにいるか、どこにいたかをアプリとサービスに通知します。

Windows 10 IoTCore RS5 2019 年 11 月の "11 B" リリース (OS バージョン 17763.865) 以降では、IoT Core の位置情報サービスが既定で "オフ" に設定されるように構成されます。 位置情報サービスをオンにする OEM は、次の手順に従ってください。 これは、IoT Core にのみ適用されます。

レジストリ キー HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionCapabilityAccessManagerCapabilitieslocationedition の下に、次の値を設定します。

• name=InitSystemGlobalConsentDenied value="0" valueType=REG_DWORD
• name=InitUserGlobalConsentDenied value="0" valueType=REG_DWORD

キットの作成者は、これらのレジストリ設定でカスタム イメージのビルド手順について、「ラボ 1c: イメージへのファイルとレジストリ設定の追加」を参照してください

シナリオ

• Windows IoT Core のカスタマイズに必要なツールの入手
• ラボ 1a: 基本イメージの作成
• ラボ 1b: イメージへのアプリの追加
• ラボ 1c: イメージへのファイルとレジストリ設定の追加
• ラボ 1d: イメージへのネットワークおよびその他のプロビジョニング パッケージ設定の追加
• ラボ 1e: イメージへのドライバーの追加
• ラボ 1f: 製品イメージのビルド
• ラボ 2: 独自のボード サポート パッケージの作成
• ラボ 3: アプリの更新

概念

Windows IoT Core イメージを作成してデプロイするプロセスを明確に理解するために、まずいくつかの概念と用語を定義する必要があります。

Windows IoT Core イメージを作成するプロセスには、次に示すいくつかのステップが含まれます。

1. イメージに含めるカスタマイズをテストして、正しく動作することを確認します。 これには、アプリ、設定、ドライバー、またはボード サポート パッケージ (BSP) が含まれます。
2. PC にテスト証明書をインストールし、カスタマイズを .CAB ファイルにパッケージ化します。
3. IoT Core パッケージおよびハードウェア製造元からの更新プログラムと共に、カスタマイズを含む Windows 10 IoT Core テスト イメージを作成します。
4. デバイスにイメージをフラッシュし、動作することをテストします。 テスト イメージに組み込まれているテスト ツールを使用して、発生する可能性のある問題のトラブルシューティングを行うことができます。
5. すべてが正常に動作することを確認したら、有効なリテール証明書を取得し、リテール証明書を使用してカスタマイズに署名します。 その後、カスタマイズを新しい .CAB ファイルに再パッケージ化する必要があります。
6. 署名された .CAB ファイルで製品イメージを作成し、そのイメージをデバイスにフラッシュします。

用語

パッケージ

パッケージ (.cab ファイル) は、IoT Core の論理的な構成要素です。 これらには、デバイス上のすべてのファイル、ライブラリ、レジストリ設定、実行可能ファイル、データが含まれています。 デバイス ドライバーからシステム ファイルまで、すべてのコンポーネントがパッケージに含まれている必要があります。 このモジュール形式のアーキテクチャにより、更新を正確に制御できます。パッケージは、デバイス上の最小の保守可能単位です。

各パッケージには以下のものが含まれます。

• 署名されたドライバー バイナリや署名された appx バイナリなどのパッケージの内容。
• パッケージ定義 (.wm.xml) ファイルでは、パッケージの内容と最終的なイメージの配置場所を指定します。 パッケージ ファイルのさまざまなサンプルについては、Windows ADK IoT Core アドオン キットの %SRC_DIR%\Packages\ ディレクトリを参照してください。 例として、「Appx.IoTCoreDefaultApp.wm.xml」を参照してください。
• 署名。 パッケージは、テストまたはリテール証明書を使用して署名できます。

pkggen ツールは、これらのアイテムを署名されたパッケージに結合します。 サンプルには、スクリプト createpkg と、pkggen を呼び出してドライバー、アプリ、設定のパッケージを作成する createprovpkg が含まれます。

フィーチャー マニフェスト (FM)

すべてをパッケージに追加したら、フィーチャー マニフェスト (FM ファイル) を使用して、最終イメージに含まれるパッケージの一覧を表示します。

イメージには、必要な数だけ FM を使用できます。 このガイドでは、次の FM について説明します。

• OEMFM.xml には、アプリやプロビジョニング パッケージなど、OEM がデバイスに追加できる機能が含まれます。
• BSPFM.xml には、ハードウェア製造元がボードを定義するために使用できる機能が含まれます。 たとえば、OEM_RPi2FM.xml には、Raspberry Pi 2 に使用されるすべての機能が含まれています。

次のタグを使用して、追加する機能の一覧を表示します。

• <BasePackages>: イメージに常に含めるパッケージ。たとえば、ベース アプリなどです。
• <Features>\<OEM>: 特定の製品設計に固有である可能性がある他の個々のパッケージ。

機能結合ツールは、デバイスにサービスを提供するために必要な機能識別子パッケージを生成します。 FM ファイルに変更が加えられるたびに、このツールを実行します。 OEM FM または OEM COMMON FM ファイルを変更した後に、buildfm oem を実行します。 BSPFM ファイルを変更した後に、buildfm bsp <bspname> を実行します。 これらのコマンドは、IoT Core シェルから実行します。

ボード サポート パッケージ (BSP)

ボード サポート パッケージには、特定のボードのソフトウェア、ドライバー、ブート構成のセットが含まれており、通常はボードの製造元によって提供されます。 ボードの製造元は、デバイスが受信して適用できるボードの更新プログラムを定期的に提供する場合があります。 独自の BSP を作成することもできます (ボードの製造元から提供されず、対応する一連のソフトウェアおよびドライバー ファイルがある場合)。 サポートされる BSP については、こちらに記載されています。

Full Flash Update イメージ ファイル

完全な Flash Update (FFU) ファイルは、デプロイできるイメージ ファイルです (別名。"flashed") を特定のハードウェア デバイスに送信します。 FFU ファイルをデバイスにフラッシュすると、すべての必須ソフトウェアがそのデバイスに同時にインストールされます。 FFU イメージ ファイルでは、ブート ローダー、Windows オペレーティング システム、ドライバー、周辺イメージ、その他の必須ファイルが 1 つのパッケージにバンドルされています。

フォアグラウンドおよびバックグラウンド アプリ

Windows IoT Core 上で実行できるアプリケーションは 2 種類あります。

• フォアグラウンド アプリ - これらのアプリには UI があります。 IoT デバイスでフォアグラウンド アプリとして実行できるアプリは 1 つだけです。 イメージに複数のフォアグラウンド アプリが含まれている場合は、1 つだけをブート時に自動開始として設定する必要があります。
• バックグラウンド アプリ - これらのアプリには UI がありません。 複数のアプリを IoT デバイスでバックグラウンド アプリとして実行できます。 任意の数のバックグラウンド アプリを自動開始するように構成できます。

詳細については、フォアグラウンド アプリまたはバックグラウンド アプリに関する記事を参照してください。

イメージの作成: ImgGen とイメージ構成ファイル (OEMInput.xml)

最終イメージを作成するには、imggen ツールをイメージ構成ファイル OEMInput.xml ファイルと共に使用します。

イメージ構成ファイルには、以下が一覧表示されます。

• フィーチャー マニフェスト (FM) と、それぞれからインストールするパッケージ。

• デバイス パーティションの設定に使用される SoC チップ識別子。 soc でサポートされる値は、対応する bspfm.xml の <devicelayoutpackages> の下に定義されています。

• デバイス レイアウトの選択に使用される Device 識別子。 device でサポートされる値は、対応する bspfm.xml の <oemdeviceplatformpackages> の下に定義されています。

• ReleaseType (Production または Test)。

  製品ビルド: 製品イメージを開発プロセスの早期に作成して、出荷の準備ができたときにすべてが機能することを確認することをお勧めします。

  これらのビルドには、有効になっているすべてのセキュリティ機能が含まれています。

  このビルドの種類を使用するには、すべてのコードに (テストではなく) リテール コード署名証明書を使用して署名する必要があります。

  サンプルについては、%SRC_DIR%\Products\SampleA\RetailOEMInput.xml を参照してください。

  テスト ビルド: これらを使用して、自社またはハードウェア製造元パートナーが作成したアプリとドライバーの新しいバージョンを試します。

  これらのビルドでは、いくつかのセキュリティ機能が無効になっているので、テスト署名または実稼働署名されたパッケージを使用できます。

  これらのビルドには、問題のトラブルシューティングに使用できるデバッグ トランスポート、SSH、PowerShell などの開発者ツールも含まれています。

  サンプルについては、%SRC_DIR%\Products\SampleA\TestOEMInput.xml を参照してください。

領域	製品ビルド	テスト ビルド
イメージ リリースの種類	ReleaseType: Production	ReleaseType: Test
パッケージ リリースの種類	サポートされているのは、Production タイプのパッケージのみです	Production タイプと Test タイプの両方がサポートされています
テスト署名されたパッケージ	サポートされていません	サポートされる IOT_ENABLE_TESTSIGNING 機能を含める必要があります。
コード整合性チェック	サポートされています。 これは既定で有効になっています。	サポートされています。 既定では、ポリシーは適用されません

試してみましょう

Windows IoT Core のカスタマイズに必要なツールの入手から始めます。