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 IDT kostenlos einen Gerätepool RTOS
Zu testende Geräte werden in Gerätepools organisiert. Jeder Gerätepool besteht aus einem oder mehreren identischen Geräten. Sie können IDT kostenlos konfigurierenRTOS, um ein einzelnes Gerät oder mehrere Geräte in einem Pool zu testen. Um den Qualifizierungsprozess zu beschleunigen, RTOS kann IDT For Free 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 auf 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 haben undSKU. Um parallel Builds des Quellcodes für verschiedene Testgruppen zu ermöglichen, RTOS kopiert IDT For Free den Quellcode in einen Ergebnisordner innerhalb des RTOS extrahierten IDT For Free-Ordners. Sie müssen in Ihrem Build- oder Flash-Befehl mithilfe der testdata.sourcePath
Variablen auf den Quellcodepfad verweisen. IDTfor Free RTOS ersetzt diese Variable durch einen temporären Pfad des kopierten Quellcodes. Weitere Informationen finden Sie unter IDTfür kostenlose RTOS Variablen.
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 Foren zu verfolgen.
Anmerkung
Wenn Sie Ihr Board im Gerätekatalog für AWS Partner auflisten möchten, muss das, was SKU Sie hier angeben, dem entsprechenSKU, das Sie bei der Angebotserstellung verwendet haben.
-
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 Kryptographie-Algorithmus für öffentliche Schlüssel an, der vom Board unterstützt wird. PKCS11ist für die Qualifikation erforderlich. Unterstützte Werte sind
ECC
RSA
, undBoth
.Both
gibt an, dass das BoardECC
sowohl als auch unterstütztRSA
. -
KeyProvisioning
-
Gibt an, wie ein vertrauenswürdiges X.509-Clientzertifikat auf das Board geschrieben werden kann.
Gültige Werte sind
Import
Onboard
,Both
undNo
.Onboard
,Both
, oder die Bereitstellung vonNo
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
oderNo
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 einsecureElementConfig
-Element hinzufügen und fügen Sie den absoluten Pfad zur Datei des öffentlichen Schlüssels in das FeldpublicKeyAsciiHexFilePath
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
OtaDataPlaneProtocol
Attribut gibt an, welches OTA Datenebenenprotokoll das Gerät unterstützt. OTAFür die Qualifizierung ist HTTP entweder ein MQTT Datenebenenprotokoll erforderlich. Um die Ausführung von OTA Tests während des Tests zu überspringen, setzen Sie die OTA Funktion aufNo
und dasOtaDataPlaneProtocol
Attribut auf.None
Dies wird kein Qualifikationslauf sein. -
BLE
-
Zeigt an, ob Ihr Motherboard 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, ob Ihr Board im NOT
pre-provisioned
LieferumfangPublicDeviceCertificateArn
enthalten ist oder nicht. DaOnboard
es sich um eine erforderliche Art der Schlüsselbereitstellung handelt, ist dieses Feld derzeit für die FullTransportInterface TLS Testgruppe erforderlich. Falls es sich bei Ihrem Gerät um einpre-provisioned
solches handelt,PublicKeyAsciiHexFilePath
ist dies optional und muss nicht im Lieferumfang 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:
-
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
-
Führen Sie den folgenden xxd Befehl aus, um in das Hex-Format
pubkey.der
zu konvertieren. Der resultierende Schlüssel wird gespeichert alsoutFile
xxd -p pubkey.der >
outFile
-
-
devices.secureElementConfig.PublicDeviceCertificateArn
-
Das ARN Zertifikat Ihres sicheren Elements, in das hochgeladen wurde AWS IoT Core. Informationen zum Hochladen Ihres Zertifikats auf AWS IoT Core finden Sie unter X.509-Client-Zertifikate 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) Auf „Ja“ setzen, 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) Legen Sie den Wert auf Ja fest, wenn die PKCS11 Core-Implementierung des Geräts Speicher für unterstützt. JITP Dadurch wird der JITP
codeverify
Test beim Testen von Core PKCS 11 aktiviert und es müssen die Labels für den Code-Verifizierungsschlüssel, JITP das Zertifikat und das Stammzertifikat PKCS 11 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.