Rust in Safety Critical Components

[qor-lb]

2026-03-06 - Rust in Safety Critical Components

Participants

Meeting Minutes

1. @pawelrutkaq presented to current state about the readiness for rust in safety critical components
2. Q @RolandJentschETAS: are use-cases for coverage across Rust & C++ boundary covered
   • A: Yes it ist, we can independently cover Rust and C++ code elements and combine the output of both reports later.
3. Q @RolandJentschETAS : does this cover the gaps for both QNX and Linux based distributions?
   • A: No these gaps are currently only assessed for the agreed safety ciritcal baseline QNX 8 for the 1.0. Additional OS onboardings would need to be clarified through the newly defined OS onboarding process during the promotion.
   • Add @skade: It would be not a hughe addition to enable that
4. Q @FScholPer: What is the timeline until when a decision on the open offer needs to be taken so that we can execute this?
   • A: Latest July the decision has to be taken
5. Q @qor-lb: If we increase the scope for additional projects within the eclipse - e.g. to enable a funding on eclipse level - would the offer need to be revised?
   • A @skade : Not necessarily - this is a first time for such an offer and Ferrous is open to discuss together with the eclipse a potential setup on how to keep this manageable

• Outcome: The current gaps for utilizing Rust in Safety Critical Components in S-CORE for the 1.0 on QNX 8 are assessed and measured. For the open mandatory gaps (libcore, libstd, coverage) we have an enabling offer on the table from Ferrous Systems.
  • S-CORE decides that this is sufficient evidence to move further with the utilization of Rust in safety critical components
  • In parallel, S-CORE wants to escalate/promote a joint founding to close these gaps to the X-CORE council
  • and representatives of the eclipse, Dana, to potentially enable Eclipse wide support

[qor-lb]

Decision Record for the outcome: #2666