System Architektur – aber wie?

Der Begriff Architektur stammt aus dem lateinischen „architectura“ und bedeutet Baukunst. Beim Bau von Gebäuden war es schon immer gängige Praxis eine Architektur zu entwerfen. Daher hat auch jeder schon von einem Architekten gehört. Die Wenigsten denken dabei aber an einen Elektroingenieur, Mechatroniker oder Software-Ingenieur. Doch gerade bei komplexen Systemen ist es unvermeidlich eine Systemarchitektur, also einen Bauplan, zu erstellen, bevor man anfängt. Tut man es nicht, ergibt sich meist ein viel zu komplexes, fehleranfälliges System. Der Preis, den man für den Verzicht auf eine Systemarchitektur bezahlt, kann sehr hoch sein.

Der Systemarchitekt hat die Aufgabe, die Anforderungen an ein System oder Produkt zu verstehen und daraus ein System zu entwerfen, das diese Anforderungen effizient, kostengünstig und sicher lösen kann. Dafür besitzt er Werkzeuge und Methoden, die er sicher beherrschen muss.

Die Systemarchitektur ist ein/eine …

• Werkzeug zum Entwurf eines Systems
• Visualisierung des Systems
• Basis für ein Review
• Leitfaden für die Entwicklung
• Ablage von Informationen über das System
• Dokumentation des Systems (Archivierung von Wissen)
• Basis für Projektplanung und Aufwandsabschätzung
• Input für die Risikoanalyse

Systemkontext

Um ein System richtig zu verstehen, ist es notwendig zu wissen in welchem Umfeld das System eingebunden ist. Ein System steht nie alleine da. Daher ist es sinnvoll in der Systemarchitektur zuerst den Systemkontext zu beschreiben.

Zum Systemkontext gehören die Personen, die mit dem Gerät interagieren. Das kann der Anwender, der Patient, der Betreiber, ein Service-Techniker oder der Entwickler sein. Überlegen Sie sich, wer oder was mit dem System in Kontakt tritt und wie die Use-Cases aussehen. Idealerweise ist das bereits im Lastenheft oder Pflichtenheft definiert. Zeichnen Sie diese Personen oder Systeme in den Systemkontext ein. Stellen Sie auch die Anwendungsteile dar. Das sind die Schnittstellen zum Patienten. Zeichnen Sie die Systemgrenze ein und machen Sie ersichtlich, für welchen Bereich Sie die Zuständigkeit übernehmen. Benennen Sie die Schnittstellen, die das System hat und die sich an den Systemgrenzen ergeben. Das kann z.B. eine Benutzerschnittstelle oder eine Funkschnittstelle zur Datenübertragung sein.

• Welche Personen haben Kontakt mit dem System?
• Welche Anwendungsteile gibt es?
• Wo ist die Systemgrenze?
• Mit welchen Systemen kooperiert mein System und wie?
• Welche Schnittstellen hat das System?
• Welche Use-Cases gibt es und deckt mein System diese ab?

Beispiel eines Systemkontextes

Seien Sie genau in der Sprache und bei den Begriffen. Erstellen Sie ein Glossar, welches die Begriffe wiedergibt, die Sie für das System benötigen. Sprechen Sie sich frühzeitig mit dem Kunden und den Projektbeteiligten über die Begriffe ab. Damit vermeiden Sie Missverständnisse und alle haben die Chance eine Komponente richtig zu nennen.

Blockschaltbild

Das Blockschaltbild ist das, was die meisten als Systemarchitektur bezeichnen. Es ist mit Sicherheit eines der wichtigsten Teile der Systemarchitektur. Eine Systemarchitektur ohne Blockschaltbild ist wie ein Auto ohne Motor.

Das Blockschaltbild sollte alles enthalten, was innerhalb der Systemgrenze liegt. Die Schnittstellen des Systems sollen darin definiert werden. Anschließend werden die Komponenten des Systems aufgegliedert und die Schnittstellen zwischen den Komponenten beschrieben.

Was soll man im Blockschaltbild sehen:

• Systemgrenze
• Schnittstellen des Systems
• Komponenten des Systems
• Schnittstellen zwischen den Komponenten

Wichtig ist, dass das Blockschaltbild gut strukturiert und übersichtlich wiedergibt wie das System aufgebaut ist. Es ist nicht notwendig zu tief ins Detail zu gehen. Die Detaillierung erfolgt im Rahmen der Hardware, Software und Mechanik Design-Spezifikationen. Die zentralen Komponenten, die das System ausmachen, sollten jedoch beschrieben sein.

Prüfen Sie, ob alle Schnittstellen aus dem Systemkontext abgebildet sind. Haben Sie alle Komponenten und deren Schnittstellen richtig und umfänglich beschrieben? Spielen Sie dazu im Kopf durch was man mit dem Gerät machen kann (z.B. Einschalten, Ausschalten, Vitalparameter aufnehmen und am Display darstellen, Akku laden, etc.). Überlegen Sie sich, wie sich die Komponenten verhalten und was an den Schnittstellen übertragen wird. Diese „Simulation“ dauert nicht mal eine Stunde und hilft Ihnen das System zu verstehen und Fehler zu finden. Gehen Sie dabei alle Use-Cases durch.

Beispiel für ein Blockdiagramm

Systemverhalten

Das Systemverhalten ist mindestens so wichtig wie das Blockschaltbild. Dennoch wird es oft vergessen oder nicht erstellt. Ein System soll sich dynamisch verhalten und nicht nur aus statischen Elementen bestehen. Daher ist das Systemverhalten zu beschreiben.

• Zustandsautomaten
• Signalflüsse oder Wirkketten im System
• Fehlerhandling
• Reaktionszeiten

Zustandsautomat

Der Zustandsautomat beschreibt, wie sich das Gerät nach außen hin verhält. Im einfachsten Fall ist es an oder aus. Doch meistens ist es komplexer. Hier sind Zustandsdiagramme das perfekte Mittel das Verhalten darzustellen. Am Ende des Tages sollten Sie in der Lage sein, anhand der Zustandsdiagramme das Geräteverhalten erklären zu können. Können Sie es nicht, so haben Sie es selbst noch nicht verstanden. Dann empfiehlt es sich noch mehr Zeit zu investieren.

Beispiel für einen Zustandsautomaten

Signalflüssen oder Wirkketten

Bei Signalflüssen oder Wirkketten geht es darum, Signale durch das System zu verfolgen und zu modellieren. Ein Signal verläuft von einer Quelle zu einer Senke. Dabei wird es verstärkt, gefiltert oder verarbeitet. Es ist sinnvoll die Signalflüsse zu modellieren, um zu verstehen, welchen Weg die Signale nehmen und wo sie letztendlich enden. In der Abbildung unten ist eine Wirkkette von einem Sensor über eine Signalkonditionierung und einen ADC zu einem Mikrocontroller (Sensor) dargestellt. Dieser überträgt Daten zu einem weiteren Mikrocontroller und dieser steuert den Aktor an. Auf diese Weise können Sie wichtige Signalflüsse oder Wirkketten beschreiben.

Beispiel einer Wirkkette

Stellen Sie Ansteuerungen graphisch als Timing-Diagramm dar. Timing-Diagramme sind eine sehr gute Möglichkeit darzustellen, wie die Signalabhängigkeiten sind und erleichtern die Implementierung sehr stark. Sie können Timing Diagramme auch mit Excel entwerfen, falls Sie dafür kein spezielles Tool haben.

Beispiel eines Timing Diagramms erstellt mit Excel

Fehlerhandling

Setzen Sie sich bei der Erstellung der Architektur mit dem Fehlermanagement auseinander. Überlegen Sie sich, welche Fehler auftreten können und wie Sie auf den Fehler reagieren möchten. Soll das Gerät weiter benutzbar sein, oder geht das Gerät in einen sicheren Fehlerzustand? Bilden Sie Kategorien von Fehlern und legen Sie fest, wie auf die Fehler reagiert werden soll. Modellieren Sie das Fehlerhandling in Ihre Zustandsautomaten mit ein.

• Welche Fehler gibt es?
• In welche Kategorien kann ich die Fehler gruppieren?
• Wie reagiert das Gerät auf einen Fehler oder eine Fehlergruppe?
• Wie wird der Fehler am Gerät angezeigt?
• Welche Daten werden gespeichert, um den Fehler nachvollziehen zu können?
• Wie verhält sich das System im Fehlerfall?

Reaktionszeiten

Die Reaktionszeiten haben einen großen Einfluss auf die Systemarchitektur und müssen daher betrachtet werden. Falls das System zum Beispiel in Echtzeit auf ein Signal reagieren soll, macht es keinen Sinn das Signal durch ein nicht echtzeitfähiges Betriebssystem zu schleusen. Erstellen Sie eine Tabelle in der Sie die Reaktionszeiten auf ein Ereignis dokumentieren. Gehen Sie von einem Initialzustand aus und werten Sie ein Ereignis aus. Legen Sie eine Reaktionszeit fest, bis das System einen Zielzustand einnimmt.

Beispiel:

Alarmkonzept

Oft kann ein Medizinprodukt auch alarmieren. Die Alarme können optisch, akustisch oder verteilt ausgegeben werden. Bei den Alarmen unterscheidet man zwischen technischen Alarmen und physiologischen Alarmen. Bei technischen Alarmen ist etwas am Gerät nicht in Ordnung. Bei physiologischen Alarmen stimmt etwas mit dem Patienten nicht. Die Alarme werden in der Norm 60601-1-8 behandelt. Bei der Systemarchitektur können Sie definieren, wie Sie die Alarmausgabe realisieren wollen und ob Sie redundante Ausgaben benötigen.

Design und mechanischer Aufbau

Bilder sagen mehr als 1000 Worte. Das Sprichwort trifft auch hier zu. Oft gibt es einen Designentwurf, wie das Gerät aussehen soll (oder ein Vorgängergerät). Man versteht ein System viel einfacher wenn man es sieht. Wenn Sie Designentwürfe haben, fügen Sie diese in die Systemarchitektur ein. Dabei ist es nicht erforderlich, dass diese Bilder eins zu eins dem fertigen Gerät entsprechen. Die Systemarchitektur hat nicht den Charakter einer Zeichnung oder einer Designvorgabe. Es soll wiedergeben, wie das System aufgebaut ist und wie es prinzipiell aussieht.

Integrieren Sie hier die Informationen, wie es „unter der Haube“ aussieht. Es ist wichtig sich bewusst zu machen, dass die Systemarchitektur ein lebendes Dokument ist und dass Sie es aktualisieren, wenn sich Komponenten oder der Aufbau des Gerätes ändern.

Falls Ihr Gerät über eine komplexe Verkabelung oder Verschlauchung verfügt, ist hier der richtige Ort dieses darzustellen.

Stromversorgung

Die meisten Systeme benötigen Strom. Es ist nicht sinnvoll, das Blockschaltbild damit zu überfrachten, dass fast jede Komponente im Gerät Strom benötigt. Daher bietet es sich an, hierzu ein eigenes Kapitel anzulegen.

Im Abschnitt zur Stromversorgung sollen alle Quellen festgelegt sein (z.B. Netzanschluss, Netzteil-Anschluss, interne Akkus oder Batterien, Goldcaps. Vergessen Sie die RTC Batterie nicht, falls Sie eine haben). Die Priorität der Quellen ist festzulegen (Akku wird nur genutzt, wenn Netzteil nicht angeschlossen oder Funktion xyz aktiviert wird). Definieren Sie auch, wann der Akku geladen wird (z.B. immer wenn das Gerät am Netz hängt und der Akku < 90% geladen ist).

Anschließend beschreiben Sie die Hauptverbraucher (Komponenten) und welche Komponente für das Schalten der Stromnetze notwendig ist. Dabei ist es nicht notwendig, auf Leiterplatten-Ebene Bauteile zu erwähnen. Wichtig ist festzulegen, wie die Stromversorgung im System funktioniert und welche Komponenten beteiligt sind. Es soll auch definiert werden, was passiert wenn eine der Quellen ausfällt (Netzausfall, Batterieausfall).

Beschreiben Sie, wieviel Leistung das Gerät verbraucht und welche Stromspitzen Sie erwarten. Stellen Sie hier die Überlegungen zur Laufzeit des Gerätes an, wenn es von Akku oder Batterie versorgt wird. Stellen Sie klar, wie sich das Gerät im ausgeschalteten Zustand verhält. Ist es wirklich stromlos oder läuft irgendwo ein Mikrocontroller in einem Energiesparmodus?

Sie können dieses Dokument auch auslagern und darauf verweisen.

Beschreibung der Software Systeme

Ein Gerät beinhaltet meistens Software. Diese ist auf einem oder mehreren Controllern enthalten. Es ist sinnvoll aufzuzeigen, welche Controller es gibt und welche Aufgaben sie übernehmen. Dies muss an dieser Stelle nicht mit Anforderungen geschehen, sondern es reicht eine Prosa-Beschreibung aus. Weiterhin kann hier die Sicherheitsklassifizierung nach IEC62304 erfolgen. Die Sicherheitsklasse der einzelnen Software Systeme wird definiert. Dabei ist es sinnvoll die Software-Aufgaben so aufzuteilen, dass die Sicherheitsklasse bei Mikrocontrollern mit sehr viel Code möglichst gering ist (meistens GUI mit Betriebssystem). Die Festlegung der Sicherheitsklassifzierung erfolgt durch das Risikomanagement.

Bei der Beschreibung der Software-Systeme soll auch festgelegt werden, welche Software bereits existiert oder zugekauft wird (SOUP/OTS-Software). Auf Systemebene geht es nicht um Bibliotheken der Software, sondern um Software, die vollständig übernommen wird (z.B. die Firmware in einem Akku, die nicht selbst entwickelt wird). Die vollständige Liste der SOUP und OTS-Software muss vom Software-Verantwortlichen an anderer Stelle erstellt werden.

Zudem sollten an dieser Stelle die Schnittstellen benannt und die Protokolle zwischen den Mikrocontrollern referenziert werden. Es sollen die Hardware-Schnittstellen definiert (UART, SPI, CAN, USB, GPIO,…) sowie die Übertragungsraten und schnittstellenspezifischen Parametern (Handshake, 8n1, Master-Slave, …) festgelegt werden. Die Protokolle definieren, welche Informationen in welchem Format übertragen werden. Achten Sie darauf, dass alle Protokolle vorliegen.

Bedienkonzept

Das Bedienkonzept beschreibt im Detail die Benutzerschnittstelle des Gerätes. Gerade bei Projekten mit viel Software-Anteil gibt ein Bedienkonzept sehr gut wieder, wie das Produkt aussehen soll. Das Bedienkonzept wird in enger Zusammenarbeit mit dem Produktmanager erstellt. Das Bedienkonzept sollte in einem separaten Dokument gepflegt werden. Hier sind PowerPoint, Inkscape oder andere Zeichenprogramme eine gute Wahl. In der Systemarchitektur sollten Sie die wichtigen Elemente aus dem Bedienkonzept übernehmen. Welche Bedienelemente gibt es? Welche Anzeigen gibt es? Wie ist die Bedienung grundsätzlich realisiert? Sie können in der Systemarchitektur auf das Bedienkonzept referenzieren.

Worauf ist beim Systementwurf zu achten?

Bauen Sie Ihre Systeme möglichst einfach auf (KISS = keep it stupid simple). Reduzieren Sie Komplexität so weit wie möglich. Dazu ist es erforderlich immer wieder zu hinterfragen, ob eine Komponente wirklich benötigt wird. Bildlich gesprochen müssen Sie von Ihrem Zeichenbrett drei Schritte zurück treten und sich fragen: „Kann ich noch etwas vereinfachen?“ Und wenn die Frage mit „ja“ beantwortet werden kann, dann tun Sie es solange bis ein „nein“ kommt. Der Aufwand lohnt sich, denn Komplexität im System führt zu ausufernden Tests und nicht beherrschbaren Systemen. Vereinfachen können Sie das System auch, wenn Sie es besser strukturieren. Teilen Sie den Systemkomponenten Aufgaben zu und minimieren Sie die Anzahl der Schnittstellen.

Gerade in der Medizintechnik muss man sich auf die Geräte verlassen können. Es ist keinem geholfen, wenn das Gerät beim kleinsten Anzeichen einer Störung die Segel streicht und den Patienten im Stich lässt. Bauen Sie deshalb Ihre Systeme fehlertolerant auf. Überlegen Sie sich, wann die wesentlichen Leistungsmerkmale nicht mehr erfüllt werden und das einen Geräteausfall zur Folge hat. Überlegen Sie sich welche Teile ausfallen dürfen und wie die anderen Komponenten darauf reagieren sollen.

Grenzen Sie Ihr System strikt ab (was ist meins und was nicht?). Definieren Sie die Schnittstellen an der Systemgrenze vollständig. Über diese Schnittstellen können Informationen, Energie oder Stoffe ausgetauscht werden. Informationen kommen z.B. von einer EKG-Elektrode als Spannung oder über eine USB-Schnittstelle von einem anderen Gerät. Energie kommt aus der Steckdose oder von einem Netzteil. Stoffe könnten Blut, Wasser oder andere Stoffe sein. Vergessen Sie nicht die mechanischen Schnittstellen. So kann ein Gerät eine Wandhalterung oder eine Schutztasche haben. Seien Sie bei der Beschreibung dieser Schnittstellen akkurat.

Achten Sie auf eine vollständige Beschreibung des Systems. Das ist manchmal gar nicht so einfach, da man selbst viele Informationen im Kopf hat. Die Information gehört aber auch zusätzlich in die Systemarchitektur. Hinterfragen Sie daher, ob das System umfassend beschrieben ist ohne in Ihrem Gedächtnis nach Informationen zu suchen. Die Prüfung eines Systems auf Vollständigkeit geht am einfachsten, wenn sich der Reviewer die Systemarchitektur durchlesen und anschließend dem Autor erklären kann, wie das System funktioniert. Falls dem Reviewer das System nicht klar geworden ist und er noch Fragen hat oder es nicht erklären kann, dann fehlt Information.

Beschreiben Sie das System vollständig, aber gehen Sie dabei nicht zu tief ins Detail. Es ist unerheblich, welchen Spannungsregler der Hardware-Entwickler einsetzen will und wie die Software aussehen soll. Das gehört in den Fachbereich der jeweiligen Experten. Sie sind dafür zuständig das System zu beschreiben und Sie sollten den Lösungsraum der Fachexperten aus den Bereichen Hardware, Software und Mechanik nicht unnötig einschränken. Es ist sinnvoll, dass Sie die Ergebnisse der Fachexperten daraufhin prüfen, ob deren Lösungen in Ihr System passen.

Beim Entwurf von Systemen sollten Sie auch die Herstellkosten im Blick behalten. Es bringt nichts wenn Sie ein tolles System designen, aber am Ende kauft es keiner, weil es viel zu teuer ist. Die Herstellkosten sind ein wichtiger Aspekt, der die Architektur entscheidend beeinflussen kann.

Achten Sie auch darauf, dass das System fertigbar ist. Das klingt banal, wird aber oft nicht gemacht. Sprechen Sie Ihre Systemarchitektur frühzeitig mit der Fertigung ab. Hier können erste Modelle (SLS-Prototypen) helfen.

Überlegen Sie sich, wie das System einfach getestet werden kann. Es bietet sich an Schnittstellen vorzusehen, die Sie für Testzwecke benötigen. Ideal ist es, wenn die Tests automatisiert durchgeführt werden können. Denken Sie auch an Tests, die Ihnen bei der Entwicklung helfen können (z.B. eine EMV-Test Schnittstelle).

Erstellen Sie frühzeitig ein Sicherheitskonzept. In diesem Dokument dokumentieren Sie, wie das System aufgebaut ist und welche Sicherheitsmaßnahmen Sie festgelegt haben. Der Fokus liegt hier auf der Sicherheit. So haben Sie eventuell zweikanalige Ansteuerungen von sicherheitsrelevanten Baugruppen. Oder Sie verwenden redundante Hardware zur Überwachung von Parametern. Eventuell gibt es auch mechanische Schutzmaßnahmen (Überdruckventil, Verpolungssicherheit). Hier beschreiben Sie auch die Selbsttests und Geräteüberwachungen während der Laufzeit und andere Überlegungen, die der Gerätesicherheit dienen. Dieses Dokument ist sehr nützlich, um bereits früh in der Entwicklung mit der Zulassungsstelle über das Design zu sprechen.

Sie müssen nicht bei jedem Projekt das Rad neu erfinden. Schauen Sie nach Komponenten, die Sie wiederverwenden können. Das spart Aufwand in der Entwicklung und kann sich auch bei den Herstellkosten positiv auswirken. Versuchen Sie auch beim Aufbau Ihres Systems darauf zu achten, ob sich wiederverwendbare Module ergeben.

Achten Sie auf versteckte Abhängigkeiten in einem System. Diese sind nicht leicht zu erkennen (Beispiel 1: Lautstärke hängt vom Akkuzustand ab – Ein schwacher Akku wird durch akustische Alarmierung signalisiert; Beispiel 2: Das Laden des HV-Kondensators eines Defibrillators führt bei Netzbetrieb zu einer Störung im EKG, welche dazu führt, dass der Herzrhythmus nicht richtig klassifiziert wird). Gehen Sie das System strukturiert nach solchen versteckten Abhängigkeiten durch. Dazu können Sie die Liste der Einsatzszenarien erstellen, und für jedes Szenario bewerten auf welches andere Szenario in der Liste es sich auswirken kann. Sie erhalten so eine Matrix mit Abhängigkeiten. Fehler, die sich dadurch ergeben, sind sehr schwer zu finden und kommen erst sehr spät in der Entwicklung ans Tageslicht.

Überlegen Sie sich, ob das System den Kundennutzen erfüllt. Der Kundennutzen ist der Grund, warum ein Kunde das System kauft. Sind die Use-Cases mit der erstellten Architektur plausibel? Achten Sie darauf, ob die User das mit dem Gerät machen können wofür Sie es entwickeln. Wenn Ihnen der Kundennutzen noch nicht klar ist, dann macht es keinen Sinn, sich an die Architektur zu wagen. Dann empfehle ich Ihnen sich über den Kundennutzen Gedanken zu machen.

Führen Sie frühzeitig Reviews der Systemarchitektur durch. Lassen Sie Kollegen bereits während der Erstellung Teile der Architektur anschauen und verbessern Sie so Ihre Architektur frühzeitig. Es ist für einen Reviewer einfacher, sich ein paar Seiten durchzulesen als die komplette Architektur auf einmal.

Ich würde mich freuen, wenn für Sie der ein oder andere Denkanstoß dabei war. Systeme zu entwerfen macht Spaß! Es geht bei diesem Thema daher nicht um ein lästiges Dokument, sondern um ein Werkzeug, das hilft Systeme effizient und professionell entwickeln zu können. Ich freue mich über Feedback und wenn Sie mit mir in Kontakt treten. Sie können gerne auch einen Kommentar zu dem Artikel abgeben. Falls Sie jemanden kennen, für den der Blog ebenfalls interessant sein könnte, freue ich mich auch sehr über eine Weiterempfehlung.

Viele Grüße

Goran Madzar

Kontaktieren Sie uns!