Om het ontwerpen van steeds complexere systemen behapbaar te kunnen houden, staat modelgebaseerd ontwikkelen de laatste tijd vol in de schijnwerpers. ASML voerde diverse proefprojecten uit met modellen voor de constructie en voor de analyse van delen van zijn lithografiemachines. Met overwegend positieve resultaten. In dit artikel beschrijft het zijn ervaringen bij de invoering van modelgebaseerd ontwikkelen.
Complexe systemen zoals lithografiemachines lijken een onbedwingbare behoefte aan ontwikkelcapaciteit te kennen. De ontwikkelafdeling van ASML is in 25 jaar tijd van ongeveer zestig mensen gegroeid naar meer dan tweeduizend en de vraag naar capaciteit stijgt nog steeds. Met name de softwareontwikkelafdeling is onevenredig gegroeid en bedraagt op dit moment een derde van de populatie.
In termen van het V-model ligt ASML‘s kracht in het zo vroeg mogelijk beginnen aan het integratietraject. Daarbij nemen we voor lief dat er mogelijk onvolkomenheden in het ontwerp zitten en dat er later gecorrigeerd en opnieuw geïntegreerd moet worden. Door de groeiende complexiteit neemt echter ook het aantal onvolkomenheden toe, waardoor het oplevermoment steeds moeilijker is te plannen.
De problemen liggen in de rechterkant van de V, maar de oplossing ervoor moet aan de linkerkant worden gezocht. Door meer aandacht te leggen op de functionele en niet-functionele ontwerpeisen, budgettering van resources, de vroegtijdige verificatie van het ontwerp en zo veel mogelijk aspecten in het ontwerptraject te automatiseren, kunnen verrassingen in het integratietraject namelijk worden voorkomen. Design for integration is dan ook het motto, waarbij de linkerkant van de V expliciet tot doel krijgt om het integratietraject zo efficiënt mogelijk te laten verlopen.
Daarvoor is eigenlijk een andere werkwijze nodig dan we traditioneel gewend zijn. Zo wil je tijdens het redeneren over het ontwerp al uitspraken kunnen doen over de prestaties van het systeem en de marges, en wil je snel weten welke gevolgen een ontwerpbeslissing heeft. Ook wil je handwerk zo veel mogelijk automatiseren om de doorlooptijd en de kans op fouten te reduceren. Om het redeneren over het ontwerp te vereenvoudigen, wil je zo veel mogelijk spreken in termen van abstracte ontwerppatronen in plaats van implementatiedetails. Daarnaast wil je dat de verschillende ontwerpdisciplines zo veel mogelijk met hun eigen, domeinspecifieke, notaties kunnen werken. Tijdens de integratie wil je echter de ontwerpen tegen elkaar kunnen verifiëren en valideren, dus moeten die beschrijvingen wel formeel aan elkaar kunnen worden gerelateerd.
Test less, verify Moore
At the Bits&Chips Event 2023 on 12 October 2023, Phillipa Hopcroft from Crocotec and Ivo ter Horst from ASML will kick off with a keynote speech on transforming how lithography machine software is built. Make sure to keep an eye on the website for program updates and save the date!
Deze manier van werken is mogelijk wanneer een modelgedreven benadering de huidige werkwijze aanvult. In de mechanica- en de halfgeleiderontwerpwereld wordt deze benadering al met veel succes toegepast. Momenteel lopen er ook voor de embedded-softwareontwikkeling van ASML drie proefprojecten: Lace (Logical Action Component Environment), Drife (Subsystem Driver Framework Environment) en het Davinci-Wings-project.
Domeinspecifiek
Bij modelgedreven ontwikkeling gaan we er vanuit dat de primaire artefacten van de ontwikkeling bestaan uit modellen. Die worden gevormd door data en gerepresenteerd met behulp van grafische of tekstuele syntaxen. Feitelijk kan alle broncode, ongeacht de programmeertaal, gezien worden als een model, maar in het algemeen noemen we dat niet zo. Het verschil zit vooral in het abstractieniveau dat we met de modellen willen bereiken. Als we binnen een besloten context met een groepje ingewijde ontwikkelaars bij de koffieautomaat of in informele documenten redeneren over een deelsysteem, hanteren we een jargon dat ons in staat stelt zeer efficiënt te communiceren. In onze modelgedreven aanpak vangen we dit jargon in goed gedefinieerde data-elementen en voorzien we deze van een geschikte syntax. Het resultaat is een zeer specifieke maar daardoor hoogabstracte modelleertaal waarin we ons deelsysteem kunnen beschrijven. Deze beschrijving is processable, zodat we daaruit bijvoorbeeld code kunnen genereren.
Een belangrijk uitgangspunt in onze benadering van modelgedreven ontwikkeling is het onderkennen van twee typen modellen, die allebei een rol spelen bij de ontwikkeling van een (deel)systeem. Constructiemodellen dragen direct bij aan de constructie van het systeem, terwijl de analyse-, verificatie- en validatiemodellen (AVV) dienen ter onderbouwing van de keuzes en het reduceren van risico‘s in de constructie. Bij de Lace- en Drife-projecten ligt onze focus op de ontwikkeling van constructiemodellen, terwijl het Davinci-Wings-project zich richt op de benodigde AVV-modellen.
Constructiemodellen zetten we vooral in bij de ontwikkeling van nieuwe componenten. Het model is daarbij het primaire artefact waaruit we broncode genereren. Dat wil niet zeggen dat er geen handmatig geschreven code meer aan te pas komt. Die scheiden we wel van gegenereerde code in aparte bestanden. Zo blijft het model consistent met de code en heeft hergeneratie weinig impact.
Bij het ontwikkelen moet de focus zo veel mogelijk liggen op de ontwerpbeslissingen en niet op bijzaken. De taal om het ontwerp in constructiemodellen vast te leggen, moet dan ook zo veel mogelijk gebaseerd zijn op het jargon dat de ontwikkelaar hanteert. Technische details die afleidbaar zijn, worden uit die taal geweerd.
Daarvoor zetten we domeinspecifieke talen in (domain-specific languages of DSL‘s). Die zijn vaak zo specifiek dat ze alleen binnen ASML betekenis hebben, en dan nog zelfs alleen binnen een deelgebied zoals een architectuurlaag van een productfamilie. De semantiek van deze constructietalen wordt bepaald door het definiëren van transformaties naar executeerbare realisaties. Dat maakt dan gelijk de geautomatiseerde constructie vanuit de DSL‘s mogelijk.
Modellen dienen aan een structuur te voldoen. Net zoals de UML-regels de structuur voor UML-modellen opleggen, specificeren DSL‘s regels waaraan een model binnen die taal moet voldoen. Deze structuur is op zijn beurt ook weer vastgelegd in een model, een zogeheten metamodel.
Winst
Een praktijkvoorbeeld van deze aanpak is het Lace-project, dat zich richt op de ontwikkeling van logische-actiecomponenten. Deze bevinden zich in een architectuurlaag die de abstracte logische acties vertaalt naar een lijst van subsysteemacties die optimaal parallel worden uitgevoerd.
Voordat we met Lace begonnen, gebruikten we een document dat het logische-actiedomein beschrijft en een softwarebibliotheek om de implementatie te vereenvoudigen. Toch kostte het nog een aanzienlijke effort om een component te ontwikkelen: de vertaling van het gewenste gedrag naar instructies voor de bibliotheek was allerminst triviaal. Bovendien was er veel detailkennis nodig van de interfaces van de softwarebibliotheek.
Met Lace kunnen we nu het gewenste gedrag van de component specificeren aan de hand van concepten die inherent zijn aan de architectuurlaag. Kennis van de bibliotheek is verankerd in codegeneratoren, gemaakt door experts die alle details van het mechanisme kennen. Deze aanpak schermt de details af voor Lace-gebruikers.
Op dit moment is Lace volwassen en het gebruik ervan verplicht gesteld. Eerder uitgevoerde pilots laten zien dat we zeventig tot honderd procent van de C-implementatie kunnen genereren. De effort van requirements tot en met onderhoud is daarbij gereduceerd met een factor vijf.
Een ander project rond constructiemodellen is Drife. Deze faciliteit richt zich op de subsysteemarchitectuurlaag met soft-realtime softwarecomponenten voor toegang tot mechatronische subsystemen en complexe sensoren. Hier verkeren we nog in een wat vroegere fase.
Bij het definiëren van het domeinmodel bleek dat zelfs experts initieel verschillende interpretaties van sommige concepten hadden. Vanwege de complexiteit van het domein en om toch voortgang te kunnen laten zien en feedback te kunnen verwerken, hebben we gekozen voor een incrementele aanpak. Na de algehele opzet van model en implementatie pakken we functionaliteiten op als initialisaties of het veranderen van setpoints.
Door deze aanpak evolueren handgeschreven en modelgegenereerde implementaties naast elkaar. Drife was echter snel in te zetten. Al bij de eerste toepassing hebben we naast de ontwerpdocumentatie zo‘n veertig procent van de C++-implementatie gegenereerd. De winst in deze prille fase schatten we op vijftien procent, van requirements tot en met onderhoud.
Handmatig
AVV-modellen zijn bedoeld om ontwerpkeuzes te analyseren, te verifiëren of te valideren. Daarvoor moet het deelontwerp in een executeerbare of berekenbare (formele) representatie worden gevangen en samengevoegd met andere bijdragen aan het deelsysteem. Zo moet een model van een softwarecomponent voor een prestatieanalyse samen te voegen zijn met de modellen van hardware, firmware en andere relevante software. Dat resulterende model kunnen we dan voorzien van stimuli, zodat we het systeemgedrag kunnen voorspellen. Daarmee is het ontwerp tijdig bij te sturen, zelfs voordat de hardware is gerealiseerd. We spreken dan ook wel over vroegtijdige integratie.
Het resulterende model representeert slechts de te analyseren aspecten van het systeem, maar moet daarvoor soms veel gedetailleerder zijn dan nodig voor de constructie. Zo kan het cachegedrag van een processor relevant zijn voor de analyse, terwijl dat bij de constructie geen rol speelt. De AVV-modellen zijn dus essentieel anders dan de constructiemodellen. Het opstellen ervan is arbeidsintensief en vergt gespecialiseerde kennis van formalismen waarover de ontwerper doorgaans niet beschikt. Het is dus zaak dat de ontwerper ze automatisch kan opstellen aan de hand van de keuzes die zijn vastgelegd in constructiemodellen.
Dit wordt mogelijk door bibliotheken aan te leggen die de relevante details beschrijven voor veel gebruikte ontwerpeenheden. Op basis van de constructiemodellen kunnen we dan via modeltransformaties de informatie uit deze bibliotheken parametriseren en combineren tot geschikte AVV-modellen. Zo zijn er bijvoorbeeld drie configuraties van een bepaald bord beschikbaar. Voor het constructiemodel selecteren we er daar een van. Vervolgens worden de bijbehorende cache-eigenschappen van de processor er voor het AVV-model bij gezocht in een bibliotheek.
Davinci-Wings hebben we samen met het Embedded Systems Institute geïnitieerd. Dit project had als doel om een model te bouwen dat de (timing)prestaties van de embedded besturingen kan verifiëren. Een domeinspecifiek model representeert de keuzes van de ontwerpers. Dit model is onderverdeeld in een gescheiden applicatie-, platform- en mapping-model volgens het Y-chart-paradigma. Hieruit genereren we een executeerbaar prestatieanalysemodel op basis van de Poosl-taal van de TUE-vakgroep Electronic Systems.
Vorig jaar is de eerste generatie opgeleverd en toegepast op een ASML-case. Dat leverde inzichten op in de aspecten die de prestaties beïnvloeden. Uit deze resultaten hebben we een pakket maatregelen afgeleid waarmee we nu ook daadwerkelijk verbeteringen kunnen doorvoeren. Ook toonden we aan dat ontwerpalternatieven met behulp van de modellen gemakkelijk en snel zijn door te rekenen, zodat je een onderbouwde ontwerpkeuze kunt maken. De modellen leveren een uitstekende basis voor een prestatiegebaseerde architectuur en technologieroadmap.
In deze eerste versie werd het domeinspecifieke model nog handmatig afgeleid uit het bestaande ontwerp. Vorig jaar startte echter het vervolgproject Davinci–Wings2. Doel is nu om een volledig automatische koppeling met de ASML-ontwerpwereld te maken. Daarmee kunnen we modelgebaseerde prestatieanalyse en verificatie daadwerkelijk inpassen in het bestaande ontwerptraject. Verder besteden we extra aandacht aan de mechatronische context (waarin de besturingen en dus ook de prestatiemodellering opereren). Dit laatste is essentieel omdat hier de basis ligt van de redenatie over het te realiseren (sub)systeem.
Op dit moment bevat het model alleen de informatie die nodig is voor de prestatieanalyse. Het is echter mogelijk om synergie met de constructiewereld te realiseren als het model voldoende informatie bevat om daaruit (delen van) de software voor het embedded systeem te genereren. De AVV-wereld en de constructiewereld hebben dan een gemeenschappelijke bron. In Figuur 2 worden de gestippelde pijlen dan omgedraaid.
Brugarchitecten
In de modelgedreven aanpak ontstaat een omgeving met gereedschapsmakers (het ’secundaire proces‘) en gereedschapsgebruikers (het ’primaire‘ proces). Gereedschapsmakers zorgen voor de middelen waarmee de verschillende aspecten van een systeem goed zijn te beschrijven en voor de ontwikkeling van generatoren om deze beschrijvingen te transformeren naar targets die op het systeem kunnen worden geïnstalleerd. De gereedschapsgebruikers zetten deze middelen vervolgens in. Bij een bedrijf als ASML ligt de focus op de ontwikkeling van complexe mechatronische systemen. De gereedschapsgebruikers, werkzaam in het primaire proces, nemen daar de belangrijkste plaats in.
Een interessant gevolg van deze werkwijze is dat het werkgebied van de softwareontwikkelaar verandert. Voorheen werd zijn bijdrage direct in het systeem toegepast, maar bij het gebruik van constructiemodellen is deze code meer en meer het resultaat van generatoren. Softwareontwikkelaars zijn steeds meer bezig met het ontwikkelen van de modellen (als gereedschapsgebruikers) of met het maken en/of configureren van de codegeneratoren (als gereedschapsmakers). Het is niet ongewoon dat ontwikkelaars met affiniteit voor hardware minder interesse tonen voor het werken aan codegeneratoren. Hun kennis zal steeds meer verschuiven van softwareontwikkeling naar het systeem onder ontwikkeling.
De gereedschapsmakers bestaan uit DSL- en modelleringspecialisten. Van hen verwachten we ook verstand van modelintegratie. Zij dienen in staat te zijn het overzicht te bewaren over de verzameling (meta)modellen en verbanden ertussen te kunnen leggen of definiëren. Deze specialismen zijn traditioneel niet altijd bij systeembouwers te vinden en kunnen wellicht beter worden ingekocht of ingehuurd in plaats van zelf ontwikkeld.
Naarmate de omgeving van gereedschapsmakers en -gebruikers zich verder uitkristalliseert, wordt ook de behoefte aan een brugfunctie zichtbaar. Er zijn architecten nodig die de verschillende aspecten van het systeemdomein kunnen vertalen naar specificaties voor de gereedschapsmakers. Domein- en taaldefinitie vergen andere capaciteiten dan implementatie op een embedded platform. Deze brugarchitecten moeten beschikken over abstractievermogen en inzicht in de mogelijkheden en beperkingen van de modeltechnologie.
Migratie naar een modelgedreven ontwikkelmethode brengt veranderingen in de werkwijze met zich mee. Dat gaat vaak met weerstand gepaard. Projectmanagement is dan ook belangrijk. Formele verificatie met een AVV-model kan fouten vroegtijdig aan het licht brengen, terwijl ze anders pas tijdens integratie geconstateerd zouden worden. Maar er moet wel tijd en ruimte zijn om deze AVV-modellen te maken en te gebruiken.
Ook de communicatie tussen verschillende disciplines verandert bij een modelgedreven aanpak. Waar de communicatie tussen disciplines vaak informeel was, zal dit in de modelgedreven aanpak formeler zijn om relaties te leggen tussen verschillende modellen. De invoering van een modelgedreven aanpak voor de softwareontwikkeling heeft dus ook invloed op de andere disciplines. Hiervoor is onderlinge afstemming vereist. De aanpak heeft dan ook alleen kans van slagen als de betrokkenen daaraan mee willen werken.
Editors
Het ontwikkelen van talen en ontwikkelomgevingen voor de constructie- en AVV-modellen is niet triviaal. Gespecialiseerde tools die de gereedschapsmakers hierbij helpen, zijn daarom essentieel. De laatste jaren zijn deze gereedschappen sterk verbeterd en gestandaardiseerd.
De gespecialiseerde tools die ons ondersteunen bij de ontwikkeling van DSL‘s zijn gebundeld in de DSL-toolkit. Deze helpt de gereedschapsmaker met het definiëren van metamodellen. Dit kan door een geheel nieuwe taal te ontwikkelen of door een reeds bestaande taal aan te passen. Daarnaast biedt de toolkit de mogelijkheid om editors te ontwikkelen om een model te maken en te onderhouden. Hierin zijn grofweg twee categorieën: tekstuele notaties zoals programmacode en grafische notaties zoals het UML-classdiagram. Uit de praktijk blijkt dat de beste notatie sterk afhankelijk is van persoonlijke voorkeuren en de aard van het probleem. Dankzij de toolkit kunnen we verschillende representaties van hetzelfde model bieden en toch de consistentie ertussen garanderen.
Een andere belangrijke rol van de DSL-toolkit is het helpen bij de ontwikkeling van modeltransformaties. Deze zijn verantwoordelijk voor de automatische constructie van een softwaresysteem uit constructiemodellen. Analoog kunnen modeltransformaties worden gecreëerd om vanuit de constructiemodellen de AVV-modellen af te leiden. De toolkit bevat talen die speciaal voor dit soort transformaties zijn ontwikkeld. Wij gebruiken bijvoorbeeld QVT om model-naar-modeltransformaties te definiëren. Deze bevatten mappings met eenduidig vastgelegde regels om (verzamelingen van) concepten uit het ene metamodel te vertalen naar (verzamelingen van) concepten in een ander metamodel. Transformaties van model naar tekst, bijvoorbeeld om programmacode te genereren, realiseren wij met een templategebaseerde transformatietaal zoals XPand.
Daarnaast biedt het systeem de mogelijkheid om verschillende transformaties zelfstandig in een bepaalde volgorde uit te voeren. Dat is een vereiste voor de automatische constructie van het softwaresysteem.
Essentieel detail
Bij de modelgedreven aanpak moeten alle codegerelateerde procesaspecten worden meegenomen. Denk bijvoorbeeld aan parallel ontwikkelen en de releasestrategie. Waar nu meer ontwikkelaars parallel aan code van een (sub)systeem werken, zullen ze in een modelgedreven aanpak met een gezamenlijk model ervan bezig zijn. Daar zijn mogelijk meerdere disciplines bij betrokken.
Bij code worden conflicten tussen verschillende opleveringen tekstueel gerepresenteerd. De tooling is onbekend met de implementatietaal en zal geen onderscheid maken tussen de relevante en niet-relevante verschillen. Het napluizen van deze verschillen en het oplossen van de conflicten is een foutgevoelig proces. Bij tooling die de modelgedreven aanpak expliciet ondersteunt, wordt het mogelijk de nadruk te leggen op de relevante verschillen. Door deze in een domeinspecifieke taal weer te geven, kan de kans op fouten ook worden verkleind.
Stel je bijvoorbeeld voor dat de initialisatiesequentie van een systeem wordt beschreven in termen van initialisatiestappen die in modules worden gerealiseerd. Indien twee versies van de sequentie met elkaar worden vergeleken, zou een taalspecifieke vergelijkingstool de verschillen kunnen weergeven met uitspraken als: ’versie X bevat een additionele initialisatiestap Y‘ of ’initialisatiestap Z verwijst naar een andere realisatie‘.
Het releasen van software baseren we nu op de toestand van het codearchief op een bepaald moment in tijd, een baseline. In de modelgedreven aanpak zal er een modellenarchief ontstaan waaruit baselines kunnen worden gegenereerd. Het archief moet modellen van verschillende disciplines kunnen bevatten. Die modellen moeten zelf geschikt zijn voor het definiëren van relaties tussen entiteiten in modellen van verschillende disciplines.
Bij een conventioneel ontwerpproces wordt ontwerpinformatie op een informele manier vastgelegd en bestaat validatie van het ontwerp uit een review van de (informeel weergegeven) documentatie. Dat wordt in de modelgedreven aanpak vervangen door het opstellen en valideren van de executeerbare AVV-modellen. Dit vereist behalve een formalisme ook een zekere mate van volledigheid. Bij een review van een informele ontwerpbeschrijving kan het gebeuren dat een voor correctheid essentieel detail ontbreekt en er bij de implementatie een fout wordt gemaakt. Om dit te voorkomen, is het van belang dat een formele verificatie het ontbreken van essentiële details detecteert. Dit ’dwingt‘ ontwerpers om deze informatie vast te leggen.
Een nadeel is dat het hierdoor kan lijken dat de modelgedreven aanpak meer inspanning vereist. Maar de informatie had eigenlijk ook deel moeten uitmaken van de informele beschrijving en bovendien zal het herstellen van een dergelijk gebrek tijdens implementatie meer tijd en kosten met zich meebrengen dan het voorkomen ervan.
Systeeminzicht
Uit de resultaten van onze interne projecten blijkt dat de gebruikers DSL‘s voor constructie als natuurlijk ervaren. De vooral grafische representaties sluiten goed aan op hun beleving. De reviews met de gegenereerde documentatie leiden tot discussie over de inhoud in plaats van over onnodige details of vorm. Bovendien is de drempel om te beginnen laag, omdat de eerste gegenereerde implementatie out-of-the-box werkt. Waar in het verleden redesigns soms duur waren, kunnen we nu het model aanpassen en code hergenereren.
Bij AVV-modellen ligt de focus vooral op risicovolle of kostbare ontwerpaspecten. Een goed voorbeeld is de uiteindelijke timingperformance van een realtime embedded systeem. Hier konden we aantonen dat het mogelijk is om voorspellingen te doen en alternatieve configuraties vooraf door te rekenen. Verder geeft het maken en kalibreren van de modellen op zichzelf al veel systeeminzicht omdat de benodigde kennis uit verschillende disciplines komt. Ook het creëren van dat systeemoverzicht helpt de besluitvorming en vergroot de zekerheid doordat disciplineonafhankelijk redeneren mogelijk is geworden.
Wilbert Alberts, Theo Baan, Niels Brouwers, Marc Hamilton en Wouter Tabingh Suermondt zijn werkzaam bij ASML