Reading time: 7 minutes
Author:
Modelgebaseerd ontwerpen is de pijler onder de designstrategie van The Mathworks. De aanpak maakt het ontwerp toegankelijk voor verschillende afdelingen en verbetert zo de communicatie. Automatische codegeneratie is door het hele proces verweven. Hiermee kunnen designers al vroegtijdig problemen signaleren en alternatieven evalueren. Co Melissant van The Mathworks laat zien hoe het genereren van code de verschillende fases in het ontwikkelproces verbetert.
Voor de modellering van systemen en de interactie daartussen maken ontwikkelaars steeds meer gebruik van tools op basis van blokdiagrammen. Met dergelijk gereedschap construeren ze modellen intuïtief uit standaard componenten. Door vervolgens een simulatie te runnen, kunnen ze het functionele gedrag van het bouwsel analyseren. Dit maakt van het model een executeerbare specificatie. Nadat de specs op deze manier zijn vastgelegd, is de stap naar implementatie van een algoritme in software eenvoudig met automatische codegeneratie. In alle fases van het ontwikkeltraject staat het modelgebaseerd ontwerpen, of model-based design, centraal.
In dit artikel beschrijf ik hoe designers vanuit een Simulink-model automatisch code kunnen genereren. Tevens zal ik laten zien hoe ze de code kunnen inzetten tijdens de verschillende fases van het ontwikkelproces. Automatische codegeneratie is al lang geen fantasie meer, maar werkelijkheid.
Een op een
Model-based design is inmiddels een bewezen werkwijze binnen bestaande ontwikkelmethodes zoals het spiraaldiagram, het V-model of de watervalaanpak. Het gebruik van de modelgebaseerde ontwerpstrategie leidt tot een efficiëntere aanpak binnen een ontwikkelproces. Zo start het validatie- en verificatietraject zodra het model simuleerbaar is. Het proces wordt geformaliseerd door een testraamwerk te ontwikkelen op basis van de requirements. Dit harnas kunnen we in een later stadium gebruiken om de gegenereerde code te valideren.
Ook zijn de prototypes eerder beschikbaar. Zodra we het model kunnen simuleren, kunnen we automatisch code genereren van (een deel van) het model. Er is dus direct een prototype van de uiteindelijke embedded software voorhanden. Prototyping is hiermee daadwerkelijk rapid.
Verder zijn de executeerbare specificaties voor elke afdeling duidelijk. Het model fungeert als communicatiemiddel tussen verschillende divisies of bedrijven. Doordat het kan worden gesimuleerd, kan er geen onduidelijkheid bestaan over het functionele gedrag. Dit in tegenstelling tot specificaties die in een document zijn vastgelegd en vaak niet volledig zijn of zelfs in tegenspraak met elkaar. De embedded-software-engineer hoeft het model alleen maar uit te breiden met details die specifiek zijn voor de implementatie in software. Hij kan zich dus concentreren op zijn specialiteit en hoeft zich niet te verdiepen in het algoritme.
Ten slotte is de implementatie een een-op-eenvertaling van het algoritme uit de specificatie, het model. Functioneel zal er dus geen verschil ontstaan door coderingsfouten of onbedoelde aanpassingen.
Bouwblokken
Softwareoplossingen voor model-based design zoals Simulink van The Mathworks ondersteunen de specificatie, het design en de validatie van modellen. Simulink is een programma voor het ontwerpen, simuleren, implementeren en testen van dynamische systemen en algoritmes. In Figuur 1 is een blokdiagram van een regel-algoritme te zien afkomstig uit het softwarepakket. De onderdelen van het diagram bevatten elk een specifieke functie (versterking, sommatie en verzadiging). Door deze blokken middels lijnen met elkaar te verbinden ontstaat een simulatiemodel van een tijdsafhankelijk proces. Gebruikers kunnen de bouwblokken uit een bibliotheek naar het model slepen (drag and drop).
Naast de standaardblokken in Simulink zijn er applicatiespecifieke bibliotheken beschikbaar voor bijvoorbeeld communicatie, radiofrequentie en signaalverwerking. Ook zijn toestandsdiagrammen te modelleren (zie Figuur 2). Designers kunnen bestaande (legacy) code opslaan in een eigen bibliotheek, zodat ze de reeds gevalideerde code gemakkelijk kunnen hergebruiken binnen nieuwe ontwerpen.
Door het model te simuleren stellen gebruikers vast of de applicatie onder testomstandigheden voldoet aan de eisen. Om goed te kunnen simuleren, modelleren ze meestal ook de omgeving in Simulink. In zijn totaliteit beschouwen ze het blokdiagram van de applicatie als een executeerbare specificatie. Naarmate het ontwikkelproces vordert, voegen ze implementatiedetails toe aan het diagram, zodat het model uiteindelijk dienstdoet als broncode voor de embedded software. Dit wordt mogelijk gemaakt met automatische codegeneratie vanuit het simulatiemodel.
Conversie
In de eerste ontwikkelfase van een systeem is automatische codegeneratie vooral handig om voor complexe modellen de simulatie te versnellen. In een later stadium zal voor functionele rapid prototyping het gebruik van codegeneratie zelfs essentieel zijn. Het algoritme is met een druk op de knop te testen op een hard realtime prototypingplatform.
Voordat de code wordt gegenereerd, is het meestal noodzakelijk om een paar aanpassingen te doen. Deze wijzigingen veranderen niets aan het functionele gedrag van het systeem, maar zijn belangrijk voor de overstap van simulatiemodel naar een hard realtime prototypingomgeving. Hierbij valt te denken aan de conversie naar een vaste sampletijd. De enige harde eis aan het model is dat het op vaste sampletijden wordt doorgerekend. Tijdens de simulatie kan de simulator slim sampletijden kiezen, maar in realtime is een vaste sampletijd noodzakelijk. Overigens kan het model wel meerdere sampletijden (multirate) en asynchrone componenten bevatten.
Dan volgt de conversie naar discrete tijd. Het is meestal gemakkelijker om dynamische systemen te modelleren in het continue tijdsdomein. Voor embedded software is het echter vaak een eis om het systeem te implementeren in het discrete tijdsdomein (dus zonder integratiealgoritme). De aanpassing van het algoritme van continu naar discreet kan gemakkelijk met een conversietool.
Vervolgens vragen de I/O-interfaces om aanpassing. Het model van het regel-systeem moet worden gewijzigd om de softwaredrivers van de I/O-interfaces toe te voegen. Veel rapid protoyping-hardware is leverbaar met een blokkenbibliotheek die de I/O-drivers direct koppelt aan het codegeneratieproces, zodat de volledige applicatie vanuit Simulink wordt gegenereerd.
Na het voltooien van enkele (of alle) aanpassingen is het model klaar voor codegeneratie. Voor het genereren van embedded software zijn er echter nog meer optimalisaties beschikbaar.
Bit-true
Gedetailleerd softwareontwerp start wanneer de functionele requirements voor het systeem en de software gespecificeerd zijn met modellen. In veel gevallen houdt hier het werk van de systeemengineer op en kan de embedded-software-engineer aan de slag. Helaas is dit eveneens het punt waarop veel miscommunicatie voorkomt. Dit probleem is op te lossen door de productiecode automatisch te genereren vanuit het systeemmodel. Dat is mogelijk omdat de details van het softwareontwerp zijn toe te voegen aan het systeemmodel. De definitieve code wordt dan automatisch gegenereerd wanneer de software compleet is ontworpen. Door als werkwijze model-based design te gebruiken, ligt het model van het algoritme als het ware opgesloten in het ontwerp van de software.
Specifieke details die aan het model zijn toe te voegen, vinden hun oorsprong vaak in requirements die het functionele gedrag niet (mogen) beïnvloeden. Denk aan interne of externe coderingsregels zowel op het gebied van de syntax als voor het ingevoegde commentaar of de partitionering in functies en bestanden, maar ook voor de integratie van de gegenereerde code in een bestaand project of een bestaande applicatie. Andere details zijn de toegankelijkheid van parameters voor andere toepassingen voor bijvoorbeeld kalibratie, inregeling of aanpassing, en de gebruikte compiler in verband met specifieke pragma‘s of storage classes. Ook de kostprijs en het energieverbruik van de hardware zijn belangrijke requirements.
Deze laatste twee eisen leiden meestal tot de conversie van het algoritme van drijvende- naar vastekommadatatypes, want het rekenen met drijvende komma‘s vereist duurdere hardware die ook nog eens meer energie verbruikt. Gewoonlijk echter gebruiken simulatiemodellen double precision drijvendekommaberekeningen. Het omzetten van een algoritme is niet triviaal, maar doordat het model binnen Simulink bit-true simuleerbaar is, zijn de drijvendekommaresultaten van het algoritme eenvoudig te vergelijken met de vastekommawaarden. Daarnaast zijn er tools die beslissingen tijdens de omzetting van drijvende naar vaste komma ondersteunen.
Harnas
De laatste uitdaging voor de engineers is het testen van de automatisch gegenereerde software. Dit gebeurt meestal in een aantal stappen. Allereerst testen ze de software binnen de ontwikkelomgeving (software in the loop, Sil). Vervolgens controleren ze de software op de uiteindelijke processor vanuit de ontwikkelomgeving (processor in the loop, Pil). De laatste stap in het validatieproces is vaak een test met alle hardware via hardware in the loop (Hil). Door hardware toe te voegen, bekijken engineers of de software in realtime werkt en of de implementatie voldoet aan de gestelde requirements.
Het harnas waarmee het model al eerder in het ontwikkelproces is getest, komt nu weer van pas. Eventueel kunnen engineers het uitbreiden tijdens de verschillende tests. De werkwijze van model-based design brengt dus ook structuur aan in het testen van de software. Dit is belangrijk aangezien software steeds vaker moet worden gecertificeerd.
First time right
Model-based design is een werkwijze die toepasbaar is binnen de bestaande ontwikkelmethode. Het verbetert de communicatie tijdens het designproces. Omdat iedereen dezelfde taal spreekt, kunnen ontwikkelaars aanpassingen aan het ontwerp snel en in een vroeg stadium (wanneer de kosten nog laag zijn) maken en simuleren. Het uiteindelijke aantal prototypes is hierdoor beperkt.
Essentieel binnen deze werkwijze is het gebruik van automatische codegeneratie. Hiermee kun je al vroegtijdig in het ontwerpproces mogelijke realtimegerelateerde problemen signaleren en alternatieven evalueren. Zo verkort je de ontwikkeltijd en bespaar je ontwikkelkosten. Risico‘s op ernstige ontwerpproblemen worden gereduceerd en first time right is opeens geen fantasie meer, maar werkelijkheid.
Co Melissant is als senior application engineer bij The Mathworks in Gouda dagelijks betrokken bij projecten die automatische codegeneratie toepassen voor zowel prototyping- als productieomgevingen.
