Panoramica delle applicazioni Azure Sphere
Importante
Questa è la documentazione di Azure Sphere (legacy). Azure Sphere (legacy) viene ritirato il 27 settembre 2027 e gli utenti devono eseguire la migrazione ad Azure Sphere (integrato) entro questo periodo. Usare il selettore di versione posizionato sopra il sommario per visualizzare la documentazione di Azure Sphere (integrata).
I dispositivi Azure Sphere è possono eseguire due tipi di applicazioni:
- Le applicazioni di alto livello vengono eseguite in contenitori nel sistema operativo Azure Sphere
- Le applicazioni con funzionalità in tempo reale (RTApp) vengono eseguite in un computer bare metal o con un sistema operativo in tempo reale (RTO) sui core per operazioni in tempo reale
Un'applicazione di alto livello è necessaria per ogni dispositivo Azure Sphere, mentre le RTApp sono facoltative.
Applicazioni di alto livello
Ogni dispositivo Azure Sphere ha un'applicazione di alto livello, che viene eseguita nel sistema operativo Azure Sphere e può usare le librerie dell'applicazione. Un'applicazione di alto livello può:
Configurare le periferiche Azure Sphere e interagire con esse, ad esempio pin GPIO (General-Purpose Input/Output), UART (Universal Asynchronous Receiver/Transmitters) e altre interfacce
Comunicare con applicazioni con operazioni in tempo reale (RTApp)
Comunicare con servizi basati su cloud e Internet
Negoziare relazioni di trust con altri dispositivi e servizi tramite l'autenticazione basata su certificati
Un'applicazione di alto livello viene eseguita in un contenitore in modalità utente Normal World, come descritto in Informazioni su Azure Sphere. Il contenitore dell'applicazione supporta un subset dell'ambiente POSIX e un set di librerie di applicazioni (applib) specifiche per il sistema operativo Azure Sphere. Le librerie e le funzioni disponibili per le applicazioni di alto livello sono limitate per garantire che la piattaforma rimanga protetta e facilmente aggiornabile. Le applicazioni possono accedere solo alle librerie e ai servizi di runtime forniti da Microsoft. Tra gli altri vincoli, non sono disponibili l'I/O diretto dei file, né l'accesso alla shell. L'ambiente di sviluppo descrive il set di API di base e introduce le librerie di applicazioni di Azure Sphere che supportano funzionalità specifiche del dispositivo.
Per le applicazioni di alto livello è prevista l'esecuzione continua: in caso di arresto o di errore, vengono riavviate automaticamente.
Creare un'applicazione di alto livello fornisce altre informazioni sulle funzionalità.
Applicazioni con funzionalità in tempo reale
Un dispositivo Azure Sphere può anche avere una o più applicazioni con funzionalità in tempo reale, oltre alla relativa applicazione di alto livello. Un'applicazione RTApp può:
- Configurare e interagire con le periferiche integrate nel microcontroller di Azure Sphere, ad esempio i pin GPIO e i dispositivi UART
- Comunicare con le applicazioni di alto livello
Le applicazioni RTApp possono essere eseguite su un computer bare metal o con un sistema operativo in tempo reale (RTOS). Il repository di esempi di Azure Sphere in GitHub include un esempio HelloWorld bare metal, oltre a un esempio che illustra la comunicazione tra core tra le app di alto livello e le app RTApp. Il repository di esempi di Azure in GitHub contiene un esempio che illustra come usare Azure Sphere con Azure RTOS.
Altri driver ed esempi per le app RTAapp destinate a core in tempo reale M4 nel chip MT3620 sono resi disponibili in GitHub dai partner di Azure Sphere MediaTek e Codethink.
Ogni applicazione RTApp viene eseguita in modo isolato su uno specifico core di I/O e può comunicare solo con un'applicazione di alto livello. Non può usare Internet, le librerie di applicazioni di Azure Sphere o altre funzionalità del sistema operativo Azure Sphere.
Creare un'applicazione con funzionalità in tempo reale fornisce altre informazioni sulle funzionalità e sul processo di sviluppo per le app RTApp.
Funzionalità comuni a tutte le applicazioni
Nonostante le differenze significative tra app di alto livello e RTApp, tutte le applicazioni Azure Sphere hanno alcuni elementi in comune. È possibile sviluppare, compilare ed eseguire il debug di entrambi i tipi di applicazioni usando Visual Studio o Visual Studio Code oppure richiamando CMake e Ninja tramite l'interfaccia della riga di comando.
Inoltre, le funzionalità di sicurezza seguenti si applicano sia alle applicazioni di alto livello che alle applicazioni RTApp:
Funzionalità dell'applicazione
Indipendentemente dalla posizione in cui viene eseguita, ogni applicazione di Azure Sphere deve specificare i servizi e le interfacce esterne richieste, ad esempio i requisiti di I/O e di rete, al fine di prevenire eventuali usi non autorizzati o non previsti.
Le funzionalità dell'applicazione sono le risorse richieste da un'applicazione. Tali funzionalità includono le periferiche usate dall'applicazione, l'host internet a cui si connette un'applicazione di alto livello e l'autorizzazione per la modifica della configurazione di rete. Ogni applicazione deve avere un manifesto dell'applicazione che identifica queste risorse.
Funzionalità del dispositivo
Una funzionalità del dispositivo consente di eseguire un'attività specifica del dispositivo. Le funzionalità del dispositivo vengono concesse dal servizio di sicurezza di Azure Sphere. Per impostazione predefinita, i chip di Azure Sphere non dispongono di nessuna funzionalità del dispositivo. Esistono due tipi principali di funzionalità del dispositivo: la funzionalità del dispositivo appDevelopment e la funzionalità del dispositivo fieldServicing .
La funzionalità del dispositivo appDevelopment cambia il tipo di firma considerata attendibile dal dispositivo. Per impostazione predefinita, i dispositivi Azure Sphere considerano attendibili i pacchetti immagine firmati dal produttore, ma non quelli firmati tramite SDK. Di conseguenza, non è possibile trasferire localmente un pacchetto immagine firmato tramite SDK in un dispositivo Azure Sphere sprovvisto di questa funzionalità. Quando la funzionalità appDevelopment è presente, tuttavia, il dispositivo considera attendibili i pacchetti immagine firmati tramite SDK. Inoltre, la funzionalità consente di avviare, arrestare, eseguire il debug o rimuovere un'applicazione dal dispositivo. In pratica, la funzionalità di sviluppo dell'applicazione deve essere presente nel dispositivo prima di poter:
- Trasferire localmente un pacchetto immagine creato con Visual Studio o con il comando azsphere image-package.
- Avviare, arrestare, eseguire il debug o rimuovere un pacchetto immagine dal dispositivo Azure Sphere, indipendentemente dal tipo di firma del pacchetto immagine.
Il comando azsphere device enable-development crea e applica la funzionalità appDevelopment e impedisce al dispositivo di ricevere aggiornamenti dell'applicazione cloud.
La funzionalità fieldServicing consente comunicazioni da dispositivo a computer nei dispositivi che si trovano nello stato di produzione DeviceComplete. Con questa funzionalità, è possibile trasferire localmente immagini firmate dall'ambiente di produzione, ma non eliminarle. È possibile avviare e arrestare le applicazioni, ma non eseguirne il debug. È anche possibile eseguire attività di manutenzione di routine, ad esempio la configurazione del Wi-Fi. È destinato all'uso a breve termine durante una sessione di manutenzione, un periodo limitato durante il quale l'accesso al dispositivo viene concesso per ogni operazione.
Requisiti per la firma e la distribuzione
Tutti i pacchetti immagine distribuiti in un dispositivo Azure Sphere devono essere firmati. Azure Sphere SDK e il comando azsphere image-package firmano i pacchetti immagine per i test usando la chiave di firma di un SDK. I dispositivi Azure Sphere considerano attendibile questa chiave solo se è presente anche la funzionalità del dispositivo appDevelopment.
Il servizio di sicurezza di Azure Sphere applica la firma di produzione ai pacchetti immagine quando vengono caricati nel cloud. I pacchetti immagine con la firma di produzione possono essere trasferiti localmente o caricati dal cloud.
Per impedire l'installazione di software non autorizzati, le applicazioni possono essere caricate in un dispositivo Azure Sphere solo in due modi:
Trasferimento locale, che può essere usato sia per lo sviluppo software che per il test e per la manutenzione sul campo dei dispositivi. Il trasferimento locale per lo sviluppo e il test del software richiede la funzionalità del dispositivo appDevelopment. Il trasferimento locale per la manutenzione dei campi richiede la funzionalità del dispositivo fieldServicing e i pacchetti di immagini firmati per la produzione. Sia Visual Studio che Visual Studio Code trasferiscono localmente le applicazioni durante lo sviluppo e il debug; è anche possibile trasferire localmente manualmente usando l'interfaccia della riga di comando di Azure Sphere.
Tramite aggiornamento cloud, che può essere eseguito solo dal servizio di sicurezza di Azure Sphere. Usare l'interfaccia della riga di comando di Azure Sphere per creare e gestire distribuzioni cloud.
Applicazioni partner
Le applicazioni che interagiscono tra loro possono essere considerate applicazioni partner e quindi possono essere trasferite localmente separatamente. Quando si esegue il trasferimento locale di un'applicazione che dispone di un partner, l'applicazione partner rimane nel dispositivo Azure Sphere se è già stata distribuita. Ogni applicazione dichiara un elenco dei partner nella relativa configurazione del progetto.
Le applicazioni che usano la configurazione del progetto CMake specificano l'ID componente dell'app partner nel campo partnerComponents della sezione configurations del file .vscode/launch.json:
"partnerComponents": [ "25025d2c-66da-4448-bae1-ac26fcdd3627" ]
Le app di alto livello e le app RTApp che comunicano tra loro devono essere identificate come partner. Azure Sphere non supporta la comunicazione tra coppie di app o coppie di app di alto livello di RTApps.