Codequalität für autonome Fahralgorithmen gewährleisten

Simon Kitzberger

3 MIN LESEDAUER

09.12.2019 –

Die Entwicklung autonomer Fahrzeuge ist ein Wettrennen, daher müssen schnellstmöglich stabile Algorithmen für das autonome Fahren entwickelt werden. Dafür müssen Bug Fixes und neue Features so schnell wie möglich implementiert werden, aber ohne die Qualität aus den Augen zu verlieren. Wie kann das gerade in solch großen und komplexen Projekten gewährleistet werden? Die Antwort findet sich in einer skalierbaren „Continuous Integration“ und Continuous Delivery“ Pipeline. Hier erfahren Sie wie der Aufbau einer skalierfähigen Continuous Integration und Continuous Delivery Pipeline in OpenShift funktionieren kann.

Continuous Integration und Delivery – was ist das?

Continuous Integration oder kurz CI sorgt dafür, dass neu entwickelter Code zusammengeführt, getestet und dann in die Gesamtcodebasis eingefügt wird. CI soll die Zusammenarbeit der Entwickler vereinfachen und dabei helfen Fehler frühzeitig zu erkennen.

Abbildung 1: So funktioniert Continuous Integration [1]

Mehrere Entwickler arbeiten an neuen Features oder Bug Fixes. Sobald einer von ihnen sein Arbeitspaket fertiggestellt hat, wird der Code committet und genau hier setzt CI dann ein. Sobald der Code gepusht wird, überprüft CI ob der neue Code sich nahtlos in die schon vorhandene Codebasis einfügen lässt. Anschließend startet ein automatischer Build, der dann aufzeigt ob der Code fehlerfrei gebaut werden kann oder ob es fehlschlägt. Schlägt der Build fehl, muss der Entwickler den Bug finden und beheben und den Prozess erneut starten. War der Build fehlerfrei, wird getestet und das entsprechende Ergebnis reportet.

Continuous Delivery oder kurz CD sorgt dafür, dass eine aktuelle Version der Software verfügbar gemacht wird. CD erweitert das CI Vorgehen um den Punkt „Release“ (Continuous Integration + Release = Continuous Delivery). Dabei wird die neue Codebasis auf eine Produktivumgebung implementiert, sodass die neuen Features dort getestet werden können.

Umsetzung mit OpenShift

CI/CD ist einer der beliebtesten Anwendungsfälle für die OpenShift Container Plattform. OpenShift stellt Container für den Bau von Continuous Delivery-Pipelines zur Verfügung. Dies ermöglicht es unter anderem Jenkins, viele Aufträge parallel auszuführen und beseitigt die Wartezeit für die Ausführung von Builds in großen Projekten. OpenShift bietet eine End-to-End-Lösung für den Aufbau kompletter Bereitstellungspipelines und ermöglicht die notwendige Automatisierung, die für die Verwaltung von Code- und Konfigurationsänderungen über die Pipeline erforderlich ist.

Dieses Beispiel zeigt eine CI/CD-Infrastruktur auf OpenShift:

Abbildung 2: Beispielhafter Aufbau einer CI/CD-Infrastruktur auf OpenShift (eigene Darstellung)

Einsatz in der Fahralgorithmen Entwicklung

Wenn ein neues Feature für den Algorithmus entwickelt wird, beispielsweise eine Erkennung von Ampeln, dann wird dieses Feature in einzelne Module aufgeteilt. Dies wird gemacht, da ein solches Feature meist zu groß ist, um es mit nur einem Team zu entwickeln oder es zu zeitintensiv ist, um es in einem Sprint fertigzustellen. Jedes dieser Module wird daher getrennt (pro Team/Sprint) entwickelt und jedes durchläuft einen CI Prozess. Dadurch durchläuft jede Teilentwicklung Unit- und Integrationstests, wodurch die Codequalität jedes Moduls und dadurch auch jedes Features steigt.

Abbildung 3: CI/CD Prozess anhand der Entwicklung eines neuen Fahralgorithmen Features (eigene Darstellung)

Ein CD erfolgt meist zu einem Sprint Ende oder pro Feature. Zum Sprint Ende werden dann mehrere neu entwickelte Features auf die E2E Umgebung und schlussendlich auf PROD deployed (siehe Abbildung 4). Bei der zweiten Herangehensweise wird ein Feature, sobald es fertig ist, deployed (siehe Abbildung 3).

Abbildung 4: Continous Delivery bei der Entwicklung autonomer Fahrfunktionen (eigene Darstellung)

Fazit: Was bringen CI und CD, auch im Umfeld autonomes Fahren?

Die Umsetzung einer CI und CD bringt einige Vorteile mit sich:

Da neue Features und Bug Fixes schneller auf der E2E beziehungsweise auf Produktivumgebung sind, kann früher mit Testfahrzeugen unter realen Bedingungen getestet und das Feedback der Kunden eingeholt werden.
Die gesamte Entwicklungs- und Testzeit neuer Features ist schneller, was eine übergreifend schnellere Entwicklung des Fahralgorithmus bedeutet. Das wiederrum kann einen Wettbewerbsvorteil in der Automobilbranche bringen.
Bugs werden früher erkannt und können besser identifiziert werden, da man nach jedem Commit weiß ob der Build geklappt hat oder nicht.
Daraus folgt eine übergreifend höhere Code- und Softwarequalität, was gerade für autonome Fahrfunktionen besonders wichtig ist.