Recently, I implemented a Rust program for some data packetization on an STM board which is now being used in an unmanned aerial vehicle(cant reveal more about it ). This made me curious that whether if anyone else was using this language over embedded C. Are people who are working in automotive, railways , aviation migrating to rust as well or are they still sticking to the conventional practices?
Rust in automotive is progressing nicely: https://www.youtube.com/watch?v=ui427FWXimQ
Rust compilers are getting approvals for such safety-critical use: First Rust compiler qualified for ISO26262 ...
Somewhere I found a presentation about using Rust on trains. Sorry, can't find the vid just now.
Sure most such embedded systems will continue in C for a long time but Rust is definitely moving into that space.
Ultimately I don't think adoption will be super different from the way Rust is being used in non-regulated, pre-existing codebases:
- look and poke at it, in one's spare time
- get buy-in from higher ups in the org to do controlled small-scale experiments
- after the success of the experiments, slowly start introducing it into code bases, where it'll primarily be leveraged for new code at first, and then it'll be used to rewrite parts of the code base as those need to be refactored.
- once large parts of the team(s) have sufficient experience with Rust in that domain (read: after 10+ years), they might opt for a rewrite of future versions of their software if they deem the cost/benefit worth it at that time.
So indeed, I expect it'll be a slow but steady march away from C/C++ and towards Rust.
And it's not unthinkable there will be no replacement for Rust, at least not in the way Rust code might replace C code: AI's are still pretty bad at writing code, being able to perform only the bare basics e.g. write me a sorting function.
But I don't expect that will be true forever, and if you can just (incrementally) give high level requirements and have a 100KSLOC of even a couple of MSLOC worth of code appear in short order based on those requirements, and have it work the way it's supposed to, I expect that at that point human beings are done as programmers, at least professionally speaking.
Unfortunately in the safety critical space, automotive, avionic, etc adoption is hindered by all manner of requirements to meet all kind of safety standards, approvals and processes. One presentation I found discussed all this and how pretty much all such regulation was built around C and C++. Meeting technical requirements is one thing, fulfilling requirements on development processes is another. For example starting with how the compiler is developed and verified.
Luckily that presenter ended with the good news that after some years of effort to follow and document procedures the authority in question itself began to realise how silly their rules were, causing a lot of useless "busy work" that did not actually contribute to safety, and started to adapt them to the modern world and Rust.
Agree with the safety standards part , but i felt that for unmanned vehicles, they aren't so strict so drones and warehouse robots can be explored with rust on industrial use
I recall Mara Bos (author of the popular Rust Atomics and Locks) originally started using Rust over C++ for embedded devices on flight controllers at her company. Here's a CppCast podcast episode "Rust <=> C++" with her discuss this among other interesting topics: Episode 382 : CppCast
One thing I don't understand about using Rust for safety critical software such as Avionics: since there are requirements to use static analysis tools that guarantee safety, what advantage does Rust bring over C/C++, and why is it significant enough to consider changing languages?
(For new projects with a new team, I can understand why using a more modern language with nice tools could make sense.)
One thing is that all the annotations in Rust are really helpful. See https://www.circle-lang.org/draft-profiles.html#c-is-under-specified for a great discussion of that.
Static analysis can be even better in Rust than in C++, because it doesn't have to start by figuring out WTF your parameters are even supposed to mean, and which things are supposed to not have safety preconditions.
See, for example, how the first thing you do in C++ to run a bunch of the static analyzers is start adding a bunch of annotations to help the checker know what you're trying to do and what the things you're calling are doing: Understanding SAL | Microsoft Learn
I have not been involved in using static analysis tools since the late 1980's. That did not result in any contribution toward correctness and was abandoned. My understanding is that while such tools have improved since then they still fall short. They simply don't have the required information for proper analysis in the source code of the programs you feed them. My understanding is that they are hard to use and still produce lots of false results, either deciding there is a problem where there is not or not pointing out real problems. Someone correct me if I am wrong on this today.
That is why back in the day the Ada language was used for safety critical systems (and still is I believe). Ada has a lot more features to ensure correctness than languages like C.
So I conclude that the features Rust offers contribute greatly to producing correct robust software. My experience using Rust for the last four years, everywhere from embedded to server side, bears that out.
Anyway, why would anyone reject the safety guarantees of Rust, which basically come for free, as a replacement for much hard to use, time consuming and error prone static analysis tools? Better yet I suspect that such analysis tools will be able to work much better given the extra information and guarantees that Rust provides them.
Never mind the skies. There is ThRust in Space: https://www.youtube.com/watch?v=O09rje6yC90&list=TLPQMjUxMDIwMjR6gKXQdU9PnA&index=3
it's worth noting that ferrocene exists to address some of the regulatory issues.
That's what I thought, but when I search for what languages are used today in critical automotive and aeronautics software, I do not see Ada, I see C/C++ with static analysis tools and formal methods (which apparently have come a long way). Ada still comes up for aerospace.
But I think it is super cool to see the tools in this category for Rust appearing, for example, see the list of talks here: https://rust-formal-methods.github.io/
This one from Amazon, that uses a property testing-like approach, looks like it might even be usable by an average programmer like me: https://model-checking.github.io/kani/getting-started.html
We're using Rust in railway. Not for primary train control, though that's only because we're not the ones doing that part... but we would use it if we were. The advantages are simply too big to ignore.
I see so is it for now just to write some data aquisition and transfer?
Rust in aerospace is alive and well, at least in the communications side. I work for an airborne satcom supplier whose products, both modems and application servers, use Rust for internal applications, and in some cases are migrating applications from Python and Java to Rust.
Yes even I worked on establishing some communication programs in my case. Do you think rust will get better support for let's say ROS which python already is using?
I'm not sure, the things we do are not at all like ROS, and aren't part of the flight control systems. Rust has a lot of features that make sense for critical control systems, so it wouldn't surprise me, but ROS also doesn't seem to be used directly in human risk-of-life systems like avionics for human carrying aircraft. Flight safety certification really raises the bar on the complexity and test costs for software, and if "we" let cars out on the road without a similar level of certification, we're certifiable.
Yes , surely ROS won't used for safety critical systems but I meant for places like warehouse robots where ROS can be quite useful.
It's for VOIP (for the on-board communication systems) as well as the radio interface to the wayside.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.