Suchen

Agile Softwareentwicklung für Fahrerassistenz & Umfeldmodell

| Autor / Redakteur: Hartmut Liefke* / Martina Hafner

Die Entwicklung von neuen Fahrerassistenzfunktionen im Automobil basiert zunehmend auf der Gestaltung hochkomplexer Embedded Software-Lösungen. Eine wesentliche Herausforderung sind hierbei die zumeist zu Beginn nur grob formulierten Anforderungen, welche dann in lauffähigem Software-Systemen in realen Fahrsituationen iterativ weiter konkretisiert und hinsichtlich Machbarkeit bewertet werden.

Firmen zum Thema

Die logische Architektur des Umfeldmodells und die dort enthaltenen Funktionalitäten.
Die logische Architektur des Umfeldmodells und die dort enthaltenen Funktionalitäten.
( BMW AG)

Die BMW AG setzt hierbei zunehmend auf agile SW-Entwicklungsmethoden, um den hohen Anforderungen an Flexibilität und Entwicklungsgeschwindigkeit gerecht zu werden. Dies wird anhand der Entwicklung des Umfeldmodells illustriert.

Moderne Fahrerassistenzsysteme zeichnen sich durch einen rasant wachsenden Anteil komplexer Software-Umfänge aus. Dies folgt zum einen aus der Verfügbarkeit immer leistungsfähigerer und kostengünstigerer Hardware (sowohl bzgl. Rechenleistung, als auch Sensorik), zum anderen aus der wachsenden Nachfrage der Kunden nach innovativen Fahrerassistenzfunktionen. Die effiziente und flexible Entwicklung dieser Systeme ist eine der großen zukünftigen Herausforderungen für die Automobilindustrie.

Das Umfeldmodell als zentrale Komponente der Fahrerassistenz-Software

Moderne Fahrzeuge besitzen bereits heute eine Vielzahl unterschiedlicher Sensoren (Kamera, Ultraschall, Lidar, Radar, etc.), welche jeweils Teilausschnitte der Umgebung erkennen. Eine zentrale Aufgabe der Fahrerassistenzentwicklung bei BMW ist die Fusion der unterschiedlichen Sensorikdaten zu einem einheitlichen Umfeldmodell. Dieses stellt Informationen zu bewegten Objekten, statischen Hindernissen, Straßenverläufen etc. den darüber liegenden Fahrerassistenzfunktionen zentral bereit.

Die Entwicklung erfolgt in C++, und als Betriebssystem-Plattform kommt AUTOSAR zum Einsatz. Die entwickelte Software wird im Rahmen der Absicherung auf verschiedenen Plattformen auf ihre funktionale Korrektheit geprüft, u.a. am Entwickler-PC, in einer Hardware-In-The-Loop-Umgebung (HiL) und in Erprobungsfahrzeugen.

Entwicklung des Umfeldmodells nach Agilen Methoden

Im Rahmen der Umfeldmodell-Software-Entwicklung wurden fünf Feature-Teams mit jeweils zwischen sechs und acht Mitarbeitern eingeführt. Als initiales Arbeitsmodell wurde „Plain Vanilla“ Scrum mit den Rollen Product Owner, Scrum Master und Entwickler eingeführt. Der Planung und Bearbeitung der Themen liegt ein entsprechender Backlog und eine eigene Definition of Ready und Definition of Done zugrunde. Die Sprints werden im zweiwöchentlichen Rhythmus durchgeführt.

Von zentraler Bedeutung für eine effiziente Arbeit ist hierbei die transparente, gegenüber den „Kunden“ (in Falle des Umfeldmodells: Kundenfunktionsverantwortlichen) vertretene Priorisierung des Backlogs und Sicherstellung der entsprechenden Planungsstabilität in den Sprints.

Scrum ermöglicht in der Umfeldmodell-Software-Entwicklung einerseits einen wesentlichen besseren Umgang mit spät definierten Anforderungen. Anderseits sind signifikant schnellere Feedback-Schleifen zwischen Anforderungsklärung, Software-Entwicklung und den funktionalen Tests möglich. Die Einführung von Scrum in der Entwicklung von automotive embedded Software ist jedoch auch mit einigen Herausforderungen verbunden, die entsprechende Anpassungen erfordern:

Einschränkungen durch Hardware-Ressourcen: Die verfügbare Hardware besitzt (insb. aufgrund von Bauraum, Energiemanagement- und Kostengründen) zumeist eine im Vergleich zu Business-IT-Systemen eingeschränkte Leistungsfähigkeit. Anforderungen an die Hardware (RAM/ROM/CPU) und Sensorik (z.B. Erkennungsraten) müssen somit einerseits frühzeitig definiert und mit den Komponenten- und Sensoriklieferanten abgestimmt werden. Andererseits muss der Ressourcenverbrauch während der agilen Entwicklung streng überwacht werden.

Wasserfall-/V-Modell für klassische Elektrik-/Elektronik-Entwicklung: Für die Architektur, Entwicklung und Integration von Komponenten kommt zumeist ein nicht-agiles Vorgehensmodell, z.B. der V-Modell-Ansatz, zum Einsatz. Hierbei existieren in der Regel fest definierte Meilensteine für Architekturfestlegungen und die Integration der Steuergeräte (und deren Software) in Teilsystemen oder im Gesamtfahrzeug. Dies betrifft insbesondere auch die Zusammenarbeit mit den Komponentenlieferanten, z.B. bei der Integration der Software.

Trennung zwischen Funktions- und Softwareentwicklung: Die in der Fahrerassistenz-Software implementierten (Regel-)Algorithmen erfordern ein tiefes Verständnis von Mathematik (insb. Stochastik) und Regelungstechnik. Oft werden deshalb die funktionale Modellierung (z.B. von Reglern oder mathematischen Filtern) und die Software-Entwicklung (Optimierung und Integration dieser Funktionalitäten ins Fahrzeug) von unterschiedlichen Rollen und Personen (mit unterschiedlichen Expertenkenntnissen) auf Basis unterschiedlicher Werkzeuge (Matlab vs. C++-Entwicklungsumgebung) durchgeführt.

Bei der Einführung von Scrum im Umfeldmodell wurde ein entsprechender kontinuierlicher Verbesserungsprozess etabliert, um diese Herausforderungen schrittweise zu adressieren und das Arbeitsmodell entsprechend den Gegebenheiten zu optimieren. Im Wesentlichen haben sich folgende Erfolgsfaktoren für eine nachhaltige Einführung von Scrum für Fahrzeug-Software-Entwicklung heraus kristallisiert:

Arbeit in interdisziplinären Feature Teams: Die Trennung zwischen Funktions- und Softwareentwicklung wird durch die Einführung der Feature Teams aufgehoben, d.h. die Feature Teams verantworten das grundlegende Algorithmendesign, die Optimierung der Software auf der Hardware, wie auch die Absicherung auf PC-, HiL- und Fahrzeugebene. Zentrales Ergebnis der Teamarbeit ist somit getestete, im Fahrzeug erprobte Software.

Durch die hohe technische Komplexität, einschließlich der Vielzahl von Technologien, Entwicklungswerkzeugen und unterschiedlichen Absicherungsstufen, gibt es in den interdisziplinären Teams einzelne Experten für bestimmte Tätigkeiten. Wichtig hierbei ist jedoch, dass durch das Gesamtteam alle Aufgabenumfänge abgedeckt werden können.

Frühzeitige Festlegung von Architekturprämissen: Die Embedded Welt stellt mit ihren Hardware-Einschränkungen und -Anforderungen hinsichtlich funktionaler Sicherheit weitreichende Anforderungen an den Architekturprozess. Es ist deshalb unerlässlich, vor dem eigentlichen Beginn der Softwareentwicklung wesentliche Architekturentscheidungen zu treffen und als Eingangsprämissen für die agile Softwareentwicklung festzulegen.

Ziel ist es jedoch, die Einschränkungen für die agile Entwicklung so gering wie möglich zu halten, sowie an der Architektur auch Anpassungen zu ermöglichen.

Lose Kopplung zu benachbarten, nicht agilen Prozessen: Grundsätzlich funktioniert Scrum gut, wenn die Schnittstellen zu benachbarten, nicht agilen Prozessen möglichst klein gehalten werden können – z.B. wenn Entscheidungen bezüglich Software-Schnittstellen agil innerhalb oder zwischen den Feature Teams getroffen werden können. Für die Mitarbeit in nicht agilen Prozessen (Architektur, Komponenten- und Fahrzeugintegration, Auslandserprobungen, etc.) werden im Backlog und den Sprints entsprechende Arbeitsblöcke eingeplant.

Das zur Abbildung einer Kundenfunktion immer stärker notwendige Zusammenspiel verschiedenster verteilter Software-Umfänge im Fahrzeug führt jedoch zwangsläufig zu einem wachsenden Handlungsdruck, etablierte Entwicklungsprozess für agile Methoden zu öffnen. Hierfür ist jedoch die entsprechende Unterstützung des Managements erforderlich.

Continuous Integration mit dem Komponentenlieferanten: Ziel muss es sein, die festen Meilensteine zur Abgabe von Software-Stände durch einen Continuous Integration Process zu ersetzen. Änderungen in der Software (sowohl bei BMW als auch beim Lieferanten) können mit der entsprechenden Build-Infrastruktur in die Software-Stände integriert, auf die Target-Hardware eingespielt und dort getestet werden.

Fazit

Die Einführung von agilen Methoden steht nicht im Widerspruch zur embedded Software-Entwicklung und ergänzt bzw. ersetzt teilweise die heutigen, nicht-agilen Vorgehensmodelle in der Fahrzeug-Software-Entwicklung. Dadurch können viele Vorteile von agilen Methoden in die Fahrzeugentwicklung übertragen werden.

Durch das spezifische Umfeld in der Fahrzeugentwicklung müssen jedoch die Methoden angepasst werden. Weiterhin erfordert die Ausweitung der agilen Methoden auf größere, im Fahrzeug verteilte Software-Umfänge eine Weiterentwicklung und Agilisierung in den heutigen Fahrzeugentwicklungsprozessen einschließlich der Zusammenarbeit mit den Komponentenlieferanten. Hierzu ist die Unterstützung durch das Management ein entscheidender Erfolgsfaktor.

* Hartmut Liefke ist bei der BMW AG als Leiter für die Embedded Software Entwicklung des Umfeldmodells in der Fahrerassistenz verantwortlich. Mit freundlicher Genehmigung wurde dieser Beitrag dem Tagungsband Embedded Software Engineering Kongress 2014 entnommen.

(ID:43690817)