Delen via

Ontwerpsuggesties voor kerntoepassingen op hoog niveau

  • Artikel

Als u een high-level (HL)-kerntoepassing wilt bouwen op een solide basis, moet u fundamentele best practices gebruiken. De volgende zijn het meest relevant:

High-level (HL) kerntoepassingen worden uitgevoerd in containers in het Azure Sphere-besturingssysteem. Tijdens code- en ontwerpbeoordelingen van oplossingen van klanten hebben we een aantal typische problemen met HL-core-toepassingen gevonden. In dit onderwerp worden suggesties voor ontwerpverbeteringen besproken om deze problemen op te lossen.

Algemene basisprincipes

Als u een HL-core-toepassing op een solide basis wilt bouwen, moet u fundamentele best practices gebruiken. De volgende zijn het meest relevant:

  • Initialisatie en beëindiging: Zorg er altijd voor dat u het SIGTERM-signaal van het Azure Sphere-besturingssysteem afhandelt en alle handlers (zoals die voor randapparatuur) goed initialiseert en vernietigt bij het afsluiten, hetzij bij crash of fout. Zie Initialisatie en beëindiging en de GNU-documentatie over Beëindigingssignalen voor meer informatie.
  • Gebruik altijd afsluitcodes: Ervoor zorgen dat de HL-core-toepassing altijd een zinvolle retourcode biedt bij het afsluiten of vastlopen (bijvoorbeeld met behulp van de SIGTERM-handler) is essentieel voor het correct diagnosticeren van het gedrag van het apparaat, met name op basis van de crashdumptelemetrie van het apparaat. Zie Afsluitcodes en Foutgegevens verzamelen en interpreteren voor meer informatie.
  • Zorg ervoor dat fouten altijd resulteren in het afsluiten of vastlopen van een toepassing in plaats van in een impassestatus: Uitgebreide logica voor foutherstel kan contraproductief zijn omdat deze fouten of gedrag kan veroorzaken, wat resulteert in een impasse of een status die moeilijk te diagnosticeren is. Een goed ontworpen Azure Sphere-toepassing moet altijd de voorkeur geven aan vastlopen of afsluiten (met een niet-nul afsluitcode) boven een mogelijke impasse, omdat dit resulteert in beide:
    • Fouttelemetrie, waarmee diagnostische gegevens voor dit probleem worden ingeschakeld
    • Een kans op onmiddellijk herstel naar een werkende status, omdat het Azure Sphere-besturingssysteem de toepassing opnieuw start
  • Foutafhandeling en logboekregistratie: Nauwkeurige foutafhandeling en logboekregistratie vormen de kern van kwaliteitstoepassingsontwikkeling. Snelle functionaliteitsimplementaties kunnen begraven blijven in codelagen en vervolgens worden overgebouwd naarmate de toepassing zich op volledige schaal ontwikkelt. Zie Foutafhandeling en logboekregistratie voor meer informatie over best practices.
  • Gebruik een systeemtimer als watchdog: Een van de meest cruciale best practices is het implementeren van een 'watchdog timer' callback (vergelijkbaar met de hardware die beschikbaar is in bare-metal MCU's) die kritieke toepassingsstatussen bijhoudt, impasse detecteert en dienovereenkomstig handelt (bijvoorbeeld het afsluiten en verzenden van telemetrie). Zie Een systeemtimer gebruiken als watchdog voor meer informatie.
  • Implementeer nooit productietoepassingen die zijn gebouwd voor een bètaversiehulpprogrammaset: Het gebruik van bètaversiehulpprogramma's wordt niet aanbevolen omdat niet kan worden gegarandeerd dat de bètasubset niet wordt gewijzigd in volgende versies van het besturingssysteem. Bètahulpprogrammasets worden alleen uitgebracht voor het testen van nieuwe functies voorafgaand aan een officiële SDK-release.

Gelijktijdigheid verwerken

  • Gebruik EventLoop waar mogelijk: Threads en synchronisatieobjecten (mutexen, semaforen, enzovoort) worden gebruikt om bijna gelijktijdige taken uit te voeren, maar binnen ingesloten systemen zijn deze duur wat betreft het gebruik van systeemresources. Om de prestaties te verbeteren, kunt u daarom overwegen epolls te gebruiken in plaats van threads, voor taken die niet strikt tijdskritiek zijn en niet gevoelig zijn voor wederzijdse blokkering. Zie Applibs eventloop.h voor informatie over het bewaken en verzenden van gebeurtenissen met EventLoop, inclusief gerelateerde voorbeelden.
  • Zoek naar efficiëntie bij gelijktijdige taken: Het is belangrijk om ervoor te zorgen dat blokkeringsbewerkingen en time-outs tot een minimum worden beperkt binnen epoll callbacks, anders worden alle andere epoll callbacks beïnvloed.
  • Wanneer gebruikt u threads (pthread): Voor specifieke scenario's, zoals wanneer het blokkeren van aanroepen onvermijdelijk is, kan het gebruik van threads nuttig zijn, hoewel deze scenario's doorgaans een beperkte levensduur hebben en moeten worden gericht op specifieke taken. Aangezien het Azure Sphere-besturingssysteem (met Linux) bijvoorbeeld geen IRQ's beschikbaar maakt voor HL-core-toepassingen (dit is alleen beschikbaar voor RT-core-apps), kan het gebruik van een combinatie van epoll- en pthread-taken optimaal zijn bij het verwerken van bijvoorbeeld een downstream seriële communicatie tijdens het downloaden van gegevens van internet.

Belangrijk

Het Azure Sphere-besturingssysteem kan tijdige bewerkingen onderbreken, met name wanneer het apparaat attestation uitvoert, controleert op updates of telemetrie uploadt. Voor tijdkritieke controletaken kunt u overwegen deze te verplaatsen naar de M4-kernen en deze te coördineren met een geschikt protocol via het postvak tussen kernen. Zie het voorbeeld van communicatie tussen kernen voor meer informatie.

Raadpleeg naast deze suggesties ook de Azure Sphere-documentatie over asynchrone gebeurtenissen en gelijktijdigheid.

Connectiviteitscontrole

Een goed ontworpen hl-kerntoepassing (high-level) moet een juiste taak voor connectiviteitsstatuscontrole implementeren, die moet zijn gebaseerd op een robuuste statuscomputer die regelmatig de status van de internetverbinding controleert (bijvoorbeeld met behulp van een epolltimer ) door gebruik te maken van de Networking_IsNetworkingReady-API . In sommige gevallen kunt u de Networking_GetInterfaceConnectionStatus-functie gebruiken, omdat deze een uitgebreidere status biedt van de connectiviteitsstatus met betrekking tot een specifieke netwerkinterface die de HL-core-toepassing kan gebruiken om de status ervan beter te verhelpen, hoewel dit kosten met zich mee brengt omdat het niet wordt aanbevolen om deze vaker aan te roepen dan elke 90 seconden.

De callback van de statuscomputer moet doorgaans de volgende kenmerken hebben:

  • Voer zo snel mogelijk uit.
  • Het polling-interval moet zorgvuldig worden ontworpen, op basis van het specifieke toepassingsscenario en de algemene oplossingsvereisten (zoals constante tijd, incrementele vertraging, enzovoort).
  • Zodra een verbroken verbinding is gedetecteerd, kan het handig zijn om Networking_GetInterfaceConnectionStatus één keer aan te roepen om de status van de specifieke netwerkinterface te registreren. Deze kan worden gebruikt om het probleem vast te stellen en de gebruiker op de hoogte te stellen via een gebruikersinterface (zoals LED's, beeldscherm, terminal). Een voorbeeld van deze benadering vindt u in de hoofdcode van het Azure Sphere DHCP-voorbeeld.
  • Activeer een mechanisme (bijvoorbeeld via een globale variabele) dat alle andere taken in de HL-core-toepassing stopt die netwerkcommunicatie uitvoeren (of zijn gekoppeld aan) om het resourceverbruik te optimaliseren totdat een verbinding opnieuw tot stand is gebracht.
  • cURL heeft onlangs het callback-gedrag en de best practices bijgewerkt. Hoewel Azure Sphere zich heeft ingespannen om ervoor te zorgen dat oudere versies van cURL-gedrag blijven werken zoals verwacht, wordt het aanbevolen om de meest recente richtlijnen voor beveiliging en betrouwbaarheid te volgen bij het gebruik van curl_multi, omdat het gebruik van recursieve callbacks kan leiden tot onverwachte crashes, connectiviteitsproblemen en potentiële beveiligingsproblemen. Als een TimerCallback wordt geactiveerd met een time-out van 0 ms, behandelt u deze als een time-out van 1 ms om recursieve callbacks te voorkomen. Zorg ervoor dat u curl_multi_socket_action ook minstens één keer expliciet aanroept na aanroepen naar curl_multi_add_handle.

Naast de vorige suggesties moet u rekening houden met de volgende scenario's voor energiebeheer:

  • Schakel de Azure Sphere-chip uit na het verzenden van gegevens. Zie Power Down-status beheren voor Azure Sphere-apparaten voor meer informatie.
  • Omdat verschillende problemen het gevolg kunnen zijn van lange exponentiële time-outs voor back-outs, is het essentieel om de totale uptime bij te houden en een timer voor afsluiten in te stellen op een redelijke limiet, zodat de batterij niet leegloopt in omstandigheden waarin connectiviteit niet meer mogelijk is vanwege externe storingen of andere factoren die buiten de controle van de toepassing vallen.
  • Bij het beheren van connectiviteitscontrole tijdens storingen kan de Wi-Fi transceiver uitschakelen door de wlan0 netwerkinterface uit te schakelen (zie Networking_SetInterfaceState en te wachten tot de volgende controle op connectiviteit opnieuw, waardoor ongeveer 100 mW wordt bespaard.

Geheugenbeheer en -gebruik

Op platforms met geheugenbeperkingen kunnen toepassingen die regelmatig geheugentoewijzingen en ongedaan maken van toewijzingen uitvoeren, ertoe leiden dat het geheugenbeheer van het besturingssysteem moeite heeft met efficiëntie, waardoor overmatige fragmentatie en geheugenuitloop ontstaan. Met name op de Azure Sphere MT3620 kan dit leiden tot te weinig geheugen waardoor de cgroup OOM-killer van het Azure Sphere-besturingssysteem kan worden gestart.

Het is begrijpelijk dat toepassingen vaak worden ontwikkeld vanaf een eerste proof-of-concept, dat uitgebreider wordt met functies die nodig zijn voor progressieve releases, waarbij uiteindelijk kleine functies die in eerste instantie werden opgenomen, worden genegeerd. Hier volgen suggesties en optimalisaties die effectief zijn gebleken voor veel scenario's die in het veld worden geanalyseerd:

  • Met name binnen HL-core-toepassingen die intensief gebruik maken van geheugen, is het essentieel om het gebruik van het toepassingsgeheugen bij te houden via de Azure Sphere-API, zoals beschreven in Run-time toepassings-RAM-gebruik bepalen. Dit wordt meestal geïmplementeerd in een epoll-timer watchdog en de toepassing reageert dienovereenkomstig op onverwacht geheugengebruik om op een redelijke manier opnieuw op te starten; bijvoorbeeld afsluiten met de juiste afsluitcode.

    Verschillende klanten en partners hebben het nuttig gevonden om het hulpprogramma Heap Tracker-geheugentracering te gebruiken, dat is gepubliceerd in de Azure Sphere-galerie. Deze bibliotheek is transparant gekoppeld aan een bestaande HL-core-toepassing en houdt geheugentoewijzingen en de bijbehorende aanwijzers bij, waardoor de meeste gevallen van geheugenlekken en misbruik van aanwijzers eenvoudiger kunnen worden gedetecteerd.

Belangrijk

Deze oefening kan de schijnbaar onverklaarde niet-reactie of fouten van het apparaat verminderen die vaak vanuit het veld worden gemeld. Dergelijke fouten worden meestal veroorzaakt door geheugenlekken of overschrijdingen die niet goed worden verwerkt door de HL-core-toepassing en ertoe leiden dat de OOM-killer het proces van de toepassing afsluit. Dit kan, samen met een slechte connectiviteit die het Azure Sphere-besturingssysteem verhindert telemetrie te verzenden, leiden tot potentiële veldincidenten, omdat de diagnose alleen kan worden gedetecteerd door de diagnostische logboeken van het Azure Sphere-besturingssysteem op te halen.

  • Op platforms met beperkte geheugenlimiet is het over het algemeen beter om waar mogelijk dynamische geheugentoewijzing te vermijden, met name binnen veelgebruikte functies. Dit vermindert de geheugenfragmentatie van de heap en de kans op volgende heap-toewijzingsfouten aanzienlijk. Overweeg ook een paradigmaverschuiving van het herhaaldelijk toewijzen van tijdelijke werkbuffers naar directe toegang tot de stack (voor variabelen van redelijke grootte) of globaal toegewezen buffers, die groter worden (tot realloc) bij overloop (zie Dynamische containers en buffers). Als er een vereiste is om geheugen te offloaden, kunt u overwegen om te profiteren van ongebruikt geheugen op de M4-kernen (zie Geheugen beschikbaar op Azure Sphere), die elk 256KiB hebben, met een lichtgewicht RT-core-toepassing voor gegevenscache. U kunt uiteindelijk externe SD-kaarten of flash gebruiken. Voorbeelden zijn te vinden in de volgende opslagplaatsen:

Het volgen van de bovenstaande suggesties kan ook helpen bij het schatten en reserveren van het geheugen dat nodig zou zijn om de HL-core-toepassing op volledige capaciteit te laten werken gedurende de levenscyclus, terwijl u de totale geheugenvoetafdruk van de toepassing beter kunt inschatten voor latere ontwerpoptimalisaties. Raadpleeg de volgende artikelen voor meer informatie over het optimaliseren van het geheugengebruik in HL-core-toepassingen, waaronder functies in het Azure Sphere-besturingssysteem en Visual Studio: