Verifiering

Intro

Att verifiera en funktion kan ofta vara minst lika arbetskrävande som att skapa den. Därför är det otroligt viktigt med ett bra verktygsstöd där man kan automatisera och återanvända så mycket som möjligt genom processen.

Det brukar sägas att kostnaden för att åtgärda en bugg stiger exponentiellt med projektets framsteg och det är därför oerhört viktigt med tidig verifiering för att hitta eventuella buggar så tidigt som möjligt.

Det är även enklare att felsöka om man testar funktionerna i varje steg av den modellbaserade utvecklingsprocessen vilket. Ett exempel på en modellbaserad process visas här med steg 1-7.

Inom modellbaserad utveckling och testning så är det modellen som står i fokus. Dels modellen av den funktion man utvecklar men när det kommer till verifiering så är det framförallt modellen av det som ska styras. Denna modell kan vara mer eller mindre komplex, beroende på vad det handlar om. Ibland kan det räcka med ett parameterset, ibland kan det vara avancerade dynamik- och logikmodeller för att skapa ett korrekt återkopplat beteende. Med en genomtänkt modellbaserad process går det att använda samma omvärldsmodell genom hela verifieringskedjan, om än med små förändringar för att matcha delfunktioner.

 

Model-In-the-Loop Simulation

När en första modell av algoritmen/styrsystemet skapats måste det verifieras att den fungerar som det är tänkt samt att den uppfyller de krav som ställs.

Simuleringsmöjligheter kommer i regel med modelleringsmiljön men för att kunna starta en simulering så krävs någon typ av stimuli. I vissa fall kan det vara parametrar som skall matas in men i många fall krävs ett återkopplat system där man också simulerar det som skall styras och eventuella hjälpfunktioner. Den modell som återskapar beteendet av omvärlden kallas för omvärldsmodell.

Genom att använda sig av simuleringsmiljö och testexekveringsverktyg som stödjer standardiserade gränssnitt så som ASAM XIL-API så kan kan man återanvända de test som skapas genom hela utvecklingsprocessen. Eftersom modelleringsverktyg har olika styrkor så är det också fördelaktigt ifall man kan ta in modeller från olika verktyg, t.ex. genom standarden Functional-Mockup-Interface (FMI) och koppla ihop dessa för en gemensam simulering.

Simulering där en modell representerar algoritmen man utvecklar kallas för Model-In-the-Loop (MIL) Simulation.

Software-In-the-Loop Simulation

Vid autogenerering av kod så kommer koden att representera modellens beteende. Det betyder inte nödvändigtvis att modell och kod kommer att uppvisa ett identiskt beteende. Det bör av den anledningen också göras  simuleringen där den färdiga koden används, kallat Software-In-the-Loop (SIL) Simulation. Detta görs med samma omvärldsmodell som i MIL.

Vid simulering av modellen är det lämpligt att hålla implementation till flyttal för att introducera så få felkällor som möjligt. Är målsystemet en heltalsenhet så kommer begränsningar såsom skalning och datatypens intervall  in och påverkar resultatet och är de inte korrekt konfigurerade kommer beteendet skilja sig markant från det tänkta.

Även målsystemet är en flyttalsprocessor så finns det ofta stora mängder kalibrerparametrar och uppslagstabeller där heltal används för att minska minnesanvändningar. Det är också möjlighet att koden använder sig av andra beräkningsbibliotek än modellen.

För se vilka konsekvenser exempelvis heltalsimplementation har så är det lämpligt att simulera koden (SIL) och jämföra resultatet med den simulerade modellen (MIL), sådana tester brukar refereras till som ”back-to-back”. Det är här en stor styrka att ha modellen i flyttal vilket gör det enkelt att identifiera potentiella problem och optimeringsmöjligheter.

Processor-In-the-Loop Simulation

För att verifiera att kompilatorn och processorn inte introducerar några fel så kan man också koppla in ett utvärderingskort i simuleringen.

Man exekverar då koden på processorn medan omvärldsmodellen (samma som i MIL/SIL) kör på datorn. Detta kallas Processor-In-the-Loop (PIL) Simulation.

Gör man detta kan man också få värdefull information så som minnesanvändning, exekveringstid och stackanvändning för funktionen.

Integrationstestning

Har man flera funktioner som utvecklas fristående av varandra så måste integrationen verifieras. I stället för att göra detta i samband med att man implementerar på målsystemet så kan man integrera dessa på PC datorn.

Genom att utföra en integrationssimulering av koden på PC så har man uppnått virtuell validering av sin styrenhet. Detta är en nyckelkomponent för att kunna testa påverkan av en uppdaterad funktion i ett kontinuerlig arbete, vilket kallas continuous integration.

Genom att välja en platform som stödjer standardiserade interface så som ASAM XIL-API så kan man man återanvända test som utvecklats mot andra platfomar.

Några fördelar med att utföra integrationstesterna i en virtuell miljö:

  • Integrationstester innan hårdvara finns tillgänglig.
  • Frikoppling från hårdvaruimplementationer såsom drivrutiner och elektriskt interface.
  • Exekvering snabbare än realtid.
  • Bra debug-möjligheter.

Hardware-In-the-Loop Simulation

När den integrationstestade koden är implementerad i hårdvaran är det dags för den slutliga verifieringen. Delar av denna verifiering görs självfallet inkopplat mot det som ska kontrolleras men det finns också många fördelar med att utföra testen i labbmiljö där övriga delar av maskinen simuleras. Vilket kallas Hardware-In-the-Loop (HIL) Simulation.

Detta öppnar för möjligheten att skapa automatiserade tester som går att återanvända för olika mjuk- och hårdvaruversioner. Här går det att testa både funktionalitet och elektriskt interface.

En stor del del av mjukvaran är oftast diagnostik och för att verifiera den måste man injicera fel. Det kan vara saker som kortslutning eller kabelbrott eller helt felaktiga värden.

Omvärldsmodellen som använts i tidigare steg måste här kompletteras med en I/O modell som mappar signaler mot fysiska utgångar på simulatorn.

 

Test Automation

I verifieringsprocessen är repeterbarhet ett nyckelord. För att uppnå repeterbarhet, s.k. regressionstester, behövs automatisering.

De flesta testuppgifterna går att automatisera med testscript, men script är ofta svåra att sätta sig in i för en testare och det är svårt att skapa sig en överblick över vad som är tänkt för återanvändning i olika testfall. Vid automatisering av tester är ramverket för utveckling och exekvering av testfall viktigt. Ett bra ramverk för utveckling av testfall tillhandahåller grundläggande funktionalitet får att t ex läsa ifrån och skriva till en realtidsapplikation, spela in och återge data i form av grafer, tabeller eller rena siffror i en rapport etc.

För att underhålla och utveckla en automatiserad testmiljö är det fördelaktigt att ha väl definierade roller och ansvarsområden med tydliga gränssnitt för informations överföring. En automatiserad testprocess byggs upp av ett flertal under processer. Ansvaret för testprocessen ägs av rollen ”Test manager”. Det är test managern som har helhetsbilden och koordinerar de underliggande processerna för testutvecklarna, ramverksutvecklarna och simuleringsmiljöutvecklarna.

Med en automatiseringsmiljö som stödjer standardiserade interface så kan testen återanvändas genom hela utvecklingsprocessen.

Test management

Testaktiviteter är en betydande del i utvecklingsprojekt av ECUer. Idag är det vanligt med kravbaserad testning där testfallens syfte är att påvisa att målsystemet uppfyller de krav som ställts.

I en iterativ utvecklingsmiljö uppdateras kraven kontinuerligt vilket medför att vid varje iteration så måste man utvärdera om ett testfall fortfarande är giltigt, om det måste uppdateras eller om det krävs ett helt nytt testfall. Denna process leder till beroenden mellan versioner för kraven och testfallen.

För testaktiveteterna är kravet statiskt i varje iteration, medan testfallets implementation och genererade resultat kan uppdateras dessa beroenden måste hanteras för att underhålla spårbarheten. Ett testfall definieras av set attribut t ex namn, exekveringsmiljö, implementation, resultat, etc.

En stor utmaning att hantera alla dessa beroenden och data. Det behövs en databas men också en metamodell för hur saker hänger ihop så att det finns en spårbarhet mellan kravversion och version av testfall så att det går att återskapa den testmiljö som var aktuell för en specifik version.

Ett test management verktyg skall alltså kunna hålla all relevant information, men också använda den genom koppling till testmiljöer. I slutändan schemaläggs det vilka test som skall köras och en rapport ges över hur det förlöpt. Genom versionberoende kopplingar så går det att följa hur olika mjukvaruversioner uppfyller olika kravversioner.

Meny