Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Créer un pool d'appareils dans IDT pour FreeRTOS Les appareils à tester sont organisés dans des groupes. Chaque groupe d'appareils se compose d'un ou de plusieurs appareils identiques. Vous pouvez configurer IDT pour FreeRTOS afin de tester un seul appareil ou plusieurs appareils dans un pool. Pour accélérer le processus de qualification, IDT for FreeRTOS peut tester des appareils avec les mêmes spécifications en parallèle. Il utilise une méthode séquentielle pour exécuter un groupe de tests différents pour chaque appareil d'un groupe. Le `device.json` fichier possède un tableau à son niveau supérieur. Chaque attribut du tableau correspond à un nouveau pool de périphériques. Chaque pool de périphériques possède un attribut de tableau d'appareils, dans lequel plusieurs appareils sont déclarés. Dans le modèle, il existe un pool de périphériques et un seul appareil dans ce pool de périphériques. Vous pouvez ajouter un ou plusieurs appareils à un groupe d'appareils en modifiant la section `devices` du modèle `device.json` dans le dossier `configs`. **Note** Tous les appareils d'un même pool doivent avoir les mêmes spécifications techniques et le même SKU. Pour permettre des compilations parallèles du code source pour différents groupes de test, IDT pour FreeRTOS copie le code source dans un dossier de résultats à l'intérieur du dossier extrait d'IDT pour FreeRTOS. Vous devez référencer le chemin du code source dans votre commande de build ou de flash à l'aide de la `testdata.sourcePath` variable. IDT pour FreeRTOS remplace cette variable par un chemin temporaire du code source copié. Pour de plus amples informations, veuillez consulter [IDT pour les variables FreeRTOS](lts-dt-vars.md). Voici un exemple de `device.json` fichier qui a été utilisé pour créer un pool de périphériques avec plusieurs appareils. ``` [ { "id": "pool-id", "sku": "sku", "features": [ { "name": "Wifi", "value": "Yes | No" }, { "name": "Cellular", "value": "Yes | No" }, { "name": "BLE", "value": "Yes | No" }, { "name": "PKCS11", "value": "RSA | ECC | Both" }, { "name": "OTA", "value": "Yes | No", "configs": [ { "name": "OTADataPlaneProtocol", "value": "MQTT | HTTP | None" } ] }, { "name": "KeyProvisioning", "value": "Onboard | Import | Both | No" } ], "devices": [ { "id": "device-id", "connectivity": { "protocol": "uart", "serialPort": "/dev/tty*" }, "secureElementConfig" : { "publicKeyAsciiHexFilePath": "absolute-path-to/public-key-txt-file: contains-the-hex-bytes-public-key-extracted-from-onboard-private-key", "publiDeviceCertificateArn": "arn:partition:iot:region:account-id:resourcetype:resource:qualifier", "secureElementSerialNumber": "secure-element-serialNo-value", "preProvisioned" : "Yes | No", "pkcs11JITPCodeVerifyRootCertSupport": "Yes | No" }, "identifiers": [ { "name": "serialNo", "value": "serialNo-value" } ] } ] } ] ``` Les attributs suivants sont utilisés dans le fichier `device.json` : ** `id` ** Un ID alphanumérique défini par l'utilisateur qui identifie de façon unique un groupe d'appareils. Les appareils appartenant à un groupe doivent être du même type. Lorsque vous exécutez une suite de tests, les appareils du groupe sont utilisés pour paralléliser la charge de travail. ** `sku` ** Une valeur alphanumérique qui identifie de façon unique la carte que vous testez. La référence est utilisée pour effectuer le suivi des cartes qualifiées. Si vous souhaitez mettre votre carte en vente dans le catalogue des appareils AWS partenaires, le SKU que vous spécifiez ici doit correspondre au SKU que vous avez utilisé lors du processus de mise en vente. ** `features` ** Tableau contenant les fonctionnalités prises en charge par l'appareil. AWS IoT Device Tester utilise ces informations pour sélectionner les tests de qualification à exécuter. Les valeurs prises en charge sont : ** `Wifi` ** Indique si la carte contient des fonctionnalités Wi-Fi. ** `Cellular` ** Indique si votre carte est dotée de fonctionnalités cellulaires. ** `PKCS11` ** Indique l'algorithme de cryptographie à clé publique pris en charge par la carte. PKCS11 est requis pour la qualification. Les valeurs prises en charge sont `ECC``RSA`, et`Both`. `Both`indique que le tableau prend en charge les deux `ECC` et`RSA`. ** `KeyProvisioning` ** Indique la méthode d'écriture d'un certificat client X.509 approuvé sur votre carte. Les valeurs valides sont `Import``Onboard`, `Both` et`No`. `Onboard``Both`, ou l'approvisionnement `No` des clés est requis pour la qualification. `Import`à elle seule, n'est pas une option valide pour la qualification. + À utiliser `Import` uniquement si votre forum autorise l'importation de clés privées. `Import`La sélection n'est pas une configuration valide pour la qualification et ne doit être utilisée qu'à des fins de test, en particulier pour les cas de PKCS11 test. `Onboard`, `Both` ou `No` est requis pour la qualification. + À utiliser `Onboard` si votre carte prend en charge les clés privées intégrées (par exemple, si votre appareil possède un élément sécurisé ou si vous préférez générer votre propre paire de clés et votre propre certificat). Veillez à ajouter un élément `secureElementConfig` dans chacune des sections de l'appareil et indiquez le chemin absolu vers le fichier de clé publique dans le champ `publicKeyAsciiHexFilePath`. + À utiliser `Both` si votre tableau prend en charge à la fois l'importation de clés privées et la génération de clés intégrée pour le provisionnement des clés. + À utiliser `No` si votre tableau ne prend pas en charge l'approvisionnement en clés. `No`n'est une option valide que lorsque votre appareil est également préconfiguré. ** `OTA` ** Indique si votre carte mère prend en charge la fonctionnalité de mise à jour over-the-air (OTA). L'attribut `OtaDataPlaneProtocol` indique le protocole de plan de données OTA pris en charge par le périphérique. L'OTA avec le protocole de plan de données HTTP ou MQTT est requis pour la qualification. Pour ignorer l'exécution des tests OTA pendant les tests, définissez la fonctionnalité OTA sur `No` et l'`OtaDataPlaneProtocol`attribut sur`None`. Il ne s'agira pas d'une course de qualification. ** `BLE` ** Indique si la carte prend en charge Bluetooth Low Energy (BLE). ** `devices.id` ** Un identificateur unique défini par l'utilisateur pour l'appareil testé. ** `devices.connectivity.serialPort` ** Le port série de l'ordinateur hôte utilisé pour se connecter aux appareils testés. ** `devices.secureElementConfig.PublicKeyAsciiHexFilePath` ** Obligatoire si votre planche n'est PAS `pre-provisioned` ou n'`PublicDeviceCertificateArn`est pas fournie. Comme `Onboard` il s'agit d'un type obligatoire de fourniture de clés, ce champ est actuellement obligatoire pour le groupe de test FullTransportInterface TLS. Si votre appareil l'est`pre-provisioned`, `PublicKeyAsciiHexFilePath` il est facultatif et n'a pas besoin d'être inclus. Le bloc suivant est un chemin absolu vers le fichier contenant la clé publique en octets hexadécimaux extraite de la clé `Onboard` privée. ``` 3059 3013 0607 2a86 48ce 3d02 0106 082a 8648 ce3d 0301 0703 4200 04cd 6569 ceb8 1bb9 1e72 339f e8cf 60ef 0f9f b473 33ac 6f19 1813 6999 3fa0 c293 5fae 08f1 1ad0 41b7 345c e746 1046 228e 5a5f d787 d571 dcb2 4e8d 75b3 2586 e2cc 0c ``` Si votre clé publique est au format .der, vous pouvez l'encoder directement en hexadécimal pour générer le fichier hexadécimal. Pour générer le fichier hexadécimal à partir d'une clé publique .der, entrez la commande suivante : **xxd** ``` xxd -p pubkey.der > outFile ``` Si votre clé publique est au format .pem, vous pouvez extraire les en-têtes et pieds de page codés en base64 et les décoder au format binaire. Ensuite, vous codez la chaîne binaire en hexadécimal pour générer le fichier hexadécimal. Pour générer un fichier hexadécimal pour une clé publique .pem, procédez comme suit : 1. Exécutez la **base64** commande suivante pour supprimer l'en-tête et le pied de page base64 de la clé publique. La clé décodée, nommée`base64key`, est ensuite sortie dans le fichier `pubkey.der` : ``` base64 —decode base64key > pubkey.der ``` 1. Exécutez la **xxd** commande suivante pour convertir `pubkey.der` au format hexadécimal. La clé obtenue est enregistrée sous `outFile` ``` xxd -p pubkey.der > outFile ``` ** `devices.secureElementConfig.PublicDeviceCertificateArn` ** L'ARN du certificat de votre élément sécurisé qui est téléchargé vers AWS IoT Core. Pour plus d'informations sur le téléchargement de votre certificat vers AWS IoT Core, consultez la section [Certificats client X.509](https://docs.aws.amazon.com/iot/latest/developerguide/x509-client-certs.html) dans le guide du *AWS IoT développeur*. ** `devices.secureElementConfig.SecureElementSerialNumber` ** (Facultatif) Numéro de série de l'élément sécurisé. Le numéro de série est éventuellement utilisé pour créer des certificats d'appareil pour le provisionnement des clés JITR. ** `devices.secureElementConfig.preProvisioned` ** (Facultatif) Réglez sur « Oui » si l'appareil possède un élément sécurisé préconfiguré avec des informations d'identification verrouillées, qui ne peut pas importer, créer ou détruire des objets. Si cet attribut est défini sur **Oui**, vous devez fournir les étiquettes pkcs11 correspondantes. ** `devices.secureElementConfig.pkcs11JITPCodeVerifyRootCertSupport` ** (Facultatif) Définissez ce paramètre sur **Oui** si l'PKCS11 implémentation principale de l'appareil prend en charge le stockage pour JITP. Cela permettra le test JITP lors du `codeverify` test du noyau PKCS 11 et nécessitera la fourniture d'étiquettes de clé de vérification du code, de certificat JITP et de certificat racine PKCS 11. ** `identifiers` ** (Facultatif) Un tableau de paires nom-valeur arbitraires. Vous pouvez utiliser ces valeurs dans les commandes de création et flash décrites dans la section suivante.