Continental entwickelte seine IIP in einem agilen Verfahren

Auf der diesjährigen IAA hat Continental erstmals den neuesten Entwicklungsstand seiner Integrated-Interior-Plattform (IIP) gezeigt. Die bisher getrennten Displays des Kombi-Instruments und des Infotainmentsystems in der Mittelkonsole wurden auf einem Hardwaresystem zusammengeführt. Damit ist die IIP ein Wegbereiter für den Umbruch der E/E-Architektur im Auto: weg von vielen einzelnen Steuergeräten und hin zu wenigen Hochleistungscomputern für hoch integrierte Funktionsbereiche oder Domänen. Nur mit zentralisierter Rechenleistung (≈ „Server“) ist es möglich, eine Vielzahl von Klienten, Funktionen und Diensten im Cockpit effizient zu vernetzen (Bild 1). Auch die Möglichkeit zum Update Over-the-Air und zum nachträglichen Flashen von Software-Patches setzt eine koordinierte Konzentration der Rechenleistung in einem Gerät voraus. Ein „Server“ bietet zusätzlich die Möglichkeit, neue Funktionen zu hosten, für die in einer dezentralisierten Architektur eine weitere ECU integriert werden müsste.

Architektur im Umbruch

Ein vernetztes Cockpit stellt die Entwickler der E/E-Architektur aktuell vor zwei Herausforderungen: zum einen eine immer stärkere Trennung von Soft- und Hardware sowie die Öffnung für Open-Source-Software aus vielen Quellen. Zum anderen verlangt es Entwicklungsprozesse, mit denen sich diese neuen Anforderungen schnell, wirtschaftlich und betriebssicher umsetzen lassen. Der Umfang und die Komplexität einer Plattform wie der IIP erfordert ein hohes Maß an Automation (Software Factory) zur Qualitätssicherung (Bottom-up) bei gleichzeitig wirtschaftlichem Arbeiten.
Die aktuelle Generation der IIP-Architektur nutzt Virtualisierungslösungen, die es erlauben, gleichzeitig Software unterschiedlicher Sicherheitsanforderungen auf einem System zu betreiben. So unterscheiden sich die Anforderungen an die Funktionssicherheit eines Kombi-Instruments von denen einer offenen Partition, auf der Anwender Android-Apps installieren können. Wo früher die Abgrenzung über die Verwendung mehrerer Steuergeräte gewährleistet wurde, übernehmen das jetzt Virtualisierungslösungen auf einem System wie der IIP.

Die Softwarelösungen auf Betriebssystemen wie QNX, Integrity, Linux und Android Automotive stammen von Zulieferern, aus der Open-Source-Welt und eigenen Entwicklungsteams.

Der aktuelle Demonstrator zeigt über die gesamte Cockpitbreite unter einer Glasfläche, wie viele Funktionen hochintegrierte Systeme gleichzeitig beherrschen müssen. Hier gibt es zwei verschiedene Modi: den manuellen und den automatisierten. Im manuellen Modus stellt das fahrerseitige Display neben den klassischen Rundanzeigen auch die Ansicht der digitalen Rückspiegel dar (Bild 2). Schaltet der Fahrer dann in den automatisierten Fahrmodus, fährt das Display vollständig hoch und bietet nun auf der vollen Fläche alle Internet-basierten Dienste und Apps an, die sonst nur auf der Beifahrer-Seite zur Verfügung stehen (Bild 3).

Neue Technologie erfordert ein neues Umfeld

Bild 1: In vernetzten Fahrzeugen verschwimmen die Grenzen zwischen sicherheitsrelevanten Funktionen, Infotainment und Komfort. Continental

Um die IIP bis zu dem jetzt gezeigten Stand weiterzuentwickeln, entschied Conti sich an dem initiierenden Standort Wetzlar zu einem generell anderen Projektmanagementansatz. Damit begann ein Kulturwechsel hin zu einer agilen Arbeitsweise, welche den Aufbau einer neuen Organisation erforderte. Die Prozessverantwortlichen konnten im Rahmen der globalen Vorgaben ihre Entwicklungsmethoden und Prozeduren sowie den Aufbau der Strukturen frei wählen, Leitbild war dabei die Automatisierung der Softwareentwicklung und von Tests. Da für die Plattformentwicklung zahlreiche, sich schnell ändernde Anforderungen berücksichtigt werden mussten, setzte man bei der Entwicklung auf ein Modell mit kurzen Entwicklungszyklen, Feedbackschleifen und hohem Automatisierungsgrad.

Manuelle Berichtsprozesse würden bei den Funktionsumfängen der IIP jeden Rahmen sprengen, denn die Entwicklung einer solchen Plattform ist trotz der enormen und weiterwachsenden Software-Umfänge eine kleinteilige Arbeit, deren zahllose individuelle Tasks und Fortschritte die Projektverantwortlichen extrem gut koordinieren und managen müssen. Als Leitbild definierten die Projektmitglieder, dass Qualität am Anfang und nicht am Ende stehen muss, was konkret bedeutet, dass sie bei der Entwicklung von Funktionen gleichzeitig auch die entsprechenden Tests erstellen. Nur mit einem Ökosystem aus geeigneten Tools und Methoden ist es möglich, diese vielen kleinteiligen Anpassungen im Rahmen einer abgestimmten Planung laufend zusammenzufügen und zu validieren (Bild 4).

Bild 2: Beim IIP Cockpit Demonstrator werden dem Fahrer im manuellen Modus wichtige Fahrinformationen angezeigt. Continental

Zusätzlich zu einer automatisierten Qualitätsschranke („Gating“) dienen daher transparente Metriken dazu, die erreichte Software-Qualität ständig bis hinab zur Ebene des Quellcodes in Echtzeit zu messen (Prinzip von Continuous Integration/Test). Alle qualitätsrelevanten Informationen sind den Scrum-Teams sowie internen und externen Stakeholdern jederzeit verfügbar. In den Entwicklungsbüros hängen Monitore, die diese Daten für jeden Mitarbeiter transparent machen. Die Teams sehen ihre Werte und können diese mit denen der anderen Teams vergleichen. Daraus entsteht eine positive Motivation „Qualität“ einzubauen. Mit diesem agilen und automatisierten Arbeiten bekommt die Software früh einen hohen Reifegrad. Dieser Übergang zu einem agilen Ökosystem ist zugleich die beste Voraussetzung für die Zusammenarbeit mit Automobilherstellern auf der Grundlage agiler Methoden.

„Social Coding“ in der Software Factory

Die Auswahl und Anpassung der Entwicklungsmethoden und der Projektskalierung basieren auf dem Scaled Agile Framework (SAFe). Zentrales Element des skalierten Arbeitens ist die „Continuous Delivery Pipeline“, die Wertschöpfungskette der IIP Software-Teams. Die Realisierung dieser Pipeline basiert auf Tools, die in der Open-Source-Welt weit verbreitet sind. Die Software Factory hat einige Lösungen entwickelt, um diese Tools miteinander zu verbinden. Ein zentrales Application Lifecycle Management (ALM) Tooling ist daher nicht mehr nötig und ist durch dezentrale, lizenzfreie Lösungen in den Teams ersetzt worden.

Beispielhaft fiel die Entscheidung für einen Wechsel von einer früheren ALM-Lösung zu Github und Gerrit als neue Entwicklungsplattform (Verteilte Versionsverwaltung von Software-Quellcode, Code Sharing Platform) für den laufenden, nahtlosen Software-Review. Github ließ sich in das Continental-DevOps-Portfolio einbinden, ebenso wie die bereits existierenden Tools. Bereits nach einer zweiwöchigen Umstellungsphase zeigte sich der Effizienzgewinn: Wo zuvor ein Release pro Monat erfolgte, beschleunigte sich das in dem neuen Prozess auf fünf bis acht Baselines pro Tag. Die anfänglichen Entwicklungs-Investitionen in moderne Entwicklungsumgebungen und -tools zahlten sich im Laufe der Umsetzung klar aus.

Bild 3: Im automatisierten Modus fahren die Displays zu voller Größe aus. Die IIP erlaubt den Passagieren nun, vollständig in ihre digitale Büro- oder Unterhaltungsumgebung einzutauchen. Continental

Mit einem herkömmlichen Entwicklungsprozess und einem hohen Anteil an manuellen Prozessschritten wäre der Umfang und das Tempo der Weiterentwicklung der IIP-Software nicht zu beherrschen: Aktuell sind an der agilen Entwicklung der IIP-Software rund 20 Continental-Teams an vier Standorten in Europa und Asien beteiligt. Dabei laufen 70.000 automatisierte Tests pro Woche ab, im selben Wochenrhythmus werden 250 Software-Baselines erzeugt und automatisch dokumentiert. Auch die Überprüfung der erfüllten Freigabebedingungen erfolgt automatisiert.

Gleichzeitig gab und gibt es Herausforderungen für das agile Arbeiten. Obwohl die meisten zugeordneten Mitarbeiter bereits erste Erfahrungen mit einer agilen Entwicklungsmethode auf Teamebene hatten, reichten die bisher erworbenen Kenntnisse der agilen Entwicklungsmethoden nicht aus, um ein Projekt dieser Größenordnung in der Praxis erfolgreich durchzuführen. Die Lernkurve erwies sich als steiler und die benötigte Zeit bis zu den ersten erfolgreichen Ablieferungen dauerte länger als ursprünglich geplant. Außerdem wurde im Verlauf der Umstellung erst iterativ die richtige Balance zwischen Disziplin und stringenter Projektstruktur sowie agilem Arbeiten gefunden.

Auch zur sicheren und umfassenden Einbindung von Drittlieferanten gibt es im DevOps-Ökosystem Industrie-Standard-Tools wie Prometheus zur Überwachung, Elasticsearch zur Datenaufzeichnung, Jira zur Nachverfolgung von Problemen, Grafana zur Darstellung von Daten, Confluence zur Dokumentation, Artifactory zur binären Speicherung, Kubernetes für die Build Infrastructure und weitere.

„Mannschaftssport“ Software-Entwicklung

Als Unterschied zur klassischen Projektmanagement-Methode, bei der Experten an Projekte vergeben wurden und typischerweise eine Teilverantwortung erhielten, wird in der IIP die Aufgaben an Teams adressiert, die selbstverantwortlich ihre Arbeit managen.

Diese Teams arbeiten an verschiedenen Continental-Standorten, aber auch weltweit bei Zulieferern. Statt einem Projektleiter gibt es nun in den Teams „Product Owner“, die inhaltlich für die Arbeit des Teams verantwortlich sind. Diese definieren den Umfang der Arbeiten (Inhalt des Backlogs) und die Reihenfolge der Abarbeitung. Die Planung, Abschätzung und Ausführung der Arbeit wird von Scrum-Mastern organisiert, die einerseits darauf achten, dass das Team die Qualität und die Regeln beachtet, und andererseits das Team unterstützen, wenn es Probleme oder Hindernisse gibt.

Bild 4: Agilität und verteilte Software-Entwicklung über Kontinente hinweg lassen sich nur mit einem Ecosystem aus Tools und Methodiken effizient handhaben. Continental

Das spezielle Mindset, das ein Scrum-Master benötigt, ist eine neue Form der Qualifikation. Entsprechende Mitarbeiter müssen zunächst gefunden oder qualifiziert werden, denn nicht jede oder jeder hat dieses Mindset. Hinzu kommt, dass auch die persönliche Entwicklung der Mitarbeiter („Karriereplanung“) in diesem agilen System neu definiert werden muss. Eine Herausforderung besteht darin, dass hier Wachstumsmöglichkeiten für den Einzelnen durch Übernahme neuer Aufgaben entstehen, die aber nicht in der konventionellen Linienstruktur abgebildet sind. Für ehemalige Linien-Führungskräfte bestand die umgekehrte Herausforderung: Sie mussten die Verantwortung an die „Product Owner“ und „Scrum-Master“ abgeben. So hatte die neue Ausrichtung einer schlanken Linienstruktur parallel zur Projektstruktur die bestehenden Abteilungs- und Gruppenleiter zunächst verunsichert. Die Akzeptanz für die neuen Rollen bedingt den Wandel in der Denkweise und der täglichen Arbeitskultur.

Zum Kulturwandel gehört bei Continental vor allem am Agile Campus Wetzlar ein umfassendes Verständnis der neuen Arbeitswelt: Dort beschränkt sich die Nutzung agiler Methoden und Werkzeuge nicht auf die Software-Entwicklung, so wie sonst meist üblich. Stattdessen werden im Zuge eines vollständigen Kulturwandels auch weitere Unternehmensbereiche sukzessive auf agile Prinzipien umgestellt. Diese komplette Umstellung ist die Konsequenz daraus, dass ansonsten Brüche zwischen Unternehmensbereichen bleiben, die nicht agil arbeiten, und solchen, die es bereits tun. So führt der aktuelle Umbruch in der E/E-Architektur im Fahrzeug dazu, dass sich die Organisation, aus der neue Lösungen für diesen Umbruch hervorgehen, ebenfalls ändert und das geeignete Umfeld für die Technologie von morgen schafft.

(prm)