Neue Software, aber bitte schnell!

Einsatz der testgetriebenen Entwicklung in Automobilanwendungen

Digitalisierung , Elektrifizierung, Konnektivität, autonomes Fahren – Automobilerstausrüster und deren Zulieferer befinden sich in einem der größten Paradigmenwechsel. Die Wertschöpfungskette verändert sich. Sind die bisherigen Innovations- und Entwicklungsprozesse schnell und flexibel genug für diese rapide Veränderung?

Aktuell akzeptiert der Markt noch die herkömmlichen Entwicklungszyklen der großen Automobilmarken. Immer mehr Nutzer sind allerdings eine wesentlich höhere Innovationsgeschwindigkeit aus dem Bereich der Konsumelektronik gewohnt. Insgesamt betrachtet müssen Automobilunternehmen also in Zukunft in Märkten bestehen, die eine deutlich höhere Dynamik als bisher aufweisen.

Weil Software für die Produktdifferenzierung immer wichtiger wird, wird auch die Softwareentwicklung immer mehr zur Kernkompetenz für die Automobilwelt. Agile Entwicklungsmethoden, wie die testgetriebene Entwicklung (en: test-driven development, TDD), die mit dem Vordringen der Software ebenfalls in die Automobilbranche schwappen, stellen eine Herausforderung dar, aber auch eine große Chance, den Wandel zu bewältigen.

Test-driven Development

Kosteneinsparung und bessere Codequalität

Die testgetriebene Entwicklung unterscheidet sich vor allem dahingehend von anderen Testmethoden, dass Tests noch vor dem Programmcode selbst erstellt werden. Für den Entwickler bedeutet das, die Testfälle ausgehend von den Anforderungen und den Schnittstellen zu betrachten und nicht vonseiten des Codeaufbaus her an die Testfälle heranzugehen.

Der Einsatz der testgetriebenen Entwicklung kann mehrere Vorteile für ein Projekt bringen, wie z. B. geringere Entwicklungskosten, eine höhere Qualität der Software und eine kürzere Zeit bis zur Markteinführung. In einer detaillierten Analyse der Universität Helsinki wurden die Auswirkungen der testgetriebenen Entwicklung über mehrere Kategorien der Softwareentwicklung hinweg gemessen. Dabei konnte in diversen Kategorien der Softwareentwicklung eine höhere Effektivität der TDD im Vergleich zu herkömmlichen Methoden nachgewiesen werden [1].

 

Bild 1 – Helsinki Report: Testgetriebene Entwicklung kann die Menge der Defekte reduzieren und zu wartungsfreundlicherem Code führen.

Da sich in der Automobilwelt der Schwerpunkt der Wertschöpfung weg von den klassischen Elementen des Fahrzeugbaus hin zu modernen softwaredefinierten Autos entwickelt, wird die Fähigkeit der OEMs und ihrer Zulieferer, die Softwareentwicklung auszubauen und gleichzeitig die Qualität und (Sicherheits-) Konformität zu erhalten, entscheidend sein, um mit den Branchenanforderungen Schritt halten zu können.

McKinsey gibt an, dass bis zum Jahr 2030 im Durchschnitt 30 % der Entwicklungskosten eines Fahrzeugs auf Software entfallen werden [2].

 

Bild 2 – McKinsey erwartet, dass Software bis 2030 fast 30% des gesamten Fahrzeugs ausmachen wird.

Als Konsequenz werden Methoden zur Softwareentwicklung, die eine Skalierung der Softwareentwicklung bei niedrigen Kosten und hoher Qualität ermöglichen, entscheidend sein. Diese Herausforderung kann mit der testgetriebenen Entwicklung gemeistert werden.

Cyber-physical Systems

Zerlegen von komplexen Systemen in handhabbare Komponenten

In Fahrzeugen eingesetzte moderne Systeme werden oft als cyber-physisches System (CPS) bezeichnet, da sie nicht nur eine funktionale Tätigkeit ausführen, sondern auch mit dem Internet verbunden sind. Dies ermöglicht Over-the-Air-Software-Updates, Anbindung von Fahrzeugdiagnosesystemen zur vorbeugenden Wartung sowie F&E-Erweiterungen von Komponenten basierend auf Nutzungsdaten aus dem Feld. Somit laufen in der Steuerung alle softwareseitigen Aspekte des Systems zusammen, wobei spezifische Funktionen in größere Subsystemkomponenten und kleinere Softwarekomponenten (en: Software Components, SWC) zerlegt werden.

 

Bild 3 – Cyber-physical System

Dieser strukturierte Ansatz für das Design und die Entwicklung der Software ist vergleichbar mit traditionellen Softwareentwicklungsmethoden wie der modellbasierten Entwicklung. Da die Baugröße und das Gewicht im Automobilbereich möglichst gering sein müssen und die Sicherheitsanforderungen kontinuierlich steigen, wird das gesamte CPS und seine Subsysteme je nach den spezifischen Anforderungen eines OEM häufig weiter in kleinere Softwarekomponenten zerlegt oder zu einem einzelnen monolithischen System zusammengefasst.

Dieser ständige Wechsel der Architekturmodelle von CPS zu CPS bedeutet, dass der Einsatz eines Tools für die Entwicklung, die Iteration und die Veröffentlichung neuer Architekturmodelle entscheidend dafür ist, dass die Entwicklung ordnungsgemäß, schnell und effizient durchgeführt werden kann.

In der Automobilwelt ist AUTOSAR der Standard für die Entwicklung solcher Softwarearchitekturen. Die von Vector für die Entwicklung der Softwarearchitektur bereitgestellten Tools sind DaVinci Developer und PREEvision. Während DaVinci Developer auf die Entwicklung von AUTOSAR-Softwarekomponenten fokussiert ist, ermöglicht PREEvision die Entwicklung von Softwarearchitekturen als Teil eines Gesamtsystems, einschließlich Kommunikationsbussen wie CAN oder Ethernet. Für die codebasierte Entwicklung der Softwarekomponenten können generierte Header-Dateien und Implementierungsvorlagen als Ausgangspunkt verwendet werden.

Die Testpyramide

Effiziente Verteilung der Tests

Bild 3 – Testpyramide

Diese Herangehensweise mit der Systemarchitektur auf der obersten Ebene und der Softwarekomponenten-Architektur auf der unteren Ebene fügt sich gut in das Konzept der Testpyramide ein. Hierbei handelt es sich um eine Strategie, bei der die Softwaretests in Ebenen unterschiedlicher Granularität gruppiert werden. Im vorliegenden Fall wird die AUTOSAR Softwarekomponentenbeschreibung der Service- und API-Layer-Testebene zugeordnet, während die generierten Header-Dateien und Implementierungsvorlagen der Modultestebene (Unit Tests) zugeordnet werden. 

Wenn wir uns die Artefakte ansehen, die von den Tools erzeugt werden, so lässt sich dies gut auf die Ausgangsanforderungen für einen Prozess zur testgetriebenen Entwicklung abbilden. Bei der TDD-Methodik werden bereits Tests erstellt, noch bevor die Programmierer jedes einzelne Stück Code für ein Softwareprojekt geschrieben haben. Genau wie beim agilen Framework muss ein Projekt bei der testgetriebenen Entwicklung in kleine Iterationen unterteilt werden, aus denen jeweils eine lauffähige Komponente hervorgeht. 

Bei der Verwendung des testgetriebenen Ansatzes beginnen Entwickler, die an einem bestimmten Feature oder einer Komponente arbeiten, mit der Erstellung eines automatisierten Tests, der die Anforderungen an den zu schreibenden Code verifiziert. Dieser Test basiert auf den vorgegebenen Spezifikationen und Anforderungen für das jeweilige Feature oder die Komponente. 
Zu Beginn wird das Programm den Test nicht bestehen, da das Feature noch nicht erstellt wurde. Die Entwickler arbeiten dann an der Erstellung von Code, der den Test besteht. Sobald der Test erfolgreich ist, können sie den Code „bereinigen“ und dabei sicherstellen, dass der Code den Test weiterhin besteht.

Entwickeln von Softwarekomponenten (SWCs)

Test-driven Development mit VectorCAST

Wenn Sie eine Testumgebung mit VectorCAST erstellen, verweisen Sie einfach auf das Verzeichnis mit den Header-Dateien für die API, die Sie testen wollen. Dabei handelt es sich um die von DaVinci Developer erzeugten Header-Dateien. VectorCAST erstellt die Testumgebung automatisch, einschließlich der Smart-Stubs, der Mock-Objekte und des Treibercodes. So entsteht ein kompletter ausführbarer Test-Harnisch, der auf der Host-Plattform oder in einer Embedded-Entwicklungsumgebung ausgeführt werden kann. Noch wichtiger ist, dass VectorCAST den Code beim Iterieren durch die Entwicklungszyklen für jede implementierte Funktion automatisch in die Testumgebung einfügt, während sie entwickelt wird. 

 

Mehr zum Thema “Test-driven Development” erfahren Sie in folgendem Whitepaper:

Entwickeln von Cyber-physical Systems (CPSs)

Test-driven Development mit vTESTstudio und CANoe

vTESTstudio und CANoe stellen eine vielseitige und integrierte Arbeitsumgebung zur Entwicklung von Tests für eingebettete Systeme bereit. Bei der Konfiguration der Umgebung zum Testen des Service-Layers oder der API eines CPS können Sie einfach auf die AUTOSAR-Softwarekomponentenbeschreibung von PREEvision oder DaVinci Developer verweisen. Diese stellt den Tools alle Daten zur Verfügung, die erforderlich sind, um die öffentlichen Schnittstellen der Softwarekomponenten eines CPS anzusteuern. vTESTstudio ermöglicht es dem Tester dann, das Verhalten der externen Ports (z. B. Eingangsnachrichten und erwartete Ausgangsnachrichten auf den Schnittstellen) zu modellieren und die Tests dann in CANoe automatisiert ablaufen zu lassen.

Ähnlich wie bei den Tests, die bei jedem Hinzufügen von neuem Code erneut für die Softwarekomponente ausgeführt werden, können die Tests mit vTESTstudio und CANoe nach dem Hinzufügen neuer Funktionen ebenfalls erneut ausgeführt werden. Dabei wird sichergestellt, dass die Softwarekomponenten alle Anforderungen erfüllen und dass keine vorhandene Funktion beschädigt wurde. Wenn das Verhalten einer Softwarekomponente von einer anderen, nicht vorhandenen Funktion abhängig ist, kann diese mit CANoe simuliert werden. Die Entwicklung der Softwarekomponenten kann so über Abteilungen oder Lieferanten hinweg parallelisiert und verteilt werden, wobei alle auf der Grundlage einer vereinbarten Schnittstelle arbeiten, die in PREEvision automatisch basierend auf einem formal vereinbarten Design generiert wurde. 

Continuous Integration

Mit VectorCAST/QA alles in einem kontinuierlichen Integrations- und Test-Workflow zusammenführen

Die kontinuierliche Integration und das kontinuierliche Testen sind wesentliche Bestandteile der testgetriebenen Entwicklung. Jeder Entwickler integriert Änderungen (1) in das Source-Code-Repository, sobald sie zum Testen bereit sind, was zu mehreren Integrationen pro Tag führt. Jede Integration wird dann durch einen automatisierten Build- (3) und Testschritt (4) verifiziert, um Integrationsfehler (5) so schnell wie möglich zu erkennen. Dieser Ansatz führt zu deutlich weniger Integrationsproblemen, sodass das Projektteam in kürzerer Zeit mehr Software entwickeln kann.

 

Bild 5 – Continuous Integration: Neue Programmteile können sofort getestet und zusammengeführt werden. Fehler lassen sich dadurch in einem sehr frühen Stadium lokalisieren und mit überschaubarem Kosten- und Zeitaufwand beheben.

VectorCAST/QA ist das ideale Tool für die Unterstützung von kontinuierlicher Integration und kontinuierlichen Tests, da Entwicklungsteams Regressionstestsuiten aus zuvor entwickelten VectorCAST- und vTESTstudio/CANoe Testumgebungen erstellen und so einen einzigen Kontrollpunkt für alle Modul-, Integrations- und Funktionstests schaffen können. Protokolle, Übersichtsberichte und farbkodierte Pass/Fail-Kriterien heben den Status jedes einzelnen Tests innerhalb der Regressionssuite übersichtlich hervor. Trendberichte sind ebenfalls verfügbar, um den Testfortschritt über der Zeit darzustellen.

Fazit

Mit dem wachsenden Trend zum softwaredefinierten Fahrzeug werden Prozesse wie die testgetriebene Entwicklung entscheidend sein, um die Entwicklungskosten dieser Systeme niedrig zu halten. Durch die Schaffung eines automatisierten Workflows von der Konzeption über die Modellierung des Gesamtsystems und die weitere Zerlegung in Softwarekomponenten können wir APIs auf Service- und Modul-Ebene in einem automatisierten, wiederverwendbaren Prozess definieren.

Mit dieser Fähigkeit und mit Tools wie VectorCAST und vTESTstudio/CANoe können wir mit der Spezifikation und Erstellung von Testfällen auf der Basis von Anforderungen beginnen. Der zu testende Code muss dabei nicht vorhanden sein. Es sind lediglich die veröffentlichten APIs in Form von AUTOSAR-Systembeschreibungen für den Service-Layer und die Header-Dateien für den Modul-Layer erforderlich. Da diese Tools auch für die Testfallausführung und die Analyse der Ergebnisse eingesetzt werden können, fügen sie sich gut in die Arbeitsabläufe zur kontinuierlichen Integration und zum kontinuierlichen Testen ein. So entsteht ein vollautomatischer Prozess von der Designspezifikation bis hin zur korrekten Implementierung bei jedem Softwareupdate.

--------------------

Quelle:

[1] Mäkinen, Simo & Münch, Jürgen: Effects of Test-Driven Development : A Comparative Analysis of Empirical Studies. January 14-16, 2014. https://helda.helsinki.fi/handle/10138/42741 

[2] Aaron Aboagye, Russell Hensley, Asutosh Padhi and Danish Shafi: Facing digital disruption in mobility as a traditional auto player. December 2017. https://www.mckinsey.com/industries/automotive-and-assembly/our-insights/facing-digital-disruption-in-mobility-as-a-traditional-auto-player

Empfohlene Seiten

CANoe

Entwickeln und Testen von Steuergeräten und Netzwerken auf höchstem Niveau.

Zur Seite gehen
DaVinci Developer

Architektur-Entwurf der Softwarekomponenten (SWCs) für AUTOSAR-Steuergeräte.

Mehr Informationen
PREEvision|Die E/E-Engineering-Lösung

Modellbasierte Entwicklung verteilter, eingebetteter E/E-Systeme in der Automobilindustrie.

Zur Seite gehen
VectorCAST

Testaktivitäten im Softwareentwicklungsprozess einfach automatisieren.

Zur Seite gehen
vTESTstudio

Komfortables Erstellen automatisierter Testabläufe für eingebettete Systeme.

Zur Seite gehen