Aktiviteter på fabriksgolvet
Tillverkning av anslutna enheter som innehåller Azure Sphere-maskinvara omfattar följande aktiviteter på fabriksgolvet för att förbereda enheter för leverans:
- Ansluta varje Azure Sphere-chip till en dator på fabriksgolvet
- Hämta enhetsinformation och spela in dem för senare användning
- Uppdatera Azure Sphere-operativsystemet om det behövs
- Uppdatera den betrodda nyckellagringen om det behövs
- Läser in programvara på enheten
- Köra funktionstester för att kontrollera att produkten fungerar korrekt
- Utföra radiofrekvenstestning (RF) och kalibrering
- Verifiera Wi-Fi kommunikation
- Konfigurera enheten för Ethernet
- Slutföra Azure Sphere-enheten för leverans
Du måste ansluta chipet till datorn först, få information om enheten först och slutföra enheten sist, men du kan utföra de andra uppgifterna i valfri ordning som passar din tillverkningsmiljö.
Viktigt
Du bör förbereda dig lite för att se till att dina aktiviteter på fabriksgolvet kan slutföras utan fördröjningar. Förberedelse omfattar konfiguration av fabriksgolvet dator och annan nödvändig utrustning och installation av nödvändiga datorprogramverktyg. Alla uppgifter som du bör utföra för att förbereda en smidig tillverkningsprocess beskrivs i förberedelsen av tillverkningsprocessen.
Anslut varje Azure Sphere-chip till en dator på fabriksgolvet
Under tillverkningen måste du ansluta varje Azure Sphere-chip till en dator på fabriksgolvet. Om du samtidigt vill ansluta flera Azure Sphere-enheter till en enda dator läser du Utrustning för aktiviteter på fabriksgolvet i tillverkningsförberedelseuppgifterna.
De flesta aktiviteter på fabriksgolvet omfattar az sphere-enhetskommandot . När du har flera enheter anslutna till datorn måste du ange vilken enhet som ska använda az sphere-enhetskommandot genom att inkludera --device parameteruppsättningen till antingen enhetens IP-adress eller enhetens anslutningssökväg. Kommandot misslyckas om parametern --device utelämnas och flera enheter är anslutna. Information om hur du hämtar IP-adressen eller anslutningssökvägen finns i Hämta enhetsinformation.
Viktigt
Azure Sphere SDK stöder kommunikation med flera anslutna enheter endast med Windows. Om du använder Linux stöds kommunikation med endast en enda ansluten enhet. Men du kan använda flera virtuella Linux-datorer (VMs), var och en med en enda USB-port mappad till den, för att ha en enda dator med flera Linux-instanser som kommunicerar med flera Azure Sphere-enheter samtidigt.
Hämta enhetsinformation
Du måste registrera enhets-ID för varje Azure Sphere-chip som ditt företag införlivar i tillverkade produkter. Du behöver enhets-ID:t för molnkonfigurationsuppgifter.
Om du har flera enheter anslutna till fabriksdatorn måste du också registrera IP-adressen eller anslutningssökvägen för anslutna enheter för senare användning i aktiviteter på fabriksgolvet. Som beskrivs i Ansluta varje Azure Sphere-chip krävs IP-adress eller anslutningssökväg för att ange målenheten när det finns flera anslutna enheter.
Om du vill hämta enhets-ID, IP-adress och anslutningssökväg för anslutna enheter använder du det az sphere device list-attached kommandot. Följande beskrivningar innehåller viktig information om enhets-ID, IP-adress och anslutningssökväg.
Enhets-ID : Silicontillverkaren skapar enhets-ID:t, lagrar det på chipet och registrerar det hos Microsoft. Den här enhetsregistreringen säkerställer att Microsoft är medvetna om alla Azure Sphere-kretsar och att endast legitima kretsar kan användas i anslutna enheter.
IP-adress – IP-adressen tilldelas när ett FTDI-baserat enhetsgränssnitt ansluts till datorn. indikerar det inte att det finns någon responsiv enhet. IP-adressen finns kvar medan det FTDI-baserade enhetsgränssnittet är anslutet till datorn, även om en annan Azure Sphere-enhet är ansluten till gränssnittet. Efter en datoromstart kan dock IP-adressen ändras. Det första FTDI-baserade enhetsgränssnittet som ska anslutas tilldelas adressen 192.168.35.2. Varje enhet tilldelas en IP-adress, även om den inte svarar, så att du kan använda IP-adressen för att identifiera en enhet som kräver återställning.
Anslutningssökväg – Anslutningssökvägen är ett FTDI-plats-ID som identifierar USB-anslutningen. Plats-ID:t finns kvar medan det FTDI-baserade enhetsgränssnittet är anslutet till samma USB-port på samma USB-hubb och i sin tur till samma port på datorn. Detta innebär att den finns kvar över omstarten. Ändringar i ledningar mellan datorn och enheten kan dock leda till ändringar i anslutningssökvägen. Precis som IP-adressen ändras den inte även om en annan Azure Sphere-enhet är ansluten till FTDI-gränssnittet.
Uppdatera operativsystemet Azure Sphere
Alla Azure Sphere-chip laddas med Azure Sphere-operativsystemet när det levereras från silicontillverkaren. Beroende på vilken version av Azure Sphere-operativsystemet som finns på chips som är tillgängliga från din leverantör, och beroende på os-versionskrav för ditt program, kan du behöva uppdatera Azure Sphere-operativsystemet under tillverkningen av den anslutna enheten. Du kan uppdatera operativsystemet genom att installera specifika återställningsbilder, som redan ska finnas på datorn. Se Förbereda en uppdatering av operativsystemet i tillverkningsförberedelseaktiviteterna. Tillverkningsexemplen innehåller ett exempelskript som utför parallell återställning med flera enheter.
Du kan uppdatera operativsystemet på Azure Sphere-enheten genom att utfärda återställningskommandot för az sphere-enheten . Använd parametern --images för att installera specifika återställnings avbildningar:
az sphere device recover --images <path-to-images> [--device <IP-address or connection-path>]
Observera
Om flera enheter är anslutna till datorn tar du med parametern --device för att identifiera målenheten via IP-adress eller anslutningssökväg. Mer information finns i Ansluta varje Azure Sphere-chip till en dator på fabriksgolvet .
Uppdatera den betrodda nyckellagringen
Som en förutsättning för att läsa in programvara på enheten kan du behöva uppdatera den betrodda nyckellagringen på enheten. Detta krävs endast om operativsystemet på enheten är äldre än din programvara och endast om Azure Sphere-avbildningssigneringsnyckeln som används av AS3 uppdaterades mellan operativsystemet som publiceras och din programvara är produktionssignerad. Om du vill undvika det här steget och minska tillverkningstiden bör du överväga att uppdatera den OS-version du använder under tillverkningen.
Du kan enkelt avgöra om det krävs en uppdatering av den betrodda nyckellagringen genom att försöka läsa in programvaran enligt anvisningarna i nästa avsnitt. Om inläsningen lyckas behöver du inte uppdatera den betrodda nyckellagringen. Om inläsningen misslyckas med att meddelandet börjar med Internal device error: Image not trusted by device är en inaktuell betrodd nyckellagring orsaken.
Om du vill uppdatera den betrodda nyckellagringsfilen måste du ha skaffat den aktuella betrodda nyckellagringsfilen. Som en del av dina tillverkningsskript använder du sedan kommandot az sphere device sideload deploy för att läsa in den uppdaterade betrodda nyckellagringen innan programprogramvara läses in och ersätts <path-to-trusted-keystore.bin> med sökvägen till den betrodda nyckellagringsfilen:
az sphere device sideload deploy --image-package <path-to-trusted-keystore.bin> [--device <IP-address or connection-path>]
Läsa in enhetsprogramvara
All programvara som du laddar – oavsett om det är en avbildning av en anslagstavla, ett testprogram eller ett produktionsprogram – måste vara produktionssignerad. Om du läser in ett tillfälligt program för testning måste du ta bort det när testningen är klar.
Alla produktionssignerade avbildningar som du behöver under fabriksgolvet ska sparas på fabriksgolvet innan du påbörjar processen, enligt beskrivningen i Hämta produktionssignerade avbildningar i tillverkningsförberedelseuppgifterna.
Under tillverkningen får Azure Sphere-enheter inte kräva några särskilda enhetsfunktioner, till exempel apputvecklingsfunktionen, som gör det möjligt att felsöka. Att skaffa funktioner för enskilda enheter minskar enhetens säkerhet och kräver internetanslutning, vilket vanligtvis inte är önskvärt på fabriksgolvet.
Om du vill läsa in programvara på en enhet i fabriken eller ta bort tillfällig programvara från en enhet när testningen är klar, använder du kommandot az sphere-enhet för separat inläsning enligt följande:
Använd az sphere device sideload deploy för att läsa in en avbildning och ersätta
<file-path>med namnet och sökvägen till den produktionssignerade avbildningsfilen:az sphere device sideload deploy --image-package <file-path> [--device <IP-address or connection-path>]Använd az sphere device sideload delete för att ta bort en tillfällig avbildning och ersätta
<component-id>med komponent-ID:n för den avbildning som ska tas bort:az sphere device sideload delete --component-id <component-id> [--device <IP-address or connection-path>]
Observera
Om flera enheter är anslutna till datorn tar du med parametern --device för att identifiera målenheten via IP-adress eller anslutningssökväg. Mer information finns i Ansluta varje Azure Sphere-chip till en dator på fabriksgolvet .
Kör funktionella tester
Funktionstester är nödvändiga för att verifiera att produkten fungerar korrekt. Kör de program som du utvecklat för funktionell testning som en del av tillverkningsförberedelseuppgifterna. Se Utveckla program för funktionell testning.
Om dina funktionstester kräver kommunikation med det chip som testas ansluter du MT3620-kringutrustningen (ISU0, ISU1, ISU2 eller ISU3) till din fabriksdator eller extern testutrustning via lämpliga kretsar av din egen design.
Utföra radiofrekvenstestning (RF) och kalibrering
Azure Sphere-kretsar kan använda Wi-Fi för att ta emot programuppdateringar och kommunicera med Internet. Om din produkt använder Wi-Fi och den antingen har en chip-down-design eller en modul som inte är RF-certifierad, måste du utföra RF-tester och kalibrering för varje enhet. Utrustning och verktyg som behövs för den här uppgiften beskrivs i Utrustning och programvara för RF-testning och kalibrering i tillverkningsförberedelseuppgifterna.
RF-verktygspaketet innehåller verktyg och ett C API-bibliotek för användning vid testning. Du kan använda C API-biblioteket för att programmera produktspecifika RF-inställningar i e-säkringar. Till exempel är e-säkringar programmerade för att konfigurera antennen och frekvensen, för att finjustera enheter för optimal prestanda och för att aktivera Wi-Fi kanaler. I avsnittet testverktyg för RF beskrivs hur du använder RF-verktygen.
Programmera e-säkringar för att aktivera Wi-Fi kanaler
Azure Sphere-operativsystemet väljer Wi-Fi kanaler baserat på regionskoden som är programmerad till MT3620-e-säkringar vid förskjutningsadresser 0x36 och 0x37. Mer information om e-säkringar på MT3620 finns i mediatekdokumentet MT3620 E-fuse Content Guidelines .
Regionkoden är en ASCII-kod på två bokstäver. Azure Sphere-operativsystemet använder regionskodsinställningen i e-säkringarna för att leta upp regionen i linux trådlösa regeldatabas och väljer sedan vilka kanaler som tillåts för den regionen. Om ingen riktnummer är programmerad i e-säkringarna, i vilket fall e-säkringarna förblir inställda på 0x00 0x00, eller om tecknen "00" är programmerade, används en konservativ uppsättning kanaler som vanligtvis är tillåtna i alla regioner. De kanaler som tillåts för region "00" anges i Linux trådlösa regeldatabas.
Regionkodsinställningen i e-säkringarna behöver inte matcha landet där enheten ska användas. Tillverkare kan välja vilken regionskod som helst som mappas till en tillåten uppsättning kanaler för region. Olika regioner och länder antar ofta liknande eller identiska förordningar, vilket kan göra det möjligt att använda riktnummer parallellt.
Exempel: För att instruera Azure Sphere OS att välja Wi-Fi kanaler för regionen "DE" (Tyskland), program 0x44=D och 0x45=E i e-säkringar på adresser 0x36 och 0x37. De tillåtna kanalerna för Tyskland, utdragna från Linux trådlösa regeldatabas, visas nedan. De flesta länder i Europeiska unionen (EU) tillåter samma uppsättning kanaler.
country DE: DFS-ETSI
(2400 - 2483.5 @ 40), (100 mW)
(5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
(5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
(5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
# short range devices (ETSI EN 300 440-1)
(5725 - 5875 @ 80), (25 mW)
# 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
Kontrollera RF-konfiguration
Använd RfSettingsTool för att kontrollera att alternativkonfigurationsalternativ som målöverföringseffekt, regionskod och Wi-Fi Mac-adress (Media Access Control) har ställts in korrekt. Dokumentationen till verktyget för RF-inställningar ger mer information om hur du använder det här verktyget.
Kontrollera Wi-Fi kommunikation
Överväg att ansluta till en Wi-Fi åtkomstpunkt för att verifiera att produktprogrammet kan kommunicera via Wi-Fi. Se till att Wi-Fi-anslutningen inte har tillgång till Internet, eftersom det kan uppstå en luftbaserad uppdatering om chipet ansluts till en Internetaktiverad åtkomstpunkt.
Om du vill ansluta en enhet till en Wi-Fi åtkomstpunkt följer du anvisningarna på fliken Snabbstart (CLI). Om flera enheter är anslutna till datorn måste du ta med parametern --device i kommandot wifi show-status för az sphere-enheten och wi-add-kommandotaz sphere device . Mer information om hur du använder az sphere-enhetskommandot med flera anslutna enheter finns i Ansluta varje Azure Sphere-chip till en dator på fabriksgolvet.
Efter Wi-Fi testning bör du ta bort alla Wi-Fi åtkomstpunkter som används för testning från kretsen så att dessa inte visas för kunderna. Återställning av enhet tar bort alla Wi-Fi konfigurationsdata från chipet.
Konfigurera enheten för Ethernet
En Azure Sphere-enhet kan kommunicera via Ethernet. Enheten kräver en extern Ethernet-adapter och en avbildning för board-configuration för kommunikation via Ethernet.
Om du vill konfigurera en Azure Sphere-enhet för Ethernet ansluter du ett Ethernet-kort till Azure Sphere-enheten enligt beskrivningen i Ansluta Ethernet-kort.
Två Ethernet-enheter stöds av operativsystemet Azure Sphere.
- Microchip ENC28J60. Det här är en 10Base-T-adapter (10 mbps). Den kan vara kabelansluten med en LED-indikator i halvsidig hastighet eller utan en LED-indikator i full dubbelsidig hastighet. Seeed devkits are wired for half-duplex operation.
- Wiznet W5500. Det här är en adapter på 100Base-TX (100 mpbs). Den har stöd för ett integrerat TCP/IP-stack- och NIC-direktläge, men Azure Sphere stöder bara NIC-direktanslutning när W5500 används för internetanslutning. På grund av bussbandbreddsbegränsningar är det inte säkert att MT3620-enheten kan uppnå en full hastighet på 100 mbps.
Ethernet-gränssnittet aktiveras automatiskt när anslagstavlans konfiguration har lästs in enligt beskrivningen i Ladda enhetsprogramvara och enheten startas om. I alla gränssnitt används dynamiska IP-adresser som standard.
Slutföra Azure Sphere-enheten
Slutförande säkerställer att Azure Sphere-enheten är i ett säkert tillstånd och är redo att levereras till kunder. Du måste slutföra enheten innan du skickar den. Slutförande omfattar:
Kör färdiga kontroller för att säkerställa att rätt systemprogramvara och produktionsprogram installeras och RF-verktyg inaktiveras.
Ange enhetstillverkningstillstånd för att låsa RF-konfigurations- och kalibreringsverktygen och förhindra säkerhetsbrister.
Kör kontroller som är klara att levereras
Det är viktigt att köra kontroller som är klara att levereras innan du skickar en produkt som innehåller en Azure Sphere-enhet. Olika kontroller måste utföras för olika tillverkningstillstånd. Kontroller som är klara att levereras säkerställer följande:
- Enhetstillverkningstillståndet är korrekt inställt för det tillverkningssteget.
- Azure Sphere-operativsystemet på enheten är giltigt och den förväntade versionen. Det här kan bara kontrolleras för enheter som ännu inte är i läget DeviceComplete.
- Användarlevererade bilder på enheten matchar listan med förväntade bilder. Det här kan bara kontrolleras för enheter som ännu inte är i läget DeviceComplete.
- Inga oväntade Wi-Fi nätverk konfigureras på enheten. Det här kan bara kontrolleras för enheter som ännu inte är i läget DeviceComplete.
- Enheten innehåller inga särskilda funktionscertifikat. För MT3620-baserade enheter kan detta bara kontrolleras på enheter som inte är i tomt tillstånd.
Olika kontroller är nödvändiga vid olika tillverkningsstadier eftersom enhetens tillverkningsstatus bestämmer enhetens kapacitet .
Vilka kontroller du kör beror också på om du utformar en modul eller en ansluten enhet. Som modultillverkare kan du till exempel välja att lämna chipet i läget Tom tillverkning så att kunden för modulen kan utföra ytterligare radiotestning och konfiguration.
Använd device_ready.py för att utföra kontroller
Paketet för tillverkningsprover innehåller ett verktyg som kallas device_ready.py, som utför kontrollerna ovan, beroende på vad som är lämpligt för varje tillverkningstillstånd. Den ska köras för alla tillverkningstillstånd som är relevanta för din enhet.
I följande tabell visas de parametrar som skriptet device_ready.py tar:
| Parametern | Beskrivning |
|---|---|
--expected_mfg_state |
Avgör vilket tillverkningstillstånd som ska kontrolleras och vilka tester som körs. Om den här parametern inte anges används "DeviceComplete" som standard. Om enhetens tillverkningsstatus skiljer sig från det här värdet misslyckas kontrollen. |
--images |
Anger den lista över avbildnings-ID:er (GUID) som måste finnas på enheten för att kontrollen ska lyckas. Listan består av bildens GUID avgränsade med blanksteg. Den här parametern används som standard i den tomma listan om den inte anges. Om listan över installerade avbildnings-ID:ar på enheten skiljer sig från den här listan misslyckas kontrollen. Genom att kontrollera avbildnings-ID:t (i stället för komponent-ID:na) säkerställer den här kontrollen att en viss version av en komponent finns. |
--os |
Anger en lista över versioner av Azure Sphere-operativsystemet. Den här parametern används som standard i den tomma listan om den inte anges. Om os-versionen som finns på enheten inte finns med i den här listan misslyckas den här kontrollen. |
--os_components_json_file |
Anger sökvägen till JSON-filen som innehåller de OS-komponenter som definierar varje version av operativsystemet. För MT3620-baserade enheter heter den här filen mt3620an.json. Använd verktyget download_os_list.py för att ladda ned den senaste versionen. |
--azsphere_path |
Anger sökvägen till verktyget azsphere.exe. Om den inte anges används standardinstallationsplatsen för Azure Sphere SDK i Windows. Använd endast den här parametern om Azure Sphere SDK inte är installerat på standardplatsen. |
--help |
Visar kommandoradshjälp. |
--verbose |
Ger ytterligare information om utdata. |
Följande exempel är en exempelkörning av device_ready.py verktyget med följande argument:
--os 22.07--os_components_json_file mt3620an.json--expected_mfg_state Module1Complete
device_ready.py --os 22.07 --os_components_json_file mt3620an.json --expected_mfg_state Module1Complete
Checking device is in manufacturing state Module1Complete...
PASS: Device manufacturing state is Module1Complete
Checking capabilities...
PASS: No capabilities on device
Checking OS version...
PASS: OS '22.07' is an expected version
Checking installed images...
PASS: Installed images matches expected images
Checking wifi networks...
PASS: Device has no wifi networks configured
------------------
PASS
Ange enhetstillverkningstillstånd
Känsliga tillverkningsåtgärder som att placera radio i testläge och ställa in Wi-Fi konfiguration av e-säkringar ska inte vara tillgängliga för slutanvändare av enheter som innehåller ett Azure Sphere-chip. Tillverkningstillståndet för Azure Sphere-enheten begränsar åtkomsten till dessa känsliga åtgärder.
De tre tillverkningstillstånden är följande:
Tom. Blank-tillståndet begränsar inte tillverkningsverksamheten på ett chip. Chips i tomt tillstånd kan gå i RF-testläge och deras e-säkringar kan programmeras. När chips skickas från siliconfabriken är de i läget Tom tillverkning.
Module1Complete. Tillverkningstillståndet Module1Complete är utformat för att begränsa de justeringar som användare kan göra i inställningar för radiokonfiguration, till exempel maximal överföringseffekt och tillåtna frekvenser. RF-kommandon kan användas tills Module1Complete har angetts. Du kan behöva begränsa slutanvändaråtkomsten till de här inställningarna för att uppfylla gällande regler kring radiomaskinvara. Den här inställningen påverkar främst tillverkare som behöver testa och kalibrera radiooperativparametrar.
Microsoft rekommenderar att du anger detta tillverkningstillstånd efter att radiotestning och kalibrering har slutförts. RF-kommandon kan inte användas när den har angetts. Module1Complete-läget skyddar enheten mot ändringar som kan störa korrekt drift av radio och andra trådlösa enheter i närheten.
DeviceComplete. Med tillverkningstillståndet DeviceComplete kan tillverkare av färdiga produkter skydda enheter som distribueras i fältet mot ändringar. När en enhet placeras i läget DeviceComplete måste en enhetsspecifik funktionsfil användas när det går att läsa in och konfigurera programvara. Med funktionen fieldservicing kan du läsa in produktionssignerade avbildningar separat, men inte ta bort dem. Apputvecklingsfunktionen tillåter både separat inläsning och borttagning av avbildningar.
Ange inte DeviceComplete för oavslutade enheter eller moduler (Wi-Fi-moduler, utvecklingstavlor och så vidare) som kan användas som en del av ett större system. detta tillstånd begränsar tillverkningsaktiviteter som testning av produktionslinje, programvaruinstallation och konfiguration. Många CLI-kommandon är inte tillgängliga när DeviceComplete har angetts och därför måste vissa kontroller som är klara att levereras köras innan det här tillståndet anges. Begränsade kommandon kan återaktiveras med en enhetsfunktion , till exempel fältenhetsfunktionen , men endast för enheter som du har hävdat, och därför är detta inte lämpligt för användning i en fabriksmiljö eftersom molnanslutning krävs.
I följande tabell sammanfattas de enhetsfunktioner som finns för varje tillverkningstillstånd.
| Tillverkningstillstånd | Enhetsfunktioner |
|---|---|
| Tom | enableRfTestMode, fieldServicing och de som antingen läses in separat eller skickas med en åtgärd, enligt beskrivningen i Enhetsfunktioner. |
| Module1Complete | fieldServicing och de som antingen läses in separat eller skickas med en åtgärd, enligt beskrivningen i Enhetsfunktioner. |
| DeviceComplete | Endast de som antingen läses in separat eller överförs med en åtgärd enligt beskrivningen i Enhetsfunktioner. |
När tillverkningen är klar använder du uppdateringskommandot az sphere device manufacturing-state för att ange tillståndet DeviceComplete :
az sphere device manufacturing-state update --state <desired-state> [--device <IP-address or connection-path>]
Observera
Om flera enheter är anslutna till datorn tar du med parametern --device för att identifiera målenheten via IP-adress eller anslutningssökväg. Mer information finns i Ansluta varje Azure Sphere-chip till en dator på fabriksgolvet .
Viktigt
Att flytta ett chip till devicecomplete-tillståndet är en permanent åtgärd och kan inte ångras. När ett chip är i devicecomplete-tillstånd kan det inte gå in i RF-testläge. inställningarna för e-säkring kan inte justeras. och Wi-Fi inställningar, operativsystemuppdateringar och installerade program kan inte ändras utan att göra anspråk på enheten och använda en enhetsfunktion. Om du behöver återaktivera funktioner på en enskild krets som enhetens funktioner inte återaktiverar, till exempel i ett scenario med felanalys, kontaktar du Microsoft.