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. Die Abhängigkeiten zwischen einer segregierten Komponente und den anderen Komponenten des 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. Sie kann also diese Variable weder 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. Es fällt dann einfacher,
- die Entwicklung auf mehrere Teams aufzuteilen und damit zu parallelisieren,
- für verschiedene Komponenten (z. B. Micro-Services) die jeweils passendsten Technologien zu verwenden,
- die Komponenten unabhängig voneinander zu testen und
- in 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 IEC 62304, das die FDA nicht kennt. Allerdings erlaubt auch die FDA einen Dokumentationsumfang, der „risk-based“ ist.
Überschätzen Sie nicht die Zeit, die Sie einsparen, wenn Sie einer Software-(Komponente) die Sicherheitsklasse B statt der Default-Klasse C zuweisen.
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ünschen, beispielsweise über unser Kontaktformular.
Ziel 4: Wartbarkeit erhöhen
Segregierte Komponenten sind dank ihrer schwachen Kopplung einfacher bzw. besser
- austauschbar/ersetzbar durch andere Komponenten,
- wiederverwendbar, z. B. in anderen Produkten, und
- analysierbar; es ist einfach nachzuvollziehen, was eine Komponente 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 zu welchem Zeitpunkt die Segregation ihrer Software-Komponenten notwendig ist. Diese Pflicht ergibt sich aus der
- ISO 14971, die 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 in 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]
Mit anderen Worten: Hersteller müssen festlegen, ob und wie verschiedene Komponenten segregiert werden müssen, um Risiken durch eine Komponente zu beherrschen bzw. Maßnahmen zur Risikobeherrschung 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 darzulegen, 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ängige Hardware. Wenn Sie nur bestimmten Komponenten eines Software-Systems eine niedrigere Sicherheitsklasse zuweisen und nicht dem Software-System insgesamt, wird die Antwort auf die Frage, ob eine Segregation 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 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 vollkommen 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 durch das Betriebssystem verursachten Speicherüberlaufs). 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 die Patienten dadurch, dass eine Race-condition zu einem Dead-lock führt. Falls 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 diesen Wert, bevor sie ihn übernimmt. Die beiden Komponenten 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 anstreben, um Risiken zu minimieren – nicht den Dokumentationsaufwand.
3. Typische Fehler bei der Segregation
Bei der Segregation von Software-Komponenten passieren regelmäßig 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, existiert nicht. Daher genügt es nicht, eine Software mit einer perfekten Architektur aus schwach gekoppelten, d. h. gut segregierten Komponenten zu entwickeln. Die 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 wird 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, vor allem, wenn durch die Segregation risikobeherrschende Maßnahmen 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 eine 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.
Die Dokumentation der Segregation und der Nachweis ihrer Wirksamkeit sind gesetzlich gefordert.
Ä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
Guten Morgen Herr Johner,
ich bin soeben durch Ihren informativen Newsletter auf die Segregation gestoßen. In der Regel sollte das ja kein Problem darstellen, da Segregation unserer Meinung zur best practice gehört.
Sie schreiben, dass die Dokumentation der Segregation und der Nachweis ihrer Wirksamkeit gesetzlich gefordert sind. An welcher Stelle der Software- oder Risikomanagementakte findet das denn statt? Darauf sind wir nämlich noch nicht gestoßen.
Ich hoffe Sie können mir weiterhelfen,
vielen Dank im Voraus und freundliche Grüße
Esther Diehm
Sehr geehrte Frau Diem,
Se stellen eine großartige Frage! Danke!
Die Forderung der Diskussion der Segregation betrifft v.a. das Thema Software-Sicherheitsklasse. Diese Diskussion gehört in die Software-Akte.
Die Segregation dient aber v.a. auch der Risikominimierung. Die Wirksamkeit solcher Maßnahmen sind Inhalt von Risikomanagementakten.
Nochmals besten Dank!
Herzliche Grüße, Christian Johner