Inbyggda system och elektronik står för en allt större del av tekniken i våra bilar. År 2010 kan elektroniken komma att utgöra 40 procent av materialkostnaden för en ny bil – en siffra som kan jämföras med 10 procent år 1970. Inbyggda system och elektronik ersätter eller förenklar mekaniska och hydrauliska system i kärnfunktioner, som bromsar och styrning. Vi finner dem även i nya avancerade funktioner, som aktiva säkerhetssystem och system för information till föraren. Detta ger kunderna ökad bekvämlighet, komfort och säkerhet.

Det faktum att inbyggda system och elektronik snabbt blir alltmer komplex, och samtidigt svåra att testa och verifiera har dock bidragit till ökade kvalitetsproblem och ett antal återkallanden. IBM bedömer att biltillverkarna årligen har kostnader på motsvarande 2–3 miljarder dollar för att åtgärda programvaruproblem och att 32 procent av alla bilgarantiärenden i USA gäller fel i programvara eller elektronik.

Modellbaserad design har utvecklats till en ledande metod för utveckling av inbyggda fordonssystem tack vare den förbättrade metodiken för specificering, design och implementation. Nya verktyg och funktioner för modellbaserad design bidrar till en bättre hantering av problematiken kring testning och verifiering, vilket höjer kvaliteten på de inbyggda systemen och samtidigt förkortar cykeln för testning och verifiering.

Modellbaserad design för testning och verifiering. Ingenjörerna inom fordonsindustrin använder normalt sett modeller under utvecklandet av funktioner för ECU (elektroniska styrenheter). Modellerna används på flera sätt: som grund för körbara specifikationer, för analys av systemets dynamik, för simulering av systemkomponenter och omgivningsförhållanden (så att behovet av dyra fysiska prototyper minskar eller elimineras) samt för utformning av algoritmer.

Automatisk generering av kod utifrån modellerna har också blivit ett accepterat sätt att ta fram den faktiska programvaran för en ECU. Det är rimligt att anta att detta framöver blir förstahandsvalet vid implementering av inbyggda reglersystem i många företag i bilbranschen.

Ur kvalitetssynpunkt har automatisk kodgenerering redan bidragit till mer optimerad design genom möjligheterna till analys och simulering, samt genom den reproducerbara karaktären hos automatiskt genererad kod. Dessutom går det att generera kod baserad på systemkomponents- och omgivningsmodeller för att skapa tester med befintlig hårdvara (hardware-in-the-loop).

Nu öppnar sig nya och kraftfullare möjligheter att utnyttja samma modeller på ett mer flexibelt och effektivt sätt (inklusive kravbaserad testning, täckningsanalys och testgenerering) med siktet inställt på att göra processerna för testning och verifiering av komplexa inbyggda system både snabbare och bättre, såväl i fråga om de inbyggda systemen som elektronikkomponenterna.

Krav rörande spårning och kontroll. De flesta programvaru- eller processtandarder, som exempelvis CMM-I, kräver dubbelriktad spårning mellan design och krav, genom hela utvecklingsprocessen. Det är också viktigt att den faktiska koden kan spåras till designen så att den kan granskas och verifieras. Med verktyg för modellbaserad design kan man skapa länkar mellan krav i textform, lagrade som dokument i Excel eller Word eller i specifika verktyg för kravhantering, och själva modellen (designen).

Det går att markera krav som inte uppfylls i aktuell design. På motsvarande sätt går det även att markera de enheter i designen som inte uppfyller vissa krav. Om någon ändring görs markerar verktygen vilka delar av designen som skulle kunna påverkas.
Verktyget för automatisk kodgenerering kan även infoga HTML-länkar i den färdiga C-koden, så att det blir möjligt att spåra kod tillbaka till modellen. Detta är extra värdefullt för system som direkt påverkar säkerheten. Funktionerna ger alltså fullständiga möjligheter för spårning mellan kod och krav.

Förutom länkningen mellan krav och design erbjuder verktygen för modellbaserad design funktioner som bekräftar att designen verkligen uppfyller specifika krav. Kraven infogas i designmodellen som egenskaper (eller utsagor, assertions) och algoritmerna för formella metoder utformar matematiska bevis för om egenskaperna gäller i varje möjlig situation. Om egenskapen inte skulle gälla i en viss situation skapar verktyget för formella metoder ett lämpligt motexempel. Ingenjören med ansvar för komponenten kan sedan använda det fallet i simuleringar och lägga till det i testplanen.

Stilkontroll för modeller. Under designfasen överförs en första högnivåmodell till en ny modell som kan vara en fungerande implementering och har ytterligare egenskaper som behövs i implementering, till exempel detaljinformation om talrepresentation med fast decimalpunkt och rensning av delar som inte skall ingå. På samma sätt som programutvecklare använder standardiserade riktlinjer för att underlätta läsning, testning och implementering av källkod kan ingenjörer som arbetar med modellbaserad design ta fram riktlinjer som garanterar att modellen kan implementeras och som gör det lättare att förstå och testa den.

Det finns två grundläggande metoder beroende på önskat arbetsflöde och om designen är en ny funktion eller en modifiering av en befintlig: att på förhand begränsa vilka möjligheter och alternativ som finns tillgängliga när designen tas fram, eller att i efterhand utföra kontroller för designen när den överförs.

Det första alternativet är vanligt i system som direkt påverkar säkerheten eller då man gör smärre justeringar av en befintlig implementering. I så fall läggs begränsningarna in från början i processen. I praktiken brukar man ta fram en begränsad delmängd modellkomponenter (block eller tillståndsenheter), modelltyper (anslutningar mellan block) och andra inställningar som inte behöver kontrolleras manuellt varje gång, eftersom automatiserade verktyg kan göra det systematiskt.

Med det andra arbetssättet sker kontrollen gentemot riktlinjerna senare i utvecklingsprocessen. Fördelen med att vänta är att man i en tidig fas kan ha helt fria händer, för att sedan steg för steg ta hänsyn till relevanta begränsningar och skapa en robust och testbar implementation. Helst ska modellen kontrolleras i den miljö där den skapas, så att utvecklaren snabbt kan markera problem och redigera designen effektivt med ett iterativt arbetssätt.

Det finns nya verktyg på marknaden som hjälper utvecklingsteam att definiera och anpassa regler för modellkontroll, tillämpa dem på modeller och direkt hantera avvikelser.

Analysera och garantera modellens täckning. Genom modellen kan man tidigt i designprocessen, före implementeringen, göra vissa tester som annars skulle göras senare genom källkodstestning. Ingenjörerna kan belasta styrenheten maximalt för att kontrollera designens egenskaper och avslöja eventuella problem, exempelvis outnyttjade delar som senare skulle leda till kod som aldrig användes eller kontrollerades.

Det är vanligt att ingenjörerna kör omfattande modellsimuleringar för att kontrollera att en design fungerar korrekt och är robust. Simuleringsresultaten är emellertid bara relevanta om man lyckas hitta lämpliga förhållanden att simulera.

Specifikt kan belastningstest av modellen i simuleringar med absolut högsta och lägsta möjliga värde för olika numeriska parametrar bidra till att minska eventuellt beräkningsspill. Det är även viktigt att säkerställa att simuleringarna gör ett heltäckande test av designen, inklusive alla tillstånd och logiklägen som ingår i designens funktionsmodell.

Genom en modelltäckningsanalys utvärderar man det sammantagna resultatet från en testsvit och fastställer vilka block eller tillstånd som nåddes under simuleringen, och vilka som missades. Vissa typer av täckningsanalys har blivit väletablerade i programmeringsspråk som C, C++ och Ada, men motsvarande analystyper har först på senare tid blivit tillgängliga på modellnivå.

Det amerikanska luftfartsverket FAA anser att MC/DC (Modified Condition/
Decision Coverage) är den mest stringenta täckningsnivån och ett krav i säkerhetskritiska system. Denna typ av täckningsanalys kan nu – tillsammans med flera andra typer – utföras inom modellbaserad design, med simuleringskörningar som grund. När detta görs inom simuleringsverktygen går det att använda automatisk loggning och rapportering av modellens täckningsresultat. Testingenjören ser då hur väl testfallen motsvarar designens struktur. Sedan kan man fokusera på att ta fram testuppsättningar som når fullständig täckning.

Automatiskt genererade tester. Nya verktyg för modellbaserad design klarar att automatiskt generera testmönster som uppfyller önskade täckningsmål, exempelvis MC/DC, genom att göra en matematisk analys av modellens struktur och skapa målen baserat på formella metoder. Strukturanalysen kan också identifiera delar av modellen som aldrig körs. Ett sådant tillstånd kan tyda på brister i specifikationen, implementeringen eller testutformningen.
Det går sedan att kombinera testmönstren med andra testfall baserade på kraven, testmiljödata, Monte Carlo-fall och anläggnings- eller omgivningsmodeller för att simulera modellen fullständigt, och senare använda testerna med den faktiska implementeringen.

Kontroll av regeluppfyllande för kod. Misra (Motor Industry Software Reliability Association) har tagit fram ”Guidelines for the Use of the C Language in Vehicle Based Software”. Dessa riktlinjer, som ibland informellt kallas MISRA-C, används nu av allt fler inom fordonsindustrin. Relevanta modellkontroller som täcker en stor del av kraven för att uppfylla MISRA-C kan baseras på kontroller av de mönster den automatiska kodgenereringen använder, i stället för en fullständig kontroll av all kod, vilket skulle krävas för manuellt skriven kod.
Det räcker dock inte alltid att kontrollera verktyget för kodgenerering, eftersom det exempelvis kan finnas handskriven äldre kod som har importerats. Öppna modellgränssnitt gör det möjligt att ordna automatiska kontroller för sådana fall. Med den här metoden görs kontrollerna efter att modellen har skapats, och innan koden genereras, för att garantera att den importerade eller genererade koden uppfyller alla krav. Ett annat alternativ är att inkludera ett verktyg för kodkontroll enligt MISRA-C eller statisk analys i processen för kodgenerering och byggande.

Identifiera körfel (runtime errors). Det kan vara synnerligen svårt att identifiera körfel på modellnivån eller under simuleringar och felen kan leda till stora problem under utveckling och testning av ny programvara. Körfel är latenta fel som ofta enbart visar sig med specifika kombinationer av datavärden, vilket gör det svårt och dyrt att hitta dem under dynamisk testning. De upptäcks därför i allmänhet genom sin påverkan på funktionen, exempelvis oväntade kommandon till styrenheter, stopp i flyttalsenheter eller oförklarliga programvarufel som är svåra att reproducera. I sådana situationer behövs ofta ett långt och krävande felsökningsarbete för att spåra problemet till källan.

Statisk analys är en metod som kan identifiera körfel. På senare år har det lanserats statiska verifieringsverktyg som använder teknik för avancerad statisk analys och minskar antalet ”falskt positiva” resultat som kräver manuell kontroll eller testning. Denna typ av verktyg utför statisk och delvis dynamisk analys av C-koden, helt oberoende av om koden har skrivits för hand eller genererats automatiskt.

Möjligheten att integrera sådana verifieringsverktyg med verktyg för modellbaserad design kan förbättra arbetsflödet betydligt. Genom att koppla analyserad kod till modellen som den automatiskt genererades från, kan verktyget för statisk verifiering presentera resultatet både i källkoden och i modellen. Att kunna navigera från kod till modell, göra en ändring och sedan automatiskt generera och kontrollera koden på nytt är ett kraftfullt sätt att analysera, felsöka och modifiera algoritmer med hjälp av både högnivåperspektiv och ett detaljerat perspektiv. Det främjar en utvecklingsprocess där ändringarna görs i modellen i stället för direkt i koden, vilket bidrar till modellernas livslängd och återvinning.

Slutord. Huvudpunkterna i den här artikeln är de tre steg som rekommenderas för att utnyttja modellbaserad design för testning och verifiering.

Steg ett är att återanvända modeller som testmiljö för implementering. Genom att köra modellsimuleringar, eller köra den implementerade programvaran länkad till modellerna eller köra den på en värddator eller målprocessor eller köra hela det inbyggda systemet i en testmiljö, blir helhetsbilden bättre. Testdata och annan information kan sedan utnyttjas under utveckling och testning.

Steg två är att se till att testa så tidigt som möjligt. Testa i simulering före realtidstester, testa i realtid i artificiell miljö före verkliga tester och testa modellen innan koden testas. Tidiga tester är ofta enklare, med en högre abstraktionsnivå. Fördelarna med att tidigt identifiera fel är tydligt dokumenterade.

Steg tre är att utnyttja alla tillgängliga tekniker. Simuleringar och formella metoder kan komplettera och förstärka varandra. Detsamma gäller modellbaserad och kodbaserad teknik för testning och verifiering. Samtliga metoder kan utnyttjas med modellbaserad design med verktyg från flera leverantörer.