Die Zukunft der Modellierung: Interview mit Andreas Willert (Teil 2)
Im ersten Teil des Interviews mit Andreas Willert ging es um den aktuellen Stand im Systems Engineering und der Modellierung, wobei Komplexität als der Treiber für Forschung in diesem Bereich identifiziert wurde.
Dies ist der zweite und letzte Teil, in dem Andreas einige Prognosen wagt und ein spannendes Kundenprojekt vorstellt.
Hinweis: Andreas Willert hält mit seinen Mitautoren das Seminar Model-Driven Embedded Software Engineering am 2. Dezember auf dem ESE-Kongress 2019.
Was bedeuten diese Entwicklungen für die Zukunft? Was muss passieren?
Hättest Du mich vor zehn Jahren gefragt, hätte ich Dir einige Punkte nennen können. Heute fehlt aus Engineering Sicht fast nichts mehr. Aber es gibt andere Gesichtspunkte, die eventuell mitverantwortlich sind, dass sich modellgetriebenes Engineering im Softwareengineering mit UML nicht so durchgesetzt hat.
Und zwar bringt die UML an sich gar nicht so viel, wenn nicht gleichzeitig auch die Architektur berücksichtigt wird. Der Übergang von C zu UML ist nicht wirklich ein Paradigmenwechsel, wenn damit nicht auch der Übergang von der prozeduralen zur objektorientierten Programmierung einhergeht, oder zu einer serviceorientierten oder asynchronen Architektur.
Ohne einen Wechsel der Architektur kann die UML am Ende nicht ihr vollständiges Potential entfalten. Und in einer Renovierung der Architektur liegt auch gleichzeitig die Problematik. Das ist nicht so einfach.
Wenn ich heute mit C einen Microcontroller einsetzen möchte, kaufe ich mir zum Beispiel als Entwicklungsumgebung die ARM µVision von Keil, wo ich schon viel mitgeliefert bekomme, wie TCP/IP Stack, grafische Displaytreiber, USB-Treiber, usw. Innerhalb kürzester Zeit habe ich eine Umgebung am Laufen, die gefühlt meine halbe Applikation ausmacht. Bei diesem Bottom-Up-Vorgehen sind in dieser Phase die noch vor einem liegenden Probleme, die aus der Komplexität resultieren, nicht sichtbar. Gefühlt bin ich schon sehr weit in dem Projekt.
Diese Treiber sind jedoch alle nicht objektorientiert oder serviceorientiert. Wenn ich die mit Rhapsody unter UML zum Laufen bringen möchte, bin ich erst einmal Tage mit Architekturarbeiten beschäftigt und gefühlt bremst mich das aus. Das ist vermutlich ein weiterer Grund, warum die Modellierung nicht in vollem Umfang eingesetzt wird. Dieses Problem ist übrigens mit Matlab nicht so groß, da die Codegenerierung noch auf veralteten Architekturprinzipien aufbaut.
Wir brauchen die Adaption an die Hardware, mit objektorientierten Treibern und Konzepten. Mit C++-Templates könnte man Treiber übrigens viel effizienter umsetzen, sowohl bezüglich Größe als auch Runtime. Die Umstellung ist halt ein Haufen Arbeit, und viele Embedded Programmierer sind nie über C hinaus gekommen und verstehen den Code dann auch nicht mehr. Aber es würde das SW Engineering auf eine ganz neue Ebene heben und wäre extrem vorteilhaft.
Denn dann hätten wir Kapselung, wodurch wir uns vom Treiber entkoppeln können. Richtig?
Ja genau. Wenn ich Komponenten zu Systemen integrieren möchte, muss ich nicht verstehen, wie genau eine Komponente intern funktioniert, nur was sie tut. Genau so wichtig aber häufig vernachlässigt muss ich berücksichtigen, in welchem Kontext sie eingebettet sein muss, damit sie funktioniert. Wir müssen verstehen, dass das, was da drinnen ist, nur richtig funktionieren kann, wenn ich es in einen definierten Kontext einbette. Da müssen wir hinkommen.
Um abzusichern, dass bei der Wiederverwendung nichts Unerwartetes passiert, ist das Vorgehen heute oft das Verstehen im Inneren, also sich den Code anzusehen um zu schauen „was im Inneren des Module / der Komponente genau geschieht“. Das neue Engineering-Paradigma muss ein: Wenn ich sicher sein will, dass das, was ich verwende, stabil läuft, dann ist der Kontext wichtig. Ich vertraue darauf, dass der Entwickler, der die Komponente erschaffen hat, professionell und sorgfältig gearbeitet hat und konzentriere mich auf die „Contracts“, also darauf, dass ich die Komponente auch richtig anwende. Die Contracts müssen natürlich spezifiziert werden. Aber ich bin sicher, ohne das erreichen wir die nächste Ebene der Komplexität nicht.
Wir müssen nicht in den Code hereinschauen, sondern vielmehr den äußeren Kontext berücksichtigen.
Wenn Du Dich mit Komplexitätswissenschaft auseinandersetzt, ist genau das der nächste Schritt: Wir können nicht mehr in die Tiefe gehen und alles verstehen, aber wir müssen sicher sein, wenn wir all diese Komponenten zusammenschalten, dass das Gesamtsystem funktioniert. Und da müssen wir auf die kontextuelle Ebene gehen. Und dafür ist die Modellierung im Vergleich zur Codierung sehr viel besser geeignet. Dazu gehört eben nicht nur der Zugriff auf die Geschwindigkeit, die in irgendeiner Variablen liegt, sondern dass die Geschwindigkeit in einer bestimmten Einheit und Genauigkeit geliefert wird, auch hinsichtlich der Abtastung zum Beispiel. Gerade in der Laufzeitarchitektur liegt heute häufig die Ursache für funktionales Fehlverhalten. Firmen wie Symtavision verdienen mit der nachträglichen Analyse viel Geld. Und so ein Werkzeug von Symtavision liegt im Bereich €30.000-€50,000. Das zeigt mir immer, dahinter stecken reale Probleme. Niemand würde so viel Geld für ein Tool ausgeben, wenn er damit nicht ein seriöses Problem lösen kann. Wenn zum Beispiel ein eingebetteter Regler in seiner Sensorik nicht mehr genau genug ist, weil er in einer Zyklusfrequenz von einem Kilohertz arbeitet, aber eine Variable bekommt, die nur mit 500 Hertz abgetastet wird. Dann kann der Regler natürlich nicht genauer sein als sein Umfeld, das ihn beliefert. Die Spezifikation der Schnittstellen von Komponenten beinhaltet diese Qualitätsattribute heute so gut wie nie.
Du erwähntest schon mehrmals Contract-Based Design. Ist das ein Lösungsweg?
Na ja, ich glaube, dass Contract-Based Design einen schwergewichtigen Anteil an einer Lösung liefern kann. Doch wie so häufig gibt es nicht die eine Maßnahme, die ein Problem löst. Ich glaube, es wird eine Kombination an Maßnahmen sein. Neben Contract-Based Design auch Erhöhung der Abstraktion, Traceability, Modellierung mit früherer Simulation, Einführung von Systems Engineering um die aus meiner Sicht wichtigsten zu nennen.
Es gibt nicht die einzige Technik, die unsere Probleme löst. Aber Systems Engineering scheint sich zunehmend als Fundament heraus zu kristallisieren.
Methodisches Systems Engineering als eigenständige Disziplin wird gefühlt in 99% aller Embedded Projekten noch nicht praktiziert, aber irgendwo müssen ja alle Engineering- Disziplinen zusammengeführt werden. Und ohne Systems Engineering kann auch Contract-Based Design nur ansatzweise angewendet werden. Und am Ende greift alles ineinander und bereichert sich gegenseitig. Alle Maßnahmen zusammengenommen sind eben mehr als deren Summe und dann sind Effizienzsteigerungen von Faktor 2-3 möglich bei gleichzeitiger Qualitätsverbesserung, auch wenn eine einzelne Maßnahme isoliert angewendet eventuell nur 10% Potential beinhaltet.
Wir haben also keine Magic Bullet, sondern viel harte Arbeit vor uns
Ja – aber das positive dabei ist, dass wir Kunden haben, die das geschafft haben und beweisen, dass es möglich ist. Wir haben einen Kunden, den ich auch nennen darf, die Firma Wagner. Die machen Brandschutz unter anderem mit einem System, dass den Sauerstoffgehalt der Luft reduziert. Dabei gibt es einen „Korridor“ des Sauerstoffgehalts, bei dem ein Feuer nicht aufkeimen kann, aber Menschen noch atmen können. Dies wird dann zum Beispiel in Lagerhallen angewendet. Das ist natürlich hoch sicherheitskritisch. Bei einer Unterschreitung ersticken die Menschen, bei einer Überschreitung ist die Schutzwirkung nicht mehr gegeben.
Die modellieren inzwischen alles, was sich im nachhinein auch als Basis für Agilität herausgestellt hat. Du kennst ja sicher die Diskussionen, dass bei einem Sprint ein „Deliverable“ herauskommen muss. Hierbei wird oft angenommen, ein Deliverable ist ein Feature, dass der Kunde anwenden kann. Da bist Du im Embedded natürlich meilenweit von entfernt. Um trotzdem z.B. Scrum anzuwenden, gibt es die Möglichkeit, die Definition von „Deliverable“ zu korrigieren. Ein Deliverable könnte die Spezifizierung aller Requirements für ein Feature sein. Das nächste könnte dann die angepasste Architektur sein, um das Feature implementieren zu können. Das nächste ist dann die Implementierung, und das darauffolgende der Test, zum Beispiel. Doch wenn sich das Vorgehen zum Continuous Engineering entwickeln soll, ist das auch nicht unbedingt das, was Du willst. Dann möchtest Du tatsächlich so ein Feature innerhalb von einem Sprint einbauen. Und dann bist Du beim hoch automatisierten Engineering bis hin zu nightly Tests, und Vorgehen wie TDD (Test Driven Development). Wagner geht noch einen Schritt weiter. Das Ziel ist die TÜV- Abnahmen pro Feature.
Die Firma Wagner ist kurz vor der Möglichkeit in wenigen Wochen eine Änderung umzusetzen, einschließlich TÜV-Zertifikat.
Voraussetzung dafür ist, dass sie Regressionstests in einem Raum durchführen, zu dem der Zugang immer nur mit dem TÜV gemeinsam möglich ist. Weder Wagner noch der TÜV können alleine an den HIL-Tests etwas ändern. Die Tests gehen digital rein und die Ergebnisse kommen digital raus. Im Raum kann nichts verändert werden, ohne dass der TÜV dabei ist. Der TÜV kann damit auch kurzfristig, innerhalb von wenigen Tagen, zertifizieren – zumindest solange keine neuen Tests benötigt werden. Damit kann Wagner in wenigen Wochen Änderungen delivern, inklusive TÜV-Zertifikat. Das ist ohne Modellierung, Regressionstests, Simulation und darauf aufbauend einem hohen Grad an Automatisierung nicht vorstellbar. Eigentlich ist es wie eine Software Factory.
Modell getriebenes Engineering wirkt sich auch aufs Testen positiv aus. Je höher meine Abstraktion ist und je besser meine Metastruktur, umso besser kann ich automatische Tests bauen. Auf UML-Ebene, wo ich über Events meine Systeme freischneiden kann, sind die Implementierung von Regressionstests gerade mal 50% so aufwändig wie auf C-Ebene mit globalen Variablen, und ähnlichem.
Der Entwicklungsleiter bei Wagner behauptt, dass sie heute Faktor drei schneller sind als früher, bei gleichzeitiger Qualitätssteigerung.
Allerdings haben sie über sechs Jahre benötigt, bis sie so weit waren. Also nicht so lange ohne Effizienzgewinn, aber für ein paar Wochen, Monate verlierst Du sogar Effizienz, um sie dann kontinuierlich zurück zu gewinnen und zu steigern. Du hast eine reelle Chance, nach einem Jahr ca. 20%-30% effizienter zu sein. Aber das Potential ist weit größer, und wenn man das wirklich konsequent durchzieht, dann kann man nach sechs, sieben Jahren bei einem Faktor von zwei bis drei landen.
Modellierung greift an ganz vielen Punkten. Modellierung mit einer höheren Abstraktion wie UML ermöglicht Testautomatisierung, UUIDs für meine Elemente, womit ich Traceability einfacher aufbauen kann, Konstrukte wie Ports und Interfaces, mit denen Contract-based Design viel einfacher genutzt werden kann.
Modellierung greift an ganz vielen Punkten um die Maßnahmen zu unterstützen, mit denen Komplexität beherrschbar wird.
Ähnlich wie das Systems Engineering ist die Anwendung von Modellierung eine Art Basis Technologie, die andere Maßnahmen enabeld und deren effizient Anwendung erst ermöglicht.
Hast Du noch abschließende Worte?
Mein Wunsch wäre, dass sich Softwareentwickler häufiger aus ihrer Komfortzonen wagen, wo sie ihre Sicherheit aufgeben. Die werden sie zurückgewinnen, auch wenn sie ohne Erfahrung in der Anwendung von neuen Methoden, Vorgehen und Werkzeugen nicht unbedingt eine Vorstellung davon haben wie das aussehen kann. Ich würde mir den Mut von Entwicklern wünschen, durch diese Talsohle zu gehen. Denn alle unsere Kunden, die das getan haben, können sich danach nicht mehr vorstellen, wie sie früher mit herkömmlichen Programmiersprachen ihre Software engineered bekommen haben.
Ich würde mir auch wünschen, dass Entscheider mehr in ein tieferes Verständnis investieren würden. Ich glaube Profitcenter-Denken in Verbindung damit, dass (gerade im SW Engineering) keine Managemententscheidungen getroffen werden, hat in den letzten Jahren zu großen Investitionsstaus geführt. Ein Beispiel: Wenn ich heute ins Top- Management in Unternehmen gehe, sitzen dort Betriebswirte, manchmal Maschinenbauer, aber selten jemand, der Softwareengineering versteht. Wenn jemand von SAP kommt, und über Betriebswirtschaftliche Vorgänge und Verbesserungen spricht versteht das Management das. Wenn ich über Abstraktion, Information Hiding, OOP und all diese Themen rede, versteht das Management wenig bis nichts. Wo investiert der Entscheider nun?
Nun ja, einen „Faktor Drei“ versteht er schon, aber…
Wenn ich von „Faktor Drei“ in Bezug auf Effizienzgewinn spreche, versteht das Management die Aussage an sich. Aber wie glaubwürdig ist sie, wenn die technischen Maßnahmen nicht verstanden werden.
Das Vertrauen hat das Management natürlich viel mehr in den Bereichen, die es auch versteht. Und SAP sagt auch „Faktor Drei“, also wird dort investiert. Oder der Entscheider geht zu seinem Softwareentwickler und fragt den. Doch der Softwareentwickler will natürlich nicht das Risiko für so eine Entscheidung übernehmen. Das funktioniert nicht.
Die Kosten für einen Paradigmenwechsel sind hoch außerhalb seines Verantwortungsbereiches. Mit Schulungen, Werkzeugen etc. sind wir schnell bei zehntausenden von Euro. Die können meist nicht auf Projektebene dargestellt werden. Die Entscheidung über solch eine Investition muss vom gehobene Management getroffen werden, und das drückt sich häufig davor.
