In diesem Artikel geben wir Ihnen einen Überblick über das Systemmodell mit iQUAVIS. Dabei gehen wir fokussiert auf das Modellkonzept ein. Zur methodischen Erarbeitung eines Systemmodells bietet sich bspw. die Methode CONSENS an, die wir in einem separaten Beitrag erläutern.
Inhalt
Grundstruktur: Anforderungen, Struktur und Verhalten
Für eine umfassende Systemmodellierung müssen unterschiedliche Sichten auf das zu entwickelnde System berücksichtigt werden. Diese beschreiben verschiedene Blickwinkel auf das System. Grundsätzlich kann man dabei die Blickwinkel Anforderungen, Struktur und Verhalten unterscheiden. Für diese Blickwinkel gibt es jeweils spezifische Sichten, die die Erarbeitung und Nutzung der Informationen ermöglichen.
Für den Blickwinkel Anforderungen kommen grundsätzlich Baumstrukturen in Frage (die übrigens auch gut tabellarisch abgebildet werden können). Dabei werden in der Regel verschiedene Modellelemente für Anforderungen und für Tests genutzt. Diese werden zum einen untereinander verknüpft. Zum anderen werden sie mit allen verschiedenen Modellelemente aus dem Bereich Struktur oder Verhalten verknüpft, um so die Traceability in den Rest des Systemmodells zu ermöglichen.
Für den Blickwinkel Struktur werden in der Regel Blockdiagramme bzw. (in iQUAVIS) Entitäten als Modellelemente genutzt. Eine Entität stellt ein Lösungselement dar, das aus verschiedenen Domänen kommen kann. Es kann ein physischen Bauteil repräsentieren oder ein Softwareelement oder ähnliches. Im Bereich der Struktur können wiederum unterschiedliche Blickwinkel eingenommen werden, die zum Beispiel das Umfeld oder die interne Struktur in den Fokus nehmen.
Für den Blickwinkel Verhalten gibt es zahlreiche Beschreibungstechniken. Typisch sind Sequenzdiagramme, die einen konkreten Ablauf präzise beschreiben, mithin die Formalisierung eines Use-Case Beschreibung darstellen. Funktionsabläufe bzw. Aktivitätsdiagramm stellen einen gewünschten Ablauf mit allen möglichen Alternativen dar. Zustandsdiagramme werden genutzt, um die Betriebszustände des modellierten Systems zu definieren. Innerhalb eines Zustands wird das Verhalten, das zuvor mit Aktivitätsdiagrammen beschrieben wurde, aufgerufen.
Entscheidend ist, die erwähnten Diagramm bzw. Beschreibungstechniken nicht nur einzeln zu betrachten, sie stellen für sich immer nur eine Sicht auf das Systemmodell dar. Das Systemmodell beinhaltet auch Verknüpfungen zwischen den Modellelementen, die die Traceability ermöglichen. So sind bspw. die Use-Cases jeweils mit einem Umfeldelement verknüpft. Die Wirkstruktur ergibt sich aus der Fokussierung auf eine Entität (typischerweise auf das zu modellierende System). Das Sequenzdiagramm ist häufig eine Ausdetaillierung eines Use-Cases und folglich mit ebendiesem verknüpft. Zustände verweisen auf Systemelemente, in denen sie laufen und auf Aktivitätsdiagramm, die sie aufrufen. Diese Aktivitäten werden ihrerseits wieder durch (andere) Systemelemente ausgeführt und daher allokiert. Anforderungen können auf verschiedene der genannten Modellelemente verknüpft werden, wobei sich bewährt hat, sie (nur) auf Funktionen oder Entitäten zu verbinden.
Verkettung R-F-L-P
Wie angedeutet ermöglicht das Systemmodell vielfältige Verknüpfungen. Um hier einen strukturierten Ansatz zu finden hat sich das R-F-L-P Konzept etabliert. Es verknüpft Anforderungen (R) mit Funktionen (F), diese wiederum mit Logischen Elementen (L), welche schließlich auf die physischen Elemente (P) verknüpft werden.
Der Aspekt Anforderungen ist grundsätzlich in das Konzept des Requirements Engineering zu integrieren. Daher sind Quellen für Anforderungen insb. die Umfeldanalyse sowie die Use-Case-Betrachtung. Auch Testfälle sind im Prinzip Bestandteil der Anforderungsbetrachtung. Anforderungen werden dann auf die Funktionen verknüpft, die diese umsetzen. Dabei ist der Umgang mit funktionalen Anforderungen recht intuitiv. Auch nicht-funktionale Anforderungen können teilweise auf Funktionen verknüpft werden, wenn sie bspw. die Performance einer Funktion präziseren. Im Fall anderer Anforderungen wie bspw. einer Farbe ist dies nicht unbedingt sinnvoll machbar. An dieser Stelle ist die Verknüpfung direkt auf ein Systemelement möglich.
Die Logische Beschreibung stellt eine Zwischenebene dar, zwischen der lösungsneutralen Definition von Funktionen und der konkreten Benennung eines Bauteils auf physischer Ebene. Sie bietet die Chance, Bauteile zusammenzufassen, die räumlich im System verteilt sind. Ebenso können Abhängigkeiten (in Form von Informations-, Energie- und Materialflüssen) zwischen den logischen Elementen analysiert werden. In einer frühen Projektphase werden logische Elemente eher im Sinne von Wirkprinzipien angelegt. Beispielsweise könnte eine Hubbewegung beabsichtigt sein, durch einen mechanischen Scherenhub oder einen pneumatischen getriebenen Zylinder realisiert werden könnte. Solche Konzeptentscheidungen würden das System maßgeblich verändern. Es gilt daher, eine entsprechende Analyse auf logischer Ebene zu machen. Mit fortschreitendem Projektverlauf wird das Wissen über die logischen Elemente präziser. Sie sollten soweit gepflegt werden, wir es für ein konsistentes Systemmodell notwendig ist. In einer solchen späteren Phase im Projekt dienen logische Elemente häufig auch der Moduldefinition. Wichtig ist, sie logische Elemente nur soweit herunterzubrechen, dass die modellierte Information für mehr als eine Disziplin relevant ist. Findet man sich in einer Situation wieder, in der man eigentlich nur noch Informationen modelliert, die nurnoch für eine Disziplin relevant ist, gehört das in die physische Ebene.
Die Definition der physischen Systemelemente erfolgt in der Regel im Bereich der CAD Werkzeuge und wird entsprechend durch PDM/PLM Werkzeuge organisiert. Das Systemmodell in iQUAVIS wird daher in der Regel auf ein solches Werkzeug verknüpft, auf Basis entsprechender Werkzeugintegrationen.
iQUAVIS ist ein leichtgewichtiges MBSE-Tool, mit dem Sie smart ins Systems Engineering einsteigen. Erfahren Sie hier mehr über iQUAVIS.
Systems Engineering ist eine Lebensart – wer sie einmal kennt, kommt nicht von ihr los! Ich brenne dafür, das Engineering zu verändern. Weg von verwirrenden Lasten- und Pflichtenheften hin zu einer modellbasierten Spezifikation. Das hilft mir, viele Aufgaben eines Projekts besser zu bewältigen, mit Kollegen ein gemeinsames eindeutiges Systemverständnis zu bilden und immer die relevanten Aufgaben im Blick zu haben. Und außerdem: Ich bin überzeugt, dass innovative Geschäftsmodelle nur mit einem solchen Ansatz möglich werden: Smarte Services, Things that think, … Let’s go together!
