From https://ferrocene.dev:
> ISO26262 (ASIL D), IEC 61508 (SIL 4) and IEC 62304 available targetting Linux, QNX Neutrino or your choice of RTOS.
The article also mentions one of those standards:
> Sonair is developing a safety-certified device (IEC 61508 and SIL2).
One of the goals when certifying Ferrocene was that it serves as a drop in replacement for rustc. So while we’re happy if you start out building your product with Ferrocene (and have made our pricing model compatible with that) - going the route of “rustc first, then slot in Ferrocene” is entirely supported. There are also sometimes good reasons to pick that approach - Ferrocene is much more limited in terms of target support and while we may have a timeline to deliver the target you need in the qualification level you need, we might not ship it yet (though we usually can enable Support relatively quickly)
That said, I’m quite confident that using Ferrocene gives you a faster route to certification than trying on your own. I’d not be surprised if we hear from them.
A lot of projects can benefit from that level of assurance since we have a different support tier policy than upstream Rust, that is: we treat different targets as Tier 1. And you get signed installers for windows etc.
Also, with the upcoming CRA legislation, using a quality managed toolchain will make your life easier - one part you don’t have to manage.
We're using Rust for space applications, and while we don't have a need to certify our software yet, we'll keep Ferrocene in mind for the future.
EDIT: Oh, the Ferrocene compiler is fully open source. I didn't expect that!
The compiler being open source is not the big thing - it’s mostly upstream rustc with very little modification. However, all of the safety manuals are open too, so you can see what you’ll get.
I see that you’re from Berlin - if you’re interested in a chat, ping us.
Heh, very relatable :)
> I see that you’re from Berlin - if you’re interested in a chat, ping us.
I also just saw you're based in Berlin. Will definitely ping you when I'm back. Particularly interested in your "Rust Experts" offering.
One question about Rust safety certification in general:
How do you deal with dependency sprawl? For example, if you write a basic async program with Tokio and friends you may end up depending on >200 crates. Would you our your clients certify them one by one? Are they much more picky with which dependencies they "take on"?
Essentially, expand your use for initial development and whittle down later as much as possible.
That said, Tokio is not going to be a good certification candidate - but that’s a topic for a longer conversation. (TL;DR: The Tokio project has aims and goals that are good for their use, but problematic when it comes to writing safety certified software)