JavaScript is currently disabled.Please enable it for a better experience of Jumi. Percepios trace fortsätter när systemet tas i drift

EMBEDDED WORLD Percepios kodspårning kan nu snurra vidare även på system som är i drift. Tjänsten heter DFM (Device Firmware Monitor) och öppnar för möjligheten att kontinuerligt kvalitetssäkra kod.

SÅ GÖRS
KODSPÅRNING
I SKARP DRIFT

Percepio Device Firmware Monitor (DFM) ger IoT-leverantörer automatisk återkoppling om detekterade fel och varningar från produkternas programvara. Det kan användas både under intern testning och i levererade produkter. 

Såhär fungerar systemet. Ett problem upptäcks i programvaran – en funktion anropas med felaktiga parametrar, en funktion som returnerar felkod, eller en detekterbar krasch. Så anropas en DFM-agent och laddar (krypterat) upp en felrapport till Amazon S3 eller annan molntjänst via exempelvis MQTT över TLS. 

Utvecklaren får en felrapport och en inspelning av felet som kan användas direkt i Percepio Tracealyzer. De senaste händelserna i koden lagrats kontinuerligt i en så kallad ringbuffert. 

En signatur av felrapporten – anonyma checksummor – skickas till Percepio där en  klassificeringsmotor identifierar symptom, programversion och enhet, men ingen potentiellt känslig information angående programvarans beteende. 

– Det enda vi kan se är att rapportering förekommer, men inte vad rapporterna innebär.

Inspelningen visar vad som pågick i programvaran omedelbart före felet, typiskt ett par hundra millisekunder – vilka tasks som var aktiva och ungefär vad de gjorde, till exempel att USB-anslutning just initierats. 

Berörda utvecklare kan meddelas via epost – kontinuerligt eller i periodiska statistiska summeringar.

DFM stöder operativsystemet FreeRTOS och webbtjänsten Amazon S3 idag. I den kombinationen finns i sin tur möjligheten att göra programvaruuppdatering (Over-The-Air update) efter att buggen fixats.

– På sikt kommer vi erbjuda liknande integrationer för andra molntjänster.

 Klicka för större bild!

Å ena sidan har introduktionen av IoT  gjort de inbyggda systemen mer komplexa. Å andra sidan öppnar uppkopplingen i sig nya möjligheter att underhålla systemet och till och med att fortsätta att avlusa källkoden medan systemet är i drift.

Det har svenska Percepio insett och applicerar nu principen på sitt verktyg Tracealyzer.

Johan
Kraft

– Genom automatisk rapportering av information i samband med fel blir det möjligt att felsöka och fixa återstående buggar snabbt. Därmed har man möjlighet att man skicka ut en programvaruuppdatering innan de flesta av dina kunder ens har märkt något problem, säger Percepios vd Johan Kraft.

Tracealyzer är ett spårningsverktyg vilket innebär att det loggar och visualiserar vad som händer på cpu:n under en programkörning – kodrader som körs, avbrottssignaler, aktuella variabelvärden. 

 Johan Kraft skapade det under sitt doktorsarbete på MDH och tillämpade det bland annat på ABB:s industrirobotar. Han var flera magnituder effektivare än etablerade lösningar och hans företag Perciepio firar i år tioårsjubileum.

Redan i ABB-robotarna gjorde Tracealyzer kodspårning i fält efter att roboten tagits i drift, och flera senare kunder har hemsnickrade lösningar för detsamma. 

Nu lanserar Percepio möjligheten som en egen tjänst under namnet  DFM (Device Firmware Monitor)

DFM tar molntjänster i bruk för att mellanlagra spårningsdata. Allt är därefter integrerat i Tracealyzer och i kundens inbyggda system.

– DFM erbjuder en färdig lösning med support som är enkel att komma igång med. Kunden behöver inte bygga en egen lösning, säger Johan Kraft.

När du gör spårning på detta sätt kan du inte som du gör normalt i Tracealyzer, skruva på parametrar i realtid, utan arbetar mot en inspelning på ett par hundra millisekunder. 

DFM låter inspelningen rulla kontinuerligt under det att programmet körs i fält. Typiskt adderar instrumenteringen för detta några procents overhead till programkörningen

Som programmerare kan du exempelvis låta så kallade ”assertions” trigga att inspelningen tankas upp för analys. En assertion är en standardmetod där utvecklaren adderar extra programkod som larmar för att något måste vara fel i koden, exempelvis att parametervärden ligger utanför sina gränser. 

TILLÄGG ONSDAG 26 februari:
Under mässans första dag annonserades att DFM vinner priset Best in show i kategorin utvecklingsverktyg. 

Att använda assertions är en defensiv programmeringsstil – du accepterar som utvecklare som ett faktum att din kod kommer att innehålla misstag, och lägger till extra hängslen och livrem i form av larm som åtminstone detekterar dem. 

DFM-tjänsten bjuder även på viss analys. Tjänsten kan inte se exakt vilka fel som inträffat – det vill systemägaren kanske behålla sig för sig själv – men den kan till exempel registrera vilken typ av fel det handlar om, och ifall det inträffat förut.

– Vi kommer dessutom att utöka våra molntjänster med mer avancerad analys på sikt, som våra kunder kan dra nytta av. 

Idag stöder DFM Amazons molntjänster och Amazons operativsystem FreeRTOS. Bredare stöd är under utveckling och kan tas fram på begäran. Percepio har även börjat öppna upp för att låta andra göra egna integreringar.

Percepio sorterar in sitt nya verktyg under rubriken ”kvalitetssäkring”.

Det finns i princip alltid kvarvarande defekter eller buggar i färdig kod. Enligt en uppskattning finns var tjugonde bugg kvar efter att systemet är taget i drift.

– Detta kan innebära hundratals buggar i den levererade produkten. Man kan alltid spendera mer tid och pengar på verifiering, men insatsen som krävs för att hitta de sista buggarna ökar exponentiellt.

Istället håller man tummarna och sjösätter. Men här bjuder alltså Percepio på ett smidigt sätt att göra detta utan att överge kunden. Utvecklaren kan fortsätta detektera fel. Och sälja detta som en kvalitetssäkring som aldrig upphör.

– Traditionell kvalitetssäkring av programvara slutar ju i praktiken vid leverans, men så behöver det inte vara för uppkopplade system – utan här kan utvecklaren ta ansvar för programvarukvaliteten även efter leverans.

– Detta höjer produktens upplevda kvalitet, vilket är vad som räknas i många fall.

Att de inbyggda systemen är uppkopplade gör att deras komplexitet ökar. Samtidigt är det just via denna uppkoppling som DFM blir möjlig. 

– IoT handlar ju om att samla in data från uppkopplade produkter och detta kan även omfatta diagnostisk information, till exempel inspelningar av programvarans beteende. 

Adderar DFM-koden i sig ytterligare komplexitet till tillämpningskoden?

– DFM kräver att DFM-agenten anropas för att rapportera fel, men detta kan kopplas in i befintlig felhantering, till exempel genom att omdefiniera assertions så att DFM anropas. 

Man kan även välja att registrera ytterligare information i inspelningen, för att få ännu bättre diagnostik. Men annars så är det inget som syns i koden. 

Hur mycket overhead adderar DFM?

– Inspelningen bygger i dagsläget på kodinstrumentering, som typiskt adderar någon mikrosekunder per händelse. Typiskt lastar detta processorn med ett par extra procent, men det beror väldigt mycket på hur snabb processor man använder, hur många händelser som din applikation genererar och hur mycket din kompilator optimerar koden. 

Är det i grunden exakt samma mjukvara som snurrar i DFM som i Tracealyzer?

– Inspelningstekniken är densamma som för Tracealyzer, som har förfinats under 10 år. Specifikt  används det mycket minneseffektiva ”flight recorder”-läget, som typiskt bara behöver 4–8 byte per händelse.

Man kan inte som i normal Tracealyzer arbeta i realtid, utan bara mot en inspelning?

– Japp, för DFM handlar det alltid om offline-analys av tidigare inspelningar. Det går att streama inspelningar live över wifi, men det är inte lämpligt för detta ändamål eftersom datamängderna skulle öka dramatiskt. 

Percepio demonstreras i Embedded World-mässan i Nürnberg som startar i morgon och pågår till den 28 februari.

DFM kommer att erbjudas till utvalda pilotkunder och den färdiga lösningen kommer ut under hösten 2019.

– Den som är intresserad att utvärdera lösningen är välkommen att höra av sig!

Prenumerera på Elektroniktidningens nyhetsbrev eller på vårt magasin.


MER LÄSNING:
 
KOMMENTARER
Kommentarer via Disqus

Rainer Raitasuo

Rainer
Raitasuo

+46(0)734-171099 rainer@etn.se
(sälj och marknads­föring)
Per Henricsson

Per
Henricsson
+46(0)734-171303 per@etn.se
(redaktion)

Jan Tångring

Jan
Tångring
+46(0)734-171309 jan@etn.se
(redaktion)