Wie sich die Automotive-System-Entwicklung verändert

Die Ära des programmierenden Elektronikers scheint beendet. Die Beherrschung der Software Stacks und Tools benötigt heute eher umgekehrt den elektronikaffinen Informatiker. Worauf es im Detail ankommt, erläutern Dr. Thaddäus Dorsch und Andreas Kress im Gastbeitrag.

Anbieter zum Thema

Würth Elektronik eiSos GmbH & Co. KG

Fujitsu Technology Solutions GmbH

Salzburger Aluminium Group

Motorsteuergeräte für Verbrenner wird es in der neuen automobilen Welt immer weniger geben. Dafür sind Energiemanagementsysteme in den Vordergrund gerückt. Welche Systeme auch immer in einer neuen E/E-Architektur eine Rolle spielen werden, durch die Halbleiterinnovation werden sie intelligenter und standardisierter werden.

Da ein analoges Ansteuern von Aktuatoren oder Sensoren mit analogen Leitungen kaum mehr vorstellbar ist, werden Aktuatoren und Sensoren digital angebunden sein, eine Automotive-Ethernet-Variante wird immer mehr Ausbreitung finden. Die physikalische Busstruktur wird weiterhin bestehen bleiben, doch kann man sich vorstellen, dass bei einem schnellen Netz eine logische Kommunikation sternförmig aufgebaut sein wird. Ein Aktuator oder Sensor muss also eine Netzwerkanbindung mitbringen. Wie intelligent er in der Vorverarbeitung von Rohdaten und der Kommunikation mit einer steuernden Einheit sein wird, bleibt der Auslegung überlassen.

Selbst wenn die Fahrzeuglebensdauer von heute 15 Jahren in Ihrer Dauer reduziert wird, die Innovation im Elektronikbereich, die im Jahresrhythmus Rechen- und Speicherleistung verbilligt und verkleinert, lässt eine Fahrzeugelektronik ziemlich schnell „alt“ aussehen. Speicher und Rechenleistung sind aber auch immer mehr die Schlüsselfaktoren, die Aktuatorik und Sensorik bei gleichbleibender analoger Peripherie verbessern können.

Vom programmierenden Elektroniker zum elektronikaffinen Informatiker

Wenn das Auto immer mehr zum Rechner auf Rädern wird, ist somit auch zu erwarten, dass sich Upgrade und Auswechselszenarien aus dem Computer-Bereich, in den Auto Bereich fortpflanzen. Dies benötigt natürlich entsprechende Standardisierung und Normierung von Schnittstellen.

Der Einzug von Autosar, QNX und weiteren Software Quasi-Standards, die allgemeine Code und Funktionsbibliotheken liefern ist der dramatischen Reduzierung der Kosten für Mikrocontroller bei gleichzeitiger Leistungsverbesserung geschuldet. Dabei hat sich die Ära des programmierenden Elektronikers beendet. Die Beherrschung der Software Stacks und Tools benötigt heute eher umgekehrt den elektronikaffinen Informatiker. Weitere Standardisierung im Fahrzeug-Computing und leistungsfähige Hardware wird das ihre tun um Funktionsverbesserung und Funktionsinnovation als reine Softwareleistung abbilden zu können.

Vom einfachen Control Loop zum Real Time Parallel Computing

Als eines der vielen Initiativen, die eine Entwicklung des Autos zum mobilen Superrechner voraussahen und diese Entwicklung erforschten, kann man beispielhaft das Institut für Informatik der TU Clausthal betrachten. Dort wurden um 2009 Projekte durchgeführt die in einer Studie zu folgenden Prognosen für den weiteren Verlauf der Automobilentwicklung führten:

2015: Das Auto ist zum mobilen Parallelrechner mit bereits sehr aufwendigen Verkabelung bis 10 km Länge geworden.

2020: Alle Kabeltechnologien sind im Fahrzeug gleichzeitig vertreten, d.h. shielded twisted Pair, Koaxialkabel, Glasfaser, Standard-Signalkabel und Starkstromkabel sind erforderlich und machen den Kabelbaum heterogen und teuer.

2030: Autonomes Fahren ist in der Serienreife. Das Auto ist nach den Maßstäben von 2009 in mobiler Supercomputer, der von einem Elektroantrieb auf telematisch kontrollierten Straßen bewegt wird.

Was autonomes Fahren betrifft, so scheint die Studie die beschleunigte Entwicklung nicht vorausgesehen zu haben. Stand 2016 gibt es je nach Auslegung und Definition bereits teilautonomes Fahren in Serie. Die Produktpalette der Firma Nvidia zeigt dabei den Stand der Möglichkeiten im Computing auf.

Wirkung auf die Organisation der Automotive-Elektronikentwicklung

Fortdauernde Kostenoptimierung nach dem Ford Prinzip und die sich dadurch ergebende tiefe Lieferkette hatte auf die Entwicklungswelt des Autos maßgeblichen Einfluss. Vielfach unsichtbar für den Endkunden, der den Autobauer, oft als den alleinigen Hersteller des jeweiligen Fahrzeugs wahrnimmt, vollzieht sich eine komplexe, dynamische und manchmal als chaotisch wahrgenommene Entwicklungswelt. Diese ist geprägt von vielen Mitspielern, die zwischen Konkurrenz und Kooperation einem „Design to Cost“ unterworfenen Neu- und Weiterentwicklungsprozess aufrechterhalten.

Die primäre Organisationsform, die dabei in den Entwicklungsabteilungen der großen Automobil- und Automobilteilehersteller vorherrscht, ist als hierarchisch als auch Matrix orientiert zu bezeichnen. Die Matrix wird dabei von den horizontal in der Organisation stattfindenden Fahrzeugprojekten geprägt, wobei Fahrzeugprojekt auch Fahrzeugplattformprojekt bedeuten kann. Die Organisation der Entwicklungsprojekte ist dabei von formalisierten Produktentwicklungsprozess Blaupausen geprägt, kurz als PEP bezeichnet. Diese Blaupausen strukturieren bis in Einzelaufgaben die Projektpläne und die Projektverfolgung durch Management und Qualitätsabteilungen.

Diese qualitätsorientierte Vorgehensweise ist heute Standard, es zieht sich über alle Lieferkettenbeteiligten und deren Zulieferteile die unter Innovationsdruck stehen. Bemerkenswert ist aber die diese Prozesse unterstützende Ingenieurs-IT. Also Werkzeuge, Datenbanken und Kollaborationsportale die in der Entwicklung im Einsatz sind. Hier herrscht eine große Vielfalt.

Conways Law

Das in der Software Engineering Gemeinde bekannte und gern zitierte Gesetz von Conway besagt folgendes: „Organizations which design systems are constrained to produce designs which are copies of the communication structures of the organizations“. Überträgt man diese aus der Softwareentwicklung stammende Hypothese auf die Entwicklungswelt von Fahrzeugen, zeigen sich ich schon auf der globalen Perspektive die ersten, von der Automobilarchitektur geprägten, übergreifenden Organisationstrukturen.

Geht man in der Elektronik Subsystem und Komponentenbereich, so stellt sich zwar das Kabelnetz und die Vernetzung der Komponenten als übergreifende Instanz dar. Darunter findet man dann aber nebeneinander die Bereiche die sich mehr oder weniger isoliert entwickelt haben. Das sind Bereiche wie Motor, Fahrwerk oder Lichtanlage. Die oft von den Kombiinstrumenten gesteuerten und von den anderen Bereichen benötigten einfachen Fahrzeugzustandsmeldungen grenzten sich auf den Zündungszustand und die Geschwindigkeit ein.

Mit jeder neuen Funktion kam ein weiteres Steuergerät hinzu, welches Kommunikation und allgemeine Softwarefunktionen redundant beinhaltete. Im Motorbereich eine Einspritzsteuerung, im Fahrwerk ABS Steuergeräte, und für die Karosserie wurden auch schon gerne zwei Steuergeräte für Front und Heck in den Kabelbaum integriert. Diese Entwicklung war der Beibehaltung einer einmal gefundenen Struktur und nur wenigen Anpassungen und Änderungen in langen Jahren geschuldet.

Welche kuriosen Betrachtungswinkel in der neuen Auto Softwarewelt dabei entstehen, kann folgender Interviewausschnitt aus einem 2012 Automobil-Industrie-Interview mit Volker Wilhelmi, Leiter Elektrik/Elektronik-Architektur bei Mercedes-Benz, zeigen:

Frage: Die OEMs können dank Autosar immer öfter die Steuergeräte-Software selbst schreiben und sie dann wie ein Tier-2-Zulieferer an den Tier 1 der Steuergeräte liefern. Was hat das für Konsequenzen?

Antwort: Dieser Trend besteht tatsächlich. Die Lieferanten profitieren von den standardisierten Autosar-Schnittstellen und Softwaremodulen und können für die verschiedenen Kunden teilweise einheitliche Produkte liefern – etwa die Software für Fensterheber Funktionen oder bestimmte Steuergeräte. Wir hingegen wollen das Zusammenspiel der Funktionen frühzeitig optimieren und übernehmen deshalb vermehrt die modellbasierte Funktionsentwicklung für diese Funktionen. So können wir schon in frühen Entwicklungsphasen die gewünschte fahrzeugspezifische Spezifikation erzeugen. Auf dieser Basis schreibt der Zulieferer dann die Software und integriert sie in das Steuergerät. Bei besonders sensiblen Innovationen wie etwa Fahrerassistenzsystemen schreiben wir auch die Software selbst. In einigen Fällen beauftragen wir damit spezialisierte Dritte. Es kommt immer auf den Einzelfall an.

Die strenge von oben nach unten Hierarchie, in der ein Halbleiterhersteller unter einem Tier1 oder Tier2 Zulieferer sitzt, ist dabei eine zu vereinfachte Sicht, es ergeben sich vielfältige Netzwerke von Liefer- und Empfängerbeziehungen.

Alles fließt

Durch Virtualisierung, Modellierung und Simulation wandelt sich nicht nur die automobile Industrie mit all Ihren Entwicklungsdisziplinen in ein Software-Unternehmen. Der Trend ist absehbar global und alles umgreifend. Einwände dürften vor allem von der Absicherung kommen, die zwar in Sachen Testautomatisierung und Testdatenmanagement bereits IT technisch ausgestattet ist. Das aber auch hier große Veränderungen kommen werden, kann schon ansatzweise mit den im Autoswift Projekt skizierten frühen Absicherungs und Bewertungskonzepten aufgezeigt werden.

Eine große Rolle wird dabei die virtuelle Absicherung spielen, die einerseits frühe, heute nur durch teure Mustertests erreichbare Einsichten erlaubt, andererseits späte physikalische Testläufe überflüssig machen wird. Dabei ist das alles nicht neu, sondern war nur durch teure Rechen- und Speicherkapazität limitiert.

Neue Projektorganisationen

Die neuen Organisationsformen werden sich mehr an „Crowd Working“ und den agilen Projektdurchführungsmethoden anlehnen. In der Softwareentwicklung ist das agile Vorgehen z.B. SCRUM heute an der Tagesordnung. Diese Organisationssysteme werden aber immer mehr in die gesamte Entwicklung und darüber hinaus eingeführt werden.

Äußerliche Kennzeichen sind Backlog-Technologie die eingesetzt werden. Ticket- und Änderungs-Tracker sind zu finden. Nach wie vor sind es die Schnittstellen zu PDM-Systemen und Ablage-Synchronisation die die Diskussion bestimmen. Leichtgewichtige Vorgehensweisen sind aber am besten in einer Kollaborativen vernetzten IT Werkzeugwelt durchführbar.

Agile Methoden wie Scrum oder Kanban sind seit Jahren in der Software-Entwicklung bekannt und weitgehend etabliert. Wenn es um die Entwicklung von Hardware oder Systemen aus Mechanik, Elektronik, Software und/oder Dienstleistungen geht, werden diesen Ansätzen bisher aber nur wenig Chancen eingeräumt. Ganz zu Unrecht, wie einige Fallbeispiele zeigen. Eine aktuelle Möglichkeit, diesem Thema auf den Grund zu gehen, bietet zum Beispiel die„Agile Systems Konferenz“, die dieses Jahr am 24.-25. Okt 2018 in München stattfindet

Über die Autoren

Andreas Kress ist als Senior Consultant im Bereich System Engineering für IT und technische Systementwicklung für die HOOD GmbH tätig. Seine Schwerpunkte liegen im Change und Configuration Management (CCVM), im Bereich Application Lifecyle Management (ALM) und im Bereich Requirements Engineering (RE). Seine Tätigkeitsschwerpunkte liegen in der Einführung und Optimierung von Prozessen, Methoden und Werkzeugen.

Dr. Thaddäus Dorsch arbeitet seit vielen Jahren als Senior Consultant für Requirements und Systems Engineering bei der HOOD GmbH. Er beschäftigt sich mit agilen und klassischen Vorgehensweisen in der Systementwicklung und dem effektiven Umgang mit Anforderungen. Ein weiterer Schwerpunkt liegt auf neuen Ansätzen und Denkmodellen für die Entwicklung von komplexen Systemen. Thaddäus Dorsch hat langjährige Erfahrung in der Systementwicklung und im Systems Engineering in den Branchen Telekommunikation, Luft- und Raumfahrt, Verteidigung, Automotive, Landmaschinen, Biotechnologie, Print und Multimedia.

(ID:45480737)