ISO 26262 vs. Rust Gap Analysis
ISO 26262 is a standard comprising 12 parts, covering Vocabulary, Management, System-, Hardware-, and Software-Level, as well as supporting processes and general guidelines. Compliance with the standard can be claimed by fulfilling each single requirement, unless it has been tailored according to part 2 or a sound technical rationale is given.
The following analysis evaluates specifically the readiness of Rust to meet the requirements of Part 6: "Product development at the software level.", following the software reference phase model (V-Model) and corresponding clauses. The structure is based around the normative tables and an additional section on "general considerations" for each clause. These considerations are derived from practical experience and address indirect requirements or ecosystem constraints - while not explicitly mentioned in the standard, they are critical for successful implementation.
Scope and limitations: This analysis provides a general overview. The actual readiness for a specific project depends on the target ASIL, the organizational context, and the specific system architecture, etc. Requirements at ASIL A/B may have fewer gaps than those at ASIL C/D. This assessment should be used as an orientation - individual evaluation for your application context is necessary.
Last updated: March 2026
Contributions and corrections are welcome via pull request.
Note: Where specific tools are referenced below, a comprehensive curated list is maintained by the Tooling subcommittee.
🟢 6-5 General topics for the product development at the software level​
Table 1 — Topics to be covered by modelling and coding guidelines
| ID | Method | Solution: Rust Native or Tool | Readiness |
|---|---|---|---|
| 1a | Enforcement of low complexity | (Process) statically enforceable by clippy tool e.g. cyclomatic_complexity | 🟢 |
| 1b | Use of language subsets | (Language) coding guidelines (are in progress by Subcommittee), need to be developed individually | 🟡 |
| 1c | Enforcement of strong typing | (Language) inherent feature of Rust | 🟢 |
| 1d | Use of defensive implementation techniques | (Architecture) encouraged by use of Types Option/Result,assert!/panic! macros, exhaustive match, mandatory bounds checking on array/slice access, and explicit per-operation overflow handling available via checked_/saturating_ methods (can also be allowed implicitly by configuring) | 🟢 |
| 1e | Use of well-trusted design principles | (Architecture) encouraged by Rust inherent features like encapsulation and RAII by default | 🟢 |
| 1f | Use of unambiguous graphical representation | (Process) UML can be used - no specific graphical representation for Rust available | ⚪ |
| 1g | Use of style guides | (Process) statically enforceable by clippy tool | 🟢 |
| 1h | Use of naming conventions | (Process) statically enforceable by clippy tool | 🟢 |
| 1i | Concurrency aspects | (Architecture) partially concurrent aspects can be enforced by Rust such as borrow checker on shared resources. Typical constructs such as Mutex, RefCells to provide guarantees also exist - but e.g. priority inversion, deadlocks etc. are still possible and need to be managed | 🟢 |
General considerations:
- Rust achieves requirement 5.4.2 The criteria that shall be considered when selecting a design, modelling or programming language are: 🟢
- an unambiguous and comprehensible definition, by the Ferrocene Language Specification; 🟢
- suitability for specifying and managing safety requirements according to ISO 26262-8:2018 if modelling is used for requirements engineering and management; ⚪ (no model-based Rust code generation available)
- support the achievement of modularity, abstraction and encapsulation; and 🟢
- support the use of structured constructs. 🟢
- Coding Guidelines 🟡
- Safety-Critical Rust Coding Guidelines are in active work
- need to be complemented by individual/organizational-specific guidelines
- Tool "clippy" can be used to enforce guidelines (but is not qualified)
- IDEs 🟢
- Multiple Supported IDEs with all common features: e.g. VSCode, JETBRAINS RustRover, ...
- Debugging and tracing support 🟡
- Multiple tools available for debugging on target for ARM, RISC V, AURIX, (e.g. probe-rs, knurling-rs, gdb/OpenOCD)
- Tracing Lauterbach TRACE32
- Build system & CI/CD 🟢
- cargo inherently allows to configure different runners
- Tests are encouraged to be written alongside the code
- Well supported by commonly available build systems (e.g. Jenkins, etc.)
- Qualified Compiler 🟢
- Multiple available for up to ASIL D for multiple targets (e.g. Hightec, Ferrocene)
🟢 6-6 Specification of software safety requirements​
This clause is not impacted by the programming language choice much.
General considerations:
- Requirements traceability tooling 🟢
- Multiple tools support convenient requirement traceability to implementation (e.g. sphinx-needs, mantra)
- These integrate well with Rust/Cargo project and allow for automatic report generation
🟡 6-7 Software architectural design​
Table 2 on software architecture notations is omitted, because it has no direct impact by/for using Rust.
Table 3 — Principles for software architectural design
| ID | Principle | Solution: Rust Native or Tool | Readiness |
|---|---|---|---|
| 1a | Appropriate hierarchical structure of the software components | (Architecture) encouraged by Rust's module system (mod hierarchy) and visibility rules (pub, pub(crate)) | 🟢 |
| 1b | Restricted size and complexity of software components | (Architecture) neutral Rust does not impose this logical design constraint | ⚪ |
| 1c | Restricted size of interfaces | (Architecture) neutral Rust does not impose this logical design constraint | ⚪ |
| 1d | Strong cohesion within each software component | (Architecture) neutral Rust does not impose this logical design constraint | ⚪ |
| 1e | Loose coupling between software components | (Architecture) neutral Rust does not impose this logical design constraint | ⚪ |
| 1f | Appropriate scheduling properties | (Architecture) partially available - multiple unqualified Rust-native concurrency frameworks exist: RTIC (static priority scheduling, formally analyzable), Embassy (cooperative async), Hubris (microkernel with MPU isolation). Integration with foreign RTOS (e.g. VxWorks, QNX, Zephyr) possible via C ABI, though the scheduler itself is outside of Rust's safety guarantees. Rust's no_std without allocator guarantees absence of hidden dynamic allocation, improving WCET analyzability. | 🟡 |
| 1g | Restricted use of interrupts | (Architecture) neutral Rust does not impose this constraint | ⚪ |
| 1h | Appropriate spatial isolation of the software components | (Architecture + Compiler) Logical isolation: Rust natively enforces strict visibility rules and memory safety but physical isolation requires hardware MPU/MMU that requires Rust drivers | 🟡 |
| 1i | Appropriate management of shared resources | (Architecture) available by Rust's Send/Sync trait system statically prevents data races. Safe concurrency primitives (Mutex, RwLock) enforce access discipline at compile time. Logical race conditions and deadlocks remain architectural concerns. See also Table 1 item 1i for coding-level concurrency. | 🟢 |
Table 4 — Methods for the verification of the software architectural design
| ID | Principle | Solution: Rust Native or Tool | Readiness |
|---|---|---|---|
| 1a | Walk-through of the design | (Process) improved by Rust's explicit ownership annotations, error handling (Result/Option), and type signatures make control flow and data dependencies easier visible | 🟢 |
| 1b | Inspection of the design | (Process) improved see entry 1a. | 🟢 |
| 1c | Simulation of dynamic behavior of the design | (Tools) not available no Rust-specific architectural simulation tool exists. Standard approaches (software-in-the-loop testing, hardware emulation via Renode) work | 🟡 |
| 1d | Prototype generation | (Process) neutral no specific gap | ⚪ |
| 1e | Formal verification | (Tools) partially available unqualified tools exist, e.g. creusot or kani | 🟡 |
| 1f | Control flow analysis | (Tools) partially available at MIR-level by e.g. llvm-flow | 🟡 |
| 1g | Data flow analysis | (Tools) not available | 🔴 |
| 1h | Scheduling analysis | (Tools) partially WCET analysis tool available, target support unclear | 🟡 |
General considerations:
- Model based code generation tools 🔴
- No Rust code generation from modeling tools (e.g. Simulink/TargetLink) exists
- Software partitioning and freedom from interference 🟡
- Logical isolation is encouraged at the software level through Rust's ownership and module system
- Temporal and spatial freedom from interference still requires hardware mechanisms (MPU/MMU) or a hypervisor
- Upper estimation of required resources (execution time, storage, communication resources) 🟡
- Timing: analysis tools (e.g. AbsInt aiT) supported
- Stack usage: Analyzable via binary inspection (e.g. stack-sizes crate, AbsInt StackAnalyzer). Deterministic in no_std without allocator.
- Heap: avoidable in no_std Rust without an allocator, making memory usage statically bounded.
- C/C++ Interoperability 🟡
- Legacy Code, vendor SDKs or specific drivers might require C-code
- the boundary (e.g. bindgen) is generally unqualified and needs to be verified individually
🟡 6-8 Software unit design and implementation​
Table 5 on unit design notations is omitted, because it has no direct impact by/for using Rust.
Table 6 — Design principles for software unit design and implementation
| ID | Principle | Solution: Rust Native or Tool | Readiness |
|---|---|---|---|
| 1a | One entry and one exit point in subprograms and functions | (Architecture) possible, not encouraged Rust idiomatically uses early returns and the ? operator for error propagation, resulting in multiple exit points. This is widely considered safer than deeply nested single-return patterns, as each exit point has explicit type-checked error handling. An assessor may accept this with justification; if not, a custom clippy lint or coding guideline can restrict it. | 🟢 |
| 1b | No dynamic objects or variables, or else online test during their creation | (Architecture) encouraged by no_std Rust without a global allocator statically guarantees the absence of heap allocation at compile time. For cases requiring dynamic-like containers, the heapless crate provides fixed-capacity collections. With a global allocator enabled, a fallible allocation API exists (try_reserve), but online testing of allocation failure remains the developer's responsibility (and would require qualification). | 🟢 |
| 1c | Initialization of variables | (Language) inherent feature, safe Rust doesn't allow reading uninitialized variables | 🟢 |
| 1d | No multiple use of variable names | (Language) inherent Rust encourages variables shadowing, but clippy can disallow it (clippy::shadow_reuse) | 🟢 |
| 1e | Avoid global variables or else justify their usage | (Language) inherent feature of safe Rust, mutable global variables are considered unsafe | 🟢 |
| 1f | Restricted use of pointers | (Language) inherent feature of safe Rust | 🟢 |
| 1g | No implicit type conversions | (Language) inherent enforced in safe Rust | 🟢 |
| 1h | No hidden data flow or control flow | largely inherent as Rust prevents most sources of hidden data flow: compared to C++ exceptions Rust's ? operator is explicit. No global mutable state without explicit synchronization, no implicit type conversions, no pointer aliasing. Control flow is explicit. The usage of macros can generate hidden control flow. | 🟡 |
| 1i | No unconditional jumps | (Language) inherent feature of Rust: no goto support | 🟢 |
| 1j | No recursions | (Architecture) statically enforceable Rust allows recursions. Rule should be enforced by static checks and no clippy lint exists so far | 🟡 |
General considerations:
- FuSa Library support for qualified microcontroller 🟡
- e.g. ARM Self Test Library support to provide diagnostic coverage for microcontroller exists only in C
- are generally provided as binary blobs or C-files and require FFI (which might tamper qualification)
- Hardware Abstraction Layer (HAL) availability 🟡/🔴
- ARM Cortex-M: Mature ecosystem — embedded-hal trait abstractions, PACs generated via svd2rust, HALs for major MCU families (STM32, nRF, ESP32, RP2040). 🟢
- ARM Cortex-R: Minimal ecosystem. No mature HALs or PACs. Limited community activity. 🔴
- Infineon AURIX (TC3xx/TC4xx): Hightec Rust toolchain available, but HAL maturity unclear. 🔴
- RISC-V: Growing ecosystem, esp-hal for ESP32-C3/C6 relatively mature, but broader RISC-V automotive targets underserved. 🟡
- Qualified RTOS / concurrency frameworks 🔴
- No Rust-native RTOS or framework is qualified to ISO 26262 today.
- OxidOS: Pursuing automotive qualification
- RTIC, Embassy, Hubris, Tock: Actively maintained but unqualified and not yet API-stable
- Foreign RTOS integration (VxWorks, QNX, Zephyr): Supported via C ABI/FFI.
- Panic Handling 🟢
- A panic_handler must be defined to reset the system safely
- Unsafe code management 🟡
- Rust's safety guarantees (memory safety, data race freedom) hold only for safe Rust; unsafe blocks opt out of compiler checks
- Embedded Rust typically requires unsafe for hardware register access, interrupt handlers, and FFI to C libraries
#[forbid(unsafe_code)]can be used at module/crate level to guarantee absence of unsafe in application-level code- Tools exist to audit unsafe usage (e.g.
cargo-geiger) but are not qualified - A formal unsafe usage and justification policy (analogous to MISRA deviation management) is needed
🟡 6-9 Software unit verification​
Table 7 — Methods for software unit verification
| ID | Method | Solution: Rust Native or Tool | Readiness |
|---|---|---|---|
| 1a | Walk-through of the design | (Process) improved by Rust's explicit ownership annotations, error handling (Result/Option), and type signatures make control flow and data dependencies easier visible | 🟢 |
| 1b | Inspection of the design | (Process) improved see entry 1a. | 🟢 |
| 1c | Pair-programming | (Process) neutral no impact by Rust | ⚪ |
| 1d | Semi-formal verification | (Tools) partially available Semi-formal verification includes methods like systematic test derivation from semi-formal specifications (e.g. state machines, decision tables). Rust's enum + match exhaustiveness checking provides compiler-verified state machine completeness — a lightweight form of semi-formal verification built into the language. For test generation from external UML or SysML specifications, no Rust-specific tooling exists | 🟡 |
| 1e | Formal verification | (Tools) partially available unqualified tools exist, e.g. creusot or kani, but quality unknown | 🟡 |
| 1f | Control flow analysis | (Tools) partially The Rust compiler builds and analyzes a control flow graph (MIR) for every function on every compilation. Miri can detect undefined behavior along execution paths. Binary-level CFA tools (e.g. AbsInt aiT) exist | 🟡 |
| 1g | Data flow analysis | (Tools) partially The borrow checker tracks variable definitions, uses, moves, and borrows. Miri extends this into unsafe code - but no reports are generated. No traditional DFA tool exists | 🟡 |
| 1h | Static code analysis | (Tools) exists clippy provides configurable static analysis. Miri detects undefined behavior in unsafe code, but clippy doesn't cover all emerging coding guideline rules yet | 🟡 |
| 1i | Static analyses based on abstract interpretation | (Tools) not available lacking support for tools like Polyspace or Astree | 🔴 |
| 1j | Requirements-based test | (Tools) available cargo test handles execution. Traceability to requirements requires tool as e.g. sphinx-needs or mantra | 🟢 |
| 1k | Interface test | (Tools) available cargo test handles execution. Traceability to interface specifications requires external tools | 🟢 |
| 1l | Fault injection test | (Tools) possible to manually implement fault injections. Currently no tool support | 🟢 |
| 1m | Resource usage evaluation | (Tools) tools exist e.g. Orbuculum or TRACE32 by Lauterbach | 🟡 |
| 1n | Back-to-back comparison test | (Tools) not available requires model generators to support Rust and export test vectors | 🔴 |
Table 8 on test case derivation methods is omitted, because it is typically a manual effort and has no direct impact by/for using Rust.
Table 9 — Structural coverage metrics at the software unit level
| ID | Method | Solution: Rust Native or Tool | Readiness |
|---|---|---|---|
| 1a | Statement coverage | available by llvm | 🟢 |
| 1b | Branch coverage | not available yet | 🔴 |
| 1c | MC/DC (Modified Condition/Decision Coverage) | not available yet, is in discussions | 🔴 |
General considerations:
- Coverage instrumentation for embedded targets 🔴
- Host-based: LLVM source coverage works on x86/ARM Linux.
- embedded target: no direct instrumentation to measure code-coverage available
- Binary-level coverage via hardware trace (ETM/ITM + Lauterbach) is language-independent but requires hardware-support and tooling.
- General test tooling and report generation 🟡
- test runner inherent feature by cargo test
- custom runner can be configured to run on embedded targets (e.g. by defmt-test by knurling-rs)
- Demonstrate equivalence between target/test environment and object code, when unit tests are not performed on target 🔴
- No information available
- Traceability between test case implementation and test case specification 🟡
- achievable using tools such as mantra
🟡 6-10 Software unit integration and verification​
Table 10 — Methods for verification of software integration
| ID | Method | Solution: Rust Native or Tool | Readiness |
|---|---|---|---|
| 1a | Requirements-based test | (Tools) available cargo test handles execution. Traceability to requirements requires tool as e.g. sphinx-needs or mantra. knurling-rs allows tests to run on target | 🟢 |
| 1b | Interface test | (Tools) available cargo test handles execution. Traceability to interface specifications requires external tools. knurling-rs allows tests to run on target | 🟢 |
| 1c | Fault injection test | (Tools) possible to manually implement fault injections. Currently no tool support | 🟢 |
| 1d | Resource usage evaluation | (Tools) exist e.g. Orbuculum or TRACE32 by Lauterbach | 🟡 |
| 1e | Back-to-back comparison test | (Tools) not available requires model generators to support Rust and export test vectors | 🔴 |
| 1f | Verification of the control flow and data flow | (Tools) not available | 🔴 |
| 1g | Static code analysis | (Process) exists clippy is standard - but does not offer all checks for coding-guidelines | 🟡 |
| 1h | Static analyses based on abstract interpretation | (Tools) not available lacking support for tools like Polyspace or Astree | 🔴 |
Table 11 on test case derivation methods for integration testing is omitted, because it has no direct impact from the programming language choice.
Table 12 — Structural coverage at the software architectural level
| ID | Method | Solution: Rust Native or Tool | Readiness |
|---|---|---|---|
| 1a | Function coverage | (Tools) supported by llvm | 🟢 |
| 1b | Call coverage | (Tools) supported by llvm | 🟢 |
For general testing-related considerations see 6-9, no specifics for integration testing.
🟡 6-11 Testing of the embedded software​
Table 13 on the verification of the software safety requirements specification is omitted, because it has no direct impact from the programming language choice.
Table 14 — Methods for tests of the embedded software
| ID | Method | Solution: Rust Native or Tool | Readiness |
|---|---|---|---|
| 1a | Requirements-based test | (Tools) available cargo test handles execution. Traceability to requirements requires tool as e.g. sphinx-needs or mantra. knurling-rs allows tests to run on embedded targets | 🟢 |
| 1b | Fault injection test | (Tools) possible to manually implement fault injections. Currently no tool support | 🟢 |
For general testing-related considerations see 6-9, no specifics for embedded testing.
🟡 Annex C (normative) Software configuration​
Table C.1: Mechanisms for the detection of unintended changes of data
| ID | Method | Solution: Rust Native or Tool | Readiness |
|---|---|---|---|
| 1a | Plausibility checks on calibration data | (Architecture) neutral needs to be implemented manually | ⚪ |
| 1b | Redundant storage and comparison of calibration data | (Architecture) not available no qualified libraries for redundant storage and integrity checks of data (e.g. encoding booleans as specific bit patterns to detect corruption) | 🟡 |
| 1c | Calibration data checks using error detecting codes | (Architecture) partially available crate to calculate e.g. CRCs available - PACs for CRC engines are not available | 🟡 |
🔴 8 Supporting Processes​
- 11 Tool Qualification 🔴
- Tools being used during the development/operation need to have undergone Tool Qualification as per ISO 26262-8 clause 11
- Most of the open source tools mentioned before are not qualified
- Where not (sufficiently) available, this has to be individually performed based on the usage context
- 12 Qualification of software components 🔴
- Qualification of software components used within the product needs to be performed as per ISO 26262-8 clause 12
- Most of the open RTOS, PACs, HALs, crates/libraries etc. are not qualified and thus can't be directly used within the product
- Where these are not qualified, this has to be individually performed based on the usage context
Note: Unqualified tools and software components are partially rated as yellow or green, rated based on estimated effort required for qualification in typical usage contexts.