Software-Schnittstellen konform IEC 62304

Interne Software-Schnittstellen sind notwendig, um Software-Komponenten innerhalb eines Software-Systems zu verbinden. Externe Software-Schnittstellen sind die Voraussetzung dafür, dass das Software-System mit anderen Systemen kommunizieren kann.

Dieser Artikel beschreibt, wie Sie Software-Schnittstellen gesetzeskonform und praxisnah dokumentieren können.

1. Interne vs. externe Software-Schnittstellen

1.1 Übersicht

Medizinprodukte, gleich ob Standalone-Software oder physische Geräte, bestehen aus Komponenten. Damit nutzt ein Produkt nicht nur externe Schnittstellen, sondern auch interne, nämlich zwischen den einzelnen Komponenten.

1.2 Sonderfall: interne = externe Schnittstelle

Zerlegt man das Software-System in Komponenten, gilt es im nächsten Schritt, diese Komponenten und deren Schnittstellen zu spezifizieren. Dabei kann und muss es vorkommen, dass die Schnittstellen der äußeren Komponente gleichzeitig die der inneren Komponenten sind.

Beispiel: Die GUI eines Medizingeräts wird gleichzeitig die GUI der Komponente sein, auf der die „Software-GUI“ läuft. Auch „Daten-Schnittstellen“ werden direkt zu einer Komponente durchgereicht, welche diese Daten-Schnittstelle implementiert.

1.3 Sonderfall: Internet als interne Software-Schnittstelle

Ob eine „Internet-Schnittstelle“ intern oder extern ist, hängt davon ab, was man als System (z. B. als Medizinprodukt) definiert.

Wenn Sie beispielsweise das Gesamtsystem aus einer Mobile Medical App und der zugehörigen Server-Software als ein Medizinprodukt und zugleich die Gesamtheit aller Software als ein Software-System definieren, dann ist das Internet eine interne(!) Software-Schnittstelle, die zwei Komponenten des Software-Systems verbindet: die Medical-App-Software-Komponente mit der Server-Software-Komponente.

2. 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 verlangen die Dokumentation der Software-Schnittstellen, 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“.

Wenn Sie die Schnittstellen Ihrer Software wie nachfolgend vorgeschlagen dokumentieren, erfüllen Sie die regulatorischen Anforderungen.

3. Dokumentation von Software-Schnittstellen

Spezifikationen sollten das spezifizierte Objekt als Blackbox beschreiben, d. h. über dessen Schnittstellen. Das gilt für Produkte bzw. Systeme (z. B. physische Geräte mit Medizingeräten (PEMS) oder Standalone-Software-Systeme) ebenso wie für Komponenten solcher Systeme, z. B. Programmierbare Elektrische Subsysteme (PESS) oder Software-Komponenten. 

Software und Software-Komponenten verfügen über maximal drei Schnittstellentypen:

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

Schritt 1: Software-Schnittstellen identifizieren

Wie granular Sie die Software-Schnittstellen spezifizieren müssen, legen die Normen (wie die IEC 62304) nicht fest. Sie müssen die Schnittstellen aber dokumentieren.

Der erste und einfachste Schritt besteht darin, die Schnittstellen überhaupt in der Software-Architektur kenntlich zu machen. Hier empfehlen sich Komponenten-Diagramme und die Lollipop-Notation (siehe Abb. 3). 

Mit Lollipops können Sie besonders gut visualisieren, welche Schnittstellen es gibt, welche Software-Komponenten die Schnittstellen implementieren und welche Komponenten die Schnittstellen anderer Komponenten nutzen.

Schritt 2: Die identifizierten Software-Schnittstellen spezifizieren

Eine bloße Nennung der Schnittstellen ist nicht ausreichend, um Normenkonformität und den eigentlichen Sinn dieser Dokumentation zu erreichen, also dem Programmier-Team und den Personen, die die Komponenten testen, ausreichend Informationen für deren Arbeit bereitzustellen.

Programmierschnittstellen API

Daher besteht der nächste Schritt darin, die API der Schnittstellen zu spezifizieren. Erst damit legen Sie wirklich die Anforderungen an die Komponenten fest. Die API beschreibt:

1. Namen und Zweck der nach außen verfügbaren Funktionen/Methoden
2. Name, Bedeutung und Wertebereiche von Übergabe- und Rückgabeparametern
3. Verhalten der Komponente bei Nutzung einer Funktion/Methode. Dieses Verhalten kann sich nur über eine Schnittstelle der Komponente zeigen.

Andere Schnittstellentypen

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

• Webservices
• REST-Schnittstellen
• Bus-Systeme (CAN-Bus, USB, I2C …)

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

Schritt 3: „Nichtfunktionale“ Anforderungen ergänzen

Ergänzen Sie die Beschreibung Ihrer API um nichtfunktionale Anforderungen 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 der spezifizierten autorisieren?
3. Zuverlässigkeit/Robustheit: Wie reagiert die Komponente auf fehlerhafte Inputs, auf fehlende Inputs, auf Inputs in falscher Reihenfolge? Fehlerhaft beinhaltet: falsche Datentypen, falsche Wertebereiche, falsche Codierung (sowohl auf struktureller, syntaktischer und semantischer Ebene), falsche Datenmengen, falsche Aufrufgeschwindigkeit usw.

Schritt 4: Sonderfall „Software-Schnittstellen bei SOUP“ dokumentieren

SOUP sind zuerst nichts anderes als Komponenten in Ihrem Software-System. Entsprechend muss die Architektur diese Komponenten erkennen lassen. Die Besonderheit besteht darin, dass SOUP (insbesondere Frameworks, z. B.  .NET), häufig so viele Funktionen anbieten, dass eine API-Beschreibung 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 geklärt ist, wie die eigenen Komponenten mit der SOUP interagieren.

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

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

4. Typische Fehler

4.1 Falscher Zeitpunkt

Sie sollten keinesfalls in der übergeordneten Komponente diese Spezifikation der Software-Schnittstellen offen lassen und das erst nachholen, wenn 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 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).

4.2 Unpassende Verantwortlichkeiten

Die IEC 62304 ist leider an einigen Stellen in Kapitel 5.3 irreführend. Die externen Schnittstellen eines Produkts sollten bereits als Teil der Produktanforderungen spezifiziert werden. Das ist typischerweise nicht die Aufgabe der Software-Entwicklung.

Die externen Schnittstellen des Software-Systems sollten konform den Anforderungen im Kapitel 5.2 der IEC 62304 formuliert werden. Es gibt keine Notwendigkeit, diese Anforderungen als Teil der Software-Architektur im Kapitel 5.3 zu spezifizieren.

4.3 Schlechte Architektur

Schwierigkeiten bei der Spezifikation der Software-Schnittstellen können ein Hinweis auf eine schlechte Software-Architektur sein.

Schwierigkeit	Hinweis auf mögliches Problem
Es ist sehr aufwändig, eine Software-Schnittstelle zu beschreiben.	Verstoß gegen die Heuristik von 7 +/- 2 Komponenten, was zu etwas wie der „Windows-DLL-Hölle“ führen kann (Wartbarkeitsproblem)
Es gibt sehr viele Komponenten, deren Schnittstellen zu spezifizieren sind.	Verstoß gegen das Paradigma „Weak Coupling“, denn ein „Weak Coupling“ bedeutet wenige Schnittstellen
Eine Komponente hat sehr viele Schnittstellen.	Verstoß gegen das Paradigma „Weak Coupling“, denn ein „Weak Coupling“ bedeutet wenige Schnittstellen

5. Fazit

Es ist vergleichsweise einfach, die regulatorischen Anforderungen an die Dokumentation von Software-Schnittstellen zu erfüllen. Schwieriger ist es, gute Software-Architekturen zu entwerfen, die in wenigen und schlanken Software-Schnittstellen münden.

---

Änderungshistorie

• 2025-01-30: Beitrag komplett überarbeitet und aktualisiert, Reihenfolge der Kapitel getauscht
• 2018-05-10: Erste Version des Beitrags erstellt