Model-Based Systems Engineering
IEC 62304 – dank MBSE und MBD
Die Entwicklung und Zulassung von Medizingeräten sind anspruchsvoll. Mit stetig zunehmender Komplexität steigen auch die Anforderungen. Model-Based Systems Engineering, Model-Based Design und die Simulation bieten Unterstützung und helfen per »Digital Thread« wichtige Normen einzuhalten.
Regulatorische Konformität, Sicherheit und Zuverlässigkeit, Innovationsdruck und Kostenmanagement sind nur einige Kriterien im Zuge der Entwicklung von Medizingeräten und deren zunehmender Systemgröße. Die steigende Komplexität, deren Bewältigung sowie eine anspruchsvollere interdisziplinäre Zusammenarbeit erschweren Ingenieuren die Arbeit. Ohne dedizierte Tools ist die Entwicklung heutiger Systeme nicht mehr zu bewältigen – etwa für eine zentrale Datenhaltung oder eine weitgehend automatisierte Analyse und Validierung.
Lost in: Systemarchitektur
Der Entwurf von Systemarchitekturen ist besonders herausfordernd, da verschiedene Zusatzfaktoren berücksichtigt werden müssen, z.B. Leistung, Energieverbrauch, Interoperabilität, Größe, Gewicht und vieles mehr. Im Entwicklungsprozess entstehen in der Regel unterschiedliche Ausgangspunkte für das Design der Unterkomponenten im Hinblick auf abgeleitete Anforderungen und Schnittstellen. Zudem müssen verschiedene Architekturkandidaten frühzeitig bewertet und verglichen werden, um die beste Lösung herauszuarbeiten.
Eine weitere Schwierigkeit besteht darin, sich auf die Systemdetails zu konzentrieren, ohne den Gesamtüberblick zu verlieren. Entscheidend ist dabei, Informationen zum Kontext zu erhalten, Anforderungen nachzuverfolgen und Teilaspekt-spezifische Ansichten bereitzustellen, um die wachsende Systemkomplexität zu beherrschen.
Nicht zuletzt besteht eine weitere Herausforderung darin, die Systeme über alle Designebenen hinweg nachzuverfolgen und zu synchronisieren. Oftmals fehlt jedoch die Verbindung zwischen der Systemtechnik und der Implementierung des Designs. Ein nahtloser Übergang zur Weiterentwicklung der Systemkomponenten sowie die Sicherstellung der Konsistenz über die verschiedenen Ebenen hinweg sind daher weitere Schlüsselfaktoren. Als Beispiel wird in den weiteren Beschreibungen auf ein fiktives Dialysegerät Bezug genommen.
Komponenten, Hierarchien, Anforderungen
Ein Projekt beginnt in der Regel mit übergeordneten Anforderungen und möglicherweise einem bestehenden Altsystem. Dieses kann strukturell oder in Teilen wiederverwendet werden. Es gilt, eine Architektur mit Unterkomponenten zu entwickeln, denen jeweils abgeleitete Anforderungen zugeordnet werden. Diese Unterkomponenten tragen ihren Teil zur Gesamtfunktion des Medizinsystems bei, wobei so viele Hierarchieebenen wie nötig einbezogen werden. Ein strukturelles Zerlegen geht dabei Hand in Hand mit einem entsprechenden Zerlegen der Anforderungen und Randbedingungen. So sind am Ende dieses Schrittes die Anforderungen und Einschränkungen jeder Unterkomponente ausreichend definiert.
Model-Based System Engineering
Werkzeuge für Model-Based Systems Engineering (MBSE), wie beispielsweise der System Composer des Referenzherstellers MathWorks, unterstützen die vorgenannten Schritte. Ingenieure können mit diesem oder vergleichbaren Tools die Architektur ihres Medizingerätes erstellen und die Architekturkomponenten direkt mit funktionalen und nicht-funktionalen System- und Komponentenanforderungen verlinken (Bild 1).
Hier werden auch Eigenschaften und Randbedingungen wie Sicherheitsstufe, Aufwand, Stromverbrauch, Ausfallwahrscheinlichkeit, usw. den Architekturelementen zugeordnet. Dazu wird eine Hierarchie von Stereotypen definiert, welche diese nicht-funktionalen Eigenschaften erfasst, sodass alle Komponenten in einer Architektur typgerecht mit den relevanten Eigenschaften versehen werden. Die Verwaltung dieser Daten zusammen mit der Architektur ermöglicht eine zentrale Datenhaltung.
Frühzeitige Evaluierung
In der Regel erstellen Entwickler zu Beginn mehrere alternative Architekturen. Beispielsweise können im Bereich der medizinischen Sensorik unterschiedliche Konzepte umgesetzt oder bei sicherheitskritischen Medizinsystemen verschiedene Ansätze zur Sicherheitsdekomposition gegenübergestellt werden. Die in der Architektur angegebenen Komponenteneigenschaften ermöglichen bereits eine frühe Evaluierung der konkurrierenden Architekturkonzepte, indem architekturspezifische Systemgrößen wie Entwicklungsdauer, Kosten oder Zuverlässigkeit bewertet werden können. Dadurch kann ein Entwickler das Einhalten der Randbedingungen überprüfen oder die optimale Architektur für die weitere Entwicklung auswählen.
Diese Zusatzdaten ermöglichen zudem die Fokussierung auf Teilaspekte des Systems. So können Diagramme erzeugt werden, welche nur alle sicherheitskritischen Teile des Systems zeigen, solche mit zu hohem Stromverbrauch, oder alle am Powermanagement beteiligten Komponenten – den Kriterien für solche Ansichten (Views) sind keine Grenzen gesetzt (Bild 2).
Zudem kann in diesen Teilansichten weitergearbeitet werden, ohne durch für den jeweiligen Kontext irrelevante Details gestört zu sein. Gerade in großen Systemen sind solche reduzierten Ansichten für das Verständnis und die Kommunikation zwischen Teams unerlässlich.
RFLP: Komplexität bewältigen
Eine weitere zunehmend eingesetzte Maßnahme zur Bewältigung der Systemkomplexität ist die RFLP-Methodik. Diese Methodik bietet einen strukturierten Ansatz zur Systementwicklung, indem sie vier wesentliche Perspektiven integriert: Auf der (R)equirements-Ebene werden die Systemanforderungen erfasst und verwaltet. Die (F)unktionale Ebene definiert die Funktionen, die das System ausführen muss, um diese Anforderungen zu erfüllen. Auf der (L)ogischen Ebene werden diese Funktionen in logische Komponenten umgesetzt, die eine Brücke zur physischen Umsetzung bilden. Schließlich erfolgt auf der (P)hysikalischen Ebene die Realisierung der logischen Architektur in physische Hardware- und Softwarekomponenten.
Diese Methodik wird im System Composer durch einen Allokationsmechanismus realisiert, der die verschiedenen Architekturebenen aufeinander abbildet. Es können verschiedene Szenarien der Allokation modelliert werden und hinsichtlich der Einhaltung der Randbedingungen analysiert werden, wie etwa die verteilte Ausführung von Softwarefunktionen auf den ECUs unter Berücksichtigung der Speicherverfügbarkeit.
Für jeden Zweck das richtige Diagramm
Zur Erstellung der Architektur stehen Diagramme wie Interne Blockdiagramme, Komponentendiagramme und Hierarchiediagramme zur Verfügung. Für die Softwareteile gibt es zudem Klassendiagramme mit Methoden und Client/Server Schnittstellen. Je nachdem, ob der Daten- oder Signalfluss im Vordergrund steht oder die Hierarchiebeziehungen und Schnittstellen, kann zwischen diesen Darstellungsarten gewechselt werden. Das Werkzeug synchronisiert diese Ansichten bei Änderungen automatisch (Bild 2).
Als Besonderheit des System Composers können Architekturen auch physikalische Schnittstellen und Verbindungen beinhalten, sowie entsprechende physikalische Komponenten. Dies ermöglicht interdisziplinäres Zusammenarbeiten von unterschiedlichen Teams weit über Software hinausgehend.
Als Verhaltensdiagramme der Komponenten stehen z.B. Zustandsautomaten und Aktivitätsdiagramme zur Verfügung. Für die Spezifikation der Abläufe und Kommunikation zwischen den Komponenten werden Sequenzdiagramme verwendet (Bild 3).
Über diese Verhaltensdiagramme hinaus kann das Verhalten von Komponenten auch in Simulink beschrieben sein – mit allen dort verfügbaren Möglichkeiten der Verhaltensmodellierung durch datenflussgetriebene Algorithmen, integriertem Code oder physikalische Modelle.
Simulation eröffnet neue Möglichkeiten
Die Simulation auf Komponenten- und Architekturebene ist eine wichtige Methodik, um das Konzept eines medizinischen Systems frühzeitig und umfassend zu validieren und die funktionalen Systemanforderungen zu überprüfen. Simulationen helfen, potenzielle Probleme frühzeitig zu erkennen und zu beheben, bevor sie später zu kostenintensiven Entwicklungsiterationen führen oder gar in die reale Anwendung gelangen.
So können Entwickler die Konsistenz der Anforderungen sowohl lokal als auch im Gesamtsystemverhalten validieren. Jede Komponente, für die ein Verhaltensdiagramm oder -Modell hinterlegt ist, wird in die Gesamtsystemsimulation einbezogen. Damit eröffnen sich auch alle Möglichkeiten der frühzeitigen Testeinrichtung und Testautomatisierung, selbst auf oberster Architekturebene, ohne hierfür dedizierte Modelle erstellen zu müssen. Schnittstellen und Verbindungen werden simulativ einbezogen, wodurch potenzielle Fehlerquellen ausgeschlossen werden können (Bild 4).
In System Composer werden alle oben aufgeführten Verhaltensdiagramme bei der Simulation animiert, um detailliert den Simulationsablauf nachzuvollziehen. Sequenzdiagramme werden dabei zusätzlich als automatisiertes »Bestanden/Nicht bestanden«-Kriterium verwendet: Weicht der Ablauf von der vorgegebenen Sequenz ab, werden zugehörige Teile des Diagramms rot eingefärbt. Mit solchen Mechanismen können Testfälle mit automatisierten »Bestanden/Nicht bestanden«-Kriterien bereits eingerichtet werden, bevor die Implementierung beginnt. Das entspricht dem agilen Ansatz der »test-first« Methodik, wie sie im Scaled Agile Framework unter Behavior Driven Development (BDD) beschrieben ist.
Sicherheitsanalysen für das Risikomanagement
Ein Teil des Systems Engineering in der Medizintechnik beinhaltet das Risikomanagement nach ISO 14971. In der Medizintechnik beginnt der Prozess der Risikoanalyse mit der systematischen Identifizierung potenzieller Gefährdungen, die mit einem Medizinprodukt verbunden sind. Dies umfasst die detaillierte Untersuchung aller möglichen Szenarien, in denen das Produkt versagen oder unerwünschte Wirkungen hervorrufen könnte. Nach der Identifizierung wird das Risiko jeder Gefährdung anhand ihrer Wahrscheinlichkeit und der Schwere möglicher Folgen bewertet. Anschließend erfolgt die Risikokontrolle, bei der Maßnahmen entwickelt und implementiert werden, um die identifizierten Gefahren zu eliminieren oder auf ein akzeptables Niveau zu reduzieren.
Der Prozess beinhaltet die Auswahl geeigneter Risikokontrollmaßnahmen, deren Implementierung und die anschließende Bewertung ihrer Wirksamkeit, um sicherzustellen, dass die verbleibenden Restrisiken akzeptabel sind. Eine solche Sicherheitsanalyse wird häufig in tabellarischer Form umgesetzt, um die Informationen systematisch und übersichtlich darzustellen – so auch mit dem System Composer. Mögliche Gefährdungen gehen insbesondere von nicht-nominalen Fehlfunktionen wie einzelnen Sensoren aus. Für jede Gefährdung muss die Rückverfolgbarkeit auf die Analyse und Bewertung des Risikos gegeben sein. Das wird außerhalb der Tabellen auch durch Traceability Links zu Anforderungen, Architektur, injizierbare Fehlfunktionen, Testfällen und Risikokontrollmaßnahmen sichergestellt. Insbesondere die Kontrolloptionen lassen sich simulativ im Rahmen von Fehlerinjektionstests hinsichtlich ihrer Wirksamkeit verifizieren und in den Tabellen als geprüft bestätigen (Bild 5).
Model-Based Design: Von der Architektur über Design zur Implementierung
Nach dem modellbasierten Systems Engineering mit dem System Composer geht es nahtlos mit einem Model-Based Design (MBD) weiter, das die Entwicklung von detaillierten Modellen und Algorithmen für die Architekturkomponenten umfasst. Diese Modelle werden in einer Umgebung wie Simulink erstellt und validiert, um sicherzustellen, dass sie die Komponentenanforderungen erfüllen. Hierfür stehen neben der Überprüfung von Modellierungsrichtlinien und dem Testen von Komponenten auch formale Methoden zur Verfügung.
Im nächsten Schritt werden die Modelle nach und nach verfeinert, um das Systemverhalten präzise abzubilden. Nach der Verifizierung und Validierung der Software-Modelle wird die automatische Codegenerierung durchgeführt, um optimierten Code zu erzeugen, der eine volle Nachverfolgbarkeit vom Modell zu den Anforderungen beinhaltet. Der Code kann in das Zielsystem integriert werden, was den Entwicklungsprozess beschleunigt und die Konsistenz zwischen Design und Implementierung sicherstellt. Die Nutzung von MBD in Verbindung mit Werkzeugen wie dem System Composer erlaubt Ingenieuren eine nahtlose Integration von Systemarchitektur, Design und Implementierung, ein Vorteil in der Entwicklung komplexer Systeme.
Die Anforderungen der IEC 62304 einhalten
Die Möglichkeiten von MBSE und MBD tragen wesentlich zur Einhaltung der Anforderungen der IEC 62304 bei. Die Nutzung von System Composer und Simulink ermöglicht eine klare Definition und Nachverfolgbarkeit von Softwareanforderungen, die den Grundstein für die Erfüllung des Standards legen. Die detaillierten Simulationsmodelle dienen der Validierung und dem Testen der Softwarefunktionen, was den Anforderungen an das Risikomanagement und an die Verifikation des Standards entspricht. Die automatische Codegenerierung sorgt für Konsistenz zwischen dem Design und der Implementierung, reduziert manuelle Fehler und erleichtert die Dokumentation. Alle Schritte beinhalten einen automatisch generierten Report, wodurch die Konformität mit den strengen Dokumentationsanforderungen der IEC 62304 erreicht wird. Mit der Durchgängigkeit der technischen Dokumentation wird so ein »Digitaler Faden« (digital thread) durch die Prozessschritte aufgebaut. Insgesamt ermöglicht dies eine strukturierte und nachvollziehbare Softwareentwicklung, die den hohen Sicherheits- und Qualitätsstandards der Medizintechnik entspricht. (uh)
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Editorial der Elektronik Medical 4-2025
Hören wir mit KI auf zu denken?
Stimmen, Bilder, Impressionen
Das war der »Health Electronics Summit« 2025
Augenlasern mit Nobel-Methode
OP-Verfahren von Carl Zeiss für Deutschen Zukunftspreis nominiert
Nur Tage nach dem Apple-Event
Apple Watch erhält FDA-Zertifizierung für Blutdruckwarnung
