Mathworks System-Engineering in model-based System

Die Entwicklung grosser Systeme ist eine Aufgabe von immer grösserer Komplexität. Die Rückverfolgbarkeit und Synchronisierung über alle Designebenen hinweg ist der Schlüssel zur Rationalisierung gross angelegter Entwicklungsprogramme. Häufig fehlt jedoch das Bindeglied zwischen der Systemtechnik und der Design- Implementierung in einem Top-down-Designprozess.

Angesichts der ständig zunehmenden Grösse und Komplexität von Systemen, der Anforderungen, die konstruiert, gewartet, abgeleitet, zugewiesen und eingehalten werden müssen, sowie der Randbedingungen hinsichtlich Leistung, Kosten, Markteinführungszeit, Energieverbrauch, Gewicht und anderen Grössen ist die Systemtechnik eine Herausforderung, die diese Faktoren beim Entwurf von Systemarchitekturen berücksichtigen muss. Das Ergebnis dieses Prozesses ist in der Regel eine Reihe von Ausgangspunkten für das Design der Unterkompo­nenten mit Schnittstellenbeschreibungen, abgeleiteten Randbedingungen und Anforderungen.

Die grösste Herausforderung besteht darin, sich auf Systemdetails zu konzentrieren, ohne den Überblick zu verlieren – entscheidende Informationen zum Systemkontext, die Rückverfolgbarkeit der Anforderungen auf System- und (abgeleiteter) Komponenten­ebene und die Verwendung gefilterter Ansichten für die Handhabung der Systemkomplexität sind von entscheidender Bedeutung. Ein einfacher Übergang zur Weiterentwicklung des Systems und garantierte Beständigkeit sind weitere Schlüsselaspekte für den Erfolg.

Bildergalerie

Bildergalerie mit 6 Bildern

Zerlegung der Anforderungen und Zuordnung zum Architekturmodell

Ein Systemtechnik-Projekt beginnt typischerweise mit Anforderungen auf hoher Ebene und optional einem Altsystem, das teilweise oder strukturell bis zu einem gewissen Grad wiederverwendet werden könnte. Die Hauptaufgabe besteht darin, eine Architektur mit Unterkomponenten zu erstellen, die jeweils abgeleiteten Anforderungen zugeordnet sind, um ihren Anteil an der Gesamtfunktionalität zu erfüllen, wobei so viele Hierarchieebenen wie nötig beteiligt sind.

Diese strukturelle Zerlegung geht also mit einer dazugehörigen Zerlegung der Anforderungen und Randbedingungen einher, so dass am Ende dieses Prozessschritts die Einschränkungen jeder Unterkomponente ausreichend definiert sind. Typischerweise werden anfangs mehrere alternative Architekturlösungen erstellt, welche es anschliessend auszuwerten und zu vergleichen gilt, um die bestgeeignete Architektur für die weitere Entwicklung auszuwählen.

Beispielsweise könnten im Bereich der Sensorik unterschiedliche Konzepte umgesetzt werden oder bei sicherheitskritischen Systemen unterschiedliche Ansätze zur Sicherheitsdekomposition gegenübergestellt werden, wie z. B. die Verwendung einzelner Komponenten höherer Sicherheitsstufe gegenüber mehreren diversitär redundanten Komponenten niedrigerer Sicherheitsstufe. Die Anforderungen, welche beim Aufbau einer Architektur als abgeleitete Anforderungen den Komponenten zugeordnet werden, können sowohl nichtfunktionaler als auch funktionaler Natur sein:

Nichtfunktionale Anforderungen und Analysen

Wie im vorangehenden Beispiel ersichtlich gibt es nichtfunktionale Anforderungen, die bei der Architekturentscheidung zu berücksichtigen sind. Neben Sicherheitsstufen können dies beispielsweise auch Anforderungen an den Lebenszyklus oder andere nichtfunktionale Einschränkungen sein.

Mögliche Komponenten sind charakterisiert durch Eigenschaften wie Gewicht, Kosten, Zuverlässigkeit, Entwicklungsaufwand und andere domänenspezifische Design­daten, die diesen nichtfunktionalen Anforderungen – sowie deren Zusammensetzung – auf jeder Hierarchieebene entsprechen müssen. Zur Einbeziehung solcher Grössen wird dementsprechend eine Hierarchie von Stereotypen definiert, die jede Art von benötigter Komponente repräsentiert und diese nichtfunktionalen Eigenschaften nach Bedarf erfasst. In einer Architektur können so alle Komponenten typgerecht mit den relevanten Eigenschaften bedatet werden. Diese Architekturdaten sind Gegenstand der Systemanalysen zur Berechnung der Gesamtgrössen zur Beurteilung der Einhaltung der Systemrandbedingungen bzw. zum Vergleich der verschiedenen Architekturlösungen.

Bei MBSE-Werkzeugen (Model-based Systems Engineering) wie dem System Composer werden die Stereotypen zu jeder Komponente ausgewählt und die Grössen der dazugehörigen Typ-Eigenschaften eingegeben. So sind zu jeder Komponente der Architektur alle komponentenspezifischen Daten verfügbar. Diese Daten kann der System Composer jederzeit auswerten und die resultierenden architekturspezifischen Systemgrössen ermitteln, wie in Abb. 1 dargestellt. So kann frühzeitig die Einhaltung der Systemrandbedingungen überprüft oder die beste Architekturlösung zur weiteren Entwicklung selektiert werden.

Funktionale Anforderungen und Simulation

Abgesehen von zeitlichen Leistungseinschränkungen werden funktionale Anforderungen in der Regel nicht speziell auf der Architekturebene behandelt, ausser dass sie parallel zur Architekturerstellung in abgeleitete Anforderungen zerlegt und den Architekturkomponenten zugeordnet werden. Mit Anforderungsverwaltungswerkzeugen wie Simulink Requirements erfolgt dies per Drag & Drop auf die Komponenten und kann direkt im Diagramm zu den Komponenten eingeblendet werden (siehe Abb. 1). Inkonsistenzen oder fehlende Anforderungen sind bei so eng integrierter Datenhaltung schnell auffällig. Für eine Präzisierung können an dieser Stelle auch Sequenzdiagramme ergänzend genutzt und später zu Verifikationszwecken wiederverwendet werden.

Erst eine vollständige Formalisierung aller funktionalen Anforderungen der Komponenten würde bereits auf Architekturebene eine frühe funktionale Analyse erlauben. Aufgrund des hohen Aufwands wird dieses Verfahren aber nur sehr selten durchgeführt.

Stattdessen greift z. B. das MBSE-Werkzeug System Composer auf Simulation von Komponenten- und Architekturebene zurück, um die Konsistenz der Anforderungen sowohl lokal als auch im Gesamtsystemverhalten zu validieren. Jede Komponente, für die ein Simulink-Modell hinterlegt ist, wird in diese Gesamtsystemsimulation mit einbezogen.

Damit eröffnen sich alle Möglichkeiten der Testeinrichtung und Testautomatisierung selbst auf oberster Architekturebene, ohne dass hierfür ein Extramodell erstellt werden müsste (Abb. 2). Schnittstellen und Verbindungen werden somit simulativ mit einbezogen und potenzielle Fehlerquellen durch einen Bruch zwischen der Systemtechnik und dem Designablauf ausgeschlossen.

Umgang mit Komplexität

Per Definition sind Systeme komplexer als nur die Software oder nur die Hardware oder jede andere Segmentierung des Systems. Die alleinige Konzentration auf Teile des Systems während jeder Entwurfstätigkeit ist zwingend erforderlich, um sich nicht in Komplexitätsfragen zu verlieren oder zu verheddern. Wenn jedoch wichtige Kontextinformationen über die Rolle einer Komponente oder ihrer systeminternen Umgebung fehlen, werden Spezifikations- oder Designfehler unvermeidlich. Es muss also eine geeignete Teilmenge (Ansicht) des Systems eingerichtet werden, um ein spezifisches Design- oder Analyse­anliegen zu verstehen, wobei nur die minimal erforderlichen Kontextinformationen enthalten sein dürfen. Alles, was für die vorliegende Aufgabe nicht relevant ist, muss ausgeblendet werden.

Eine manuelle Erstellung einer geeigneten Ansicht, die den oben genannten Kriterien entspricht, ist sehr aufwendig und bei Änderungen im System der Gefahr der Inkonsistenz ausgesetzt. Zudem reicht es in der Regel nicht aus, nur eine Ansicht für einen Teil des Systems zu erstellen, da verschiedene Per­spektiven der Systembetrachtung verschiedene Ansichten erfordern, die sich darüber hinaus überlappen können: funktionale Abhängigkeiten, organisatorische Abhängigkeiten, Engpassansichten, Überlegungen zum Energieverbrauch, Lieferantenabhängigkeiten, Reifegrade, Ansichten zur Ausfallwahrscheinlichkeit, Abschnitte zum Sicherheits­integritätsniveau usw. Ein vollständiges Verständnis eines bestimmten Design- oder Analyse­anliegens erfordert ein schnelles Umschalten zwischen der grossen Anzahl verschiedener Gruppierungen und Filter, die auf den (Teil-)Systemen benötigt werden.

Da all diese unterschiedlichen Sichtweisen auf ein System stets konsistent sein müssen, ist die Tool-Unterstützung für die Einrichtung und Verwendung solcher Sichtweisen von entscheidender Bedeutung. Beispielsweise erlaubt der System Composer hierfür die Einrichtung beliebiger Ansichten über multiple Filterbedingungen und optionale Gruppierungskriterien (Abb. 3 und 4). So können Teile der Architektur unter ausgewählten Gesichtspunkten dargestellt werden, z. B. alle Komponenten von bestimmten Zulieferern und deren Verbindungen zur Betrachtung von Lieferantenabhängigkeiten oder alle Komponenten, welche bestimmte Sensordaten erhalten, oder alle Komponenten einer bestimmten Sicherheitsstufe usw. Hier sind beliebige Kriterien möglich. Unnötige Komponenten oder Signalverbindungen sind in einer Ansicht entfernt, hingegen sind optionale Gruppierungen einbezogen und im automatischen Layout der Darstellung berücksichtigt.

Bei entsprechender Werkzeugunterstützung sind diese Sichten basierend auf den Filterbedingungen automatisch generiert und somit immer konsistent zur Gesamtarchitektur. Änderungen sowohl in der Struktur wie z. B. das Hinzufügen weiterer Komponenten als auch in den Komponenteneigenschaften sind in allen Ansichten automatisch synchronisiert und somit aktualisiert.

Ebenfalls wichtig in der Systemtechnik sind sogenannte Allokationen von z. B. Software-Funktionen auf die logische oder physikalische Ausführungsebene. Zur Bearbeitung und Visualisierung der Allokationszuordnung haben sich Matrizendarstellungen bewährt.

Der Einsatz von MBSE-Werkzeugen

Aufgrund der Grösse 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 im Zusammenhang mit Einheitlichkeit oder veralteten Daten ist einfach zu hoch, wenn keine spezielle Werkzeug-Unterstützung in Anspruch genommen wird, um die Daten zusammen- und konsistent zu halten. Dies gilt umso mehr für jeden manuellen Ansatz, mit dem eine Art von Sicht auf das System geschaffen wird, bei der man sich nur auf bestimmte Aspekte konzentriert und alles andere aussen vor lässt.

Aus diesem Grund sind MBSE-Werkzeuge oder Entwicklungsumgebungen für Software und für Hardware, die Lösungen für die oben genannten Herausforderungen und Aufgaben bieten, sehr zu empfehlen.

Für die Verwendung der Architekturstruktur, der Schnittstellendefinitionen, der zugewiesenen Anforderungen usw. für den anschliessenden Entwurf der Verhaltensspezifikation wird ausserdem dringend empfohlen, diese Systemtechnik-Funktionalität in eine Entwicklungsumgebung zu integrieren, die eine nahtlose Fortsetzung der Arbeit auf Komponentenebene sowie eine automatische Integration in das Architekturmodell einschliesslich der besonders wichtigen Systemsimulationsfunktion für die Validierung ermöglicht. Für Model-based Design – also den Entwurf gemischter Software- und Hardwaresysteme mit automatischer Codegenerierung unter Einbeziehung der physikalischen Teile und der Simulationsumgebung – stehen derartige Systemtechnik-Funktionen mit den Produkten System Composer und Simulink Requirements zur Verfügung, die Simulink mit allen oben genannten Funktionen integrieren und erweitern.

Bereits während der Architekturentwicklung kann für jede Komponente der Architektur hierbei mit Simulink für datenfluss­orientiertes Verhalten oder Stateflow zur Automatenerstellung ein zugehöriges Verhalten modelliert werden – die Schnittstellen werden hierbei automatisch übernommen und sind somit immer identisch zur Architektur, auch bei Änderungen (Abb. 5). Sind die Komponentenverhaltensmodelle in Simulink lauffähig, kann die Gesamtintegration auf Architekturebene auch simuliert und getestet werden.

Mit diesen Systemtechnik-Fähigkeiten bietet Model-based Design somit einen vollständigen Workflow von den Systemanforderungen über die Architektur und die Verhaltensmodelle über den generierten Code bis hin zum virtuellen Produkt und adressiert hierbei zentrale Herausforderungen im Bereich der Analyse, Komplexität und Simulation.

(ID:47757213)