Dela via

Skyddsmoduler

  • Artikel

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).

En skyddsmodul är tilläggsmaskinvara som innehåller ett Azure Sphere-chip och som fysiskt kopplas till en port på en "brownfield"-enhet, dvs. en befintlig enhet som kanske redan används.

Med hjälp av en skyddsmodul kan du lägga till säkra IoT-funktioner till utrustning som antingen inte stöder internetanslutning eller inte stöder den på ett säkert sätt. Kort och kort är en skyddsmodul ett sätt att implementera säker anslutning på befintliga enheter utan att exponera enheterna för Internet. Eftersom det är en Azure Sphere-enhet är alla säkerhets- och anslutningsfunktioner i Azure Sphere tillgängliga: alla data krypteras, os- och programuppdateringar levereras på ett säkert sätt och autentiseringen säkerställer att modulen endast kommunicerar med betrodda värdar.

Så här fungerar en skyddsmodul:

  • Skyddsmodulen ansluter till en brownfield-enhet enligt beskrivningen i avsnittet Anslutning i det här avsnittet. Själva brownfield-enheten är inte ansluten till nätverket.

  • Azure Sphere OS körs på skyddsmodulen tillsammans med ett anpassat högnivåprogram och andra Azure Sphere-program som ditt scenario kräver.

  • Skyddsmodulen använder Azure Sphere Security Service för certifikatbaserad autentisering, felrapportering och trådlösa programuppdateringar.

  • Brownfield-enheten kommunicerar med skyddsmodulen, som kan svara genom att vidta en lokal åtgärd eller genom att rapportera till en molnnärvaro som Azure IoT Central.

Du kan köpa skyddsmoduler från en leverantör och anpassa dem ytterligare för ditt användningsscenario, eller så kan du utforma en egen skyddsmodul, eventuellt arbeta med en maskinvarupartner. Mer information om maskinvaruleverantörer finns på Azure Sphere-webbplatsen .

Använder för en skyddsmodul

En skyddsmodul kan göra allt som andra Azure Sphere-enheter kan göra, samtidigt som den fungerar som ett säkert gränssnitt mellan befintlig utrustning och ett externt nätverk. Möjliga användningsområden för en skyddsmodul är:

  • Samla in data från brownfield-enheten, bearbeta data och överföra data på ett säkert sätt till en molnslutpunkt
  • Skicka data till flera slutpunkter, förutsatt att de kan autentisera varje slutpunkt
  • Samla in ytterligare data som inte är tillgängliga från brownfield-enheten. Sensorer i skyddsmodulen kan till exempel tillhandahålla miljödata för användning med driftdata från brownfield-enheten
  • Spara data från brownfield-enheten om anslutningen går förlorad

Azure Sphere-exempellagringsplatsen innehåller två exempel som visar hur en Azure Sphere-enhet kan användas som en skyddsmodul:

  • Enhet till molnet visar hur en Azure Sphere-enhet kan användas för datainsamling samtidigt som den ger säker Internetåtkomst för en brownfield-enhet som är ansluten till den via ett seriellt gränssnitt.
  • Privata nätverkstjänster visar hur en Azure Sphere-enhet kan ge säker internetåtkomst för en brownfield-enhet som är ansluten till den via ett TCP/IP-gränssnitt.

Anslutning

Det finns flera mekanismer som stöds för anslutning mellan skyddsmodulen och nätverket, och mellan skyddsmodulen och brownfield-enheten. Allmän information om Azure Sphere-anslutningslösningar finns i Anslutningsöversikt och Nätverkskrav.

En skyddsmoduls högnivåprogram kommunicerar uppströms med nätverket, inklusive Azure Sphere Security Service och andra molntjänster, och nedströms med brownfield-enheten:

  • För överordnade anslutningar mellan skyddsmodulen och nätverket kan du använda Ethernet, Wi-Fi eller mobilnät.

  • För nedströmsanslutningar mellan skyddsmodulen och brownfield-utrustningen kan du använda följande:

    • Alla seriegränssnitt, till exempel UART, RS-485 eller SPI, som brownfield-enheten exponerar
    • Privat Ethernet, som inte exponerar brownfield-enheten för det offentliga nätverket
    • Trådlöst, till exempel Bluetooth eller ZigBee

Programutveckling och programdistribution

Att utveckla och distribuera ett program för en skyddsmodul skiljer sig inte från att utveckla och distribuera ett program för någon annan Azure Sphere-enhet. Mer information finns i Översikt över Azure Sphere-program och grunderna för distribution. Precis som med alla Azure Sphere-enheter måste en skyddsmodul ha minst ett Azure Sphere-program på hög nivå och kan även ha realtidskompatibla program.

Du behöver åtkomst till tjänsten UART, som är huvudgränssnittet för programmering och felsökning mellan MT3620 och utvecklingsmiljön som körs på en värddator. Om du utformar din egen skyddsmodul måste du se till att tjänstens UART-signaler exponeras och att du stöder ett sätt att interagera med tjänstenS UART antingen på själva skyddsmodulen eller på en separat maskinvara. Om du köper moduler från en leverantör bör leverantören tillhandahålla en lösning som aktiverar den här anslutningen.

Om din leverantör eller någon annan tredje part skapar programmet kan du behöva ge åtkomst till din Azure Sphere-klientorganisation så att programutvecklaren kan läsa in och testa programmet och skapa en distribution.

Program på hög nivå

Ett högnivåprogram för skyddsmoduler måste vara anpassat skrivet för varje organisations brownfield-enheter. Om leverantören av skyddsmodulen tillhandahåller ett program ska du se till att du får programkällkoden och biblioteken på hög nivå så att du kan ändra eller uppdatera programmet efter behov.

Precis som med alla Azure Sphere-enhetsprogram måste enhetsspecifik och programspecifik information anges i programmanifestet. Till exempel är guardian-modulens anslutningar enhetsspecifik information som måste ingå i manifestet.

Ett högnivåprogram som körs på en skyddsmodul ansvarar för följande:

  • Upprätta och underhålla anslutningar med brunfältsutrustningen
  • Upprätta och underhålla anslutningar till Internet, inklusive Azure Sphere Security Service och andra molntjänster
  • Hantera data som tas emot från brownfield-enheten – packa upp och lagra data vid behov och kommunicera med Internetvärdarna efter behov
  • Hantera data som tas emot från en internetvärd – packa upp och lagra data vid behov och kommunicera med brunfältsutrustningen efter behov

Data som skickas uppströms kan innehålla felrapporter, driftparametrar eller övergripande telemetri. Azure Sphere ser till att alla sådana data krypteras. Programmet kan ansluta till webbtjänster och använda ömsesidig autentisering för sådana anslutningar.

Data som skickas nedströms kan innehålla uppdaterad programvara eller ändringar av inställningar eller parametrar för brownfield-enheten. För att undvika potentiella säkerhetsöverträdelser bör programmet verifiera inkommande data innan det skickas nedströms till brownfield-enheten.

Programöverväganden

När du skapar ett program bör du överväga kringutrustningen, lagringskraven och energiförbrukningen.

Kringutrustning

Precis som andra Azure Sphere-enheter skiljer sig skyddsmodulerna åt i kringutrustningen som de exponerar. Välj en skyddsmodul som tillhandahåller de anslutnings- och avkänningsfunktioner som ditt scenario kräver.

Beroende på maskinvaruarkitekturen i skyddsmodulen, det vill: hur den exponerar funktioner i Azure Sphere-chipet, kan du avgöra om programvaran för att få åtkomst till enskilda funktioner måste implementeras som ett högnivåprogram eller ett realtidskompatibelt program.

Lagringskrav

Azure Sphere har begränsad lagring, så tänk noga på hur mycket minne som behövs för program och data. Mer information finns i Tillgängligt minne .

När du skickar data nedströms från molnet till brownfield-enheten kontrollerar du att skyddsmodulen har tillräckligt med utrymme för att lagra data. Du kan behöva skicka data i segment, vilket visas av HTTPS_Curl_Multi exempel på Azure Sphere GitHub-exempellagringsplatsen.

När du skickar data uppströms från brownfield-enheten till skyddsmodulen kontrollerar du att programmet kan hantera överordnad anslutningsfel. Om brownfield-enheten tillhandahåller löpande telemetri måste du överväga vilka data och hur mycket av dem som ska behållas och senare skickas till molnet när anslutningen återställs. Se galleriexemplet store-and-forward, som visar hur du använder lokal lagring för att tillfälligt cachelagera data innan de laddas upp.

Strömförbrukning

Det finns många program där skyddsmodulen är inaktiv för det mesta. Tänk dig till exempel en Azure Sphere-enhet som en gång i timmen samlar in data från ett nätverk med sensorer och laddar upp dessa data till molnet – en åtgärd som kan ta en minut eller två. I det här fallet är den största delen av den ström som förbrukas av enheten bortkastad.

Du kan avsevärt minska energiförbrukningen och därmed öka batteritiden antingen genom att placera enheten i power down-tillstånd när den är inaktiv eller genom att ange en strömprofil. Mer information finns i Hantera Power Down-tillstånd och Ange energiprofiler .