Was es im Jahr 2026 tatsächlich braucht, um KI-gestützte Automobilsoftware zu entwickeln

Das Auto, das Sie heute kaufen, wird mit einer Roadmap ausgeliefert – und zwar ausschließlich mit Software. Der Funktionsumfang bei Auslieferung entspricht Version 1.0, das eigentliche Produkt entwickelt sich jedoch durch die Updates der nächsten fünf Jahre. Diese Entwicklung wandelt die Automobil-Softwareentwicklung von einer einmaligen Ingenieursaufgabe zu einer kontinuierlichen Produktdisziplin, die eher SaaS als der Fertigung ähnelt.

Auch KI ist zu einem entscheidenden Bestandteil des Systems geworden: Modelle, die Inferenzprozesse am Netzwerkrand durchführen, Assistenten, die Interaktionen im Fahrzeuginnenraum steuern, oder Systeme, die einen Ausfall einer Komponente vorhersagen, bevor der Fahrer überhaupt etwas bemerkt.

Wenn Sie gerade ein KI-Projekt im Automobilbereich planen oder prüfen, ob Ihr aktuelles Team dazu in der Lage ist, erfahren Sie in diesem Artikel, was die Arbeit tatsächlich beinhaltet – von der Architektur über Standards bis hin zum Technologie-Stack – und wo die meisten Projekte scheitern.

Von Hardware zu Software: Softwaredefinierte Fahrzeuge

Der Begriff „softwaredefiniertes Fahrzeug“ (SDV) wird oft ungenau verwendet, seine technische Bedeutung ist jedoch präzise. Ein herkömmliches Fahrzeug verteilt seine Funktionen auf Dutzende isolierter elektronischer Steuergeräte (ECUs), die jeweils mit proprietärer Firmware und minimaler Kommunikation untereinander arbeiten. Ein softwaredefiniertes Fahrzeug hingegen konsolidiert diese Funktionen auf zentralen Rechenplattformen. Dort steuert die Software das Fahrzeugverhalten, und neue Funktionen können drahtlos (OTA) bereitgestellt werden, ohne dass die Hardware verändert werden muss.

Dieser Architekturwandel ist für die Softwareentwicklung im Automobilbereich von enormer Bedeutung, denn er bedeutet Folgendes:

• Fahrzeugfunktionen, die früher einen physischen Austausch des Steuergeräts erforderten, können jetzt per Fernzugriff aktualisiert werden.
• Funktionen können nach dem Verkauf durch Abonnement- oder Funktions-auf-Abruf-Modelle monetarisiert werden.
• Ein einziges Softwareteam kann den gesamten Fahrzeuglebenszyklus managen, nicht nur die Vorproduktionsphase.
• Die Logik für das OTA-Rollback wird genauso wichtig wie das Update selbst.

Der Markt für softwaredefinierte Fahrzeuge (SDV) verdeutlicht die rasante Entwicklung dieser Technologie. Laut Fortune Business Insights wurde der globale Markt für Automobilsoftware im Jahr 2025 auf 36 Milliarden US-Dollar geschätzt und soll bis 2034 auf 113 Milliarden US-Dollar anwachsen. Der SDV-Sektor wächst jährlich um 25–30 %, was etwa dem Achtfachen des Wachstums des gesamten Automobilmarktes entspricht.

Die nächste Stufe dieser Entwicklung hat einen Namen: das KI-definierte Fahrzeug (AIDV). Während das SDV die architektonische Grundlage bildet (zentralisierte Rechenleistung, OTA-Bereitstellung, modulare Softwareschichten), führt das AIDV KI nicht als Anwendungsfunktion, sondern als grundlegende Plattformschicht ein. Das Fahrzeug interpretiert den Kontext, lernt aus Fahrmustern und passt sein Verhalten in Echtzeit an. Diese Unterscheidung ist für Entwicklungsteams heute relevant, denn die Konzeption einer AIDV-Architektur von Anfang an ist ein völlig anderes Projekt als die nachträgliche Integration von KI-Funktionen in einen bestehenden SDV-Stack.

Die 5 Kernkomponenten von KI-Automobilsoftware

Die Entwicklung von Automobilsoftware für KI-fähige Fahrzeuge umfasst fünf verschiedene Funktionsebenen. Jede dieser Ebenen hat ihre eigene Ingenieursdisziplin, die wir im Folgenden näher erläutern.

ADAS- und Wahrnehmungssysteme

Die Entwicklung von Software für Fahrerassistenzsysteme (ADAS) ist der Bereich, in dem der größte Teil der rechenintensiven Arbeit stattfindet. Wahrnehmungspipelines erfassen gleichzeitig Daten von Kameras, Radar, LiDAR und Ultraschallsensoren, und Sensorfusionsalgorithmen führen diese Eingaben zu einem kohärenten Echtzeitmodell der Fahrzeugumgebung zusammen.

Die technische Herausforderung besteht nicht nur in der Genauigkeit, sondern auch in der Genauigkeit unter Bedingungen, die in den Trainingsdaten nicht enthalten waren. Regen in der Nacht, ein teilweise verdecktes Stoppschild und ein Fußgänger, der zwischen geparkten Lkw hervortritt, sind Beispiele für Hindernisse, die die Systeme erst durch zufällige, seltene Begegnungen erkennen. Die Entwicklung von ADAS-Software für den Produktiveinsatz erfordert die Abdeckung eines breiten Spektrums an Störszenarien, nicht nur die Erfüllung von Benchmark-Vorgaben.

Auf der CES 2026 präsentierte KPIT Technologies eine agentenbasierte KI-Suite, die auf generativer KI basiert und speziell für die Beschleunigung der Entwicklungszyklen von ADAS und die Reduzierung von Fehlern in sicherheitskritischen Systemen entwickelt wurde. Die Richtung ist klar: KI wird nun eingesetzt, um bessere KI für Fahrzeuge zu entwickeln.

Fahrzeuginterne KI und das digitale Cockpit

Das digitale Cockpit ist die Benutzerschnittstelle der KI-Architektur. Hier kommt die fahrzeuginterne KI in Form von Sprachassistenten, personalisierten Einstellungen, vorausschauender Navigation und kontextbezogenem Infotainment zum Einsatz. Es ist zudem einer der dynamischsten Bereiche der Architektur, angetrieben durch die Integration von LLM (Low-Level-Management) und den Trend hin zu fahrzeuginternen LLM-Architekturen, die natürliche Sprachbefehle für mehrere Fahrzeugfunktionen gleichzeitig verarbeiten können.

Für eine erfolgreiche Integration von KI in Fahrzeuge reicht es nicht aus, einfach ein umfangreiches Sprachmodell einzubinden. Die Latenzanforderungen für die Fahrerinteraktion werden in Millisekunden gemessen. Daher müssen die Modelle zuverlässig auf ressourcenbeschränkter Edge-Hardware laufen. Zudem muss das System bei Verbindungsverlust einen reibungslosen Leistungsabfall gewährleisten, da sich der Fahrer weiterhin im Fahrzeug befindet – unabhängig davon, ob die Cloud erreichbar ist.

Vorausschauende Wartung und Diagnose

Vorausschauende Wartungssoftware für Fahrzeuge überwacht Sensordaten von Antriebsstrang, Batterie, Bremsen und Fahrwerk, um Anomalien zu erkennen, bevor es zu Ausfällen kommt. Für Flottenbetreiber und OEMs mit vernetzten Fahrzeugprogrammen zählt dies zu den KI-Anwendungen mit dem höchsten ROI, da die Kosten einer ungeplanten Panne fast immer höher sind als die Kosten einer präventiven Reparatur.

Eine erfolgreiche Umsetzung erfordert mehr als das Trainieren eines Klassifizierungsmodells anhand von Fehlercodes. Sie müssen eine Datenpipeline entwerfen, die Telemetriedaten zuverlässig vom Fahrzeug zur Auswertungsschicht überträgt, fehlende oder verrauschte Signale verarbeitet und handlungsrelevante Warnmeldungen anstelle von Wahrscheinlichkeitswerten liefert, die ein Wartungsteam nicht nutzen kann.

OTA-Update-Infrastruktur

FOTA (Firmware-over-the-Air) ist einer der weniger glamourösen Bereiche der Softwarearchitektur im Automobilbereich, aber von entscheidender Bedeutung für den Betrieb. Ein schlecht konzipiertes OTA-System kann dazu führen, dass Fahrzeuge in großem Umfang unbrauchbar werden, Compliance-Risiken entstehen oder das System stillschweigend ausfällt – was in mancher Hinsicht noch schlimmer ist.

Eine produktionsreife OTA-Infrastruktur für Automobilsoftware muss folgende Anforderungen erfüllen:

• Komprimierung von Delta-Updates zur Minimierung der Bandbreitenbelastung im Mobilfunknetz
• Kryptografische Signierung und Verifizierung auf jeder Ebene
• Stufenweise Rollouts mit automatischem Rollback bei Fehlern
• Einhaltung der UNECE R156, der internationalen Regulierungsnorm für OTA-Software-Updates in Fahrzeugen

Laut der JD Power Vehicle Dependability Study gaben 58 % der Fahrer, die im Jahr 2025 OTA-Updates erhielten, an, keine spürbare Verbesserung festgestellt zu haben. Diese Zahl sagt etwas Wichtiges über die Kluft zwischen der Bereitstellung eines Updates und der Bereitstellung eines guten Updates aus.

V2X und Datenpipelines für vernetzte Fahrzeuge

Software für vernetzte Fahrzeuge verwaltet die Kommunikation zwischen dem Fahrzeug und externen Systemen wie Infrastruktur, anderen Fahrzeugen, Flottenmanagement-Plattformen und Cloud-Backends. V2X-Protokolle (Vehicle-to-Everything) ermöglichen Anwendungsfälle, die von der Optimierung von Ampelsystemen bis hin zur Koordination zur Kollisionsvermeidung reichen.

Die Herausforderung im Bereich Data Engineering ist hier erheblich. Ein einzelnes Fahrzeug generiert pro Stunde zwischen 25 und 100 GB an Sensor- und Telemetriedaten. Die Entscheidung, was am Edge verarbeitet, was übertragen und was gespeichert werden soll, erfordert sorgfältige architektonische Vorarbeit und ist keine nachträgliche Leistungsoptimierung.

Warum das tatsächlich schwierig ist: Die echten Herausforderungen bei der Entwicklung von Automobilsoftware

Die Herausforderungen bei der Entwicklung softwaredefinierter Fahrzeuge werden in den Marketinginhalten zu diesem Thema nicht ausreichend behandelt. Hier listen wir reale Probleme auf, mit denen Teams tatsächlich konfrontiert sind, basierend auf unseren eigenen Entwicklungserfahrungen.

Funktionale Sicherheit ist keine Dokumentation

ISO 26262 ist die internationale Norm für funktionale Sicherheit in der Automobilsoftware. MISRA C ist der Satz von Codierungsrichtlinien, der die C- und C++-Entwicklung in sicherheitskritischen Systemen regelt. AUTOSAR ist das Software-Architektur-Framework, dessen Einhaltung von den meisten OEM-Lieferketten verlangt wird.

Der Fehler, den die meisten Software-Teams außerhalb der Automobilbranche begehen, besteht darin, diese als Checklisten für die Konformität zu betrachten – also als etwas, das das QA-Team am Ende erledigt. In Wirklichkeit bestimmen die Anforderungen an die funktionale Sicherheit, wie Sie das System architektonisch gestalten, wie Sie Code schreiben und überprüfen, wie Sie testen und wie Sie jede Designentscheidung dokumentieren.

Es handelt sich nicht um eine Ebene, die man der fertigen Software erst nachträglich hinzufügt, sondern um eine Vorgabe, die von Anfang an jede technische Entscheidung durchzieht. Der Softwareentwicklungsprozess für sicherheitskritische Komponenten im Automobilbereich umfasst eine Gefahrenanalyse und Risikobewertung (HARA) während der Entwurfsphase, Software-in-the-Loop- und Hardware-in-the-Loop-Tests sowie eine umfassende Rückverfolgbarkeit von den Anforderungen bis hin zu den Testfällen. Dies ist nicht optional, und man kann ab einem bestimmten Punkt nicht mehr beschleunigen.

Die Einschränkungen bei der Rechenleistung am Edge sind real

Große KI-Modelle laufen problemlos auf Cloud-GPUs. Auf der eingebetteten Rechenhardware in den meisten Serienfahrzeugen laufen sie jedoch nicht problemlos. Eingebettete Automobilsoftware für KI-Anwendungen erfordert Modellkomprimierung, Quantisierung und in vielen Fällen speziell entwickelte Inferenz-Laufzeitumgebungen wie ONNX oder TensorFlow Lite, die für den jeweiligen SoC im Fahrzeug optimiert sind.

Der Kompromiss zwischen Modellgenauigkeit und Inferenzlatenz auf ressourcenbeschränkter Hardware ist eine der entscheidenden technischen Herausforderungen bei der Entwicklung von KI für den Automobilbereich. Wenn hier Fehler gemacht werden, entstehen Systeme, die entweder zu langsam sind, um sicher zu sein, oder zu ungenau, um nützlich zu sein.

Datenlabeling im Automobilmaßstab

Das Trainieren eines Wahrnehmungsmodells für ADAS ist kein Wochenendprojekt. Produktionsdatensätze für die ADAS-Softwareentwicklung umfassen Millionen von gelabelten Bildern unter verschiedenen Lichtverhältnissen, geografischen Bedingungen, Wetterbedingungen und Randfällen. Die Labeling-Pipeline selbst ist eine technische Herausforderung hinsichtlich Konsistenz, Qualitätskontrolle und der Tools zur Verwaltung von Annotationen in großem Maßstab, was allesamt spezielle Investitionen erfordert.

Viele Unternehmen starten ein KI-Projekt für die Automobilindustrie, ohne dies zu verstehen, entdecken das Datenproblem nach sechs Monaten und gehen entweder Kompromisse bei der Modellqualität ein oder verfehlen den Zeitplan.

Regulatorische Unterschiede zwischen den Märkten

Die Compliance-Anforderungen für die Softwareentwicklung in der Automobilindustrie variieren je nach Region in einer Weise, die für die Architektur von Bedeutung ist. Die UNECE-Vorschriften der EU (R155 für Cybersicherheit, R156 für OTA-Updates) legen Anforderungen fest, die sich von den US-amerikanischen NHTSA-Richtlinien und den sich entwickelnden chinesischen GB-Standards unterscheiden.

Wenn Sie Software für ein Fahrzeug entwickeln, das in mehreren Märkten verkauft werden soll, muss dies bereits bei der Systemkonzeption berücksichtigt werden, da die nachträgliche Anpassung an die Vorschriften verschiedener Märkte kostspielig ist.

Der Automotive-KI-Tech-Stack

Die Auswahlmöglichkeiten beim Automotive-KI-Tech-Stack sind eingeschränkter als in der allgemeinen Softwareentwicklung. So sieht die tatsächliche Landschaft im Jahr 2026 aus.

Betriebssystemebene:

• Automotive Grade Linux (AGL) für Infotainment und nicht sicherheitsrelevante Bereiche
• BlackBerry QNX für sicherheitskritische Echtzeitsysteme (QNX und Vector Informatik unterzeichneten im Juni 2025 eine Absichtserklärung zur gemeinsamen Entwicklung einer grundlegenden SDV-Plattform)
• AUTOSAR Adaptive für serviceorientierte Middleware auf Hochleistungs-Recheneinheiten
• AUTOSAR Classic für traditionelle ECU-basierte Bereiche, in denen es weiterhin eingebettet bleibt

KI und Inferenz:

• PyTorch und TensorFlow für das Modelltraining
• TensorFlow Lite und ONNX Runtime für Edge-Inferenz auf Fahrzeug-SoCs
• CUDA für GPU-beschleunigte Inferenz, sofern die Rechenressourcen dies zulassen
• Domänenspezifische LLMs, die auf Interaktionsdaten aus dem Automobilbereich für Assistenzsysteme im Fahrzeug feinabgestimmt sind

Kommunikation:

• SOME/IP und DDS für die fahrzeuginterne Dienstkommunikation
• MQTT und AMQP für Cloud-Telemetrie-Pipelines
• Spezielle V2X-Stacks (DSRC, C-V2X) für die Infrastrukturkommunikation

Cloud und Backend:

• AWS und Azure bieten beide automobil-spezifische SDKs und Dienste für vernetzte Fahrzeuge an
• OTA-Management-Plattformen, darunter Uptane (das Sicherheits-Framework, das von den meisten OTA-Systemen in der Serienproduktion verwendet wird)

Sprachen:

• C und C++ für eingebettete und sicherheitskritische Bereiche (mit MISRA-konformen Tools)
• Rust gewinnt bei eingebetteten Anwendungen an Boden, bei denen Speichersicherheit wichtig ist und der Overhead von C akzeptabel ist
• Python für ML-Pipelines und Tools (nicht in der Fahrzeug-Laufzeitumgebung)

Wie ein kompetentes Entwicklungsteam für KI-Software im Automobilbereich tatsächlich aussieht

Bei der Einstellung von Softwareentwicklern für die Automobilbranche laufen Projekte am häufigsten schief, weil man dabei die Fachkenntnislücke nicht berücksichtigt. So kommt es, dass man nach sechs Monaten ein Team hat, das zwar hervorragend Python programmiert, aber noch nie nach ISO 26262 gearbeitet hat und keine Ahnung hat, was AUTOSAR ist.

Ein Partner für die Entwicklung von KI im Automobilbereich, der serienreife Ergebnisse liefern kann, benötigt:

• Embedded-Software-Ingenieure, die Erfahrung mit Echtzeitbetriebssystemen haben
• KI- und ML-Ingenieure, die Erfahrung mit der Bereitstellung von Modellen auf Edge-Hardware haben, nicht nur mit deren Training
• Ingenieure für funktionale Sicherheit, die ISO 26262 auf Architekturebene verstehen
• Ein QA-Softwaretestteam, das den Unterschied zwischen Softwaretests und der Validierung von Automobilsoftware kennt

Wie man mit der Entwicklung von KI-Software für die Automobilindustrie beginnt, ohne sechs Monate zu verschwenden

Die Frage, wie KI-gestützte Software für die Automobilindustrie entwickelt wird, wird oft als große Architekturfrage dargestellt. In der Praxis ist der effektivste Ausgangspunkt enger gefasst: Wählen Sie ein klar abgegrenztes Problem, entwickeln Sie eine Lösung in Serienqualität und nutzen Sie diese, um die Werkzeuge, Prozesse und das Teamverständnis zu entwickeln, die ein größeres Programm erfordert.

Beispielsweise ist Software für die vorausschauende Wartung im Automobilbereich oft ein gutes erstes Projekt. Die Daten sind vorhanden (Fahrzeugtelemetrie wird bei den meisten modernen Fahrzeugen bereits erfasst), der ROI ist messbar (reduzierte ungeplante Ausfallzeiten) und die sicherheitsrelevanten Auswirkungen sind geringer als bei Wahrnehmungs- oder ADAS-Systemen, was bedeutet, dass Sie schneller vorankommen können, während Sie gleichzeitig die organisatorischen Strukturen für funktionale Sicherheitsprozesse aufbauen.

Einige Dinge, die es in den ersten zwei Wochen zu entscheiden gilt, nicht erst im sechsten Monat:

• Edge- oder Cloud-Inferenz?
  Dies bestimmt die Hardwareanforderungen, die Latenzarchitektur und die Annahmen zur Konnektivität für das gesamte Projekt.
• Welche Sicherheitsklassifizierung gilt?
  ISO 26262 umfasst ASIL-Stufen von A bis D. Zu verstehen, wo Ihr Anwendungsfall angesiedelt ist, bestimmt, wie viel Sicherheitsprozess Sie benötigen und welche Werkzeuge unverzichtbar sind.
• OTA vom ersten Tag an?
  Die nachträgliche Integration von OTA-Fähigkeiten in einen Fahrzeug-Software-Stack, der nicht dafür ausgelegt ist, ist kostspielig. Wenn die Produkt-Roadmap Updates nach der Bereitstellung vorsieht, müssen diese in die ursprüngliche Architektur einbezogen werden.

Hier macht sich eine Discovery-Phase bezahlt. In der Automobil-KI bedeutet eine falsche Architekturentscheidung in Woche zwei eine sechsmonatige Korrekturphase in Monat acht.

Planen Sie ein Projekt im Bereich der Automobil-KI? Wir sind schon lange genug in diesem Bereich tätig, um zu wissen, welche Entscheidungen in Woche eins wichtig sind und welche zwar dringend erscheinen, es aber nicht sind. Kontaktieren Sie Redwerk noch heute und lassen Sie uns darüber sprechen, wie wir Ihr Produkt entwickeln können.

FAQ

Erfahren Sie, wie wir Mass Movement bei der Zusammenführung von Vermögenswerten mit JB Hunt unterstützt haben, was zu einem Umsatzwachstum von 2,74 Milliarden US-Dollar führte

Bitte geben Sie Ihre Geschäfts-E-Mail-Adresse ein ist keine Geschäfts-E-Mail

Fallstudie abrufen