Rust im Fahrzeug Warum die Sprach- zur Regulierungsfrage geworden ist

Anbieter zum Thema

Metrofunk Kabel-Union GmbH

Würth Elektronik eiSos GmbH & Co. KG

Die Wahl der Programmiersprache für Fahrzeugsteuergeräte galt lange als reine Entwicklungsfrage. Seit in der EU eine UN-Regulierung für alle neu zugelassenen Fahrzeuge verbindlich ist und europäische Hersteller erste Rust-basierte Steuergeräte-Software in Serienfahrzeugen ausliefern, ist daraus eine Entscheidung geworden, die Architektur, Zulassung und Einkauf betrifft.

Als Mitgründer eines Unternehmens, das Software für Fahrzeugsteuergeräte entwickelt und ausliefert, beobachte ich eine Verschiebung, die inzwischen auch Produkthaftung und Strategie berührt. Die Frage, in welcher Programmiersprache Fahrzeug-Software geschrieben wird, verlässt die Entwicklerbüros und rückt in Bereiche, in denen über Architektur, Risiko und Zulassung entschieden wird. 2026 liefern europäische Hersteller erstmals Rust-basierte Software in Serienfahrzeugen aus. Das ist kein Experiment, sondern eine Reaktion auf Anforderungen, die seit Mitte 2024 gelten.

Was die UN-Regulierung ausgelöst hat

UNECE R155 ist die UN-Regulierung zur Fahrzeugcybersicherheit. Seit Juli 2024 ist sie für alle neuen in der EU zugelassenen Fahrzeuge verbindlich. Hersteller und Zulieferer müssen seither nachweisen, dass ihre Fahrzeug-Software auf Cyberangriffe überwacht, bewertet und bei Bedarf aktualisiert werden kann. Im Fokus stehen kryptografische Funktionen, Update-Mechanismen für drahtlose Softwareaktualisierungen und alle Komponenten, die externe Daten verarbeiten. Genau dort sitzen auch die gefährlichsten Software-Fehler.

Was sich durch die Regulierung ändert, ist weniger ein neues Feature, sondern die Nachweispflicht. Wer heute ein neues Fahrzeug zulassen will, muss darlegen, wie die Software über den gesamten Lebenszyklus überwacht und abgesichert wird. Das verändert die Bewertung von Programmiersprachen. Was gestern eine reine Entwicklungsentscheidung war, ist heute Teil eines Dossiers, das gegenüber Behörden und Zertifizierungsstellen bestehen muss.

Warum Speicherfehler zum zentralen Thema werden

Eine Studie des Microsoft Security Response Center und dem Google Chrome Security-Programm weist aus, dass 60 bis 70 Prozent der Sicherheitslücken in eingebetteten Systemen auf Speicherprobleme zurückgehen. Gemeint sind Fehler, bei denen Software auf Speicher zugreift, auf den sie nicht zugreifen sollte, oder auf Speicher, der bereits freigegeben wurde. Das Problem mit dieser Fehlerklasse: Sie ist im Fahrzeug oft nicht sichtbar.

Auf einem Desktop-Betriebssystem fängt ein Schutzmechanismus eine Speicherkorruption meist ab und erzeugt einen sichtbaren Absturz. Auf einem Mikrocontroller in einem Fahrzeug fehlt dieser Schutz in vielen Fällen. Ein korrumpierter Zustand kann unbemerkt bestehen bleiben und zu unzuverlässigen Sensordaten oder Fehlfunktionen in sicherheitskritischen Systemen führen. In der Produktion ist das die Fehlerklasse, die am schwersten zu reproduzieren und am teuersten zu beheben ist.

Rust adressiert dieses Problem auf Sprachebene. Das Ownership-Modell, der Kernmechanismus der Sprache zur Speicherverwaltung, legt bereits zum Zeitpunkt der Übersetzung fest, welche Programmteile wann auf welchen Speicherbereich zugreifen dürfen. Unzulässige Zugriffe werden nicht zur Laufzeit abgefangen, sondern vom Compiler abgelehnt. Code, der nicht gebaut werden kann, kann auch im Feld keinen Schaden anrichten.

Was europäische Hersteller heute ausliefern

Wer Rust im Automotive-Bereich bisher mit dem Argument abwehrte, es fehlten Serienreferenzen, hat 2026 weniger Argumente. In jedem Volvo EX90 und Polestar 3, der heute vom Band läuft, arbeitet ein Low-Power-Steuergerät, dessen Firmware vollständig in Rust geschrieben ist. Ampere, die Elektromobilitätsmarke der Renault-Gruppe, hat über 200 Entwickler in Rust geschult und setzt die Sprache gezielt in sicherheitsrelevanten Komponenten ein. Dazu gehören kryptografische Operationen und die Prozesse für Firmware-Updates. Für die nächste Generation von Fahrerassistenzsystemen plant Ampere den Einsatz von Rust auf ASIL-B-Niveau. Rust heute auf Stufe B serientauglich einsetzen zu können, setzt qualifizierte Compiler und zertifizierte Teile der Standardbibliothek voraus. Diese Infrastruktur ist seit der Embedded World 2026 sichtbar gewachsen.

Keine Sprachdebatte, sondern eine Architekturfrage

Rust ersetzt C nicht. Wer das behauptet, kennt die Realität industrieller Embedded-Entwicklung mit Produktlebenszyklen von 15 Jahren nicht. Die Frage, die Entwicklungsleitung und Einkauf heute beantworten müssen, lautet anders. An welchen Stellen senkt der Wechsel das Gesamtrisiko, und an welchen Stellen erhöht er es?

AUTOSAR Classic ist in C implementiert und seit Jahrzehnten im Feld validiert. Hardware-nahe Treiber, die unter bestehenden Werkzeugketten bereits auf höchster Sicherheitsstufe zertifiziert wurden, neu zu schreiben, ergibt wirtschaftlich keinen Sinn. Das C-Ökosystem für diese Schichten ist ausgereift, auditiert und in seinem Fehlerverhalten gut verstanden. Die pragmatische Antwort liefert die AUTOSAR-Laufzeitumgebung, also die Schnittstelle zwischen Applikations- und Basis-Software. Etliche Automotive-Softwareanbieter ermöglichen heute Rust-Komponenten auf dieser Schicht. Bestehender C-Code und neuer Rust-Code koexistieren im selben Steuergeräteprojekt. Das ist kein Kompromiss, sondern Engineering-Realität.

Auch innerhalb des Rust-Ökosystems ist Sicherheitszertifizierung kein binärer Schalter. Ferrocene, die zertifizierte Rust-Werkzeugkette für sicherheitskritische Anwendungen, ist für den Compiler auf ASIL D qualifiziert, für Teile der Kernbibliothek derzeit auf ASIL B. Das Ökosystem schließt diese Lücken kontinuierlich, aber wer heute auf höchsten Sicherheitsstufen arbeitet, muss das in die Architekturentscheidung einrechnen.

Wo Rust im Fahrzeug heute den größten Hebel hat

Aus Sicht eines Unternehmens, das Rust-basierte Software für Steuergeräte vom Infineon Aurix TriCore bis zum Linux-basierten Hochleistungssystem entwickelt und ausliefert, kristallisieren sich drei Einsatzfelder heraus.

Die Software-Schicht zwischen Hardware-Abstraktion und eigentlicher Fahrzeugfunktion wächst in ihrer Komplexität am stärksten. Parallele Prozesse, asynchrone Kommunikation zwischen Komponenten und ein Zustandsmodell, das global korrumpiert werden kann, wenn die Speicherverwaltung fehlerhaft ist. Der Mechanismus, mit dem Rust parallele Schreibzugriffe bereits zur Übersetzungszeit verhindert, greift hier am direktesten und schaltet eine Fehlerklasse aus, die in C-Codebasen zu den aufwendigsten Debugging-Fällen gehört.

Die zweite Gruppe umfasst Komponenten mit Angriffsfläche. Kryptografische Funktionen, Update-Handler und Parser für externe Nachrichten sind die Stellen, an denen Speicherfehler nicht zu Fehlfunktionen führen, sondern zu ausnutzbaren Sicherheitslücken. Hier ist strukturelle Speichersicherheit keine technische Tugend, sondern eine regulatorische Erwartung. Wer UNECE R155 nachweislich erfüllen will, wird für diese Komponenten begründen müssen, warum er auf die Sicherheitsgarantien verzichtet, die Rust auf Sprachebene liefert.

Die dritte Gruppe sind neue Plattformen ohne Altbestand. Wer heute ein neues Steuergerät von Grund auf entwickelt, hat kei

nen sachlichen Grund mehr, dabei ausschließlich auf C zu bestehen. In Projekten auf der grünen Wiese entfallen Migrationskosten vollständig, die Werkzeugauswahl ist frei, und das Team kann von Beginn an mit den Sicherheitsgarantien der Sprache arbeiten, statt sie nachträglich durch externe Analysewerkzeuge herzustellen.

Der Ausredenkatalog wird kürzer

Für technische Entscheider lautet die produktivere Frage nicht mehr „Rust oder C?“, sondern: Welche Komponenten tragen mit welcher Sprache das geringste Gesamtrisiko, technisch, regulatorisch und wirtschaftlich? Das ist eine Architekturentscheidung, keine Sprachdebatte.

Was sich 2026 verändert hat, ist konkret. Fahrzeughersteller liefern Serienfahrzeuge mit Rust-Komponenten aus. Regulierungsanforderungen konkretisieren sich. Zertifizierungsinfrastruktur wächst. Wer heute eine neue Steuergeräteplattform aufsetzt, muss begründen, warum er Rust nicht einsetzt, nicht mehr umgekehrt.

Die Frage lautet also nicht mehr, ob Rust ins Fahrzeug gehört. Sondern welche Komponenten zuerst migriert werden und mit welcher technischen und regulatorischen Begründung. (se)

Software-Defined Vehicle

Rust in Automotive

Kooperation von HighTec, Elektrobit und Infineon

Nahtlose Integration von Rust-Anwendungen in AUTOSAR Classic-Basissoftware

* Daniel Frassinelli ist Mitgründer und CTO bei der Veecle GmbH.

(ID:50827587)