Rust im Fahrzeug Hype oder der Anfang vom Ende von C in sicherheitskritischen Systemen?

Anbieter zum Thema

emlix GmbH

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

Rust ist im Fahrzeug längst mehr als ein Experiment. Serienprojekte, Cybersecurity-Vorgaben und zertifizierte Toolchains verschieben die Debatte: Wo senkt Rust heute konkret das Risiko gegenüber C?

Rust oder C? Die Frage stellen sich heute viele Entwicklungsteams in der Automobilelektronik. Während sie lange theoretisch blieb, hat sie 2026 eine neue Qualität: OEMs liefern Rust-basierte Steuergeräte-Software in Serienfahrzeugen aus, und eine Regulierung, die seit Juli 2024 greift, erhöht den Handlungsdruck. Als Mitgründer und CTO, der seit Jahren Rust-Software für Automotive-Steuergeräte entwickelt und ausliefert, habe ich eine klare Einschätzung, welche Komponenten davon profitieren – und welche nicht.

Warum die Frage nicht verschwindet

Wer in der Automobilelektronik Software entwickelt, kennt eine Klasse von Fehlern, die besonders schwer auszutreiben und besonders gefährlich ist, wenn sie übersehen wird. Eine Studie der Cornell University zeigt: 60 bis 70 Prozent der Sicherheitslücken in eingebetteten Systemen gehen auf Speicherprobleme zurück — fehlerhafte Speicherzugriffe, Zugriffe auf bereits freigegebene Speicherbereiche, Zeiger, die ins Leere verweisen.

Was diese Fehler so tückisch macht, ist ihre Stille. Auf einem Desktop-Betriebssystem übersetzt ein Speicherschutzmechanismus eine Korruption häufig in einen sichtbaren Absturz — dokumentiert, reproduzierbar, behebbar. Auf einem Mikrocontroller im Fahrzeug fehlt dieser Schutzmechanismus oft. Ein korrumpierter Zustand kann unerkannt persistieren, mit Folgen, die von unzuverlässigen Sensordaten bis zu Fehlfunktionen in sicherheitskritischen Systemen reichen.

Rust adressiert dieses Problem auf Sprachebene. Das Ownership-Modell — Rusts Kernmechanismus zur Speicherverwaltung — legt für jeden Speicherbereich zur Compile-Zeit fest, wer darauf zugreifen darf und wann. Unzulässige Zugriffe werden nicht zur Laufzeit abgefangen, sondern bereits vom Compiler abgelehnt. Was gar nicht erst gebaut werden kann, kann auch nicht im Feld abstürzen.

Was sich 2026 verändert hat

Wer Rust im Automotive-Bereich bisher mit dem Argument abgewiegelt hat, Hersteller-Referenzen oder Serienreife fehlten, hat 2026 weniger Argumente. In jedem Volvo EX90 und Polestar 3, der heute vom Band läuft, ist ein Low-Power-Steuergerät verbaut, 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 in sicherheitsrelevanten Komponenten ein — darunter kryptografische Operationen und Firmware-Update-Prozesse. Für die nächste Generation von Fahrerassistenzsystemen plant Ampere Rust auf ASIL-B-Niveau.

ASIL steht für Automotive Safety Integrity Level, die Sicherheitseinstufung nach ISO 26262, der internationalen Norm für funktionale Sicherheit in Fahrzeugen. Die Stufen reichen von ASIL A (niedrigste Anforderungen) bis ASIL D (höchste Anforderungen, etwa für Lenk- oder Bremssysteme). Dass Rust auf Stufe B heute serientauglich eingesetzt werden kann, setzt qualifizierte Compiler und zertifizierte Bibliotheksanteile voraus — Infrastruktur, die seit der Embedded World 2026 weiter gewachsen ist.

Hinzu kommt ein regulatorischer Treiber, der bisher wenig Aufmerksamkeit in der technischen Debatte bekommt: UNECE R155, die UN-Regulierung zur Fahrzeugcybersicherheit, ist seit Juli 2024 für alle neuen EU-Fahrzeuge verbindlich. Hersteller und Zulieferer müssen seither nachweisen, dass ihre Fahrzeugsoftware auf Cyberangriffe überwacht, bewertet und bei Bedarf aktualisiert werden kann. Kryptografische Funktionen, OTA-Update-Handler (Over-the-Air, also drahtlose Softwareaktualisierungen) und alle Komponenten, die externe Daten verarbeiten, stehen dabei im Fokus, also genau die Bauteile, in denen Speicherfehler am gefährlichsten sind.

Drei Entscheidungen aus der Produktionspraxis

Als jemand, der Rust-basierte Software für Automotive-Steuergeräte — von Infineon-AURIX-TriCore-Chips bis zu Linux-basierten Hochleistungssystemen — entwickelt und ausliefert, treffe ich diese Abwägung regelmäßig. Die Einschätzung unten ist nicht die eines Werkzeuganbieters, sondern die eines Anwenders, der liefern muss.

Neue Middleware und Applikationsschicht. Die Softwareschicht zwischen Hardware-Abstraktion und eigentlicher Fahrzeugfunktion ist heute der Ort mit dem stärksten Komplexitätswachstum. Hier laufen parallele Prozesse, kommunizieren Komponenten asynchron, und Fehler in der Speicherverwaltung können Systemzustände global korrumpieren. Rusts Mechanismus zur Verhinderung paralleler Schreibzugriffe zur Compile-Zeit wirkt hier am direktesten und verhindert eine Fehlerkategorie, die in C-Codebasen zu den aufwendigsten Debugging-Fällen gehört.

Komponenten mit Angriffsfläche. Kryptografische Funktionen, Update-Handler und Parser für externe Nachrichten sind die Stellen, an denen Speicherfehler nicht nur 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 von Rust verzichtet.

Neue Plattformen ohne Legacy-Last. Wer heute ein neues Steuergerät von Grund auf entwickelt, hat keinen sachlichen Grund mehr, dabei auf C zu bestehen. In Greenfield-Projekten entfallen Migrationskosten vollständig, die Toolchain-Auswahl ist frei, und das Team kann von Beginn an mit den Sicherheitsgarantien der Sprache arbeiten, statt sie nachträglich durch externe Analysewerkzeuge herzustellen.

Wo C bleibt — und warum das keine Niederlage ist

Rust ersetzt C nicht, und wer das behauptet, kennt die Realität industrieller Embedded-Entwicklung mit 15-jährigen Produktlebenszyklen nicht. Die entscheidende Frage ist nicht, welche Sprache besser ist, sondern wo der Wechsel das Gesamtrisiko senkt und wo er es erhöht.

AUTOSAR Classic — die in der Automobilindustrie weit verbreitete, standardisierte Softwarearchitektur für Steuergeräte — ist in C implementiert und seit Jahrzehnten feld-validiert. Low-Level-Hardwaretreiber, die unter bestehenden Toolchains bereits auf ASIL D zertifiziert wurden, werden nicht neu geschrieben. Das Kosten-Nutzen-Verhältnis gibt das nicht her. Das C-Ökosystem für diese Schichten ist ausgereift, auditiert und in seiner Fehlercharakteristik gut verstanden.

Die pragmatische Antwort liefert die AUTOSAR-Laufzeitumgebung (RTE — Runtime Environment, die Schnittstelle zwischen Applikations- und Basissoftware): Führende Automotive-Softwareanbieter ermöglichen heute Rust-Komponenten auf dieser Schicht, sodass bestehender C-Code und neuer Rust-Code im selben Steuergeräteprojekt koexistieren. Gemischtsprachliche Architekturen sind kein Kompromiss, sie sind Engineering-Realität.

Auch innerhalb von Rust ist Sicherheitszertifizierung kein binärer Schalter. Ferrocene, der führende zertifizierte Rust-Compiler-Toolchain 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 einkalkulieren.

Die Frage hat sich verschoben

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

Was sich 2026 verändert: Der Ausredenkatalog wird kürzer. Fahrzeughersteller liefern Serienfahrzeuge aus. Regulierungsanforderungen konkretisieren sich. Zertifizierungsinfrastruktur wächst. Wer heute eine neue Steuergeräte-Plattform aufsetzt, muss begründen, warum er Rust nicht einsetzt und 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 Begründung.  (sg)

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

(ID:50835685)