TEMA: AI & INBYGGDA SYSTEM
Percepio i Västerås sedan 2024. Han har en civilingenjörsexamen i Teknisk fysik med systemutveckling och har arbetat inom svensk mjukvaru industri med global marknad, i olika kommersiella och ledarskapsroller, bland annat på IAR Systems och Imint Vidhance, ett programvarubolag inom videoanalys och förbättring.
IKEL
Andreas Lifvendahl är VD för
PE R
Andreas Lifvendahl har även styrelse uppdrag i andra innovationsbolag, samt i Uppsala Innovation Center, Uppsalas innovationsinkubator.
O
bserverbarhet kan definieras som ”förmågan att mäta ett systems inre tillstånd genom att observera vad som kommer ut ur det”. För programvarusystem handlar det om att samla in detaljerad information under körning, som till exempel loggfiler, data från programspårning, och minnesdumpar. 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,
22
R TA T
Av Andreas Lifvendahl, Percepio
EX
Kontinuerlig observerbarhet
Kontinuerlig observerbarhet knyter samman information från utvecklingslabb, kvalitetskontroll och driftövervakning.
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 nativemiljö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 trig-
gas 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
ELEKTRONIKTIDNINGEN 10/24