Auf der Jagd nach einer einzigen Quelle der Wahrheit

Modellbasierte Systemtechnik von Jon Holt
Auf der letztjährigen Sysarch-Konferenz sprach Jon Holt, Experte für modellbasierte Systemtechnik, mit Ger Schoeber vom High Tech Institute über die MBSE-Ausbildung. „In fünf Jahren wird die gesamte Systemtechnik modellbasiert sein“, so Holt, der derzeit technischer Direktor von Incose UK ist.

 

Mit seinem schwarzen Outfit ist Jon Holt eher als Magier denn als Systemingenieur zu erkennen. Eigentlich ist er beides.

Lassen Sie uns mit der Magie beginnen. Das ist das Zeug, das er benutzt, um zu inspirieren. Als professioneller Magier tritt er auf Musikfestivals und verschiedenen Wissenschafts- und Technologieveranstaltungen auf und nutzt Magie, Gedankenlesen und manchmal auch Entfesselungskunst, um technische Prinzipien zu erklären. „Wir machen Dinge, die auf Mathematik, Wissenschaft und Gedächtnistechniken beruhen. Ich versuche zum Beispiel, den Leuten zu erklären, wie wichtig Visualisierung als Designkonzept ist.“ Er lächelt: „Es gibt auch einen egoistischen Aspekt. Ich genieße es auch. Geben Sie mir eine Gelegenheit, mich zu zeigen, und ich ergreife sie.“

Jon Holt - Trainer für modellbasierte Systemtechnik
Jon Holt: „Geben Sie mir eine Gelegenheit, mich zu zeigen, und ich werde sie ergreifen.“

Holt hat auch ein gereimtes Bilderbuch über Systemtechnik geschrieben, das sich an Kinder im Alter von sieben bis elf Jahren richtet. Als technischer Direktor des International Council on Systems Engineering (Incose) in Großbritannien setzt er sich gemeinsam mit Berufsverbänden für die Sensibilisierung von Familien mit Kindern ein. „Es ist wichtig, dass wir nicht nur darüber nachdenken, wo wir stehen, sondern auch über die nächste Generation aller Ingenieure.

Holt stößt auf viele Missverständnisse über das Ingenieurwesen. „Der Begriff wird sehr schlecht verstanden. Viele Leute denken immer noch, dass ich Dinge repariere, die kaputt sind. Nun, das stimmt nicht ganz. Ingenieurwesen wird als langweilig oder uninteressant angesehen. Für mich könnte das nicht weiter von der Wahrheit entfernt sein. Sehen Sie sich die unglaublichen Systeme an, an denen wir arbeiten. Kinder können nicht mehr von ihren Handys getrennt werden. Ich möchte die Menschen dazu bringen, die Technik in diesem Telefon zu schätzen.“

Incose hat Holt als einen der 25 einflussreichsten Systemingenieure der letzten 25 Jahre bezeichnet. Er ist ein international anerkannter Experte auf dem Gebiet der modellbasierten Systemtechnik (MBSE) und hat 17 Bücher zu diesem Thema verfasst. Außerdem ist er Professor für Systems Engineering an der Cranfield University.

'In five years, all systems engineering will be model based.'

In Holts Karriere hat MBSE eine zentrale Rolle gespielt. Auf der letztjährigen Bits&Chips Sysarch Konferenz in Eindhoven erklärte er, dass im Jahr 2025 die gesamte Systemtechnik modellbasiert sein wird. „Wenn Sie 10 Jahre und länger zurückgehen, habe ich meine ganze Zeit damit verbracht, mit Leuten darüber zu streiten, ob Modellierung eine gute Idee ist. Auf Konferenzen haben die Leute mit Dingen nach mir geworfen, weil sie nicht modellieren wollten“, erinnert er sich. Aber das hat sich geändert. „Jetzt lautet die Frage nicht mehr: Sollten wir modellieren? Sondern: Wie können wir effektiv und effizient modellieren?“

Holt sieht den Wandel in seiner Arbeit mit großen multinationalen Unternehmen, die zwanzig Jahre lange Produktlebenszyklen haben. „Sie wollen diese Zyklen verkürzen. Natürlich geht es dabei auch um Qualität, aber der Hauptgrund für den Einsatz von MBSE ist die Verbesserung der Effizienz ihrer Prozesse. Auch die menschliche Seite der Dinge kommt ins Spiel. Die Unternehmen wollen sicherstellen, dass ihre Mitarbeiter über die entsprechenden Fähigkeiten verfügen und wenden MBSE darauf an.

Vier Veränderungen in der Komplexität

Um die Komplexität zu erklären, vergleicht Jon Holt den alten Triumph Herald, den er in den siebziger Jahren besaß, mit seinem neuesten Auto. „Das Grundbedürfnis ist immer noch, von A nach B zu kommen, die Schnittstelle zwischen Mensch und Maschine ist immer noch ein Lenkrad, eine Gangschaltung und drei Pedale. Aber die Komplexität dieser Systeme hat sich in den letzten Jahrzehnten verändert.“ Er beschreibt den Wandel auf vier spezifische Arten.
„Die erste Art, wie sich das System verändert hat, hat mit den Systemelementen zu tun. Sie waren zu 95 Prozent mechanisch. Wahrscheinlich waren etwas weniger als 5 Prozent elektrisch. Was die Schnittstellen anbelangt, so hatte die Triumph mechanische Schnittstellen und elektrische zu mechanischen. Nur sehr wenige waren elektrische Schnittstellen. Jetzt haben wir auch noch Elektrik und Software. Mit diesen Elementen kommen Vernetzung und Kommunikationsprotokolle. Wir haben eine viel größere Komplexität.“
Als nächstes kommen die Einschränkungen. „Die einzigen Sicherheitsvorkehrungen im alten Auto waren die Sicherheitsgurte vorne, und man musste sie nicht einmal anlegen – das war optional. Auf den Rücksitzen gab es keine Sicherheitsgurte. Was den Aufprallschutz anbelangt, so war das Auto aus sehr dickem Metall gefertigt. Man musste nur darauf achten, dass es dicker war als das, worauf man aufprallen würde. Das war die Sicherheit in den 60er und 70er Jahren. Heute würden Sie nicht mehr in ein Auto steigen, ohne Sicherheitsgurte anzulegen. Ein modernes Fahrzeug verfügt über Airbags und Antiblockiersystem und verhindert, dass Sie mit etwas anderem zusammenstoßen oder auf eine andere Fahrspur ausweichen. Die Komplexität hat zugenommen. Nicht nur wegen der Zwänge, sondern auch wegen der Quelle all dieser Zwänge wie Normen und Gesetze. All diese Best-Practice-Modelle gab es in den 70er Jahren noch nicht.“
Der dritte Punkt ist die Konnektivität. „In meinem Triumph war ich die wichtigste Verbindung zur Außenwelt. Jetzt ist das Auto tatsächlich Teil eines größeren Systems von Systemen. Es verbindet sich mit der Cloud, mit Straßenschildern, mit dem britischen und europäischen Straßennetz und kommuniziert mit anderen Autos. Das bringt eine ganz neue Ebene von Schnittstellen mit sich. Ich habe eine App, die mir jederzeit sagt, wo sich mein Elektroroller befindet.“
Die vierte Welle ist die Veränderung der Komplexität. „In meinem alten Auto lag die Komplexität im Verbrennungsmotor. Die Komplexität hat sich auf die Software verlagert. Die mechanische Komplexität eines Motors in einem modernen Elektrofahrzeug ist sehr, sehr gering, während die Softwarekomplexität sehr, sehr hoch ist. Die Software übernimmt die gesamte Steuerung und kümmert sich um die Konnektivität. In den letzten Jahrzehnten hat die Komplexität bis zur Unkenntlichkeit zugenommen.“

Ingenieure vernetzen

Abgesehen davon könnte das Arbeitsmodell auch der Schlüssel sein, um Ingenieure zu verbinden. Hier sprechen wir über die Ambitionen von Ger Schoeber, dem Vorsitzenden von Incose Niederlande, den wir zu einem Interview eingeladen haben. Schoeber ist seit kurzem bei Lightyear als Group Lead Systems Engineering tätig. Er ist außerdem für die System- und Softwareschulung am High Tech Institute verantwortlich. In den vergangenen Jahren hat er als Vorsitzender von Incose daran gearbeitet, die Kluft zwischen den technischen Welten der Infrastruktur und der Hochtechnologie zu überbrücken.

Schoeber malt diese beiden sehr unterschiedlichen Welten schwarz auf weiß: „Ingenieure in öffentlichen Projekten haben mit Auftragnehmern, Subunternehmern und Verträgen zu tun. Ihr Schwerpunkt liegt auf Papierkram und Prozessen, das System ist zweitrangig.“ Auf der anderen Seite ist die High-Tech-Industrie kommerziell ausgerichtet. „Dort liegt der Schwerpunkt auf der Zeit bis zur Markteinführung. Andernfalls können sie nicht konkurrieren und werden sicherlich nicht die Welt erobern. Deshalb ist der Ansatz pragmatisch und konzentriert sich auf das System, das Produkt.“

Schoeber hat seine Wurzeln in der High-Tech-Branche, aber als Vorsitzender von Incose stellt er fest, dass die Mitglieder der niederländischen Sektion typischerweise in Infrastrukturprojekten arbeiten, beim Bau von Eisenbahnen, Straßen und Tunnelsystemen. „Wir haben eine große High-Tech-Industrie, aber nicht viele Ingenieure kennen Incose.“ Die Chance, so Schoeber: „Ich bin sicher, dass beide Welten eine Menge voneinander lernen können.“

Eine einzige Quelle der Wahrheit

MBSE ist ein gemeinsamer Nenner, sind sich Schoeber und Holt einig. Es kann Hightech helfen, noch bessere Produkte herzustellen. Die Techniken, die Hightech- und Bauingenieure anwenden, um Systeme zu entwickeln und erfolgreich zu liefern, müssen verbessert werden, um den zusätzlichen Anforderungen und der Komplexität gerecht zu werden. Die häufigste Methode ist die Anwendung modellbasierter Techniken. Holt drückt es in einfachen Worten aus: „Traditionell hat sich das Ingenieurwesen sehr stark auf Dokumente verlassen. Für das Design, für das Verständnis der Anforderungen und so weiter. Das hat viele Jahrzehnte lang sehr gut funktioniert. Ein absolut guter, solider Ansatz. Aber wenn die Komplexität zunimmt und all das Wissen, die Daten und die Informationen, die mit einem System verbunden sind, auf mehrere Dokumente verteilt sind – und wir sprechen hier von Tausenden – dann ist es sehr, sehr komplex, die Konsistenz zu wahren.“

Ger Schoeber: „Das Wichtigste ist nicht das Modell, sondern die Anwendung des gesunden Menschenverstands.

Bei einem modellbasierten Ansatz werden alle für das System relevanten Kenntnisse und Informationen an einem Ort aufbewahrt und konsistent gehalten. „Auf diese Weise haben wir das, was oft als eine einzige Quelle der Wahrheit bezeichnet wird“, sagt Holt. „Wir können diese einzige Quelle pflegen, und wenn das richtig gemacht wird, garantiert das, dass die Dokumente, die auf dieser einzigen Wahrheitsquelle basieren, konsistent sind. Anstatt also alles über Tausende von verschiedenen Dokumenten zu verteilen, führen wir alles in einer einzigen Wahrheitsquelle zusammen. Für alles, was wir über das System wissen wollen, fragen wir das Modell ab. Das ist der Ort, an dem sich die Informationen befinden.

Ausführlich: „Die Leute sagen: ein Modell kann nie vollständig sein. Nun, das muss es auch nicht sein. Es muss so vollständig sein wie nötig, um unser System zu liefern. Es kann niemals alle Informationen des Systems enthalten. Es muss Dinge geben, die fehlen, aber das bedeutet nicht, dass es falsch ist. Wir konzentrieren uns auf die relevanten Informationen, um das System zu entwickeln. Es muss nützlich sein und uns bei unserer Arbeit helfen. Wenn das nicht der Fall ist, dann vergessen Sie es.“

Brontosaurus der Komplexität

Um die Auswirkungen der Komplexität auf die Systemtechnik zu erklären, verwendet Jon Holt das Problem der Brontosaurus-Theorie. Diese Theorie ist eine Analogie, die besagt, dass Ausmaß und Komplexität direkt proportional zur Dicke des Tieres sind. „Zu Beginn eines Projekts blicken Sie in das lächelnde Gesicht des Brontosaurus“, stellt Holt klar. „Die Komplexität ist gering, er ist zu diesem Zeitpunkt dünn. Sie sehen sich Ihre Anforderungen an und denken: Ja, das macht Sinn. Sie lächeln, weil es einfach ist, und der Brontosaurus lächelt Ihnen zu. Sie leben in einer sehr glücklichen, wenn auch etwas naiven Welt.“
Aber dann kommen die Systemingenieure mit ihren Kosten-, Zeit- und Ressourcenschätzungen ins Spiel. Sie fangen an, ihre Prinzipien der Systemtechnik anzuwenden. „Sie beginnen mit der Modellierung, der Identifizierung von Stakeholdern, der Erstellung von Szenarien und während sie sich in den Nacken des Brontosaurus begeben, nimmt die Komplexität zu. Wenn Ihnen jemand Diagramme zeigt, die so groß wie eine Wand sind, wissen Sie, dass Sie im Bauch des Brontosaurus angekommen sind. Denn obwohl das Diagramm sehr clever ist, kann es niemand verstehen. Und Sie haben Leute, die alle möglichen unterschiedlichen Methoden und Tools verwenden. Oder noch schlimmer, sie verwenden dasselbe Tool, aber leicht unterschiedliche Versionen, die nicht im Entferntesten miteinander kompatibel sind.“ Holt, aus seiner Erfahrung heraus: „Alle Auftragnehmer gehen an diesem Punkt. Das Leben wird ein bisschen zu kompliziert für sie. Es sieht aus, als wäre es das Ende der Welt.“
Aber es gibt eine Lösung. „Das Problem ist komplex. Es ist schwer zu verstehen und fast unmöglich, es all den verschiedenen Interessengruppen zu vermitteln. Es ist sehr frustrierend, denn als Systemingenieur sagt man sich: Moment mal, ich habe das alles richtig gemacht, ich habe diese Prinzipien angewandt, und doch befinde ich mich im Bauch des Brontosaurus.“ Dann passiert etwas Interessantes, sagt Holt. „Denn wenn Sie Ihre Techniken weiter anwenden, wird die Komplexität immer geringer, bis zum Schwanz des Brontosaurus – und das ist unser Ziel. Und am Schwanz des Brontosaurus haben Sie eine prägnante, elegante Lösung.“

'As soon as you start to apply systems engineering and modeling, it gets more complex before it’s going to result in an optimal solution.'

Holts Botschaft: Wenn Sie ein reales Problem betrachten, wird es komplexer, sobald Sie beginnen, Systemtechnik und Modellierung anzuwenden, bevor es zu einer optimalen Lösung führen wird.

Das Modell und seine Ansichten

Die grundlegende Funktion eines Modells im MBSE ist die Kommunikation. Es muss den Systemingenieur in die Lage versetzen, das in der Entwicklung befindliche System mit allen Beteiligten zu besprechen, mit der Finanzabteilung, dem Kunden, dem Chef, dem Ingenieurteam oder einer Normungsorganisation, die prüfen will, ob das System allen Sicherheitsvorschriften entspricht.

Für all diese verschiedenen Akteure gibt es sogenannte „Ansichten“ (des Modells). Sie sind die Grundeinheiten eines Modells. Jede von ihnen ist eine Sammlung von Informationen mit allen Informationen, die ein bestimmter Interessenvertreter über das zu entwickelnde System wissen muss. Holt: „Zunächst einmal muss es eine gültige Ansicht sein. Wenn Sie keinen Ihrer Stakeholder identifizieren können, der daran interessiert wäre, sich das anzusehen, dann lassen Sie es bleiben.“ Zweitens sollte der Stakeholder einen Nutzen aus der Betrachtung dieser speziellen Sichtweise ziehen. „Wenn Sie diese Frage nicht beantworten können, ist sie nicht relevant. Es ist keine Ansicht.“

„Wenn Sie sich das Modell als einen großen amorphen Informationsklumpen vorstellen, ist jede Ansicht wie das Öffnen eines winzigen Fensters in diesem Modell“, fährt Holt fort. „Wir müssen sicherstellen, dass wir genügend dieser Fenster öffnen, damit wir das Modell als Ganzes verstehen können. Wegen der vielen Beteiligten müssen wir sicherstellen, dass alle Ansichten konsistent sind. Sonst ist es kein Modell.“ Er verwendet SysML als Modellierungssprache, aber im Grunde können Sie jede Sprache verwenden. Es geht nur darum, es richtig zu machen, damit am Ende ein konsistentes Modell herauskommt.

Holt verwendet zum Beispiel Modelle als Grundlage für den Vertrag. „Wenn Unternehmen in verschiedenen Sektoren wie der Luft- und Raumfahrt, der Energiewirtschaft oder der Nuklearindustrie eine Ausschreibung machen, geben sie ihre Spezifikationen für die eingehenden Angebote bekannt. Was sie tatsächlich tun, ist, eine Reihe von Ansichten zu veröffentlichen, die sie als technischen Teil ihres Angebots einreichen.“

Die Vorteile liegen auf der Hand: „Das Modell wird Teil des Vertrags. Wenn vier Leute für die Ausschreibungen bieten, haben sie Angebote für dieselben Ansichten erstellt. Für den Kunden ist es viel einfacher, sie zu vergleichen als beispielsweise textbasierte Beschreibungen. Ein weiterer Vorteil besteht darin, dass der Satz von Ansichten – das eingereichte Modell – dann tatsächlich zu einem Vertrag wird. Die Auftragnehmer müssen klare Informationen liefern.“

Die hochrangigen Ansichten auf der konzeptionellen Ebene werden später fast so etwas wie die Akzeptanzkriterien für das, was geliefert wird. „Dies kann sowohl auf die Infrastruktur als auch auf die High-Tech- und kommerziellen Industrien angewendet werden.

Schoeber weist darauf hin, dass der Systemarchitekt oder Systemingenieur eine wichtige Rolle als Übersetzer der SysML-Ansichten für Beteiligte ohne technischen Hintergrund spielt.

Appetit

Die Automobilindustrie ist ein gutes Beispiel für eine Branche, die großen Appetit auf MBSE entwickelt hat, sagt Holt. „Es begann vor fünf Jahren. Die Komplexität hat sich im Laufe der Zeit verändert. Vergleichen Sie ein altes Auto von vor 30, 40 Jahren mit einem modernen Auto und sehen Sie sich die Komplexität der Systemelemente, die Konnektivität oder die Sicherheitsauflagen an. Wir sehen, dass sich die Komplexität bis zur Unkenntlichkeit verändert hat. Die Techniken, die wir vor zwanzig Jahren auf ein vermeintlich modernes Auto anwenden konnten, sind heute einfach nicht mehr gut genug. Sie sind nicht rigoros genug, um auf ein modernes Fahrzeug anzuwenden, das Teil eines umfassenderen Systems von Systemen ist. MBSE verschafft der Automobilindustrie einen Wettbewerbsvorteil. Wenn sie es nicht anwenden, werden ihre Konkurrenten bessere und zuverlässigere Produkte herstellen.“

Wo soll man mit MBSE anfangen? Holt weist darauf hin, dass es wichtig ist, die Frage nach dem Warum zu beantworten. „Wenn Sie diese Frage nicht beantworten können, sollten Sie die Arbeit nicht machen. Es kommt auf den Kontext an. Sie müssen sich fragen, was Sie eigentlich verbessern wollen? Was ist es, das Sie überhaupt erreichen wollen? Das kann alle möglichen Schwerpunkte haben, etwas Kommerzielles oder Dinge wie Qualitätsmerkmale, ein besseres Produkt, das sicherer, zuverlässiger und wartungsfreundlicher ist. Oder nehmen Sie die Sicherheit. Man kann ein Auto stehlen, indem man ein Mobiltelefon benutzt, das ist verrückt. Die Forderung, dies zu verhindern, gab es vor fünf oder zehn Jahren noch nicht. Jetzt wird es zu einer Standardanforderung der Kunden. Es gibt noch keine 100 Prozent autonomen Fahrzeuge, aber wir haben Fahrerassistenzsysteme, Kommunikation mit Straßenschildern und Kollisionsvermeidung, um zu verhindern, dass wir zwischen den Fahrspuren abdriften. Das sind Standardfunktionen, keine optionalen Extras in einem modernen Auto.“

Heiliger Gral?

Besteht die Gefahr, dass MBSE zu sehr als heiliger Gral betrachtet wird? Schoeber: „Was mich ein wenig beunruhigt, ist, dass wir MBSE und all den Tools, die damit einhergehen, zu sehr vertrauen. Man muss aufpassen, dass man seinen gesunden Menschenverstand nicht verliert.“ Holt teilt die Besorgnis von Schoeber: „Kritisch zu denken und Dinge zu hinterfragen ist eine der Fähigkeiten des Systemingenieurs. Wir müssen immer wieder nach dem Warum fragen. Das kann man nicht umgehen.“

Es geht auch darum, die Erwartungen der Menschen zu erfüllen, findet Holt. „Wie jede andere Lösung ist auch MBSE kein Patentrezept. Es wird nicht alle unsere Probleme auf einen Schlag beheben. Sie müssen wissen, was Sie erreichen wollen, und vor allem, wie Sie das Erreichte messen wollen. Ein Teil des Problems besteht darin, dass die Leute die Tools zu teuer verkaufen.“

Holt zufolge ist der Reifegrad von MBSE in den verschiedenen Organisationen und Branchen sehr unterschiedlich. „Sicherlich in Großbritannien. Traditionell war die modellbasierte Systemtechnik immer eine Domäne des Militärs, der Luft- und Raumfahrt und später der Eisenbahn. Aber wenn Sie sich jetzt die aktuellen Roadmaps der Automobilindustrie ansehen, dann haben sie eine gute Zeit.“

Die verschiedenen Branchen haben auch unterschiedliche Zeitpläne. Entwicklungen in der Unterhaltungselektronik sind kürzer als Infrastrukturprojekte. Längere Entwicklungen sind nicht per se entspannter, wie Schoeber betont. „Die Europäische Weltraumorganisation in Noordwijk arbeitet seit über 10 Jahren mit SysML. Bei der ESA arbeiten viele Länder zusammen, um Satelliten zu produzieren. Sie haben nur eine Chance für einen erfolgreichen Start. Aber auf der anderen Seite müssen sie manchmal harte Entscheidungen treffen, wenn ihnen nach 10 Jahren Entwicklung die Zeit davonläuft. Dann müssen sie sich entscheiden: Gehen sie das Risiko ein, einige Test- und Verifizierungsphasen zu überspringen, um das Startfenster einzuhalten, oder nehmen sie die enormen Kosten in Kauf, die mit einem Jahr Verzögerung einhergehen?“

In der Hightech-Industrie sieht Schoeber ein Spielfeld mit vielen Helden, den kreativen und proaktiven Menschen, die bei Entwicklungen die Führung übernehmen. „Sehen Sie sich ASML an. Das ist ein Unternehmen, das auf Helden basiert. Aber mit einem Marktanteil von fast 90 Prozent und enorm komplexen Systemen haben sie das Bedürfnis, die Verarbeitung und Modellierung auf eine formalere Art und Weise durchzuführen. Sonst werden sie die nächsten zehn Jahre nicht überleben.“

Ersetzen die Modelle die Helden? Holt: „Ich denke, es gibt immer einen Bedarf an Helden, aber Sie brauchen nicht annähernd so viele, wenn Sie einen guten Ansatz haben. Oft sind die Helden da, weil die Dinge nicht richtig gemacht wurden und sie ständig Brände bekämpfen müssen. Viele dieser Dinge könnten vermieden werden. Die Raumfahrt ist ein wirklich gutes Beispiel. Bis Sie Ihre Rakete in den Himmel schießen, wissen Sie nicht, was passieren wird. Sie können Mechanismen einrichten, um das Risiko zu minimieren, aber Sie können nicht alles abmildern. Ja, Sie brauchen Helden, aber wir sollten uns nicht für alles auf Helden verlassen.“

Schoeber: „Am wichtigsten ist es, den gesunden Menschenverstand einzusetzen. Systemingenieure müssen mutig genug sein, aufzustehen und Verantwortung zu übernehmen. Denn das ist es, was einen Helden wirklich ausmacht.“ Holt: „Es geht nicht so sehr darum, dass sie sich an den Wortlaut ihrer Verträge halten müssen, sondern vielmehr um die zugrunde liegende Absicht.“

Dieser Artikel wurde von René Raaijmakers geschrieben, dem technischen Redakteur von Bits&Chips.

„Die Anforderungen an die Lieferanten von Werkzeugen sind nicht auf dem neuesten Stand und das ist frustrierend“

Der Beruf des Requirements Engineering entwickelt sich so schnell, dass die Anbieter von Tools kaum Schritt halten können. „Die Software der großen Anbieter berücksichtigt kaum die neuesten Erkenntnisse in unserem Bereich“, sagt Cees Michielsen, Trainer für System Requirements Engineering am High Tech Institute.

Der Kunde rückt immer mehr in den Mittelpunkt, die Systeme werden immer komplexer und der Entwicklungsprozess wird immer stärker verflochten. Dies sind, kurz gesagt, die Faktoren, die den Wandel im Requirements Engineering vorantreiben. „Das Requirements Engineering ist aus seiner Blase herausgetreten“, sagt Cees Michielsen, Trainer für System Requirements Engineering am High Tech Institute. „Es ist jetzt ein integraler Bestandteil der Systemtechnik.“

„In der Vergangenheit haben wir nur auf den inneren Wert einer Anforderung geachtet. So war auch das Tooling ursprünglich aufgebaut. Inzwischen konzentrieren wir uns mehr und mehr darauf, was eine solche Anforderung in der Gesamtheit der Produktentwicklung bewirkt. Wir zoomen mehr heraus. Leider sind die Software-Tools nicht mit uns gewachsen.“

In den kommenden Monaten wird Michielsen in Bits&Chips eine Handvoll Trends in seinem Bereich beleuchten. In diesem Interview stellen wir Ihnen zunächst einige der Themen vor, die er behandeln wird.

Wichtige Trends

Beim Requirements Engineering geht es darum, sicherzustellen, dass die Kundenwünsche klar und eindeutig in den Produktentwicklungsprozess einfließen, ohne dass Informationen verloren gehen. Diese Informationen können sehr konkret sein: eine LED-Lampe mit 2.700 K und 350 Lumen. Aber sie kann auch vage sein: ein komfortabler Lastwagen. „Wir müssen das richtige Produkt finden“, sagt Michielsen. „Wir müssen das, was der Kunde will, auf effiziente, aber korrekte Weise umsetzen.

Grob gesagt, sieht Michielsen eine Handvoll wichtiger Trends im Requirements Engineering. So ist es zum Beispiel eine immerwährende Herausforderung für Ingenieure, die Anforderungen für ein Produkt vollständig zu erfassen. „Das ist eine immer wiederkehrende Frage von Teilnehmern meiner Schulungen“, bemerkt Michielsen. Es besteht auch der Wunsch, die Qualität der Anforderungen zu verbessern. Das ist zwar nicht immer aufregend, aber eine Herausforderung für Ingenieure, denn Sprache und Formulierung spielen bei der Erstellung von guten Anforderungen und Produktspezifikationen eine entscheidende Rolle.

“We have to implement what the customer wants in an efficient but correct way.”

Die zunehmende Notwendigkeit der Rückverfolgbarkeit könnte man vielleicht als einen wirklich neuen Trend bezeichnen. „Dieser Begriff bezieht sich auf die Möglichkeit, alle Ereignisse und Entscheidungen im Anforderungsentwicklungs-, Design- und Entscheidungsfindungsprozess nachzuvollziehen, von den Interessengruppen bis zur Produktimplementierung“, erklärt Michielsen. „Umgekehrt ist es vor allem bei größeren Projekten wichtig, dass Sie für jede Anforderung auf jeder Zerlegungsebene wissen, wie Sie zu den Bedürfnissen des Stakeholders zurückfinden. Warum sollte man einen Seitenspiegel an einem LKW durch eine Außenkamera und ein Display in der Kabine ersetzen? Sie wollen wissen, warum eine solche Anforderung überhaupt besteht und warum sie so wertvoll ist, wie sie ist. Welche Funktionen sollte die Kamera haben, wie groß ist das Display und welche Auflösung hat es? Welche Entscheidungsfindung hat zu diesen spezifischen Werten für diese Anforderung geführt?“

„Ein guter Requirements-Engineering-Prozess stellt sicher, dass die Anforderungen der Stakeholder über die verschiedenen Entwicklungsiterationen hinweg in die Implementierung einfließen, ohne dass Informationen verloren gehen, einschließlich der Absicht der Kundenanforderungen. Außerdem sollten keine Anforderungen hinzugefügt werden, für die es keinen Stakeholder gibt.“

Warum ist es so wichtig, nicht nur das Ergebnis einer Entscheidung aufzuzeichnen, sondern auch den Entscheidungsprozess?

„Sie möchten Änderungen an Ihrem Produkt schnell und effizient vornehmen können. Dazu müssen Sie auch die Gründe kennen, die Sie zu einer Lösung geführt haben. Wenn Sie den Entscheidungsprozess nicht aufzeichnen, müssen Sie bei jeder Änderung den gesamten Denkprozess erneut durchlaufen. Sie müssen den gesamten Prozess noch einmal durchlaufen und auf hohem Niveau neu darüber nachdenken, was die vorgeschlagene Änderung bedeutet.“

„Wenn Sie die Entscheidungsfindung aufzeichnen, sparen Sie unheimlich viel Zeit. Vor allem in Unternehmen, die mit vielen Produktvarianten arbeiten. Wenn Sie wissen, dass eine Anpassung nur mit dem Unterschied zwischen Variante 1 und Variante 2 zu tun hat, sind Sie viel schneller fertig. Sie können viel effizienter arbeiten.“

Das ist wichtig, wenn Sie hundert verschiedene Rasierapparate herstellen.

„Ja. Wenn Sie bei solchen Zahlen eine gute Rückverfolgbarkeit in Ihren Anforderungsentwicklungsprozess einbauen, ist Ihr Verwaltungsaufwand fast verschwunden.“

20220204 Cees Michielsen RRA_1234

Trainer Cees Michielsen

Zu Michielsens großer Enttäuschung hinken fast alle Anbieter von Anforderungswerkzeugen der Realität in der Produktentwicklung deutlich hinterher. Dinge wie Rückverfolgbarkeit und die Beziehungen zwischen Anforderungen sind in den Softwaretools von Anbietern wie IBM und Siemens kaum berücksichtigt. „Es scheint, als hätten sie sich nie mit den Phasen beschäftigt, die die Anforderungen von den Bedürfnissen der Stakeholder bis zur Implementierung durchlaufen. Das Fehlen einer funktionalen und physischen Aufschlüsselung des Systems bedeutet, dass Sie die Anforderungen nicht mit diesen spezifischen Systemelementen verknüpfen können. Ihnen fehlt tatsächlich der größte Teil der funktionalen und physischen Aufschlüsselung – die linke Seite des V-Modells.“

„Ich denke, dass die Anbieter von Tools für das Product Lifecycle Management derzeit eine zu eingeschränkte Sicht auf die Rolle des Requirements Engineering innerhalb des Systems Engineering haben. Darüber hinaus unterstützen sie die linke Seite des V-Modells nicht oder nur unzureichend. Aus diesem Grund bin ich der Meinung, dass sie den Titel ‚PLM-Tool-Anbieter‘ nicht verdient haben. Schließlich unterstützen sie nur einen begrenzten Teil des Lebenszyklus.“

Können Sie anhand eines Beispiels erklären, was falsch ist?

„Bei der traditionellen Arbeitsweise behalten die Ingenieure den Überblick darüber, inwieweit jedes Teil oder Produkt Teil eines Funktionsmoduls ist. Nehmen wir als Beispiel einen Fahrradlenker des Typs X mit einer integrierten Fahrradklingel Q im Griff dieses Lenkers. Für den Fahrradlenkertyp X ist dies ein fester Bestandteil. Der Fahrradlenker Typ X enthält die Fahrradklingel Typ Q.“

„Nehmen wir an, dass der Fahrradlenkertyp Y mehrere Optionen für die Anbringung einer Fahrradklingel hat, darunter eine integrierte Version. Der Fahrradlenkertyp Y enthält optional den Fahrradklingeltyp Q. Traditionell erfassen wir die Beziehung zwischen dem Objekt Fahrradklingel Q und den Fahrradlenkern X und Y als charakteristische Information der Fahrradklingel Q. Dies führt dazu, dass das Objekt Fahrradklingel Q jedes Mal bei jeder neuen Beziehung zu einem Fahrradlenker geändert werden muss. Die Versions- oder Revisionsnummer, der Status und so weiter. Darüber hinaus müssen alle bestehenden Verknüpfungen überprüft werden. Das bedeutet einen großen Verwaltungsaufwand.“

„Aber das ist wirklich nicht nötig, denn das Objekt Fahrradklingel Q hat sich überhaupt nicht verändert. Nur die Beziehungen zwischen den Teilen haben sich geändert. Die Lösung ist relativ einfach: Sorgen Sie dafür, dass die Information, die die Art der Beziehung zwischen den Objekten angibt, eine bedingte Beziehung ist. Diese Fähigkeit fehlt jedoch in den aktuellen Tools. Der Verwaltungsaufwand zieht sich bis zu den Anforderungen durch, in denen die Beziehung zu anderen Objekten ebenfalls als Attribut beschrieben wird. Wir sprechen hier von den Werkzeugen der großen PLM-Anbieter! Im Moment können sie das einfach nicht leisten. Hier gibt es also noch viel zu gewinnen.“

“The lack of a functional and physical breakdown of the system means that you can’t link the requirements to those specific system elements.”

Sie sagen, dass große Unternehmen wie IBM und Siemens mit ihren riesigen Entwicklungsabteilungen nicht auf dem neuesten Stand sind?

„Das sind sie noch nicht. Die Praxis der Anforderungsentwicklung hat große Schritte gemacht, aber die Anbieter von Werkzeugen sind noch nicht nachgezogen. Selbst kleinere Anbieter wie Top Team, Cockpit und Contact Software sind noch nicht so weit. Das ist eine große Enttäuschung.“

Neue Anbieter von Tools haben einen Markt zu erobern und sollten motiviert sein, Funktionen hinzuzufügen.

„Sie tun das noch nicht genug, obwohl sie als Newcomer die Flexibilität dazu haben. Das niederländische Unternehmen Relatics aus Ridderkerk ist ein Anbieter, der gut abschneidet, aber das Unternehmen ist hauptsächlich auf das Bauwesen und nicht auf den Maschinenbau ausgerichtet. Relatics hat sein ganzes Tool auf die semantische Modellierung ausgerichtet, bei der Sie die ganze Welt als Objekte und Beziehungen zwischen ihnen und allen dazugehörigen Attributen betrachten.“

Das Requirements Engineering beeinflusst auch die Art und Weise, wie wir die Produktentwicklung betrachten. In der High-Tech-Branche wird oft auf das V-Modell verwiesen, wenn es um den Prozess von der ersten Idee bis zur Produktimplementierung geht. Dieses Modell beginnt mit einer funktionalen Gliederung, dem linken Bein des V. Michielsen: „Ein praktisches Problem ist, dass man nicht alle Anforderungen in die traditionelle funktionale Gliederung aufnehmen kann. Das gilt unter anderem für die physikalischen Eigenschaften von Produkten. Masse, Volumen, diese Art von Informationen. Es wäre klug, in diesem linken Bein zwei parallele Trajektorien zu starten. Denn später wird sich herausstellen, dass Sie im aufsteigenden Bein, wenn Sie integrieren, nicht testen können, was Sie angegeben haben. Dies ist zum Beispiel der Fall, wenn ein Submodul oder eine Funktion auf mehrere physische Module verteilt oder aufgeteilt ist. In diesem Fall können Sie diese bestimmten Subsysteme nicht als separate Module testen, sondern nur eines nach dem anderen.

Das Teilsystem kann erst getestet werden, wenn die gesamte Maschine zusammengebaut ist?

„Sie würden eine solche Funktion gerne gleich zu Beginn testen, aber das funktioniert in der Tat nicht. Sie brauchen dann tatsächlich zwei parallele Entwicklungspfade, einschließlich der Verantwortlichkeiten und Budgets, die Sie ihnen zuweisen können. Bevor Sie überhaupt etwas herstellen oder montieren lassen, verwenden Sie Simulationswerkzeuge, um eine virtuelle Funktionsintegration und eine virtuelle physische Integration durchzuführen. Das Ziel ist es, zunächst festzustellen, ob das Design korrekt ist. Dass alles funktioniert und alles passt.“

„Wenn Sie am Ende dieser virtuellen Entwicklung angelangt sind, wissen Sie auch genau, dass Sie die richtigen Bausteine entwickelt haben. Sie sind vollständig, was die Funktionalität angeht. Gleichzeitig wissen Sie auch, wo diese Bausteine in den verschiedenen physischen Modulen landen, weil Sie das durch Ihr physisches Design demonstrieren können. Sobald alles virtuell passt, können Sie mit der Implementierung, der Konstruktion, der Programmierung und so weiter beginnen.

Das W-Modell, wie Michielsen diese Form der Entwicklung nennt, wird das Thema einer separaten Folge seiner Trendserie sein.

Die Trendserie zu den Systemanforderungen ist auch als Bits&Chips-Podcasts auf Apple, Buzzsprout und Spotify verfügbar.

Dieser Artikel wurde verfasst von René Raaijmakers, technischer Redakteur von Bits&Chips.

Recommendation by former participants

By the end of the training participants are asked to fill out an evaluation form. To the question: 'Would you recommend this training to others?' they responded with a 8.6 out of 10.