Software-Architektur (IEC-62304-konform)

Hersteller müssen für Medizinprodukte-Software fast immer eine Software-Architektur entwerfen und diese verifizieren.

1. Grundlagen

a) Ziel

Die Software-Architektur dient dem Software-Entwicklungsteam als Input, um die Software wie geplant (Zeit, Geld, Qualität) entwickeln zu können. Sie soll damit Entwicklungsrisiken minimieren und sicherstellen, dass die Software die Software-Anforderungen erfüllt.

b) Definition

Unter Software-Architektur versteht man sowohl eine Phase mit einem Satz an Aktivitäten als auch das Ergebnis dieser Aktivitäten. Die meisten Definitionen zielen auf das letztere.

Eine anschauliche Definition stammt von Martin Fowler:

2. Software-Architektur im Entwicklungslebenszyklus

a) Standalone-Software (Software as a Medical Device)

Bei Standalone-Software ist die Software-Architektur der „Bauplan“, der vorgibt, wie die Software-Anforderungen (der Input) in Software umgesetzt werden soll (s. Abb. 1). Als Output entsteht in dieser Phase die dokumentierte Software-Architektur. Dazu zählen die Software-Komponenten und die Anforderungen daran.

Die Abbildung 1 erinnert an ein V-Modell. Sie ist aber eher als Dokumentationsmodell für die Software-Entwicklung zu verstehen und nicht als Prozessmodell.

b) Software als Teil eines Produkts (Software in a Medical Device)

Auch bei Software, die Teil eines Produkts ist, dienen die Software-Anforderungen als Input für die Software-Architektur. Sie entsprechen aber nicht den System- bzw. Produktanforderungen (s. Abb. 2 und Tipp 1).

Der Output ist auch hier die dokumentierte Software-Architektur, einschließlich der Anforderungen an die Komponenten.

c) Zusammenspiel mit dem Risikomanagement

Bei Medizinprodukten müssen die Software-Architektur und das Software-Risikomanagement Hand in Hand arbeiten. Das betrifft insbesondere die Risikoanalyse bei Software, beispielsweise mithilfe einer Software-FMEA oder des Threat Modelings.

In dieser Phase sollten auch risikominimierende Maßnahmen wie die Segregation von Komponenten festgelegt werden.

d) Abgrenzung (Baucharchitektur)

Bauarchitekten erstellen im Gegensatz zu Software-Architekten nicht nur den Bauplan. Sie ermitteln (gemeinsam mit dem Bauherrn) auch die Stakeholder-Anforderungen.

Die Software-Architekten sollten nur den Bauplan (die Software-Architektur) erstellen. Die Anforderungen zu erheben, ist Aufgabe des Requirements-Engineering.

Regulatorische Anforderungen

Europa

MDR, IVDR

Die MDR und IVDR verlangen Software-Lebenszyklus-Prozesse nach Stand der Technik (s. MDR, Anhang I, Abschnitt 17.2) und die „Beschreibung des Software-Designs“ (s. Anhang II, Abschnitt 6.1.b).

IEC 62304

Die für diese EU-Verordnungen harmonisierte Norm IEC 62304 schreibt in den Kapitel 5.3 und 5.4 eine Software-Architektur und ein detailliertes Software-Design vor. Dazu müssen die Hersteller die Software-Komponenten und Software-Einheiten identifizieren und die entsprechenden Schnittstellen spezifizieren.

Falls die Hersteller Off-the-shelf-Software (SOUP) verwenden, müssen sie auch dafür die Anforderungen spezifizieren und die Voraussetzungen für deren Einsatz dokumentieren und gewährleisten.

Die Norm verpflichtet die Hersteller dazu, die Software-Architektur zu verifizieren, ob beispielsweise alle Anforderungen berücksichtigt und Maßnahmen zur Risikobeherrschung umgesetzt sind.

USA

Die FDA erkennt die IEC 62304 als „recognized standard“ an. Aber die relevantesten Vorgaben an die Software-Architektur formuliert die Behörde in ihrer Leitlinie General Principles of Software Validation.

Zudem gibt die Leitlinie Content of the premarket submission  vor, welche Unterlagen Hersteller einreichen müssen. Darin macht die FDA auch Vorgaben für die „Software Architecture“ und das „Software Detailed Design“.

Praxistipps

Tipp 1: Das Software-System nicht als die Gesamtheit der Software festlegen

Medizinisch-elektrische Geräte können mehr als eine CPU und damit mehr als eine „Software“ enthalten (s. Abb. 3). Hersteller sollten nicht die Gesamtheit aller Software als das Software-System definieren. Vielmehr sollte die Software für jede Prozessoreinheit (kann mehrere Kerne enthalten) als eigenes Software-System zählen.

Damit vermeiden Hersteller Schichtenarchitekturen und  Produkte, die gedanklich nach Gewerken in die Schichten Mechanik, Elektronik und Software unterteilt sind. Sie sollten Produkte nach funktionalen Überlegungen unterteilen.

Tipp 2: Den richtigen Zeitpunkt wählen

Es ist weder sinnvoll noch gesetzeskonform, die Software-Architektur erst nach der Software-Entwicklung zu spezifizieren und dokumentieren.

Bei der agilen Software-Entwicklung ist ein kontinuierliches Refactoring möglich und üblich. Die Erfahrung zeigt jedoch, dass die meisten Hersteller mit einer präzisen und tragfähigen Upfront-Architektur sehr gefordert sind. Die konzeptionelle Integrität einer Architektur in einer agilen Entwicklung zu bewahren, klappt nur in wenigen Fällen.

Daher ist es hilfreich, die wesentlichen Design-Entscheidungen früh und auf Basis stabiler Anforderungen zu treffen.

Tipp 3: Definierte Notation verwenden

Manche Entwickler dokumentieren die Software-Architektur mithilfe von Kästchen und Pfeilen in PowerPoint. Bei so einem Pfeil muss allerdings klar sein, was dieser bezeichnet. Eine

• Abhängigkeitsbeziehung?
• Assoziation? Komposition oder Aggregation?
• Vererbungsbeziehung?
• Datenflussrichtung?
• Richtung der Methodenaufrufe?
• Implementierung?

Ein Modell ist nur dann aussagekräftig, wenn die Notationselemente (Formen, Farben etc.) definiert sind. Erfinden Sie daher keine eigene Notationssprache, sondern nutzen Sie standardisierte Sprachen wie UML.

Tipp 4: Integrationsstrategie frühzeitig festlegen

Eine wesentliche Eigenschaft guter Software-Architekturen sind Komponenten, die sich im Software-System durch „weak coupling and strong cohesion“ auszeichnen. Diese schwache Kopplung ist die Voraussetzung, um die Software später stückweise aus den Komponenten zusammensetzen und integrieren zu können.

Hersteller sollten sehr frühzeitig die Integrationsstrategie bestimmen, weil sie damit von Beginn an gezwungen sind, über die Stärke der Kopplung nachzudenken. Die Integrationsstrategie hat auch Einfluss auf die Integrationstests.

Tipp 5: Verifizierung mit Checklisten

Die Architektur muss verifiziert werden, bevor entwickelt wird. Eine Änderung an der Software-Architektur bedarf einer erneuten Verifizierung (zumindest der Änderungen).

Mit Checklisten, wie sie im Auditgarant zu finden sind, lassen sich Konformität und Vollständigkeit der Software-Architektur nachvollziehbar prüfen. Damit vermeiden Hersteller, Aspekte zu vergessen.