Erfahrungswerte eines Embedded-Entwicklers Gründe, warum MBSE sein Potenzial nicht nutzt

Anbieter zum Thema

MicroConsult Academy GmbH

emlix GmbH

RTI Real-Time Innovations

Model-Based Systems Engineering (MBSE) ist als Buzzword branchenweit in aller Munde. Insbesondere größere Konzerne setzen zunehmend auf modellbasierte Entwicklung. Liegt hierin ein großer Zukunftstrend – oder ist es eine Modeerscheinung? Wo liegen die Potenziale und wo die Herausforderungen von MBSE?

Die Mitarbeiter eines Unternehmens haben viel zu tun, bis aus einer ursprünglichen Produktidee das fertige Resultat entsteht. Die Anstrengungen vieler unterschiedlicher Abteilungen müssen gebündelt werden, damit jedes Rädchen ineinandergreift und vermieden wird, dass „die linke Hand nicht weiß, was die rechte macht“.

Die fehlende Abstimmung zwischen Gewerken führt oft zu Missverständnissen. Nicht selten kommt es vor, dass im Projektverlauf Dinge widersprüchlich, doppelt oder gar nicht umgesetzt werden. Die Konsequenz: Entwicklungszeiten und die Fertigstellung von Produkten verlängern sich, wertvolle Ressourcen wie Zeit und Geld werden verschwendet.

Mit dem Systems Engineer ist eine Rolle gefunden worden, um alle Nahtstellen zwischen den beteiligten Abteilungen aufzuspüren und dann alle Wünsche zu erfassen und zu koordinieren. Anstelle von oft textbasierten Dokumenten aus unterschiedlichen Softwarewerkzeugen sollen mit MBSE (Model-Based Systems Engineering) komplexe Systeme mit einheitlichen formellen Modellen beschrieben werden. Heute wird hierfür auf UML basierend meist SysML verwendet. Das ist allerdings keine ultimative Allzweck-Lösung: Eine allumfassende Unternehmensmodellierung mit SysML z.B. ist sicher nicht sinnvoll, auch wenn der Gedanke, einen digitalen Zwilling von einem gesamten Unternehmen zu haben, reizvoll erscheinen mag.

MBSE wird vielmehr genau dann gewinnbringend eingesetzt, wenn ein Unternehmen damit herausfindet, welche Komponenten für unterschiedliche Produktgruppen als Gleichteile entwickelt und eingesetzt werden können. So wird vermieden, dass Dinge rein aufgrund von koordinatorischen Hürden doppelt entwickelt werden. Ziel sollte es immer sein, Verschwendung an Entwicklungsressourcen effektiv zu beenden und Entwicklereffizienz zu fördern.

Am allermeisten aber soll MBSE die Produkteigenschaften finden, die in der Entwicklung umgesetzt werden sollen. Es geht also eher um das Auffinden von Anforderungen und Lösungsansätzen. Leider lässt sich in der Praxis nur allzu häufig beobachten, dass die Arbeitsweise, das Vorgehen und das arbeitsorientierte Endprodukt von MBSE nicht in den Köpfen der Elektronik-Entwickler ankommt. Dafür gibt es einige Gründe:

Missverhältnis zwischen MBSE-Kompetenz und Kernkompetenz

Die Systemingenieure besitzen die Methoden- und die Toolkompetenz, wenn es um Modellbasierte Systementwicklung geht. Doch die technische, firmenspezifische Kernkompetenz liegt bei den alteingesessenen Entwicklern. Für eine sinnvolle Anwendung von Model-Based Systems Engineering müssten genau diese Entwickler eigentlich die entsprechenden Methoden sowie Tools für MBSE verwenden und die Historie dokumentieren.

Die Praxis zeigt: In der Regel wird kaum ein Entwickler zu einem Systemingenieur. Ein Entwickler ist in der Produktentwicklung oft unabkömmlich. Die jungen aufstrebenden Systemingenieure, welche die Methoden- und Werkzeugkompetenz besitzen, haben es schwer, neue Modelle zu erstellen, in denen das ganze Wissen der Vergangenheit wiederkehrt. MBSE funktioniert deswegen in der Erfahrung des Autoren meist nur sehr schwierig bei Bestands- oder Folgeprojekten. Technologische Paradigmenwechsel mit Hilfe von MBSE sind zwar prinzipiell möglich. Aber das richtige Mindset muss von Beginn an verankert sein, was bei alteingesessenen Entwicklerteams oft schwierig umzusetzen ist. In Innovationsprojekten, in denen „von der grünen Wiese“ aus gestartet werden kann. klappt das hingegen deutlich besser.

Entwicklungszweige laufen auseinander

Die Entwicklung der Modelle und der Software hat unterschiedliche Geschwindigkeiten. Somit laufen die Fortschritte dieser beiden Entwicklungszweige zwangsläufig auseinander. Das immer synchron zu halten, ist sehr schwer.

Kann dies nicht gehalten werden ist die Konsequenz, dass sich MBSE-Team und Software-Team entfremden. Effektiv arbeiten dann zwei Teams an zwei Entwicklungssträngen. Dann aber reden wir nicht mehr von Zusammenarbeit - das Entwicklerteam verfolgt dann effektiv wieder wie gehabt seine eigene Vorgehensweise, und die Arbeitsprodukte vom MBSE kommen in den Köpfen der Entwickler nicht an. Die Arbeit des System Engineers war denn effektiv vergebens.

Methoden- und Toolevolution

Die Methoden und Tools entwickeln sich immer weiter. Während sie auf der Programmiererseite seit Jahren nur kleinen Änderungen unterliegen, sind die Methoden und Tools ständig im Fluss. Ein Beispiel: Es steht schon seit längerem fest, dass SysML 2.0 kommen wird – aber es ist noch nicht klar, ob es ebenfalls UML basieren wird oder nicht.

Wenn eine neue Version kommt, und noch dazu auf einer anderen Basis aufsetzt: Was passiert dann mit den alten Modellen? Gibt es Migrationsstrategien?

Ist ein Entwickler nicht bereits mit MBSE vertraut, wird von ihm eine Menge verlangt: Er muss Entwicklungs-Methoden und Werkzeuge beherrschen und zusätzlich mit der Evolution der MBSE-Bordmittel schritthalten. Das ist zusätzlicher Aufwand, der ihn jedoch bei der Entwicklungsarbeit behindert.

Interoperabilität der eingesetzten Werkzeuge

Es ist schön, wenn eine Produkteigenschaft, die als Anforderung ermittelt wurde, auch am Ende umgesetzt wird. Leider ist die Kette der Entwicklungswerkzeuge vom Modell über die Anforderungswerkzeuge und Entwicklungswerkzeuge bis zur Testumgebung in der Praxis meist nicht einheitlich.

Zwischen den Werkzeugen gibt es idealerweise eine Interoperabilität und Nachverfolgbarkeit (Traceability). Meist existiert das leider nur in Form von Export- und Importfunktionen oder, schlimmer noch, es müssen Daten manuell aus dem einen Tool in ein anderes überführt werden. Das Fehlerpotenzial ist hier sehr hoch und verzögert die Entwicklung.

Wahrnehmung von MBSE als Umweg

Durch MBSE verlängert sich die Entwicklungskette. Vor dem Programmieren wird zunächst ein Modell erstellt. Aus diesem heraus werden dann Softwarekomponenten identifiziert und in die Softwarearchitektur eingepasst. Oft sind die Modelle nur eine Teilmenge der gesamten Funktionalität. Für den Entwickler bedeutet das in solchen Fällen, dass er Teile der Software mit und Teile der Software ohne MBSE entwickelt.

Erst wenn der Zeitpunkt der Implementierung gekommen ist kann dann der Software-Entwickler feststellen, ob das Modell, das er übernimmt, auch wirklich in seine Vorstellung passt und in seiner Umgebung funktioniert. Viele MBSE-Ansätze erlauben es leider nicht, die Funktion der Modelle zu testen. Ob ein Modell richtig funktioniert, kann erst nach der Integration festgestellt werden. Sollten dann Fehler auftreten, was zu erwarten ist, muss zunächst das Modell angepasst werden. Dann erfolgt eine neue Integration und der Zyklus beginnt von vorn. Ist diese Schleife tatsächlich erforderlich für einen schnellen Entwicklungsverlauf, oder handelt es sich um Zusatzaufwand?

Ein Programmierer kann prinzipiell direkt aus den Anforderungen Code erzeugen. Wenn er seine Arbeit gut macht, ist dieser auch lesbar wie ein Buch. Warum, denkt sich dann so mancher Software-Entwickler, ist dann eine weitere Beschreibung notwendig – erzeugt das nicht Mehraufwand?

Das gravierendste Problem ist, dass Entwickler MBSE meist als einen Umweg betrachten. Sie sind es gewohnt, Requirements – ob klassisch oder agil – direkt umzusetzen und sofort testen zu können, ob die Produkteigenschaft erfüllt ist. Warum also zunächst eine andere Beschreibungsform wählen?

Dieser Eindruck verstärkt sich umso mehr, wenn man wie oben beschrieben bedenkt, dass zudem Tool- und Grundlagen-Versionen wie UML 1.0, 2.0 oder 2.5.1 sich ändern oder immer umfangreicher werden.

Budget und Personalfragen

Modellbasiertes System-Engineering einzuführen kostet erst einmal Geld – und gute MBSE-Experten haben ebenfalls ihren Preis. Das Verhältnis MBSE-Experte im Vergleich zum Rest des Teams ist aus Unternehmenssicht häufig ungünstig. Der Wunsch, gerade zu Projektbeginn Kosten zu sparen, ist dabei immer groß. Das führt dazu, dass die Zahl der Tools oder am Projekt beteiligten MBSE-Experten gerne möglichst klein gehalten wird.

Gibt es aber nur einen oder wenige MBSE-Experten im Team und die Aufgabe ist umfangreich, reicht dieser Personalbestand nicht aus, um schnell Modelle zu entwickeln oder schnell auf Änderungen zu reagieren. Wenn also an dieser Stelle gespart wird, dann kann Modellbasiertes System-Engineering auch nicht erfolgreich zum Projekterfolg beitragen.

Was könnte MBSE besser machen?

Mit Blick auf die verschiedenen Aspekte lässt sich folgendes Fazit ziehen: Die Entwickler benötigen für die Programmierung eine gute und strukturierte Vorarbeit. Meist müssen sie diese selbst leisten.

Es wäre wünschenswert, wenn es Dokumente und Modelle gibt, welche die Produkteigenschaften mit guter Richtigkeit und Vollständigkeit beschreiben, so dass der Softwareentwickler ohne viel Nachfragen seine Programmieraufgaben erledigt. Auch der Tester ist in der Lage, eine ebenso richtige und vollständige Testspezifikation zu erstellen und mit einer guten Testtiefe zu testen.

In der Vergangenheit gab es der Serienentwicklung vorgeschaltet eine Forschungs- und Entwicklungsabteilung und eine Vorentwicklung. Dort wurde gute Vorarbeit geleistet. Der Entwickler konnte von den Erfahrungen profitieren und die Entwicklung des Endproduktes funktionierte zufriedenstellend bis gut. Dieser Gedanke sollte auch auf Modellbasiertes System-Engineering angewandt werden, um von Beginn an Komplexität und Zusammenhänge im Blick zu halten. Vielversprechend wären daher heute MBSE, die vorgelagert als F&E mit Vorentwicklung fungieren würden.

Basics

Grundlagen des Modellbasierten System-Engineering (MBSE)

* Thomas Lachtrup ist Geschäftsführer der digithings GmbH, Anbieter für Embedded Hardware- und Softwareentwicklung. Sein Unternehmen hat es sich auf die Fahne geschrieben, selbst in Stocken geratene und finanziell kostspielige Projekte zügig und erfolgreich abzuschließen. „Wir haben aus den oben geschilderten Erfahrungswerten gelernt und verzichten mittlerweile auf MBSE.“

Als Erfolgsfaktor für die digithings GmbH schreibt er dem Wirtschaftsstandort Paderborn besondere Bedeutung zu, welcher mit über 300 IT-Unternehmen ideale Bedingungen für technologische Innovationen bietet. Die Kombination aus Tradition und Innovation, die Unterstützung durch lokale Institutionen und die enge Zusammenarbeit mit wissenschaftlichen Einrichtungen schaffen ein Umfeld, in dem Unternehmen wie die digithings GmbH florieren können. „Wir sind stolz darauf, Teil dieser dynamischen und zukunftsorientierten Region zu sein“, betont Lachtrup.

(sg)

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

(ID:50370596)