Prof. Dr. Christian Johner

Autor: Prof. Dr. Christian Johner

Inhaber der Johner Institut GmbH

Software-Schnittstellen: Beschreibung konform IEC 62304

Mittwoch 19. August 2015

Software-Systeme sollten aus Komponenten bestehen, die über Software-Schnittstellen miteinander kommunizieren. Dieser Artikel beschreibt, wie Sie Software-Schnittstellen IEC 62304 konform dokumentieren können. Dabei zeigt er Konzepte, die sich nicht nur auf interne und externe Software-Schnittstellen, sondern auch auf Hardware-Schnittstellen übertragen lassen.

Update: Internet als interne Schnittstelle?

Software-Schnittstellen

UML Komponentendiagramme verschaffen einen schnellen Überblick über die Software-Schnittstellen eines Software-Systems

Dokumentation von Schnittstellen: Regulatorische Anforderungen

Die IEC 62304 verlangt in Kapitel 5.3.2, dass die Hersteller die Software-Schnittstellen zwischen den Software-Komponenten dokumentieren. Eine nahezu identische Forderung findet sich im Kapitel 5.4.3, die ebenfalls die „Entwicklung eines detaillierten Designs für Schnittstellen“ fordert. Beide Kapitel legen aber nicht fest, wie diese Software-Schnittstellen zu beschreiben/spezifizieren sind.

Ähnlich unkonkret fordert die FDA im Software Validation Guidance eine „definition of all external and user interfaces, as well as any internal software-to-system interfaces;“

Dieser Artikel beschreibt, wie Sie Software-Schnittstellen konform mit der IEC 62304 und den Forderungen der FDA dokumentieren können.

Dokumentation von Software-Schnittstellen

Spezifikationen sollten das spezifizierte Objekt als Blackbox d.h. über dessen Schnittstellen beschreiben. Das gilt für Objekte die Systeme sind (z.B. PEMS oder Software-System) ebenso wie für Komponenten wie beispielsweise PESS oder Softwarekomponenten. Software verfügt über drei Schnittstellentypen:

  1. Benutzer-System-Schnittstellen (User Interface, GUI)
  2. System-System-Schnittstellen (Datenschnittstellen wie APIs, BUS-Systeme, Sensoren, Aktoren, Webservices)
  3. Schnittstelle zur Laufzeitumgebung

1. Schritt: Übersicht über die Software-Schnittstellen mit Komponentendiagrammen

Wie granular Sie die Software-Schnittstellen spezifizieren müssen, sagt die IEC 62304 nicht. Sie müssen Sie aber dokumentieren. Der erste und einfachste Schritt besteht darin, die Schnittstellen überhaupt in der Software-Architektur kenntlich zu machen. Hier empfehle ich Komponenten-Diagramme und die Lolipop-Notation (siehe Abb. 1). Die Lollipops helfen Ihnen besonders gut zu visualisieren, welche Schnittstellen es gibt, welche Software-Komponenten die Schnittstellen implementieren und welche Komponenten die Schnittstellen anderer Komponenten nutzen.

2. Schritt: Beschreibung der Software-Schnittstellen

Eine bloße Nennung der Schnittstellen ist aber noch etwas zu wenig, sowohl um Normenkonformität zu erreichen als auch um den eigentlichen Sinn dieser Dokumentation zu erreichen: Den Entwicklern und den Komponenten-Testern ausreichend Informationen für deren Arbeit zu geben.

Programmierschnittstellen API

Daher besteht der nächste Schritt darin, die API der Schnittstellen zu formulieren. Erst damit spezifizieren Sie wirklich die Komponenten. Die API beschrei

  1. Namen und Zweck der Funktionen/Methoden
  2. Name, Bedeutung und Wertebereiche von Übergabe- und Rückgabeparametern
  3. Verhalten der Komponente bei Nutzung einer Methode. Dieses Verhalten kann sich nur über eine Schnittstellen der Komponente zeigen. Software-Komponenten haben nur folgende Schnittstellen-Typen: Zum Anwender (UI), zu anderen Systemen (d.h. wieder über Funktionen/Methoden) und zur Laufzeitumgebung einschließlich Hardware bzw. Sensorik.

Andere Schnittstellentypen

Wenn Sie andere Software-Schnittstellen beschreiben müssen wie z.B.

  • Webservices
  • REST-Schnittstellen
  • Bussysteme (CAN-Bus, USB, I2C …)
  • usw.

empfehlen wir Ihnen, diese anhand des Interoperabilitätsmodells zu spezifizieren und auf Vollständigkeit zu prüfen.

Zu viel Arbeit

Wenn Sie das Gefühl haben, dass diese Beschreibung zu aufwendig weil zu umfangreich sei, dann ist das ein Hinweis, dass Sie zu „breite“ Schnittstellen und damit eine suboptimale Kapselung Ihrer Komponenten planen: Eine schlechte Architektur.

3. Schritt: Dokumentation von „nicht-funktionalen“ Eigenschaften

Ergänzen Sie die Beschreibung Ihrer API um nicht-funktionale Eigenschaften wie

  1. Performanz: Wie schnell muss die Komponente auf Aufrufe über die Schnittstelle reagieren? Wie ändert sich diese Geschwindigkeit in Abhängigkeit von der Anzahl der Aufrufe pro Zeiteinheit oder von der Größe der übertragenen Daten?
  2. Security: Werden die Daten verschlüsselt übertragen? Auf welcher Übertragungsschicht? Wie müssen sich andere Komponenten an unserer autorisieren?
  3. Zuverlässigkeit/Robustheit: Wie reagiert die Komponente auf fehlerhafte Inputs um, auf fehlende Inputs, auf Inputs in falscher Reihenfolge? Fehlerhaft beinhaltet: Falsche Datentypen, falsche Wertebereiche, falsche Kodierung (sowohl auf strukturelle, syntaktischer und semantischer Ebene), falsche Datenmengen, falsche Aufrufgeschwindigkeit usw.

4. Schritt: Dokumentation von Software-Schnittstellen bei SOUPs

SOUPs sind zuerst nichts anderes als Komponenten in Ihrem Software-System. Entsprechend muss die Architektur diese Komponenten erkennen lassen. Die Besonderheit besteht aber darin, dass SOUPs insbesondere Frameworks (z.B.  .NET) häufig so viele Funktionen anbieten, dass eine API-Beschreibung durch den Medizinprodukte-Hersteller nicht mehr sinnvoll möglich ist. Ein bloßer Verweis auf die API des SOUP-Herstellers würde aber auch nicht genügen, weil damit nicht klar wäre, wie die eigenen Komponenten mit der SOUP interagieren.

In diesem Fall können Sie statt konkrete Interfaces auf „abstrakte“ Interfaces verweisen. Beispiele dafür wären „Persistenz“, „Webservice“ und „UI“. Dass natürlich eine UI 1000e Klassen und noch mehr Methoden bereitstellt, ist unbestritten. Diese aber zu listen von endlichem Wert. Im Gegenteil, der Sinn einer Architektur wäre damit konterkarie

  1. Entwicklern und Testern eine präzise Vorgabe für deren Arbeit geben
  2. Die Güte der Architektur bewerten können.
  3. Auswirkungen von Änderungen auf andere Komponenten und damit Risiken beurteilen können.

Interne versus externe Software-Schnittstellen

Medizinprodukte, gleich ob standalone Software oder Medizingeräte, sollten aus Komponenten bestehen. Damit haben Medizinprodukte nicht nur externe Schnittstellen, sondern auch interne, nämlich zwischen den einzelnen Komponenten.

Komponenten-interne-externe-Schnittstellen

Abb 1.: Externe Schnittstellen sind immer auch interne Schnittstellen (hier mit orangenen Kreisen markiert). Umgekehrt haben interne Schnittstellen nicht immer ein externes Pendant.

Interne = externe Schnittstellen?

Zerlegt man das Objekt in (Sub-)Komponenten, gilt es im nächsten Schritt diese Subkomponenten zu spezifizieren. Und auch dieses Mal sollten die Schnittstellen beschrieben sein. Dabei kann und muss es vorkommen, dass die Schnittstellen der äußeren Komponente gleichzeitig die der inneren Komponenten sind.

Beispielsweise wird die GUI eines Medizingeräts gleichzeitig die GUI der Subkomponente sein, auf der die „Software-GUI“ läuft. Eine „Ethernet-Schnittstelle“ wird direkt zu einer Subkomponente durchgereicht.

Natürlich spezifiziert man diese Schnittstellen nicht redundant, sondern verweist in der Sub-Komponenten-Spezifikation auf die entsprechende Spezifikation der übergeordneten Komponente. Wohlgemerkt von der Sub-Komponente zur übergeordneten Komponente.

Internet als interne Software-Schnittstelle?

Eine Software-Schnittstelle zum Internet ist immer eine externe Schnittstelle, richtig oder? Nein: Ob eine solche Schnittstelle intern oder extern ist, hängt davon ab, was man als Medizinprodukt definiert.

Internet: Interne oder externe Software-Schnittstelle

Wenn Sie beispielsweise

  • das Gesamtsystem aus Mobile Medical App und zugehöriger Server-Software als ein Medizinprodukt und
  • zugleich die Gesamtheit aller Software als Ihr Software-System

definieren, dann ist das Internet eine interne(!) Software-Schnittstelle, die zwei Komponenten des Software-Systems verbindet: Eben die Medical-App-Software-Komponente mit der Server-Software-Komponente.

Wir raten Ihnen allerdings davon ab, das Software-System als Gesamtheit aller Software zu definieren. Ein Software-System sollte immer an den Grenzen der jeweiligen Prozessor-/Speichereinheit enden. In obigem Beispiel hätte man somit zwei Software-Systeme: die App und die Server-Software. Dann sind die Schnittstellen zum Internet jeweils externe Software-Schnittstellen.

Diese Aufteilung empfehlen wir übrigens unabhängig davon, ob Sie beide Systeme zu einem Medizinprodukt zählen oder nicht.

Typische Fehler

Falscher Zeitpunkt

Sie sollten keinesfalls in der übergeordneten Komponente diese Spezifikation der Software-Schnitttstellen noch offen lassen, um das zu einem späteren Zeitpunkt nachzuholen, nämlich dem Zeitpunkt, zu dem die Subkomponente spezifiziert wird. Wer das tut, läuft Gefahr

  • Fehler zu spät zu bemerken, unnötige Nachbesserungen zu verursachen und dadurch das Projekt zu verzögern,
  • missverstandene Anforderungen des Kunden zu spät zu entdecken und dadurch Konflikte mit ihm zu verursachen,
  • wider den Vorschriften der Normen zu entwickeln,
  • Rollen mit Aufgaben zu beauftragen, die dafür nicht ausgebildet sind beispielsweise Entwickler mit der Spezifikation der GUI statt Usability Engineers.

In den Videotrainings im Auditgarant beschreibe ich genau, wie Sie Schnittstellen schnell und normenkonform spezifizieren können und so die Voraussetzung für eine zielgerichtete Entwicklung ohne unnötige Nachbesserungsschleifen schaffen.

Videotrainings ansehen

Fehler in der IEC 62304 mit Bezug zu Software-Schnittstellen

Die IEC 62304 ist leider unpräzise um nicht sogar zu sagen falsch an einigen Stellen des Kapitel 5.3. Es ist gerade nicht Gegenstand der Schnittstellen-Bescheibung auf externe Schnittstellen einzugehen. Das ist Gegenstand der Software-Anforderungen, die das System aus Blackbox-Sicht beschreiben sollen.


Kategorien: Software & IEC 62304
Tags: , ,

2 Kommentare über “Software-Schnittstellen: Beschreibung konform IEC 62304”

  1. Heiko Schmidt schrieb:

    Hallo Herr Johner

    Wie sie erwähnt haben, verlangt Kapitel 5.3.2 der 62304 genau diese Beschreibung der Schnittstellen zwischen SW-Komponenten.

    Kapitel 5.4.3 der 62304 verlangt aus meiner Sicht genau das Identische, nur auf SW-Einheiten Ebene.
    Somit könnte ich die von Ihnen beschriebene Vorgehensweise auch auf SW-Einheiten Ebene anwenden.
    Sehen Sie das genauso?

  2. Christian Johner schrieb:

    Das sehe ich absolut genauso, lieber Herr Schmidt!

    Leider ist die Norm so unsauber, dass es in der Tat diesbezüglich immer wieder zu Fragen kommt. Die fraktale Darstellung von PEMS > PESS > Software > Komponente sollte auch auf die „Sub-Komponenten“ bzw. Einheiten fortgesetzt werden.

    In anderen Worten: Nutzen Sie genau das gleiche Vorgehen auf für die „kleinsten“ Komponenten. Also genau wie Sie vermuten.

Kommentar schreiben