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).
This article is exclusively available to premium members of Bits&Chips. Already a premium member? Please log in. Not yet a premium member? Become one for just €20 for the first year and enjoy all the benefits.