CCM past al enkele jaren succesvol een modelgebaseerde aanpak toe op het gebied van regeltechiek. De controlesoftware, die de regie voert over de verschillende regelsystemen, vereist echter een andere aanpak. Bij de ontwikkeling van een Philips-scanner voor microscoopglaasjes werd voor het eerst Verums ASD-aanpak ingezet. De nauwkeurige specificatie van de interfaces die deze methode afdwong, vereenvoudigde de integratie van de deelsystemen aanzienlijk. Een waardevolle aanvulling op de vertrouwde Mathworks-tooling.
Al 42 jaar bedienen we bij CCM de hightechindustrie met mechatronische oplossingen, in een breed applicatiedomein en voor een diversiteit van klanten. In die jaren hebben we heel wat veranderingen meegemaakt, maar de laatste jaren lijkt deze industrie in een stroomversnelling te zijn gekomen. Nieuwe technologieën dienen zich in een rap tempo aan. We zien een toename in functionaliteit en prestatie in de producten en machines die we voor onze klanten ontwikkelen.
Daarnaast zijn ook de businessmodellen en manieren van samenwerken aan het veranderen. We zien steeds vaker dat CCM risicodragend participeert in een productontwikkeling met meerdere partners. In de rol als systeemintegrator moeten we de verschillende deelstukken tot een geheel samensmelten dat zijn functies volgens de specificatie uitvoert. Dat moet steeds sneller, door toenemende druk van de markt en de concurrentie. Onze ontwerpers moeten in steeds minder tijd meer functionaliteit met betere prestaties en hogere betrouwbaarheid ontwikkelen. De systeemarchitecten moeten een raamwerk neerleggen waarmee deelsystemen en componenten parallel, door verschillende partijen tegelijkertijd, zijn te ontwikkelen. De integrator staat voor de uitdaging deze deelsystemen te integreren.
Enkele jaren geleden hebben we ons bij CCM gerealiseerd dat modelgebaseerd design kan helpen om hiermee om te gaan. Voor de mechatronica zetten we al een tijd met succes ontwikkelgereedschappen in van bijvoorbeeld Mathworks, 20-Sim en Ansys. Deze tools zijn voor CCM echter minder geschikt om de ’controle‘-software te ontwikkelen, die alle deelsystemen functioneel aan elkaar knoopt, maar er ook en vooral voor zorgt dat het systeem in orde is. Voor dit deel is recentelijk een op formele basis gestoelde maar praktisch hanteerbare modelgebaseerde aanpak beschikbaar gekomen, namelijk Verums Analytical Software Design-methode (ASD).
Temperatuur
Begin 2009 begon CCM samen met Frencken, Philips en Prodrive voor Philips Digital Pathology aan de ontwikkeling van een scanner voor microscopische glaasjes. De technische uitdaging was om ‘s werelds snelste scanner met de allerhoogste resolutie en beeldkwaliteit te ontwikkelen. Bovendien moesten we in twaalf maanden een eerste werkend prototype realiseren. Alle mechanische en elektronische hardware, de optiek en alle software, inclusief de nodige complexe algoritmes, hebben meerdere partners daarbij in een parallel traject ontwikkeld.
Bij dit project hebben we voor het eerst ASD naast de vertrouwde Mathworks-omgeving ingezet. In dit geval kwam de kracht van ASD vooral tot uiting bij het vastleggen van de interfaces tussen de componenten. Dat vereenvoudigde de uiteindelijke integratie van de door diverse partners ontwikkelde componenten aanzienlijk.
In de besturing van een mechatronisch systeem herkennen we, simpel gezien, drie controlelagen (Figuur 1). In de onderste laag, de fysische-controlelaag, wordt de hardware aangestuurd en geregeld. Denk hierbij aan servoregeling van beweging, temperatuur of een andere grootheid. Een wat complexere machine zal uit een groot aantal verschillende fysieke subsystemen bestaan. De laag daarboven, de behavioral control-laag, coördineert de interactie tussen de verschillende subsystemen. De normale processequentie en de afhandeling van uitzonderingssituaties gebeuren in deze laag. Op dit niveau zie je typisch parallelle processen die veel moeten communiceren en die vaak door middel van toestandsdiagrammen zijn te beschrijven. De bovenste laag in ons model is de user control-laag. Hiermee kan de gebruiker (of een ander systeem) interacteren met het systeem.
Machinecode
De onderste laag, waarin de fysica wordt beteugeld, is het domein van de Mathworks-tooling. Veel regeltechnici zijn hiermee al tijdens de studie in aanraking gekomen en we hebben een geavanceerde bibliotheek ontwikkeld met software- en hardwareonderdelen van waaruit systeemontwerpers het benodigde regeltechnische vraagstuk kunnen samenstellen. De bouwstenen in deze Saxcs-bibliotheek bieden een uniforme interface richting de behavioral control.
In de fysische-controlelaag worden rekenkundig gezien zeer verschillende eisen gesteld. Er zijn vraagstukken waarbij informatie in het MHz-domein moet worden geïnterpreteerd, zoals interpolatie van encoderinformatie. De uitkomst van die interpretatie kan veelal door digitale filters worden geleid met een bemonstertijd van typisch tweehonderd microseconden. Het komt echter ook voor dat die filters het signaal iedere vijf microseconden moeten doorrekenen. Parallel aan deze rekentaak staat er een toestandsmachine mee te doen om fysische transities op de gewenste manier te bewerkstelligen. Alle informatie komt samen in de processor van een standaard (industriële) pc, die onderdeel is van het product of apparaat.
We merken dat de eisentoename bij veel projecten vooral in deze onderste laag tot uiting komt. Mede hierdoor willen we tijdens de ontwikkeling zo vroeg mogelijk weten of bedachte oplossingen echt gaan werken. De modelgebaseerde aanpak helpt hierbij. Door een totaalsysteem, dus fysica plus regeltechniek, te modelleren, kan de haalbaarheid van de gestelde specificaties worden bevestigd. Hierbij doorloopt de ontwerper de cirkel van concept naar design en simulatie vaak een aantal keren. Ook kan de machinecode voor de processor met de Mathworks-gereedschappen worden gemaakt.
Daarnaast is de modelroute essentieel voor het concurrent engineering-proces. Als de regeltechnicus een oplossing met Saxcs heeft ’gecomponeerd‘, kan hij die op zijn eigen computer tot in detail doorrekenen en verifiëren. Vervolgens brengen we deze oplossing naar de beoogde besturingscomputer die in simulatiemodus staat, wat wil zeggen dat de fysica en beoogde regelstrategie worden nagebootst. De softwareontwerpers van de behavioral control kunnen zo in een vroeg stadium hun software integreren, interfaces verifiëren en testen tegen een realistische simulatie van het uiteindelijke systeem. Gedurende het project wordt gesimuleerde hardware stapsgewijs vervangen door echte hardware.
Voor de pathologiescanner is bijvoorbeeld het dynamische gedrag van de bewegende assen gemodelleerd. In een aantal iteraties (concept-design-simulatie) werd een ontwerp bereikt dat aan zowel de prestatie- als de kostprijseisen voldoet. Ook konden de eisen voor de implementatie helder worden doorgezet naar Prodrive, dat de daadwerkelijke aansturing heeft ontwikkeld. Parallel hieraan hebben we bij CCM een prototype besturing opgetuigd zodat we al het dynamische gedrag vooraf aan de totale integratie konden verifiëren.
Happy flow
In de fysische-controlelaag kom je typisch componenten tegen die een duidelijk afgebakende taak hebben met weinig onderlinge interactie. Voor de coördinatie tussen deze componenten is de behavioral control verantwoordelijk. Deze laag bepaalt in grote mate het gedrag van het systeem en regelt zowel de goedweer- als de slechtweerscenario‘s. Dit is het terrein waar de ASD-aanpak van Verum tot zijn recht komt.
Een ontwikkeling met ASD begint traditioneel met de requirementsanalyse. De softwarespecificatie die daaruit volgt, vormt de input voor de architectuurfase, die onder meer de beschrijving oplevert van de verschillende systeemcomponenten. Vervolgens maakt de ontwikkelaar voor iedere component een interface die het gedrag naar buiten toe modelleert en een designmodel dat het interne gedrag beschrijft. Dit gebeurt in een beschrijvingstaal die softwareontwerpers goed kunnen toepassen zonder kennis van de formele wiskunde. De Verum-tools vertalen de modellen onder water wel naar een formele taal, waarna een model-checker de correctheid verifieert en op ontwerpfouten wijst zoals racecondities, deadlocks, livelocks, et cetera. Als het model correct is, wordt het met de codegeneratieknop naar, in ons geval, C++ geconverteerd. De Verum-tooling ondersteunt ook diverse andere talen.
Door ASD in te zetten voor de behavioral control-software bij de ontwikkeling van de Philips-scanner konden we het complete gedrag van het apparaat specificeren – zowel de ’happy flow‘ als de uitzonderingsscenario‘s. De ASD-aanpak dwong om alle software-interfaces inclusief alle gedragsaspecten goed vast te leggen. Dit gold ook voor de interfaces van de deelsystemen ontwikkeld door de verschillende partners.
Met name dit aspect bleek een groot voordeel van de Verum-aanpak. Ondanks de complexiteit van het project – niet alleen van het apparaat maar ook van de samenwerking met meerdere partijen – kon de integratie van software en hardware binnen enkele dagen succesvol worden afgerond. Normaal zou dat eerder in de maanden lopen.
Achilleshiel
De modelgebaseerde aanpak biedt ons de nodige handvatten om systeemontwikkeling naar het vereiste hogere plan te tillen qua functionaliteit, prestaties en betrouwbaarheid in minder tijd, en is een goede manier om samen te werken met verschillende ontwikkelpartners. Maar er worden ook eisen gesteld aan de organisatie. Zowel voor de Mathworks- als de Verum-aanpak geldt dat er meer tijd moet worden geïnvesteerd in de specificatie- en ontwerpfase van een project. Project- en lijnmanagement moeten zich hiervan bewust zijn. Zeker in de eerste projecten kan dit spanningen opleveren. De aanpak stelt ook eisen aan de ontwerpers. Er wordt meer gevraagd van hun abstraherende en analytische vermogens. Van een ontwerper wordt daarbij een precisie verwacht die niet bij iedereen even goed zal passen. Hij wordt gedwongen om compleet te zijn, ook als hij dat niet wil.
Via training zijn de methodes goed te leren. Investering hierin is belangrijk, maar echt goed modelgebaseerd ontwikkelen is het best te leren door het te doen. Reken op een forse investering in ’learning on the job‘ en zet hierbij liefst ervaren ontwerpers in. Bij ASD hebben we bijvoorbeeld moeten werken aan een set designpatronen die een goed met ASD realiseerbaar ontwerp opleveren. Wie te veel vasthoudt aan een bestaand design of bestaande aanpak kan behoorlijk uit de bocht vliegen. Belangrijk is ook te leren wanneer de methodes optimaal zijn in te zetten en wanneer de traditionele aanpak volstaat.
ASD is vooral zeer geschikt om gedrag te modelleren. De formele verificatie helpt om fouten er zo veel mogelijk in het ontwerptraject uit te halen en automatische codegeneratie verkort het implementatietraject aanzienlijk. Het kleine aantal echte softwarefouten dat we in de periode erna vonden, toont aan dat de kwaliteit hoog is. Maar de grootste winst zit in de systeemintegratie. Hiermee wordt de extra tijd van de specificatie- en architectuurfase ruimschoots goedgemaakt. Dataprocessing is echter de achilleshiel van de aanpak. Dit is juist een domein waar de Mathworks-tooling sterk is. In combinatie goed ingezet geldt dat een en een drie is.