Merken 01.10.2020

Von Systems Engineering zur Implementierung

Der interdisziplinäre Ansatz des Systems Engineering ist eine Aufgabe von immer größerer Komplexität. Nur wenn Arbeitsschritte und Modifikationen über alle Designebenen hinweg rückverfolgbar sind und synchronisiert werden, können groß angelegte Entwicklungsprogramme rationalisiert werden. Häufig fehlt in einem Top-down-Designprozess jedoch ein Bindeglied zwischen dem Systems Engineering und der Design-Implementierung.

Systems Engineering haben die Aufgabe, den Balanceakt zwischen immer größeren und komplexeren Systemen und deren vielfältige Anforderungen sowie den Einschränkungen hinsichtlich Leistung, Kosten, Markteinführungszeit, Energieverbrauch, Gewicht und anderen Bereichen zu meistern. Das Ergebnis dieses Prozesses ist in der Regel eine Reihe von Ausgangspunkten für das Design der Unterkomponenten mit Schnittstellenbeschreibungen, Unterbeschränkungen und abgeleiteten Anforderungen.
Die Herausforderung besteht darin, sich auf jede Komponente im System zu konzentrieren, ohne den Überblick zu verlieren. Essentielle Informationen zum Systemkontext oder die Rückverfolgbarkeit der Anforderungen auf Systemebene und (abgeleiteter) Komponentenebene sind dabei von entscheidender Bedeutung.

Anforderungen und Architekturmodell

Zuerst muss ein Anforderungsprofil erstellt werden. Ein Systems Engineering-Projekt beginnt typischerweise mit Anforderungen auf hoher Ebene und optional einem Vorgängersystem, das unter Umständen bis zu einem gewissen Grad wiederverwendet werden kann. Die Hauptaufgabe besteht dann in der Erstellung einer Architektur mit Unterkomponenten, die jeweils abgeleiteten Anforderungen zugeordnet sind, um ihren Anteil an der Gesamtfunktionalität zu erfüllen.

Nicht-funktionale Anforderungen

Viele Anforderungen beziehen sich auf Fragen des Lebenszyklus oder andere nicht-funktionale Einschränkungen wie zum Beispiel Gewicht, Kosten, Zuverlässigkeit, Entwicklungsaufwand und andere Designdaten. Dementsprechend muss eine Hierarchie von Stereotypen definiert werden, die jede Art von Unterkomponente repräsentiert und Eigenschaften nach Bedarf erfasst, einschließlich der oben erwähnten nicht-funktionalen Anforderungen.

Funktionale Anforderungen

Abgesehen von zeitlichen Randbedingungen werden funktionale Anforderungen in der Regel auf der Architekturebene nicht speziell behandelt, außer dass sie parallel zur Systemzerlegung ebenfalls in abgeleitete Anforderungen zerlegt werden. Die Durchführung einer vollständigen Analyse in diesem frühen Stadium ist mit formalisierten Anforderungen prinzipiell möglich. Aber aufgrund der Schwierigkeit, einen vollständigen Satz von Anforderungen und Annahmen zu erhalten, wird sie in der Praxis nur sehr selten angewandt. Stattdessen wird eine Simulation auf Komponenten- und Architekturebene vorgeschlagen, um die Konsistenz der Anforderungen sowohl lokal als auch im Gesamtsystemverhalten zu validieren.

Umgang mit Komplexität

Eine Ansicht für alle erforderlichen Betrachtungen funktioniert hier nicht, da verschiedene Perspektiven der Systembetrachtung verschiedene Ansichten erfordern, die sich überlappen. Dies sind zum Beispiel funktionale Abhängigkeiten, organisatorische Abhängigkeiten, Engpassbetrachtungen, Überlegungen zum Energieverbrauch, Lieferantenabhängigkeiten, Reifegrade, Ansichten zur Ausfallwahrscheinlichkeit, Abschnitte zum Sicherheitsintegritätsniveau usw.
Ein vollständiges Verständnis eines bestimmten Design- oder Analyseanliegens erfordert ein schnelles Umschalten zwischen einer großen Anzahl verschiedener Gruppierungen und Filter auf der (Teil-)System-Ebene.
Da all diese unterschiedlichen Sichtweisen auf ein System stets einheitlich sein müssen, ist die Tool-Unterstützung für die Definition und Verwendung solcher Sichtweisen von entscheidender Bedeutung.

Die richtigen Werkzeuge

Aufgrund der Größe und Komplexität von Systemen sind klassische Ansätze mit Zeichentools und Tabellenkalkulationen zur Berücksichtigung benutzerdefinierter Eigenschaften und entsprechender Analysen nicht mehr angemessen. Die Wahrscheinlichkeit von Problemen durch fehlende Konsistenz oder veraltete Daten ist einfach zu hoch, wenn es keine spezielle Tool-Unterstützung gibt, um die Daten zusammen und konsistent zu halten. Dies gilt umso mehr für manuelle Ansätze. Aus diesem Grund empfehlen sich Systems Engineering-Werkzeuge oder Entwicklungsumgebungen für Software und für Hardware, die Lösungen für die genannten Herausforderungen und Aufgaben bieten.
Darüber hinaus sollte diese Systems Engineering-Funktionalität in eine Entwicklungsumgebung integriert sein, so dass die Verwendung der strukturellen Architektur, der Schnittstellendefinitionen oder der Anforderungen für den anschließenden Entwurf der Verhaltensspezifikation innerhalb der Umgebung möglich ist. So wird eine nahtlose Fortsetzung der Arbeit auf Komponentenebene sowie eine automatische Integration in das Architekturmodell einschließlich der Systemsimulationsfunktionen für die Validierung ermöglicht.
Für Model-Based Design – also den Entwurf gemischter Software- und Hardwaresysteme mit automatischer Codegenerierung und unter Einbeziehung der physikalischen Teile und der Simulationsumgebung – stehen derartige Systems Engineering Funktionen zum Beispiel mit den Produkten System Composer und Simulink Requirements zur Verfügung. Mit den neuen Systems Engineering Fähigkeiten bietet Model-Based Design einen vollständigen Workflow von den Systemanforderungen bis hin zum virtuellen Produkt.

www.mathworks.com