Code-Generierung für die Regelung von Medizingeräten — Teil 1

Die Code-Generierung verspricht viel: Der Entwicklungsingenieur spezifiziert grafisch das Systemverhalten und generiert daraus Programme für unterschiedliche Zielplattformen ohne zu programmieren. Außerdem wird die Dokumentation erzeugt, normkonform statisch analysiert und auf Modellebene getestet. Wir haben langjährige Erfahrung mit diesem Ansatz, aber auch mit der von anderen Werkzeugen unterstützen Programmierung und stellen fest: Der Aufwand für die gleiche Qualtät sinkt nicht unbedingt. Um Softwarefehler zu vermeiden, vollständige Dokumente zu erstellen und alle geforderten Tests durchzuführen, muss trotz Unterstützung die gesamte Verarbeitungskette nachvollzogen, angepasst und erweitert werden. In drei Teilen möchten wir Ihnen einen Überblick über die Code-Generierung geben:

1. In diesem ersten Teil stellen wir die Ziele der Code-Generierung und einen Überblick über unsere Erfahrungen vor.
2. Im zweiten Teil werden wir die Vor- und Nachteile anhand von Beipielen mit C-Code und Simulink-Modellen konkret diskutieren und mit Kriterien bewerten.
3. Im letzten Teil geben wir einen Überblick zu Alternativen wie beispielsweise synchrone Sprachen und diskutieren deren Einsatz in der Medizintechnik.

Im Mittelpunkt aller Teile steht die Frage ob und wann Code-Generierung in der Medizintechnik eingesetzt werden sollte.

Das Ziel der modellbasierten Entwicklung und der damit verbundenen Erzeugung von Programmtexten ist es, dem Ingenieur wiederkehrende Arbeiten abzunehmen. Vor allem die Programmierung soll ihm erspart werden. Weitere Beispiele für wiederkehrende Aufgaben, die unmittelbar die Code-Generierung betreffen, sind:

• Simulation von physikalischen Systemen mit Integratoren, Übertragungsfunktionen und ähnlichen Teilsystemen,
• Verwendung von logischen Operationen, Bitoperationen und mathematischen Funktionen,
• Erstellung von Tabellensuchprogrammen,
• Integration von Kontrollstrukturen und Zustandsmaschinen und
• Festkommarechnung.

Zusätzlich sollen auch folgende Aufgaben unterstützt werden:

• Anzeigen von Signalen und Variablen während der Entwicklung,
• Generierung von Dokumentation (mit Rückverfolgbarkeit),
• Portierung auf unterschiedliche Zielplattformen und
• Durchführung von statischen Prüfungen und Tests auf der Ebene von Einheiten und für das Gesamtsystem.

In verschiedenen Projekten haben wir Simulink für die Code-Generierung eingesetzt. Neben Software für Medizingeräte entstand Regelungssoftware für Teststände. Das Entwicklungs-Werkzeug lässt sich grob als grafischer Editor des Aufrufbaumes eines Programmes verstehen. In der Hauptansicht werden Blöcke abgelegt, deren Parameter über Eingabemasken verändert werden können. Zwischen ihnen spezifizieren Pfeile den Signalfluss. Blöcke können entweder einer Bibliothek entnommen oder durch eine grafische Zusammenschaltung von Teilfunktionen definiert werden. Die zweite Sicht auf die entstehende Hierarchie ist eine textbasierte Baumansicht mit einem Tabelleneditor, über den Variablen und Parameter aller Teilsysteme bearbeitet werden können. Zusätzlich steht eine Programmierschnittstelle zur Modellmanipulation zur Verfügung. Wenn hauptsächlich gängige Funktionen aus der mitgelieferten oder der eigenen Bibliothek verwendet werden, lässt sich so zügig ein lauffähiges Programm spezifizieren, das in der Simulationsumgebung getestet werden kann. Darüber hinaus kann mit dem Embedded Coder C-Code für eingebettete Systeme generiert werden. Dadurch lässt sich das Programm unter anderem in Medizingeräte und Teststände integrieren. Um dabei ein sicheres Medizinprodukt zu erhalten, waren bei der Entwicklung der Regelung eines Herzunterstützungssystems folgende Schritte erforderlich:

1. Anforderungen, Architektur und Design wurden ohne den mitgelieferten Report-Generator dokumentiert.
2. Die Regelungskern-Funktion wurde modelliert und in Simulationen getestet.
3. Entwicklungsbegleitende Tests mit der Hardware wurden durchgeführt.
4. Schnittstellen, Programmlogik und Zustandsmaschinen wurden ergänzt.
5. Die Datentypen wurden für die Festkommarechnung umgestellt.
6. Für Unit- und Integrations-Tests wurde ein eigenes Werkzeug programmiert, das die Modelle für unterschiedliche Tests und die erforderlichen Dokumente erzeugt. Auch die Reviewergebnisse werden damit verwaltet und protokolliert.
7. Ein Äquivalenztest auf der Zielhardware wurde durchgeführt.
8. Die statische Modellanalyse wurde durchgeführt.
9. Die Matlab-Bug-Liste sind wir durchgegangen, um gefährliche Konstrukte zu beseitigen oder zu umgehen.
10. Für die Tests der Anforderungen mit dem Antrieb des Herzunterstützungssystems wurde in C ein zusätzliches Modul implementiert. Variablen können damit gelesen, manipuliert und über den CAN-Bus an ein Python-Programm gesendet werden.

Das folgende Bild veranschaulicht den Zusammenhang zwischen den entstandenen Vorgabedokumenten, der erstellten Software und den Nachweisdokumenten.

Diese kurze Überblick zeigt bereits: An vielen Stellen lassen sich nicht alle Vorteile der Automatisierung nutzen. Es lohnt sich also, an konkreten Beispielen die Vor- und Nachteile zu diskutieren und dann anhand von für Medizingeräte relevanten Kriterien zu bewerten. Beide Schritte werden wir Ihnen im zweiten Teil dieses dreiteiligen Beitrags präsentieren. Mit weiteren Alternativen wie synchronen Sprachen wird sich der dritte Teil beschäftigen.