Hi,
I joined the Eclipse Rust SIG today and would like to follow up on two remarks regarding the classification in “ISO 26262 vs. Rust Gap Analysis”, which I also raised during the call.
Specifically, this concerns the following two statements:
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.
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
Both items are currently ranked as "🟡 Achievable - requirement can be met with moderate additional effort"
In my opinion, both requirements are not specific to Rust and are not directly influenced by the choice of programming language:
- Scheduling properties (1f) are determined by system architecture decisions, the RTOS, and the underlying hardware. Rust neither improves nor degrades scheduling guarantees compared to other systems programming languages.
- Spatial isolation (1h) likewise depends on hardware (MPU/MMU), OS configuration, and system design. While Rust provides strong logical isolation and memory safety, physical isolation is entirely outside the responsibility of the language and equally required for C, C++, or any other language.
Rust is therefore not worse than other languages in these areas, but it also does not fundamentally “enable” these requirements. They are addressed through proper OS usage, hardware configuration, and system-level design choices.
For these reasons, I would suggest classifying both 1f and 1h as:
"⚪ Not impacted - requirement is not directly affected by the choice of programming language"
This would better reflect that the ISO 26262 requirements in question are architectural/system concerns rather than language-driven properties.
If the intention behind the "🟡 Achievable" rating for items 1f and 1h is to highlight gaps in Rust bindings for qualified RTOSes or hypervisors, then this concern appears to be already covered elsewhere in the gap analysis—in particular under:
“FuSa library support for qualified microcontroller", "Hardware Abstraction Layer (HAL) availability”, and
“Qualified RTOS / concurrency frameworks”
(listed under 🟡 6–8 Software unit design and implementation)
In my view, duplicating this aspect at the architectural level (1f / 1h) risks conflating language impact with ecosystem maturity and availability of qualified integration layers. Keeping these concerns scoped to the software unit / tooling level would help maintain a clearer separation between system architecture topics and language-specific effects.
Best regards
Anton
Hi,
I joined the Eclipse Rust SIG today and would like to follow up on two remarks regarding the classification in “ISO 26262 vs. Rust Gap Analysis”, which I also raised during the call.
Specifically, this concerns the following two statements:
Both items are currently ranked as "🟡 Achievable - requirement can be met with moderate additional effort"
In my opinion, both requirements are not specific to Rust and are not directly influenced by the choice of programming language:
Rust is therefore not worse than other languages in these areas, but it also does not fundamentally “enable” these requirements. They are addressed through proper OS usage, hardware configuration, and system-level design choices.
For these reasons, I would suggest classifying both 1f and 1h as:
"⚪ Not impacted - requirement is not directly affected by the choice of programming language"
This would better reflect that the ISO 26262 requirements in question are architectural/system concerns rather than language-driven properties.
If the intention behind the "🟡 Achievable" rating for items 1f and 1h is to highlight gaps in Rust bindings for qualified RTOSes or hypervisors, then this concern appears to be already covered elsewhere in the gap analysis—in particular under:
“FuSa library support for qualified microcontroller", "Hardware Abstraction Layer (HAL) availability”, and
“Qualified RTOS / concurrency frameworks”
(listed under 🟡 6–8 Software unit design and implementation)
In my view, duplicating this aspect at the architectural level (1f / 1h) risks conflating language impact with ecosystem maturity and availability of qualified integration layers. Keeping these concerns scoped to the software unit / tooling level would help maintain a clearer separation between system architecture topics and language-specific effects.
Best regards
Anton