The automotive industry is rapidly evolving toward software-defined vehicles (SDVs), where software drives innovation and shapes increasingly complex vehicle functions. This transformation is accelerating the adoption of zonal architectures and the shift toward centralized computing powered by high-performance computing (HPC) platforms.
However, advancing vehicle architectures does not automatically make automotive software safer. As more vehicle functions depend on software, vulnerabilities within individual components become increasingly critical. Beyond modernizing system architectures, OEMs and Tier 1 suppliers must rethink their approach to software development, exploring AUTOSAR C++ Rust migration practices to improve code reliability, strengthen memory safety, and prevent defects that could compromise vehicle safety.
Memory safety as a critical requirement for automotive software
C and C++ have powered automotive software development for decades, but their reliance on manual memory management introduces risks, particularly in safety-critical systems. Common issues such as null-pointer dereferences, buffer overflows, use-after-free errors, and data races can compromise software reliability, create cybersecurity vulnerabilities, and potentially affect vehicle safety.
Addressing these risks is an essential part of automotive functional safety and cybersecurity engineering, governed by standards such as ISO 26262 and ISO/SAE 21434. At the same time, the shift toward memory-safe programming languages is gaining momentum across industries. Initiatives such as the U.S. Office of the National Cyber Director’s Back to the Building Blocks report and DARPA’s TRACTOR program highlight the growing importance of adopting languages like Rust.
For automotive developers, AUTOSAR Rust integration represents more than adopting another programming language. Its key advantage is the ability to enforce certain memory safety guarantees at compile time, reducing reliance on detecting and correcting these classes of defects during subsequent automotive software testing and verification.
How Rust improves code safety and performance in automotive systems
For safety-critical automotive applications, Rust combines strong memory protection with the efficiency and hardware-level control required for embedded development. While established standards such as AUTOSAR C++ coding guidelines help developers minimize software risks through coding rules and verification practices, Rust takes a complementary approach by enforcing certain memory safety constraints directly during compilation.
Its key advantages for automotive software include:
- Compile-time memory protection. Rust’s ownership and borrowing mechanisms prevent common memory-related defects in safe code, including use-after-free errors and unsafe memory access, helping identify issues before deployment on physical ECUs.
- Performance comparable to C/C++. Without requiring a garbage collector, Rust supports predictable resource management and zero-cost abstractions, making it suitable for performance-sensitive automotive applications and resource-constrained microcontrollers.
- Support for embedded environments. With #![no_std], developers can build Rust applications without relying on the standard library, retaining low-level control over memory and hardware resources.
- Concurrency safety. Rust’s type system prevents data races in safe code, providing additional protection when multiple threads or processor cores operate on shared resources in multicore ECUs and HPC platforms.
These capabilities make Rust an attractive option for mobility software development. However, replacing established AUTOSAR C/C++ implementations across the entire vehicle software stack is neither straightforward nor always necessary. The more practical question is how to integrate Rust into existing AUTOSAR architectures while preserving proven components and development infrastructure.
Hybrid integration: Bringing Rust into existing AUTOSAR Classic systems
A complete transition from C to Rust is neither practical nor necessary for most automotive manufacturers and Tier 1 suppliers. Replacing established software architectures would require substantial investment, extensive revalidation, and introduce additional development risks.
AUTOSAR Classic is supported by decades of engineering experience, mature C-based software components, established toolchains, and proven development processes. Rather than replacing this foundation, a hybrid approach enables automotive companies to introduce Rust gradually, targeting specific software components (SWCs) where improved memory safety can deliver the greatest value.
This selective integration allows Rust and C to coexist within the same AUTOSAR environment, preserving existing infrastructure while bringing compiler-enforced safety mechanisms to critical application functions. The focus shifts from replacing legacy code to identifying where Rust can strengthen software reliability with minimal disruption to established automotive development workflows.
Integrating Rust with AUTOSAR Classic: RTE interfaces and toolchain compatibility
Introducing Rust into AUTOSAR Classic requires establishing reliable communication between Rust-based software components and the existing AUTOSAR Runtime Environment (RTE). Since the RTE provides generated C interfaces for executing runnables and accessing software component ports, Rust applications can connect to these interfaces through a Foreign Function Interface (FFI).
However, Rust’s compile-time safety guarantees do not automatically extend across the C/Rust boundary. FFI declarations require unsafe code, making it essential to minimize and isolate this part of the implementation. A practical solution is to place generated FFI declarations in a dedicated low-level bindings crate while keeping the application logic in a separate layer configured with #![forbid(unsafe_code)]. This confines the auditable unsafe code to a clearly defined integration layer rather than exposing the entire software component (SWC) to additional risks.
Choosing a toolchain strategy for hybrid Rust/C development
Integrating Rust and C components into a single ECU application also requires a compatible compilation and linking process. Depending on the existing development environment, engineering teams can use either a unified toolchain supporting both languages or separate compiler toolchains.
For a practical AUTOSAR Rust integration proof of concept (PoC), a dual-toolchain configuration was selected to maintain compatibility with an existing TASKING-based development environment. Although HighTec offers a unified Rust/C solution built on a shared LLVM backend, combining separate toolchains provided a suitable approach for this implementation.
The build process involved two main stages:
- Rust compilation with HighTec. The Rust software component was compiled into a static library using the HighTec Rust compiler, which provides qualification support for ISO 26262 development up to ASIL D on supported Infineon AURIX targets. Other qualified Rust compiler solutions, such as Ferrocene, are also available, but compatibility with the AURIX platform was a key selection criterion.
- C compilation and final linking with TASKING. The generated Rust static library was integrated into the TASKING build process alongside the existing AUTOSAR C modules, including Vector MICROSAR Classic Basic Software (BSW) and the RTE. TASKING then performed the final linking to produce the ECU executable.
Ensuring binary compatibility and tool qualification
Using separate compiler toolchains introduces additional integration and qualification requirements. In particular, Rust-generated objects must comply with the TriCore Application Binary Interface (ABI) expected by TASKING to ensure correct interaction between compiled components.
The tool qualification assessment must also account for both compilers and the final linking stage, rather than evaluating the Rust compiler independently. These compatibility and qualification requirements were addressed in the PoC, but they must be verified for each specific project configuration.
A unified C/Rust toolchain can simplify certain aspects of this process by sharing the compiler backend, linker, and build infrastructure, although it also increases dependence on a single technology vendor.
Ultimately, the choice of toolchain architecture depends on existing ECU development infrastructure, target hardware, and functional safety requirements. Both approaches demonstrate that Rust can be incorporated into established AUTOSAR Classic systems without replacing their C-based foundations, enabling gradual software modernization while preserving existing engineering investments.
Rust beyond memory safety
Beyond build compatibility and memory protection, Rust offers advantages for managing concurrent operations and error handling in AUTOSAR applications.
In multicore microcontrollers such as Infineon AURIX, multiple tasks may access shared component data stored in PerInstanceMemory (PIM). In C, developers typically control this access using Rte_Enter_EA() and Rte_Exit_EA(), where missing or incorrect calls can introduce data races. Rust’s proposed PimGuard pattern strengthens this mechanism by requiring the appropriate lock before PIM data can be accessed, enforcing this constraint through the type system.
However, this protection applies only within the Rust component. Since the compiler cannot verify access from the C-based RTE or other C modules, concurrency analysis across component boundaries remains necessary.
Rust also improves error handling through its Result type and pattern matching, making potential failures explicit and warning developers when results are ignored. Together, these capabilities move certain software safety checks from manual coding practices and subsequent verification into compile-time enforcement.
From PoC to real-world ECU validation
To demonstrate Rust integration in a production-relevant AUTOSAR Classic environment, Intellias engineers developed and validated a proof of concept (PoC) using physical automotive hardware.
The project focused on migrating an ultrasonic sensor module within a parking assistance software component (Park Assist SWC) from C to Rust. Designed to process high-frequency sensor data in real time, the component was deployed on an Infineon AURIX TriCore TC375 microcontroller, running Vector MICROSAR Classic Basic Software (BSW) and configured using Vector DaVinci tools.
The Rust-based application was integrated into the Intellias ECU Kit, connected via CAN to the IntelliKit hardware and software platform. IntelliKit simulates vehicle parameters, including speed, battery state of charge, gear changes, and regenerative braking, while processed sensor data is transmitted to the digital cockpit display.
This setup enables end-to-end validation across the complete integration chain, from the AUTOSAR Classic software stack and ECU hardware to CAN communication and the human-machine interface (HMI).
The PoC development and validation processes underwent independent external assessment against ASPICE Capability Level 2, ISO 26262, and ISO/SAE 21434, with supporting VDA and TÜV audit reports.
Remaining challenges of Rust adoption in AUTOSAR Classic
Despite its advantages, integrating Rust into existing AUTOSAR Classic environments introduces engineering challenges that require careful consideration:
- Runtime failure handling. In no_std environments, developers must define how the system responds to a Rust panic. This includes assessing its impact on other ECU functions and ensuring freedom from interference in accordance with the system’s safety concept.
- Coding standards. Rust-specific safety-critical coding practices are still evolving, with ongoing work by the Safety-Critical Rust Consortium. Unlike established MISRA and AUTOSAR C++ coding guidelines, Rust projects may require individually defined coding restrictions and supporting justification.
- Debugging and tool support. Debugging across C/Rust interfaces, managing symbols, and analyzing execution traces remain less mature than established C-based automotive workflows, potentially increasing integration and validation effort.
The road ahead for Rust in automotive software
Rust adoption in AUTOSAR Classic is likely to follow an incremental path, enabling OEMs and Tier 1 suppliers to strengthen selected software components while maintaining existing C-based architectures, validated tools, and development processes.
The AUTOSAR ecosystem is also evolving to accommodate Rust. While the Adaptive Platform has included a Rust framework since R23-11, the R25-11 release materials identify Rust integration for the Classic Platform as an area for further development. Generated RTE interfaces and toolchain compatibility remain important considerations for its broader adoption.
Rather than replacing established automotive programming languages, Rust introduces an opportunity to prevent certain classes of software defects during compilation, complementing traditional safety engineering, testing, and verification practices. For automotive developers, the next step is to identify where these capabilities provide measurable benefits and introduce them through controlled, component-level migration.
The result is a more practical path toward memory-safe automotive software, combining the reliability of existing AUTOSAR infrastructure with additional safety guarantees built directly into the programming language and development toolchain.
