Förberedelse av tillverkningsprocessen

Viktigt!

Det här är dokumentationen om Azure Sphere (Legacy). Azure Sphere (Legacy) upphör den 27 september 2027 och användarna måste migrera till Azure Sphere (integrerad) vid den här tiden. Använd versionsväljaren ovanför TOC för att visa dokumentationen om Azure Sphere (integrerad).

Tillverkningsprocessen omfattar både uppgifter på fabriksgolvet och molnkonfigurationsuppgifter. Förberedelse krävs för att säkerställa att dessa uppgifter kan slutföras utan avbrott.

Följande förberedelsesteg hjälper dig att säkerställa att tillverkningsprocessen fungerar smidigt:

• Konfigurera utrustning och installera pc-programvara
• Utveckla program för funktionell testning
• Kontrollera att program och skript fungerar
• Förbereda för en uppdatering av operativsystemet
• Post-ID:t och annan information
• Hämta produktionssignerade avbildningar

Viktigt!

Vissa förberedelsesteg omfattar Azure Sphere CLI. Du behöver en dator med en Internetanslutning och Azure Sphere SDK för att slutföra sådana steg. Installationsanvisningar för SDK finns i Installera Azure Sphere SDK för Windows eller Installera Azure Sphere SDK för Linux.

Konfigurera utrustning och installera pc-programvara

Både uppgifter på fabriksgolvet och molnkonfigurationsuppgifter kräver en dator. Annan nödvändig utrustning beror på vilken uppsättning uppgifter som utförs, enligt beskrivningen i det här avsnittet. De flesta tillverkningsuppgifter kräver också vissa programvaruverktyg, som måste installeras på den dator som används för dessa uppgifter.

Utrustning för uppgifter på fabriksgolvet

Uppgifterna på fabriksgolvet kräver följande utrustning:

• En dator på fabriksgolvet. Varje Azure Sphere-enhet måste vara ansluten till en dator på fabriksgolvet. Den här datorn måste köra Windows 11, Windows 10 Anniversary Update (eller senare) eller Linux (Ubuntu 24.04 (förhandsversion), Ubuntu 22.04 eller Ubuntu 20.04).

  Du kan samtidigt ansluta så många Azure Sphere-enheter till datorn som datorns USB-undersystem stöder. Datorprogramverktygen begränsar inte antalet enheter som kan anslutas samtidigt.

• Ett chip-till-PC-gränssnitt. Det här gränssnittet krävs av datorprogramverktygen för USB-UART-kommunikation mellan datorn och den anslutna enheten.

  

  Du väljer hur du implementerar det här gränssnittet:

  • Utforma ett gränssnittskort som ansluter till datorn under tillverkningen.

  • Utforma ett gränssnitt som är inbyggt i varje ansluten enhet. Till exempel innehåller MT3620-referenskortdesignen (RDB) ett sådant gränssnitt.

  Mer information om designkraven för chip-till-PC-gränssnittet finns i MCU-programmerings- och felsökningsgränssnittet .

• En Wi-Fi-åtkomstpunkt. En enhet måste kunna ansluta till Wi-Fi för att verifiera att kundprogrammet kan kommunicera via Wi-Fi. Wi-Fi-anslutningen får inte ha internetåtkomst eftersom en uppdatering över luften kan inträffa om chipet ansluter till en Internetaktiverad åtkomstpunkt.

• Extern testutrustning (valfritt). För funktionella tester kanske du vill ansluta kringutrustningens UART på MT3620 (ISU0, ISU1, ISU2 eller ISU3) till extern testutrustning via lämpliga kretsar av egen design. Om du har skapat ett chip-till-PC-gränssnitt på en separat tavla, enligt beskrivningen i det andra punktobjektet, kanske du vill lägga till den här kretskretsen på kortet.

• Radiofrekvens (RF) testutrustning. Den här utrustningen är endast nödvändig om du inkluderar RF-testning och kalibrering i dina uppgifter på fabriksgolvet. Mer information finns i Utrustning och programvara för RF-testning och kalibrering.

Utrustning för molnkonfigurationsuppgifter

Molnkonfigurationsuppgifterna kräver följande utrustning:

• En dator för molnkonfiguration. Azure Sphere-enheter behöver inte vara anslutna till molnkonfigurationsdatorn. Den här datorn måste köra Windows 11, Windows 10 Anniversary Update (eller senare) eller Linux.

• En internetanslutning. Den dator som används för molnkonfiguration måste vara ansluten till Internet.

Utrustning och programvara för RF-testning och kalibrering

Kraven och utformningen av produkten avgör om du måste inkludera RF-testning och kalibrering i dina uppgifter på fabriksgolvet. Om din produkt kräver Wi-Fi och den innehåller något av följande måste du utföra RF-testning och kalibrering för varje enhet:

• En chip-down design

• En modul som inte redan är RF-certifierad – kontakta din leverantör om du har frågor.

Följande utrustning och pc-programvara krävs för RF-testning och kalibrering:

• RF-testutrustning. Den här utrustningen kommer att användas med RF-verktygspaketet, som beskrivs i nästa punktlista.

  Du ansvarar för integreringen mellan RF-verktygen C, C# eller Python-biblioteken och testutrustningen. För närvarande har Microsoft samarbetat med LitePoint för att tillhandahålla en nyckelfärdig lösning som integrerar Azure Sphere RF-testbiblioteket med LitePoint-utrustningen.

  

• RF Tools-paket. Den här pc-programvaran innehåller verktyg och C-, C#- och Python-API-bibliotek för användning vid testning och kalibrering av RF-åtgärder. Med API-biblioteken kan du skapa anpassade program för RF-testning och kalibrering.

  Kontakta din Microsoft-representant för att hämta det här paketet. Installera den på din dator på fabriksgolvet. Om testhuset behöver använda verktyget för att certifiera din enhet kontaktar du din Microsoft-representant innan du delar programvaran med dem.

Datorprogramverktyg

Olika uppgifter på fabriksgolvet och molnkonfigurationsuppgifter kan använda följande datorprogramverktyg. Dessa programvaruverktyg måste installeras på den dator som används för dessa uppgifter.

• Azure Sphere SDK. SDK innehåller Azure Sphere CLI och andra verktyg för att skapa och hantera program och distributioner. CLI-kommandon kan utföra åtgärder som att läsa in programvara på en ansluten enhet, göra anspråk på en enhet och hämta information om en ansluten enhet. SDK:t behövs för både fabriks- och molnkonfigurationsuppgifter.

  Installera SDK :t för Windows eller för Linux, beroende på vilken dator som körs.

• Tillverkningsexempel. Tillverkningsexemplen ger stöd för både fabriks- och molnkonfigurationsuppgifter och omfattar:

  • Python- och C#-klientbibliotek för rest-API:et för enheter som implementerar direkt kommunikation mellan datorer och enheter för optimerad tillverkning. Dessa är också tillgängliga från PyPI och NuGet.
  • En uppsättning tillverkningsverktyg som är Python-skript som automatiserar olika tillverkningssteg, inklusive enhetsberedskapskontroller, återställning med flera rutor och OTA-konfiguration med flera bräden.

• RF Tools-paket. Det här paketet är bara nödvändigt om du inkluderar RF-testning och kalibrering i dina uppgifter på fabriksgolvet. Mer information finns i Utrustning och programvara för RF-testning och kalibrering.

Utveckla program för funktionell testning

Funktionstester kontrollerar att produkten fungerar korrekt. De specifika tester som du ska köra beror på din enskilda maskinvara. Funktionstester måste ingå i uppgifterna på fabriksgolvet.

Du kan organisera dina tester som ett enda program eller som en serie program. Översikt över Azure Sphere-program, Azure Sphere-exempel och mallar i Azure Sphere SDK innehåller information om programdesign. Oavsett vilken design du väljer måste dina program för funktionstestning vara produktionssignerade enligt beskrivningen i förberedelsesteget Hämta produktionssignerade avbildningar och sedan distribueras som en del av processen på fabriksgolvet.

För att rapportera fel, loggdata eller sekvenstester kräver vissa funktionella tester kommunikation med chipet som testas. Om du vill aktivera sådan kommunikation kan du använda de kringutrustnings-UART:erna på MT3620 (ISU0, ISU1, ISU2 eller ISU3). Anslut dessa UARTs till antingen din dator på fabriksgolvet eller extern testutrustning via lämpliga kretsar i din egen design. Om du har skapat ett gränssnittskort för att stödja chip-to-PC-kommunikation kanske du vill lägga till den här kretskretsen på kortet.

Kontrollera att program och skript fungerar

Du bör noggrant testa dina färdiga produktprogram, testprogram och testskript. Omtestning rekommenderas när du uppdaterar Azure Sphere SDK, Azure Sphere OS eller din programvara.

Följ dessa riktlinjer:

• Kontrollera att dina testprogram och färdiga produktprogram kan installeras, köras och tas bort.

• Kontrollera att dina testskript, testprogram och färdiga produktprogram fungerar med de senaste versionerna av Azure Sphere SDK och Azure Sphere OS.

Förbereda för en uppdatering av operativsystemet

En uppdaterad Version av Azure Sphere OS kan behöva läsas in på enheter under tillverkningen när ett separat program har uppdateringar som kräver os-funktioner som endast finns i en nyare version av operativsystemet eller när Microsoft släpper ett operativsystem med säkerhetsuppdateringar.

Gör följande för att förbereda för en uppdatering av Azure Sphere-operativsystemet under tillverkningen:

• Skapa en plan för att uppdatera enheter till den nya operativsystemversionen. Du kan uppdatera enheter i din egen tillverkningslinje eller genom att samordna med maskinvaruleverantören.

• Kontrollera att versionen av Azure Sphere SDK på fabriks- och molnkonfigurationsdatorerna fungerar med en ny version av operativsystemet. Om det behövs uppdaterar du SDK enligt beskrivningen i Installera Azure Sphere SDK för Windows eller Installera Azure Sphere SDK för Linux.

• Se till att rf-testningen och kalibreringsprocessen fungerar med den nya os-versionen om du inkluderar RF-testning och kalibrering i dina uppgifter på fabriksgolvet. Se Kompatibilitet för RF-verktyg mellan os-versioner.

• Hämta de senast tillgängliga Azure Sphere OS-återställningsfilerna för MT3620-baserad maskinvara och lagra filerna på din dator på fabriksgolvet. Om du vill hämta dessa filer godkänner du licensvillkoren och laddar sedan ned filerna.

Post-ID:t och annan information

Tillverkningsaktiviteter kan kräva att du anger en avbildnings-, komponent-, produkt- eller enhetsgrupp. En post med de ID:er och namn som används för att identifiera dessa objekt ska skapas och lagras på lämpliga datorer för senare användning under fabriks- och molnkonfigurationsuppgifter. I det här avsnittet beskrivs hur du hämtar identifierande information för varje objekt.

Bild-ID och komponent-ID

Varje program har ett komponent-ID och ett avbildnings-ID. Registrera avbildnings-ID och komponent-ID under förberedelseaktiviteten Hämta produktionssignerade avbildningar . Både bild-ID och komponent-ID visas i utdata från kommandot azsphere image add , som används i förberedelseuppgiften.

Produktnamn och enhetsgrupp

Registrera namnen på produkter och enhetsgrupper när du skapar dem. Varje Azure Sphere-enhet måste tilldelas till en produkt och en enhetsgrupp som en del av molnkonfigurationsuppgifterna.

En tillverkare bör skapa en produkt för varje modell av en ansluten enhet, till exempel en diskmaskin eller kaffebryggare. Varje ansluten enhet har en enda produkt, men en enda produkt kan associeras med många enheter. När du skapar en produkt skapas standardenhetsgrupper i produkten. Du kan använda standardenhetsgrupperna eller skapa egna.

Om du vill skapa en produkt använder du kommandot azsphere product create enligt följande. Ersätt <product-name> och <product description> med ett namn respektive en beskrivning som passar din produkt.

azsphere product create --name <product-name> --description <product description>

För molnkonfiguration kan du antingen använda enhetsgruppen Produktionsstandard eller skapa en egen. Om du vill skapa en egen enhetsgrupp använder du kommandot azsphere device-group create enligt följande. Ersätt <device-group-name> med ett valfritt namn. Ersätt <product-name> med namnet på den produkt där du vill skapa din enhetsgrupp.

azsphere device-group create --name <device-group-name> --product <product-name>

Hämta produktionssignerade avbildningar

När du laddar upp en avbildning till Azure Sphere Security Service (AS3) signeras avbildningen så att den kan distribueras till enheter på ett sätt som är betrott. Enheter som distribueras i produktion accepterar endast produktionssignerade avbildningar som en del av Azure Spheres säkerhetslöfte. Under tillverkningen kanske du vill läsa in produktionssignerade avbildningar på enheter. För att undvika behovet av internetanslutning under processen på fabriksgolvet skapar du de produktionssignerade avbildningarna en gång, laddar ned dem från AS3 och sparar dem sedan på en dator på fabriksgolvet för separat inläsning under produktionen.

Program som endast är avsedda att användas under fabriksgolvet måste uttryckligen identifieras som tillfälliga avbildningar. Detta säkerställer att dessa program kan tas bort i slutet av testningsprocessen. Använd inte tillfälliga avbildningar för program som kommer att finnas kvar på enheten efter tillverkningen. annars fungerar inte over-the-air-uppdateringsprocessen korrekt.

Stegen för att hämta en produktionssignerad avbildning är följande:

1. Ladda upp bilden till AS3. Använd kommandot azsphere image add enligt följande och ersätt <path-to-image-package> med sökvägen och namnet på det avbildningspaket som innehåller programvaran. Inkludera parametern --temporary för att markera bilden som tillfällig. Annars utelämnar du den.

   azsphere image add --image <path-to-image-package> --temporary
   

2. Spara avbildnings-ID:t och komponent-ID:t som kommandot azsphere image add visade i dess utdata i steg 1. Du behöver dem senare för vissa uppgifter på fabriksgolvet och molnkonfigurationsuppgifter. Avbildnings-ID:t behövs också i nästa steg.

3. Ladda ned den produktionssignerade avbildningen. Använd kommandot azsphere image download (azsphere image download) och ersätt <image-id> med ID:t för avbildningen för att ladda ned och <file-path> med sökvägen och filnamnet där den nedladdade avbildningen ska sparas.

   azsphere image download --image <image-id> --destination <file-path>
   

Viktigt!

Om en enhet kan begäras till en annan klientorganisation än den som användes under stegen för att få en produktionssignerad avbildning måste du behålla de exakta originalfilerna (före uppladdningen) så att du kan ladda upp dem till den faktiska klientorganisationen som en enhet begärs till. Det här kravet beskrivs mer detaljerat i molnkonfigurationsuppgifter.

Hämta ett uppdaterat betrott nyckelarkiv

I vissa fall kan du ha en nyare produktionssignerad avbildning som du behöver tillämpa på ett äldre operativsystem. Detta kan inträffa om du uppdaterar programbilden, till exempel för att åtgärda ett fel.

Detta kan dock leda till ett problem. Operativsystemet innehåller ett "betrott nyckelarkiv" som gör att det kan lita på en uppsättning nycklar som används vid signering av produktionssignerade avbildningar. Om dina produktionssignerade avbildningar är nyare än operativsystemet, och om AS3 under tiden uppdaterade sin avbildningssigneringsnyckel, kanske operativsystemet inte litar på nyckeln som används för att signera avbildningen. Du kan avgöra om det här problemet påverkar en viss kombination av os- och produktionssignerade avbildningar genom att följa uppgifterna på fabriksgolvet.

Problemet kan åtgärdas genom att uppdatera operativsystemet som används i produktionen, se Förbereda för en uppdatering av operativsystemet. Men om du av någon anledning inte ville uppdatera operativsystemet kan du i stället använda det äldre operativsystemet och uppdatera bara det betrodda nyckelarkivet.

För att göra detta godkänner du licensvillkoren och laddar sedan ned återställningsbilderna och extraherar bara filen "trusted-keystore.bin" från zip-filen. Uppgifterna på fabriksgolvet beskriver hur du använder den här "trusted-keystore.bin"-filen för att uppdatera bara det betrodda nyckelarkivet.