Segregation von Software: 3 Ziele, die Sie kennen sollten

Was ist das Ziel der Segregation?

Die Segregation verfolgt mehrere Ziele:

1. Ziel: Das Risiko durch eine fehlerhafte Software-Komponente zu minimieren.
2. Ziel: Die Wartbarkeit der Software zu erhöhen: Nur segregierte, d.h. schwach gekoppelte Komponenten sind
   • gut (isoliert) testbar
   • einfach austauschbar
   • wiederverwendbar z.B. in anderen Produkten
   • analysierbar d.h. ist einfach nachzuvollziehen, was eine Komponenten macht und was die Auswirkungen sind, wenn sie das nicht tut.
3. Ziel: Den Aufwand für die Dokumentation einer Software-Komponente zu minimieren (die IEC 62304 erlaubt ausreichend segregierten Komponenten unterschiedliche Sicherheitsklassen zuzuweisen).

Seien Sie sich also zuerst klar, welches Ziel Sie mit der Abgrenzung Ihrer Software-Komponenten verfolgen. Wenn es nur das letzte ist, sollten Sie in Betracht ziehen, dass Sie den Aufwand für die Dokumentation einer höheren Software-Sicherheitsklasse überschätzen. Beispielsweise unterscheidet sich der Aufwand für ein Klasse B und eine Klasse C Software kaum.

Mit meinem Team schaffen wir beispielsweise eine Software-Architektur und ein detailliertes Design mit einer Anzahl an Tagen zu erstellen, die Sie an einer Hand abzählen können. Unabhängig von der Sicherheitsklasse!

Ist die Segregation überhaupt verlangt?

Die IEC 62304 verlangt in Kapitel 5.3.5, dass Sie festlegen, wie verschiedene Komponenten segregiert werden müssen, um Risiken durch eine Komponente zu beherrschen bzw. Risikobeherrschungsmaßnahmen wirksam zu gestalten.

Weiter verlangt die IEC 62304 in Kapitel 4 die Wirksamkeit der Segregation dazulegen, wenn einem Software-System verschiedene Sicherheitsklassen zugewiesen werden sollen. Konkret schreibt die Norm: Wenn ein Software-System in Software-Komponenten zerlegt wird und wenn eine Software-Komponente in weitere Software-Komponenten zerlegt wird, so müssen diese Software-Komponenten die Software-Sicherheitsklasse der ursprünglichen Software-Komponente (oder des Software-Systems) übernehmen, es sei denn, der Hersteller dokumentiert eine Begründung für die Klassifizierung in eine andere Software-Sicherheitsklasse. Eine solche Begründung muss darlegen, wie die neuen Software-Komponenten so abgegrenzt sind, dass sie getrennt klassifiziert werden können.

Segregation: Wann ist sie ausreichend?

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.

Daher finden Sie hier einige Gedanken dazu.

Segregation durch unterschiedliche Hardware

Eine Software(komponente), die auf einem eigenen/unabhängigen Prozessor und Speicherbereich läuft, ist sicher ausreichend segregiert. Sie könnten sogar diese Diskussion vermeiden, in dem Sie diesen Teil Ihrer Software als eigenes Software-System definieren, dem Sie unabhängig eine Sicherheitsklasse zuweisen.

Segregation durch spezielle Prozessoren bzw. Betriebssysteme

Ein dezidierter 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.

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.

• Beispiel 1: 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 Speicherüberlauf). In diesem Fall ist eine logische Trennung der Komponenten (z.B. durch Packages, private-Modifier, OSGI-Bundles, Namensräume) schwer zu argumentieren.
• Beispiel 2: 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.

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.

Was kann man bei der Segregation falsch machen?

Die häufigsten Fehler, die wir bei der Segregation von Software-Komponenten beobachten sind:

• Die Segregation ist überhaupt nicht erfolgt bzw. diskutiert.
• Die Segregation ist in der Architektur nicht nachvollziehbar beschrieben. Einige in PowerPoint gemalte Kästchen sind keine Beweisführung. Sie müssen vielmehr die Schnittstellen der Komponenten beschrieben haben (was Kapitel 5.3.2 der IEC 62304 auch verlangt).
• Es ist nicht diskutiert, weshalb zwei Komponenten ausreichend segregiert sind, insbesondere wenn sie auf dem gleichen Prozessor laufen.
• Im Risikomanagement finden sich die segregierten Komponenten nicht (z.B. als Teil einer FMEA). Damit ist nicht nachvollziehbar, welche risikobeherrschenden Maßnahmen durch die Segregation erreicht werden sollten.

Folgen der Segregation

Wie oben dargestellt, verfolgt die Segregation die Ziele

• Risiken zu minimieren,
• die Wartbarkeit zu erhöhen und
• den Dokumentationsaufwand durch Reduktion der Sicherheitsklassen zu verringern.

Es kann durchaus sein, dass eine Segregation nicht ausreichend ist, um eine Reduktion der Sicherheitsklasse ausreichend zu begründen. Dennoch kann es sinnvoll sein, eine solche Maßnahme zu ergreifen, um das Risiko zu minimieren.

Als Beispiel mögen zwei Software-Komponenten dienen: Die eine enthält die Regelungslogik u.a. Fuzzy-Mechanismen. Weil man das Ergebnis dieser Berechnung nicht deterministisch vorhersagen und vollständig testen kann, hat der Hersteller in einer zweiten Komponente eine Überwachung der von der ersten Komponente berechneten Ergebnisse implementiert, um die möglichen Werte „abzuregeln“. Hier wird durch die zweite Komponente somit das „Risiko“ eines Fehlers oder unvorhersagbaren Verhaltens in der ersten Komponente reduziert.

Wenn diese Überwachung korrekt implementiert ist, wird sie das Risiko einer Fehlberechnung oder unerwarteter Ergebnisse minimieren. Ob die Aufteilung in zwei Komponenten ausreichend ist, um ihnen eine unterschiedliche Sicherheitsklasse zuzuweisen, ist eine andere Sache.