Dela via

Underordnade OTA-uppdateringar med Azure Sphere

  • Artikel

Många Azure Sphere-lösningar innehåller både en Azure Sphere-certifierad MCU och andra processorer som en del av en komplett IoT-lösning. Dessa andra processorer behöver regelbundna uppdateringar av inbyggd programvara. Den här guiden beskriver hur du aktiverar underordnade OTA-uppdateringar med hjälp av Azure Sphere.

Beroende på det specifika programscenariot finns det ett antal olika sätt att uppnå detta. Varje lösning har ett gemensamt flöde:

  1. Utlös uppdateringen av den inbyggda programvaran.
  2. Hämta uppdateringen av den inbyggda programvaran.
  3. Fastställa en mellanliggande nedladdningsplats.
  4. Verifiera inbyggd programvara och uppdatera nedströmsprocessorn.

Steg 1: Utlös uppdateringen av inbyggd programvara

Problem: Hur initieras uppdateringsprocessen för inbyggd programvara?

Alternativ:

  • Varje Azure Sphere-appversion är kopplad till en nedströmsversion av inbyggd programvara:

    • Beskrivning: När Azure Sphere-appen startar jämförs den version av inbyggd programvara som stöds med den distribuerade versionen på den underordnade processorn. Om versionerna inte matchar krävs en uppdatering.
    • Fördelar: Definierat supportkontrakt mellan Azure Sphere-appen och versionen av den inbyggda programvaran. Dessutom utnyttjar den befintliga Azure Sphere-appuppdateringsprocessen.
    • Nackdelar: Måste uppdatera Azure Sphere-appen för att utlösa en uppdatering av inbyggd programvara även om det inte finns några ändringar i Azure Sphere-appen. Måste också lägga till övervakning av uppdateringsförloppet.

  • Uppdatering av inbyggd programvara för enhetshantering i Azure IoT Hub:

    • Beskrivning: När en uppdatering av den inbyggda programvaran är klar skapar en IoT-lösningsoperator en ny enhetshanteringskonfiguration med den uppdaterade inbyggda programvaran. Azure Sphere-programmet tar emot begäran om uppdatering av inbyggd programvara och kan påbörja uppdateringen.
    • Fördelar: Enkel hanteringslösning för att definiera, utlösa och övervaka en uppdatering.
    • Nackdelar: Måste använda Azure IoT Hub, inga andra molnslutpunkter stöds.

  • Separat kontroll av inbyggd programvara (anpassad lösning):

    • Beskrivning: Skapa en anpassad kontroll av inbyggd programvara i Azure Sphere-programmet. Kontrollera regelbundet en definierad slutpunkt för en ny version och starta en uppdatering om en identifieras.
    • Fördelar: Fungerar med valfri molnslutpunkt för att ladda ned inbyggd programvara.
    • Nackdelar: Måste lägga till övervakning av uppdateringsprocessen. Anpassad lösning, så att du inte utnyttjar några befintliga uppdateringsvägar.

Rekommenderad lösning: Om utlösande av uppdateringar för underordnade processorer via Azure Sphere-appuppdateringar fungerar för ditt scenario rekommenderas den här metoden. Den här lösningen säkerställer att Azure Sphere- och nedströmsversionerna av inbyggd programvara alltid matchas, och det kräver inte att du skapar ett annat system för att utlösa uppdateringar. Annars, om programmet redan använder Azure IoT Hub, är IoT Enhetshantering den rekommenderade lösningen, annars krävs en anpassad lösning.

Exempel:

  • ExternalMcuUpdate-referenslösningen visar hur du kräver en specifik version av den inbyggda programvaran på en nedströmsenhet för varje Azure Sphere-programversion.
  • Azure Sphere External MCU OTA implementerar en uppdatering av inbyggd programvara för Azure Sphere med hjälp av Enhetshantering av Azure IoT Hub.
  • Självstudien om uppdatering av inbyggd programvara i Azure IoT Hub beskriver hur du utlöser uppdateringar via egenskaper för Azure IoT Hub-enhetstvillingar.

Steg 2: Hämta uppdateringen av inbyggd programvara

Problem: Hur ska den inbyggda programvaran laddas ned med tanke på minnesbegränsningarna för Azure Sphere MT3620?

Alternativ:

  • Inkludera den nedströms inbyggda programvaran i det avbildningspaket som distribuerats till MT3620. Detta är möjligt om den totala storleken på MT3620-programvaran, inklusive nedströmsbilden, inte överskrider den dokumenterade blixtgränsen.

  • Ladda ned den inbyggda programvaran från en värdbaserad plats, till exempel med hjälp av Azure Blob Storage. Det kan vara nödvändigt att ladda ned den inbyggda programvaran i segment eftersom RAM-gränsen på MT3620 kan förhindra att hela avbildningen laddas ned till RAM-minnet. Det är viktigt att verifiera servern som används för nedladdning av inbyggd programvara, till exempel genom att använda HTTPS, för att säkerställa att endast betrodd inbyggd programvara laddas ned och tillämpas på den underordnade processorn. Observera att i det här fallet är det möjligt för en enhet att vara online medan Azure Sphere-appen uppdateras, men sedan gå offline innan den nya appen kan ladda ned ny nedströms inbyggd programvara. Om detta är en möjlighet för ditt användningsfall är det viktigt att upprätthålla kompatibiliteten mellan Azure Sphere-appen och äldre nedströmsversioner av inbyggd programvara.

Rekommenderad lösning: Om avbildningen av den inbyggda programvaran passar in i flashgränsen för Azure Sphere-avbildningspaketet, och om det är acceptabelt att uppdatera MT3620-programvaran varje gång en nedströmsuppdatering behövs, rekommenderar vi att du inkluderar den nedströms avbildningen i MT3620-bildpaketet. Annars måste du ladda ned avbildningen av den inbyggda programvaran från den värdbaserade platsen.

Exempel:

Steg 3: Fastställa en mellanliggande nedladdningsplats

Problem: Det här problemet är bara relevant om du inte använder en avbildning av inbyggd programvara som ingår i Azure Sphere-bildpaketet och där den inbyggda programvaran som laddas ned är större än det tillgängliga RAM-minnet på MT3620.

Alternativ:

  • Extern blixt ansluten till Azure Sphere.
  • Nedströms MCU- eller PC-lagring.

Det finns inget rätt eller fel svar på var den nedladdade inbyggda programvaran ska lagras. Det här valet beror på maskinvarukonfigurationen och kostnaden. Vilket är det bästa alternativet för dig? Du kan överväga att koppla externt flashminne till din Azure Sphere-enhet eller välja en nedströmsprocessor med tillräckligt stor lagring för att ta emot uppdateringen av den inbyggda programvaran.

Rekommenderad lösning: Välj det bästa alternativet för konfigurationen.

Exempel:

Steg 4: Validera inbyggd programvara och uppdatera nedströmsprocessor

Problem: Hur validerar och tillämpar du uppdateringen av den inbyggda programvaran på den underordnade processorn?

Alternativ: Varje processor har en annan lösning. De flesta processortillverkare har exempel som visar hur du utför uppdateringar av inbyggd programvara på sina enheter och du bör följa metodtipsen för din specifika lösning. Nedladdningen och uppdateringen av den inbyggda programvaran bör utföra en integritetskontroll för att verifiera den inbyggda programvaran innan uppdateringen startas.

Rekommenderad lösning: Skiljer sig åt för varje processor. Se processortillverkarens exempel.

Exempel: ExternalMcuUpdate-referenslösningen visar hur du uppdaterar en nordisk nRF52 via ett UART-gränssnitt från MT3620.