René Schott is systeemengineer bij Macawi.

6 December 2011

De beademingsapparaten die Macawi ontwikkelt, beginnen hun leven als Matlab/Simulink-model en worden stapsgewijs omgezet naar de fysieke wereld. Met deze modelgebaseerde benadering kan het systeem al vroeg worden geperfectioneerd en is er een constante koppeling met de requirements mogelijk.

Een probleem met de longen of luchtwegen, een verstoring in het signaal van de hersenen naar de longen: als een patiënt niet in staat is om de uitwisseling van zuurstof en CO2 zelfstandig en voldoende in stand te houden, moet een beademingsapparaat die functie overnemen. Bij Macawi ontwikkelen en produceren we dergelijke apparaten voor uiteenlopende toepassingen met eveneens uiteenlopende eisen. In een helikopter moeten ze bijvoorbeeld bestand zijn tegen sterke trillingen en schokken. Bij emergency care-systemen is het belangrijk dat het ook buiten in de kou, bij regen of juist in een stoffige, warme omgeving correct blijft functioneren. Op de intensive care moeten ze grote volumes lucht kunnen pompen voor volwassenen of milliliters voor pasgeboren baby‘s. Daar moeten ze ook breed inzetbaar zijn en zo min mogelijk valse alarmen genereren, zodat verplegend personeel en artsen niet onnodig worden afgeleid.

Het beademingsapparaat, ook wel ventilator genoemd, moet ook in alle denkbare situaties betrouwbaar blijven werken. In de Europese Unie worden medische hulpmiddelen ingedeeld in vier risicoklassen. Beademingsapparatuur zit in de op één na hoogste klasse, omdat er schade aan de patiënt toegebracht kan worden als het apparaat niet goed functioneert. Om de veiligheid en effectiviteit te kunnen garanderen, wordt er veel aandacht besteed aan de verificatie van deze systemen.

Bij Macawi pakken we dit aan met een modelgebaseerde ontwikkelmethode. Nadat de requirements zijn opgesteld, ’bouwen‘ we het nieuwe systeem eerst volledig op in Matlab en Simulink. Vervolgens voegen we hier stapsgewijs steeds meer van de echte wereld aan toe. Bij elke stap kunnen we testen of het systeem nog aan de requirements voldoet, en waar nodig bijsturen.

Macawi ontwikkelt beademingsapparatuur die met een blower lucht rondpompt.

Slijtende onderdelen

De requirements komen voornamelijk van de klant, maar voor een groot deel vloeien ze ook voort uit de normen waaraan een medisch apparaat moet voldoen. Er zijn zowel algemene normen voor medische systemen als specifieke voor beademingsapparatuur. De belangrijkste die op dit moment voor de ontwikkeling van beademingsapparatuur worden gebruikt, staan in Tabel 1. Deze regelgeving nemen we vanaf het begin, bij het opstellen van de eisen aan het apparaat, mee. Zo garanderen we dat we het apparaat daadwerkelijk testen aan de hand van de  geldende normen.

Ook voeren we al in de eerste fase voor het complete systeem een risicoanalyse uit, die alle geïdentificeerde gevaren, gevaarlijke situaties, hun risico‘s en de maatregelen daartegen beschrijft. Deze analyse bevat onder meer een zogeheten failure mode and effect analysis (FMEA), waarmee op een systematische manier het gevolg van mogelijk falen wordt geanalyseerd. Op die manier kunnen we al op voorhand maatregelen nemen om dit mogelijk falen te voorkomen of de gevolgen ervan te beperken. Uit de risicoanalyse komen extra requirements die we moeten meenemen tijdens de ontwikkeling van het apparaat.

Als de requirements af zijn, ontwikkelen we in Matlab/Simulink een model dat het hele systeem kan simuleren. Dit omvat drie delen. Het belangrijkste deel is de meet- en regelsoftware die in het uiteindelijke product terecht zal komen. Verder is er het simulatiemodel van de hardware (sensoren, elektronica, pneumatiek, kleppen, blower en dergelijke), dat de werkelijke componenten zo goed mogelijk nabootst. Het derde deel is een simulatiemodel van de verschillende typen patiënten. Het Simulink-model is gedurende de hele productontwikkeling leidend, omdat we uit het deel met de meet- en regelalgoritmes C-code genereren die daadwerkelijk in de eindproducten wordt gebruikt.

Omdat we het Matlab/Simulink-pakket inzetten voor medische systemen, hebben we intern een set validatietests ontwikkeld om de geschiktheid en betrouwbaarheid van de tools aan te tonen. Pas als de resultaten overeenkomen met de verwachte resultaten, wordt de tool vrijgegeven. Bij elke nieuwe release van Matlab/Simulink voeren we deze validatie opnieuw uit.

Met de modelgebaseerde aanpak kunnen we in een vroeg stadium de besturingsalgoritmes testen op verschillende gesimuleerde patiënten. Het voordeel is dat we eenvoudig het gedrag bij bijvoorbeeld extreem zware of kleine patiënten of personen met COPD kunnen simuleren. Ook kunnen we de hardware en pneumatiek kunstmatig verslechteren om het effect van defecte of slijtende onderdelen te testen voordat er een fysiek model beschikbaar is. Dit alles kan volledig automatisch, zodat we in korte tijd veel verschillende testscenario‘s kunnen doorlopen.

Een ander voordeel van modelgebaseerd ontwerpen is dat de verificatie een vast onderdeel is in elke ontwikkelstap. Alle requirements, ook als ze uit de normen voortvloeien, worden dus constant daadwerkelijk geverifieerd.

Macawi gebruikt een modelgebaseerde aanpak bij het ontwikkelen van zijn beademingssystemen, waarbij het systeem eerst volledig wordt gebouwd en stapsgewijs steeds meer echte hardware wordt toegevoegd.

Handmatige vertaalstap

Om een goed model te ontwikkelen, zijn meerdere iteraties nodig. Pas als de ontwikkelaars het gevoel hebben dat de modellen van de hardware de werkelijkheid goed genoeg beschrijven, en ze er dus alle validatievragen voor de controllers mee kunnen beantwoorden, zetten we de volgende stap.

Deze volgende stap behelst het maken van een fysiek pneumatisch prototype met de elektronica, mechanische delen, sensoren en actuatoren. Wij gebruiken DSpace om deze fysieke hardware op Matlab/Simulink aan te sluiten. De algoritmes draaien dus nog steeds in Matlab/Simulink, terwijl de sensoren en actuatoren echt zijn. Deze simulaties leveren alle benodigde informatie over de hardware, bijvoorbeeld voor de responstijd of de resolutie van sensoren en de AD-converters. Op deze manier kunnen we de hardware doorontwikkelen tot een min of meer definitieve versie. De wijzigingen nemen we ook mee in het model van de hardware en pneumatiek.

De volgende stap is om C-code te genereren uit de Matlab/Simulink-algoritmes. De gegenereerde code moet wel worden vergeleken met het Matlab/Simulink-model en eventuele verschillen moeten eruit worden gehaald. De codegeneratoren van Matlab zijn namelijk niet gevalideerd voor medische systemen. Onze ervaring is echter dat de resulterende code van zeer goede kwaliteit en redelijk efficiënt is. Tot nu toe hebben we het nog niet meegemaakt dat de C-code zich anders gedroeg dan het Simulink-model. Als de gegenereerde code goed blijkt te zijn, integreren we die in ons basissoftwareraamwerk, dat we ook voor een deel automatisch genereren.

De belangrijkste normen voor de ontwikkeling van beademingsapparatuur
Norm Beschrijving
Iso 80601-1 Medical electrical equipment
Iso 80601-2-12 Particular requirements for basic safety and essential performance of critical care ventilators
Iso 10651 Lung ventilators for medical use
Iso 14971 Medical devices – application of risk management to medical devices
IEC 62304 Medical device software – software life cycle processes
EN 1789 Medical vehicles and their equipment – road ambulances
EN 13718 Medical vehicles and their equipment – air ambulances

De besturingssoftware is modulair opgebouwd, zodat we unittests kunnen uitvoeren op de losse modules, zoals de patroongenerator, de actuatordriver of de sensormodule. De unittests en de verwachte resultaten worden van tevoren bedacht en meegenomen in de requirements. Onder unittests vallen onder meer het automatisch testen van een algoritme met een vaste reeks inputvectoren. De uitkomsten van het algoritme moeten dan steeds overeenkomen met het vooraf gedefinieerde verwachte resultaat. Voordat we met een modelgebaseerde aanpak begonnen, startten we pas met unittests wanneer de software op het target was geladen. Nu kunnen we een deel van de tests al op het simulatiemodel uitvoeren. We zijn dus eerder aan het testen en eventuele aanpassingen zijn veel makkelijker door te voeren in Simulink dan in handmatige code.

Mathworks biedt tools om deze tests uit te voeren, voor een deel automatisch. Zo is er de Simulink Validation and Verification-toolbox om het model te controleren op programmeerrichtlijnen. Deze software biedt bovendien de mogelijkheid links naar requirements en normen te leggen. Dit maakt de traceability een stuk duidelijker. Simulink Design Verifier controleert modellen op ontwerpfouten en genereert zelfs testcases om ze aan te tonen.

Verder is er Simulink Code Inspector, dat verschillen tussen de Simulink-modellen en de daaruit gegenereerde C-code kan vinden. Dit wordt natuurlijk onafhankelijk gedaan van de codegenerator. Hiermee kan worden gegarandeerd dat de gegenereerde code daadwerkelijk hetzelfde doet als het Simulink-model.

Bij de traditionele manier van ontwikkelen worden alle stappen met de hand uitgevoerd. Eventueel worden wel simulaties uitgevoerd, maar de code wordt onafhankelijk ervan geschreven en getest. Dit houdt niet alleen in dat de code moet worden gecontroleerd, maar in dit geval ook de functionaliteit. Het kan immers mogelijk zijn dat de code goed in elkaar zit en compileert, maar dat de geïmplementeerde algoritmes iets anders doen dan de modellen. Deze handmatige vertaalstap is niet nodig met modelgebaseerd ontwerpen.

Kunstlongen

Na de integratie van de softwaremodules zetten we de volgende stap: de software downloaden op het PCB, de hardware en pneumatiek aansluiten en de integratietests uitvoeren. De code draait dan op de microprocessor van het uiteindelijke apparaat.

Integratietests hebben bijvoorbeeld betrekking op de stabiliteit bij het genereren van bepaalde druk- en flowpatronen en de nauwkeurigheden van de flow- en drukmetingen en van het mixen van zuurstof met lucht. Ook voeren we tril- en schoktests uit om de trillingen na te bootsen van de verschillende typen helikopters die in de emergency care worden gebruikt. Meestal gebeurt dat bij het Nationaal Lucht- en Ruimtevaartlaboratorium (NLR), waarbij grote opstellingen trillingen met de benodigde specifieke frequenties genereren. Tevens voeren we EMC-tests uit, om te controleren of het apparaat niet gevoelig is voor elektromagnetische straling en zelf ook niet te veel uitstraalt.

Het model bestaat uit drie componenten om het hele systeem te kunnen doorrekenen: de meet- en regelalgoritmes in de software, de hardware en mechanica, en de patiënt. Door een gesimuleerde patiënt te gebruiken, kan het systeem op een brede reeks aan lichaamstypes worden getest, zoals zware of kleine personen. De modellen van de meet- en regelalgoritmes worden uiteindelijk via codegeneratie vertaald naar de software voor het systeem.

De verificatie van het totale systeem doen we met behulp van kunstlongen, meestal opgebouwd uit een balg met een veer die een luchtweerstand en een compliantie vormen. Voor kleine longen gebruiken we ook wel glazen flessen, omdat kleine complianties op deze manier beter zijn te realiseren.

Als allerlaatste stap, pas als het apparaat een bepaalde graad van volwassenheid heeft, doen we klinische tests. Deze zijn onder meer van belang om de interactie tussen patiënt en ventilator te testen. Over het algemeen zijn dit soort tests lastig uit te voeren met kunstlongen, omdat echte patiënten bijvoorbeeld kunnen hoesten of hikken tijdens beademing. Verder is het op deze manier mogelijk de effectiviteit van beademing te testen, omdat ook de zuurstofsaturatie in het bloed en het CO2-gehalte in de uitgeademde lucht kunnen worden gemeten. Met behulp van deze informatie blijven we de simulatiemodellen van de patiënt ook steeds verbeteren, zodat we de softwarealgoritmes in de simulatiefase al uitgebreider kunnen testen en de klinische tests kunnen beperken.

Modelgebaseerd ontwerpen biedt allerlei extra handvatten ten opzichte van de traditionele manier die met name voor medische systemen van belang zijn: van de traceability in het ontwikkelproces tot en met het eenvoudig aantonen van de verificatie. Bovendien worden eventuele designfouten al vroeg in het ontwikkelproces gevonden.