Reading time: 7 minutes
Author:
Bart Broekman is senior consultant bij Sogeti Nederland. Hij was sinds februari 1999 betrokken bij een Europees ITEA-project over het ontwikkelen en testen van embedded systemen. Broekman is coauteur van het boek ’Testing embedded software‘. Op 12 oktober geeft hij tijdens het Sogeti-event ’Testen is embedded in het ontwikkelproces‘ in Veldhoven een lezing over dit onderwerp (www.sogeti.nl).
Het V-model is een klassieke methode bij de ontwikkeling van embedded systemen. Het houdt echter geen rekening met de verschillende verschijningsvormen van het systeem. Het Multiple-V-model gaat een stap verder en geeft de modellen, het prototype en het eindproduct een eigen V. Bart Broekman beschrijft in dit artikel zijn ervaringen met het testen van geïntegreerde systemen en de nauwe samenhang met de benodigde testomgevingen.
’Embedded systemen‘ is een vage term waaronder uiteenlopende dingen vallen zoals airbags, mobieltjes en vliegtuigen. Ik ga me niet wagen aan een sluitende definitie, maar één van de kenmerkende eigenschappen is dat de software en de hardware onlosmakelijk met elkaar verbonden zijn. Embedded systemen worden steeds omvangrijker en complexer. Ontwikkeling en testen hebben heel wat voeten in aarde. Als er dan iets mis blijkt te zijn (en dat is meestal het geval), is het een kostbare zaak om de problemen te analyseren en op te lossen. Een betere methode is om eerst modellen en prototypes te maken en in een gesimuleerde omgeving uit te proberen. De reden hiervoor is simpel. Het is veel sneller en goedkoper om wijzigingen aan te brengen in een prototype dan in het eindproduct, en nog sneller en goedkoper om wijzigingen aan te brengen in een model. Om dit te illustreren beschrijf ik hieronder in hoofdlijnen hoe (embedded) cruisecontrolesoftware voor auto‘s deze stadia doorloopt.
Na verificatie van de requirements en het conceptueel design wordt een systeemmodel ontworpen. Het gemodelleerde systeemgedrag is te testen door inputparameters aan het model aan te bieden en de outputparameters op te vangen en te analyseren. Hiervoor is een specifieke ontwikkel- en testomgeving nodig, zoals Matlab en Simulink van The Mathworks. Deze fase heet Model Testing (of MT).
Ultieme test
De ultieme manier om te testen of het model goed werkt, is het uitproberen in zijn werkelijke omgeving: de tester plugt zijn laptop met het model van het cruise-controlesysteem in een echte auto. Tijdens een autorit bedient de aangekoppelde computer de cruisecontrole en legt de resultaten vast. Rapid Prototyping (of RP) heet deze fase.
Op basis van dat model kan de softwarebouwer aan de slag. De programmatuur doorloopt vervolgens tests in een pure softwareomgeving, waar alle andere componenten zijn gesimuleerd. Dit wordt Software in the loop (of SIL) genoemd.
In een iteratief proces koppelt de tester vervolgens de software aan prototypes en integreert en test hij experimentele versies van de hardware. Tijdens deze Hardware in the Loop (of HIL)-fase vervangt hij steeds meer gesimuleerde onderdelen door de ’echte‘ componenten, totdat uiteindelijk het eindproduct in zijn bedoelde vorm is ontstaan.
Vanaf dat moment is het echte systeem gebouwd en is het mogelijk om het in zijn eigenlijke omgeving (de auto) te testen. Deze finaletest heet de Systeemtest (of ST). Vaak worden hierin ook de environmental tests uitgevoerd zoals testen op schokbestendigheid en elektromagnetische straling.
Gedurende het ontwikkelproces doorloopt een embedded systeem verschillende verschijningsvormen: modellen, prototypes en het eindproduct. Het Multiple-V-model is een ontwikkel- en testlevenscyclus waarin dit fenomeen expliciet is opgenomen. Het is gebaseerd op het welbekende V-model, waar in de linkertak de activiteiten requirements, design en bouw staan en aan de rechterkant de bijbehorende testactiviteiten.
Multiple-V
In het Multiple-V-model doorlopen de verschillende verschijningsvormen -ieder een volledige V-cyclus (zie Figuur 1). Het proces begint met het opstellen van de modeleisen. Daarna wordt het model ontworpen, gebouwd en vervolgens getest. Als het model voldoet, vormt het de basis voor de prototypes. Ook hierbij zijn eerst requirements uitgewerkt voordat het bouwen en testen begint. De essentie is dat elk van de verschijnings-vormen dezelfde vereiste functionaliteit bezit. Dat betekent dat de complete functionaliteit getest moet zijn op zowel het model als de prototypes en het eindproduct. Het testen van de verschillende verschijningsvormen vereist vaak wel specifieke technieken en testomgevingen. Er moet een nauwe relatie bestaan tussen het Multiple-V-model en de testomgevingen.
Het Multiple-V-model biedt een kapstok om alle ontwerp-, verificatie- en testactiviteiten een plaats te geven. Zo past modelintegratie aan de rechterkant van de model-V, terwijl code-inspectie aan de linkerkant van de tweede V (prototype) thuishoort. In de eerste V is immers nog geen sprake van code; die ontstaat pas in de prototype-V. Het testen van toestandovergangen is een techniek die zowel in de eerste V als de tweede V toepasbaar is. Als voorbeeld laat Figuur 2 nog een aantal testgerelateerde onderwerpen zien die typisch bij de tweede V thuishoren.
Het Multiple-V-model heeft in deze vorm nog tekortkomingen. Zo komt het fenomeen van decompositie en integratie niet goed naar voren. Na een architectuurdesign worden componenten gedefinieerd waarmee verschillende ontwikkelteams vervolgens parallel aan de slag gaan. De uiteindelijke delen vormen dan samen het totale systeem. Dat kun je zien als een overkoepelend V-model. Elk van de gedefinieerde componenten komt tot stand met modellen en prototypes en doorloopt dus meerdere V‘s. Uiteindelijk ziet het totale ontwikkel- en testproces van een complex embedded systeem er dus uit als een combinatie van een overkoepelende V met onderliggende parallelle V‘s, het zogenaamde geneste Multiple-V-model (zie Figuur 3).
Paar graadjes complexer
De werkelijkheid is meestal een paar graadjes complexer. Het Multiple-V-model is geen sequentieel proces. Met name de middelste V voor prototypes is vaak sterk iteratief van karakter. Typisch komen hier iteratieve methodes als RUP en XP om de hoek kijken.
Integratie van componenten gebeurt niet alleen aan het eind van de overkoepelende V. Sommige componenten worden al tijdens de prototypefase geïntegreerd en later weer gekoppeld met andere deelsystemen.
In de praktijk blijken bedrijven het moeilijk te vinden om het geneste Multiple-V-plaatje in te vullen. Ze vinden het lastig om precies in kaart te brengen hoe ze de release van een product in totaal moeten ontwikkelen en testen. Is het dan gek dat zulke bedrijven vaak ook niet weten of ze wel goed genoeg testen en hoe dat anders zou moeten? Ze weten vaak niet eens hoe hun ontwikkelproces er uitziet met al zijn oplever- en integratiemomenten.
Specifieke hardware
Zoals ik in het begin van het artikel al heb aangegeven, werkt embedded software pas in samenhang met de specifieke hardware. Om in een vroeg stadium een stuk software (of andere component) te kunnen testen terwijl de rest van het apparaat nog niet bestaat, moet de tester de rest simuleren. Bij het testen van embedded software mogen we simulators in hoofdletters schrijven. Maar wat ga je dan precies simuleren? Hoeveel simulators? Hoeveel verschillende testomgevingen? Om dat wat overzichtelijker te maken is in Figuur 4 een generieke blauwdruk van een embedded systeem geschetst, waarin in hoofdlijnen vier simulatiegebieden zijn benoemd.
De embedded software zelf is te simuleren met een model. De ontwikkelaar schrijft de software eerst voor een hostcomputer en kruiscompileert die later naar een geëmuleerde targetprocessor om het uiteindelijk op het echte doelplatform te laten draaien.
Bij massaproductie van consumentenproducten is het belangrijk om een zo goedkoop mogelijke processor te hebben. Als je een Pentium V in een mobieltje stopt, kost die direct al een paar honderd euro meer. Als het met een 8-bitter kan, ga je geen 16 bit processor gebruiken. De ontwikkelomgeving voor de software is meestal een krachtige pc of mainframe. De designer moet de goedkope targetprocessor op die omgeving simuleren. De rest van het systeem moet hij simuleren met experimentele hardwareconfiguraties of prototype PCB‘s.
De buitenwereld waar het embedded systeem mee communiceert, is statisch te simuleren door het genereren en aanbieden van inputsignalen of dynamisch door een computermodel.
Testsoorten
Gedurende het Multiple-V-ontwikkel- en testproces komen verschillende soorten tests aan de orde, waarbij één of meerdere van de vier simulatiegebieden zijn gesimuleerd en de overige gebieden vervangen zijn door echte componenten of de experimentele versies daarvan.
Elk van de drie V‘s uit het Multiple-V-model heeft zijn eigen testsoorten en gebruikt zijn eigen simulatiegebieden.In de modeltest in de eerste V zijn zowel het embedded systeem als de omgeving waarmee hij praat gesimuleerd. Tijdens de Rapid Prototyping-fase probeert de tester het model uit in de werkelijke gebruiksomgeving. De omgeving is nu reëel.
De tweede V gaat over het prototype. Tijdens de software-unittest en de software-integratietest is de programmatuur geschreven of gegenereerd. Testen gaat in een softwareomgeving waar de rest van het embedded sys-teem (zoals de hardwarecomponenten) en de omgeving zijn gesimuleerd. In eerste instantie wordt de software geschreven op de host. Daarna wordt de software kruisgecompileerd voor de werkelijke processor en getest op een geëmuleerde versie daarvan. De tester integreert de software dan met echte hardwarecomponenten of experimentele versies daarvan, zoals hard-wired circuit boards. Hij gebruikt hierbij de uiteindelijke processor. De omgeving en nog niet beschikbare componenten zijn gesimuleerd. Laatste stap is hier de systeemintegratietest. Alle hardwarecomponenten worden samengebracht en geïntegreerd op een prototype PCB. De testomgeving lijkt erg op die van de eerdere hardware-software-integratietest.
Uiteindelijk doorloopt ook het eindproduct zijn V. Met specifieke tests onderzoekt de ontwikkelaar of het embedded systeem bestand is tegen omgevingsinvloeden zoals vochtigheid en schokken. Soms komen deze eigenschappen al in de tweede V aan de orde. In de finaletest kijkt hij of aan alle requirements is voldaan. Daarnaast stelt hij dan vast of het systeem bijvoorbeeld snel genoeg is en of het in groten getale te produceren is.
| Testniveaus | Embedded software | Processor | Rest Embedded Systeem | Plant | |
|---|---|---|---|---|---|
| Enkel simulatie | MT | Gesimuleerd | – | – | – |
| Feedback-simulatie | MT | Gesimuleerd | – | – | Gesimuleerd |
| Rapid prototyping | RP | Exp. | Exp. | Exp.l | Echt |
| SW/U, SW/I (1) | SIL | Experimenteel (host) | Host | Gesimuleerd | Gesimuleerd |
| SW/U, SW/I (2) | SIL | Echt (target) | Emulator | Gesimuleerd | Gesimuleerd |
| HW/SW/I | HIL | Echt (target) | Echt (target) | Exp. | Gesimuleerd |
| Systeem-integratie | HIL | Echt (target) | Echt (target) | Prototype | Gesimuleerd |
| Omgeving | HIL/ST | Echt (target) | Echt (target) | Echt | Gesimuleerd |
| Reproductie | ST | Echt (target) | Echt (target) | Echt | Echt |
Figuur 5: Overzicht van de testsoorten en het geleidelijk vervangen van gestimuleerde componenten door de echte componenten.
Het geheel is samengevat in Figuur 5. Deze tabel laat duidelijk zien hoe de testsoorten beginnen met volledige simulaties en echte componenten vervolgens de simulaties vervangen, totdat de laatste testsoort het volledig echte systeem in zijn echte omgeving test.
