Agile Methoden und Model-Based Design für die Entwicklung technischer Software

Die meisten Teams, die heute Software für technische Anwendungen entwickeln, erkennen die Nachteile herkömmlicher Methoden (Wasserfallmodell): Fehler und Entwurfsprobleme werden erst in späteren Projektphasen erkannt, Änderungen der Anforderungen können nicht berücksichtigt werden, und es besteht das Risiko, ein System zu erstellen, das die Bedürfnisse der Kunden nicht erfüllt.

Um diese Nachteile zu vermeiden, verwenden viele Teams heute einen Ansatz, der agile Methoden mit Model-Based Design kombiniert.

Eine Untersuchung von Model-Based Design und agilen Methoden zeigt, dass Model-Based Design agile Methoden für technische Anwendungen ergänzt und sogar ermöglicht. Wie der agile Ansatz wurde Model-Based Design konzipiert, um schnelle Iterationen zu unterstützen. Außerdem können mit Model-Based Design Herausforderungen der Systementwicklung bewältigt werden, für die agile Methoden allein nicht ausreichen:

• Frühes Testen ohne Verfügbarkeit von Geräten
• Bewältigung der Komplexität technischer Systeme
• Verringerung des Risikos, beim Testen ungeprüfter Software auf teurer Hardware
• Einhaltung der Anforderungen an die funktionale Sicherheit und anderen Standards, einschließlich DO-178B/C und ISO 26262

In diesem Artikel wird erläutert, wie Model-Based Design die zentralen Werte der agilen Entwicklung unterstützt. Als Beispiel wird die Entwicklung eines adaptiven Tempomats vorgestellt, für die Model-Based Design mit agilen Methoden und dem Scrum-Framework kombiniert wird.

Zuordnung der zentralen Werte agiler Methoden zum Model-Based Design

Im Agile Manifesto werden vier zentrale Werte für die Softwareentwicklung definiert:

• Individuen und Interaktionen werden mehr geschätzt als Prozesse und Werkzeuge,
• funktionierende Software mehr als umfassende Dokumentation,
• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung,
• Reagieren auf Veränderung mehr als das Befolgen eines Plans.

Die Autoren des Manifests betonen, dass „mehr als“ nicht „ausschließlich“ bedeutet. Sie schlagen eine Veränderung der Prioritäten vor: „Obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.“

Sehen wir uns nun an, wie diese agilen Werte dem Model-Based Design zugeordnet werden können.

Fokussierung auf Individuen und Interaktionen

Die Prozesse und Tools in Model-Based Design – insbesondere die Modellierung und die Simulation – fördern produktive Interaktionen zwischen Individuen und Teams. Das Modell kann direkt in Simulink^®, in einem Bericht oder als Webseite weitergegeben werden, sodass es alle Beteiligten als gemeinsamen Bezugspunkt und als verbindliche Informationsquelle verwenden können. Simulationsergebnisse sind klar und sichtbar und können Entwurfsentscheidungen, die Scrum-Planung und Diskussionen mit allen Beteiligten erleichtern.

Fokussierung auf die Zusammenarbeit mit dem Kunden

Die Zusammenarbeit mit dem Kunden steht im Zentrum agiler Methoden. Jeder Sprint beginnt mit einem Planungs-Meeting und endet mit einem Review-Meeting, zu dem häufig auch Kunden beitragen. Modellierung und Simulation unterstützen nicht nur die produktive Zusammenarbeit mit Kunden, sondern ermöglichen auch die Zusammenarbeit zwischen unterschiedlichen Teams, Aufgabenbereichen und Disziplinen. Ingenieure aus Hardwareentwurf, Systementwurf sowie Funktions- und Komponentenentwicklung haben eine gemeinsame Sprache und können sich auf ihre Zusammenarbeit konzentrieren, statt über Tools nachzudenken.

Fokussierung auf funktionierende Software

Einer der wesentlichen Vorteile von Model-Based Design für ein Team, das agile Methoden verwendet, ist die Möglichkeit, von den ersten Sprints an eine funktionierende Version des Systems zu entwickeln, auch wenn Zielhardware, Strecke, Sensoren oder sonstige Hardware nicht verfügbar sind. Ein durch Simulation verifiziertes Simulink-Modell kann während des gesamten Projekts als funktionierende Software verwendet werden. Ein Modell dient als ausführbare Spezifikation des zu entwickelnden Systems. In frühen Sprints, in denen Hardware möglicherweise nicht zur Verfügung steht, können dem Kunden Simulationsergebnisse statt Ergebnissen von Hardwaretests übergeben und dazu genutzt werden, den Fortgang der Arbeit einzuschätzen, um Unterstützung zu bitten oder den nächsten Sprint zu planen. Außerdem ermöglichen Modelle eine klare und einfache Messung der Fortschritte. Wenn das Modell weiter ausgearbeitet wird, kann es verwendet werden, um Code für Software-in-the-Loop (SIL), Processor-in-the-Loop (PIL) und Hardware-in-the-Loop (HIL) Tests sowie für Echtzeit-Prototypen und Produktionssysteme zu generieren. 

Außerdem dient das Modell als Grundlage für eine umfassende Dokumentation. Im Model-Based Design ist die Dokumentation ein Ergebnis des Entwurfsprozesses statt einer separaten Aufgabe, da Dokumentation und Berichte bei Bedarf aus dem Modell generiert werden können.

Fokussierung auf das Reagieren auf Veränderung

Ein wesentliches Erfolgshindernis bei der Entwicklung nach dem Wasserfallmodell ist die Unmöglichkeit, angemessen zu reagieren, wenn Anforderungen und Bedingungen sich verändern. Agile Entwicklung und Model-Based Design haben diesen Nachteil nicht und ermöglichen Teams effektivere Reaktionen auf Veränderungen. Jede nichttriviale Änderung einer technischen Anwendung kann ein Ingenieur im Model-Based Design durch Modifikation des Modells umsetzen und anschließend einfach den Code erneut generieren.  Vor der Implementierung von Änderungen kann das Team Was-wäre-wenn-Analysen durchführen, um die beste Möglichkeit zu ermitteln, eine bestimmte Anforderung umzusetzen. Nachdem Änderungen am Modell vorgenommen wurden, können Ingenieure Simulationen als Regressionstests durchführen, um sicherzustellen, dass die Änderungen kein unbeabsichtigtes Systemverhalten verursachen. Außerdem kann das Team Auswirkungsanalysen durchführen, um zu verstehen, wie eine Änderung an einem Teil des Modells andere Teile beeinflussen wird.

Anwendungsfall: Kombination agiler Methoden mit Model-Based Design für die Entwicklung eines adaptiven Tempomats

In diesem Beispiel entwickelt ein Team von Automobilingenieuren Software für einen adaptiven Tempomat mit Sensorfusion. Das System führt Eingabedaten von Radar und Vision-Sensoren des Fahrzeugs zusammen, um das wichtigste Objekt und seinen Abstand zum eigenen Fahrzeug zu identifizieren. Damit kann es die Geschwindigkeit anpassen und eine sichere Entfernung einhalten.

In diesem Projekt arbeitet eine Gruppe von Ingenieuren an der Entwicklung der Steuerungsalgorithmen, während eine andere Fahrszenarien und synthetische Sensordaten entwickelt. Mithilfe dieser synthetischen Daten können die Ingenieure die Algorithmen schon lange entwickeln und testen, bevor tatsächliche Sensordaten verfügbar werden. Frühe Simulationen anhand synthetischer Daten können als Grundlage für Entwurfsentscheidungen dienen, beispielsweise hinsichtlich der Art, Anzahl und Positionierung von Sensoren im Fahrzeug.

Im ersten Sprint modelliert jedes Teilteam (oder jede Gruppe von Ingenieuren) seine jeweiligen Subsysteme. Dabei verwenden die Teilteams ein gemeinsam genutztes Simulink-Modell auf Systemebene, um ihre Arbeit zu koordinieren (Abbildung 2). Schon in dieser frühen Phase können sie Simulationen durchführen, um zu ermitteln, wie sich die Steuerung unter verschiedenen Bedingungen verhält. Sie debuggen die Steuerung, identifizieren zu optimierende Parameter und visualisieren wichtige Leistungsmetriken von einer funktionierenden Version des Systems, und zwar, bevor sie auch nur eine Zeile Code schreiben oder generieren.

In einem Review-Meeting mit dem Kunden gegen Ende des ersten Sprints zeigen sie ihm das Modell und die Simulationsergebnisse (Abbildung 3). Das Modell und die Ergebnisse bieten eine konkrete Darstellung der funktionierenden Software – beispielsweise, indem sie veranschaulichen, wie die Geschwindigkeit des Fahrzeugs sinkt, nachdem ein anderes Fahrzeug in seine Fahrspur wechselt. 

In nachfolgenden Sprints verfeinern oder erweitern die Teams das Modell anhand von Kundenfeedback – beispielsweise, indem sie den Sicherheitsabstand zum Vorderfahrzeug anpassen oder die Beschleunigungs- oder Abbremsrate verändern – und optimieren es für die Codegenerierung und die Bereitstellung auf der ECU. Der generierte Code kann unverändert genutzt oder im Rahmen eines größeren Systems in Legacy-Code integriert werden. Kontinuierliche Integration (CI) mit Jenkins™ wird verwendet, um kontinuierlich die Integration generierten und manuellen Codes zu überprüfen, das Modell zu testen, die Einhaltung von Modellierungsrichtlinien zu prüfen und später Tests auf dem generierten Code durchzuführen. Ergebnisse all dieser Aktivitäten werden automatisch in Berichten abgelegt. Diese können zur Nachverfolgung des Fortschritts genutzt werden und Beteiligten zur Verfügung gestellt werden, die keine Entwicklungstools verwenden.

In späteren Sprints beziehen die Teams strengere Verifikations- und Validierungsaktivitäten ein, darunter SIL-, PIL- oder HIL-Tests, um sicherzustellen, dass der Entwurf die Anforderungen erfüllt. Außerdem überprüfen sie, ob die Modelle und der Code etablierten Standards und Richtlinien genügen, verwenden statische Analysen und formale Methoden, um die Abwesenheit kritischer Laufzeitfehler zu beweisen, und erstellen Berichte und andere Artefakte zur Vorbereitung für Zertifizierungen nach Standards.

Die Anforderungen des Kunden können sich im Laufe des Projekts verändern. Beispielsweise kann der Kunde eine modellprädiktive Regelung (MPC) statt eines klassischen Steuerungsalgorithmus verlangen, weil das Fahrzeug mit einer fortschrittlichen MPC auf aggressivere Manöver anderer Fahrzeuge in der Umgebung reagieren kann. Da in diesem Projekt ein Systemmodell verwendet wird, kann das Algorithmenteam leicht den ursprünglichen Steuerungsalgorithmus durch eine neu entwickelte modellprädiktive Regelung ersetzen und den Rest des Modells unverändert lassen. Das Team führt die Simulationen dann erneut aus und stellt die Ergebnisse dem Kunden zur Verfügung. Nun kann eine fundierte Entscheidung darüber getroffen werden, ob die Entwurfsänderung übernommen wird oder ob zum vorherigen Ansatz zurückgekehrt werden soll.

Dieses Team verwendete Model-Based Design in seinem agilen Entwicklungs-Workflow und stellte funktionierende Software bereit, lange bevor Hardware einbezogen wurde. Mithilfe von Modellierung und Simulation konnte das Team den Entwurf anhand von Kundenfeedback kontinuierlich verbessern und sogar eine wesentliche Anforderungsänderung berücksichtigen, die erst spät im Projekt erfolgte.