Die IEC 62304 verpflichtet die Hersteller, die notwendige Segregation (auf Deutsch „Abgrenzung“) von Software-Komponenten zu bestimmen. Wie diese zu erfolgen hat, legt die Norm nicht fest, was zu vielen Diskussionen führt. Finden Sie hier Antworten auf häufige Fragen.
1. Die fünf Ziele der Segregation
Die Segregation verfolgt mehrere Ziele.
Ziel 1: Risiken minimieren
Die Segregation einer Komponente hilft, das Risiko dieser Software-Komponente im Fehlerfall zu minimieren. Denn die Abhängigkeiten zwischen dieser segregierten Komponente und den anderen Komponenten des gleichen Software-Systems sind schwächer als das bei einer nicht oder nur schwach segregierten Komponente der Fall wäre.
Eine Komponente wird dadurch segregiert, dass sie nicht (mehr) auf Variablen anderer Komponenten oder gar auf globale Variablen zugreifen kann. D.h. sie kann weder diese Variable lesen noch verändern.
Damit kann bei einer segregierten Komponente ohne diesen Zugriff eine fehlerhafte (globale) Variable nicht direkt zu einem Fehlverhalten dieser Komponente führen. Auch kann eine segregierte Komponente nicht globale Variablen fehlerhaft verändern und damit zu einem Fehlverhalten des gesamten Software-Systems führen.
Die IEC 62304 diskutiert die Segregation mit dem Fokus auf Risikominimierung.
Ziel 2: Entwicklung vereinfachen / beschleunigen
Entwicklungsteams profitieren von schwach gekoppelten Komponenten dadurch, dass es ihnen einfacher fällt,
- die Entwicklung auf mehrere Teams aufzuteilen und damit zu parallelisieren,
- für verschiedene Komponenten (z.B. Micro-Services) die jeweils passendsten Technologien zu verwenden und
- die Komponenten unabhängig voneinander zu testen und
- zu einem Gesamtsystem zu integrieren.
Ziel 3: Dokumentationsaufwand minimieren
Die IEC 62304 erlaubt es, ausreichend segregierten Komponenten unterschiedliche Sicherheitsklassen zuzuweisen. Die Anforderungen an die Dokumentation von Komponenten mit einer niedrigen Sicherheitsklasse (A oder B) sind niedriger als bei höheren Sicherheitsklassen.
Die Sicherheitsklassen sind ein Konzept der IC 62304, das die FDA nicht kennt. Allerdings erlaubt auch die FDA einen risk-based Dokumentationsumfang.
Überschätzen Sie die Zeit nicht, die Sie dadurch einsparen, dass sie einer Software-(Komponente) die Sicherheitsklasse B statt der Default-Klasse C zu weisen.
Vielmehr rechnet sich die Zeit, um eine belastbare Software-Architektur und ein detailliertes Design zu erstellen. Denn damit lassen sich große Aufwände sparen für
- ineffiziente weil nicht abgestimmte Entwicklung,
- Nachbesserungen bei fehlerhafter Software und
- die Wartung des Software-Systems.
Diese Dokumentation gelingt uns meist innerhalb weniger Tage. Melden Sie sich, falls Sie Unterstützung wünsche, beispielsweise über unser Kontaktformular.
Ziel 4: Wartbarkeit erhöhen
Segregierte Komponenten sind Dank ihrer schwache Kopplung einfacher bzw. besser
- austauschbar / ersetzbar durch andere Komponenten,
- wiederverwendbar z.B. in anderen Produkten und
- analysierbar. D.h. es ist einfach nachzuvollziehen, was eine Komponenten macht und was die Auswirkungen sind, wenn sie das nicht tut.
Ziel 5: Gesetzliche Anforderungen erfüllen
Hersteller müssen zumindest darüber nachdenken und dokumentieren, ob und zum welchem die Segregation ihrer Software-Komponenten notwendig sind. Diese Pflicht ergibt sich aus der
- ISO 14971, welche verlangt, dass die Risiken minimiert werden beispielsweise dadurch, dass ein „Design“ verwendet wird, das möglichst inhärent sicher ist,
- IEC 62304, die das explizit im Kapitel 5.3.5 fordert.
The MANUFACTURER shall identify any segregation between SOFTWARE ITEMS that is necessary for RISK CONTROL, and state how to ensure that such segregation is effective. [Class C]
D.h. Hersteller müssen festlegen, ob und wie verschiedene Komponenten segregiert werden müssen, um Risiken durch eine Komponente zu beherrschen bzw. Risikobeherrschungsmaßnahmen wirksam zu gestalten.
Das führt die Norm auch im Anhang aus:
The software ARCHITECTURE should promote segregation of software items that are required for safe operation and should describe the methods used to ensure effective segregation of those SOFTWARE ITEMS.
Gemäß Kapitel 4.3 der IEC 62304 ist die Wirksamkeit der Segregation auch dazulegen, wenn Hersteller einem Software-System verschiedene Sicherheitsklassen zuweisen.
2. Möglichkeiten zur Segregation
Wenn Sie ein komplettes Software-System herunterklassifizieren wollen, verlangt die IEC 62304 eine unabhängig Hardware. Wenn Sie nur bestimmten Komponenten eines Software-Systems eine niedrigere Sicherheitsklasse zuweisen wollen als dem Software-System insgesamt, wird die Antwort auf die Frage, ob eine Segregration ausreichend begründet ist, schwieriger.
a) Segregation durch unterschiedliche Hardware
Eine Software(komponente), die auf einem eigenen/unabhängigen Prozessor und Speicherbereich läuft, ist meist ausreichend segregiert.
Sie vermeiden sogar diese Diskussion, wenn Sie jeden Teil Ihrer Software, der auf einer eigenen Hardware läuft, als eigenes Software-System definieren, dem Sie unabhängig eine Sicherheitsklasse zuweisen dürfen.
b) Segregation durch spezielle Prozessoren bzw. Betriebssysteme
Ein dedizierter Prozessor bzw. ein spezielles Betriebssystem, auf dem unterschiedliche Prozesse völlig unabhängig voneinander laufen und bei dem sich deren Speicherbereiche nicht gegenseitig beeinflussen können, wird man ebenfalls als ausreichend segregiert begründen können.
c) Segregation innerhalb einer Software auf einem Prozessor
Schwieriger wird es, verschiedene Komponenten einer Software als ausreichend segregiert zu begründen, die auf einem Prozessor laufen. Hier gilt es zu untersuchen, welche Risiken durch die Segregation minimiert werden sollen.
Es besteht ein Risiko für den Patienten dadurch, dass das Medizinprodukt nicht verfügbar ist, weil die Software insgesamt abstürzt (z.B. wegen eines durchs Betriebssystem verursachten Speicherüberlauf). In diesem Fall ist eine logische Trennung der Komponenten (z.B. durch Packages, private-Modifier, OSGI-Bundles, Namensräume) schwer zu argumentieren.
Es besteht ein Risiko für den Patienten dadurch, dass eine Race-Condition zu einem Dead-lock führt. Falls nun ein unabhängiger Prozess auf dem gleichen Prozessor diesen Dead-lock identifizieren und darauf geeignet reagieren kann, wäre die Trennung der Prozesse wahrscheinlich ausreichend.
Die Methode einer Komponente berechnet eine Bestrahlungsdosis. Die Methode einer zweiten Komponente überprüft diese Werte bevor sie sie übernimmt. Die beiden Komponente sind hinsichtlich dieses logischen Fehlers ausreichend segregiert. Falls jedoch die erste Komponente Werte an die zweite Komponente übergeben kann, welche die zweite zu einem Absturz bringt (z.B. Buffer Overflow), wäre die Segregation nicht ausreichend.
Beachten Sie also, dass Segregationsgrenzen, die nur logisch bestehen, immer über den „Umweg“ Betriebssystem/Speicher ausgehebelt werden können. Wenn diese „Umwege“ nicht zu unvertretbaren Risiken führen, ist eine Segregation innerhalb einer Software auf einem Prozessor denkbar.
Die Segregation sollten Hersteller immer mit dem Fokus anstreben, Risiken und nicht den Dokumentationsaufwand zu minimieren.
3. Typische Fehler bei der Segregation
Bei der Segregation von Software-Komponenten passieren regelmäßige Fehler.
Fehler 1: Fehlende Segregation
Der Hersteller hat es unterlassen, seine Komponenten zu segregieren – oder überhaupt Komponenten zu identifizieren.
Fehler 2: Fehlende Dokumentation
Für Auditoren und Reviewer gilt: Was nicht dokumentiert ist, das existiert nicht. Daher genügt es nicht, eine Software mit einer perfekten Architektur aus schwachgekoppelten d.h. gut segregierten Komponenten zu entwickeln. Diese Architektur und die Entwurfsentscheidungen müssen auch dokumentiert sein.
Fehler 3: Unzureichende Beweisführung
In PowerPoint gemalte Kästchen zählen zwar als Dokumentation, sie sind aber keine Beweisführung. Die Hersteller müssen die Schnittstellen dokumentieren und begründen, weshalb diese Schnittstellen zu einer so schwachen Kopplung der Komponenten führen, dass diese als ausreichend segregiert gelten.
Es ist nicht diskutiert, weshalb zwei Komponenten ausreichend segregiert sind, insbesondere wenn sie auf dem gleichen Prozessor laufen.
Diese Überlegungen müssen sich auch in der Risikomanagementakte wiederfinden, insbesondere wenn risikobeherrschenden Maßnahmen durch die Segregation erreicht werden sollten.
Fehler 4: Mangelhafte Implementierung
Papier ist geduldig. Das gilt auch für Architekturdokumente und Risikomanagementakten. Entscheidend ist, dass diese Vorgaben implementiert und damit die Annahmen zutreffend sind.
Zu oft passiert es, dass bei der Entwicklung doch noch eine nicht geplante Methode auf einer Fassadenklasse implementiert wird, welche die Abhängigkeiten von Komponenten erhöht und damit die Segregation sabotiert.
Fehler 5: Unzureichende Verifizierung (z.B. Tests)
Jede risikominimierende Maßnahme muss auf Wirksamkeit überprüft werden. Daraus folgt, dass die Hersteller überprüfen müssen, ob die Segregation wirksam ist. Diese Nachweise gelingen üblicherweise durch Tests. Gesetze und Normen fordern, diese Tests zu planen, durchzuführen, die Ergebnisse zu bewerten und all dies zu dokumentieren.
Manche Tests sind aufwändig. Beispielsweise sind ein Buffer Overflow, ein Absturz einer Laufzeitumgebung oder fehlerhafte Daten von einem Nachbarsystem nicht immer einfach zu simulieren.
Diese Wirksamkeitsnachweise fehlen regelmäßig.
4. Fazit und Zusammenfassung
Software für Medizinprodukte muss sicher sein. Die Segregation von Software-Komponenten ist ein Hebel, um diese Sicherheit zu erreichen und Risiken zu minimieren. Deshalb fordern Regularien die Segregation ein.
Die schwache Kopplung von Komponenten ist eine Voraussetzung für deren Segregation. Ob ein logische Trennung ausreicht oder eine physikalische Trennung zur Segregation notwendig ist, hängt vom Einzelfall ab. Aber eine Segregation ist bei Medizinprodukten fast immer notwendig. Deren Dokumentation und der Nachweis deren Wirksamkeit sind gesetzliche Pflicht.
Änderungshistorie
- 2024-11-26: Artikel fast vollständig neu geschrieben
- 2015-11-27: Erste Version des Artikels veröffentlicht
Guten Tag Herr Johner,
es mag sich meinerseits um ein Verständnisproblem handeln, aber so klar unterschiedliche Hardware, wie Sie aus der 62304 rauslesen, kann ich in folgendem Abschnitt nicht erkennen:
„5.3.5 Festlegung der für die RISIKOBEHERRSCHUNG erforderlichen Abgrenzung
Der HERSTELLER muss die Abgrenzung zwischen den SOFTWARE-KOMPONENTEN festlegen, die für die
RISIKOBEHERRSCHUNG wesentlich ist, und muss zeigen, wie sichergestellt wird, dass die Abgrenzung wirksam
ist.“
Verschiedene Prozessoren mit jeweils eigenen Ressourcen werden nur als ein Beispiel angeführt, nicht aber als die alleinige Lösung zum Problem. Der Hersteller ist in der Verantwortung, diese Lösung zu definieren, hat dort aber von der 62304 wohl auch bewusst Freiheiten bekommen.
Freundliche Grüße
Fabian Pilatus
Lieber Herr Johner,
Ich führte in der Vergangenheit die Segregationsdiskussion intensiv und glaube, dass es sich v.a. um die Unsicherheit handelt, in welchem Verhältnis Risiko, Segregation und Safety Class zueinander stehen.
Die englische Formulierung der Normparagraphen 5.3.5 („The MANUFACTURER shall identify the segregation between SOFTWARE ITEMS that is essential to RISK CONTROL…) bringt nach meinem Verständnis klar zum Ausdruck, dass Segregation eine Antwort des Software Architectural Design auf zuvor identifizierte Risiko-Expositionen ist und kein Selbstzweck. Nach einer erneuten Risikoevaluation kann dann eventuell die Safety Categorie von C auf B reduziert werden – ist also eine mögliche Konsequenz. Kurzgefasst resultiert daraus folgender „Prozess“:
Risiko Evaluation > SW Architectural Design > Risiko Re-Evaluation > Potentielle Reduktion der Safety Class
In diversen Kommentaren und Übersetzungen wird dieser Zusammenhang meines Erachtens nicht klar genug gemacht. Auch die Eingangsformulierung: „Die IEC 62304 verlangt die Notwendigkeit einer Segregation…“ gehört da leider auch dazu :-(.
Ich hoffe, ich konnte einen Beitrag zum besseren Verständnis leisten und habe nicht das Chaos perfektioniert – andernfalls bitte ich um schonendes Anhalten.
Freundliche Grüsse
Stefan Beisswenger
Sehr geehrter Herr Beisswenger,
danke für Ihren Beitrag!
Ich denke, dass wir in die gleiche Richtung denken. Im Beitrag war geschrieben, dass die Risikominimierung ein wichtiges (wenn nicht sogar das wichtigste) Ziel der Segregation ist.
Mit den besten Grüßen und Wünschen
Christian Johner