Interne Software -Schnittstellen sind erforderlich, um Softwarekomponenten innerhalb eines Softwaresystems zu verbinden. Externe Software -Schnittstellen sind die Voraussetzung, damit das Software -System mit anderen Systemen kommunizieren kann.
In diesem Artikel wird beschrieben, wie Sie Software -Schnittstellen gemäß dem Gesetz dokumentieren können.
1. Differenzierung interner gegen externe Software -Schnittstellen
1.1 Übersicht
Produkte wie medizinische Geräte, ob eigenständige Software oder physische Geräte, sollten aus Komponenten bestehen. Dies bedeutet, dass Produkte nicht nur externe Schnittstellen verwenden, sondern auch intern, nämlich zwischen den einzelnen Komponenten.
1.2 Sonderfall “intern = externe Schnittstellen”
Wenn Sie das Softwaresystem in Komponenten einteilen, besteht der nächste Schritt darin, diese Komponenten und deren Schnittstellen anzugeben. Es kann und muss passieren, dass die Schnittstellen der äußeren Komponente gleichzeitig der der inneren Komponenten sind.
Zum Beispiel wird die GUI eines medizinischen Zentrums auch die GUI der Komponente sein, auf der die “Software -GUI” ausgeführt wird. “Datenschnittstellen” werden ebenfalls direkt in eine Komponente übergeben, die diese Datenschnittstelle implementiert hat.
Geben Sie diese Schnittstellen nicht redundant an, sondern beziehen Sie sich auf die entsprechende Spezifikation des übergeordneten medizinischen Geräts oder der übergreifenden Komponente in der Komponentenspezifikation.
1.3 Spezialfall “Internet als interne Software -Oberfläche”
Ob eine “Internet -Schnittstelle” intern oder extern ist, hängt davon ab, was Sie als System als medizinisches Gerät definieren.
Wenn zum Beispiel das Gesamtsystem der mobilen medizinischen App und die zugehörige Serversoftware als A Definieren Sie das medizinische Gerät und gleichzeitig die gesamte Software als Softwaresystem, dann ist das Internet eins intern (!) Software -Schnittstelle, die zwei Komponenten des Softwaresystems verbindet: die Softwarekomponente für medizinische Apps mit der Server -Softwarekomponente.
Wir raten uns, das Softwaresystem als gesamte Software zu definieren. Ein Softwaresystem sollte immer an den Grenzen der jeweiligen Prozessor-/Speichereinheit enden. Im obigen Beispiel haben Sie zwei Softwaresysteme: die App und die Serversoftware. Dann sind die Schnittstellen zum Internet externe Software -Schnittstellen.
Übrigens empfehlen wir diese Aufteilung, unabhängig davon, ob Sie beide Systeme auf einem medizinischen Gerät sind oder nicht.
2. Regulatorische Anforderungen
Sterben IEC 62304 In Kapitel 5.3.2 benötigen die Hersteller die Software -Schnittstellen zwischen den Softwarekomponenten. In Kapitel 5.4.3 gibt es auch eine fast identische Anforderung “Entwicklung eines detaillierten Designs für Schnittstellen” Forderungen.
Beide Kapitel erfordern die Dokumentation der Software -Schnittstellen, bestimmen jedoch nicht, wie diese Software -Schnittstellen beschrieben/angegeben werden sollen.
Die Anforderungen ähnlich unkontrolliert FDA IM -Software -Validierungsanleitung eins „Definition aller externen und Benutzeroberflächen sowie alle internen Software-System-Schnittstellen;
Wenn Sie die Schnittstellen Ihrer Software wie unten vorgeschlagen dokumentieren, erfüllen Sie die regulatorischen Anforderungen.
3. Dokumentation von Software -Schnittstellen
Spezifikationen sollten das angegebene Objekt als Black Box DH über seine Schnittstellen beschreiben. Dies gilt für Produkte oder Systeme (z. B. physische Geräte mit medizinischen Geräten (PEMs) oder eigenständigem Softwaresystem) sowie für Komponenten solcher Systeme (z. B. programmierbare elektrische Subsysteme oder Softwarekomponenten).
Software- und Softwarekomponenten haben maximal drei Stecklinge:
- Benutzersystem -Schnittstellen (Benutzeroberfläche, GUI)
- System -System -Schnittstellen (Datenschnittstellen wie APIs, Bussysteme, Sensoren, Aktuatoren, Webdienste)
- Schnittstelle zur Laufzeitumgebung
Schritt 1: Identifizieren Sie Software -Schnittstellen
Standards wie die IEC 62304 bestimmen nicht, wie granulär Sie die Software -Schnittstellen angeben müssen. Sie müssen jedoch die Schnittstellen dokumentieren.
Der erste und einfachste Schritt besteht darin, die Schnittstellen in der Softwarearchitektur zu identifizieren. Komponentendiagramme und die Lolipop -Notation (siehe Abb. 2) werden hier empfohlen.
Die Lolipops helfen Ihnen besonders gut bei der Visualisierung, welche Schnittstellen, welche Softwarekomponenten die Schnittstellen implementieren und welche Komponenten die Schnittstellen anderer Komponenten verwenden.
Schritt 2: Geben Sie die identifizierten Software -Schnittstellen an
Eine bloße Benennung der Schnittstellen reicht jedoch nicht aus, um die Standardkonformität und die tatsächliche Bedeutung dieser Dokumentation zu erreichen:
Bereitstellung des Programmierteams und der Personen, die die Komponenten ausreichend Informationen für ihre Arbeit testen.
Programmierschnittstellen API
Der nächste Schritt besteht daher darin, die API der Schnittstellen anzugeben. Erst dann bestimmen Sie wirklich die Anforderungen für die Komponenten. Die API beschreibt:
- Name und Zweck der extern verfügbaren Funktionen/Methoden
- Name, Bedeutung und Wertebereich von Übergabe- und Rückgabeparametern
- Verhalten der Komponente bei Verwendung einer Funktion/Methode. Dieses Verhalten kann nur über eine Schnittstelle der Komponente gezeigt werden.
Andere Stecklinge
Wenn Sie andere Software -Schnittstellen wie z. B. beschreiben müssen
- Webservices
- Verbleibende Schnittstellen
- BUSSYSTEME (CAN-BUS, USB, I2C…)
- usw.
Wir empfehlen, sie anhand des Interoperabilitätsmodells anzugeben und sie auf Vollständigkeit zu überprüfen.
Schritt 3: Vollständige “nicht funktionierende” Anforderungen
Vervollständigen Sie die Beschreibung Ihrer API durch nicht funktionale Anforderungen wie z. B.
- Leistung: Wie schnell muss die Komponente über die Schnittstelle auf Ansichten reagieren? Wie ändert sich diese Geschwindigkeit abhängig von der Anzahl der Ansichten pro Zeiteinheit oder der Größe der übertragenen Daten?
- Sicherheit: Sind die Daten verschlüsselt? Auf welcher Übertragungsschicht? Wie müssen sich andere Komponenten in den angegebenen Genehmigungen autorisieren?
- Zuverlässigkeit/Robustheit: Wie reagiert die Komponente auf fehlerhafte Eingänge, fehlende Eingänge, auf Eingänge in der falschen Reihenfolge? Falsch enthält: falsche Datentypen, falsche Wertbereiche, falsche Codierung (sowohl auf struktureller, syntaktischer und semantischer Ebene), falsche Datenmenge, falsche Anrufgeschwindigkeit usw.
Schritt 4: Dokumentspezifische Fall “Software -Schnittstellen bei Suppen”
Suppen sind zunächst nichts weiter als Komponenten in ihrem Softwaresystem. Dementsprechend muss die Architektur diese Komponenten anzeigen. Die Besonderheit ist jedoch, dass insbesondere Suppen so viele Funktionen anbieten, dass eine API -Beschreibung nicht mehr möglich ist. Ein bloßer Hinweis auf die API des Suppenherstellers würde auch nicht ausreichen, da nicht klar wäre, wie Ihre eigenen Komponenten mit der Suppe interagieren.
In diesem Fall können Sie anstelle von konkreten Schnittstellen auf “abstrakte” Schnittstellen verweisen. Beispiele wären “Persistenz” und “UI”. Es ist unbestritten, dass ein UI 1000E -Klassen und noch mehr Methoden noch mehr Methoden liefern. Aber dies wäre ein endgültiger Wert. Im Gegenteil, der Bedeutung einer Architektur würde entgegengewirkt:
- Entwicklern und Tester eine genaue Voraussetzung für ihre Arbeit geben
- Kann die Qualität der Architektur bewerten.
- Auswirkungen von Änderungen an anderen Komponenten und damit können Risiken bewerten.
4. Typische Fehler
4.1 falsche Zeit
Unter keinen Umständen sollten Sie diese Spezifikation der Software-Schnittpunkte in der übergreifenden Komponente offen lassen, um dies zu einem späteren Zeitpunkt auszugleichen, nämlich der Zeit, zu der die Unterkomponente angegeben ist. Wer macht das Gefahr?
- Fehler zu spät zu bemerken, um unnötige Verbesserungen zu verursachen und damit das Projekt zu verzögern.
- Fehlverständliche Anforderungen des Kunden zu spät zu entdecken und damit Konflikte mit ihm zu verursachen.
- sich gegen die Vorschriften der Normen zu entwickeln,
- Rollen mit Aufgaben, die dafür nicht geschult sind, beispielsweise Entwickler mit der Spezifikation der GUI anstelle von Benutzerfreundlichkeitsingenieuren ausgebildet.
Im Video -Training im Auditgarant beschreibe ich genau, wie Sie Schnittstellen schnell und gemäß den Standards angeben und so die Voraussetzung für die gezielte Entwicklung ohne unnötige Wiederherstellungsschleifen erstellen können.
4.2 Unangemessene Verantwortlichkeiten
Die IEC 62304 ist leider in einigen Stellen in Kapitel 5.3 irreführend. Die externen Schnittstellen eines Produkts sollten bereits als Teil der Produktanforderungen angegeben werden. Dies ist normalerweise nicht die Aufgabe der Softwareentwicklung.
Die externen Schnittstellen der Softwaresysteme sollten gemäß den Anforderungen in Kapitel 5.2 des IEC 62304 formuliert werden. Es ist nicht erforderlich, diese Anforderungen als Teil der Softwarearchitektur in Kapitel 5.3 anzugeben.
c) Schlechte Architektur
Schwierigkeiten bei der Angabe von Software -Schnittstellen können ein Hinweis auf eine schlechte Softwarearchitektur sein.
| Schwierigkeit | Hinweis zu einem möglichen Problem |
| Es ist sehr komplex, eine Software -Schnittstelle zu beschreiben | Verletzung des Paradigmas “schwache Kopplung”, weil eine “schwache Kopplung” eine “schmale Schnittstelle” bedeutet |
| Es gibt viele Komponenten, deren Schnittstellen angegeben werden sollen | Verletzung des Heuristik von 7 +/- 2 Komponenten, was zu so etwas wie dem “Windows-Dll-hölle” (Warteproblem) führen kann |
| Eine Komponente hat viele Schnittstellen | Verletzung des Paradigmas “schwache Kopplung”, weil eine “schwache Kopplung” nur wenige Schnittstellen bedeutet |
5. Schlussfolgerung
Es ist vergleichsweise einfach, die regulatorischen Anforderungen für die Dokumentation der Software -Schnittstellen zu erfüllen. Es ist schwieriger, gute Softwarearchitekturen zu entwerfen, die zu einigen und schlanken Software -Schnittstellen führen.
Registrieren Sie sich (z. B. über das Kontaktformular), um mit den Software- und Regulierungsexperten des Johner -Instituts zu klären, wie Sie genau gestalten können, und auf Softwarearchitekturen und dokumentieren Softwareentwicklung schlank, verständlich und entsprechend den Standards.
Geschichte verändern
- 2025-01-30: Veröffentlicht vollständig überarbeitet und aktualisiert, Reihenfolge der Kapitel ausgetauscht
- 2018-05-10: Erste Version des erstellten Beitrags