Änderungen während der Softwareentwicklung leicht gemacht

Anbieter zum Thema

Anwendungsfall: Entwicklung eines adaptiven Tempomats

Ein Team von Automobilingenieuren entwickelte 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.

Eine Gruppe von Ingenieuren erarbeitete die Steuerungsalgorithmen, während eine andere Fahrszenarien und synthetische Sensordaten entwickelte. Mithilfe dieser synthetischen Daten konnten die Ingenieure die Algorithmen schon entwickeln und testen, lange bevor tatsächliche Sensordaten verfügbar waren. 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 sie ein gemeinsam genutztes Simulink-Modell auf Systemebene, um ihre Arbeit zu koordinieren (Bild 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.

Ende erster Sprint: Darstellung der funktionierenden Software

In einem Review-Meeting mit dem Kunden gegen Ende des ersten Sprints zeigen sie ihm das Modell und die Simulationsergebnisse (Bild 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. Die Ergebnisse all dieser Aktivitäten werden automatisch in Berichten abgelegt. Diese können zur Nachverfolgung des Fortschritts genutzt und Beteiligten zur Verfügung gestellt werden, die keine Entwicklungstools verwenden.

Spätere Sprints: Testen, ob Entwurf die Anforderungen erfüllt

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.

Definitionen Agile Softwareentwicklungsmethoden basieren auf den zentralen Werten und Prinzipien, die im Agile Manifesto von 2001 umrissen sind. Heute ist Scrum eines der am häufigsten verwendeten Frameworks für die agile Entwicklung. In Scrum besteht die Entwicklung aus einer Abfolge von Zyklen, die als Sprints bezeichnet werden. Für jeden Sprint ist ein Zeitfenster festgelegt, in dem das Team funktionierende Software entwickelt, testet, integriert und dokumentiert.
Model-based Design ist ein modellzentrierter Ansatz für die Entwicklung von Systemen. Es verwendet keine physischen Prototypen und Spezifikationen in Textform für die Kommunikation, sondern arbeitet mit einem Modell, das alle Komponenten, die für das Systemverhalten relevant sind, umfasst. Nachdem das Modell entwickelt (ausgearbeitet) wurde, kann es verwendet werden, um Code, Berichte und andere Arten von Dokumentation zu generieren. Die zentralen Komponenten des Model-based Designs sind der Entwurf und die Simulation auf System- und Komponentenebene, die Codegenerierung sowie das ständige Testen und Verifizieren.

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 Algorithmen-Team 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.

Funktionierende Software existiert vor Hardware

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.

Mit einer solchen Vorgehensweise ist die Projektdauer besser vorhersehbar. Je nach Projektzeit, Projektanforderungen und Komplexität lässt sich die Effizienz um 25 bis 40 % steigern. Zudem enden Projekte nicht mit zeitaufwändigem Debuggen/Testen. Die Methode kann generell für alle Produkte eingesetzt werden. Die größten Vorteile bietet sie, wenn es Unsicherheiten gibt, wenn Anforderungen sich ändern oder zu Beginn unklar sind oder wenn die Ziel-Hardware nicht festgelegt ist oder austauschbar sein soll.

* Roger Aarenstrup ist Senior Consultant und Gaurav Tomar ist Automotive Industry Marketing Manager bei Mathworks. Weitere Informationen: The Mathworks GmbH in 85737 Ismaning, Tel. (0 89) 45 23 56 700

(ID:46059494)