Guide de fabrication IoT Standard

Notes

Pour la version précédente, consultez guide de fabrication IoT Core pour v5.x.

Vous pensez à des appareils produisant en masse exécutant Windows 10 IoT Standard ? Utilisez les modules complémentaires Windows ADK IoT Core pour créer des images que vous pouvez flasher rapidement sur de nouveaux appareils.

Vous pouvez créer des images de test, qui incluent des outils permettant d’accéder rapidement aux appareils et de les modifier. Les images de test sont idéales pour :

• Les développeurs, les fournisseurs de matériel et les fabricants (OEM) qui essaient de nouvelles conceptions d’appareils.
• Les amateurs et les organisations qui créent des appareils conçus pour s’exécuter dans des environnements réseau non connectés ou contrôlés.

Vous pouvez créer des images de vente au détail, qui peuvent être rendues plus sécurisées pour les réseaux publics ou d’entreprise tout en recevant des mises à jour.

Vous pouvez ajouter des personnalisations, notamment des applications, des paramètres, des configurations matérielles et des packages de support de carte (BSP).

Pour les images de style OEM, vous allez encapsuler vos personnalisations dans des fichiers de package (.cab). Les packages permettent aux oem, aux ODM, aux développeurs et à Microsoft de travailler ensemble pour fournir des mises à jour de sécurité et de fonctionnalités à vos appareils sans s’arrêter sur le travail des uns et des autres.

Votre appareil IoT Core avec Windows 10 service de localisation indique à vos applications et services où vous êtes ou où vous êtes allé.

À partir du Windows 10 version « 11 B » d’IoTCore RS5 novembre 2019 (version du système d’exploitation 17763.865), les services de localisation pour IoT Core seront configurés pour être définis sur « off » par défaut. Si vous êtes oem et que vous souhaitez activer les services de localisation, suivez les étapes ci-dessous. Cela s’applique uniquement à IoT Core.

Sous la clé HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionCapabilityAccessManagerCapabilitieslocationeditionde Registre , définissez les valeurs suivantes :

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

Les générateurs de kit doivent faire référence à Lab 1c : Ajout de fichiers et de paramètres de Registre à une image pour obtenir des instructions sur la création d’une image personnalisée avec ces paramètres de Registre

Scénarios

• Obtenir les outils nécessaires pour personnaliser Windows IoT Core
• Labo 1a : créer une image de base
• Labo 1b : ajouter une application à votre image
• Labo 1c : ajouter des fichiers et des paramètres de registre à une image
• Labo 1d : Ajouter des paramètres de mise en réseau et d’autres packages d’approvisionnement à une image
• Labo 1e : ajouter un pilote à une image
• Labo 1f : Créer une image de vente au détail
• Labo 2 : Création de votre propre package de support de carte
• Labo 3 : Mettre à jour vos applications

Concepts

Pour bien comprendre le processus de création et de déploiement d’images Windows IoT Core, vous devez d’abord définir quelques concepts et terminologie.

Le processus de création d’une image Windows IoT Core implique plusieurs étapes, répertoriées ici :

1. Testez toute personnalisation à inclure dans l’image pour vérifier qu’elles fonctionnent correctement. Il s’agit notamment des applications, des paramètres, des pilotes ou des packages de support de carte (BSP).
2. Installez des certificats de test sur votre PC et empaquetez vos personnalisations dans des fichiers .CAB.
3. Créez une image de test Windows 10 IoT Standard qui inclut vos personnalisations, ainsi que le package IoT Core et toutes les mises à jour de votre fabricant de matériel.
4. Flashez l’image sur un appareil et vérifiez qu’elle fonctionne. Vous pouvez utiliser les outils de test intégrés à l’image de test pour résoudre les problèmes qui peuvent survenir.
5. Une fois que vous avez vérifié que tout fonctionne correctement, obtenez un certificat de vente au détail valide et signez vos personnalisations avec votre certificat de vente au détail. Vous devez ensuite reconditionner la personnalisation dans de nouveaux fichiers .CAB.
6. Créez une image de vente au détail avec vos fichiers .CAB signés et flashez-la sur vos appareils.

Terminologie

Paquets

Les packages (fichiers .cab) sont les blocs de construction logiques d’IoT Core. Ils contiennent tous les fichiers, bibliothèques, paramètres du Registre, exécutables et données sur l’appareil. Des pilotes de périphérique aux fichiers système, chaque composant doit être contenu dans un package. Cette architecture modulaire permet un contrôle précis des mises à jour : un package est la plus petite unité utilisable sur l’appareil.

Chaque package contient :

• Contenu du package, tel qu’un fichier binaire de pilote signé ou un binaire appx signé.
• Un fichier de définition de package (.wm.xml) spécifie le contenu du package et l’emplacement où il doit être placé dans l’image finale. Pour obtenir différents exemples de fichiers de package, consultez le répertoire %SRC_DIR%\Packages\ du kit complémentaire Windows ADK IoT Core . Par exemple, examinez Appx.IoTCoreDefaultApp.wm.xml.
• Signature. Un package peut être signé avec un certificat de test ou de vente au détail.

L’outil pkggen combine ces éléments dans des packages signés. Nos exemples incluent des scripts : createpkg, et createprovpkg, qui appellent pkggen pour créer des packages pour nos pilotes, applications et paramètres.

Manifestes de caractéristiques (FMs)

Une fois que vous avez tout placé dans des packages, vous allez utiliser le manifeste de fonctionnalités (fichiers FM) pour répertorier les packages qui appartiennent à l’image finale.

Vous pouvez utiliser autant de machines virtuelles dans une image que vous le souhaitez. Dans ce guide, nous faisons référence aux machines virtuelles suivantes :

• OEMFM.xml inclut des fonctionnalités qu’un OEM peut ajouter à un appareil, telles que l’application et un package d’approvisionnement.
• BSPFM.xml inclut des fonctionnalités qu’un fabricant de matériel peut utiliser pour définir une carte. Par exemple, OEM_RPi2FM.xml inclut toutes les fonctionnalités utilisées pour le Raspberry Pi 2.

Vous allez répertorier les fonctionnalités à ajouter à l’aide de ces balises :

• <BasePackages> : packages que vous avez toujours inclus dans vos images, par exemple votre application de base.
• <Fonctionnalités>\<OEM> : autres packages individuels qui peuvent être spécifiques à une conception de produit particulière.

L’outil Fusion de fonctionnalités génère les packages d’identificateur de fonctionnalité requis pour la maintenance de l’appareil. Exécutez cet outil chaque fois que des modifications sont apportées aux fichiers FM. Après avoir modifié les fichiers OEM FM ou OEM COMMON FM, exécutez buildfm oem. Après avoir modifié le fichier BSPFM, exécutez buildfm bsp <bspname>. Ces commandes sont exécutées à partir de l’interpréteur de commandes IoT Core.

Packages de support board (BSPs)

Les packages de support de carte contiennent un ensemble de logiciels, de pilotes et de configurations de démarrage pour une carte particulière, généralement fournis par un fabricant de cartes. Le fabricant de la carte peut fournir régulièrement des mises à jour pour la carte, que vos appareils peuvent recevoir et appliquer. Vous pouvez également créer votre propre BSP si le fabricant de carte n’en fournit pas et si vous disposez de l’ensemble correspondant de fichiers logiciels et de pilotes. Les BSP pris en charge sont répertoriés ici.

Fichiers image de mise à jour full Flash

Les fichiers FFU (Full Flash Update) sont des fichiers image qui peuvent être déployés (c’est-à-dire. « flashed ») sur un appareil matériel spécifique. Lorsque vous flashez un fichier FFU sur un appareil, tous les logiciels requis sont installés sur cet appareil en même temps. Un fichier image FFU regroupe les chargeurs de démarrage, le système d’exploitation Windows, les pilotes, les images périphériques et tous les autres fichiers requis dans un seul package.

Applications au premier plan et en arrière-plan

Il existe deux types d’applications qui peuvent s’exécuter sur Windows IoT Core.

• Applications de premier plan : ces applications ont une interface utilisateur. Une seule application peut s’exécuter sur un appareil IoT en tant qu’applications de premier plan. Si plusieurs applications de premier plan sont incluses dans l’image, une seule doit être définie comme démarrage automatique au démarrage.
• Applications en arrière-plan : ces applications n’ont pas d’interface utilisateur. Plusieurs applications peuvent s’exécuter sur un appareil IoT en tant qu’applications en arrière-plan. Vous pouvez configurer n’importe quel nombre d’applications en arrière-plan pour le démarrage automatique.

Pour plus d’informations, consultez Applications de premier plan ou Applications en arrière-plan.

Création de l’image : ImgGen et le fichier de configuration d’image (OEMInput.xml)

Pour créer l’image finale, vous allez utiliser l’outil imggen avec un fichier de configuration d’image ,OEMInput.xml fichier.

Le fichier de configuration d’image répertorie :

• Les manifestes de fonctionnalités (FMs) et les packages que vous souhaitez installer à partir de chacun d’eux.

• Identificateur de puce SoC , qui est utilisé pour aider à configurer les partitions d’appareil. Les valeurs prises en charge pour soc sont définies dans le bspfm.xml correspondant, sous <devicelayoutpackages>.

• Identificateur de l’appareil , qui est utilisé pour sélectionner la disposition de l’appareil. Les valeurs prises en charge pour l’appareil sont définies dans le bspfm.xml correspondant, sous <oemdeviceplatformpackages>.

• ReleaseType ( production ou test).

  Builds de vente au détail : nous vous recommandons de créer des images de vente au détail au début de votre processus de développement pour vérifier que tout fonctionne lorsque vous êtes prêt à être expédié.

  Ces builds contiennent toutes les fonctionnalités de sécurité activées.

  Pour utiliser ce type de build, tout votre code doit être signé à l’aide de certificats de signature de code de vente au détail (et non de test).

  Pour obtenir un exemple, consultez %SRC_DIR%\Products\SampleA\RetailOEMInput.xml.

  Builds de test : utilisez-les pour essayer de nouvelles versions de vos applications et pilotes créés par vous et vos partenaires fabricants de matériel.

  Certaines fonctionnalités de sécurité sont désactivées pour ces builds, ce qui vous permet d’utiliser des packages signés par un test ou en production.

  Ces builds incluent également des outils de développement tels que le transport de débogage, SSH et PowerShell, que vous pouvez utiliser pour résoudre les problèmes.

  Pour obtenir un exemple, consultez %SRC_DIR%\Products\SampleA\TestOEMInput.xml.

Domaine	Builds de vente au détail	Builds de test
Type de version d’image	ReleaseType : Production	ReleaseType : Test
Type de version du package	Seuls les packages de type de production sont pris en charge	Le type de production ou le type de test sont pris en charge
Packages signés par test	Non prise en charge	La fonctionnalité IOT_ENABLE_TESTSIGNING prise en charge doit être incluse.
Case activée d’intégrité du code	Pris en charge. Par défaut, cette option est activée.	Pris en charge. Par défaut, aucune stratégie n’est appliquée

Nous allons essayer.

Commencez ici : Obtenez les outils nécessaires pour personnaliser Windows IoT Core.