Eine durchgängige PMT-Landschaft – nice-to-have oder unverzichtbar?
Sebastian Heinemann: „Einheitliche und verständliche Prozesse, Methoden und Tools (PMT) sind die Wunschvorstellung vieler operativer Entwickler, Prozessverantwortlicher, Qualitätsbeauftragter, Entwicklungsbudget-Verantwortlicher, Projektleiter und Manager. Gleichzeitig stellen sie eine Grundvoraussetzung dar, damit wir die Herausforderungen in der Automotive-Softwareentwicklung meistern und neueste Plattform-Architekturen erfolgreich in Serie bringen können. Denn während einerseits die Komplexität kontinuierlich zunimmt, fällt andererseits die Time-to-Market neuer Software auch mittels Over-the-air-Updates immer kürzer aus. Hinzu kommt, dass Automobilhersteller und -zulieferer etablierte und neue Standards und Anforderungen nach Automotive SPICE, ISO 26262 und UNECE-WP.29 erfüllen und gleichzeitig über agile Vorgehensweisen ihre komplexen Projekte in überschaubare Teilstücke zerlegen müssen. Um all diesen Herausforderungen erfolgreich begegnen zu können, müssen Unternehmen ihre PMT-Struktur grundlegend anpassen. Es gilt, durchgängige Prozesse, Methoden und Tools zu schaffen die miteinander in Einklang stehen, jeden Beteiligten in seiner kreativen Arbeit zu unterstützen und gleichzeitig wirtschaftlich abbildbar zu sein.“
Gibt es weitere Herausforderungen an die PMT?
Sebastian Heinemann: „Zusätzlich zu den angesprochenen neuen Prozess- und Qualitätsstandards und dem Bedarf an immer schneller getakteten Softwareauslieferungen gibt es einen weiteren Aspekt, der die Auflösung bisher vorherrschender heterogener, in sich gekapselter, steuergerätespezifischer PMT-Strukturen notwendig macht: Viele OEMs werden ihre Fahrzeugarchitekturen künftig auf zentrale Hochperformance-Steuergeräte aufbauen. Das bedeutet, dass in kommenden Fahrzeuggenerationen nur noch drei bis fünf zentralisierte Performance-Steuergeräte für Logik und Funktion verantwortlich sind und die Funktionen nicht mehr wie bisher auf vielen Steuergeräten im Fahrzeug verteilt sind. Die zentralen Hochperformance-Steuergeräte werden dann jeweils kombiniert mit einfacheren Steuergeräten für die Regelung und Ansteuerung der Komponenten. Erste Modelle mit diesem zentralisierten Ansatz sind bereits in Serienproduktion. Auf Organisationsebene beziehungsweise in der domänenübergreifenden PMT-Verantwortung werden dadurch grundsätzliche Prozess- und technologische Entscheidungen gesamtheitlich getroffen. Hier geht es zum einen darum, umfangreiche, verbindliche Vorgaben aus Prozess- und Qualitätsstandards zur Entwicklung und Absicherung, wie A-SPICE, ISO 26262, UNECE WP.29, ISO 29119 und ISTQB, sowie zur Homologation zu implementieren. Zum anderen müssen technologische und übergreifende Toolentscheidungen in den Bereichen Lifecycle Management, Source-Code-Verwaltung und Cloud-Systeme getroffen werden.“
Was macht die Umsetzung domänenübergreifender einheitlicher Lösungen so komplex?
Sebastian Heinemann: „Zu den bereits erwähnten Punkten kommt hinzu, dass einzelne Domänen individuelle Methoden und Tools für Ihre Projekte einsetzen müssen. Nehmen wir beispielsweise den Bereich der Antriebs- und Fahrwerksfunktionen: Diese sind oft mit regelungstechnischen Funktionen ausgestattet und lassen sich am effizientesten mit dem modellbasierten Ansatz (MBSE), einer Codegenerierung und in der Absicherung mit einem klassischen MIL-SIL-HIL-Ansatz implementieren. Auf der anderen Seite haben wir ADAS/AD-Systeme, bei denen wir teils regelungstechnische, teils algorithmische Herausforderungen – wie etwa Längsführung, Sensor-Daten-Fusionen, Objektklassifizierungen und Einsatz von künstlicher Intelligenz – begegnen. Funktionen werden in objektorientierten Sprachen, wie C++, implementiert. Die Absicherung dieser Software bedingt oft szenarienbasierte Testverfahren in komplexen Co-Simulationsumgebungen. Des Weiteren haben wir Infotainment-Systeme, die unter anderem mit Java implementiert werden. Die Herausforderungen dabei liegen in der UX-Entwicklung, in grafischen Systemen und komplexen Statemachines sowie ganz individuellen Absicherungsmethoden, teilweise mittels Bildverarbeitung. Hinzu kommen schließlich noch Connectivity-Systeme, die ihre Funktionen und Daten verteilt im Fahrzeug, in der Cloud und auf Mobile Devices rechnen. Diese Systeme bringen nochmals ganz andere Herausforderungen in der Implementierung und der End-to-End-Absicherung der Software mit sich. Domänenübergreifend hierfür nun einheitliche Lösungen zu schaffen und die einzelnen Domänen mit ihren spezifischen Herausforderungen und Technologien zu unterstützen, ist eine echte Mammutaufgabe.“
Was bedeutet dies hinsichtlich der Vision einer einheitlichen PMT-Struktur?
Sebastian Heinemann: „Zusammengefasst bedeutet das, dass die Domänen mit ihren unterschiedlichsten Technologien ganz unterschiedliche Anforderungen an ihre Implementierungs- und Absicherungsmethodik stellen und damit auch an die einzusetzenden Methoden und Tools. Die Anforderungen an eine möglichst homogene, detaillierte und domänenübergreifende PMT sind daher differenziert zu betrachten und sind zumindest für die Implementierungs- und SW-Absicherungsebene (im Kontext A-SPICE: SWE.3 bis inkl. SWE.6) so nicht umsetzbar. Eine vollkommen homogene PMT-Landschaft bleibt also auch künftig eine Illusion, da im Detail die technologischen Herausforderungen in der Entwicklung und Absicherung der zukünftigen Antriebs-, ADAS/AD-, Connectivity- und Infotainment-Systeme einfach zu groß sind. Dennoch arbeiten OEMs und Zulieferer längst an durchgängigen Prozesslandschaften und setzen dabei auf Automatisierungslösungen und agiles Arbeiten. Der entscheidende, bisher in den Phasen der DevOps-Pipeline jedoch weitestgehend von Automatisierungslösungen unbeachtete Faktor: der Mensch. Für die Entwicklung sogenannter ‚software-defined cars‘ müssen Prozesse und Methoden nicht nur automatisiert, sondern auch von allen Beteiligten eingehalten und gelebt werden. Wir bei ASAP haben deshalb das Process Automation Kit (PAK) entwickelt – eine Automatisierungslösung die dort ansetzt, wo andere Lösungen aufhören: auf Entwicklerebene. PAK bietet die Möglichkeit, die komplexe PMT der Organisation und des Projektes auf Entwicklerebene einheitlich abzubilden, maximal zu automatisieren und rückt den Menschen in der DevOps-Pipeline in den Fokus. PAK ist für jede DevOps-geprägte Organisation oder jene, die es werden will, eine geeignete Lösung zur sinnvollen Ergänzung der eigenen Automatisierungs-Pipeline.“
Mehr zum Lösungsansatz durch konsequenten Einsatz von DevOps und zur Automatisierungslösung PAK erfahren Sie im nächsten Teil der ASAP Interview-Reihe ‚DevOps weitergedacht‘. Jetzt den ASAP Newsletter abonnieren und den nächsten Teil nicht verpassen.