Prof. Dr. Christian Johner

Autor: Prof. Dr. Christian Johner

Inhaber der Johner Institut GmbH

Segregation von Software: 3 Ziele, die Sie kennen sollten

Freitag 27. November 2015

Die IEC 62304 verlangt die Notwendigkeit einer Segregation (auf Deutsch „Abgrenzung“) von Software-Komponenten. Wie diese zu erfolgen hat, legt die Norm nicht fest, was zu vielen Diskussionen führt. Finden Sie hier Antworten auf häufige Fragen.

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!Segregation von Software-Komponenten

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.


Kategorien: Software & IEC 62304

3 Kommentare über “Segregation von Software: 3 Ziele, die Sie kennen sollten”

  1. Fabian P. schrieb:

    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

  2. Stefan Beisswenger schrieb:

    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

  3. Christian Johner schrieb:

    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

Kommentar schreiben