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éez un pool d'appareils IDT gratuitement RTOS
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 Free IDT RTOS pour tester un seul appareil ou plusieurs appareils dans un pool. Pour accélérer le processus de qualification, IDT for Free RTOS peut tester en parallèle des appareils répondant aux mêmes spécifications. 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 etSKU. Pour activer les compilations parallèles du code source pour différents groupes de test, IDT for Free RTOS copie le code source dans un dossier de résultats situé dans le dossier RTOS extrait IDT for Free. 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. IDTfor Free RTOS remplace cette variable par un chemin temporaire du code source copié. Pour de plus amples informations, veuillez consulter IDTpour les RTOS variables libres.
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. Le SKU est utilisé pour suivre les tableaux qualifiés.
Note
Si vous souhaitez répertorier votre carte dans le catalogue des appareils AWS partenaires, le tableau que SKU vous spécifiez ici doit correspondre à celui 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 chiffrement de clé publique que la carte prend en charge. PKCS11est requis pour la qualification. Les valeurs prises en charge sont
ECC
RSA
, etBoth
.Both
indique que le tableau prend en charge les deuxECC
etRSA
. -
KeyProvisioning
-
Indique la méthode d'écriture d'un certificat client X.509 approuvé sur votre carte.
Les valeurs valides sont
Import
Onboard
,Both
etNo
.Onboard
Both
, ou l'approvisionnementNo
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
ouNo
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émentsecureElementConfig
dans chacune des sections de l'appareil et indiquez le chemin absolu vers le fichier de clé publique dans le champpublicKeyAsciiHexFilePath
. -
À 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éapprovisionné.
-
-
OTA
-
Indique si votre tableau prend en charge la fonctionnalité de mise à jour over-the-air (OTA). L'
OtaDataPlaneProtocol
attribut indique le protocole de OTA plan de données pris en charge par le périphérique. OTAavec l'un HTTP ou l'autre protocole du MQTT plan de données est requis pour la qualification. Pour ignorer l'exécution OTA des tests pendant les tests, définissez la OTA fonctionnalité surNo
et l'OtaDataPlaneProtocol
attribut surNone
. Il ne s'agira pas d'une course de qualification. -
BLE
-
Indique si votre carte est compatible avec le 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
PublicDeviceCertificateArn
est fournie NOTpre-provisioned
ou non. CommeOnboard
il s'agit d'un type obligatoire de fourniture de clés, ce champ est actuellement obligatoire pour le groupe de FullTransportInterface TLS test. Si votre appareil l'estpre-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 :
-
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 fichierpubkey.der
:base64 —decode base64key > pubkey.der
-
Exécutez la xxd commande suivante pour convertir
pubkey.der
au format hexadécimal. La clé obtenue est enregistrée sousoutFile
xxd -p pubkey.der >
outFile
-
-
devices.secureElementConfig.PublicDeviceCertificateArn
-
Le certificat ARN de votre élément sécurisé qui est téléchargé sur 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 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 JITR clés.
-
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 cette option sur Oui si l'PKCS11implémentation principale de l'appareil prend en charge le stockage pourJITP. Cela permettra le JITP
codeverify
test lors du test du noyau PKCS 11 et nécessite la fourniture des étiquettes de clé de vérification du code, de certificat et de certificat racine PKCS 11. JITP -
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.