Bits&Chips

Tien jaar modelgebaseerd ontwikkelen

Auteur: Jeroen Kouwer en Ferenc Schopbarteld
11 september 2015 

Thales Nederland ontwikkelt de software voor zijn radarsystemen al meer dan tien jaar met behulp van modelgebaseerde technieken. Wat begon met het genereren van codefragmenten groeide uit tot het modelleren en genereren van de software-infrastructuur. Een terugblik, met speciale aandacht voor de struikelblokken en geleerde lessen.

De afdeling Processing in Hengelo ontwikkelt software voor de radarsystemen van Thales. Het domein kenmerkt zich door hoge datarates (GB/s), lage latency’s (microseconden) en een enorme schaalbaarheid in de onderliggende platforms, zowel in aantal (gedistribueerd) als in toegepaste technologieën (heterogeen). In de tijd die nodig is om een radar te ontwikkelen, kunnen we bovendien meerdere technologie-upgrades verwachten. Met name het front-end (dicht bij de antenne, waar de zwaarste realtime-eisen gelden en de datarates het hoogst zijn) is enorm technologiegedreven, aangezien nieuwere technologieën zowel de reken- als de communicatiesnelheid verbeteren.

In de jaren negentig gebruikten we Vxworks als besturingssysteem in onze radars en Solaris-machines als hostomgeving. Om efficiënter te kunnen testen en debuggen op zowel host als target zijn we de software al vroeg van onderliggende technologieën als os’en, communicatieprotocollen en platformarchitectuur gaan scheiden door het component-containermodel toe te passen. Hierbij genereer je de container uit een metabeschrijving van de component. Deze container verbindt de component met de onderliggende technologieën. Later zijn we ook de verbindingen tussen de componenten gaan vastleggen in modellen. Hiermee werd het mogelijk de ontwikkelde bouwstenen in verschillende configuraties te plaatsen door de ‘wiring’ van buiten op te leggen. Als laatste hebben we standaard services toegevoegd aan het metamodel, om componenten van de buitenkant te kunnen monitoren en besturen. Het hele traject hebben we de ondersteuning van technologieën stapsgewijs uitgebreid.

Het resultaat is dat we de software kunnen inzetten op verschillende platforms en systemen. De toegevoegde services geven niet alleen de programmeurs maar ook de testengineers de mogelijkheid om ‘in’ de software te kijken, daarmee hergebruik stimulerend. De geboden handvatten om datastromen naar believen te kunnen opnemen en afspelen zorgen voor een enorme efficiëntieverbetering tijdens de integratie en de evaluatie van systemen in het veld.

In een sterke projectorganisatie met een doorlooptijd van jaren was hergebruik over projecten niet vanzelfsprekend. Door haar voordelen is de modelleeromgeving steeds populairder geworden en zijn projecten er zelf om gaan vragen. Engineers, over de afdelingen en projecten heen, hebben dezelfde vocabulaire ontwikkeld, wat veel misverstanden uit de weg ruimt. Er is een soort ecosysteem ontstaan waarin we lokale initiatieven kunnen borgen en eenvoudig globaal beschikbaar kunnen maken voor alle gebruikers. Denk aan ondersteuning van gegenereerde code uit Simulink, de generatie van diverse documenten, online built-in-tests op interfaces, boundarychecks op de inhoud van binnenkomende berichten en Matlab-ondersteuning.

Struikelblok

Zijn er dan geen nadelen? Jazeker wel. Ten eerste vereist deze aanpak een hoger abstractieniveau van engineers. Niet iedereen heeft dit in zich en zelfs degenen die het wel in zich hebben, doen er even over om het zich eigen te maken. In de loop der tijd is ook gebleken dat niet iedereen hoeft te modelleren. Binnen de afdeling zijn modelleerexperts opgestaan, die het merendeel van het modelleerwerk op zich nemen en anderen assisteren.

Met verschillende abstractieniveaus werken is moeilijk, en informatie catalogiseren in de juiste abstractielaag gaat dan ook niet in één keer goed. Mede vanuit de initiële wens van de engineers om veel controle te hebben over de codegeneratie hebben we veel detailinformatie opgenomen in het metamodel. Daardoor hebben we minder abstractieniveauwinst behaald dan gehoopt, met als resultaat een complexer en arbeidsintensiever model.

Een ander struikelblok is dat we eigenlijk geen goede modelleeromgeving hebben. Vrijwel alle beschikbare tools zijn óf niet volwassen genoeg óf niet gebaseerd op open technologie. Wij hebben in 2008 genoegen genomen met IBM Rational Software Architect omdat dit gereedschap een open standaard hanteert bij de onderliggende dataopslag, zodat we voor het benaderen van de informatie niet afhankelijk zijn van de tool en de leverancier.

Ook de introductie van een agile manier van werken heeft de nodige uitdagingen met zich meegebracht. Zo’n werkwijze vereist korte ontwikkelcycli en kleinere teams, en dat stelt hoge eisen aan de architectuur en de modelleeromgeving. Waar onze eerste modellen het hele systeem in al zijn details beschreven in één modelartefact, zijn de latere modellen opgebouwd uit meerdere artefacten die naar elkaar verwijzen. Elk modelartefact beschrijft dan een deelaspect en alle artefacten samen geven een complete beschrijving van het te ontwikkelen systeem. Zo kunnen verschillende teams tegelijkertijd aan verschillende aspecten of deelbeschrijvingen werken.

De toekomst

En daar staan we dan, anno 2015, tien jaar ervaring rijker. We hebben een omgeving waarmee we in UML softwareapplicaties kunnen modelleren, deze applicaties aan de beschikbare platforms kunnen toewijzen en veertig procent van de code kunnen genereren. Daar waar we ook de algoritmiek modelleren (in Simulink) halen we zelfs 95 procent.

Door het gebruik van profielen in UML hebben we in wezen een domeinspecifieke taal (dsl) gedefinieerd. UML is daarvoor echter niet de beste keuze: de uitdrukkingsvormen blijven gebonden aan UML en zijn niet toegespitst op het applicatiedomein. Op hoger niveau zien we structuren ontstaan die herbruikbaar zijn, standaard bouwblokken met een gedefinieerde interface. Wellicht is het opportuun om niet zozeer software te modelleren als wel de radar. Uitgaande van een generieke radararchitectuur kunnen we een metamodel creëren waarmee we een specifieke radar kunnen beschrijven, inclusief de toegestane variaties. Dit impliceert dat we een dsl nodig hebben voor radararchitecturen waarmee we radarproducten kunnen samenstellen: een dsl op macroniveau.

Daarnaast zien we meer en meer de noodzaak dat softwarecomponenten niet alleen ontkoppeld zijn van de technologie, maar ook nog meer ontkoppeld van elkaar. We groeien naar een servicearchitectuur waarbij we het ‘variatie door compositie’-dogma kiezen. Geen grote softwarebouwblokken, maar kleinere modules die functioneel ontkoppeld zijn door het gebruik van services en die dynamisch samen te stellen zijn. De technologieontkoppeling verkregen in de componenten wordt zo ook doorgevoerd in de architectuur. En daarmee hebben we ook een uitbreiding in onze domeintaal nodig om deze ‘variatie door compositie’ te kunnen uitdrukken: een dsl op microniveau.

Hoe ziet onze toekomst eruit? Er is een wens voor een dsl op macroniveau, om radararchitecturen te modelleren, maar op dat niveau hebben we nog geen ervaring. Ook is er een duidelijke wens voor een dsl op microniveau, om de servicearchitectuur te modelleren, en daar hebben we dan weer wel ervaring mee. En we zien dat er nu modelleeromgevingen zijn die meer volwassen zijn en die ook andere aspecten van systeemgedrag kunnen beschrijven. Het lijkt wenselijk deze omgevingen te combineren om zo nog beter radars te kunnen ontwikkelen, maar ook hier hebben we nog geen ervaring mee.

Voorlopig zijn we nog even een stukje de bekende weg aan het bewandelen: we zijn aan het verkennen hoe een dsl op microniveau UML met profielen zou kunnen vervangen, maar wel met in het achterhoofd dat we radars willen kunnen modelleren en ook dat we op termijn andere aspecten van die radars willen kunnen beschrijven.

Jeroen Kouwer en Ferenc Schopbarteld werken beiden als softwarearchitect bij Thales Nederland.

Redactie Nieke Roos

Abonneer direct op onze nieuwsbrief

abonneren

Digital signal processing

1 oktober - 15 oktober

Eindhoven

C and C++ secure coding

9 oktober - 11 oktober

Eindhoven