Thermo Fisher Scientific heeft smaak te pakken van modellering
Zo’n drie jaar geleden begon Thermo Fisher Scientific in Eindhoven aan een reis om modelgebaseerde ontwikkeling naar een hoger plan te tillen. In nauwe samenwerking startten software- en systeemarchitecten met de verkenning van verschillende technieken. Na pilots met onderzoekpartners maakt het bedrijf nu succesvolle stappen met commerciële tools van onder meer Axini en Obeo.
‘Voor onze transmissie-elektronenmicroscopen hebben we drie productfamilies: instapniveau, middenklasse en high-end’, zegt Olivier Rainaut, r&d-manager systeemarchitectuur bij Thermo Fisher Scientific in Eindhoven. ‘Binnen deze productlijnen, met alle opties en accessoires, hebben we meer dan duizend actieve configuraties. Dat is meer dan we r&d-engineers hebben in Eindhoven.’
Deze ingenieurs, nu bijna vierhonderd in getal, doen niet alleen r&d. ‘Onze systemen blijven twintig jaar of langer actief. Al die tijd moeten ze beschikken over de nieuwste versies van de besturings- en applicatiesoftware, de juiste netwerkinstellingen en de nieuwste beveiligingspatches’, benadrukt Rainaut. ‘Ons werk houdt niet op als we een nieuwe module hebben ontwikkeld en geïmplementeerd; het is ook onze plicht om alles in de lucht en bruikbaar te houden.’
De sleutel tot het draaiende houden van alle systemen in het veld is volgens Rainauts collega Arjen Klomp goed interfacebeheer. ‘Gedurende hun levensduur worden de microscopen voortdurend geüpgraded en bijgewerkt met nieuwe hardware- en softwaremodules en -applicaties’, zegt de softwareontwikkelmanager. ‘We moeten niet alleen achterwaartse compatibiliteit met veel verschillende versies garanderen maar ook bewijzen dat wanneer we een interface wijzigen alles correct blijft werken.’ Om deze multidimensionale interfacebeheeruitdaging aan te gaan, investeert het Eindhovense r&d-team fors in modelgebaseerde systeemengineering (MBSE).
Softwaremodellen
De MBSE-push is ongeveer drie jaar geleden ingezet. ‘We merkten dat de toenemende complexiteit het onze engineers steeds moeilijker maakte om hun weg te vinden in het systeem- en softwareontwerp’, herinnert Klomp zich. ‘Dus hebben we besloten om een makkelijk toegankelijke kennisbank te bouwen die mensen kunnen raadplegen als ze vragen hebben over het systeem. Modellen spelen een grote rol bij het creëren van zo’n single source of truth.’
‘Tijdens het ontleden van de software realiseerden we ons dat we de interfaces formeel moesten definiëren en wijzigingen gecontroleerd moesten doorvoeren’, vervolgt Klomp. ‘Tegelijkertijd zagen we tijdens de integratie veel problemen de kop opsteken omdat de interfacedefinitie weliswaar hetzelfde was gebleven, maar het interfacegedrag was veranderd. Dit deed ons beseffen dat het niet genoeg is om de syntax van een interface te definiëren; je moet ook de semantiek beheren. Kort daarna zijn we een project gestart met TNO Esi om dit probleem aan te pakken.’
Voortbouwend op het Comma-framework was de exercitie met Esi – zoals Klomp het omschrijft – bedoeld om zowel de syntax als de semantiek van subsysteeminterfaces te modelleren. ‘We hebben geleerd dat dit echt helpt om systeemgedrag beter te begrijpen. De modellering stimuleert vroege ontwerpdiscussies. Het maakt ook modelgebaseerd testen mogelijk: in plaats van eerst te implementeren en vervolgens tests te schrijven op basis van de implementatie, kun je al tests maken op basis van de interfacedefinities en vervolgens implementeren tegen die tests. Zo heeft de Comma-exercitie ons geholpen om verschillende defecten te ontdekken en op te lossen.’
Dit zorgde ervoor dat Klomp en zijn softwareteam de smaak te pakken kregen en meer wilden modelleren. ‘Om een tool op grotere schaal binnen een bedrijf in te zetten, heb je twee dingen nodig: managementondersteuning, om de benodigde middelen veilig te stellen, en buy-in op de werkplek, zodat mensen het gaan gebruiken. Voor dat laatste hebben we naar een aantal criteria gekeken, waaronder de volwassenheid van de tool en de ondersteuning vanuit de leverancier. Na een zorgvuldige afweging hebben we gekozen voor Axini voor het modelleren en testen van de subsysteeminterfaces. Die tool was de enige die commercieel beschikbaar was voor modelgebaseerd testen en het was de meest volwassen oplossing, met veel meer functies en zeven tot acht jaar meer historie dan academische alternatieven.’
Systeemmodellen
In 2020 werd de modelgebaseerde push uitgebreid naar systeemniveau, waar Rainaut en zijn team dezelfde exercitie deden om de MBSE-tool te selecteren die het beste bij hun doeleinden past. Uit een groot aantal opties, waaronder Sparx Enterprise Architect, IBM Rhapsody en Dassault 3DX, kozen ze de open-source Eclipse-gebaseerde Capella-tool, via het cloudgebaseerde aanbod van Obeo. ‘We gebruiken Capella voor systeemdecompositie op een SysML-achtige manier – voor hardware en software, tot aan interfacemapping’, vertelt Rainaut.
Voorafgaand aan de toolkeuze zijn de systeemarchitecten volgens een standaard werkwijze in Visio aan de slag gegaan. ‘Dat vonden ze niet leuk, omdat alles met de hand moet en er geen link is tussen de verschillende decompositielagen’, zegt Rainaut, ‘maar het dwong hen om hun gedachten over de systemen te structureren en de architectuurbeschrijvingen in een digitale vorm te gieten. Momenteel hebben we meer dan 80 procent van de architectuur op deze manier afgedekt, dus we zijn redelijk dicht bij die single source of truth.’
Het project om het systeem in Capella te ontleden, is afgelopen zomer van start gegaan. Rainaut: ‘Door ze eerst Visio te laten gebruiken om alles vast te leggen, hebben we een gemeenschappelijke manier van werken afgedwongen en hebben we de contentbeschrijving losgekoppeld van de te selecteren tool. Volgens mij was dat een geweldige opstap naar MBSE. In allerlei proefprojecten doen we nu steeds meer in Capella. Het uiteindelijke doel is natuurlijk om alles daar en in een gekoppeld ecosysteem te hebben.’
MBSE-landschap
Met behulp van Capella wordt de transmissie-elektronenmicroscoop opgedeeld in subsystemen, dat wil zeggen: in combinaties van hardware en software, onderling verbonden door high-level interfaces. Denk bijvoorbeeld aan een camera, een lens of een samplelader. Eén zo’n subsysteem bevat een aantal softwarecomponenten, die zelf weer interfaces hebben met aangrenzende componenten en die specifieke functionaliteit realiseren. Sommige componenten verwerken gegevens door algoritmes uit te voeren, andere leiden de uitvoering in goede banen.
‘De high-level subsysteeminterfaces modelleren we, en testen we ook steeds vaker, met Axini’, vertelt Klomp. ‘Door een zogeheten test clam rond een subsysteem te creëren, kunnen we zowel de aangeboden interfaces als hun relatie met de vereiste interfaces modelleren. Dit maakt het mogelijk om fouten te injecteren, waardoor we het goedweergedrag kunnen testen. Door de vereiste interfaces te manipuleren, kunnen we bovendien slecht weer veroorzaken en checken of de geboden interfaces de verwachte respons geven.’
‘Met Dezyne van Verum modelleren we de besturingscomponenten binnen de subsystemen en controleren we of ze doen wat ze moeten doen, namelijk of ze voldoen aan hun interfacespecificaties’, vervolgt Klomp. ‘Let wel dat we het hier hebben over discrete toestandscontrole. Voor continue fysieke controle, bijvoorbeeld om de samplelader te verplaatsen, maar ook voor andere soorten dataverwerking, ga je meer richting Mathworks-achtige modellering.’
Waar Axini en Verum soms als concurrenten worden gezien, zijn ze voor Klomp juist complementair. ‘Axini is meer een tool voor interfaceverificatie op systeemniveau’, verduidelijkt hij. ‘Terwijl we afdalen in het MBSE-landschap en steeds meer details en verfijning toevoegen, komen we op een bepaald moment op het niveau van softwarecomponenten en betreden we het domein van Dezyne.’
Uitbetalen
Klomp is erg blij om te zien dat de MBSE-push zijn vruchten afwerpt. ‘De modellering dwingt mensen om vooraf goed na te denken. Het is niet langer mogelijk om je toevlucht te nemen tot een Powerpoint-architectuur en het vervolgens aan de ingenieurs over te laten om de problemen op te lossen. De tools laten duidelijk zien waar een ontwerp niet werkt en het is aan de architecten om oplossingen te vinden. In het begin waren degenen die niet bekend waren met de aanpak erg terughoudend om hun werkwijze aan te passen, maar de mentaliteit is veranderd. Omdat ze daadwerkelijk fouten vinden en oplossen, valt niet meer te ontkennen dat het werkt.’
Modellering gaat ook zeer nuttig zijn bij de aanpak van een van de grote testuitdagingen in de hightech op dit moment: de schaarste aan hardware om op te testen. ‘Dat wordt voor ons steeds meer een probleem’, erkent Klomp. ‘Omdat ze zo groot en kostbaar zijn, zijn er om te beginnen niet zo veel fysieke testsystemen. En naarmate de behoefte aan testen toeneemt, wordt het alleen maar moeilijker om machinetijd voor tests te reserveren. Bovendien kunnen we de meer dan duizend actieve configuraties onmogelijk allemaal fysiek testen. Daarom draaien we steeds meer van onze tests in een virtuele omgeving – met behulp van modelleertools zoals Axini, waarmee we interfaces kunnen testen zonder dat alle componenten beschikbaar hoeven te zijn.’
De beslissing om naar een single source of truth te gaan – uiteindelijk in Capella – met een gemeenschappelijke manier van werken, betaalt zich ook op andere manieren uit. Rainaut: ‘Toen iedereen nog vrij was om zijn eigen tool voor architectuurbeschrijving te kiezen, was het onmogelijk om een volledig overzicht te krijgen en zeer tijdrovend om systeemspecificaties te achterhalen. Met de modellen, onder het toeziend oog van change control boards, hebben we deze gemeenschappelijke basis nu wel. Het stelt ons in staat om betere discussies te voeren over de architectuur en veel sneller informatie te vinden en decomposities te doen. Het is ook veel makkelijker geworden om nieuwe medewerkers het systeem te laten leren kennen, wat des te belangrijker is omdat het r&d-team in Eindhoven snel groeit – alleen al vorig jaar hebben we meer dan honderd mensen aangenomen.’
Externe samenwerking
En er liggen nog meer voordelen in het verschiet. ‘Performancevoorspelling’, geeft Rainaut als voorbeeld. ‘De tijd tot resolutie, dus hoe lang het duurt voordat de elektronenmicroscoop het gewenste beelddetail bereikt, is een belangrijke maatstaf voor onze klanten. Vroeger deden we allerlei berekeningen in Matlab of zelfs Excel om daarvoor een schatting te kunnen afgeven. Nu zouden we bijvoorbeeld kunnen beginnen met tolerantiebudgettering op basis van in Capella gemaakte architectuurmodellen, of deze modellen verbinden met een prestatie-analysetool zoals Poosl van Esi en simulaties uitvoeren om te controleren of een ontwerp voldoet aan onze doelstelling voor tijd tot resolutie. Dit geeft ons een stevige kwantitatieve basis voor ontwerpverbeteringen. Een van onze speerpunten voor 2022 is het koppelen van de architectuurmodellen aan de simulatiemodellen.’
Naast de interne ontwikkeling kan modelgebaseerd interfacebeheer ook de externe samenwerking stroomlijnen. ‘Bij het communiceren en integreren van technologieën met partners en leveranciers helpt het echt om een duidelijk gedefinieerde lijst met interfaces te hebben’, vindt Rainaut. ‘Het op één lijn brengen van beide kanten is daar de grote uitdaging. Een ander aandachtspunt voor dit jaar is dan ook de verdere integratie van onze systeemmodellen met die van hen.’ Klomp heeft een vergelijkbare prioriteit voor zijn softwareteam: ‘In 2022 wil ik, ondersteund door Axini, Verum en onze andere toolpartners, onderzoeken hoe we onze modelgebaseerde technologieën kunnen uitbreiden naar ons toelevernetwerk.’
Dit artikel is geschreven in nauwe samenwerking met Axini.
