Attività della linea di produzione

La produzione di dispositivi connessi che incorporano Azure Sphere hardware prevede le seguenti attività di produzione per preparare i dispositivi per la spedizione:

• Connessione di ogni chip Azure Sphere a un PC di produzione
• Ottenere i dettagli del dispositivo e registrarli per usarli in un secondo momento
• Aggiornamento del sistema operativo Azure Sphere, se necessario
• Aggiorna il keystore attendibile, se necessario
• Caricamento del software nel dispositivo
• Esecuzione di test funzionali per verificare l'operazione corretta del prodotto
• Esecuzione di test e calibrazione della radiofrequenza (RF)
• Verifica della comunicazione Wi-Fi
• Configurazione del dispositivo per Ethernet
• Finalizzazione del dispositivo Azure Sphere per la spedizione

È necessario connettere il chip al PC per primo, ottenere i dettagli del dispositivo secondo e finalizzare l'ultimo dispositivo, ma è possibile eseguire le altre attività in qualsiasi ordine adatto all'ambiente di produzione.

Connettere ogni chip Azure Sphere a un PC di produzione

Durante la produzione, è necessario connettere ogni chip Azure Sphere a un PC di produzione.During manufacturing, you must connect each Azure Sphere chip to a factory-floor PC. Se si desidera connettere simultaneamente più dispositivi Azure Sphere a un singolo PC, vedere Attrezzatura per le attività in reparto produzione nelle attività di preparazione per la produzione.

La maggior parte delle attività di fabbrica implica il comando az sphere device . Quando si dispone di più dispositivi collegati al PC, è necessario specificare il dispositivo in cui applicare il comando az sphere device includendo il --device parametro impostato sull'indirizzo IP del dispositivo o sul percorso di connessione del dispositivo. Il comando avrà esito negativo se il --device parametro viene omesso e vengono collegati più dispositivi. Per ottenere l'indirizzo IP o il percorso di connessione, vedere Ottenere i dettagli del dispositivo.

Ottenere i dettagli del dispositivo

Devi registrare l'ID dispositivo di ogni chip Azure Sphere che la tua azienda incorpora nei prodotti prodotti. Sarà necessario l'ID dispositivo per le attività di configurazione cloud.

Se si dispone di più dispositivi collegati al PC di produzione, è necessario registrare anche l'indirizzo IP o il percorso di connessione dei dispositivi collegati per usarli successivamente nelle attività di produzione. Come illustrato in Connettere ogni chip Azure Sphere, è necessario specificare l'indirizzo IP o il percorso di connessione quando sono presenti più dispositivi collegati.

Per ottenere l'ID dispositivo, l'indirizzo IP e il percorso di connessione dei dispositivi collegati, usare il comando az sphere device list-attached . Le descrizioni seguenti forniscono informazioni essenziali sull'ID dispositivo, l'indirizzo IP e il percorso di connessione.

• ID dispositivo: il produttore del processore crea l'ID dispositivo, lo archivia nel chip e lo registra con Microsoft. Questa registrazione del dispositivo garantisce che Microsoft sia a conoscenza di tutti i chip Azure Sphere e che solo i chip legittimi possano essere usati nei dispositivi connessi.

• Indirizzo IP : l'indirizzo IP viene assegnato quando un'interfaccia del dispositivo basata su FTDI è collegata al PC; non indica che è presente un dispositivo reattivo. L'indirizzo IP persiste mentre l'interfaccia del dispositivo basata su FTDI è collegata al PC, anche se un altro dispositivo Azure Sphere è collegato all'interfaccia. Dopo un riavvio del PC, tuttavia, l'indirizzo IP può cambiare. Alla prima interfaccia del dispositivo basata su FTDI da collegare viene assegnato l'indirizzo 192.168.35.2. A ogni dispositivo viene assegnato un indirizzo IP, anche se non risponde, in modo da poter usare l'indirizzo IP per identificare un dispositivo che richiede il ripristino.

• Percorso di connessione: il percorso di connessione è un ID percorso FTDI che identifica la connessione USB. L'ID posizione rimane invariato finché l'interfaccia del dispositivo basata su FTDI è collegata alla stessa porta USB sullo stesso hub USB, e quest'ultimo è a sua volta collegato alla stessa porta del PC. Pertanto, persiste anche dopo il riavvio. Tuttavia, eventuali modifiche al collegamento tra il PC e il dispositivo possono comportare modifiche al percorso di connessione. Come l'indirizzo IP, non cambia anche se un altro dispositivo Azure Sphere è collegato all'interfaccia FTDI.

Aggiornare il sistema operativo Azure Sphere

Ogni chip Azure Sphere viene caricato con il sistema operativo Azure Sphere quando viene spedito dal produttore del processore. A seconda della versione del sistema operativo Azure Sphere sui chip disponibili dal fornitore e, a seconda dei requisiti di versione del sistema operativo dell'applicazione, potrebbe essere necessario aggiornare il sistema operativo Azure Sphere durante la produzione del dispositivo connesso. È possibile aggiornare il sistema operativo installando immagini di ripristino specifiche, che dovrebbero essere già presenti nel PC. Vedere Preparare un aggiornamento del sistema operativo nelle attività di preparazione della produzione. Gli esempi di Manufacturing includono uno script di esempio che esegue il ripristino parallelo di più dispositivi.

È possibile aggiornare il sistema operativo nel dispositivo Azure Sphere eseguendo il comando az sphere device recover. Usare il --images parametro per installare immagini di ripristino specifiche:

az sphere device recover --images <path-to-images> [--device <IP-address or connection-path>]

Aggiorna il keystore attendibile

Come prerequisito per il caricamento del software nel dispositivo, potrebbe essere necessario aggiornare l'archivio chiavi attendibile nel dispositivo. Questa operazione è necessaria solo se il sistema operativo nel dispositivo è precedente al software e solo se la chiave di firma dell'immagine Azure Sphere usata da AS3 è stata aggiornata tra il sistema operativo pubblicato e il software firmato in produzione. Per evitare questo passaggio e ridurre il tempo di produzione, è consigliabile aggiornare la versione del sistema operativo in uso durante la produzione.

È possibile determinare facilmente se l'aggiornamento dell'archivio chiavi attendibile è necessario tentando di caricare il software in base alle istruzioni riportate nella sezione successiva. Se il caricamento riesce, non è necessario aggiornare il keystore attendibile. Se il caricamento non riesce con il messaggio che inizia con Internal device error: Image not trusted by device , un archivio chiavi attendibile non aggiornato è la causa.

Per aggiornare il keystore attendibile, è necessario aver ottenuto il file del keystore attendibile aggiornato. Quindi, nell'ambito degli script di produzione, usa il comando az sphere device sideload deploy per caricare il keystore attendibile aggiornato prima di caricare il software applicativo, sostituendo <path-to-trusted-keystore.bin> con il percorso del file del keystore attendibile:

az sphere device sideload deploy --image-package <path-to-trusted-keystore.bin> [--device <IP-address or connection-path>]

Caricare il software del dispositivo

Tutto il software caricato, indipendentemente dal fatto che si tratti di un'immagine di configurazione della scheda, di un'applicazione di test o di un'applicazione di produzione, deve essere firmato dall'ambiente di produzione. Se si carica un'applicazione temporanea per il test, è necessario eliminarla al termine del test.

Tutte le immagini firmate per la produzione necessarie durante il processo in fabbrica devono essere salvate sul PC del piano di fabbrica prima di avviare il processo, come descritto in Ottenere immagini firmate per la produzione nelle attività di preparazione per la produzione.

Durante la produzione, i dispositivi Azure Sphere non devono richiedere funzionalità speciali device, ad esempio la funzionalità appdevelopment, che abilita il debug. L'acquisizione di funzionalità per i singoli dispositivi riduce la sicurezza dei dispositivi e richiede la connettività Internet, che in genere è indesiderata sul piano della fabbrica.

Per caricare il software in un dispositivo nella factory o per eliminare il software temporaneo da un dispositivo al termine del test, usare il comando az sphere device sideload come indicato di seguito:

• Usare az sphere device sideload deploy per caricare un'immagine, sostituendo <file-path> con il nome e il percorso del file immagine firmato per la produzione:

  az sphere device sideload deploy --image-package <file-path> [--device <IP-address or connection-path>]
  

• Usare az sphere device sideload delete per eliminare un'immagine temporanea, sostituendo <component-id> con l'ID componente dell'immagine da eliminare:

  az sphere device sideload delete --component-id <component-id> [--device <IP-address or connection-path>]
  

Eseguire test funzionali

I test funzionali sono necessari per verificare che il prodotto funzioni correttamente. Eseguire le applicazioni sviluppate per i test funzionali come parte delle attività di preparazione della produzione. Vedere Sviluppare applicazioni per i test funzionali.

Se i test funzionali richiedono la comunicazione con il chip che viene testato, connettere gli UART periferici MT3620 (ISU0, ISU1, ISU2 o ISU3) al PC di produzione o alle apparecchiature di test esterne tramite circuiti adatti del proprio progetto.

Eseguire test e calibrazione della radiofrequenza (RF)

Azure Sphere chip possono usare Wi-Fi per ricevere gli aggiornamenti software e comunicare con Internet. Se il prodotto usa Wi-Fi e incorpora una progettazione chip-down o un modulo non certificato RF, è necessario eseguire test RF e calibrazione per ogni dispositivo. Le attrezzature e gli strumenti necessari per questa attività sono descritti in Apparecchiature e software per i test RF e la calibrazione nelle attività di preparazione della produzione.

Il pacchetto RF Tools include utilità e una libreria api C da usare durante i test. È possibile usare la libreria API C per programmare impostazioni RF specifiche del prodotto in e-fuse. Ad esempio, i fusibili e-fuse sono programmati per configurare l'antenna e la frequenza, ottimizzare i dispositivi per prestazioni ottimali e abilitare i canali Wi-Fi. L'argomento Strumenti di test RF descrive come usare gli strumenti RF.

Programma e-fuse per abilitare i canali Wi-Fi

Azure Sphere OS seleziona i canali Wi‑Fi in base al codice regionale programmato nelle e-fuse del MT3620 agli indirizzi di offset 0x36 e 0x37. Per informazioni dettagliate sulle e-fuse su MT3620, vedere il documento MT3620 E-fuse Content Guidelines Mediatek.

Il codice di area è un codice ASCII a due lettere. Il sistema operativo Azure Sphere usa l'impostazione del codice della regione negli e-fuse per individuare la regione nel database normativo wireless di Linux e quindi seleziona i canali consentiti per tale regione. Se non viene programmato alcun codice di area nelle e-fuse, nel qual caso le e-fuse rimangono impostate su 0x00 0x00 o se i caratteri "00" sono programmati, il sistema operativo usa per impostazione predefinita un set conservativo di canali generalmente consentiti in tutte le aree. I canali consentiti per l'area "00" vengono specificati nel database normativo wireless Linux.

L'impostazione del codice dell'area nelle e-fuse non deve corrispondere al paese in cui verrà usato il dispositivo. I produttori possono scegliere qualsiasi codice di area mappato a un set consentito di canali per l'area operativa. Aree geografiche e paesi diversi spesso adottano normative simili o identiche, che possono consentire l'uso intercambiabile dei codici di area.

Esempio: Per istruire il sistema operativo Azure Sphere a selezionare i canali Wi‑Fi per la regione "DE" (Germania), programmare 0x44=D e 0x45=E negli e-fuse agli indirizzi 0x36 e 0x37. I canali consentiti per la Germania, estratti dal database normativo wireless Linux, sono illustrati di seguito. La maggior parte dei paesi dell'Unione europea (UE) consente lo stesso set di canali.

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)

Verificare la configurazione RF

Utilizzare RfSettingsTool per verificare che le opzioni di configurazione radio, come la potenza di trasmissione target, il codice della regione e l'indirizzo MAC Wi‑Fi, siano state impostate correttamente. La documentazione dello strumento impostazioni RF fornisce altre informazioni sull'uso di questo strumento.

Verificare la comunicazione Wi‑Fi

Valutare la possibilità di connettersi a un punto di accesso Wi-Fi per verificare che l'applicazione del prodotto sia in grado di comunicare tramite Wi-Fi. Assicurarsi che la connessione Wi-Fi non abbia accesso a Internet, perché può verificarsi un aggiornamento over-the-air se il chip si connette a un punto di accesso abilitato per Internet.

Per connettere un dispositivo a un punto di accesso Wi-Fi, seguire le istruzioni nella scheda Avvio rapido (interfaccia della riga di comando). Se più dispositivi sono connessi al PC, è necessario includere il --device parametro nel comando az sphere device wifi show-status e il comando az sphere device wifi add . Per informazioni dettagliate sull'uso del comando az sphere device con più dispositivi collegati, vedere Connettere ogni chip Azure Sphere a un PC dell'area di produzione.

Dopo Wi-Fi test, è necessario rimuovere tutti i punti di accesso Wi-Fi usati per il test dal chip in modo che non siano visibili ai clienti. Il ripristino del dispositivo rimuove tutti i dati di configurazione Wi-Fi dal chip.

Configurare il dispositivo per Ethernet

Un dispositivo Azure Sphere può comunicare tramite Ethernet. Il dispositivo richiede una scheda Ethernet esterna e un'immagine di configurazione della scheda per la comunicazione tramite Ethernet.

Per configurare un dispositivo Azure Sphere per Ethernet, connettere una scheda Ethernet al dispositivo Azure Sphere, come descritto in Connessione di schede Ethernet.

Due dispositivi Ethernet sono supportati dal sistema operativo Azure Sphere.

1. Microchip ENC28J60. Si tratta di una scheda 10Base-T (10 mbps). Può essere collegato con un indicatore LED a velocità half duplex o senza un indicatore LED a velocità full duplex. I devkit Seeed sono cablati per il funzionamento half-duplex.
2. Wiznet W5500. Si tratta di un adattatore da 100Base-TX (100mpbs). Supporta uno stack TCP/IP integrato e modalità pass-through della NIC, ma Azure Sphere supporta il pass-through della NIC solo quando si usa il W5500 per la connettività a Internet. A causa delle limitazioni della larghezza di banda del bus, la velocità massima di 100 mb potrebbe non essere raggiungibile dal dispositivo MT3620.

L'interfaccia Ethernet verrà abilitata automaticamente dopo il caricamento della configurazione della scheda, come descritto in Caricare il software del dispositivo e il dispositivo viene riavviato. Per impostazione predefinita, tutte le interfacce usano indirizzi IP dinamici.

Finalizzare il dispositivo Azure Sphere

La finalizzazione garantisce che il dispositivo Azure Sphere sia protetto ed è pronto per essere spedito ai clienti. È necessario finalizzare il dispositivo prima di spedirlo. La finalizzazione prevede:

• Esecuzione di controlli pronti per la spedizione per assicurarsi che il software di sistema e l'applicazione di produzione corretti siano installati e che gli strumenti RF siano disabilitati.

• Impostazione dello stato di produzione del dispositivo per bloccare la configurazione rf e gli strumenti di calibrazione e prevenire violazioni della sicurezza.

Esegui i controlli di idoneità alla spedizione

È importante eseguire controlli pronti per la spedizione prima di spedire un prodotto che include un dispositivo Azure Sphere. È necessario eseguire controlli diversi per diversi stati di produzione. I controlli pre-spedizione garantiscono quanto segue:

• Lo stato di produzione del dispositivo viene impostato correttamente per tale fase di produzione.
• Il sistema operativo Azure Sphere sul dispositivo è valido e corrisponde alla versione prevista. Questo può essere controllato solo per i dispositivi che non sono ancora nello stato DeviceComplete.
• Le immagini fornite dall'utente nel dispositivo corrispondono all'elenco delle immagini previste. Questo può essere controllato solo per i dispositivi che non sono ancora nello stato DeviceComplete.
• Nel dispositivo non sono configurate reti Wi-Fi impreviste. Questo può essere controllato solo per i dispositivi che non sono ancora nello stato DeviceComplete.
• Il dispositivo non contiene certificati di funzionalità speciali. Per i dispositivi basati su MT3620, questo può essere controllato solo nei dispositivi non nello stato Vuoto.

Sono necessari controlli diversi in diverse fasi di produzione perché lo stato di produzione del dispositivo determina le funzionalità del dispositivo.

I controlli eseguiti dipendono anche dal fatto che si stia progettando un modulo o un dispositivo connesso. Ad esempio, come produttore di moduli, è possibile scegliere di lasciare il chip nello stato di produzione Vuoto in modo che il cliente del modulo possa eseguire test e configurazione radio aggiuntivi.

Usare device_ready.py per eseguire i controlli

Il pacchetto Manufacturing Samples comprende uno strumento denominato device_ready.py, che esegue le verifiche sopra indicate, in modo appropriato per ciascuno stato di produzione. Deve essere eseguita per ognuno degli stati di produzione rilevanti per il dispositivo.

Nella tabella seguente sono elencati i parametri accettati dallo script device_ready.py:

L'esempio seguente mostra un'esecuzione di esempio dello strumento device_ready.py con i seguenti argomenti:

• --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

Impostare lo stato di produzione del dispositivo

Le operazioni di produzione sensibili, ad esempio l’impostazione della radio in modalità di test e la configurazione degli e-fuse Wi‑Fi, non devono essere accessibili agli utenti finali dei dispositivi che contengono un chip Azure Sphere. Lo stato manufacturing del dispositivo Azure Sphere limita l'accesso a queste operazioni sensibili.

I tre stati di produzione sono i seguenti:

• Vuoto. Lo stato Vuoto non limita le operazioni di produzione su un chip. I chip nello stato Vuoto possono entrare in modalità di test RF e i loro fusibili possono essere programmati. Quando i chip vengono spediti dalla fabbrica di siliconi, si trovano nello stato di produzione Vuoto .

• Module1Complete. Lo stato di produzione Module1Complete è progettato per limitare le regolazioni che gli utenti possono apportare alle impostazioni di configurazione radio, ad esempio livelli massimi di potenza di trasmissione e frequenze consentite. I comandi RF possono essere utilizzati finché non viene impostato Module1Complete. Potrebbe essere necessario limitare l'accesso degli utenti finali a queste impostazioni per soddisfare i criteri normativi relativi all'hardware radio. Questa impostazione interessa principalmente i produttori che devono testare e calibrare i parametri operativi radio.

  Microsoft consiglia di impostare questo stato di produzione dopo il completamento di test radio e calibrazione; I comandi RF non possono essere usati dopo l'impostazione. Lo stato Module1Complete protegge il dispositivo dalle modifiche che potrebbero interrompere il corretto funzionamento della radio e di altri dispositivi wireless nelle vicinanze.

• DeviceComplete. Lo stato di produzione DeviceComplete consente ai produttori di prodotti finiti di proteggere i dispositivi distribuiti nel campo rispetto alle modifiche. Quando un dispositivo viene inserito nello stato DeviceComplete , è necessario usare un file di funzionalità specifico del dispositivo ogni volta che si eseguono attività di caricamento e configurazione del software. La funzionalità fieldservicing consente di trasferire localmente immagini firmate dall'ambiente di produzione, ma non di eliminarle. La funzionalità appdevelopment consente sia il trasferimento locale che l'eliminazione di immagini.

  Non impostare DeviceComplete per dispositivi o moduli incompleti (moduli Wi‑Fi, schede di sviluppo e così via) che possono essere utilizzati come parte di un sistema più ampio; questo stato limita le attività di fabbricazione, ad esempio i test sulla linea di produzione, l'installazione del software e la configurazione. Molti comandi dell'interfaccia della riga di comando non sono disponibili dopo l'impostazione di DeviceComplete e pertanto è necessario eseguire alcuni controlli pronti per la spedizione prima che questo stato sia impostato. I comandi con restrizioni possono essere riabilitato usando una funzionalità del dispositivo , ad esempio la funzionalità fieldservicing , ma solo per i dispositivi richiesti e pertanto non è appropriato per l'uso in un ambiente factory-floor perché richiede la connettività cloud.

La tabella seguente riepiloga le funzionalità del dispositivo presenti per ogni stato di produzione.

Al termine della produzione, usare il comando az sphere device manufacturing-state update per impostare lo stato DeviceComplete :

az sphere device manufacturing-state update --state <desired-state> [--device <IP-address or connection-path>]