Nucletron en Verum evalueren CT-scansoftware

Begin dit jaar lanceerde Verum zijn Analytical Software Design (ASD)-tools voor het ontwikkelen van mathematisch bewezen correcte software. Daar ging een lang ontwikkeltraject aan vooraf, waarin het bedrijf uit Waalre zijn gereedschappen uitprobeerde bij verschillende bedrijven. Bestaande softwareonderdelen werden daar opnieuw in elkaar gezet om te kijken of dit de gewenste resultaten opleverde. Ook met Nucletron, ontwikkelaar van bestralingsapparatuur voor tumoren, voerde Verum rond de jaarwisseling zo‘n evaluatieproject uit. ’Het doel van de exercitie was om te kijken hoe snel en correct we het gedrag van het systeem konden nabouwen‘, vertelt Cis van Heerde, applicatieontwikkelaar bij Nucletron, die het project samen met collega Berthold Hutten uitvoerde.

Als onderdeel van zijn productlijn heeft Nucletron de Simulix Evolution, een CT-scanner met conische bundel. Dit apparaat wordt gebruikt om de bestralingsstrategie uit te stippelen. Voor zijn ASD-vingeroefening koos Nucletron een deel van de Simulix Evolution-software. Dit stuk is verantwoordelijk voor de driedimensionale reconstructie van de detectorgegevens en de omzetting in een 2D- of 3D-afbeelding. De beelden worden ook weggeschreven naar een opslagmedium om ze later weer op te vragen. De Simulix Evolution is al enkele jaren op de markt. ’We hadden een stuk software dat al meerdere iteraties had doorlopen, waar we al jaren aan gespendeerd hadden en waar we al veel fouten uit hadden gehaald‘, zegt Van Heerde. Veel nieuwe fouten waren er dan ook niet te verwachten.

Gaten

Het gekozen stuk software bestaat uit drie delen. De Reconstruction Handler is het onderdeel dat de daadwerkelijke 3D-reconstructies uitvoert. Deze software bevat een interface naar een server met de onbewerkte sensordata. De Storage Handler verzorgt het wegschrijven van de beelden. Om het hele proces aan te sturen, is er de Acquire Reconstruction Handler. ’We hebben de Storage Handler helemaal opnieuw gemaakt met de ASD-tools‘, vertelt Ronald Wiericx, die het proces vanuit Verum begeleidde. ’De Reconstruction Handler hebben we niet helemaal voor elkaar gekregen binnen de beschikbare tijd. Daar waren best wat semantiekverschillen.‘

De software voor de Simulix Evolution heeft Nucletron ontwikkeld zoals de meeste organisaties dat doen: via het watervalmodel. Eerst worden de specificaties en requirements opgesteld, daarna wordt de software ontworpen, vervolgens geïmplementeerd en ten slotte zwaar getest en verbeterd totdat het systeem voldoende betrouwbaar is. De Nucletron-engineers gebruiken hierbij UML om het ontwerp in kaart te brengen.

Met de requirements die er al lagen vanuit de oorspronkelijke ontwikkeling gingen Nucletron en Verum opnieuw aan de slag om de modellen op te stellen die vereist zijn voor de ASD-tools. Het gaat hierbij om twee modellen: een interfacemodel dat beschrijft wát het component doet en een designmodel dat beschrijft hóe.

Het interfacemodel omvat alle interacties tussen de verschillende softwareonderdelen. Het Verum-gereedschap kan daarmee controleren of er geen fouten zitten in de manier waarop zij met elkaar omgaan. Deadlocks, livelocks en racecondities komen in deze stap boven water. Ook dwingt het proces tot het specificeren van responsies voor elke component. ’Zo kun je gaten in de specificatie van je requirements vinden‘, legt Wiericx uit.

Het overzetten van de Nucletron-specs naar een ASD-interfacemodel bleek vrij rechttoe rechtaan. ’Waar we tegen aanliepen, waren puur inleerproblemen die je met elke nieuwe software hebt‘, vertelt Van Heerde. ’Nucletron werkte al op een hele nette manier met UML-modellen‘, vult Wiericx aan. ’Daardoor hadden ze een soortgelijk tabelvorm als we in ASD hanteren.‘

Ook het designmodel, dat ingaat op het hoe, bleek niet voor grote problemen te zorgen. Alleen de data en controle moesten beter gescheiden worden, een vereiste voor de ASD-tools.

Vervolgens kon het gedrag van de component worden geverifieerd. Volgens de Verum-tool waren er ruim driehonderd verschillende uitvoeringsscenario‘s in de Storage Handler. De check bracht direct een raceconditie en een livelock in het ontwerp aan het licht. ’Het bleek dat de software kon vastlopen als de opslagserver een specifieke terugmelding niet gaf‘, vertelt Van Heerde. ’In een echte situatie controleert de software altijd eerst de hoeveelheid beschikbare data en zou het niet kunnen voorkomen, maar die check hadden we niet in het ASD-model gestopt. Prettig was dat de tools je dwingen om goed na te denken over je ontwerp en het gedrag daarvan.‘

De Reconstruction Handler bleek lastiger om te zetten. ’Onze software was in een enkele thread uitgevoerd. Daar hadden we bewust voor gekozen om de synchroniteit onder controle te krijgen‘, vertelt Van Heerde. ’Verum ontkoppelt asynchrone callbacks echter via een aparte callbackthread.‘ Uit de modelcheck kwam dan ook een berg aan racecondities naar boven, die in het daadwerkelijke systeem niet aan de orde waren. ’Zouden we de software herschrijven voor ASD, dan zouden we het ontwerp anders opzetten. Voor deze evaluatie was te veel werk‘, zegt Van Heerde. ’Maar we hebben wel gezien dat het meerwaarde geeft voor toepassingen met complex gedrag.‘ Nucletron zal ASD daarom zeker weer gaan gebruiken bij de ontwikkeling van nieuwe complexe software.