Rust SIG Meeting - 2026-04-28 #25

PLeVasseur · 2026-04-28T13:48:25Z

PLeVasseur
Apr 28, 2026
Collaborator

Hey folks 👋 welcome to our 8th meeting of 2026.

Solicitation of notetaker
- Pete LeVasseur
Rust Watercooler Chat Topic - How ready is Rust for ISO 26262 applications? A practical gap analysis; Stefan Akatyschew - Anori Tech UG
Review GitHub repo content and discuss how to enrich (Pete)
1. Issues
2. Discussions are now active! We'll take meeting notes here based on previous agreement in the SIG.
Office hours - Rust + Automotive questions - come chat! (All)
Discuss upcoming events / news related to Rust & Automotive (All)
Meeting close

(we had about 10 people at one point, including the folks listed below)

discussions among group: C, C++, or Rust
from this got motivated to survey the ecosystem for how "ready" Rust is for use in Automotive/ISO 26262 and other functional safety
got involved with putting together this practical gap analysis for Rust

Eclipse SDV WG: good example of an organization that's helping with transition
going from largely hardware first, to software first as defining more and more functionality
important to follow standards like IEC 61508 (mother of many other standards for functional safety), ISO 26262 (Automotive)

Some considerations:

For example, may not be a lot of impact on the choice of programming language for certain steps
Some others the impact may be quite large like software unit design and implementation
ISO 26262 specifies a number of steps for each item in the V model, some of which do then depend on the programming language choice

The approach:

take experience and the letter of the standards to make this determination
- experience important, as ISO 26262 does not tell how to implement the requirement, the specifics
- some things not specified in the standards, but practically speaking this is just something you will run into like having a Hardware Abstraction Layer (HAL) or an Real-Time Operating System (RTOS)
holistic judgement based on traffic light systems
- red/yellow/green based on how ready/mature Rust is

so, true, for e.g. C++ there's a large number of safety-certified libraries; how do these compare?
there's another level / dimension of complexity
- depends on the application in ISO 26262
- for simple applications may not need many/any libraries
- on the other hand, for e.g. High Performance Compute (HPC) you may need many
do we know of existing safety-certified crates?
- there is Ferrocene, a safety-qualified compiler for ISO 26262, IEC 61508 and (the medical standard whose number I forget)

Is the C++ library already qualified?
- C++ is already qualified
Now developing the Rust portion that binds to the C++ portion
As an assessor would like to have evidence that there are no issues with e.g. data alignment or endianness between the two programming languages

Is invocation of FFI via Rust safe?
- no, marked as unsafe
If the assessor is unaware of these details, then you as the submitter should be proactive and responsible enough to share with them evidence of why the FFI is reasonable
claims related to e.g. borrow checker are now not valid when in any unsafe block, including FFI
- implies the submitter should put in the effort to prove this with evidence
- Unsafe Coding Guidelines may help here
recommended to have unsafe blocks be as tightly scoped as possible
unsafe propagates up to the module scope
can use Cargo Vet to automatically validate of quality level into building process to formalize these in reviews

Enforcement of low complexity: 🟢
Use of language subsets: 🟡
- May be able to be bumped up to 🟢 with the the release of the SAE document JA-1020 (https://standardsworks.sae.org/standards-committees/safer-rust-task-force)
Enforcement of strong typing: 🟢

There are some things not covered by the standard explicitly, but still important

Model-based tooling: 🔴
- unaware of these existing currently in e.g. Simulink
- not exactly an issue; you could argue not a hindrance to development
Software partitioning / Freedom From Interference (FFI) 🟡
- Logical separation of software units/modules encouraged
- Temporal and spatial freedom from interference requires hardware mechanisms (MPU/MMU) or a hypervisor
- Yellow: typically tools available from vendor, which can help with setting up registers for example if using another language like C, C++
  - Comment from audience: not really programming language specific
  - Not many RTOS drivers/APIs available in Rust yet
  - Problem itself is programming language independent, the partitioning and Freedom From Interference
  - Vendor might provide something prepared for you that you can use, typically implemented in C; could also be the case that you simply need to fulfill the hardware's safety manual in an independent way from programming language
Qualified RTOS / Concurrency framework 🔴
Branch coverage 🔴
- In nightly; not qualified yet
- Might be that Vector has a product
Coverage instrumentation 🔴
- Some like Lauterbach may be available, depending on the platform chosen