Software-Defined Vehicle Rust in AUTOSAR Classic: From Theory to Practical Implementation in the SDV Ecosystem

In many SDV projects, AUTOSAR Classic is used as a practical standard, with C or C++ as the programming language. Now, new architectures are being adopted, and security requirements are increasing. Does this mean it is advisable to replace C/C++ with Rust? And are there alternatives, such as hybrid models?

The trend is clear: Software is increasingly shaping vehicle functions and is becoming one of the most important drivers of innovation. We are living in the age of the software-defined vehicle (SDV), which is bringing about profound changes to the entire automotive development process and, from the consumers’ perspective, enabling entirely new features.

Because software—and with it, (cyber) security—is becoming increasingly important, the industry is moving toward zonal architectures and is increasingly consolidating computing power on high-performance computing (HPC) platforms.

But centralization alone does not eliminate vulnerabilities. And the more vehicle functions are implemented through software, the more important it becomes not only to consider the system’s architecture but also the way the code is written. After all, a software error can have implications for physical safety.

Storage Security Is Becoming Part of Vehicle Safety

This addresses C and C++, which have been the foundation of automotive software for decades. A key challenge in their use in critical environments lies in the risks associated with manual memory management.

This can lead to null pointer dereferences, buffer overflows, and use-after-free errors, as well as data conflicts, which can result in system failures and security vulnerabilities. In critical systems, this creates additional risks that must be taken into account with regard to functional safety and cybersecurity. This also includes the requirements of ISO 26262 and ISO/SAE 21434.

What Rust Changes at the Code Level

Against this backdrop, interest is growing—not only in the automotive industry—in programming languages with built-in memory safety mechanisms. One such language is Rust, and it is used in automotive development because it increases reliability in critical systems without requiring the OEM to sacrifice efficiency.

Several features of Rust are particularly relevant to automotive software:

• Integrated memory safety during compilation: Safe Rust prevents various vulnerabilities—such as null pointer dereferences, buffer overflows, and use-after-free errors—even before the software runs on a physical microcontroller.
• C/C++-level performance without a garbage collector: Through zero-cost abstractions and low-level resource control, Rust can deliver the performance required for real-time systems and ECUs with limited computational resources.
• Suitability for deeply embedded systems: Rust can run in #![no_std] mode without the standard library. This allows developers to maintain control over available resources even in embedded environments.
• Safer Concurrency:Safe Rust prevents data conflicts when multiple threads or processor cores access shared resources simultaneously. This is particularly relevant for multicore control units and HPC platforms.

This raises an obvious question: If Rust offers such significant advantages, why hasn't the automotive industry switched over to it entirely?

Perspective: Hybrid Integration of Rust and C

The answer is obvious: For OEMs and Tier 1 suppliers, it would be economically impractical and involve significant risks to abandon existing systems and completely rewrite automotive software from scratch.

Over the decades, the industry has built up an extensive foundation of proven C components, processes, tools, and infrastructure related to AUTOSAR Classic. A phased or hybrid integration is therefore a more realistic approach.

In this model, C is not replaced by Rust across the entire software stack; rather, it is used specifically for those critical software components (SWCs) where Rust's security mechanisms offer the greatest benefit.

The key question, therefore, is not whether the automotive industry should switch from C to Rust, but rather where Rust can be integrated without abandoning the existing AUTOSAR ecosystem and the investments already made.

How Hybrid Integration Works in AUTOSAR Classic

This approach is based on the deterministic interaction between Rust code and the AUTOSAR Runtime Environment (RTE). Since the RTE generates standardized C interfaces for calling runnables and accessing ports, Rust can interact with it via a foreign function interface.

However, this is where the guarantees end: The generated bindings are, by definition, unsafe. The value of this approach therefore depends on keeping this area as small as possible, generating it rather than writing it manually, and making it verifiable. In practice, this means isolating all FFI declarations in a low-level bindings crate and building the application component on top of it using #![for-bid(unsafe_code)]. This way, the auditable area containing unsafe code is limited to a single layer rather than the entire SWC.

In practice, this requires combining two compiler toolchains into a single build process—though this is a project-specific decision and not a fundamental prerequisite for hybrid Rust/C integration.

Dual or Single-Vendor Toolchain?

In a proof of concept (PoC) by Intellias described below, two separate toolchains from different vendors are used. Alternatively, a single-vendor toolchain that compiles both languages is also possible—for example, HighTec’s unified Rust/C offering based on a shared LLVM backend. This can reduce the area at the link boundary that is relevant for qualification. For the PoC described here, the dual-toolchain approach was chosen because it aligned with the project’s existing TASKING-based build.

• Compiling with HighTec Rust: The Rust component is compiled into a static library using the HighTec Rust compiler. The compiler is qualified for use in development according to ISO 26262 up to ASIL D on Infineon AURIX. In addition to HighTec, Ferrocene also offers an ISO 26262-qualified Rust compiler; however, support for the AURIX target was a key factor here.
• Hybrid linking with TASKING: The resulting static Rust library is passed to the TASKING toolchain. It compiles the remaining AUTO-SAR C modules—including the Vector MICROSAR Classic Basic Software and the RTE—and performs the final linking.

PoC: Introduction of Rust into the AUTOSAR Classic Infrastructure

If two toolchains are combined into a single image, the Rust objects must conform to the TriCore ABI expected by TASKING. Furthermore, the tool qualification process must take into account both compilers as well as the final linking step—not just the Rust side.

In our setup, these requirements were met. However, this must be analyzed on a project-by-project basis and cannot be generalized. A single-vendor toolchain that compiles C and Rust using the same backend, linker, and build infrastructure can eliminate the need for this analysis. To achieve this, the project must rely on the same vendor for both programming languages.

This approach makes it possible to introduce Rust in a targeted manner without abandoning the existing AUTOSAR Classic infrastructure. For practical implementation, this ability to coexist with C may ultimately be more important than completely replacing one programming language with another.

Thinking Beyond Storage Security

Compatibility at the build level is merely the foundation. Rust can also improve the implementation of certain engineering challenges in AUTOSAR—such as multicore computing and error handling.

With multicore microcontrollers such as Infineon AURIX, multiple tasks can simultaneously access a component’s internal state or its PerInstanceMemory (PIM). In C, the developer manages this process manually using Rte_Enter_EA() and Rte_Exit_EA(). If such a call is omitted or used incorrectly, a data conflict may occur that the compiler cannot detect.

The proposed PimGuard pattern shifts this protection into Rust's type system: Access to PIM data requires that the corresponding lock be held at compile time.

However, this guarantee is limited to the Rust side. The C-RTE and other C components may still hold references to the same `PerInstanceMemory`, and the compiler has no insight into these accesses. The pattern thus increases the level of safety within the Rust SWC, but does not replace the usual analysis of parallelism at the component boundary.

A similar principle applies to error handling. Rust uses the explicit `Result` type in conjunction with pattern matching. `Result` explicitly makes an error scenario visible in the type system; at the same time, the compiler issues a warning by default if the result is ignored.

Essentially, this illustrates one of the key changes that Rust can bring to automotive development: Certain control mechanisms, which traditionally depend on the developers’ discipline and subsequent verification, can be shifted to the level of the programming language and the compiler.

From Concept to Actual Hardware

To test this approach in a real AUTOSAR Classic environment, an Intellias team developed and validated a practical proof of concept (PoC).

For the migration from C to Rust, the team selected an ultrasonic sensor module for a parking assistance system (Park Assist SWC) that processes high-frequency data in real time. The software runs on a physical Infineon AURIX TriCore TC375 microcontroller using Vector MICROSAR Classic BSW and DaVinci tools.

The Rust-based module was integrated into the Intellias ECU Kit, which is connected via CAN to the IntelliKit hardware and software platform. IntelliKit simulates vehicle parameters such as speed, battery charge level, gear shifts, and regenerative braking. The processed sensor data is then transmitted via CAN to the digital cockpit display.

In this environment, the Rust component can be tested across the entire end-to-end chain—from AUTOSAR Classic and the ECU, through CAN, to the HMI.

The PoC's development and validation processes were independently assessed by external auditors and comply with ASPICE CL2, ISO 26262, and ISO/SAE 21434. Compliance is confirmed by official VDA and TÜV audit reports.

Where Challenges Remain

• Panic Behavior: In no_std mode, the panic handler is the developer’s responsibility. Its behavior must be defined with regard to “Freedom from Interference.” The impact of a panic-induced termination of a Rust runnable on the rest of the ECU is a matter of the safety concept, not the programming language.
• Coding Standards: There is currently no equivalent to MISRA for Rust. The Safety-Critical Rust Consortium is working on this. Projects must therefore currently define their own subsets and justify their selection.
• Debugging and Tooling: Step-by-step debugging across the C/Rust boundary, as well as symbol handling and trace analysis using existing automotive debuggers, are possible but still significantly less mature than in a pure C environment. Teams often underestimate these practical challenges.

What Happens Next?

Experience with Rust in AUTOSAR Classic shows that the transition does not necessarily require a choice between the existing software stack and a new one. A hybrid approach makes it possible to retain proven components and existing infrastructure while gradually introducing memory-safe technologies where they offer the greatest benefit.

Rust is also playing an increasingly important role in AUTOSAR’s work. In the R25-11 release materials, Rust is listed for the Classic Platform under “Rust in CP Outlook” as an area for further development; the corresponding approaches are being further refined. A Rust framework has been available for the Adaptive Platform since R23-11. The Classic Platform represents the later and more challenging use case—particularly due to the requirements described by the generated RTE and the toolchains.

Rust does not render decades of development with C and AUTOSAR Classic obsolete—nor should that be the goal. Rather, its potential lies in preventing certain classes of errors at compile time, rather than relying solely on detecting and fixing them later.

For the automotive industry, this points to a gradual shift. The approach in which safety is primarily ensured through processes and verification is being replaced by a model in which certain safety guarantees are directly embedded in the programming language and development tools. This is not happening completely or automatically. However, for components where precisely these classes of errors play a significant role, a gradual transition makes sense—and it’s worth starting today. 

*Abdelrahman Mabrouk is an Automotive Architect and Functional Safety Engineer at Intellias

The 3D Tech Auto Experts Can’t Afford to Ignore!

3D Digitilization in Automotive Sector