Agile Softwareentwicklung mit Scrum verändert die E/E-Integration

Nachdem sich die klassischen Ansätze vielfach als überfordert herausgestellt haben, entwickelt sich in der Automobilbranche zunehmend ein Trend, flexiblere und auch leistungsfähigere Entwicklungsprozesse zu nutzen. Doch anders als bei reinen Software-Firmen müssen OEMs auf zwei Feldern spielen: Die deutlich längeren Zyklen von Hardware und Fahrzeug bleiben weiterhin die Basis. Eine anspruchsvolle Aufgabe für die Systemintegration, die genau an diesen Schnittstellen zwischen Software-Modulen, E/E-Systemen und Hardware für eine reibungslose Gesamtfunktion sorgen soll.

Agilität als Organisationsprinzip

Bild 1: Klare Übergabepunkte im schichtweise gezeichneten Entwicklungsprozess sind in der Praxis oft schwer umsetzbar. Umlaut

Scrum als Projektsteuerungs- und Organisationsphilosophie ist an sich wohlbekannt und auch bei den Automobilherstellern seit mindestens einer Dekade im Einsatz. Neu ist, dass sich Scrum-Anwendungen nicht mehr als Nische einzelner Teams oder Abteilungen finden lassen, sondern dass sich nun Projekte mit hunderten oder tausenden von Entwicklern agil steuern lassen sollen.

Ein Kernelement von Scrum ist der Sprint: meist ein Zeitraum von einer bis vier Wochen, an dessen Ende ein Shipable Product stehen soll. Ziel ist ein beim Endverbraucher einsetzbarer Funktionshub. Das ist in einer stark von Software getriebenen Welt deutlich einfacher realisierbar als in einer Welt, in der multipel miteinander vernetzte Hardware mit längeren Entwicklungs- und Lieferzeiten dazugehört. Diejenigen Umfänge, die außerhalb der Sprints zu betrachten sind, gehören in der Scrum-Logik in das Undone-Department, die Abteilungen für alles, was nicht in einen Sprint passt.

Die Sprintlogik soll es dem selbstorganisierten Scrum-Team ermöglichen, möglichst schnell eine Lernschleife zu Erfolg und Qualität ihrer Entwicklungsarbeit zu erzielen. Und dazu muss das Entwicklungsteam möglichst gute, umfassende und automatisierte Testumgebungen besitzen, um so früh wie möglich Fehler zu erkennen, daraus zu lernen und diese zu beheben.

Nun ist die Größe eines Scrum-Teams natürlich begrenzt und sollte nicht mehr als zehn Personen umfassen. Für die Organisation von Großprojekten sind daher die Entwicklungsaufgaben auf mehrere parallel arbeitende Teams aufzuteilen, beziehungsweise es ist eine Zwischenebene einzuführen, um Entwicklungsstränge zusätzlich zu bündeln.

Scrum im Großformat

Die zwei am weitesten verbreiteten Ansätze dazu heißen Large-Scale Scrum (LeSS) und Scaled Agile Framework (SAFe). LeSS ist im Wesentlichen ein kaskadiertes „Scrum of Scrums“ mit minimalen Zusatzstrukturen, während SAFe deutlich stärker Steuerungselemente einbaut, um bekannte Themen wie das Portfolio, Hauptreleases oder Varianten eines Produktes mit einzubeziehen.

Im Vergleich von herkömmlichen Entwicklungsprozessen, Rollen und Strukturen mit SAFe ist die Ähnlichkeit frappierend – was ein zweiseitiges Schwert ist. Denn einerseits sind viele Fragestellungen des realen Entwicklungsbetriebs eines OEMs bereits abgedeckt, andererseits jedoch kann die SAFe-Struktur zu einem „weiter wie bisher“ verleiten – nur heißen jetzt die Rollen und Meetings anders.

Bild 2: Die vier Stellhebel für eine gute Systemintegration. Umlaut

Scrum ist eben nicht als Projektmanagement-Methode zu verstehen, sondern reicht viel tiefer. Ein agiler Entwicklungsansatz trimmt eine R&D-Organisation auf effiziente Lernschleifen und hohen Output. Außerdem stellt er eher grundlegende Prinzipien zur Verfügung als ein dogmatisches Set von Projektmanagement-Methoden.

Die Idee zum Beispiel, nach jedem Sprint ein auslieferbares Produkt-Inkrement in den Händen zu halten, erweist sich im automobilen Kontext in der Regel als nicht realisierbar. Zudem würde es einem zentralen agilen Prinzip widersprechen: Nicht die sture Implementierung eines Best-Practice-Konzepts ist gefordert, im Vordergrund steht die (experimentelle) Frage, welche Methodik den effizientesten und besten Lernprozess bietet.

Integration 4.0

Was im V-Modell (Bild 1) als sauberer, schichtweiser Entwicklungsprozess mit klaren Übergabepunkten dargestellt ist, erweist sich in der Praxis als deutlich schwieriger. Nach im schlimmsten Fall unrealistischen oder unklaren Spezifikationen müssen die Programmierer unter hohem Zeitdruck Softwarestände entwickeln, die im Resultat dann oftmals noch nicht ausgereift sein. Der 2nd-Tier übergibt an den 1st-Tier, der wiederum an den OEM und keiner hat den Reifegrad vorher ausreichend abgesichert. Eine große Anzahl der von Umlaut durchgeführten Test-Assessments hat in den vergangenen Jahren immer wieder die gleichen Schwierigkeiten und Lücken identifiziert – flächendeckend und nahezu unabhängig vom konkreten Zulieferer.

Die eigentliche Integrationsaufgabe, nämlich das Zusammenbauen der Software-Module zu einem lauffähigen Release, benötigt zudem viel technischen Sachverstand. Viele OEMs streben nach mehr eigener Wertschöpfungstiefe und beginnen, einzelne Software-Module oder ganze Frameworks selbst zu entwickeln. Dies soll zugleich die Wiederverwendbarkeit der Software-Module sicherstellen. Das Durchwechseln der 1st-Tier und fehlende Rechte am Source Code haben dies bisher verhindert.

Späte Vergaben, unrealistische Spezifikationsinhalte und Meilensteine, ein später Ressourcenaufbau sowie wenig bis keine Wiederverwendbarkeit sind nur einige der Folgen des bisherigen Zusammenarbeitsmodells, wodurch am Projektende wenig Innovationshub für den Verbraucher übrigblieb.

Herausforderung bei Integration und Komplexität

Monolithische Systeme wie die Infotainment-Headunits werden zunehmend zerlegt. Die Lieferbeziehungen sind fragmentierter, die Verantwortlichen kaufen einzelne Software-Module gezielt ein und der OEM liefert selbstentwickelte Software an seinen 1st-Tier. Die Systemintegration ist damit immer wichtiger für die Leistungsfähigkeit des Entwicklungsprozesses.

Die Systemgrenzen weiten sich dabei immer mehr aus. War die letzte Dekade die der inneren Vernetzung des Fahrzeuges, so gibt es in Zukunft kaum noch Funktionen, die nicht mit der Außenwelt vernetzt sind. Im Besonderen trifft das für die E-Mobilität und das autonome Fahren zu. Hier kommt der Vernetzungsaspekt mit Infrastrukturkomponenten (V2X) hinzu: Das Fahrzeug spricht mit der Verkehrssteuerung, dem Parkhaus, Meshup-Netzwerken, dem Regulierer und vielem mehr.

Wenn die Systemkomplexität überhandnimmt und das Gesamtverständnis nicht mehr herstellbar ist, kann eine Verkapselung zu Funktionsblöcken hilfreich sein. Möglichst stabile Schnittstellen sprechen hierbei einzelne Bausteine (funktionale Blöcke) an und ermöglichen es dadurch, unterschiedliche Entwicklungsgeschwindigkeiten zu realisieren und die Absicherung der Funktionsblöcke einfacher zu gestalten.

Die Software sollte außerdem von der Hardware möglichst unabhängig sein. Eine Entkopplung braucht also Unabhängigkeit der Funktionsblöcke und das bedeutet Abstrahierung, was wiederum einen erhöhten Ressourcenaufwand bedeutet. Als Resultat sind eine höhere Skalierbarkeit, geringere Komplexität und Wiederverwendbarkeit möglich, sofern die Grundarchitektur stimmt.

Test- und Integrationskompetenz

Bild 3: Die Testfarm von Umlaut. Vollautomatisiert wird ein sauberer, eindeutig definierter Anfangszustand per remote hergestellt, vollkommen unabhängig davon, wo sich die Testbench befindet. Umlaut

Die Test- und Integrationskompetenz in die Inhouse-Entwicklungsteams zu bringen, ist eine von vier Stellhebeln (Bild 2) für gute Systemintegration. Je einfacher ein Entwicklungsteam sein Software-Modul in der nächst höheren Integrationsstufe testen kann, desto effizienter sind Fehlersuche und Fehlerbehebung. Allerdings sind die Ressourcen- und Prozesskosten hoch, wenn jedes Software-Entwicklungsteam eine komplexe Testumgebung am Schreibtisch haben soll.

Neben den Hardware-Ressourcen geht es vor allem um die dahinterliegenden Prozesse: Beschaffung, Flashen, Hardware- und Software-Logistik, Debugging-Tools oder Update-Prozesse. Eine Vielzahl an Anforderungen, die ein Scrum-Team mit fünf bis zehn Entwicklern nicht vollumfänglich bedienen kann.

Daher ist auch ein skalierbares, effizientes Betriebskonzept für die dezentralen Test- und Integrationsorte nötig, welches ein interner oder externer Partner umsetzt, der nicht nur Testen/Integrieren kann, sondern vor allem konzeptionelle Kompetenz zur Prozess-Architektur mitbringt. Fehlende Support-Prozesse führen ins Chaos, das bedeutet: Support- und Betriebsprozesse sind professionell und skalierbar zu organisieren.

Schnittstellen bündeln

Bei dem zweiten Stellhebel handelt es sich um die Schnittstellen zum Gesamtfahrzeug und der restlichen Organisation. Eine funktionierende agile Entwicklung im Großprojekt hat viel damit zu tun, das Produkt und die Entwicklungsteams gut zu „schneiden“, also die bestmögliche Organisation zu finden. Dazu gehört auch die Frage, wer die Vielzahl von nachfolgenden Prozessschritten und Prozesspartnern bedient.

Ein wesentliches Merkmal heutiger E/E-Systeme ist, dass ihre Entwicklung in Generationen stattfindet, die entkoppelt vom Fahrzeug sind. Ist eine Generation eines Infotainment-Systems erstmals entwickelt, erfolgt im Anschluss dessen Einbau in einer Reihe von Fahrzeugen. Aber vorher sind diese Systeme noch zu applizieren.

Beim Aufbau einer agil arbeitenden Entwicklungsorganisation müssen die Schnittstellen zu Fahrzeugintegration, Fahrzeugvarianten, Produktion, Qualität und vielem mehr klar definiert sein. Viele dieser Stakeholder haben andere Planungszyklen als die schnellen Sprints in der Entwicklung. Einige Themen brauchen eine übergreifende Abstimmung und längerfristige strategische Planung.

Das Spannungsfeld zwischen agilen und nicht-agilen Bereichen ist daher durch Prozess- und Organisationsexperten auszugestalten, die beide Seiten kennen, verstehen und in ihren Bedürfnissen ernst nehmen.

Komplexität des Ökosystems durch API-Partner kanalisieren

Wenn Fahrzeuge sich in komplexen, vernetzten Ökosystemen bewegen, kann kein OEM all diese Schnittstellen und die Dynamik dahinter selbst in den Griff bekommen. Ein banales Beispiel sind die Consumer Devices, die die Kunden ins Fahrzeug mitbringen – heutzutage vor allem Smartphones und Tablets: selbstverständlich gibt es Standards wie Bluetooth oder USB, aber die Integration deckt schonungslos Spezifikationslücken und Implementierungsfehler auf.

Und es kommen stets neue Systeme hinzu. Fahrzeuge sprechen mit den Verkehrsleitzentralen für die Ampelsteuerung, mit Parkhäusern, Bezahlsystemen, mit Content-Providern und mit Startups zur Parkplatzsuche – die Liste ist beliebig erweiterbar.

Die Automobilhersteller brauchen externe Partner, die wie eine API die Komplexität der äußeren Partnersysteme kapseln, kanalisieren und standardisiert zur Verfügung stellen. Dazu müssen sie beide Seiten als Insider verstehen. Dies ist auch der dritte Stellhebel für eine erfolgreiche Systemintegration.

Virtualisierung und Test-as-a-Service

Wer Cloud-Plattformen wie Microsofts Azure oder Amazons AWS nutzt, weiß, dass es nicht um den Standort des Servers geht. Virtualisierte Infrastruktur kann eine dramatische Beschleunigung mit sich bringen, da sie zentrale Supportprozesse entkoppelt.

Die Umlaut Testfarm (Bild 3) stellt Entwicklern und Testern virtuelle Testumgebungen zur Verfügung. Über Web-Services lässt sich zunächst die Konfiguration definieren: das Hardware-Target, die Software-Konfiguration, zu testende Applikationen und die notwendigen Daten. Auf sehr flexible Weise lässt sich so vollautomatisiert ein sauberer, eindeutig definierter Anfangszustand herstellen. Das Ganze erfolgt remote, ohne dass es für den Tester relevant ist, wo sich die Testbench tatsächlich befindet.

Danach werden entweder automatisierte Test-Skripts ausgeführt, die sich über ein von Umlaut entwickeltes Framework abspielen lassen oder der Tester möchte das System remote und manuell steuern. Weitere wichtige Bestandteile sind die automatisierte Dokumentation des Testablaufes, das Clustern aller notwendigen Trace-Dateien und eine intelligente Interpretation der Ergebnisse, als vierter und letzter wichtiger Stellhebel.

(aok)