Ladda ner artikeln här (länk, pdf). Fler tekniska rapporter finns på etn.se/expert

Observerbarhet under utvecklingsfasen löses traditionellt genom att utvecklarna pluggar in olika felsöknings- och loggfunktioner när de stöter på ett problem. Det är ett reaktivt arbetssätt som förutsätter att eventuella problem kan detekteras på annat sätt, men det är inte till mycket hjälp mot de svåraste problemen, de som bara uppträder sporadiskt och ofta är svåra att reproducera. Rena debug-verktyg är inte heller särskilt användbara för problem som uppträder efter att produkten har lämnat utvecklingsstadiet.

För oss innebär kontinuerlig observerbarhet ett proaktivt arbetssätt, där datainsamlingen som standard är påslagen och pågår kontinuerligt, och där avvikelser rapporteras automatiskt. På det sättet säkerställs att dia­gnostikdata alltid är tillgängliga när ett problem dyker upp.

Kontinuerlig observerbarhet innebär också att man systematiskt observerar utvecklingen under en produkts hela livscykel, från tidig programutveckling över integrationstester och systemtester ända till driftsatta enheter i fält. Det kan kombineras med auto­matiserad övervakning för att upptäcka ­dolda fel, prestandaproblem och andra avvikelser så snart som möjligt.

Övervakning och rapportering lämnas med fördel aktivt även i driftsatta produkter, för att underlätta diagnostisering av rapporterade problem hos kunderna. Det ger också möjlighet att upptäcka och analysera systemavvikelser för att hitta grundorsaken.

Ta till exempel en observation att processorlasten ökar i många enheter ungefär samtidigt – det kan vara ett bagatellartat problem, men det kan även vara ett första tecken på en pågående cyberattack mot ­företagets IT-infrastruktur. Utan kontinuerlig och systematisk observerbarhet kan den typen av attacker pågå under lång tid utan att uppmärksammas.

Den närbesläktade idén om observerbarhetsdriven utveckling (ODD) formulerades från början i den så kallade cloud native-miljön (utveckling av programvara som från grunden är avsedd att köras i en distribuerad molnarkitektur) och poängterar också vikten av att proaktivt bygga in observerbarhet från början samt att utnyttja observerade data under systemtestfasen. De tankarna kan precis lika bra appliceras på inbyggnadssystem.

Inbyggda system blir alltmer komplexa
För några decennier sedan hade de flesta inbyggnadssystem ett enda jobb, att köra samma kod om och om igen i en evig loop. Mer komplexa system byggdes genom att man satte samman flera hårdvarumoduler, och den observerbarhet som erbjöds var att plugga in ett instrument och logga det som sändes på databussen. Idag har den enklaste mikroprocessor flera processorkärnor, samtidigt som det finns väldigt begränsade möjligheter att observera på hårdvarunivå. Dessutom kan varje kärna vara ansvarig för en bukett programvarufunktioner som triggas asynkront och exekverar på olika trådar, vilket lätt leder till oförutsägbara variationer i exekveringstid. Förr eller senare nås också den punkt där det inte längre är realistiskt att testa alla möjliga scenarier.

Till skillnad från många andra teknikområden är programutveckling sällan klar bara för att produkten har skeppats. Alla kända fel och buggar må vara lösta men utvecklarna kan normalt se fram emot en lång svans av problem som inte visar sig förrän systemet är driftsatt. Koden i inbyggda system innehåller typiskt omkring tre fel per 1 000 rader kod.

Med extern konnektivitet ökar komplexiteten ännu mer, och dessutom kan det exponera systemet för cyberhot utifrån. Å andra sidan kan konnektivitet också vara ett effektivt botemedel: för det första möjliggör det uppdateringar over-the-air (OTA), så att man kan korrigera fel i programvaran, och för det andra möjliggör det observerbarhet under drift så att utvecklarna kan upptäcka och analysera anomalier på distans. Den kombinationen ger helt nya förutsättningar att hantera komplexiteten.

Software-Defined Vehicles, ett lysande exempel
Software-Defined Vehicles (SDV) är ett nytt begrepp som driver många förändringar när det gäller utveckling av inbyggda system. I ett traditionellt fordon är varje elektronikmodul självständig, avgränsad och rigoröst testad och validerad att den lever upp till strikta funktionskrav. SDV vänder på arkitekturen och sätter istället programvaran i centrum, så att funktioner implementeras i programvara snarare än att vara knutna till en specifik hårdvarumodul. Finesser som OTA-uppdatering, dynamisk aktivering och deaktivering av olika funktioner, och konstant uppkoppling är bara möjliga i ett SDV. Inte lika robust, men erbjuder å andra sidan mer flexibilitet och möjlighet till snabba anpassningar.

Det är mot den här bakgrunden som kontinuerlig observerbarhet kan visa sitt värde. Med kontinuerlig insikt i hur system uppträder i realtid kan utvecklare lättare försäkra sig om att uppdatering av programvara eller konfigurationer inte slår ut kärnfunktioner som säkerhet eller prestanda. Kontinuerlig observerbarhet tjänar som en garant för användarnas förväntningar på pålitlighet och säkerhet.

SDV-trenden, om vi kan kalla den så, kan för övrigt observeras även inom andra industrier, som medicinteknik och rymd/flygteknik. Även där definieras numera många funktioner I programvara och kontinuerlig observerbarhet kommer bli ett nödvändigt verktyg för att hålla ordning på systemhälsa och -integritet.

Nästa steg är observerbarhetsdriven utveckling
Observerbarhetsdriven utveckling, ODD, är som tidigare nämnts nära besläktat med kontinuerlig observerbarhet, och kan beskrivas som en strategi för att hantera växande komplexitet inom inbyggnadssystem. ODD passar också väl ihop med Percepios idéer kring observerbarhet: observation integreras i varje steg i utvecklingscykeln och ger realtidsinsyn hela vägen från tidig programutveckling till driftsatta system, med programvaruspårning som det enskilt viktigaste verktyget. ODD kan utvidgas till att också omfatta övervakning av nyckelparametrar, så att systemen i någon mening blir självmedvetna och kan slå larm om något parametervärde sticker ut för mycket. Proaktiva larm när ett system närmar sig kritiska gränser kan potentiellt spara enorma summor genom att man undviker fel och minskar eventuell nertid hos kunderna.

I branscher där kostnaden för fel är hög – återigen är fordon, medicinteknik och rymd/flyg bra exempel – erbjuder ODD ett ovärderligt extra lager av säkerhet. Dessutom får utvecklarna den insyn de behöver för att bibehålla kontrollen över sina produkter oavsett hur ofta programvaran behöver uppdateras.

Dyrbara misstag
Ett uppmärksammat exempel på dyrbara misstag är den biltillverkare som tvingades återkalla en miljon bilar som tillverkats under 2020 till 2022 på grund av ett fel i samspelet mellan programvara och sensorer, som potentiellt kunde påverka om krockkudden utlöstes eller ej. Felet upptäcktes inte under testning och det blev dyrbart inte bara i ren kostnad för att fixa bilarna utan också för att det gav en negativ bild av företaget. Ett annat exempel involverade ett medicintekniskt företag vars insulinpumpar fick dras tillbaka 2018 efter att man hade upptäckt en sårbarhet som kunde tillåta en angripare att kontrollera pumpen via dess fjärrkontroll.

Så sent som i år upptäcktes en bakdörr i XZ Utils, ett vida spritt Linuxverktyg för komprimering, som kunde ha gett en angripare tillgång till miljontals Linuxdatorer världen över om den hade hunnit spridas i större skala. Den sårbarheten illustrerar en ny, stor attackyta, nämligen skadlig kod i öppen källkods-moduler, men det mest intressanta i det här sammanhanget är hur den upptäcktes. Av en händelse satt en utvecklare på Microsoft och mätte exekveringstider när bakdörren smögs ut i en uppdatering av XZ Utils, och han noterade att vissa anrop plötsligt tog mångdubbelt längre tid. Den sortens mätningar görs sällan som standard, men med kontinuerlig observerbarhet kan de automatiseras och mätvärdena sparas i en databas för att underlätta att hitta oväntade förändringar.

Den gemensamma nämnaren i dessa exempel är insikten att traditionella metoder för test och felsökning inte längre räcker till i ljuset av komplexiteten i dagens uppkopplade och programkodsstyrda enheter. Buggar i programkod är inte bara ett irritationsmoment; de har påtagliga och ibland mycket kostsamma konsekvenser. Hade företagen i exemplen tillämpat ODD och kontinuerlig observerbarhet kunde de ha identifierat och löst problemen mycket tidigare, utan stora förseningar och återkallande av redan sålda enheter.

Vänta inte
ODD kräver en förskjutning till vänster i tidsskalan, så att observerbarhet läggs till från början för att stödja de följande faserna i produktutveckling och underhåll. Det är alltså inte bara en angelägenhet för QA- och testteamen utan också för att bygga en konkurrenskraftig produktutvecklingsorganisation. Det finns ingen anledning att vänta med att införa metoden.