Einleitung

Referenzen auf nichtexistierende Kapitel oder Dokumente, veraltete Abbildungen, inkonsistente Bezeichnungen!

Eine ungepflegte Systemarchitektur-Dokumentation wirft oft mehr Fragen auf, als sie zu beantworten im Stande ist. Dementsprechend sollte darauf geachtet werden, dass alle Informationen immer auf Stand gehalten werden.

Doch selbst mit den besten Vorsätzen, präzise definierten Arbeitsabläufen und streng eingehaltenen Entwicklungsprozessen, werden sich immer wieder einmal Fehler einschleichen. Dies hat zur Folge, dass man den Informationen doch nicht immer ganz vertraut und öfter auch in der Implementation nachsieht.

Im Folgenden wird das Problem des Informations-Managements im Systementwicklungsprozess beleuchtet. Dabei werden die Schwächen des «klassischen» dokumentenzentrierten Ansatzes angesprochen und alternative Ansätze aufgezeigt.

Wieso ist es so schwierig die, Informationen aktuell zu halten?

Eine Systemarchitektur hat eine hierarchische Struktur, welche üblicherweise in einem oder mehreren Dokumenten mittels Abbildungen und Text, beschrieben wird.

In Abbildung 1 ist ein Beispiel für die Struktur einer Systemarchitektur dargestellt. Die Pfeile stellen zum einen die hierarchische Abhängigkeit dar und zum anderen den Informationsfluss (Bezeichnungen etc.) im Zuge des Design-Prozesses.

Abbildung 1: Systemarchitektur Dokumente (mit Implementations-Artefakten) für ein System mit drei Teilsystemen.

Die Informationen sind also über mehrere Dokumente und Abbildungen verteilt und wenn eine Information an mehreren Stellen verwendet wird, handelt es sich immer um eine Duplikation. Man erstellt also jedes Mal eine Kopie der Information, wobei keinerlei Verbindung mehr zur Ursprungsinformation besteht.

Damit ist das Problem schon offensichtlich. Um eine Änderung korrekt durchzuführen, muss die Information an allen Stellen, wo diese verwendet wird, angepasst werden. Dies ist nicht nur sehr zeitaufwändig, sondern auch fehleranfällig, da völlig unbekannt ist, wo die entsprechende Information überall verwendet wird.

Das fortlaufende Kopieren und Weitergeben einer Information erinnert stark an das wohl allen bekannte Kinderspiel «Stille Post», wobei hier der Reiz gerade darin liegt, dass es unvermeidlich zu Fehlern kommt.

In Abbildung 2 dient dieses einfache Spiel, zum Aufzeigen dessen, was mit einer Parameterbezeichnung passieren könnte – in diesem Fall sogar, ohne einen inhaltlichen Fehler einzuführen. Für die Verständlichkeit einer Systemarchitektur ist dies jedoch auch sehr abträglich.

Abbildung 2: Problem von Informationsduplizierung, veranschaulicht anhand des Kinderspiels «Stille Post»

Wie kann das divergieren von Informationen verhindert werden?

Wenn wir uns das «Stille Post»-Beispiel ansehen, ist die Lösung wohl offensichtlich.

Abbildung 3: Der erste in der Reihe stellt sicher, dass alle die Information direkt von ihm erhalten. Die Information kann nicht divergieren, wenn sie immer aus einer einzigen Quelle stammt.

Und so einfach ist der ganze Spass des Spiels zunichtegemacht. Für alle anderen Fälle, in denen abweichende Informationen keinen Spass machen, bringt dies jedoch einen grossen Vorteil.

In der Softwareentwicklung gibt es ein Grundprinzip, welches genau darauf abzielt: «Don’t repeat yourself». Hauptziel ist, Redundanz zu vermeiden, um die Widerspruchsfreiheit zu erhöhen. Dieses Prinzip kann auch auf eine Systemarchitektur angewendet werden. Damit wäre es möglich, diese einfach und mit geringem Fehlerrisiko auf Stand zu halten, wovon nicht nur der Design-Prozess profitiert, sondern auch der Entwicklungs- und LifeCycle-Prozess.

Ein weiterer Weg, dies zu erreichen, ist die andauernde Synchronisation der Informationen. Dabei wird die Änderung einer Information automatisch an alle Instanzen, welche diese benutzen, propagiert. Dabei handelt es sich um einen dezentralen Ansatz, bei welchem eine Softwareentwicklungs-Analogie am ehesten einem Git-Repository, mit der Möglichkeit zum Zusammenführen (merge), mehrerer Informationsbestände entspricht.

Wie lässt sich dies umsetzen?

Single Point of Definition

Ebenfalls aus der Softwareentwicklung kommt ein Ansatz, den man entweder als pragmatisch oder radikal betrachten kann, «the Code is the design». Vielleicht ist dieser Ansatz auch ein Resultat des «Law of the Instrument» («Wer nur einen Hammer hat, sieht in jedem Problem einen Nagel»).

Und obwohl die Schlichtheit dieser Idee einen gewissen Reiz hat, bringt sie zu viele Limitierungen mit sich.

• Limitierung auf reine Software-Projekte.
• Die Verständlichkeit leidet enorm an einer Überfrachtung mit zu vielen unnötigen Details.
• Das rein textbasierte Medium erlaubt keinerlei grafische Elemente zur Erläuterung.

Ein etwas generellerer Ansatz ist die Verwendung eines zentralen Informationsmanagers, welcher Informationen zentral verwaltet und für die unterschiedlichen Einsatzgebiete zur Verfügung stellt. Diese Idee ist auch nicht neu und wird in der Softwareentwicklung zum Beispiel im «Model View Controller»-Konzept verwendet. In der Systementwicklung spricht man dabei oft von «Model based …» oder «Model driven …». Dabei versteht man unter «Model» den Ort, an dem die zentralen Daten abgelegt bzw. verwaltet werden.

In Abbildung 4 ist das weiter oben gezeigte Beispiel der Struktur einer Systemarchitektur dargestellt, wobei eine zentrale Informationsmanagement-Instanz hinzugefügt wurde.

Abbildung 4: Systemarchitektur für ein System mit drei Teilsystemen mit zentraler Informationshaltung.

Dieser Ansatz benötigt aber eine stärkere Unterstützung durch spezifische Softwarelösungen, da Informationen vom «System Model» bezogen werden müssen. Als Folge dessen sind die Architektur-Dokumente nicht mehr das direkte Ausgangsprodukt des Designprozesses, sondern müssen in einem gesonderten Schritt, aus dem «System Model», generiert werden.

Doch auch, wenn dies eine gewisse Umstellung in den gewohnten Arbeitsmitteln mit sich bringt, überwiegen die Vorteile einer solchen Lösung. Dies ist nicht zuletzt daran zu sehen, dass sich ähnliche Konzepte in anderen Gebieten bereits durchgesetzt haben. Als Beispiele seien hier die CAD-Software für die Mechanikentwicklung oder ECAD-Software für die Elektronikentwicklung erwähnt. In der IMT werden hierfür zum Beispiel «SOLIDWORKS 3D CAD» und «Altium Designer» eingesetzt.

Synchronisation

Eine geläufige Bezeichnung für diesen Ansatz ist «Roundtrip engineering», dabei sollen Informationen in unterschiedlichen Dokumenten, Software-Artefakten, etc. synchron gehalten werden.  Es beschreibt damit so etwas, wie das Idealbild einer Software Architektur oder gar einer ganzen Produktumsetzung. Unabhängig an welcher Stelle ich eine Information verändere wird diese automatisch an allen Stellen, wo sie verwendet wird, nachgeführt. Es verspricht sogar noch mehr, unabhängig davon, ob eine neue Komponente in der Architektur oder der Implementation hinzugefügt wird, erhält man denselben vollständigen Satz an Dokumenten, Software-Artefakten, etc. So schön dies auch wäre, beginnt hier diese Utopie etwas zu bröckeln.

Das grundlegende Problem ist, dass dies eine eineindeutige Beziehung zwischen allen hierarchischen Ebenen voraussetzt. Dies würde nicht nur zu sehr strikten Einschränkungen bei der Umsetzung führen, sondern ist in manchen Fällen zudem nicht erreichbar, da durch die Abstraktion auf höheren Ebenen gar nicht die gesamte Information vorhanden ist.

Doch betrachten wir das etwas pragmatisch, zeigt sich, dass dies für den Anwendungsfall der Systementwicklung auch gar nicht nötig ist. Vielmehr scheint es für mich viel verständlicher, wenn klar definiert ist, auf welcher Ebene welche Information definiert ist. Mit der Ausnahme dieser Einschränkung kann die zentrale Datenhaltung, welche zuvor vorgestellt wurde, dieselbe Funktionalität zur Verfügung stellen.

Kann die zentrale Information auch über die Systemarchitektur hinaus verwendet werden?

Natürlich wäre es konsequent, in möglichst allen Aspekten der Systementwicklung, diese zentralen Daten zu verwenden. Dies erfordert jedoch eine Integration aller dafür notwendigen Funktionen in eine Softwarelösung, oder zumindest eine definierte Schnittstelle, um die Informationen zu teilen. Da die unterschiedlichen Gebiete der Systementwicklung jedoch jeweils sehr spezifische Anforderungen haben und es dafür bereits sehr gute eigenständige Softwarelösungen gibt (z.B. «SOLIDWORKS 3D CAD» und «Altium Designer»), wäre es wohl mit einem enormen Aufwand verbunden, die Informationen auch direkt in den spezifischen CAD-Anwendungen zu verwenden.

Für den agilsten Teil der Systementwicklung, die Softwareentwicklung, ist es aber gut möglich, mit Hilfe von Code-Generierung, die Struktur und sogenannten «Boilerplate-Code», für die Implementation zu erzeugen. Damit können die Vorteile des zentralen Informationsmanagements bis in die Umsetzung hinein genutzt werden. Die IMT setzt hierfür auf das eigene, im Haus entwickelte Software-Tool «DATAFLOW Designer», welches neben dem Bereitstellen von Boilerplate-Code auch beim Nachweis der Normenkonformität unterstützt.

Zusammenfassung

Das Ziel ist eine aktuelle, widerspruchsfreie und verständliche System Architektur, welche jedem Entwickler die benötigten Informationen einfach und schnell zur Verfügung stellt. Um dies zu erreichen, sollte die Entwickler bei der Erstellung und Anpassung bestmöglich unterstützt werden. Ein fundamentaler Baustein dafür stellt das zentrale Informations-Management dar, mit dem es möglich ist, die Entwickler vom Design bis zur Umsetzung auf vielseitige Weise zu unterstützen. Die erzielbaren Effizienz- und Qualitätssteigerungen kommen dabei sowohl dem Kunden als auch dem Entwickler zugute.

Einleitung

Die (EN) ISO 13485 in Ihrer Ausgabe von 2016, genauso wie die FDA Guidances und die Europäische Medical Device Regulation (MDR) fordern, dass Software, welche im Qualitätsmanagement System der Medizingerätehersteller verwendet wird, zu validieren sei. Während die ISO 13485 und die EU MDR nicht weiter beschreiben, wie die Toolvalidierung auszusehen hat, hat die US FDA am 11. Januar 2002 eine Guidance veröffentlicht: “General Principles of Software Validation; Final Guidance for Industry and FDA Staff”. Auch die Arbeitsgruppen von ISO und IEC haben sich Gedanken zu diesem Thema gemacht und 2017 den ISO/TR 80002-2 veröffentlicht: «Validation of software for medical device quality systems».

Ziel dieses Artikels ist es, einen einfachen Weg aufzuzeigen, wie eine solche Tool-Validierung aufgebaut werden kann.

Software Liste

Beide, die ISO 13485 (in Kapitel 4.1.6) und die FDA Guidance (in Kapitel 4.8) fordern, dass die Validierung der Software dem Risiko der Software entspricht, unabhängig von der Firmengrösse oder der zur Verfügung stehenden Ressourcen. Dementsprechend benötig ein Qualitätsmanagementsystem eine Übersicht über die eingesetzten Softwareapplikationen sowie ihres Verwendungszwecks. Vorzugsweise wird in dieser Übersicht auch dokumentiert ob es sich um eine

• «Off the shelf» Software (also eine Software die als Massenprodukt im Handel erworben werden kann),
• eine angepasste Software
• oder sogar um eine explizit für den geplanten Einsatz entwickelte Software handelt.

Eine Standard-Software wie z.B. Word von Microsoft sind zu tausenden installiert, die Wahrscheinlichkeit, dass die Schwarmintelligenz dieser tausenden von Nutzern ein Fehler findet, ist wohl um einiges höher, als meine Tool Validierung. Diesem Umstand darf in der Toolvalidierung Rechnung getragen werden. Der Prozess für Standard Software, welche nur für nicht-kritische Zwecke verwendet wird, kann unter Umständen bereits hier abgeschlossen werden.

Abbildung 1: Software Liste

Software Validierungsplan

Der Software-Validierungsplan bzw. Toolvalidierung sollte folgende Elemente enthalten:

1. Beschreibung der Software inklusive vorgesehenen Gebrauch, vorgesehene Nutzer und deren Umgebung
2. Anforderungen an die Software
3. Testspezifikation für die Softwareanforderungen
4. Risikomanagement Plan für die zu validierende Software

Diese Elemente können entweder alle in einem Dokument mit verschiedenen Unterkapitel dokumentiert werden, oder aber in verschiedene Dokumente ausgelagert. Letzteres eignet sich vor allem bei umfangreicheren Anforderungsdokumenten.

Beschreibung der Software

Das Kapitel oder Dokument mit der Beschreibung der Software soll den vorgesehenen gebrauch, die vorgesehenen Nutzer und deren Umgebung beschreiben. Use Case Diagramme können hier von Vorteil sein um eine einfache, visuelle Übersicht zu geben:

Abbildung 2: Use Case Diagram – Benutzer Verwalten

Software Nutzer Anforderungen

Die Nutzer-Anforderungen sollten in einer testbaren Form erfasst und mit einer eindeutigen ID versehen werden. Wir bei IMT nutzen hier meist die folgende Syntax:

zum Beispiel könnte eine solche Anforderung heissen

oder

Beide Anforderungen haben eine eindeutige ID und können getestet werden. Anforderungen welche nicht getestet werden können sind zu vermeiden, so sollte «schnell» durch eine Zeitangabe wie «2 Sekunden» ersetzt werden, oder «hell» durch «unter einer Inspektionslampe mit 1500lx».

Testspezifikation für die Nutzer-Anforderungen

Jede Nutzer-Anforderung benötigt im Minimum einen Test. Zur Testspezifikation gehört neben einer eindeutigen ID, die Prüfanweisung sowie das Akzeptanzkriterium oder erwartete Resultat. So könnte ein Test für obiges UR-001 aussehen:

Risikomanagement Plan für diese Software

Da die Auswirkungen bei einem Fehler der Software im Qualitätsmanagementsystem anders sind, als bei einem Medizinprodukt, muss auch der Risikomanagementplan entsprechend angepasst sein. Insbesondere die Definitionen der Auswirkungskategorien benötigen eine differenzierte Betrachtung. Je nach Anwendungsbereich bekommen die selben Auswirkungskategorien eine völlig unterschiedliche Bedeutung. Die Auswirkungskategorie «kritisch» bedeutet bei einem Medizingerät möglicherweise den Tod eines Patienten, bei einer Software zur Rückverfolgung der Medizingeräte dagegen der Verlust von Daten.

Prüfen und Bewerten

Bevor der Validierungsbericht erstellt werden kann, muss die Software getestet und die Risiken müssen bewertet werden.

Testbericht

Die Software ist gemäss der Prüfspezifikation zu prüfen. Dabei ist zu jedem Prüfschritt nicht nur ein «Pass/Fail» zu protokollieren, sondern auch das tatsächlich beobachtete Verhalten, so dass die Prüfung nachgestellt werden kann. Daher muss auch die Software und ihre Umgebungsbedingungen protokolliert werden. Dazu gehören:

• Name und Hersteller der Software
• Version, Build Nummer
• Betriebssystem
• 32/64 Bit Umgebung
• Verwendete Peripherie
• ….

Aber auch Datum, Prüfer sowie eine Bewertung im 4-Augen-Prinzip gehört dazu:

Ein solcher Report für obiges Beispiel könnte wie folgt aussehen:

Risikoanalyse

In der Risikoanalyse sollten alle bekannten Probleme bewertet werden. Bei Software, welche mit dem Zweck des Einsatzes in regulierter Umgebung vertrieben wird, wird oft auch eine entsprechende Liste der bekannten Anomalien veröffentlicht. Hier lohnt es sich auf der Support-Webseite vom Hersteller nachzusehen oder den Support zu kontaktieren. Neben den Problemen die dem Hersteller bekannt sind, sind auch Unzulänglichkeiten wie fehlende Features zu bewerten. Ist ein Risiko nicht akzeptabel, müssen Kontrollmassnahmen definiert werden, um das Risiko zu reduzieren. Als Medizingerätehersteller, welche sich an Risikomanagement nach ISO 14971 gewöhnt sind, empfehlen wir, dabei dem gleichen Prozess zu folgen.

Software Validierungsbericht

Der Software Validierungsreport sollte folgende Elemente enthalten:

1. Identifikation der Software und Umgebung
2. Testbericht(e) oder Verweis(e) darauf
3. Risikomanagementbericht über die bekannten Anomalien der Software
4. Nachweis, dass alle Anforderungen geprüft wurden. Dies lässt sich am einfachsten über eine Traceability Matrix abbilden.
5. Formelle Bewertung und Freigabe der Software zur Nutzung

Hinweis: Für «kleinere» Applikationen, kann möglicherweise Testreport, Risikoanalyse und Validierungsbericht auch in einem Dokument erstellt werden.

Identifikation der Software und Umgebung, Testbericht

Oft gibt es für die Software eine Matrix der validierten Versionen und Umgebungen, dann sollte diese im Validierungsbericht entsprechend abgebildet werden:

Risikomanagementbericht über die bekannten Anomalien der Software

Der Validierungsbericht soll weiter das Restrisiko welche durch die Nutzung dieser Software entsteht bewerten. Insbesondere liegt hier der Fokus auf der Akzeptabilität der bekannten Anomalien und/oder fehlenden Funktionen.

Traceability

Ein weiterer Aspekt den es abzudecken gibt, ist nachzuweisen dass alle Anforderungen an die Software getestet wurden. Je nach Umfang der Anforderungen und der Dokumentation der Tests haben sich zwei Möglichkeiten herausgeschält dies zu dokumentieren:

Vorwärts-Verlinkung der Anforderungen zu den Tests

Die Anforderungstabelle wird um eine Spalte ergänzt, wo die Anforderung geprüft wird:

Diese Variante eignet sich vor allem bei kleinem Umfang an Anforderungen und wenn die gesamte Validierung in einem Dokument erstellt wird.

Traceability-Matrix

Bei umfangreichen Anforderungsdokumenten oder wenn die Testdurchführung ihre eigenen ID’s besitzt, empfiehlt es sich eine Traceability Matrix zu erstellen, welche die Anforderungen der Testspezifikation und eventuell dem Testbericht gegenüberstellt:

Sollen mehrere Berichte für verschiedene Laufzeitumgebungen und Softwareversionen abgebildet werden müssen, so kann dies in einer Traceability Matrix sehr einfach durch zusätzliche Spalten abgebildet werden.

Formelle Bewertung und Freigabe

Zu guter Letzt soll das Gesamtpaket der Dokumentation bewertet und mit einem Entscheid der Freigabe dokumentiert werden.

Zusammenfassung

Bildlich dargestellt, ist die Validierung der Software im Qualitätsmanagementsystem nichts anderes, als die Systematische, dokumentierte Durchführung der linken und rechten, oberen Ecken des in der Softwareentwicklung weit verbreiteten V-Modells:

Dazu gehören:

• Vorgesehener Nutzen sowie Anforderungen
• Risikomanagement
• Validierung der Nutzeranforderung
• Bewerten der Risiken
• Bewerten der Gesamtvalidieurng und Freigabe der Software für den vorgesehenen Nutzen.

Einleitung

Modellbasierte Systementwicklung bzw. modellbasierte Methoden gewinnen immer mehr an Popularität in der Entwicklung. Wieso ist das so? Und was ist das eigentlich genau?

Um einen Entwicklungsprozess effizient zu gestalten, führt kein Weg an modellbasierten Methoden vorbei. Damit unterschiedlichste Aspekte der Systementwicklung verbessert bzw. vereinfacht werden.

Es gibt eine sehr breite Palette an modellbasierten Methoden, welche für unterschiedlichste Einsatzzwecke gedacht sind und es hängt sehr stark vom Projekt ab, welche Methoden überhaupt einen Mehrwert bringen. Es gilt also, für jedes Projekt das richtige Set von modellbasierten Methoden zu wählen.

In diesem Artikel versuchen wir, das Begriffsdickicht um modellbasierte Methoden in der Systementwicklung etwas aufzuklären sowie die Einsatzmöglichkeiten aufzuzeigen.

Was ist ein Modell

«Ein Modell ist ein vereinfachtes Abbild der Wirklichkeit. Das Abbild kann die Form konkreter Gegenstände haben oder rein abstrakt dargestellt sein.» Wikipedia

Ein gutes Modell zeigt dabei alle relevanten Eigenschaften der Wirklichkeit bei bestmöglicher Vereinfachung.

Daraus folgt aber auch, dass ein Modell immer für einen spezifischen Einsatzzweck optimiert ist.

Abbildung 1: Drei Modelle eines Autos, je für einen anderen Einsatzzweck.

Wie im Beispiel von Abbildung 1 zu sehen ist, können Modelle für dasselbe reale Objekt sehr unterschiedliche Formen annehmen.

Dabei gibt es eine fast unbegrenzte Anzahl an möglichen Modellen, je komplexer ein Objekt umso mehr Möglichkeiten ergeben sich natürlich. Aber selbst für sehr kleine Dinge wie Atome oder Licht sind in der Physik unterschiedliche Modelle im Einsatz.

Eventuell ist dies ein Grund, warum der Begriff «Modell» bei «modellbasierten Methoden» so viele unterschiedliche Interpretationen zu lässt.

Der Kern ist dabei jedoch stets derselbe und entspricht im Wesentlichen genau der oben genannten Definition. Ein Modell ist eine vereinfachte Darstellung, welche alle relevanten Eigenschaften der Wirklichkeit abbildet. Ein so geartetes Modell reduziert die Komplexität und vereinfacht damit das Arbeiten in Bezug auf den spezifischen Einsatzzweck.

Damit ist es nur folgerichtig, dass es eine ganze Reihe von «modellbasierten Methoden» (model-based methods) für unterschiedliche Einsatzgebiete gibt. Im Folgenden wird versucht, die etwas verwirrenden Begrifflichkeiten, die sich dabei ergeben, ein wenig zu ordnen.

Wie lassen sich die verschiedenen Ansätze einteilen?

Nach allem, was wir nun über Modelle wissen, bietet sich der Einsatzzweck als zentrale Eigenschaft eines Modells als Parameter für eine Einteilung an.

Damit kann man auch gleich zu Beginn klarstellen, dass wir hier nur Ansätze für die Entwicklung technischer Systeme betrachten wollen. Damit können wir das Modellauto aus Abbildung 1 also getrost ausser Acht lassen.

Die beiden anderen Modelle zeigen uns jedoch zwei wichtige Einsatzzwecke auf. Diese Einsatzzwecke könnte man wie folgt unterteilen:

• Verhaltensbeschreibung
• Informationsaustausch

Auch wenn es teilweise Überschneidungen gibt, lassen sich die modellbasierten Methoden anhand ihrer Grundintention in diese zwei Gruppen einteilen.

Verhaltensbeschreibende modellbasierte Methoden

Geht man von einer Softwareapplikation aus, ist es naheliegend, dass ein verhaltensbeschreibendes Modell dazu verwendet werden kann, um daraus die Implementation dieser Applikation automatisiert zu erstellen.

Erweitert man diesen Ansatz nun noch um ein zweites verhaltensbeschreibendes Modell, welches die Umgebung, also das Verhalten aller Schnittstellen des ersten Modells abbildet, erhält man die Möglichkeit das Verhalten des Gesamtsystems zu simulieren.

Die gebräuchlichste Bezeichnung für solch einen Ansatz ist:

• Model-Based Design (MBD)

Damit ist es auch möglich, Simulationen bzw. Tests für unterschiedliche Entwicklungsstufen durchzuführen. Die möglichen Ansätze bezeichnet man dabei als:

• Model-in-the-Loop (MIL)
• Software-in-the-Loop (SIL)
• Processor-in-the-Loop (PIL)
• Hardware-in-the-Loop (HIL)

Eine Beschreibung dieser Ansätze ist im unten folgenden Glossar zu finden.

Da das Verhalten durch das Modell beschrieben ist, ist es damit also nicht nur möglich, die Software-Applikation automatisiert generieren zu lassen, sondern die Implementation auch in unterschiedlichen Entwicklungsphasen zu verifizieren.

Modellbasierte Systementwicklungsmethoden für das Informationsmanagement

Das rechte Bild in folgender Abbildung zeigt den stark abstrahierten Aufbau eines Autos.

Ein Auto besteht aus 2 Vorderrädern, 2 Hinterrädern und einem Motor, wobei über eine Achse 2 Räder vom Motor angetrieben werden. Diese Art von Modellen ist sehr gut geeignet, um Strukturen und Beziehungen darzustellen.

Modellbasierte Methoden, welche ähnlich geartete Modelle zur Informationsverwaltung nutzen, sind unter anderem:

• Model-Based Enterprise (MBE)
• Modelle für Printed Circuit Boards (PCB) in ECAD Applikationen
• Model-Based System Engineering (MBSE)

Die ersten beiden Methoden kommen in den spezifischen Disziplinen Mechanik und Elektronik zum Einsatz und sind in den entsprechenden Entwicklungswerkzeugen integriert. MBSE ist hingegen eine Methode, um Architekturen kompletter Systeme zu beschreiben und setzt damit im Prinzip noch eine Stufe höher an.

Welches ist nun die beste modellbasierte Methode?

Nach den obigen Ausführungen ist klar, dass dies die falsche Frage ist. Jede der oben genannten Methoden hat ihren spezifischen Einsatzzweck. Die Frage sollte also lauten:

Welche modellbasierten Methoden soll ich einsetzen?

Modellbasierte Systementwicklung bzw. modellbasierte Methoden bieten viele Vorteile, verlangen jedoch oft eine entsprechende Tool-Unterstützung. Ist diese gegeben, ist es auch ohne weiteres möglich, alle obengenannten Methoden einzusetzen.

Werden all diese Methoden eingesetzt, ergibt sich damit folgendes Gesamtbild:

• Architektur/Design: MBSE

• Mechanik: MBE
• Elektronik: ECAD
• Software: Model-Based Design

Zusammenfassung

Die Begriffe Modell und modellbasiert können sehr breit interpretiert werden. Dies hat nicht zuletzt mit dem Umstand zu tun, dass ein Modell immer für einen bestimmten Zweck erstellt wird und die Menge an legitimen Modellen zumindest sehr gross, wenn nicht gar unendlich ist.Was sie jedoch alle gemeinsam haben ist, dass es sich um eine Vereinfachung bzw. um eine Reduktion aufs Wesentliche handelt. Das Ziel ist dabei immer, auch die damit durchgeführten Tätigkeiten zu erleichtern.

Allgemeine Vor- und Nachteile von modellbasierten Methoden:

Die Vorteile liegen in der Verbesserung bzw. Unterstützung von Arbeitsabläufen.

Als Nachteil kann die notwendige Tool-Unterstützung betrachtet werden. Hier kann noch unterteilt werden in Tool-Kosten, Einarbeitung in neue Tools und die Gefahr von Tool-Lock-ins (starke Bindung an proprietäre Datenformate etc.).

Die genannten Nachteile können jedoch mit einer bedachten Wahl der Tools/Entwicklungswerkzeuge sehr reduziert werden. Natürlich gilt es auch dann noch, die Vor- und Nachteile gegeneinander abzuwägen. Wir sind überzeugt, dass jedes Projekt, egal welcher Grössenordnung, von der Nutzung von modellbasierten Methoden profitieren kann.

Glossar

Einleitung

Für medizinische Systeme mit sicherheitskritischen Anforderungen, wie z.B. Patientenüberwachungssysteme oder Beatmungsgeräte, ist die Dokumentation von System- und Software-Architekturen explizit erforderlich. Ergänzend muss ein Nachweis erfolgen, dass eine Architektur auch gemäss Ihrer Definition umgesetzt ist. Aber auch ausserhalb des regulierten Bereiches ist die sorgfältige Beschreibung einer Architektur für die meisten Anwendungen sinnvoll, denn die Beschreibung einer Architektur ist nicht nur ein Nachweis der Erfüllung von Anforderungen, sondern hilft auch, Fehler in der Spezifikation frühzeitig zu erkennen. Dieser Artikel zeigt, mit welchen (Hilfs-)Mitteln eine Architektur beschrieben werden kann und woran man sich dabei halten kann.

Beschreibung von Architekturen

Wie im Artikel über System- und Software-Architektur erläutert, ist die Architektur eines Systems «die Menge von Strukturen, welche benötigt werden, um auf das System schliessen zu können, respektive, um sicherzustellen, dass das System die geforderten Eigenschaften erfüllt. »

Zugegeben, diese Definition ist ziemlich abstrakt und zeigt keinen konkreten Bezug zu Hardware, Elektronik oder Software. Ein System besteht aber aus verschiedenen Strukturen wie Software, Elektronik oder Mechanik. Zusätzlich kann sich ein System auch durch logische Strukturen oder zeitlich aufeinanderfolgende Vorgänge charakterisieren. In diesem Sinne kann der Begriff «Die Architektur» irreführend sein, da die Singularität des Begriffes Architektur suggerieren könnte, dass eine Architektur aus einem einzigen Bild besteht. Die Praxis zeigt aber, dass ein System aus vielen unterschiedlichen Ansichten (Views) betrachtet und demnach auch beschrieben werden muss. Beispielsweise kann ein System in logische Einheiten und Funktionen unterteilt werden, die nicht unbedingt mit der physikalischen Aufteilung übereinstimmen. Dies kann anhand des folgenden, stark vereinfachten, Beispiels gezeigt werden:  

Abbildung 1: Logische und physikalische Sicht einer Client-Server-Anwendung sowie ein zugehöriges Szenario, um die Ansichten zu verbinden.

Aber welche ist die richtige oder beste, und vor allem von Regularien anerkannte Ansicht?

Eine Architekturbeschreibung besteht in der Regel genau darin, unterschiedlichen Ansichten aufzuzeigen, Verbindungen zwischen den Ansichten herzustellen und das Erfüllen von unterschiedlichen Anforderungen deutlich zu machen. Insofern besteht die Beschreibung einer Architektur aus mehreren Ansichten, welche unterschiedliche Aspekte beleuchten. Das heisst, es gibt nicht die einzig wahre Ansicht, sondern die Beschreibung einer Architektur berücksichtigt unterschiedliche Ansichten gleichwertig^[1].

Ansichten einer Architektur

Die Ansichten sind ein wesentlicher Bestandteil des internationalen ISO/IEC/IEEE 42010-Standards [link to https://www.iso.org/standard/50508.html], welcher eine Leitlinie bietet, wie die Architektur eines Systems zu beschreiben ist. Dieser Standard wurde 2011 veröffentlicht und ist das Resultat einer gemeinsamen ISO- und IEEE-Überarbeitung des früheren (stark Software-geprägten) IEEE 1471-Standards [link to https://standards.ieee.org/standard/1471-2000.html]. Der ursprüngliche IEEE 1471-Standard spezifizierte, wie die Architektur eines Systems zu beschreiben ist. Weitere Anforderungen wie der Aufbau einer Architektur sowie Anforderungen an die Beschreibungssprache wurden in 42010 ergänzt. Der Standard erfordert jedoch keine spezifische Architekturbeschreibung oder Beschreibungssprache. Stattdessen sollte die Praxis der Beschreibung einer Architektur standardisiert werden.

Ansichten (engl. Views) sollen ein System abbilden, indem sie auf Basis definierter Standpunkte die Anforderungen (Concerns) der Stakeholder berücksichtigen. Abbildung 2 zeigt, wie Ansichten, Standpunkte, Anforderungen und Stakeholder zusammenhängen.

Abbildung 2: Abhängigkeiten zwischen Ansichten, Standpunkten, Anforderungen und Stakeholdern in Anlehnung an den ISO 42010- Standard

Für die Erstellung einer Architekturbeschreibung hat sich folgender Prozess etabliert, welcher stark an den ISO 42010-Standard angelehnt ist:

1. Identifikation der Stakeholder
2. Identifikation der Belange / Anforderungen an die Beschreibung
3. Definition der passenden Standpunkte (Viewpoints)
4. Erstellung der Ansichten, basierend auf den Standpunkten
5. Verifikation der Architektur mittels Szenarien, wobei die Schritte 4 und 5 iterativ erfolgen.

Die einzelnen Schritte werden in den folgenden Kapiteln näher beschrieben.

Identifikation der Stakeholder

Damit die Standpunkte gezielt und vor allem systematisch definiert werden können, sollen in einem ersten Schritt die Stakeholder identifiziert werden, welche mit und für das System arbeiten oder Entscheidungen über das System treffen. Das können unter anderem Entwickler, Produkt-Manager, Risk-Manager, Endanwender, Produktionsmitarbeiter, Projekt-Manager usw. sein.

Identifikation der Belange und Anforderungen

Auf der Basis der identifizierten Stakeholder sollen deren Anforderungen an die Architekturbeschreibung erfasst und dokumentiert werden. Ergänzend zum Kontext-Interview mit den Stakeholdern können Hinweise zu Anforderungen an die Architekturdokumentation auch in den User- oder System-Requirements zu finden sein. Tabelle 1 zeigt, wie dies am Beispiel von Abbildung 1 aussehen könnte.

Tabelle 1: Identifikation von Stakeholdern und Erwartungen an die System-Architektur

Definition der passenden Standpunkte

Der Standpunkt charakterisiert sich durch eine Menge von Anforderungen der entsprechenden Stakeholder sowie durch unterschiedliche Konventionen hinsichtlich Modell-Typen, Notationen sowie Techniken für die darauf aufbauenden Ansichten. Die Standpunkte können wie im Beispiel von Tabelle 2 definiert werden. Ergänzend zu der tabellarischen Aufführung müssen die entsprechenden Notationen definiert werden. Dies kann entweder in jeder Ansicht separat, oder, im Sinne des 42010-Standards, in einem separaten Standpunkt-spezifischen Abschnitt erfolgen.

Tabelle 2: Definition der Standpunkte

Definition eines Standpunktes

Ein Standpunkt ist eine Art Vorlage, welche über mehrere Systeme (wieder-)verwendet werden kann und/oder unter Architekten austauschbar ist. Eine solche Vorlage wird dann verwendet um auf deren Basis systemspezifische Ansichten zu erstellen. Eine bekannte Sammlung von Standpunkten ist das «4+1 view model» von Kruchen oder das arc42 template, welche insbesondere in Software-Systemen Anwendung finden. Die Verwendung von Standpunkten ist aber nicht nur auf Software-Architekturen limitiert, sie können auf beliebige Systeme angewendet werden.

Die Definition und Wahl der Standpunkte werden primär durch die Belange der identifizierten Stakeholder festgelegt. In den nachfolgenden Kapiteln stellen wir drei mögliche Standpunkte vor, wobei diese Zusammenstellung nicht für jedes System anwendbar ist.

Generell empfiehlt es sich, die Anzahl der verwendeten auf ein sinnvolles Minimum zu beschränken, da Redundanzen mit jedem zusätzlichen steigen. Ausserdem muss jede Ansicht, welche aus den Standpunkten erstellt wird, über den Projektverlauf gepflegt, nachgeführt und vor allem konsistent gehalten werden. Der resultierende Aufwand nimmt mit der Anzahl der Standpunkte und den erstellten Ansichten zu. Unter der Voraussetzung, dass die Standpunkte und deren Ansichten den Nachweis der Anforderungen ermöglichen, ist also in diesem Fall weniger mehr.

Der logische Standpunkt

Der logische Standpunkt wird für Geräte, bestehend aus Hard- und Software, häufig als (primären) Standpunkt verwendet. Dabei wird das System in seine logischen Einzelteile zerlegt und angeordnet. In den daraus erstellten Ansichten können insbesondere funktionale Anforderungen den Komponenten zugeordnet und mögliche funktionale Redundanzen innerhalb des Systems identifiziert werden. Eine explizite Zuordnung der Systemanforderungen ist sinnvoll, da dadurch die Rückverfolgbarkeit (Traceability) gewährleistet wird. Insbesondere für sicherheitskritische Systeme ist ein Nachweis der Rückverfolgbarkeit erforderlich. Dies gilt nicht nur für System-Architekturen, sondern auch für Subsystem- und Software-Architekturen.

Kommunikationswege und zeitliche Abfolgen/Abhängigkeiten können, je nach Architektursprache, ebenfalls innerhalb der logischen Ansicht definiert werden. Da die logische Aufteilung und die dazugehörigen Prozesse eine sehr starke Abhängigkeit haben, bietet sich eine Kombination an. Alternativ können die Prozesse in einer dedizierten Sicht dargestellt werden, wobei für diesen Fall das Design von logischer Sicht und Prozess-Sicht üblicherweise iterativ erfolgt.

Der physikalische Standpunkt

Gleichwertig zum logischen Standpunkt können unterschiedliche physikalische Standpunkte die Beschreibung und das Verständnis des Systems erweitern. Physikalische Standpunkte können beispielsweise elektronische, pneumatische oder elektromechanische Ansichten sein, welche je nach Anforderungen an das System sinnvoll sind. Auch für verteilte Software-Systeme kann ein physikalischer Standpunkt Sinn machen, in der die Umsetzung von nicht-funktionalen Anforderungen wie Skalierbarkeit, Verfügbarkeit oder Performance aufgezeigt werden kann.

Der Entwicklungs-Standpunkt

Eine häufig nur implizit durchgeführte, aber für einen reibungslosen Projektablauf sehr wichtiger Standpunkt, ist die Entwicklungssicht. Dabei wird aufgezeigt, wie das zu entwickelnde System in kleine Arbeitspakete aufgeteilt werden kann, um diese den einzelnen Entwicklern oder Entwicklungs-Teams zuzuweisen. Damit können nicht nur interne Anforderungen wie beispielsweise Wiederverwendbarkeit oder die Auswahl der Entwicklungs-Tools berücksichtigt werden, sondern eine solche Ansicht ermöglicht auch die Überwachung der Entwicklungskosten und Termine im Verlauf des Projektes. Die Entwicklungssicht ist häufig nicht Bestandteil der formalen System-Architektur, sondern wird im Rahmen der Projektplanung erstellt.

Verifikation der Architektur

Ein beliebtes Instrument zwecks Verifikation einer Architektur ist das Durchspielen von Szenarien. Dabei werden in Abhängigkeit von den Anforderungen die wichtigsten Schlüssel-Szenarien definiert. Ein Szenario ist keine eigene Ansicht, sondern baut auf bestehenden Ansichten auf, indem es diese in Verbindung bringt. Demnach ist eine vollständige Architekturbeschreibung die Grundlage für die Verifikation, respektive, die Szenarien können nur durchgespielt werden, sofern die Architektur vollständig beschrieben ist. Analog zur Beschreibung der logischen oder physikalischen Ansichten, wird der Ablauf des Szenarios in der Form eines Diagramms dargestellt. Häufig werden dazu Objekt-Interaktions-Diagramme verwendet um die Interaktion zwischen den logischen und/oder physikalischen Elementen darzustellen (siehe dazu auch Abbildung 1). Solche Szenarien dienen nicht nur der Verifikation einer Architektur, sondern helfen auch, den Aufbau eines Systems zu verstehen.

Zusammenfassung

Häufig sind unterschiedliche Stakeholder involviert, welche unterschiedliche Anforderungen an ein System stellen. Damit diese Anliegen gezielt adressiert und deren Erfüllung nachgewiesen werden kann, bedarf es zur Beschreibung einer Architektur mehrerer Ansichten. Diese Ansichten können von generell definierten Standpunkten abgeleitet werden. Die Standpunkte bestehen aus allgemein anwendbaren Konventionen und sind somit über mehrere Systeme hinweg austausch- und wiederverwendbar. Abschliessend zur Architekturbeschreibung kann diese mit Hilfe von Szenarien verifiziert werden, um die Erfüllung der wichtigsten Anforderungen nachzuweisen.

Einleitung

«System-Design», «System-Architektur», «Software-Architektur», was steckt genau hinter diesen Begriffen? Was ist damit gemeint? Was sind die Definitionen? Warum ist es wichtig diese Begriffe zu unterscheiden?

Mit Antworten auf diese Fragen beschäftigt sich dieser Artikel.

Das System

Wir beschäftigen uns hier mit technischen Systemen. Noch etwas spezifischer mit Embedded Systemen. Ein Embedded System, auf Deutsch ein «eingebettetes System» ist wie folgt definiert:

«Ein eingebettetes System ist ein elektronischer Rechner oder auch Computer, der in einen technischen Kontext eingebunden (eingebettet) ist. Dabei übernimmt der Rechner entweder Überwachungs-, Steuerungs- oder Regelfunktionen oder ist für eine Form der Daten- bzw. Signalverarbeitung zuständig, beispielsweise beim Ver- bzw. Entschlüsseln, Codieren bzw. Decodieren oder Filtern.»

Quelle: Wikipedia

Ganz ähnlich diese Definition (Quelle https://www.embedded-software-engineering.de):

«Ein eingebettetes System ist ein binärwertiges digitales System (auch Computersystem genannt), das in ein umgebendes technisches System eingebettet ist und mit diesem in Wechselwirkung steht. Dabei übernimmt der Rechner meist Überwachungs-, Steuerungs- oder Regelungsfunktionen, ist oft aber auch für eine Form der Daten- bzw. Signalverarbeitung zuständig.»

Diese Definitionen können mit dem folgenden Diagramm verdeutlicht werden:

Abbildung 1: Allgemeines Embedded System mit der gewünschten Funktion / Verantwortung umgeben von externen Systemen und einem oder mehrere Benutzer.

Der Einfachheitshalber wird meist einfach von dem „System“ gesprochen mit welchem man sich befasst. Auch im Rest dieses Artikels wird häufig nur noch von „System“ gesprochen und meint damit das entsprechende technische oder eben das Embedded System.

Architektur & Design

Um die Begriffe zu erklären, muss aufgezeigt werden, wie ein solches System gebaut wird. Abbildung 1 stellt das Embedded System als Blackbox dar. Der Aufbau des Systems ist noch nicht definiert. Es muss definiert werden aus welchen Bestandteilen das System aufgebaut werden soll. Diese Tätigkeit nennt man «Design». Bei einem «System-Design» geht es also um die Definition und Festlegung des Systemaufbaus. Das Resultat einer solchen Design-Tätigkeit könnte dann basierend auf dem Diagramm (Abbildung 2) wie folgt aussehen:

Abbildung 2: Resultat (Architektur) der ersten Design Iteration zur Definition der Bestandteile (Architekturelemente).

Meist läuft eine solche Design-Tätigkeit iterativ ab. Das heisst die Bestandteile – man spricht hier von Architekturelementen – werden soweit zerlegt (engl. «decompose»), bis diese genügend definiert sind. Erst dann kann die Erstellung (Entwicklung) des Systems beginnen.

Das Resultat dieser Design-Aktivität nenn man «Architektur». Die Abbildung 2 ist also eine erste «System-Architektur» (genau genommen ist die Abbildung 2 eine Referenzarchitektur eines allgemeinen Embedded System). Wobei der Begriff Architektur in diesem Zusammenhang noch genauer definiert werden muss. Es gibt nicht eine einzige etablierte Definition des Architektur-Begriffes. Eine Sammlung von Definitionen findet man hier: https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=513807. Dies sind zwar Definitionen für Software-Architektur, gelten jedoch auch für den System-Architektur Begriff. Die Unterscheidung liegt im Anwendungsbereich (engl. Scope) –  dazu aber weiter unten noch mehr.

Wir verwenden die folgende Definition des Architektur-Begriffes (aus «Software Architecture in Practice – Third Edition»):

Definition (Software-) Architektur

“The (software) architecture of a system is the set of structures needed to reason about the system, which comprise (software) elements, relations among them, and properties of both.”

Übersetzt sind darin die folgenden 3 Sätze enthalten:

1. Die Architektur eines Systems ist aus einer Menge von Strukturen aufgebaut.
2. Es sind die Strukturen, welche benötig werden, um auf das System schliessen zu können.
3. Die Strukturen umfassen die Elemente, deren Beziehungen und deren Eigenschaften.

Was bedeutet das nun?

Die Strukturen bestehen aus Elementen, deren Beziehungen und deren Eigenschaften. Architektur besteht aus den Strukturen, welche benötigt werden, um sicherzustellen, dass sich das System wie gefordert verhält. Wobei hier nicht nur die Erfüllung der funktionalen Anforderungen gemeint ist, sondern auch der ganze Bereich der nicht-funktionalen Anforderungen. Beispielsweise haben Forderungen bezüglich Weiterentwickelbarkeit meist Einfluss auf die Struktur des Systems. Es gehören jedoch nicht alle Strukturen eines Systems zur Architektur. Nicht alle Strukturen sind Architektur-relevant. Man spricht bei diesen Strukturen dann nicht mehr von Architektur, sondern von Design.

«Design» ist einerseits die Tätigkeit, welche zu einer Architektur führt (siehe weiter oben), als auch der Begriff für sämtliche nicht Architektur-relevanten Resultate aus der Design Tätigkeit.

Viele Definitionen machen sich das einfacher, indem sie ausführen, die Grobstruktur oder die früh im Design Prozess definierten Strukturen sind Architektur. Alle späteren oder detaillierteren Strukturen sind Design. Diese Definitionen sind allerdings unzureichend, da durchaus detailliertere Strukturen notwendig sein können, um die geforderten Anforderungen zu erfüllen. Auch wird in einer agilen Entwicklung nicht alles Relevante schon früh im Design Prozess definiert.

System versus Software

Zuletzt noch die Unterscheidung zwischen «System-Architektur» und «Software-Architektur»: Wie bereits weiter oben aufgeführt unterscheiden sich diese im Anwendungsbereich (Scope). Die System-Architektur umfasst die Strukturen von verschiedenen System-Elementen, wie Hardware, Software, Mechanik. Die Software-Architektur hingegen umfasst die Strukturen, welche den Aufbau eines Software-Elementes (ein Element aus der System-Architektur) definieren. Dies ist in den nachfolgenden Diagrammen ersichtlich:

Abbildung 3: System Architektur Diagramm mit Hardware und Software Elementen.

Bei der weiterführenden Zerlegung eines Software Elementes landen wir schlussendlich bei der Software Architektur:

Abbildung 4: Software Architektur Diagramm des Software Elementes «Control Software».

Zusammenfassung

Tab. 1: Begriffe und deren Bedeutung resp. Definition