Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Erstellen Sie einen Gerätepool in IDT für FreeRTOS Zu testende Geräte werden in Gerätepools organisiert. Jeder Gerätepool besteht aus einem oder mehreren identischen Geräten. Sie können IDT for FreeRTOS so konfigurieren, dass ein einzelnes Gerät oder mehrere Geräte in einem Pool getestet werden. Um den Qualifizierungsprozess zu beschleunigen, kann IDT for FreeRTOS Geräte mit denselben Spezifikationen parallel testen. Er verwendet eine Round Robin-Methode, um auf jedem Gerät in einem Gerätepool eine andere Testgruppe auszuführen. Die `device.json` Datei hat ein Array in der obersten Ebene. Jedes Array-Attribut ist ein neuer Gerätepool. Jeder Gerätepool hat ein Geräte-Array-Attribut, für das mehrere Geräte deklariert sind. In der Vorlage gibt es einen Gerätepool und nur ein Gerät in diesem Gerätepool. Sie können ein oder mehrere Geräte zu einem Gerätepool hinzufügen, indem Sie den Abschnitt `devices` der Vorlage `device.json` im Ordner `configs` bearbeiten. **Anmerkung** Alle Geräte im selben Pool müssen dieselbe technische Spezifikation und SKU haben. Um parallel Builds des Quellcodes für verschiedene Testgruppen zu ermöglichen, kopiert IDT for FreeRTOS den Quellcode in einen Ergebnisordner innerhalb des extrahierten IDT for FreeRTOS-Ordners. Sie müssen in Ihrem Build- oder Flash-Befehl mithilfe der Variablen auf den Quellcodepfad verweisen. `testdata.sourcePath` IDT for FreeRTOS ersetzt diese Variable durch einen temporären Pfad des kopierten Quellcodes. Weitere Informationen finden Sie unter [IDT für FreeRTOS-Variablen](lts-dt-vars.md). Die folgende `device.json` Beispieldatei wurde verwendet, um einen Gerätepool mit mehreren Geräten zu erstellen. ``` [ { "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" } ] } ] } ] ``` Die folgenden Attribute werden in der Datei `device.json` verwendet: ** `id` ** Eine benutzerdefinierte alphanumerische ID, die einen Gerätepool eindeutig identifiziert. Geräte, die zu einem Pool gehören, müssen vom gleichen Typ sein. Bei der Ausführung einer Reihe von Tests werden Geräte im Pool verwendet, um den Workload zu parallelisieren. ** `sku` ** Ein alphanumerischer Wert, mit dem das getestete Board eindeutig identifiziert wird. Die SKU wird verwendet, um qualifizierte Boards nachzuverfolgen. Wenn du dein Mainboard im Gerätekatalog für AWS Partner anbieten möchtest, muss die hier angegebene SKU mit der SKU übereinstimmen, die du bei der Angebotserstellung verwendest. ** `features` ** Ein Array, das die vom Gerät unterstützten Funktionen enthält. AWS IoT Device Tester verwendet diese Informationen, um die durchzuführenden Qualifikationstests auszuwählen. Unterstützte Werte sind: ** `Wifi` ** Gibt an, ob Ihr Board über WiFi-Funktionen verfügt. ** `Cellular` ** Zeigt an, ob Ihr Motherboard über Mobilfunkfunktionen verfügt. ** `PKCS11` ** Gibt den Kryptografiealgorithmus mit öffentlichen Schlüsseln an, den das Board unterstützt. PKCS11 ist für die Qualifikation erforderlich. Unterstützte Werte sind `ECC``RSA`, und`Both`. `Both`gibt an, dass das Board `ECC` sowohl als auch unterstützt`RSA`. ** `KeyProvisioning` ** Gibt an, wie ein vertrauenswürdiges X.509-Clientzertifikat auf das Board geschrieben werden kann. Gültige Werte sind `Import``Onboard`, `Both` und`No`. `Onboard`,`Both`, oder die Bereitstellung von `No` Schlüsseln ist für die Qualifizierung erforderlich. `Import`allein ist keine gültige Qualifizierungsoption. + Verwenden Sie diese Option `Import` nur, wenn Ihr Board den Import von privaten Schlüsseln zulässt. `Import`Die Auswahl ist keine gültige Konfiguration für die Qualifizierung und sollte nur zu Testzwecken verwendet werden, insbesondere bei PKCS11 Testfällen. `Onboard`, `Both` oder `No` ist für die Qualifizierung erforderlich. + Verwenden Sie diese Option, `Onboard` wenn Ihr Board integrierte private Schlüssel unterstützt (z. B. wenn Ihr Gerät über ein sicheres Element verfügt oder wenn Sie es vorziehen, Ihr eigenes Geräteschlüsselpaar und Ihr eigenes Zertifikat zu generieren). Stellen Sie sicher, dass Sie in jedem der Geräteabschnitte ein `secureElementConfig`-Element hinzufügen und fügen Sie den absoluten Pfad zur Datei des öffentlichen Schlüssels in das Feld `publicKeyAsciiHexFilePath` ein. + Verwenden Sie diese `Both` Option, wenn Ihr Board sowohl den Import von privaten Schlüsseln als auch die integrierte Schlüsselgenerierung für die Schlüsselbereitstellung unterstützt. + Verwenden Sie diese `No` Option, wenn Ihr Board die Schlüsselbereitstellung nicht unterstützt. `No`ist nur dann eine gültige Option, wenn Ihr Gerät ebenfalls vorab bereitgestellt wurde. ** `OTA` ** Zeigt an, ob Ihr Board die over-the-air Aktualisierungsfunktion (OTA) unterstützt. Das Attribut `OtaDataPlaneProtocol` gibt an, welches OTA-Protokoll auf Datenebene das Gerät unterstützt. Für die Qualifizierung ist ein OTA mit entweder dem HTTP- oder dem MQTT-Datenebenenprotokoll erforderlich. Um die Ausführung von OTA-Tests während des Tests zu überspringen, setzen Sie die OTA-Funktion auf `No` und das `OtaDataPlaneProtocol` Attribut auf. `None` Dies wird kein Qualifikationslauf sein. ** `BLE` ** Gibt an, ob Ihr Board Bluetooth Low Energy (BLE) unterstützt. ** `devices.id` ** Eine benutzerdefinierte eindeutige Kennung für das zu testende Gerät. ** `devices.connectivity.serialPort` ** Der serielle Port des Host-Computers, der zur Herstellung einer Verbindung mit den getesteten Geräten verwendet wird. ** `devices.secureElementConfig.PublicKeyAsciiHexFilePath` ** Erforderlich, wenn Ihr Board NICHT `pre-provisioned` oder nicht zur Verfügung gestellt `PublicDeviceCertificateArn` wird. Da `Onboard` es sich um eine erforderliche Art der Schlüsselbereitstellung handelt, ist dieses Feld derzeit für die FullTransportInterface TLS-Testgruppe erforderlich. Ob Ihr Gerät es ist`pre-provisioned`, `PublicKeyAsciiHexFilePath` ist optional und muss nicht enthalten sein. Der folgende Block ist ein absoluter Pfad zu der Datei, die den öffentlichen Hex-Byte-Schlüssel enthält, der aus dem `Onboard` privaten Schlüssel extrahiert wurde. ``` 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 ``` Wenn Ihr öffentlicher Schlüssel im.der-Format vorliegt, können Sie den öffentlichen Schlüssel direkt hexcodieren, um die Hex-Datei zu generieren. Um die Hex-Datei aus einem öffentlichen .der-Schlüssel zu generieren, geben Sie den folgenden Befehl ein: **xxd** ``` xxd -p pubkey.der > outFile ``` Wenn Ihr öffentlicher Schlüssel im.pem-Format vorliegt, können Sie die Base64-codierten Kopf- und Fußzeilen extrahieren und in das Binärformat dekodieren. Anschließend kodieren Sie die binäre Zeichenfolge hexadezimal, um die Hex-Datei zu generieren. Gehen Sie wie folgt vor, um eine Hex-Datei für einen öffentlichen PEM-Schlüssel zu generieren: 1. Führen Sie den folgenden **base64** Befehl aus, um die Base64-Kopf- und Fußzeile aus dem öffentlichen Schlüssel zu entfernen. Der dekodierte Schlüssel mit dem Namen wird `base64key` dann in die Datei ausgegeben: `pubkey.der` ``` base64 —decode base64key > pubkey.der ``` 1. Führen Sie den folgenden **xxd** Befehl aus, um in das Hex-Format `pubkey.der` zu konvertieren. Der resultierende Schlüssel wird gespeichert als `outFile` ``` xxd -p pubkey.der > outFile ``` ** `devices.secureElementConfig.PublicDeviceCertificateArn` ** Der ARN des Zertifikats von Ihrem sicheren Element, in das hochgeladen wird AWS IoT Core. Informationen zum Hochladen Ihres Zertifikats auf AWS IoT Core finden Sie unter [X.509-Client-Zertifikate](https://docs.aws.amazon.com/iot/latest/developerguide/x509-client-certs.html) im *AWS IoT Developer* Guide. ** `devices.secureElementConfig.SecureElementSerialNumber` ** (Optional) Die Seriennummer des sicheren Elements. Die Seriennummer wird optional verwendet, um Gerätezertifikate für die JITR-Schlüsselbereitstellung zu erstellen. ** `devices.secureElementConfig.preProvisioned` ** (Optional) Legen Sie diese Option auf „Ja“ fest, wenn das Gerät über ein vorab bereitgestelltes sicheres Element mit gesperrten Anmeldeinformationen verfügt, das keine Objekte importieren, erstellen oder zerstören kann. Wenn dieses Attribut auf **Ja** gesetzt ist, müssen Sie die entsprechenden pkcs11-Labels angeben. ** `devices.secureElementConfig.pkcs11JITPCodeVerifyRootCertSupport` ** (Optional) Auf **Ja** setzen, wenn die PKCS11 Core-Implementierung des Geräts Speicher für JITP unterstützt. Dadurch wird der `codeverify` JITP-Test beim Testen von Core-PKCS 11 aktiviert, und es müssen die PKCS 11-Labels für den Codeverifizierungsschlüssel, das JITP-Zertifikat und das Stammzertifikat bereitgestellt werden. ** `identifiers` ** (Optional) Ein Array beliebiger Namen-Wert-Paare. Sie können diese Werte in den im nächsten Abschnitt beschriebenen Build- und Flash-Befehlen verwenden.