Översikt över Azure Sphere-program
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).
Azure Sphere-enheter kan köra två typer av program:
- Högnivåprogram körs i container i Azure Sphere OS
- Realtidskompatibla program (RTApps) körs utan operativsystem eller med ett realtidsoperativsystem (RTOS) på realtidskärnorna
Ett högnivåprogram krävs för varje Azure Sphere-enhet. RTApps är valfria.
Program på hög nivå
Varje Azure Sphere-enhet har ett högnivåprogram som körs på Azure Sphere OS och kan använda programbiblioteken. Ett högnivåprogram kan göra följande:
Konfigurera och interagera med kringutrustning för Azure Sphere som GPIO-stift (general purpose input/output), UART-enheter (universal asynchronous receiver/transmitter) och andra gränssnitt
Kommunicera med RTApps
Kommunicera med internet och molnbaserade tjänster
Förhandla relationer med andra enheter och tjänster via certifikatbaserad autentisering
Ett högnivåprogram körs i en container i användarläget Normal World enligt beskrivningen i Vad är Azure Sphere?. Programcontainern stöder en delmängd av POSIX-miljön och en uppsättning programbibliotek (Applibs) som är specifika för Azure Sphere-operativsystemet. De bibliotek och funktioner som är tillgängliga för program på hög nivå är begränsade för att säkerställa att plattformen förblir säker och enkelt kan uppdateras. Program kan bara komma åt de bibliotek och körningstjänster som Microsoft tillhandahåller. Varken direkt fil-I/O- eller gränssnittsåtkomst är tillgängliga, bland andra begränsningar. Utvecklingsmiljön beskriver den grundläggande API-uppsättningen och introducerar De Azure Sphere-programbibliotek som stöder enhetsspecifika funktioner.
Program på hög nivå förväntas köras kontinuerligt och startas om automatiskt om de stoppas eller misslyckas.
Skapa ett högnivåprogram innehåller mer information om funktioner.
Realtidskompatibla program
En Azure Sphere-enhet kan också ha ett eller flera realtidskompatibla program utöver sitt högnivåprogram. En RTApp kan:
- Konfigurera och interagera med kringutrustning som är integrerad i Azure Sphere MCU, till exempel GPIO-stift och UART
- Kommunicera med program på hög nivå
RTApps kan köras antingen utan operativsystem eller med ett realtidsoperativsystem (RTOS). Lagringsplatsen Azure Sphere-exempel på GitHub innehåller ett HelloWorld-exempel utan operativsystem samt ett exempel som visar kommunikation mellan kärnor mellan högnivå- och RTApps-enheter. Lagringsplatsen Azure Samples på GitHub innehåller ett exempel som visar hur du använder Azure Sphere med Azure RTOS.
Ytterligare drivrutiner och exempel för RTApps som riktar in sig på M4-realtidskärnorna på MT3620-chipet finns tillgängliga på GitHub från Azure Sphere-partnerna MediaTek och Codethink.
Varje RTApp körs isolerad på en viss I/O-kärna och kan endast kommunicera med ett högnivåprogram. Den kan inte använda Internet, Azure Sphere-applibs eller andra funktioner i Azure Sphere-operativsystemet.
Skapa ett realtidskompatibelt program innehåller mer information om funktionerna och utvecklingsprocessen för RTApps.
Funktioner som är gemensamma för alla program
Trots de stora skillnaderna mellan appar på hög nivå och RTApps har alla Azure Sphere-program vissa saker gemensamt. Du kan utveckla, skapa och felsöka båda typerna av program med hjälp av Visual Studio eller Visual Studio Code, eller genom att anropa CMake och Ninja med hjälp av CLI.
Dessutom gäller följande säkerhetsfunktioner för både högnivå- och RTApps:
Programfunktioner
Oavsett var det körs måste varje Azure Sphere-program ange de externa tjänster och gränssnitt som krävs, till exempel dess I/O- och nätverkskrav, för att förhindra obehörig eller oväntad användning.
Programfunktioner är de resurser som ett program kräver. Programfunktionerna omfattar kringutrustning som programmet använder, de Internetvärdar som ett högnivåprogram ansluter till och behörighet att ändra nätverkskonfigurationen, bland annat. Varje program måste ha ett programmanifest som identifierar dessa resurser.
Enhetsfunktioner
En enhetsfunktion möjliggör en enhetsspecifik aktivitet. Enhetsfunktioner beviljas av Azure Sphere Security Service. Som standard har Azure Sphere-chips inga enhetsfunktioner. Det finns två huvudsakliga typer av enhetsfunktioner: funktionen appUtvecklingsenhet och funktionen fieldServicing-enhet .
Funktionen appUtvecklingsenhet ändrar den typ av signering som enheten litar på. Som standard litar Azure Sphere-enheter på produktionssignerade avbildningspaket men litar inte på SDK-signerade avbildningspaket. Därför kan du inte separat läsa in ett SDK-signerat avbildningspaket till en Azure Sphere-enhet som inte har den här funktionen. När funktionen appDevelopment finns litar enheten dock på SDK-signerade avbildningspaket. Dessutom kan du starta, stoppa, felsöka eller ta bort ett program från enheten. Sammanfattningsvis måste programutvecklingsfunktionen finnas på enheten innan du kan:
- Läs in ett avbildningspaket som har skapats av Visual Studio eller kommandot azsphere image-package.
- Starta, stoppa, felsöka eller ta bort ett avbildningspaket från Azure Sphere-enheten, oavsett hur avbildningspaketet signeras.
Kommandot azsphere device enable-development skapar och tillämpar funktionen appUtveckling och förhindrar att enheten tar emot uppdateringar av molnprogram.
Funktionen fieldServicing tillåter kommunikation från enhet till dator på enheter som är i tillverkningstillståndet DeviceComplete. Med den här funktionen kan du separat läsa in produktionssignerade avbildningar, men inte ta bort dem. Du kan starta och stoppa program, men inte felsöka dem. Du kan också utföra rutinunderhållsuppgifter som att konfigurera Wi-Fi. Den är avsedd för kortsiktig användning under en servicesession, en begränsad period under vilken åtkomst till enheten beviljas per drift.
Krav för signering och distribution
Alla avbildningspaket som distribueras till en Azure Sphere-enhet måste signeras. Azure Sphere SDK och kommandot azsphere image-package signerar avbildningspaket för testning med hjälp av en SDK-signeringsnyckel. Azure Sphere-enheter litar endast på den här nyckeln om funktionen appUtvecklingsenhet också finns.
Azure Sphere Security Service-produktionssigneringspaketen signerar avbildningspaket när du laddar upp dem till molnet. Produktionssignerade avbildningspaket kan läsas in separat eller läsas in från molnet.
För att förhindra installation av oseriösa program kan program bara läsas in på en Azure Sphere-enhet på två sätt:
Separat inläsning, som kan användas både för programutveckling och testning och för fältservice av enheter. För separat inläsning för utveckling och testning av programvara krävs funktionen appUtvecklingsenhet. För separat inläsning för fältservice krävs att det finns kapacitet för fieldServicing-enheter och produktionssignerade avbildningspaket. Både Visual Studio och Visual Studio Code läser in program separat under utveckling och felsökning. du kan också läsa in manuellt med hjälp av Azure Sphere CLI.
Molnuppdatering, som endast kan utföras av Azure Sphere Security Service. Använd Azure Sphere CLI för att skapa och hantera molndistributioner.
Partnerprogram
Program som fungerar tillsammans kan betraktas som partnerprogram och kan sedan läsas in separat. När du läser in ett program som har en partner förblir partnerprogrammet kvar på Azure Sphere-enheten om det redan har distribuerats. Varje program deklarerar en lista över sina partner i sin projektkonfiguration.
Om du vill lägga till partner i CMake-projektkonfigurationen anger du komponent-ID för partnerappen i fältet partnerComponents i konfigurationsavsnittet i launch.vs.json eller .vscode/launch.json-filen:
"partnerComponents": [ "25025d2c-66da-4448-bae1-ac26fcdd3627" ]
Appar på hög nivå och RTApps som kommunicerar med varandra måste identifieras som partner. Azure Sphere stöder inte kommunikation mellan par med högnivåappar eller RTApp-par.