iCon-L in der Medizintechnik
Einleitung
Bei der Hämodialyse (Blutwäsche mit Maschine, „künstliche Niere") wird der Blutkreislauf des Patienten an eine „künstliche Niere" angeschlossen. Dieses Gerät heißt Hämodialysemaschine und reinigt das Blut des Patienten. Die eigentliche Blutreinigung findet im Dialysator statt, dem Filter der Dialysemaschine. Um das Blut durch den Hämodialysator zur leiten, legt der Arzt ähnlich wie bei der Blutabnahme einen Katheter in eine Vene, durch den das zu reinigende Blut durch die künstliche Niere gepumpt wird.
Um eine fehlerfreie Funktion der Dialysemaschine sicherzustellen, ist der zuverlässige Test des Dialysators unerlässlich. Mit dem Hämodialysator Analysator wurde ein Prüfsystem entwickelt, mit dem der Test automatisch durchgeführt werden kann. Der Analyser erfüllt die Norm DIN EN 1283.
- Druckhaltetest
- Lecktest
- Messung der hydraulischen Permeabilität
- Bestimmung der diffusen Permeabilit
- Bestimmung des Siebkoeffizienten
Prozesse
Mit ca. 80 Betriebsarten, 12 PID-Regelkreisen und mehr als 30 eigenständigen Prüfungen auf Plausibilität stellt die Automatisierung sehr hohe Anforderungen an das Softwareengineering der Mikrocontroller und hier insbesondere an die Möglichkeiten zur Beobachtung des Softwareverhaltens.
Systemarchitektur
Die gesamte Systemarchitektur ist konsequent auf die 3 technologischen Bereiche
- Dialysat-Kreislauf (DC)
- Blut-Kreislauf (BC)
- Breitstellung der Test-Medien (MSU)
zugeschnitten. So wurde für jeden Kreislauf ein eigener Controller mit einer eigenständigen Software vorgesehen. Die Controller arbeiten als Service-Erbringer und erhalten vom zentralen Bedienrechner nur noch Parameter und Betriebsart. Alle notwendigen Regelungs- und Steuerungsaufgaben für die Umsetzung der Betriebsart realisieren die Controller selbständig und bestätigen lediglich die Erfüllung der Betriebsart.
Die Synchronisation zwischen den Controller erfolgt auf Basis der zentralen Betriebsartenverwaltung.
Projektbericht
| Projekt | HDA10 |
|---|---|
| Kurzbeschreibung | Entwicklung und Produktion einer Kleinserie eines automatischen Prüfsystems für Dialysatoren |
| Auftraggeber | IBP Medical GmbH |
| Leistung von ProSign | Implementierung des iCon-L Laufzeitkerns sowie Softwaretechnologieberatung und Unterstützung bei der Entwicklung der Anwendungssoftware für die Mikrocontroller. |
| iCon-L Version | 4.5 |
| Zielsysteme | 3 eigenständige Controller LPC2468 (ARM7) |
| Prozessdatenpunkte | ca. 50 I/O-Datenpunkte über spezielle I/O-Module (RS485) |
| Besonderheiten | - OPC-Interface zu LabView über CAN-Bus - Kommunikationsmanagement zu den IO-Modulen in iCon-L programmiert |
| Umfang der Applikation | - DC-Controller 2537 FBs - BC-Controller 2235 FBs - MSU-Controller 1573 FBs - Visualisierungs- und Parameterbausteine wurden nicht mitgezählt |
Systematisch von der Aufgabenstellung zum Programm
Obwohl in die Entwicklung von Software viel Zeit und Geld fließt, wird der Wert von Software häufig nicht als solches gesehen. Meist wird auf das Design eines Schaltschranks mehr Wert gelegt, als auf das Design von Software. Insbesondere bei der späteren Änderungen wird zum Teil sehr nachlässig mit Software und hier im Speziellen mit der Änderungsdokumentation umgegangen. Durch ein gutes Basisdesign können Sie spätere Nachlässigkeiten verringern, da es einem Menschen naturgemäß schwerer fällt ein schönes Design zu zerstören als ein ohnehin schlechtes Softwaredesign noch schlechter zu machen. Die Softwarestruktur kann die Nachhaltigkeit und den dauerhaften Wert von Software grundlegend bestimmen. Sehen Sie die Software immer als ein wertvolles Gut an, mit dem genauso sorgfältig umgegangen werden muss, wie mit materiellen Dingen.
Neben dem grundlegenden Wert von Software muss die Software in eingebetteten Systemen aber noch weitere Forderungen erfüllen.
- Die Software muß hohe Standards bezüglich Nachvollziehbarkeit, Testbarkeit und Beobachtbarkeit erfüllen.
- Die Software ist in sehr kostenintensive und werthaltige Systeme eingebettet und aus diesem Grund meist sehr langlebig
- Auf Grund der Langlebigkeit wird die Software häufig an mehrere Entwicklergenerationen übertragen
- Durch die Interaktion mit physikalisch, technischen Prozessen ist die Inbetriebnahme und Fehlersuche sehr schwierig und wird durch klassische Methoden für das Debug nur unzureichend unterstützt.
- Im Gegensatz zu reinen Softwaresystemen unterliegt die Funktion der Software in eingebetteten Systemen, insbesondere durch die enge Verzahnung mit den physikalisch, technischen Systemen, den Auswirkungen von Alterung und Verschleiß und wird daher ständig in die Wartung und Pflege einbezogen.
Aus den vorgenannten Gründen muss die Software in eingebetteten Systemen gewisse Voraussetzungen erfüllen.
- Grundlegende Softwareprinzipien wie Modularität, TopDown-Entwurf, Strukturierte Analyse, Hierarchie,.. müssen erfüllt werden
- Die Software muss in einem hohen Maße eine selbstdokumentierende Struktur besitzen und den Kontext der Anwendung deutlich darstellen.
- Die Software muss eine Beobachtbarkeit bei der Inbetriebnahme und Wartung unterstützen, die auf die jeweiligen Anforderungen der Anwendung zugeschnitten ist
Im vorliegenden HDA10-Projekt bot das Pflichtenheft ideale Voraussetzungen, um die goldene Regel anzuwenden. Die Diagramme geben den Kontext der Anwendung klar und deutlich wieder. Zudem unterstützen die Diagramme die Anwendung des TopDown-Entwurfsverfahrens.