Software Defined Vehicle Rust in AUTOSAR Classic: Von der Theorie zur praktischen Umsetzung im SDV-Ökosystem

In vielen SDV-Projekten wird AUTOSAR Classic als praxisgerechter Standards genutzt, mit C oder C++ als Programmiersprache. Jetzt kommen neue Architekturen zur Anwendung, und die Anforderungen an die Security steigen. Ist deshalb der Ersatz von C/ C++ durch Rust empfehlenswert? Und gibt es Alternativen, zum Beispiel hybride Modelle?

Der Trend ist eindeutig: Software bestimmt zunehmend die Fahrzeugfunktionen und entwickelt sich zu einem der wichtigsten Innovationstreiber. Wir leben im Zeitalter des softwaredefinierten Fahrzeugs (SDV), was tiefgreifende Veränderungen für den gesamten Prozess der Automobilentwicklung nach sich zieht und aus Sicht der Konsumenten ganz neue Funktionen ermöglicht.

Weil die Software – und mit ihr die (Cyber-)Security – eine immer größere Bedeutung hat, bewegt sich die Branche in Richtung zonaler Architekturen und bündelt Rechenleistung zunehmend auf High-Performance-Computing-Plattformen (HPCs).

Aber eine Zentralisierung allein beseitigt keine Schwachstellen. Und je mehr Fahrzeugfunktionen durch Software realisiert werden, desto wichtiger wird nicht nur die Architektur des Systems, sondern auch die Art und Weise, wie der Code geschrieben ist. Denn ein Softwarefehler kann Auswirkungen auf die physische Sicherheit haben.

Speichersicherheit wird Teil der Fahrzeugsicherheit

Damit werden C und C++ adressiert. Sie sind seit Jahrzehnten die Grundlage der Automobilsoftware. Eine zentrale Herausforderung bei ihrem Einsatz in kritischen Umgebungen liegt in den Risiken, die mit der manuellen Speicherverwaltung verbunden sind.

Hier kann es zu Null-Zeiger-Dereferenzierungen, Pufferüberläufen und Use-after-free-Fehlern sowie zu Datenkonflikten kommen, die zu Systemausfällen und Sicherheitslücken führen. In kritischen Systemen entstehen dadurch zusätzliche Risiken, die im Hinblick auf funktionale Sicherheit und Cybersicherheit berücksichtigt werden müssen. Dazu gehören auch die Anforderungen von ISO 26262 und ISO/SAE 21434.

Was Rust auf Code-Ebene verändert

Vor diesem Hintergrund wächst – nicht nur in der Automobilindustrie – das Interesse an Programmiersprachen mit integrierten Mechanismen zur Speichersicherheit. Eine solche Sprache ist Rust, und sie wird in der Automobilentwicklung verwendet, weil sie bei kritischen Systeme die Zuverlässigkeit erhöht, ohne dass der OEM Einbußen bei der Effizienz in Kauf nehmen muss.

Mehrere Eigenschaften von Rust sind für Automobilsoftware besonders relevant:

• Integrierte Speichersicherheit während der Kompilierung: Safe Rust verhindert diverse Schwachstellen wie Null-Zeiger-Dereferenzierungen, Pufferüberläufe und Use-after-free-Fehler, noch bevor die Software auf einem physischen Mikrocontroller ausgeführt wird.

• Leistung auf C/C++-Niveau ohne Garbage Collector: Durch Zero-Cost-Abstraktionen und eine Low-Level-Steuerung der Ressourcen kann Rust die Leistung bereitstellen, die für Echtzeitsysteme und ECUs mit begrenzten Rechenres-sourcen erforderlich ist.

• Eignung für tief eingebettete Systeme: Rust kann im #![no_std]-Modus ohne Standardbibliothek betrieben werden. Entwickler behalten dadurch auch in Embedded-Umgebungen die Kontrolle über die verfügbaren Ressourcen.

• Sicherere Parallelität: Safe Rust verhindert Datenkonflikte, wenn mehrere Threads oder Prozessorkerne gleichzeitig auf gemeinsam genutzte Ressourcen zugreifen. Dies ist insbesondere für Multicore-Steuergeräte und HPC-Plattformen relevant.

Damit stellt sich eine naheliegende Frage: Wenn Rust derart große Vorteile bietet, warum stellt die Automobilindustrie nicht vollständig darauf um?

Perspektive: Hybride Integration von Rust und C

Die Antwort liegt auf der Hand: Für OEMs und Tier-1-Zulieferer wäre es wirtschaftlich kaum praktikabel und mit erheblichen Risiken verbunden, bestehende Systeme aufzugeben und Automobilsoftware vollständig neu zu schreiben.

Über Jahrzehnte hinweg hat die Branche eine umfangreiche Basis aus bewährten C-Komponenten, Prozessen, Tools und Infrastrukturen rund um AUTOSAR Classic aufgebaut. Eine schrittweise bzw. hybride Integration ist daher ein realistischerer Weg.

In diesem Modell wird C nicht über den gesamten Software-Stack durch Rust ersetzt, sondern gezielt bei denjenigen kritischen Softwarekomponenten (SWCs) verwendet, bei denen die Rust-Sicherheitsmechanismen den größten Nutzen bieten.

Die entscheidende Frage lautet daher nicht, ob die Automobilindustrie von C auf Rust umsteigen sollte, sondern an welchen Stellen sich Rust integrieren lässt, ohne das bestehen-de AUTOSAR-Ökosystem und die bereits getätigten Investitionen aufzugeben.

So funktioniert die hybride Integration in AUTOSAR Classic

Grundlage dieses Ansatzes ist die deterministische Interaktion zwischen Rust-Code und der AUTOSAR Runtime Environment (RTE). Da die RTE standardisierte C-Schnittstellen für den Aufruf von Runnables und den Zugriff auf Ports generiert, kann Rust über ein Foreign Function Interface mit ihr interagieren.

An dieser Grenze enden jedoch die Garantien: Die generierten Bindings sind per Definition unsafe. Der Nutzen dieses Ansatzes hängt deshalb davon ab, diesen Bereich möglichst klein zu halten, ihn zu generieren statt manuell zu schreiben und ihn überprüfbar zu gestalten. In der Praxis bedeutet dies, sämtliche FFI-Deklarationen in einem Low-Level-Bindings-Crate zu isolieren und die Anwendungskomponente darauf mit #![for-bid(unsafe_code)] aufzubauen. So beschränkt sich der auditierbare Bereich mit unsicherem Code auf eine einzige Schicht und nicht auf die gesamte SWC.

In der Praxis erfordert dies die Kombination zweier Compiler-Toolchains in einem gemeinsamen Build-Prozess – wobei das eine projektspezifische Entscheidung ist und keine grundsätzliche Voraussetzung für eine hybride Rust/C-Integration.

Dual oder Single-Vendor Toolchain?

In einem weiter unten beschriebenen Proof of Concept (PoC) von Intellias kommen zwei separate Toolchains unterschiedlicher Anbieter zum Einsatz. Alternativ ist auch eine Single-Vendor-Toolchain möglich, die beide Sprachen kompiliert – beispielsweise das einheitliche Rust/C-Angebot von HighTec auf Basis eines gemeinsamen LLVM-Backends. Das kann den für die Qualifizierung relevanten Bereich an der Link-Grenze reduzieren. Für den hier beschriebenen PoC wurde der Dual-Toolchain-Ansatz gewählt, weil er zum bereits bestehenden TASKING-basierten Build des Projekts passte.

• Kompilierung mit HighTec Rust: Die Rust-Komponente wird mit dem HighTec-Rust-Compiler zu einer statischen Bibliothek kompiliert. Der Compiler ist für den Einsatz in der Entwicklung nach ISO 26262 bis ASIL D auf Infineon AURIX qualifiziert. Neben HighTec bietet auch Ferrocene einen nach ISO 26262 qualifizierten Rust-Compiler, hier war aber die Unterstützung des AURIX-Targets wichtig.

• Hybrides Linking mit TASKING: Die daraus resultierende statische Rust-Bibliothek wird an die TASKING-Toolchain übergeben. Sie kompiliert die verbleibenden AUTO-SAR-C-Module, darunter die Vector MICROSAR Classic Basic Software und die RTE, und übernimmt das finale Linking.

PoC: Einführung von Rust in die AUTOSAR Classic-Infrastruktur

Werden zwei Toolchains in einem gemeinsamen Image kombiniert, müssen die Rust-Objekte der von TASKING erwarteten TriCore-ABI entsprechen. Darüber hinaus muss die Argumentation zur Tool-Qualifizierung beide Compiler sowie den abschließenden Linking-Schritt berücksichtigen – und nicht allein die Rust-Seite.

In unserem Setup waren diese Voraussetzungen erfüllt. Dies muss jedoch projektspezifisch analysiert werden und lässt sich nicht verallgemeinern. Eine Single-Vendor-Toolchain, die C und Rust mit demselben Backend, Linker und derselben Build-Infrastruktur kompiliert, kann diese Analyse vermeiden. Dafür bindet sich das Projekt für beide Programmiersprachen an denselben Anbieter.

Dieser Ansatz ermöglicht es, Rust gezielt einzuführen, ohne die bestehende AUTOSAR-Classic-Infrastruktur aufzugeben. Für die praktische Einführung kann diese Fähigkeit zur Koexistenz mit C letztlich wichtiger sein als der vollständige Ersatz einer Programmiersprache durch eine andere.

Über die Speichersicherheit hinaus denken

Die Kompatibilität auf Build-Ebene bildet lediglich die Grundlage. Rust kann darüber hin-aus die Umsetzung bestimmter Engineering-Herausforderungen in AUTOSAR verbessern – etwa beim Multicore Computing und bei der Fehlerbehandlung.

Innovate Your Software – for a Smarter Future

Deutschlands Leitkongress der Embedded-Softwarebranche

Das Programm des ESE Kongress umfasst 96 Vorträge, 21 Seminare und 3 Keynotes. Seien Sie dabei, wenn sich die Embedded-Software-Community trifft, und nutzen Sie Diskussionen und Expertengespräche für einen ergiebigen Wissenstransfer und erfolgreiches Networken. Während der vier Kongresstage erwartet Sie zudem eine große Fachausstellung mit den führenden Firmen der Branche. Erfahren Sie alles über die neuesten Trends, Herausforderungen und Lösungen im Embedded Software Engineering, von KI, Safety und Security bis hin zu Management und Innovation.

Jetzt mehr erfahren und anmelden!

Bei Multicore-Mikrocontrollern wie Infineon AURIX können mehrere Tasks gleichzeitig auf den internen Zustand einer Komponente beziehungsweise auf ihren PerInstanceMemory (PIM) zugreifen. In C verwaltet der Entwickler diesen Prozess manuell über Rte_Enter_EA() und Rte_Exit_EA(). Wird ein solcher Aufruf vergessen oder fehlerhaft eingesetzt, kann ein Datenkonflikt entstehen, den der Compiler nicht erkennt.

Das vorgeschlagene PimGuard-Pattern verlagert diesen Schutz in das Typsystem von Rust: Der Zugriff auf PIM-Daten setzt voraus, dass zur Kompilierungszeit der entsprechen-de Lock gehalten wird.

Diese Garantie beschränkt sich allerdings auf die Rust-Seite. Die C-RTE und andere C-Komponenten können weiterhin Referenzen auf denselben PerInstanceMemory halten, und der Compiler hat keinen Einblick in diese Zugriffe. Das Pattern erhöht somit das Sicherheitsniveau innerhalb der Rust-SWC, ersetzt aber nicht die übliche Analyse der Parallelität an der Komponentengrenze.

Ein ähnliches Prinzip gilt für die Fehlerbehandlung. Rust verwendet den expliziten Typ Result zusammen mit Pattern Matching. Result macht ein Fehlerszenario im Typsystem ausdrücklich sichtbar; zugleich warnt der Compiler standardmäßig, wenn das Ergebnis ignoriert wird.

Grundsätzlich zeigt sich hier eine der zentralen Veränderungen, die Rust in die Automobilentwicklung bringen kann: Bestimmte Kontrollmechanismen, die traditionell von der Disziplin der Entwickler und einer anschließenden Verifikation abhängen, können auf die Ebene der Programmiersprache und des Compilers verlagert werden.

Vom Konzept auf die reale Hardware

Um diesen Ansatz in einer realen AUTOSAR-Classic-Umgebung zu testen, entwickelte und validierte ein Intellias-Team einen praktischen Proof of Concept (PoC).

Für die Migration von C auf Rust wählte das Team ein Ultraschallsensormodul für ein Parkassistenzsystem (Park Assist SWC), das hochfrequente Daten in Echtzeit verarbeitet. Die Software läuft auf einem physischen Infineon AURIX TriCore TC375-Mikrocontroller unter Verwendung von Vector MICROSAR Classic BSW und DaVinci-Tools.

Das Rust-basierte Modul wurde in das Intellias ECU Kit integriert, das über CAN mit der IntelliKit-Hardware- und -Softwareplattform verbunden ist. IntelliKit simuliert Fahrzeugparameter wie Geschwindigkeit, Batterieladezustand, Gangwechsel und regeneratives Bremsen. Die verarbeiteten Sensordaten werden anschließend über CAN an das Display des digitalen Cockpits übertragen.

In dieser Umgebung lässt sich die Rust-Komponente über die gesamte End-to-End-Kette hinweg testen – von AUTOSAR Classic und der ECU über CAN bis zum HMI.

Die Entwicklungs- und Validierungsprozesse des PoC wurden von externen Auditoren un-abhängig bewertet und erfüllen ASPICE CL2, ISO 26262 und ISO/SAE 21434. Die Konformität wird durch offizielle VDA- und TÜV-Auditberichte bestätigt.

Wo weiterhin Herausforderungen bestehen

• Panic-Verhalten: Im no_std-Modus liegt der Panic Handler in der Verantwortung des Entwicklers. Sein Verhalten muss unter dem Gesichtspunkt der Freedom from Interference definiert werden. Welche Auswirkungen ein panikartiger Abbruch eines Rust-Runnables auf die übrige ECU hat, ist eine Frage des Sicherheitskonzepts und nicht der Programmiersprache.

• Coding-Standards: Für Rust existiert bislang kein Äquivalent zu MISRA. Im Safety-Critical Rust Consortium wird daran gearbeitet. Projekte müssen deshalb derzeit eigene Subsets definieren und deren Auswahl begründen.

• Debugging und Tooling: Das schrittweise Debugging über die C/Rust-Grenze hin-weg sowie Symbol-Handling und Trace-Analysen mit bestehenden Automotive-Debuggern sind möglich, aber noch deutlich weniger ausgereift als in einer reinen C-Umgebung. Diese praktischen Aufwände werden von Teams häufig unterschätzt.

Wie geht es weiter?

Die Erfahrungen mit Rust in AUTOSAR Classic zeigen, dass der Übergang nicht zwangsläufig eine Entscheidung zwischen dem bestehenden und einem neuen Software-Stack erfordert. Ein hybrider Ansatz ermöglicht es, bewährte Komponenten und bestehende Infrastrukturen beizubehalten und gleichzeitig schrittweise speichersichere Technologien dort einzuführen, wo sie den größten Nutzen bieten.

Auch in der Arbeit von AUTOSAR spielt Rust zunehmend eine Rolle. In den Release-Materialien zu R25-11 wird Rust für die Classic Platform unter „Rust in CP Outlook“ als Bereich für die weitere Entwicklung aufgeführt; die entsprechenden Ansätze werden weiterentwickelt. Für die Adaptive Platform existiert bereits seit R23-11 ein Rust Framework. Die Classic Platform ist der spätere und anspruchsvollere Anwendungsfall – insbesondere aufgrund der beschriebenen Anforderungen durch die generierte RTE und die Toolchains.

Rust macht Jahrzehnte der Entwicklung mit C und AUTOSAR Classic nicht überflüssig – und das sollte auch nicht das Ziel sein. Das Potenzial liegt vielmehr darin, bestimmte Fehlerklassen bereits zur Kompilierungszeit unmöglich zu machen, anstatt sich ausschließlich darauf zu verlassen, sie später zu erkennen und zu beheben.

Für die Automobilindustrie deutet dies auf einen schrittweisen Wandel hin. Der Ansatz, in dem Sicherheit vor allem durch Prozesse und Verifikation gewährleistet wird, wird ersetzt durch ein Modell, in dem bestimmte Sicherheitsgarantien direkt in der Programmiersprache und den Entwicklungswerkzeugen verankert sind. Das geschieht nicht vollständig und nicht automatisch. Aber für Komponenten, bei denen genau diese Fehlerklassen eine wesentliche Rolle spielen, ist ein schrittweiser Wandel sinnvoll – und es lohnt sich, damit bereits heute zu beginnen.  (sg)

* Abdelrahman Mabrouk ist Automotive Architect und Functional Safety Engineer bei Intellias

(ID:50991800)