Softwaretracering op in het veld geïmplementeerde apparaten

Softwaretracering is een belangrijk hulpmiddel in de gereedschapskist van elke embedded ontwikkelaar, vooral in combinatie met geavanceerde visualisatie. De meeste embedded systemen hebben veel cyclische patronen, waarbij dezelfde reeks zich keer op keer herhaalt. Bij het debuggen wil je vaak de anomalieën vinden, d.w.z. afwijkingen van het normale cyclische gedrag waar iets ongewoons gebeurde.

Software-tracering op zich is echter slechts een vorm van gegevensverzameling. Het zoeken naar een probleem in een schat aan tekstuele of numerieke loggegevens is vergelijkbaar met zoeken naar een speld in een hooiberg, maar met de juiste visualisatie wordt het zoeken getransformeerd in een probleem van visuele patroonherkenning, iets waar het menselijk brein bijzonder goed voor is uitgerust . Interactieve grafieken met uitvoeringstijden, reactietijden, taakwisselingen, het doorgeven van berichten tussen taken - dit alles stelt een ontwikkelaar in staat om snel afwijkingen in de uitvoering van hun firmware op te sporen en dieper te graven.

Tools voor visuele sporendiagnostiek bestaan ​​al minstens tien jaar en zijn nuttig gebleken voor ontwikkeling en debuggen in het laboratorium. Nu steeds meer ontwikkelaars van embedded software veilige 'internet of things'-cloudconnectiviteit toevoegen, is het heel natuurlijk om het gebruik van tracering in geïmplementeerde apparaten in het veld te overwegen, om echte problemen vast te leggen die tijdens het testen over het hoofd waren gezien. Voor op software gebaseerde tracering is immers geen extra hardware nodig en een aangesloten IoT-apparaat is uiteraard in staat diagnostische traceergegevens te uploaden, op dezelfde manier als reguliere applicatiegegevens. Op deze manier kunnen ontwikkelaars zich snel bewust worden van eventuele resterende softwareproblemen die problemen veroorzaken tijdens het gebruik in de echte wereld en ook gedetailleerde diagnoses krijgen om de oorzaak te begrijpen.

In dit scenario is software tracing vergelijkbaar met een virtuele "flight recorder", zoals die in vliegtuigen wordt gebruikt bij ongevallen. Het is een geïntegreerd onderdeel van het product dat altijd aan het opnemen is en essentiële informatie geeft in geval van een probleem. Maar in tegenstelling tot de echte vluchtrecorderboxen, is het een softwareoplossing en bedoeld voor softwareproblemen.

Een oplossing voor dit soort IoT-apparaatmonitoring is Percepio's DevAlert (figuur 1), die uit drie delen bestaat:een firmwaremonitor, een kleine bibliotheek die u aan uw firmware toevoegt om het traceren en uploaden van waarschuwingen mogelijk te maken; onze Tracealyzer-tool voor visuele sporendiagnostiek; en een cloudservice, die verantwoordelijk is voor het categoriseren en opslaan van waarschuwingen, het informeren van ontwikkelaars, het filteren van dubbele waarschuwingen en meer.

Figuur 1. Percepio DevAlert biedt IoT-ontwikkelaars directe feedback over fouten in hun met de cloud verbonden apparaten, waardoor de apparaatsoftware snel en continu kan worden verbeterd.
(Klik op de afbeelding om te vergroten)

De eerste versie draait op AWS en is bedoeld voor RTOS-applicaties die AWS IoT core gebruiken, maar de oplossing kan worden aangepast voor andere cloudplatforms.

Softwaretracering en cloudconnectiviteit
Traceren in het ontwikkelingslab en ingezette apparaten traceren zijn twee verschillende dingen. Als u vandaag visuele sporendiagnostiek in het laboratorium gebruikt en wilt uitbreiden naar het veld, zijn er een paar dingen waar u over moet nadenken.

Vergeleken met een directe fysieke verbinding zoals USB of Ethernet, biedt een cloudverbinding zowel een beperkte bandbreedte als veel langere reactietijden. Het uploaden van bijvoorbeeld 5 KB aan gegevens kan tientallen of honderden milliseconden vergen via een draadloze interface. In deze benadering worden sporen echter niet continu verzonden, maar alleen wanneer een waarschuwing wordt gegenereerd en slechts een klein spoor van de meest recente gebeurtenissen. Waarschuwingen zijn alleen bedoeld voor ongebruikelijke maar belangrijke dingen, bijvoorbeeld als er een fout is gedetecteerd in de applicatiecode, zoals een mislukte sanity check, harde storing of een watchdog-reset.

Elk apparaat met internetverbinding moet veilig zijn. Het is daarom belangrijk om geen nieuwe aanvalsvectoren te introduceren. We lossen dit in DevAlert op door te vertrouwen op bestaande cloudconnectiviteit in plaats van een nieuwe verbinding te introduceren. Dit maakt gebruik van de beveiliging van AWS en andere toonaangevende IoT/cloud-providers, die geverifieerde SDK's bieden voor cloudconnectiviteit die zijn beveiligd volgens best practices, zoals apparaatauthenticatie met behulp van X.509-certificaten en versleutelde communicatie met TLS. Dit zou DevAlert-uploads dan net zo veilig maken als reguliere IoT-toepassingsgegevens, en voor extra veiligheid heeft het alleen eenrichtingscommunicatie nodig:het luistert nooit naar inkomende berichten.

Bij deze benadering worden waarschuwingen geüpload naar hetzelfde cloudaccount dat normaal door het apparaat wordt gebruikt, en met hetzelfde beveiligingsniveau. Eenmaal in de cloud wordt een klein deel van de data aan de clouddienst geleverd. Dit omvat niet de daadwerkelijke traceergegevens, die als gevoelige informatie kunnen worden beschouwd en daarom in het cloudaccount van het apparaat blijven. Figuren 2a en 2b tonen de datastroom en de beveiligingsbarrières in meer detail.

Figuur 2a. De gegevensstroom begint in de apparaatsoftware, waar ontwikkelaars waarschuwingen toevoegen aan de broncode. Elke waarschuwing die wordt geüpload naar het cloudaccount van het apparaat, bevat een korte tracering met de meest recente gebeurtenissen voorafgaand aan de waarschuwing. Ten slotte wordt een metadatahandtekening doorgestuurd naar de DevAlert-cloudservice. (Klik op afbeelding om te vergroten)

Figuur 2b. De cloudservice vergelijkt inkomende waarschuwingen met eerdere waarschuwingen van het volledige apparaatvloot van de klant en stelt ontwikkelaars op de hoogte van nieuwe problemen. Dubbele waarschuwingen worden geteld en opgeslagen, maar er worden geen meldingen verzonden. Op deze manier worden de inboxen van ontwikkelaars niet overspoeld als dezelfde waarschuwing op meerdere apparaten wordt geactiveerd. (Klik op afbeelding om te vergroten)

De operationele kosten voor het ontvangen van waarschuwingen voor een cloudaccount zijn doorgaans laag, hoewel dit natuurlijk afhankelijk is van het volume. Om te beginnen, zolang er geen problemen worden gedetecteerd, worden er geen waarschuwingen verzonden. Over het algemeen rekenen cloudproviders ook heel weinig voor het verzenden en opslaan van incidentele waarschuwingsberichten. De meeste IoT-toepassingen genereren veel meer data, wat tot uiting komt in de prijsstelling van de IoT/clouddiensten. Het verzenden van 1 miljoen MQTT-berichten naar de AWS IoT-kern kost bijvoorbeeld US$ 1.

Het grootste deel van de alarmverwerking vindt plaats in de cloudservice, een volledig beheerde service die wordt gehost door Percepio. Alleen de eerste verwerking vindt plaats in het cloudaccount van de apparaatontwikkelaar, waardoor de cloudkosten laag blijven en de integratie wordt vereenvoudigd.

Het verzenden van draadloze updates om gerapporteerde fouten op te lossen kan mogelijk wat meer kosten, omdat u veel meer gegevens naar alle apparaten moet overbrengen. AWS geeft een prijsvoorbeeld waarbij de kosten voor het updaten van een vloot van 600.000 apparaten US$ 1.275 bedragen. Dit is echter niet erg duur in verhouding tot de kosten van het onopgelost laten van een bug:beschadigde klantervaring, lagere beoordelingen van productrecensies, lagere verkopen of zelfs ongelukken en juridische stappen.

DevOps voor embedded ontwikkeling
Het inschakelen van uw IoT-apparaten om "naar huis te bellen" in geval van softwareproblemen heeft een aanzienlijk voordeel. Het directe besef van fouten en gedetailleerde diagnostiek creëren een feedbacklus tussen ontwikkelaars en geïmplementeerde code, waardoor ontwikkelaars bugs sneller kunnen oplossen en bijgewerkte firmware sneller kunnen uitbrengen - zie afbeelding 3. Deze zogenaamde DevOps-filosofie is lange tijd de standaard geweest in de ontwikkeling van mobiele en cloudapplicaties, en met de introductie van veilige cloudgebaseerde IoT-platforms is het mogelijk geworden voor embedded ontwikkeling om ook op deze manier te werken.

Figuur 3. Het DevAlert-dashboard in Tracealyzer toont de meest recent gerapporteerde waarschuwingen en sporen.
(Klik op de afbeelding om te vergroten)

Vanuit een zakelijk perspectief vertaalt deze monitoring in DevOps-stijl zich in minder ontevreden klanten, omdat minder eindgebruikers worden getroffen door bugs in productiecode. De meeste embedded software bevat een aantal gemiste bugs bij de release, ondanks alle verificatie-inspanningen, maar ze verschijnen meestal niet direct voor iedereen. Er is vaak enige tijd om het probleem op te lossen voordat veel klanten worden getroffen, als u er vroeg van op de hoogte bent. Idealiter zouden ontwikkelaars binnen enkele seconden na de allereerste waarschuwing op de hoogte moeten worden gebracht en de meegeleverde traceringsdiagnose maakt snelle analyse en correctie mogelijk. Ontwikkelaars kunnen dan een automatische over-the-air update sturen om het probleem op te lossen. De onmiddellijke signalering en traceerdiagnose kunnen de reparatietijd aanzienlijk verkorten en het aantal getroffen klanten minimaliseren.

Verbeterde apparaatbetrouwbaarheid vermindert aansprakelijkheidsrisico's en verlaagt ook de kosten voor klantenondersteuning, retourzendingen en foutopsporing. De meegeleverde diagnose maakt het veel gemakkelijker voor ontwikkelaars om problemen van klanten te reproduceren, omdat ze informatie rechtstreeks van het apparaat krijgen en niet op de gebruiker hoeven te vertrouwen om de omstandigheden te beschrijven. Zonder automatische feedback vertrouwt u erop dat uw eindgebruikers eventuele problemen melden en voldoende gedetailleerde informatie verstrekken. Een vaag foutrapport als "het systeem reageert niet meer" is niet erg nuttig en het kan weken duren om een ​​waarschijnlijke oorzaak te vinden. En zelfs dan is het gewoon je beste gok - je kunt niet echt weten of je het juiste probleem hebt opgelost.

Niet alleen bugs
Een ding om op te merken is dat waarschuwingen niet alleen over gemiste bugs en de resulterende fouten hoeven te gaan. Omdat ontwikkelaars vrij zijn om te beslissen waar en waarom waarschuwingen moeten worden gegenereerd, kunnen ze deze ook gebruiken voor het bewaken van de belangrijkste prestatiestatistieken van de applicatie en om de reden voor incidentele prestatieproblemen te zien.

Het monitoren van de gebruikersinterface kan ook interessante informatie opleveren. Stel dat u een situatie hebt waarin de gebruiker een menu op een aanraakscherm opent, bijv. in de infotainmentsystemen van een auto, en aarzelt dan waar te gaan. Om dergelijke problemen op te vangen, kan de applicatieontwikkelaar een timer starten na elke invoergebeurtenis en een waarschuwing genereren als er binnen bijvoorbeeld 5 seconden geen invoer wordt ontvangen. Als er vervolgens veel waarschuwingen worden ontvangen over hetzelfde deel van de gebruikersinterface, kan dit belangrijke feedback zijn die uw organisatie kan helpen betere producten te bouwen.

Al met al heeft het gebruik van softwaretracering en cloudgebaseerde waarschuwingen op geïmplementeerde apparaten grote voordelen en is niet ingewikkeld. Om een ​​workflow in DevOps-stijl volledig te omarmen, is echter de mogelijkheid nodig voor draadloze updates en een responsieve ontwikkelingsorganisatie die de beperkingen van het testen van software en het belang van continue verbetering, ook na de release, begrijpt.