Användningen av exekverbara modeller för att simulera och designa inbäddad programvara för fordonssystem är väl etablerad inom fordonsindustrin och allt oftare utnyttjas samma modeller för att automatiskt generera programvarukomponenter. Idag ligger värdet av dessa modeller för testning, verifiering och validering av programvara vanligtvis i HIL-simulering (Hardware-In the-Loop). Jim Tung från the MathWorks beskriver här nya och förbättrade metoder att använda modellerna i test och verifiering, både för programvara och elektroniska komponenter.

Hela artikeln i PDF-format.

Det påpekas ofta att elektronik och programvara utgör en växande och allt viktigare del av en bil och dess utveckling baserat på utvecklingskostnader, materialkostnader, kundens värdeupplevelse och andra mätvärden.

1970 utgjorde elektroniken 10 procent av ett fordons materialkostnad och år 2010 förväntas elektroniken utgöra 40 procent av materialkostnaden [i]. Enligt Strategy Analytics [ii] har ”uppskattningar inom branschen visat att kostnaderna i samband med utveckling av fordonsprogramvara utgjorde ungefär 4 procent av fordonets totala kostnad år 2002. Det förväntas stiga till 13 procent år 2010.

Samtidigt förknippas elektronik och programvara med kvalitetsproblem. IBM Corporation noterar [iii] att ”biltillverkare spenderar mellan 2 och 3 miljarder dollar om året på att korrigera programvaruproblem” och att ”32 procent av alla garantireparationer av bilar i USA gäller programvaru- eller elektronikrelaterade problem.”

Tillämpa modeller
Fordonsingenjörer bemöter dessa utvecklingsutmaningar genom att i allt högre grad använda sig av modeller för att konstruera, designa och analysera funktioner som ska köras på en ECU. De upplever förbättrade resultat i designeffektivitet, innovation och kvalitet för användarkonferenser [iv], SAE-konferensartiklar [v] och andra sammanhang. Vidare har automatisk kodgenerering från dessa modeller blivit ett accepterat sätt att implementera ECU-programvara i produktionen och, under de kommande åren, förväntas det bli den primära metoden för implementerad inbäddad styrprogramvara inom många bilföretag. Modellerna används på flera olika sätt inom modellbaserad design:
• i simuleringar som ger insikter i systemets dynamiska och algoritmiska aspekter
• som exekverbara specifikationer
• för kommunikation av krav mellan OEM och leverantör
• för att skapa virtuella prototyper av fordonssystem och modeller av förare, vägförhållanden och andra miljöförhållanden för utveckling av algoritmer
• för automatisk kodgenerering för produktions-ECU:er
• att definiera och programmera beteendet för HIL-testsystem (Hardware-In-The-Loop).

Nya utvecklingar höjer dock ständigt ribban för utmaningen. Aktiva säkerhetsteknologier, telematik och förarinformationssystem ökar mängden programvara och elektronik. De kräver dessutom ofta specialanpassning till kommunikationsprotokoll och standarder för konsumentelektronik, som ofta förändras mycket snabbare än de typiska utvecklingsprocesserna inom fordonsindustrin eller, som fallet är med radar och andra teknologier, kanske inte är så välbekanta för fordonsingenjörer. Implementeringen av de inbäddade funktionerna kan bestå av programvara (som körs på styrprocessorer eller DSP-kretsar), maskinvara (som t ex ASIC, PLD, etc) eller en kombination av båda delarna.

Samtidigt som dessa områden utlovar bättre värde för kunden i vad beträffar bekvämlighet, komfort och säkerhet så gör de systemutvecklingen mer komplicerad (både för fordonet och när det gäller att koppla fordonet till andra system). De här trenderna gör att test- och verifieringstekniken blir allt viktigare.

De modeller som används i modellbaserad design har haft avgörande betydelse för testmetoder som t ex Hardware-In-the-Loop-, Processor-In-the-Loop- och Software-In-the-Loop-simulering. Nu utvecklas och kombineras nya framväxande testmetoder som utnyttjar dessa modeller och i betydande grad förkortar och förbättrar utvecklingscykelns test- och verifieringsstadier i tillägg till de befintliga fördelarna med simulering och automatisk kodgenerering. I vissa fall kommer dessa metoder från flygindustrin, trådlös kommunikation och andra branscher med likartade metoder för modellbaserad design, men de är samtliga mycket relevanta och tillämpningsbara för bilindustrin.

Modell- och kodbaserade metoder
På grund av kostnaden och svårtillgängligheten för fysiska prototyper är det praktiskt att testa modellen på en arbetsstation innan den installeras på en ECU för bygge och integrering. Källkodsbaserad testning har använts i många år, men med hjälp av nya metoder kan man nu använda modelltestning och strukturell täckning.

Användningsscenariot är att en utvecklare till fullo belastar styrenheten för att verifiera dess designintegritet med hjälp av simulering och täckningsanalys. Exempel på undermålig designintegritet inkluderar numeriskt spill och/eller död kod. Genom att belastningstesta modellen med numeriska minimi- och maxvärden går det att se till att spillförhållanden inte uppstår. Den här typen av testning är enkel att genomföra med simulering men det är inte så enkelt att identifiera död kod eftersom det kräver strukturell täckning. Död kod skiljer sig från deaktiverad kod genom att den senare är känd av utvecklaren och har deaktiverats i ett specifikt syfte. Död kod innebär att någonting missades under specifikation, implementering eller skapandet av testet.

Därefter används modellutsagor för att avgöra om testet klaras eller ej. Utsagorna associeras med modellsignaler och gör det möjligt för testingenjörerna att specificera de förväntade resultaten. Om en signal överskrider sitt gränsvärde under en simulation eller ett test aktiveras en utsaga som antingen stoppar exekveringen eller spelar in den för senare analys.

Modelltäckning utvärderar det kumulativa resultatet av en testsvit och fastställer vilka block eller tillstånd som exekverades eller inte. Vissa täckningsanalyser är väl etablerade i källkodsspråk som C, C++ och Ada men de typerna av analys fanns tills nyligen inte tillgängliga på modellnivå [vi].

MC/DC (Modified Condition/Decision Coverage) anses av FAA (Federal Aviation Administration) vara den mest stringenta täckningsnivån som krävs för säkerhetskritiska system [vii]. Den här täckningsanalysen finns nu tillsammans med andra tillgänglig inom modellbaserad design och utförs baserat på simuleringar. När detta görs inom simuleringsverktygen går det att använda automatisk loggning och rapportering av täckningsmätvärdena för modellen (fig 1).

En viktig aspekt av modelltestning och strukturtäckning är definitionen av lämpliga testmönster som omfattar alla aspekter av modellen och koden som genereras från modellen. Många av dessa testmönster identifieras interaktivt under modellutvecklingen och från krav. Andra testmönster, särskilt för täckning, kan genereras automatiskt genom att analysera modellen. I dagsläget använder olika verktyg [viii] olika metoder som alla har sina egna styrkor och svagheter. Gemensamt för dem alla är dock att de automatiserar en tröttsam process som lätt introducerar fel. Idealiskt kan de här testmönstren köras i modellmiljön, med ett HIL-system, på testbädden och i fordonet för att visa om implementeringen genom hela utvecklingen uppför sig som referensdesignen. För algoritmutvecklare och systemingenjörer är den här modelltestningen och strukturtäckningen ett kraftfullt verktyg som kan användas tidigt i processen. Det finns dock en särskild kategori fel som kan vara svåra att upptäcka via simulering och som kan orsaka betydande problem under programvaruutveckling och -testning: runtime-fel. De är problematiska av flera anledningar [ix]:¨

• Runtime-fel är latenta fel som ofta dyker upp under extremt specifika kombinationer av datavärden vilket gör det mycket kostsamt att hitta dem med hjälp av dynamisk testning. Det indikerar att man utförligt bör testa alla kombinationer av värden, vilket inte är möjligt.

• Runtime-fel kan inte enkelt associeras med koden med hjälp av dynamisk testning. De upptäcks i själva verket i allmänhet genom de konsekvenser eller funktionella beteenden de ger upphov till, inklusive oväntade kommandon till ställdon, stopp i matematisk hjälpprocessor samt oförklarliga programvarufel som är svåra att upprepa. Omfattande avlusning krävs sedan för att spåra problemet till källan.

• Om runtime-fel upptäcks under testet antyder det en exponentiell ökning av avlusningsarbetet. Att hitta och avlusa ett spill från en krasch i en motorstyrenhet under ett systemtest är mödosamt, tidskrävande och ett exempel på den arbetsinsats som krävs för att lösa problemet med dynamisk testning.

• Runtime-fel inverkar ofta negativt på funktionstester. Om ett sådant fel hittas under testningen måste det korrigeras och regressionstestning utföras för att se till att felet inte dolde andra fel eller att lösningen orsakade ett problem någon annanstans. Med andra ord innebär att ett testscenario som har GODKÄNTS kan UNDERKÄNNAS senare om ett runtime-fel upptäcks och korrigeras.

• Runtime-fel utgör 30-40 procent av de fel som upptäcks vid underhåll.

Statisk analys
Statisk analys är en metod som många programutvecklare är bekanta med. Men många leverantörer av kodbaserade verktyg medger [xi] att traditionell statisk analys utlovade betydande tidsbesparing när det gäller testtid och kostnader men inte kunde uppfylla de löftena fullt ut av två orsaker:

• För det första att antalet ”falska positiva” meddelanden i allmänhet är för stort vilket kan slösa bort dyrbar programmeringstid.

• För det andra för att traditionella, statiska analysverktyg inte är fullständiga till sin natur. Koden måste fortfarande inspekteras eller testas för att se hur robust den är eftersom den innehåller en mängd ”falska negativa”.

Under de senaste åren har statiska verifieringsverktyg [xii] som använder avancerade statiska analysmetoder introducerats med förbättrade möjligheter att reducera både ”falska positiva” och ”falska negativa”. Sådana verktyg utför statisk analys på C-kod. Analysen är densamma oavsett om koden är handskriven eller genererad automatiskt. Men integreringen av dessa verktyg i modellbaserade verktyg förbättrar arbetsflödet betydligt.

Genom att koppla den analyserade koden till modellen som den automatiskt genererades från kan det statiska analysverktyget presentera resultatet både i källkoden och i modellen. Att kunna navigera från koden till modellen, göra en ändring och sedan automatiskt generera och kontrollera koden på nytt är ett kraftfullt sätt att analysera, avlusa och modifiera algoritmer med hjälp av både högnivåperspektiv och detaljerat perspektiv. Det främjar en utvecklingsprocess där ändringarna görs i modellen istället för direkt i koden vilket bidrar till modellernas livslängd och återvinningsbarhet från projekt till projekt. Den här möjligheten kan även hantera arbetsflöden med integrering av olika kod som t ex:

• när automatiskt genererad kod och handskriven kod integreras i slutet av processen
• när handskriven kod kapslas in i modellen och sedan integreras i kodgenereringsprocessen

Systemingenjören och programmeraren kan se resultatet i det modellerings- eller kodsammanhang som de är vana vid och ändå kommunicera med varandra eftersom testresultaten är desamma. Det gör att varje team kan arbeta med verktyg som de redan är vana vid vilket leder till mer tillförlitliga resultat och mer effektiv användning.

Modellkontroll och egenskapskontroll
Formella metoder, som integreras sömlöst i designmiljön, har också potential att tillhandahålla avancerad avlusning och modellkontroll som gör det möjligt för ingenjören att skapa en design som har större chans att fungera från början. Formella och matematikbaserade metoder kombineras med empiriska och simuleringsbaserade metoder för att validera om en designspecifikation uppfyller kraven. Befintliga verktyg som tillämpar formella metoder i modellbaserad design är i viss utsträckning lovande men der återstår mycket forskningsarbete på det här området.

Kravspårning
De flesta programvaru- eller processtandarder, som t ex CMM-I, kräver dubbelriktad spårning av, som kanske kommer från andra kravverktyg, genom hela utvecklingen. Det är också viktigt att koden kan spåras till diagrammet så att den kan granskas och verifieras. De nedskrivna textkraven kan spåras till modellen och sedan kan C-koden spåras tillbaka till modellen. Dessa funktioner tillhandahåller tillsammans en komplett spårningssökväg från koden till kravet (fig 2). Ännu viktigare är att dessa funktioner hjälper till att bekräfta att modellen uppfyller kraven. Nästa steg i spårningssökvägen är att visa att koden kan spåras tillbaka till modellen. Det är särskilt viktigt för säkerhetskritiska system. Kodgenereringsverktyg för produktion prioriterar tydlig kod, till skillnad från kodgenereringsverktyg för snabbprototyper. Ett exempel på det är att inkludera HTML-länkar i den genererade C-koden som markerar den eller de block i källkoden som koden genererades från.

De modeller som används för att designa och implementera inbäddade system genomgår en serie av omvandlingar - en del mindre, andra mer betydande - under utvecklingsprocessen. Inledningsvis kan modellen fungera som en exekverbar specifikation eller algoritmbeskrivning för systemingenjören eller algoritmutvecklaren. Senare kan modellerna fungera som en beskrivning av hur algoritmen ska delas upp i program- och maskinvaruimplementationer. De framväxande modellerna fungerar nu som utgångspunkt för programmering tack vare den automatiska genereringen av inbäddad kod. De kan också fungera som utgångspunkt för vissa aspekter av maskinvarudesign tack vare möjligheten att generera FPGA-design från de modellerna. När modellerna närmare sig implementeringsfaserna vill utvecklare annotera och omvandla modellerna, lägga till begränsningar för systembeteende, beskriva egenskaper som krävs för implementering (som t ex fixpunktsinformation) eller länka komponenter i designen till de relevanta delarna av krav- och specifikationsdokumentationen. Det har beskrivits i andra artiklar [xiii]. Dessa omvandlingar av modellen kan dock även tillhandahålla en möjlighet att begränsa designen på ett sätt som gör implementeringen enklare att testa och verifiera.

I vissa fall har företag som använder modellbaserad design, särskilt inom flyg- och fordonsindustri, samarbetat och definierat gemensamma modellriktlinjer och bästa praxis [xiv]. Dessa stilriktlinjer har sedan skräddarsytts av individuella organisationer (och ibland specifika utvecklingsteam som jobbar med en typ av tillämpning) för att se till att designen är säker, komplett, otvetydig och lämplig för inbäddad kodgenerering.

Det finns två grundläggande metoder beroende på önskat arbetsflöde, om designen är en ny funktion eller en modifiering av en befintlig funktion och vad utvecklingsteamet föredrar.

I den ena metoden tillämpas begränsningarna a priori genom att ge designern en begränsad palett med auktoriserade block (som i själva verket kan vara komponenter eller delsystem) att använda. Det kan vara särskilt lämpligt för säkerhetskritiska system eller en design som utgör en mindre modifiering av en befintlig implementering.

Detta fungerar hand i hand med ett processteg för att fastställa typerna av modellkomponenter (block eller tillstånd), modellkonstruktioner (hur blocken är sammankopplade), komposition och andra inställningar (t ex fixpunktaspekter) som blir ett begränsat delsystem av designen som inte behöver kontrolleras varje gång eftersom det kontrollerats systematiskt. Självklart går det även att inkludera designkomponenter som ligger utanför det definierade delsystemet. De tilläggskomponenterna måste då kontrolleras för konsekvens och förutsägbarhet varefter de kan tillämpas i one-off-designen eller läggas till det begränsade delsystemet.

I den andra metoden tillämpas begränsningarna mitt i processen eller a posteriori genom att låta designern använda en större palett med block och sedan kontrollera modellen och se till att den följer en given uppsättning regler eller riktlinjer. Helst ska modellen kontrolleras i den miljö den skapas i så att utvecklaren snabbt kan markera problem och redigera modellen på ett effektivt och iterativt sätt. Nyligen har verktyg lanserats som hjälper teamet att definiera sina egna regler, tillämpa dem på modeller, markera undantag och gå direkt till modelleringsmiljön för att lösa undantagen.

Kontroll av kodkompatibilitet - (MISRA)
MISRA (Motor Industry Software Reliability Association) publicerade för första gången ”Guidelines for the Use of the C Language In Vehicle Based Software” i april 1998 och uppdaterade den senare med ”MISRA-C:2004-Guidelines for the use of the C language in critical systems” [x] i oktober 2004. MIS-RA-C används av ett ökande antal billtillverkare och underleverantörer.

En betydande del av modellkontrollarbetet, t ex för MIS-RA-C-kompatibilitet, kan utföras genom att se på vad det automatiska kodgenereringsverktyget systematiskt genererar istället för att se på varje bit genererad kod baserat på antagandet att varje kodsegment har oförutsedda variationer vilket innebär att varje fall måste utvärderas. MIS-RA-C är dock fortfarande viktigt i minst två scenarier som kan förekomma vid modellbaserad design:

• Import av eller gränssnitt mot äldre, återanvänd kod som bryter mot en eller flera regler
• Medvetna eller oavsiktliga ändringar i inbyggd kodgenereringsinställning leder till överträdelser.
Öppna modellgränssnitt gör det möjligt att skriva sådana kontroller. Koden körs sedan på en given modell. Med den här metoden görs kontrollerna efter att modellen skapats och innan koden genereras för att se till att koden klarar kontrollen.

Ett annat alternativ är att inkludera en MISRA C-kodkontrollerare eller statisk analys i kodgenererings- och byggprocessen. Det är också möjligt tack vare användning av öppna Apirer och Hood-funktioner i byggprocessen.

Av dessa och andra orsaker är det lämpligt att lägga till ett kodbaserad kontrollverktyg till den modellbaserade designmiljön med verktyg som t ex Splint. [xvi] [xvii]

Lösningar för maskinvara
Som vi nämnde tidigare kan implementeringen av de inbäddade funktionerna bestå av programvara (som körs på t ex styrprocessorer eller DSP-kretsar), maskinvara (som t ex ASIC, PLD, etc) eller en kombination av båda.

Valet att implementera i programvara eller maskinvara, och ofta en kombination av båda delarna, är aktuellt särskilt ofta för nya teknologier, som t ex aktiv säkerhet, telematik och andra områden. Det här valet (som har konsekvenser för design, implementering och testning) har redan bemötts i branscher som hemelektronik och kommunikation och metoder från de branscherna är även relevanta för fordonsindustrin. Exempelvis kan designflödet för maskinvara, inklusive både digital och A/MS-maskinvara (Analog/Mixed-Signal), från traditionella EDA-verktygsleverantörer (Electronic Design Automation) som t ex Cadence och Mentor Graphics integreras i metoder för modellbaserad design för att möjliggöra både uppifrån-och-ner- och nerifrån-och-upp-arbetsflöden för design och verifiering mot en referensmodell.

Vidare kan maskinvarudesignkomponenter (FPGA [xviii], ASIC, A/MS-kretsar [xix]) kopplas tillbaka i en systemmodell som fungerar som en virtuell testbädd och hjälper till att markera potentiella integreringsproblem som uppstår innan tid och arbete slösas bort på implementering. Det gör det även möjligt att återanvända validerade komponenter så designen oftare återanvänder stabila komponenter istället för att införa okända attribut som kan förstås.

Idag kan verktyg integreras som verifierar beteendet för diskreta maskinvarudesigner (i form av VHDL eller Verilog) för kretsmodeller eller andra systemkomponenter [xx]. Dessutom kan modeller för ställdon och sensorer, representerade som analoga och A/MS-kretsar utvärderas på samma sätt.

På det viset kan de modeller som skapats för utveckling av inbäddad programvara också användas (i vissa fall med smärre justeringar) för olika typer av maskinvaruimplementeringar.

Jim Tung, The Mathworks, © 2005 SAE International

Referenser
[i] Automotive Engineering International, mars 2005.
[ii] Strategy Analytics, forskningsrapport, december 2003, www.strategyanalytics.net.
[iii] S. Stefanis, IBM Corporation, i Detroit News, 18 maj 18, 2005.
[iv] Användarpresentationer från MathWorks Automotive Conferences finns tillgängliga på: www.mathworks.com/industries/auto/iac
Användarpresentationer från flera konferenser om modellbaserad design finns tillgängliga på: www.mathworks.de/company/events/mbd www.mathworks.co.uk/company/events/mbd www.mathworks.fr/company/events/mbd
[v] G. Hodge, J. Ye, W. Stuart, ”Multi-Target Modelling for Embedded Software Development for Automotive Applications,” Artikel 2004-01-0269, 2004 SAE World Congress.
[vi] B. Aldrich, ”Using model coverage analysis to improve the controls development process,” AIAA 2002.
[vii] Ibid.
[viii] Exempel på verktygsleverantörer på det här området inkluderar Reactive Systems (www.reactive.com), T-VEC Technologies (www.t-vec.com) och TNI Software (www.tni.com).
[ix] (C. Hote, ”Advanced Software Static Analysis Techniques That Provide New Opportunities for Reducing Debugging Costs and for Streamlining Functional Tests”, opublicerad.
[x] M. Sullivan och R. Chillarege, Software defects and their impact on system availability, proc. 21thInternational Symposium On Fault-Tolerant Computing (FTCS-21), Montreal, 1991, 2-9, IEEE Press.
[xi] Se not 9.
[xii] Ett exempel är PolySpace för modellbaserad design (www.polyspace.com).
[xiii] T. Erkkinen, ”Production Code Generation for Safety-Critical Systems,” teknisk artikel, 2004 SAE World Congress.
[xiv] T ex MAAB Controller Style Guidelines (The MathWorks).
[xv] ”MISRA-C:2004 - Guidelines for the use of the C language in critical systems”, ISBN #0-9524156-2-3, www.misra-c2.com.
[xvi] Två exempel på verktygsleverantörer i den här kategorin är PolySpace Technologies (www.polyspace.com) och LDRA Software Technology (www.ldra.com).
[xvii] Du kan hitta ett exempel på användning av Splint i majnumret 2003 av MATLAB Digest (The MathWorks).
[xviii] Några FPGA-leverantörer vars verktyg kan användas i modellbaserad design inkluderar Xilinx (www.xilinx.com) och Altera (www.altera.com).
[xix] A/MS-designverktyg som Mentor Graphics ADVance MS (www.mentor.com), Cadence Virtuoso AMS Designer (www.cadence.com) och Synopsys Saber (www.synopsys.com) har gränssnitt till.
[xx] HLI-modeller (Hardware Description Language) i Verilog och VHDL kan t ex simuleras med ModelSim och Simulink (www.modelsim.com).