Elektrobit

Etablierte Firma

Alle Videos anzeigen

Introduction and Trends in Automotive Software

Dr. Georg Gaderer von Elektrobit gibt in seinem devjobs.at TechTalk einen Überblick zum Thema Automotive Software und spricht über zukünftige Trends in diesem Gebiet.

Beim Videoaufruf stimmst Du der Datenübermittlung an YouTube und der Datenschutzerklärung zu.

Video Zusammenfassung

In „Introduction and Trends in Automotive Software“ zeigt Dr. Georg Gaderer (Elektrobit) die Megatrends automatisiertes Fahren, Elektrifizierung, Konnektivität und Shared Mobility und erklärt, warum Fahrzeuge als sicherheitskritische Softwaresysteme bei enormem Maßstab (>100 Mio. Fahrzeuge mit EB‑Software) besondere Anforderungen haben. Er kontrastiert AUTOSAR Classic (Echtzeit, C, signalbasiert, sehr kurze Bootzeiten) mit Adaptive AUTOSAR auf POSIX (serviceorientiert über IP/Ethernet, längere Bootzeiten, aktuell geringere Safety‑Levels) und beschreibt Qualitätssicherung via MISRA/ISO 26262, täglich über eine Million Tests und statische Codeanalyse. Zudem erläutert er Fahrzeug‑HPCs mit virtualisierten Multi‑OS‑Stacks, Hardware‑Beschleuniger für Kommunikation/Isolation/Zeitsynchronisation sowie den Übergang von Domänen‑ über zentrale zu zonalen Architekturen—wertvolle Orientierung für die Funktionspartitionierung, Plattformwahl und das Design sicherer, updatefähiger Steuergeräte.

Vom Domain-Bordnetz zu HPC und Adaptive Autosar: Einführung und Trends in Automotive-Software mit Dr. Georg Gaderer (Elektrobit)

Warum wir zuhören: Einordnung der Session

Bei DevJobs.at haben wir „Introduction and Trends in Automotive Software“ mit großem technischen Interesse verfolgt. In der Session von Dr. Georg Gaderer (Speaker) von Elektrobit (Company) wurde präzise herausgearbeitet, weshalb heutige Fahrzeuge ohne hochqualitative Software nicht mehr denkbar sind – und wie sich die Architektur der Steuergeräte, Betriebssysteme und Netzwerke in Richtung „software-defined car“ entwickelt. Die Botschaft ist klar: steigende Rechenleistung, wachsende Funktionsdichte und härteste Sicherheitsanforderungen prägen den gesamten Entwicklungsprozess.

„Product quality is most important.“ – Dieses Leitmotiv zieht sich durch den gesamten Talk: Automotive-Software muss korrekt, sicher und robust sein, weil Fehler reale Konsequenzen haben können.

In diesem Beitrag fassen wir die technischen Kernaussagen zusammen – von der ECU-Landschaft über Autosar Classic und Adaptive bis zu High-Performance-Computern, Hardwarebeschleunigern und zonalen Architekturen. Wir bleiben dabei strikt bei dem, was in der Session gesagt wurde, und leiten praxisnahe Takeaways für Ingenieurinnen und Ingenieure ab.

Der Kontext: Elektrobit und die vier Megatrends

Zum Start ordnet Dr. Gaderer Elektrobit ein: ein global agierender Softwareanbieter, 100% im Eigentum von Continental und dennoch als Unternehmen eigenständig, mit rund 3.500 Mitarbeitenden und einem Kernfokus auf „automotive-grade software“. Die schiere Marktdurchdringung zeigt sich in einer bemerkenswerten Zahl: Mehr als 100 Millionen Fahrzeuge mit Software von Elektrobit sind auf der Straße – in Summe mit einer Milliarde eingebetteter Geräte.

Auf dieser Basis beschreibt er vier große Strömungen, die heute die Automobilindustrie bestimmen:

Automatisiertes Fahren
Elektrifizierung (geringerer CO2-Footprint)
Konnektivität (Services im Fahrzeug via Cloud/Infra)
Geteilte Mobilität

Diese Megatrends sind kein Selbstzweck. Sie fordern neue Rechen- und Software-Architekturen heraus – von der sicheren Sensorik über vernetzte Dienste bis hin zu Fahrzeugservern und Virtualisierung.

Steuergeräte verstehen: ECUs, Zonen und Aufgaben

Um die technische Entwicklung nachvollziehen zu können, lohnt ein Blick auf die Typen elektronischer Steuergeräte (ECUs), die im Fahrzeug verteilt sind:

Performance/Computation Units: Hochperformante Rechenboxen, etwa ein „car server“. Sie bündeln Leistung für rechenintensive Aufgaben.
Sensoren: Von Kameras bis zu Drehzahl- und Lenkwinkelsensoren – modernste Fahrzeuge bringen Dutzende bis Hunderte Sensoren mit.
Aktuatoren: Sie setzen Befehle um (z. B. Bremslicht ansteuern).
Integrations- und Steuerboxen: In bestimmten „Zonen“ des Fahrzeugs angesiedelt, übernehmen sie die lokale Integration und Kontrolle. Diese Zonen-Idee wird später für die Architekturentwicklung entscheidend.

Alle diese Bausteine müssen zusammenspielen. Und sie müssen es deterministisch, sicher und mit klaren Kommunikationsmustern tun.

Smartphone vs. Auto: Warum Automotive-Software anders ist

Die Vision des „software-defined car“ bedeutet: Funktionalität über Software-Features (Apps) erweitern – ein Gedanke, den wir aus der Smartphone-Welt kennen. Aber die Unterschiede sind fundamental:

Smartphone: Ein Prozessor, ein Display, ein OS, wenige Sensorsubsysteme, hunderte Gramm Gewicht, praktisch keine hohe Fahrgeschwindigkeit.
Auto: Hunderte Mikrocontroller, mehrere Displays, mehrere Betriebssysteme, Hunderte Sensoren, ca. zwei Tonnen Gewicht, mögliche Geschwindigkeiten bis 250 km/h.

Der Schluss ist unausweichlich: Fahrzeuge bewegen sich in einem sicherheitskritischen Umfeld. Software muss fehlerarm starten, deterministisch reagieren und in allen Situationen korrekt funktionieren. Andernfalls drohen Unfälle – eine unbedingte Absage an „move fast and break things“.

Safety first: Standards, Prozesse und riesige Testfarmen

Wie produziert man Automotive-Software unter diesen Vorzeichen? Dr. Gaderer nennt mehrere Säulen:

Strikte Programmierregeln: MISRA-C und MISRA-C++ inklusive Security- und Safety-Erweiterungen, um typische Fehlerklassen (z. B. Überläufe, Division durch Null) zu vermeiden.
Zusätzliche Anforderungen: interne Requirements bei Elektrobit sowie Vorgaben der OEMs (Hersteller), inklusive Initiativen wie der Herstellerinitiative Software.
Relevante Normen und Standards: etwa ISO-26262 sowie weitere genannte Standards wie „IC-6108“ oder „DU-178C“ (aus dem Aerospace-Umfeld).
Systematisches Risikomanagement: Ziel ist jederzeit eine belastbare Risikoabschätzung und -steuerung.
Testen im großen Stil: Mehr als eine Million Tests täglich in Testfarmen, ergänzt durch statische Codeanalyse mit spezialisierten Tools.

Diese Disziplinen sorgen dafür, dass Software „the right thing right“ tut – fachlich korrekt und sicher.

Autosar Classic vs. Adaptive: Zwei Welten, ein Fahrzeug

Ein Kernteil des Vortrags widmet sich der Betriebssystem- und Middleware-Ebene: Autosar Classic und Adaptive.

Autosar Classic: Echtzeit, C-Code, kurze Bootzeiten

Stack: C-programmierte Software, ein Echtzeitbetriebssystem (RTOS), typischerweise vollständig vom Softwarezulieferer geliefert und damit unter voller Kontrolle.
Safety: Für sicherheitsrelevante Bereiche geeignet, eben weil deterministischer und stark kontrolliert.
Kommunikation: Signalbasiert (z. B. CAN, LIN, FlexRay) oder servicebasiert – in jedem Fall kontrolliert, robust und auf Echtzeitpfade zugeschnitten.
Hardware: Mikrocontroller mit spezialisierten Peripherien.
Bootzeit: Extrem kurz. Niemand akzeptiert, dass ein Bremslicht erst Sekunden nach dem „Start“ funktioniert.

Adaptive Autosar: POSIX, Services, IP/Ethernet

Stack: Ein POSIX-OS (Linux, QNX oder Android) als Basis, darauf aufbauend Automotive-Software.
Safety: Heute nicht über ACLB hinaus – dennoch muss Security gewährleistet sein.
Kommunikation: Serviceorientierte Welt, IP/Ethernet-basiert. Keine direkten Signalbusse wie CAN an diese Geräte „anflanschen“.
Bootzeit: Sekundenskala ist akzeptabel (z. B. für Head-Unit/Infotainment), wobei auch zwei Sekunden für Linux herausfordernd sein können.

Die Konsequenz: Moderne Fahrzeuge kombinieren beide Welten. Harte Echtzeit und höchste Safety-Anforderungen landen in Classic; rechen- und serviceorientierte Workloads in Adaptive – mit jeweils passender Bootzeit- und Kommunikationsstrategie.

Zweiter Trend: High-Performance-Computer (HPC) als Fahrzeugserver

Mit der Einführung von Fahrzeugservern (HPCs) explodiert die Komplexität. Dr. Gaderer illustriert das über die Entwicklung der Codebasis:

Älterer Body-Controller: 200.000 bis 2 Millionen Zeilen Code.
Navigationssysteme: ca. 4 Millionen Zeilen.
High-End-Infotainment: ca. 10 Millionen Zeilen.
Heutige High-Performance-Controller: ca. 20 Millionen Zeilen – Tendenz steigend.

Technisch bedeutet das:

Mehrere Betriebssysteme auf einem SoC: ein RTOS (Classic), mehrere POSIX-basierte OS (Linux, Android, QNX) und häufig ein Security-OS.
Virtualisierung: Die OS laufen in VMs auf einem Hypervisor.
Bootmanagement: Mehrere Bootmanager orchestrieren den Start – ein integraler Teil, weil die Systemteile unterschiedliche Anforderungen an Startreihenfolge und -zeiten haben.
Updates: Diese Systeme müssen aktualisierbar sein, ohne „zu brechen“ – ein weiteres Engineering-Thema, das in die Boot- und Virtualisierungsstrategie hineinragt.
Hardwareausstattung: 2 bis 4 Prozessoren, insgesamt bis zu 28 Cores.

Für Entwicklerinnen und Entwickler heißt das: Mixed-Criticality, Isolation, definierte Kommunikationspfade und kontrollierte Update-Prozesse werden zum Alltag. Das klassische „ein OS, eine ECU“ ist in der HPC-Ära passé.

Dritter Trend: Hardwarebeschleuniger für Kommunikation (COM-Accelerators)

Als konkretes Beispiel greift Dr. Gaderer den NXP S32G heraus (ähnliche Prinzipien gelten auch für andere Microcontroller). Das Schema zeigt grün/blaue Bereiche für Classic/Adaptive-Rechenkerne – und daneben dedizierte Hardwarebeschleuniger für Kommunikation.

Wozu das Ganze?

Entlastung der CPU-Kerne: Kommunikationsverarbeitung kostet Zeit. Spezialisierte Hardware übernimmt diese Last.
Strikte Trennung: Fehlverhalten in einem OS (z. B. ein „durchdrehender“ Prozess) beeinträchtigt die Kommunikation anderer OS nicht. Die Trennung ist hardwarebasiert.
Firewalling: Segmentierung und kontrollierter Zugriff auf Kommunikationspfade lassen sich im Accelerator abbilden.
VM-Unabhängigkeit: Virtuelle Maschinen bleiben entkoppelt, selbst wenn auf einer Seite sicherheitskritische Steuerung und auf der anderen eine Android-App läuft.
Gateway-Funktionen: Box-zu-Box-Kommunikation bleibt möglich – wohldefiniert und kontrolliert.
Zeitsynchronisation: Eine konsistente gemeinsame Zeitbasis ist übergreifend herstellbar.

Für die Praxis heißt das: Sicherheits- und Echtzeitpfade nicht über general purpose Cores leiten, sondern in Hardware separieren, wenn immer möglich. Das verbessert Determinismus, Safety und Security.

Von Domain zu Zentral zu Zonen: Die Architektur-Evolution

Dr. Gaderer zeichnet die Architekturentwicklung der letzten Jahre nach:

1) Domain-Architektur

Pro Fahrzeugdomäne (z. B. Bremse, Body, Infotainment) existiert ein eigenes Netzwerk.
Gateways verbinden die Domänen.
Nachteil: In der physischen Umsetzung bedeutet das viele parallele Leitungen. Beispiel: Es ergibt keinen Sinn, getrennte Kabelbäume quer durchs Fahrzeug zu legen, wenn ein gemeinsames Netz effizienter wäre.

2) Zentralisierte Architektur

Einführung eines zentralen HPC („vehicle server“), an den die anderen Boxen angebunden sind.
In dieser Phase kommen Adaptive Autosar und Ethernet ins Fahrzeug.
Vorteil: Ein homogenes, zentrales Rückgrat, weniger doppelte Verkabelung.

3) Controller pro Fahrzeugbereich („Zonen“)

An jeder Region des Fahrzeugs wird eine Integrations-/Steuerbox platziert, die lokale Funktionen bündelt und Cross-Zonen-Kommunikation ermöglicht.
Lokalisierung der klassischen Feldbusse (CAN, LIN, FlexRay) pro Zone – und zugleich Vorteile verteilter Intelligenz.

Die Bewegung geht also weg von isolierten Domänen, über Zentralisierung hin zu strukturierten Zonen mit klaren Kommunikationsgrenzen – auf einem gemeinsamen Netz.

Bootzeiten, Safety-Level, Kommunikationsmuster: Entscheidungen mit System

Der Talk vermittelt eine Reihe von Entscheidungsregeln, die wir aus Engineering-Sicht so zusammenfassen:

Bootzeitanforderung klärt die Ebene: Wenn Funktionsbereitschaft sofort nötig ist (z. B. Bremslicht), führt kein Weg an Classic/RTOS vorbei. Für komfortorientierte Komponenten sind Sekunden boot akzeptabel.
Safety-Level vs. OS-Stack: Für hohe Safety-Ansprüche bleibt Classic die erste Wahl. Adaptive bewegt sich, wie gehört, aktuell nicht über ACLB hinaus – Security muss dennoch robust umgesetzt werden.
Kommunikationsbedarf: Signalbasierte Kommunikationspfade (CAN/LIN/FlexRay) sind in Classic verankert; serviceorientierte Kommunikation läuft in der Adaptive/IP/Ethernet-Welt. HPCs müssen beide Sphären trennen und zugleich sinnvoll koppeln.
Virtualisierung als Muss: Mehrere OS auf einem SoC erfordern Hypervisor, Bootmanager und strikt geregelte Update-Prozesse.
Hardware-Offloading nutzen: Kommunikationsaufgaben in Accelerators auslagern, um Core-Last, Interferenzrisiken und Latenzen zu reduzieren.

Diese Leitplanken helfen, Systemgrenzen korrekt zu ziehen und Risiken schon in der Architektur zu minimieren.

Testen und Analyse im Maßstab „Automotive“

Die Zahl „>1 Million Tests täglich“ illustriert, dass Qualität hier nicht allein ein Prozessschritt ist, sondern eine Plattformfrage. Tests müssen:

breit streuen (Funktionalität, Schnittstellen, Regressionen),
automatisiert und reproduzierbar sein,
durch statische Analysen flankiert werden (z. B. Erkennung von Überläufen oder Division durch Null),
zielgerichtet auf Risiko gesteuert werden (Fokus auf sicherheitskritische Pfade).

Für Engineering-Teams bedeutet das: Tooling, Infrastruktur und klare Definition of Done sind genauso wichtig wie Code. Safety ist kein nachträglicher Check, sondern Teil des Designs.

Praktische Takeaways für Software- und Systemingenieur:innen

Aus der Session von Dr. Georg Gaderer (Elektrobit) lassen sich konkrete Handlungsanweisungen für die tägliche Arbeit ableiten:

Anforderungen schärfen: Start-/Bootzeiten, Safety-Level und Kommunikationspfade früh definieren – sie steuern die Wahl von Classic vs. Adaptive und den Einsatz von Hardwarebeschleunigern.
Mixed-Criticality absichern: SoCs mit Hypervisor sauber partitionieren; sicherheitskritische Funktionen strikt isolieren – sowohl software- als auch hardwareseitig.
Serviceorientierung gezielt nutzen: IP/Ethernet in Adaptive bietet Flexibilität, verlangt aber Security-by-Design und robuste Update-Konzepte.
Feldbusse gezielt lokalisieren: CAN/LIN/FlexRay in Zonen begrenzen; Gateways und COM-Accelerators als kontrollierte Brücken einsetzen.
Zeitsynchronisation planen: Eine gemeinsame Zeitbasis über Domänen/VMs hinweg ist Voraussetzung für deterministisches Verhalten in verteilten Systemen.
Testen skalieren: Continuous Testing und statische Analysen fest verankern; „mehr als eine Million Tests täglich“ ist die Größenordnung, die moderne Automotive-Projekte benötigen.
Standards ernst nehmen: MISRA-C/C++, Herstellerinitiative Software, ISO-26262 und die im Talk genannten weiteren Standards („IC-6108“, „DU-178C“) sind nicht optional, sondern Rahmenbedingungen.

Diese Punkte greifen direkt die im Vortrag adressierten Herausforderungen auf – ohne zusätzliche Annahmen oder Spekulation.

Fazit: Engineering am Limit – und genau deshalb spannend

Der Talk „Introduction and Trends in Automotive Software“ von Dr. Georg Gaderer (Elektrobit) macht unmissverständlich klar: Die technischen Computing-Trends – von Adaptive/Serviceorientierung über HPC/Virtualisierung bis zu Hardwarebeschleunigern – ermöglichen erst die großen Megatrends wie automatisiertes Fahren und vernetzte Dienste. Gleichzeitig wächst die Komplexität dramatisch: Kabelbäume, Steuergeräte, Bootmanager, Hypervisor, Sicherheitsniveaus und Kommunikationsnetze bilden ein eng verzahntes System, das durchgängig korrekt funktionieren muss.

Die drei zentralen Trends, die wir mitnehmen:

Leistungsstarke Rechenplattformen ergänzen Echtzeitkerne im Fahrzeug.
High-Performance-Computer (HPCs) als Vehicle Server erhöhen Funktionsdichte und Komplexität.
Hardwarebeschleuniger entlasten die Cores von reiner Kommunikationslast und schaffen harte Isolation.

Kurz: Automotive-Softwareentwicklung ist herausfordernd – und hochinteressant. Wer sich auf Standards, Tests und klare Architekturprinzipien stützt, kann „the right thing right“ bauen. Genau das braucht es, um die nächsten Fahrzeuggenerationen sicher, vernetzt und funktionsreich auf die Straße zu bringen.

Weitere Tech Lead Stories

Weitere Dev Stories