Innovation durch Offenheit
Software-Entwicklung im Automobilbereich neu gedacht
Die Zukunft der Software-Entwicklung im Automobilbereich liegt in der konsequenten Etablierung kollaborativer Ansätze. Durch klare organisatorische Rahmenbedingungen und optimierte Prozesse sind eine offene Zusammenarbeit mit Code-First-Arbeitsweise sowie höchste Qualitätsanforderungen vereinbar.
Im Bereich der Software-Entwicklung ist die Kollaboration in Code-Repositories ein wichtiger Innovationstreiber. Die Zusammenarbeit an Quellcodeartefakten erfolgt über Organisationsgrenzen hinweg, manchmal sogar branchenübergreifend zwischen Einzelpersonen, Universitäten und Unternehmen. Den organisatorischen Rahmen für diese Kollaboration bilden häufig Open-Source-Projekte [1].
Eine Branche, die sich bislang eher schwer damit getan hat, Quellcode mit anderen Firmen zu teilen und insbesondere Beiträge von »außen« in die eigenen Software-Produkte zu integrieren, ist die Entwicklung von Embedded-Software im Automobilbereich. Dies mag daran liegen, dass hier hohe Anforderungen an die Qualität und Nachvollziehbarkeit der Prozessartefakte gestellt werden. Dennoch bietet die Zusammenarbeit im Quellcode auch im Bereich der automobilen Software-Entwicklung ein großes Innovationspotential.
Jobangebote+ passend zum Thema
Einsatz von Code-First in der Automobilindustrie
Zunächst ist es wichtig, die Entwicklungsansätze bei der Kollaboration in einer offenen Umgebung einerseits und der geschlossenen Entwicklung im Automobilbereich andererseits zu unterscheiden. Die offene Kollaboration an gemeinsam genutzten Quellcodeartefakten, wie sie beispielsweise in Open-Source-Projekten praktiziert wird, erfolgt normalerweise nach einem »Code-First«-Ansatz. Änderungen werden in Form von Quellcode vorgeschlagen und – wenn die Maintainer des Projekts sie für gut befinden – in das Projekt integriert. Der Code-First-Ansatz basiert auf der frühzeitigen Bereitstellung von Funktionen und deren Verfeinerung auf Grundlage von Kundenrückmeldungen oder sonstigen Erfahrungen im Projektkontext.
Der Ansatz stellt keine oder nur geringe Anforderungen an Prozessartefakte außerhalb des Quellcodes, beispielsweise Anforderungsspezifikation, Testabdeckung, Dokumentation und Traceability. Dies ermöglicht es Entwicklern, Quellcode beizusteuern, auch wenn sie nicht in den besonderen Prozessen der Automobilindustrie geschult sind. Dadurch wird eine breite Kollaboration ermöglicht.
Im Automobilbereich dominiert in der Embedded-Software-Entwicklung bislang ein Ansatz, der als »Code-Right« bezeichnet werden kann und der sich am V-Modell [2] orientiert. Die Implementierung von Funktionen erfolgt auf Basis einer zuvor definierten Spezifikation. Während des Entwicklungsprozesses werden alle prozessrelevanten Artefakte erzeugt, um sicherzustellen, dass die Software die Anforderungen für die Freigabe und die Serienproduktion vollständig erfüllt. Beide Ansätze haben in bestimmten Situationen Vorteile, die in Tabelle 1 gegenübergestellt sind.
| Eignung des Ansatzes | |
|---|---|
| Code-First |
|
| Code-Right |
|
Tabelle 1. Übersicht über die Eignung der Entwicklungsansätze Code-First und Code-Right.
Wenn im Kontext von Automotive-Software ein Wechsel von einem Code-Right- zu einem Code-First-Ansatz angestrebt wird, müssen die Anforderungen an den Prozess weiterhin berücksichtigt werden. Das bedeutet, dass auf der Grundlage des kollaborativ erstellten Quellcodes anschließend eine Härtung durch den Maintainer der Software-Komponente erfolgen muss, in der die notwendigen Prozessschritte durchlaufen und die erforderlichen Artefakte erstellt werden.
Dieser Härtungsschritt ist vergleichbar mit der Härtung von Systemen gegenüber Angriffen von außen [3]. Er wird hier jedoch ganzheitlich betrachtet und umfasst neben der Sicherheit (Security) auch die Zuverlässigkeit der Software und die funktionale Sicherheit (Safety). Auf der Grundlage des gehärteten Quellcodes kann dann wieder eine kollaborative Weiterentwicklung erfolgen (Bild 1).
Entscheidend ist, dass der Härtungsschritt nicht nur eine nachträgliche Dokumentation darstellt. Möglicherweise muss die Funktionalität weitgehend neu entwickelt werden, um die Prozessanforderungen zu erfüllen. Ein Code-First-Ansatz ist daher nicht in jedem Fall eine Maßnahme, um die Entwicklungskapazität durch Beiträge von außen zu steigern. Vielmehr geht es darum, Innovationen durch externe Beiträge zuzulassen und diese dann nachgelagert abzusichern.
Organisatorische Rahmenbedingungen für Code-First
Eine kollaborative Entwicklung auf der Grundlage des Code-First-Ansatzes kann innerhalb verschiedener organisatorischer Rahmenbedingungen erfolgen. Diese reichen von einem öffentlichen Repository, beispielsweise im Rahmen eines Open-Source-Projekts oder auch unter einer von der Open-Source-Definition (OSD) [4] abweichenden »Source-Available«-Lizenz, bis hin zu einem Community-Ansatz, bei dem in einem geschlossenen Kreis mit Partnern gemeinsam am Quellcode gearbeitet wird. Eine weitere Option ist die Partner-Entwicklung, bei der ein Unternehmen ausgewählten Kunden Zugriff auf das eigene Code-Repository gewährt, so dass diese aktiv mitwirken können.
| Organisatorischer Rahmen | Verwertungsrechte |
|---|---|
| Open-Source-Projekt | Open-Source-Lizenz |
| Source-Available-Projekt | Von OSD abweichende Source-Available-Lizenz mit eingeschränkten Verwertungsrechten, zum Beispiel Einschränkung der Verwertung auf nicht-kommerzielle Zwecke |
| Community-Entwicklung | Regeln der Community definieren die Verwertungsrechte |
| Partner-Entwicklung | Inhaber des Code-Repositories behält die vollen Verwertungsrechte |
Tabelle 2. Regelungen der Verwertungsrechte für einen Code-First-Ansatz.
Entscheidend ist, dass die Verwertungsrechte im Zusammenhang mit dem jeweiligen organisatorischen Rahmen klar geregelt sind – sowohl in Bezug auf die Nutzung des gesamten Quellcodes als auch in Bezug auf die in das Repository eingebrachten Beiträge. Typische Regelungen für die genannten organisatorischen Modelle sind in der Tabelle 2 zusammengefasst.
Im Kontext der Partner-Entwicklung stellt sich die Frage, ob es im Interesse der Kooperationspartner liegen kann, zu einem Quellcode beizutragen, dessen Verwertung ausschließlich der anderen Partei vorbehalten ist. Eine solche Situation liegt vor, wenn ein Kunde die Innovation eines von ihm verwendeten Produkts fördern möchte, ohne selbst ein kommerzielles Interesse an der Vermarktung oder Verwertung des Produkts zu haben.
Qualität und Prozess bei einer Code-First-Arbeitsweise
Wie bereits erwähnt, steht bei Code-First die Förderung der Zusammenarbeit im Vordergrund und weniger die Effizienzsteigerung durch externe Beiträge. Insofern erfordert der Code-First-Ansatz einen möglichst schlanken Prozess, um den Entwicklungspartnern einen niederschwelligen Einstieg zu ermöglichen.
Dennoch ist es ein wichtiges Ziel, dass der beigesteuerte Quellcode weitgehend übernommen werden kann. Nur so kann vermieden werden, dass sich im nachgelagerten Härtungsschritt herausstellt, dass die Implementierung für den Einsatz in Seriensoftware völlig ungeeignet ist. Um dies zu gewährleisten, sollte der Maintainer gewisse Leitplanken hinsichtlich der Form des eingebrachten Quellcodes setzen:
Abstimmung über die Umsetzung: Zu Beginn ist eine Abstimmung zwischen den beitragenden Entwicklungspartnern und dem für den nachgelagerten Härtungsschritt der Software verantwortlichen Maintainer sinnvoll. Ziel dieser Abstimmung ist die Klärung der Frage, wie das geplante Feature optimal in den bestehenden Quellcode integriert werden kann, beispielsweise durch die Implementierung einer weiteren Unit. Handelt es sich um eine neue Komponente, sollte ein Produktarchitekt in den Prozess eingebunden werden. Dabei sollte die konsequente Anwendung der zentralen Designkonzepte des zugrunde liegenden Produkts im Vordergrund stehen und nicht die Einführung neuer Ansätze. Dies gilt insbesondere für etablierte Patterns wie die Fehlerbehandlung oder die Behandlung von Nebenläufigkeit.
Verwendung von statischer Code-Analyse: Die Vermeidung von Programmierpraktiken mit hohem Refactoring-Risiko wird durch den Einsatz statischer Code-Analyse unterstützt. Der Schwerpunkt liegt hierbei nicht auf einer umfassenden Analyse oder einer vollständigen Rechtfertigung aller Warnungen gemäß Standards wie MISRA. Stattdessen sollten nur kritische Meldungen unmittelbar behoben werden.
Testabdeckung: Da die für eine vollständige Testabdeckung erforderlichen Spezifikationsartefakte zum Zeitpunkt der Code-First-Entwicklung noch nicht verfügbar sind, sollten die Testfälle für die neue Funktionalität auf Grundlage der Erfahrung der Entwickler erstellt werden. Die Coverage-Messung lässt sich dabei als unterstützendes Werkzeug nutzen.
Vor der Übernahme des Codes durch einen Entwicklungspartner sollte eine Überprüfung und eine Freigabe durch den Maintainer erfolgen. Dabei werden sowohl technische Schulden, wie beispielsweise erforderliche Optimierungen in der Implementierung, als auch Prozessschulden, wie etwa fehlende oder unvollständige Prozessartefakte, dokumentiert.
Die Behebung der im Review identifizierten technischen Schulden sowie der Unvollständigkeiten bezüglich der Prozessartefakte erfolgt dann im nachgelagerten Härtungsschritt (Bild 1), so dass am Ende dieses Härtungsschritts ein voll qualifizierter Release mit allen Artefakten und Nachweisen vorliegt. Diese Vorgehensweise ist mit Aspice [5] und ISO 26262 [6] vereinbar, da beide Standards iterative Entwicklungsansätze unterstützen. Insbesondere die ISO 26262 erlaubt ausdrücklich eine schrittweise Verfeinerung, solange Sicherheitsaspekte von Anfang an berücksichtigt werden.
Mögliche Realisierung einer Code-First-Infrastruktur
Die Infrastruktur wird in einer Cloud-Umgebung betrieben, um den Entwicklungspartnern einen einfachen und schnellen Zugang zu ermöglichen. Dies stellt sicher, dass die benötigte Infrastruktur unabhängig von der jeweiligen lokalen Umgebung der Partner jederzeit verfügbar ist.
Bild 2 zeigt eine mögliche Umsetzung dieses Ansatzes: Die Infrastruktur umfasst ein extern zugängliches Repository für die Code-First-Phase sowie ein internes Repository, das ausschließlich der Maintainer für den Härtungsschritt einsetzt. Für beide Phasen werden speziell auf den jeweiligen Prozessumfang und die Anforderungen zugeschnittene Continuous-Integration-Pipelines (CI-Pipelines) zur Verfügung gestellt. Die Aufteilung in zwei getrennte Repositories ist jedoch nur eine denkbare Form der Umsetzung. Es ist ebenso möglich, dass externe Entwicklungspartner auf demselben Repository arbeiten wie die interne Entwicklung, indem ein Branch für die externe Kollaboration verwendet wird.
Die »Code-First CI-Pipeline« umfasst die für die Entwicklungspartner relevanten Schritte wie Build & Test, grundlegende statische Analysen sowie die automatische Generierung der Nutzerdokumentation. Diese Pipeline ist bewusst schlank gehalten. Das sorgt für eine schnelle Iteration und effizientes Feedback. Die enthaltenen Tools und Prozesse sind so gewählt, dass sie kurze Laufzeiten gewährleisten und den Entwicklungsprozess nicht ausbremsen. Die »Hardening CI-Pipeline« hingegen umfasst alle Prozessschritte zur Bereitstellung eines voll qualifizierten Releases. Dazu gehören umfangreichere statische Analysen, Security-Checks sowie eine detaillierte Verifikation der Artefakte. Die Hardening-Pipeline ist somit die Grundlage für eine robuste und fehlerfreie Auslieferung von Software.
Ein wesentliches Merkmal der Code-First-Infrastruktur ist die ausschließliche Verwendung textbasierter Artefakte, da dies den Einsatz gängiger Standardwerkzeuge der Software-Entwicklung für deren Review ermöglicht. Die Nutzung standardisierter Formate fördert zudem die Nachvollziehbarkeit und Wiederverwendbarkeit der Ergebnisse. Insgesamt unterstützt dieser Ansatz das agile Arbeiten, indem schnelle Iterationen ermöglicht und die Ergebnisqualität sichergestellt werden.
Die Zukunft der Software-Entwicklung
Die Zusammenarbeit über Unternehmensgrenzen hinweg ist ein entscheidender Treiber für die Zukunft der Software-Entwicklung. Großes Potenzial liegt darin, kollaborative Ansätze weiter zu etablieren und bestehende Hürden abzubauen. Ein offener Austausch und die hohen Qualitätsanforderungen im Automobilbereich lassen sich durch klare organisatorische Rahmenbedingungen und geeignete Prozesse erfolgreich miteinander vereinbaren. Entscheidend dafür ist die Einführung entsprechender Entwicklungs-Pipelines, um eine Code-First-Infrastruktur schnell und einfach umzusetzen.
Literatur
[1] Eric von Hippel (2005). Democratizing Innovation. 2. Auflage. ISBN 0-262-00274-4. The MIT Press.
[2] Barry W. Boehm (1979). Guidelines for Verifying and Validating Software Requirements and Design Specifications. In: Euro IFIP 79. North Holland.
[3] Claudia Eckert (2014). IT-Sicherheit. 9. Auflage. ISBN 978-3-486-77848-9. De Gruyter.
[4] Open Source Initiative. The Open Source Definition.https://opensource.org/osd. (Zugriff am 17.12 2024)
[5] VDA Working Group (2023). Automotive SPICE Process Assessment / Reference Model. Version 4.0. VDA QMC.
[6] International Organization for Standardization (2018). Road vehicles – Functional safety. 2. Auflage. ISO 26262:2018.
Die Autoren
Dr. Constantin Christmann
ist Gruppenleiter im Produktmanagement bei Vector Informatik. Nach seinem Studium der Medieninformatik an der Universität Ulm war er als wissenschaftlicher Mitarbeiter am Fraunhofer IAO tätig und promovierte an der Universität Stuttgart. Anschließend sammelte er bei Vector Informatik umfassende Erfahrungen in Produktmanagement und Entwicklung im Bereich der Embedded-Software. Seine Expertise umfasst sowohl technische als auch strategische Aspekte der Softwareentwicklung für Embedded-Systeme im Automobilbereich und deren Umsetzung in marktfähige Produkte.
Hartmut Hörner
ist Gruppenleiter in der Entwicklung bei Vector Informatik. Nach seinem Studium der Elektrotechnik an der Universität Stuttgart war er bei Wandel & Goltermann im Umfeld Messtechnik für Kommunikationsnetze tätig. Anschließend arbeitete er bei Vector Informatik an verschiedenen Themen in der Entwicklung im Bereich der Embedded-Software sowie den entsprechenden Entwicklungsprozessen und Infrastrukturen.
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
تقرير الأمن السيبراني للسيارات
خسائر بالمليارات بسبب هجمات سيبرانية على قطاع السيارات
Razorcat unterstützt AbixX HiperSIM
Software-Verifikation für MLX16-basierte Automotive-Systeme
Schlüsseltechnologie fürs Bordnetz
ZF bringt Glasfasertechnik ins Fahrzeug
Automotive Cybersecurity Report
Milliardenschäden durch Cyberattacken in der Automobilindustrie
Sicherheit beim autonomen Fahren
Board-to-Board-Verbindung von Steuergeräten
Thermische Effekte minimieren
Das volle Potenzial der 3D-IC-Technologie ausschöpfen
Vernetzte Zukunft
Synergien von ALM und PLE in der Fahrzeugentwicklung
