IEC 62304 verpflichtet Hersteller, das Notwendige bereitzustellen Abgrenzung (auf Deutsch „Abgrenzung“) von Softwarekomponenten. Wie dies zu bewerkstelligen ist, wird in der Norm nicht festgelegt, was zu vielen Diskussionen führt. Antworten auf häufig gestellte Fragen finden Sie hier.
1. Die fünf Ziele der Segregation
Segregation hat mehrere Ziele.
Ziel 1: Risiken minimieren
Die Trennung einer Komponente hilft Risiko dieser Softwarekomponente im Fehlerfall minimieren. Die Abhängigkeiten zwischen dieser getrennten Komponente und den anderen Komponenten desselben Softwaresystems sind schwächer, als dies bei einer nicht oder nur schwach getrennten Komponente der Fall wäre.
Eine Komponente ist dadurch abgesondert, dass sie nicht mehr auf Variablen anderer Komponenten oder sogar auf globale Variablen zugreifen kann. Das bedeutet, dass diese Variable weder gelesen noch verändert werden kann.
Das bedeutet, dass in einer segregierten Komponente ohne diesen Zugriff eine falsche (globale) Variable nicht direkt zu einer Fehlfunktion dieser Komponente führen kann. Eine abgesonderte Komponente kann zudem globale Variablen fälschlicherweise verändern und so zu Fehlfunktionen des gesamten Softwaresystems führen.
In der IEC 62304 wird die Trennung mit Schwerpunkt auf der Risikominimierung erörtert.
Ziel 2: Entwicklung vereinfachen/beschleunigen
Entwicklungsteams profitieren von schwach gekoppelten Komponenten, indem sie ihnen die Arbeit erleichtern
- die Entwicklung auf mehrere Teams aufzuteilen und so zu parallelisieren,
- die am besten geeigneten Technologien für verschiedene Komponenten (z. B. Microservices) zu verwenden und
- die Komponenten selbstständig zu testen und
- in ein Gesamtsystem zu integrieren.
Ziel 3: Dokumentationsaufwand minimieren
Die IEC 62304 ermöglicht die Zuordnung ausreichend getrennter Komponenten zu unterschiedlichen Sicherheitsklassen. Die Dokumentationsanforderungen für Komponenten mit einer niedrigen Sicherheitsklasse (A oder B) sind geringer als für höhere Sicherheitsklassen.
Die Sicherheitsklassen sind ein Konzept der IC 62304, das der FDA nicht bekannt ist. Allerdings lässt die FDA auch einen risikobasierten Umfang der Dokumentation zu.
Überschätzen Sie nicht die Zeitersparnis, die Sie durch die Zuweisung einer Software-(Komponenten-)Sicherheitsklasse B anstelle der Standardklasse C einsparen.
Vielmehr lohnt sich die Zeit für die Erstellung einer belastbaren Softwarearchitektur und eines detaillierten Designs. Denn dadurch kann viel Aufwand eingespart werden
- ineffizient, da keine koordinierte Entwicklung,
- Verbesserungen an fehlerhafter Software und
- die Wartung des Softwaresystems.
Diese Dokumentation erledigen wir in der Regel innerhalb weniger Tage. Kontaktieren Sie uns, wenn Sie Unterstützung wünschen, zum Beispiel über unser Kontaktformular.
Ziel 4: Wartbarkeit erhöhen
Aufgrund ihrer schwachen Kopplung sind getrennte Komponenten einfacher oder besser
- austauschbar/ersetzbar mit anderen Komponenten,
- wiederverwendbar z. B. in anderen Produkten und
- zerlegbar. Dadurch ist es leicht zu verstehen, was eine Komponente tut und welche Konsequenzen es hat, wenn sie dies nicht tut.
Ziel 5: Gesetzliche Anforderungen erfüllen
Hersteller müssen zumindest darüber nachdenken und dokumentieren, ob und in welchem Umfang die Trennung ihrer Softwarekomponenten notwendig ist. Diese Verpflichtung ergibt sich aus der
- ISO 14971, die eine Minimierung von Risiken fordert, beispielsweise durch die Verwendung eines möglichst inhärent sicheren „Designs“,
- IEC 62304, die dies in Kapitel 5.3.5 explizit fordert.
Der HERSTELLER muss jede Trennung zwischen SOFTWAREELEMENTEN identifizieren, die für die RISIKOKONTROLLE erforderlich ist, und angeben, wie sichergestellt werden kann, dass eine solche Trennung wirksam ist. [Class C]
Das bedeutet, dass Hersteller bestimmen müssen, ob und wie verschiedene Komponenten getrennt werden müssen, um Risiken durch eine Komponente zu kontrollieren oder Risikokontrollmaßnahmen effektiv zu gestalten.
Die Norm gibt dies auch im Anhang an:
Die Software-ARCHITEKTUR sollte die Trennung von Softwareelementen fördern, die für einen sicheren Betrieb erforderlich sind, und die Methoden beschreiben, die zur Gewährleistung einer wirksamen Trennung dieser SOFTWAREELEMENTE verwendet werden.
Gemäß Kapitel 4.3 der IEC 62304 gilt die Wirksamkeit der Segregation auch dann, wenn Hersteller einem Softwaresystem unterschiedliche Sicherheitsklassen zuordnen.
2. Möglichkeiten der Segregation
Wenn Sie ein komplettes Softwaresystem herabstufen möchten, erfordert IEC 62304 unabhängige Hardware. Will man nur bestimmten Komponenten eines Softwaresystems eine niedrigere Sicherheitsklasse zuordnen als dem Softwaresystem als Ganzes, wird die Beantwortung der Frage, ob eine Segregation hinreichend begründet ist, schwieriger.
a) Trennung durch unterschiedliche Hardware
Eine Software (Komponente), die auf einem eigenen/unabhängigen Prozessor- und Speicherbereich läuft, ist normalerweise ausreichend getrennt.
Sie können diese Diskussion sogar vermeiden, wenn Sie jeden Teil Ihrer Software, der auf einer eigenen Hardware läuft, als separates Softwaresystem definieren, dem Sie unabhängig eine Sicherheitsklasse zuweisen können.
b) Trennung durch spezielle Prozessoren oder Betriebssysteme
Auch ein dedizierter Prozessor oder ein spezielles Betriebssystem, auf dem verschiedene Prozesse völlig unabhängig voneinander laufen und bei dem sich ihre Speicherbereiche nicht gegenseitig beeinflussen können, kann als hinreichend getrennt begründet werden.
c) Trennung innerhalb der Software auf einem Prozessor
Es wird immer schwieriger, die ausreichende Trennung verschiedener Softwarekomponenten, die auf einem Prozessor laufen, zu rechtfertigen. Hier gilt es zu prüfen, welche Risiken durch eine Segregation minimiert werden sollten.
Für den Patienten besteht das Risiko, dass das medizinische Gerät nicht verfügbar ist, weil die Software insgesamt abstürzt (z. B. aufgrund eines Speicherüberlaufs durch das Betriebssystem). In diesem Fall ist eine logische Trennung der Komponenten (z. B. durch Pakete, private Modifikatoren, OSGI-Bundles, Namespaces) schwer zu argumentieren.
Für den Patienten besteht das Risiko, dass eine Race-Bedingung zu einem Deadlock führen könnte. Wenn ein unabhängiger Prozess auf demselben Prozessor diesen Deadlock identifizieren und angemessen darauf reagieren kann, würde eine Trennung der Prozesse wahrscheinlich ausreichen.
Die Einkomponentenmethode berechnet eine Strahlendosis. Die Methode einer zweiten Komponente prüft diese Werte, bevor sie sie übernimmt. Hinsichtlich dieses logischen Fehlers sind die beiden Komponenten hinreichend getrennt. Wenn die erste Komponente jedoch Werte an die zweite Komponente übergeben kann, die zum Absturz der zweiten Komponente führen (z. B. Pufferüberlauf), wäre eine Trennung nicht ausreichend.
Bitte beachten Sie, dass Trennungsgrenzen, die nur logisch bestehen, immer über das Betriebssystem/den Speicher umgangen werden können. Wenn diese „Umwege“ nicht zu unzumutbaren Risiken führen, ist eine Segregation innerhalb der Software auf einem Prozessor denkbar.
Hersteller sollten stets eine Trennung anstreben, wobei der Fokus auf der Minimierung von Risiken und nicht auf dem Dokumentationsaufwand liegt.
3. Typische Fehler bei der Segregation
Bei der Trennung von Softwarekomponenten kommt es regelmäßig zu Fehlern.
Fehler 1: Mangelnde Segregation
Der Hersteller versäumte es, seine Komponenten zu trennen oder gar zu identifizieren.
Fehler 2: Fehlende Dokumentation
Für Auditoren und Gutachter gilt: Was nicht dokumentiert ist, existiert nicht. Daher reicht es nicht aus, Software mit einer perfekten Architektur aus schwach gekoppelten, also gut getrennten Komponenten zu entwickeln. Diese Architektur- und Designentscheidungen müssen ebenfalls dokumentiert werden.
Fehler 3: Unzureichende Beweise
In PowerPoint gezeichnete Kästchen gelten als Dokumentation, sind aber kein Beweismittel. Hersteller müssen die Schnittstellen dokumentieren und begründen, warum diese Schnittstellen zu einer so schwachen Kopplung der Komponenten führen, dass sie als ausreichend getrennt gelten.
Es wird nicht diskutiert, warum zwei Komponenten ausreichend getrennt sind, insbesondere wenn sie auf demselben Prozessor laufen.
Diese Überlegungen müssen sich auch in der widerspiegeln Risikomanagementdatei Dies gilt wiederum insbesondere dann, wenn Maßnahmen zur Risikokontrolle durch Trennung erreicht werden sollen.
Fehler 4: Schlechte Umsetzung
Papier ist geduldig. Dies gilt auch für Architekturdokumente und Risikomanagementdateien. Entscheidend ist, dass diese Vorgaben umgesetzt werden und die Annahmen somit stimmen.
Zu oft kommt es vor, dass während der Entwicklung eine ungeplante Methode auf einer Fassadenklasse implementiert wird, die die Abhängigkeiten von Komponenten erhöht und somit die Segregation sabotiert.
Fehler 5: Unzureichende Überprüfung (z. B. Tests)
Jede risikominimierende Maßnahme muss auf ihre Wirksamkeit überprüft werden. Daraus folgt, dass Hersteller prüfen müssen, ob die Trennung wirksam ist. Dieser Nachweis wird in der Regel durch Tests erbracht. Gesetze und Normen verlangen, dass diese Prüfungen geplant, durchgeführt, die Ergebnisse ausgewertet und dokumentiert werden.
Manche Tests sind komplex. Beispielsweise sind ein Pufferüberlauf, ein Absturz der Laufzeitumgebung oder fehlerhafte Daten eines Nachbarsystems nicht immer einfach zu simulieren.
Dieser Wirksamkeitsnachweis fehlt regelmäßig.
4. Fazit und Zusammenfassung
Software für medizinische Geräte muss sicher sein. Die Trennung von Softwarekomponenten ist ein Hebel, um diese Sicherheit zu erreichen und Risiken zu minimieren. Aus diesem Grund fordern die Vorschriften eine Rassentrennung.
Die schwache Kopplung der Komponenten ist Voraussetzung für deren Entmischung. Ob eine logische Trennung ausreicht oder zur Abgrenzung eine räumliche Trennung erforderlich ist, hängt vom Einzelfall ab. Bei Medizinprodukten ist jedoch fast immer eine Trennung erforderlich. Ihre Dokumentation und der Nachweis ihrer Wirksamkeit sind gesetzlich vorgeschrieben.
Geschichte ändern
- 26.11.2024: Artikel fast komplett neu geschrieben
- 27.11.2015: Erste Version des Artikels veröffentlicht
