Die Systemarchitektur beschreibt, wie ein (Medizin)produkt aus Komponenten zusammengesetzt ist und wie die Komponenten über deren Schnittstellen miteinander in Beziehung stehen. Bei standalone Software fallen Systemarchitektur und Softwarearchitektur zusammen.
Dokumentation der Systemarchitektur
Die Dokumentation sollte die einzelnen Komponenten und deren Zusammenspiel erkennen lassen. Wir empfehlen, Standardnotationen wie UML bzw. SysML zu nutzen und nicht in PowerPoint mit undefinierten Notationselementen zu arbeiten.
Neben den Diagrammen mit den verschiedenen Sichten gilt es die Schnittstellen der einzelnen Komponenten zu spezifizieren. Hier finden Sie Hinweise, wie Sie Interoperabilitätsanforderungen vollständig beschreiben können.
Regulatorische Anforderungen an die Systemarchitektur
Es gibt einige regulatorischen Anforderungen an die Dokumentation von Systemarchitekturen. Zum einen fordert die Medizinprodukterichtlinie MDD, dass Hersteller Konstruktionszeichnungen […] sowie Pläne von Bauteilen, Baugruppen, Schaltungen in der Produktakte dokumentieren müssen. Ohne eine explizit dokumentierte Systemarchitektur wäre diese gesetzliche Anforderung nicht erfüllt.
Auch die IEC 60601-1 fordert, dass die Medizinproduktehersteller die programmierbaren elektronischen Subsysteme PESS identifizieren, Anforderungen daran formulieren und deren Erfüllung verifizieren. Ohne eine dokumentierte Systemarchitektur ist die Forderung nicht erfüllbar.
Eine dokumentierte Systemarchitektur ist zudem eine notwendige Voraussetzung für eine Risikoanalyse genauer für eine FMEA. Eine geeignete Systemarchitektur dient gleichzeitig der Risikobeherrschung. Im Auditgarant finden Sie Videotrainings zu sicherheitskritischen Systemarchitekturen.
Dokumentation: Systemarchitektur und Komponenten-Spezifikation
Bedarf es zweier Dokumente, einer Systemarchitektur und eine Komponenten-Spezifikation? Sollten diese beiden Dokumente zeitnah geschrieben werden? Von der gleichen Person?
Ob man die Systemarchitektur und Komponenten-Spezifikationen (Plural) in ein oder mehrere Dokumente packen soll, lässt sich nicht pauschal beantworten. Das hängt z.B. davon ab
- wie viele Komponenten es gibt
- wie umfangreich das Dokument werden würde
- ob die Komponenten von einem oder mehreren unabhängigen Teams entwickelt werden soll
- ob die Komponentenentwicklung outgesourced wird oder nicht
- usw.
Die Komponenten-Spezifikationen sollten sehr zeitnah und immer unter Mitwirkung des System-Architekten erfolgen. Schließlich zerlegt er das zu entwickelnde System nicht nur in Komponenten, sondern er beschreibt auch, wie diese Komponenten zu interagieren haben. D.h. er beschreibt wie sich die Komponenten über ihre Schnittstellen im Sinne einer Blackbox verhalten. Und genau das ist eine Komponenten-Spezifikation.
Diese Überlegungen gelten übrigens unabhängig davon, ob man ein Medizingerät oder eine stand-alone Software entwickelt, sie sind für PEMS genauso anwendbar wie für Software-Systeme. Im einen Fall bewegen wir uns eher im Dunstkreis der IEC 60601, im anderen Fall dem der IEC 62304.
Zerlegung von Systemen in Komponenten
Gefahr beim Zerlegen von Systemen in Schichten
Bei der Zerlegung von von Systemen in Komponenten, neigen manche Hersteller dazu, diese in die „Gewerke“ zu zerlegen, beispielweise in Mechanik, Elektromechanik, Elektronik und Software (linke Seite in folgender Abbildung).
Davon möchten wir abraten, weil diese schichtenartige Systemarchitektur zum einen (hoffentlich) nicht der Realität entspricht und zum anderen dazu führt, dass man nicht konsequent in Komponenten denkt.
Nur eine komponentenorientierte Systemarchitektur ist eine wartbare, testbare, wiederverwendbare Architektur.
Systemarchitektur und Softwarearchitektur
Insbesondere kann und sollte es nicht sein, dass Software-Komponenten auf der ersten Ebene der Systemarchitektur modelliert sind. Ob das bei Ihnen der Fall ist hängt auch davon ab, was Sie als Softwarearchitektur definieren.
Variante 1: Ein Software-System ist Teil eines PESS
Wenn Sie ein Software-System als die Gesamtheit aller Software definieren, das in einem Speicher/Prozessor (und damit in einem) PESS läuft, sollten in der Systemarchitektur überhaupt keine Software zu sehen sein. Es sei denn zum System zählt eine standalone Software. Andernfalls würde man in der Systemarchitektur nur die Komponenten erkennen, von denen eine Untermenge PESS sind. Und in jeder PESS gibt es Software (also ein Software-System), für das es wieder Softwareanforderungen und eine Softwarearchitektur gibt und damit Softwarekomponenten identifiziert werden. Aber letztere sieht man nicht in der Systemarchitektur.
Variante 2: Software-System ist die Gesamtheit aller Software
Wenn man hingegen unter einem Softwaresystem die Gesamtheit aller Software im Medizinprodukt versteht (diese Definition empfehle ich nicht), dann hätte man eine „Lasagne-Unterteilung“. Dann hätte man gar keine richtige Systemarchitektur, sondern eine Software-Architektur, eine Elektronik-Architektur und eine „Mechanik-Architektur“.
Die Norm gibt Ihnen keine Vorgabe, für welche Variante Sie sich entscheiden müssen.
Unterstützung beim Erstellen und Prüfen von Systemarchitekturen
Das Team des Johner Instituts ist darauf spezialisiert, mit und für Medizinproduktehersteller Systemarchitekturen zu erstellen und zu prüfen und so
- Risiken durch das Medizinprodukt zu identifizieren und zu beherrschen,
- Schwierigkeiten im Audit und bei der Zulassung zu vermeiden,
- Systemarchitekturen schlank, präzise, aussagekräftig und normenkonform zu dokumentieren sowie
- Fehler frühzeitig zu finden und zu beheben und so teure Nachbesserungen und Projektverzug zu vermeiden.
Nehmen Sie Kontakt mit den Experten des Johner Instituts auf.
