Model Based Systems Engineering: So führen Sie MBSE erfolgreich ein

hartmut.schorrig

					[url=/model-based-systems-engineering-so-fuehren-sie-mbse-erfolgreich-ein-a-818061/][b]Model Based Systems Engineering: So führen Sie MBSE erfolgreich ein[/b][/url]


					Wenn es um die Einführung modellbasierten Systemdesigns geht, scheinen Unternehmen manchmal etwas blauäugig vorzugehen: Tool kaufen, Mitarbeiter schulen, fertig. So einfach ist die Sache nicht. Wer nicht bedacht an MBSE herangeht, beraubt die Systemmodellierung um einige ihrer stärksten Eigenschaften

					[url=/model-based-systems-engineering-so-fuehren-sie-mbse-erfolgreich-ein-a-818061/]zum Artikel[/url]

hartmut.schorrig

					[url=/model-based-systems-engineering-so-fuehren-sie-mbse-erfolgreich-ein-a-818061/][b]Model Based Systems Engineering: So führen Sie MBSE erfolgreich ein[/b][/url]


					Wenn es um die Einführung modellbasierten Systemdesigns geht, scheinen Unternehmen manchmal etwas blauäugig vorzugehen: Tool kaufen, Mitarbeiter schulen, fertig. So einfach ist die Sache nicht. Wer nicht bedacht an MBSE herangeht, beraubt die Systemmodellierung um einige ihrer stärksten Eigenschaften

					[url=/model-based-systems-engineering-so-fuehren-sie-mbse-erfolgreich-ein-a-818061/]zum Artikel[/url]

hartmut.schorrig

Zwei Anmerkungen:

Neben der UML gibt es auch die Function-Block orientierte Grafische Programmierung, die mit Tools wie Simulink oder Modelica ausgeführt wird. Diese würde ich auch deutlich als MBSE bezeichnen. Allerdings liegt bei FBlock-Grafiken der Schwerpunkt nicht auf Traceability wie bei UML. Der Artikel zeigt deutlich, dass dies wichtig ist. Ich bin im Moment sehr aktiv dabei, diese beiden MBSE-Herangehensweisen zu vereinigen zu wollen, es ist notwendig. Die FBlock-MBSE ist genaugenommen älter als die UML, weit verbreitet aber wenig standardisiert. Jeder Toolhersteller macht für sich. Hier ist einiges an Entwicklung noch zu leisten. Ich bin dabei.
Es wird sehr oft davon geredet, dass unsere heutige Welt so komplex ist. Dazu brauchen wir noch komplexere Tools. Ich sage: Die Komplexität wird dahergeredet. Tools müssen dazu dienen, um Dinge darzustellen, damit man sie durchschaut, ihnen damit die Komplexität nimmt. Grafiken zuerst, Tabellen sind auch überschaubar. Außerdem muss die Überschaubarkeit nicht nur für den Experten da sein, sondern die anderen Nutzer der Software, Endkunden vielleicht auch, Vertriebler, Prüfer der Zulassung, Fachleute beim Kunden, Piloten in Flugzeugen, müssen mindestens als Überblick wissen, was in der Software drinnen ist. Der Black-Box-Gedanke ist alt und gut. Nach außen bekannte Sachen müssen nicht noch detailliert werden, das wird zuviel. Aber die oberen Modellebenen sollten schon durchschaubar sein für die eben genannten Personengruppen. Damit diese mitreden und mitdenken können.
Dr. Hartmut Schorrig

Ein Modell ist immer eine Vereinfachung des ihm zugrunde liegenden Gegenstands der Betrachtung. Leider vergißt das ein Großteil der Leute, die MBSE für sich entdecken.
Wäre cool, wenn Hersteller von MagicDraw oder EA dass mal in ihre Start-Splashscreens aufnehmen würden, damit es sich einprägt.

Reales Beispiel: für eine Software-Einheit soll ein Modell erstellt werden. Es tauchen Dinge auf, wie die Electrical oder Mechanical View. Auf Rückfrage bei den Auskennern wird einem gesagt, dass sei das Modell schlechthin, man macht ja auch ordentliches Systems Engineering, schließlich sei man INCOSE zeritifziert und wüßte, was man tut. Dass dort Perspektiven und Strukturen aufgezwungen werden, die über den gesamten Lifecylce nie mit Inhalten gefüllt werden, schien nur von nachgeordnetem Interesse zu sein - Prinzipienreiterei im Elfenbeinturm.

Auch dass Model Based Anything einen Paradigmentwechsel von der auf Dokumenten basierter Kommunikation zwischen Ingenieuren, PMs, Kunden usw. darsteltt, wird in der Euphorie vergessen.
MBSE ist so recht kein Silver Bullet: wenn die Stakeholder nicht alle ein Mindestmaß an MBSE-Verständnis in einer Organisation oder einem Projekt mitbringen, dann taugt es als Kommmunikationsmittel nicht.
Auch die das Req Eng mit MBSE ist per se nicht besser als das geschriebene Wort. Wenn ich bedenke, wie viele Fehler bei der Definition von Anforderungen in natürlicher Sprache gemacht werden, dann hege ich große Zweifel, dass es mit einer Abstraktion im Model zwangsläufig besser ginge.

@Dr. Hartmut Schörring
Modellierung gibt es natürlich nicht erst seit der SysML. Ich gehe mal davon aus, dass die Ägypter schon exzessiv Modelle eingesetzt haben. Und sicherlich gehören Function-Block orientierte Lösungen wie die genannten zu den Wegbereitern des von MBSE. Genauso wie xCAD Lösungen und zahlreiche weitere diziplin- und brachchenspezifische Modellierungsumgebungen – häufig mit der Fähigkeit Modelle zu Ausführung zu bringen und dynamische Aspekte zu analysieren. Das geht grundsätzlich auch mit einschlägigen UML/SysML Authoring-Tools. Die Stärke liegt dabei aber sicher eher bei der statischen Betrachtung und diskretem Verhalten. Auch wenn einige SysML/UML Tools mit Gleichungslösern und Simulationsfähigkeiten daherkommen, kontinuierliches Verhalten lässt sich heute sicher besser mit Simulink und Modelica abbilden. Leider alles proprietär und aus meiner Sicht vorwiegend nur Experten zugänglich.

Hier kommen meines Erachtens die Stärken von UML/SysML zum Tragen. Es ist standardisiert und wenn man sich ein wenig Mühe gibt, kann man Modellsichten (Diagramme, Tabellen, ICDs) erstellen, die auch Nicht-Experten zugänglich sind. Es adressiert die Systemebene vom Stakeholder über die Anforderungen bis runter zur Schnittstellendefinition. Da ist UML/SysML zuhause. Wenn es in die Disziplin geht ist man mit FB oder xCAD häufig besser bedient. Dahin muss man eine Brücke schalgen. Neben den Möglichkeiten aus UML/SysML Links in disziplinspezifische Modelle zu erstellen gibt es mittlerweile einige interessante Tools, die einen Layer über all diese Modelltypen legen und die Verlinkung herstellen. Mit Standards wie OSLC rückt auch der wünschenswerte Single-Point-of-Truth in greifbare Nähe.

Was das Thema Komplexität angeht gibt es mehrere Aspekte. Es gibt Tools, die machen durch ihr Bedienkonzept aus einfachen Modellierungsaufgaben komplizierte Arbeitsabläufe. Andere weisen nicht auf den fehlerhaften Gebrauch der Sprache hin oder zeigen unplausible Sichten auf das Modell. Das trägt nicht zur Verständlichkeit bei. Ein wichtiger Punkt ist aber auch, dass insbesondere Diagramme häufig überfrachtet werden. Im Modellierungstunnel wird gern der Leser des Diagramms vergessen. Gute Diagramme adressieren ihre Leserschaft und zeigen nur die Teile des Modells die relevant sind.

Wenn man den Blick Richtung SysML2 wirft könnte, so meine Hoffnung, so mache proprietäre Modellierungssprache ersetzt werden, ohne deren Fähigkeiten zu verlieren. Vielleicht kommen wir in einigen Jahren dahin, dass ein Authoring-Tool egal ob es Modelica, MagicDraw oder Catia heißt immer die Funktion „Save as XMI“ besitzt.

Bernd Busam

Die beste Modellierungssprache, mit dem smartesten Tool und der ausgefeiltesten Methode helfen nicht wenn schlechtest Systems Engineering betrieben wird. Leider wird in vielen Projekten der Erhebung, Bewertung, Validierung, Abstimmung, etc. von Anforderungen zu wenig Raum eingeräumt. Anforderungen kann man schließlich nicht anfassen, ausliefern und fakturieren. Es soll jedoch vorkommen, dass gute Anforderungen helfen das Richtige zu implementieren und Kunden zufriedenzustellen.

So verhält es sich auch mit modellbasiertem Systems Engineering. Schlechtes SE wird nicht besserm wenn man es mit Modellen tut. Wenn wichtige Stakeholder das Modell oder Sichten daurauf nicht mehr verstehen, dann hat man das Ziel die Kommunikation zu verbessern und zweifelsfreier zu gestalten definitv verfehlt. Das ist dann ein guter Moment den Elfenbeinturm herab oder auch hinauf zu kommen. Gute System Engieers treffen sich jedoch regelmäßig in der Mitte.