Model-Based Design und Agile
Effiziente Software-Entwicklung für mechatronische Systeme
Mechatronische Systeme wie Fahrzeuge und Produktionsmaschinen sind zunehmend »software-defined«. Das macht Entwicklung und Test der Systeme komplexer. Wie lässt sich die Komplexität verringern oder auf einem gut handhabbaren Niveau halten? Model-Based Design und Agile lauten hier die Stichwörter.
Die Funktionalität mechatronischer Systeme, zum Beispiel von Produktionsmaschinen, wird zu einem immer größeren Teil in Software umgesetzt. Darum kommen immer mehr Sensoren und immer leistungsfähigere Prozessoren zum Einsatz. Gleichzeitig sollen mechatronische Systeme durch Modularität und Updates aufgerüstet oder an andere Prozesse und Materialien angepasst werden können. Das macht die Entwicklung und das Testen solcher Systeme auf eine Weise komplexer, die mit konventionellen Entwicklungsmethoden kaum noch zu bewältigen ist.
Die Entwicklung mechatronischer Systeme erfolgt zunehmend parallel, wobei der Software-Entwicklung eine zentrale Rolle zukommt. Statt die Mechanik zuerst zu entwerfen, gefolgt von der Elektrik und zuletzt der Software, wird die Software von Anfang an in den Entwicklungsprozess integriert. Weil Komplexität und Umfang der Software stetig zunehmen, ist es entscheidend, potenzielle Fehler oder Probleme frühzeitig zu erkennen.
Jobangebote+ passend zum Thema
So lässt sich das System mithilfe simulierbarer Modelle schon validieren, bevor die zugehörigen Teile endgültig feststehen. Das gibt den Entwicklern beziehungsweise System Engineers die Zeit, das Funktionieren der Software mit ihrer Umgebung frühzeitig zu testen, Alternativen auszuprobieren und die Mechanik zu verfeinern, bevor das endgültige Aussehen der Komponenten feststeht. So kann Zeit gegenüber Mitbewerbern gewonnen und Liefertermine zuverlässig eingehalten werden.
Visualisierung der Modellsimulation
Durch die detaillierte Simulation des Systems mit Simulink von MathWorks lässt sich das Zusammenspiel der Mechanik mit der Software testen (Bild 1), einschließlich der Visualisierung und Animierung aller Transitions- und Kommunikationsabläufe.
Die Vorteile einer Gesamtsimulation liegen in der deutlich ausgereifteren Hard- und Software. Die Softwareentwickler können zudem früher mit ihrer Arbeit beginnen. Darüber hinaus erlaubt eine Gesamtsimulation das Testen kritischer Zustände, ohne dabei Schäden befürchten zu müssen. Der Einsatz von Modellen ermöglicht die frühzeitige Erkennung von Designfehlern und damit indirekt eine höhere Innovationsfähigkeit, weil neue Ideen schneller »ausprobiert« werden können.
Model-Based Systems-Engineering und Model-Based Design: Modelle einsetzen von Anfang an
Der höchste Return on Investment durch den Einsatz von Modellen und früher Simulation wird erzielt, wenn Modelle vom ersten Tag an die Entwicklungsgrundlage bilden – vom Entwurf der System- und Software-Architektur bis zur Definition der einzelnen Komponenten. Diese Methodik wird modellbasierte Systementwicklung (Model-Based Systems-Engineering, MBSE) beziehungsweise Model-Based Design genannt.
In MBSE ist die zentrale Datenhaltung wesentlich. Alle Anforderungen, Randbedingungen und Zusatzinformationen sind integraler Bestandteil des modellbasierten Systems. Dies ermöglicht Analysen, Optimierungen und spezifische Visualisierungen aller Teilaspekte (Bild 2). Sowohl die physikalischen Anteile als auch die Software werden in einer Systemarchitektur auf Basis des MBSE-Add-ons »System-Composer« von MathWorks inkludiert und zu Validierungszwecken gegebenenfalls noch in äußere Umgebungsmodelle eingebettet.
Die physikalischen Teile eines Systems werden dabei grafisch aufgebaut – zum Beispiel mithilfe von Bibliotheken mit Blöcken, Funktionsgleichungen oder komplett vorkonfigurierten Komponenten. Verfügbar sind diese Komponenten für sämtliche relevanten Domänen, unter anderem Mechanik, Elektrik, Elektronik, Hydraulik und Pneumatik.
Um die Software zu entwerfen, werden beim Software-Engineering zunächst die Anforderungen und Use Cases festgelegt, woraufhin die Software-Architektur durch Block- und Klassendiagramme erstellt wird. Zur Funktionsbeschreibung folgen Aktivitäts- und Sequenzdiagramme, die auch das Zusammenwirken und Zeitverhalten der Komponenten beschreiben (Bild 3). Auch diese lassen sich simulieren und animieren – noch bevor die eigentlichen Algorithmen modelliert werden. Die Algorithmen werden schließlich mit Datenflussdiagrammen, Zustandsautomaten oder Programmcode realisiert.
Solche Modelle geben das System anschaulich als ausführbare Spezifikation wieder und enthalten dessen Komponenten inklusive der Verbindungen und Schnittstellen. Anforderungen lassen sich direkt und nachverfolgbar mit Komponenten und Software verbinden (Bild 4). An jedem Punkt der Entwicklung kann so durch Tests verifiziert werden, ob das System wie vorgesehen arbeitet und die Anforderungen erfüllt.
Jede modulare Komponente der Architektur wird iterativ verfeinert, sodass die Komponenten auch parallel entwickelt werden können, was den Prozess beschleunigt. So wächst das Modell Stück für Stück zu einer immer realistischeren Darstellung des Gesamtsystems, das sich kontinuierlich testen und validieren lässt. Fehler werden damit früher erkannt und lassen sich leichter und schneller beheben.
Die bidirektionale Nachverfolgbarkeit von Anforderungen zum Modell sowie die automatische Berichtserzeugung sorgen für eine transparente Dokumentation des gesamten Prozesses mit vergleichsweise geringem Aufwand.
Agile Entwicklungsansätze
In der Software-Industrie hat sich für die beschriebene Art der inkrementellen Entwicklung mit kontinuierlicher Verfeinerung ein eigener Zweig von Entwicklungsansätzen herausgebildet, der »Agile« genannt wird. Er soll Komplexität handhabbar machen und effizienter sein als traditionelle Methoden. Kleine Teams arbeiten an jeweils einem Teil einer Software wie der Architektur oder einer Komponente. Bei dieser iterativen Arbeitsweise werden Anforderungen und Lösungen oft erst während der Entwicklung ausgearbeitet (Bild 5). Am Ende jeder Iteration – »Sprint« genannt – wird ausgewertet, wo man steht, was fehlt und wie die nächsten Schritte aussehen sollten. Diese Art der Entwicklung zeichnet sich durch hohe Flexibilität und Resilienz aus. Auf Fehler oder sich ändernde Anforderungen lässt sich einfacher eingehen als bei konventionellen Entwicklungen.
Die Gemeinsamkeiten mit Model-Based Design liegen auf der Hand, weil auch hier durch inkrementelle Ausarbeitung des Gesamtsystems am Ende ein Produkt entsteht. Das kontinuierliche, frühestmögliche Testen steht dabei im Vordergrund.
Verhaltens- und testgetriebene Entwicklung
SAFe (Scaled Agile Framework, https://scaledagileframework.com) ist ein Framework für agile Software-Entwicklung, das in verschiedenen Branchen genutzt wird. Laut SAFe ist »Behavior-Driven Development (BDD) eine Test-First-, Agile-Testing-Praxis, die eingebaute Qualität bietet, indem Tests definiert (und potenziell automatisiert) werden, vor oder als Teil der Spezifizierung des Systemverhaltens«. Der Fokus liegt dabei auf der korrekten Erfassung der Anforderungen und ihrem gegebenenfalls iterativen Abgleich mit dem Design. Durch die Verbindung von BDD und den Systemsimulationsfunktionen von Model-Based Design lassen sich schon früh virtuelle Prototypen erstellen und das Systemverhalten – zusammen mit dem Erfüllen der Akzeptanzkriterien – aus Sicht des Endbenutzers erforschen. Einmal erstellte Testfälle werden dabei dank der vollständigen Automatisierung mit funktionalen Akzeptanzkriterien durch eine Auswahl an Formalismen (Bild 6) kontinuierlich weiterverwendet.
Demgegenüber existiert auf Komponentenebene der Ansatz der testgetriebenen Entwicklung (Test-Driven Development, TDD), der typischerweise eine Software-Komponente isoliert und testet. Auch auf dieser Ebene ist das automatisierte Testen formalisierter Anforderungen zentral. Bei diesem Ansatz werden zuerst die Komponententests spezifiziert und automatisiert ausführbar eingerichtet – erst danach wird die Implementierung gestartet. Somit können Entwickler jederzeit automatisiert überprüfen, ob die Komponente bereits die spezifizierten Anforderungen erfüllt.
BDD und TDD mit Model-Based Design
In Bild 7 ist ein möglicher Gesamtprozess von der Anforderungsdefinition bis zur fertigen Software in Entwurf und Test dargestellt. Nachdem Systemanforderungen und Systemarchitektur definiert wurden (Phase A und B), beginnt bereits das Schreiben von Testfällen auf Systemebene, einschließlich des Aufsetzens einer Testumgebung, die jederzeit die Tests automatisiert wiederholen kann (Phase C). Bei Inkonsistenzen wird wieder zurück über die Phasen A und B iteriert.
Nach Erstellung der Systemtests wird auf die Komponentenebene gewechselt, wo nun parallel für alle Komponenten der Architektur mit TDD erneut der Test-first-Ansatz umgesetzt wird: die Erstellung automatisiert ausführbarer Tests für die jeweilige Komponente noch vor dem Entwurf des Komponentenverhaltens (Phase D). Das Komponentenverhalten wird entwickelt, bis die angelegten Testfälle funktionieren (Phase E). Weitere Optimierungen oder Codegenerierung erfolgen später.
Sind alle Komponenten modelliert und in die Architektur integriert, werden die Systemtests aus Phase C automatisiert wiederholt (Phase F). Schon hier lässt sich das System den Stakeholdern vorführen, um das gegenseitige Verständnis weiter abzusichern – unterstützt durch eine visuelle Systemanimation (Bild 1). Dadurch wird frühestmöglich ein großes Vertrauen in die Anforderungsdefinition, die System- und Software-Architektur sowie die Komponentenbeschreibungen geschaffen, sodass die Wahrscheinlichkeit aufwendigerer Iterationen durch zu spät aufgedeckte Probleme deutlich sinkt.
Anschließend lässt sich das Vertrauen in den Systementwurf weiter erhöhen, indem der Software-Teil des Systems mit realer Hardware mittels Rapid Prototyping getestet wird (Phase G).
Nachdem die Systemfunktion und das Systemzusammenwirken abgesichert sind, wird in Phase H die Finalisierung der Komponenten bezüglich der Optimierung des Algorithmus, Sicherstellung der Modellqualität und schließlich Codegenerierung umgesetzt.
Zum Abschluss werden in den Phasen I und J das Systemverhalten im Software-in-the-Loop- und Hardware-in-the-Loop-Test final überprüft.
Codegenerierung
Einer der zentralen Vorteile von Model-Based Design ist die Fähigkeit, Software automatisch aus dem Modell zu generieren. So lässt sich C/C++-Code, strukturierter Text oder auch VHDL/Verilog-Code für FPGAs, SoCs und ASICs erzeugen – Codes, die eine effiziente und optimierte Implementierung technischer Systeme in unterschiedlichsten Anwendungsfeldern ermöglichen (Bild 8).
Dabei ist es zunächst unwichtig, auf welcher Plattform der Code später ausgeführt wird. Ausgangspunkt ist immer das gleiche Modell – die Entwickler müssen sich also nicht von vorneherein festlegen. Diese Flexibilität ermöglicht beispielsweise einen nachträglichen Wechsel auf ein leistungsfähigeres System. Auch die Wiederverwendung in Nachfolgeprojekten mit anderen Anforderungen ist so möglich.
Zukunftsfähigkeit durch Model-Based Design und Agile
Ergänzen Ingenieure Model-Based Design um Agile-Methoden, profitieren sie von einer Reihe von Vorteilen: Zum einen gleichen sich die Arbeitsweisen von Hardware- und Software-Entwicklern an. So entstehen neue Synergien und eine verbesserte Kommunikation. Administratoren werden entlastet, weil sich auch die Software-Landschaft vereinheitlicht.
Agile Entwicklung eignet sich besonders dazu, Produkte weiterzuentwickeln und zu aktualisieren, während sie schon beim Nutzer in Betrieb sind. Bei dieser als Continuous Integration/Continuous Delivery (CI/CD) bezeichneten Methode wächst das Produkt kontinuierlich weiter, wird verbessert oder mit Sicherheits-Updates versorgt.
Reaktionsschnelligkeit wird in diesem Umfeld zu einem zentralen Wettbewerbsfaktor. Die Beherrschung von CI/CD ist ein Schlüsselfaktor, um dies zu erreichen. Der hier beschriebene Ansatz erfüllt alle dafür erforderlichen Voraussetzungen. Unternehmen, die Model-Based Design mit Agile kombinieren, sind für CI/CD und neue Geschäftsfelder besser aufgestellt. Ihre Ingenieure bringen die dazu nötigen Fähigkeiten und Einstellungen mit, die internen Prozesse unterstützen es, und geeignete Software-Werkzeuge wie System Composer und Simulink ermöglichen es.
The Mathworks auf der embedded world: Halle 4, Stand 110
Lesen Sie mehr zum Thema
