Building a 3D safety sensor with Rust

https://www.sonair.com/journal/building-for-safety-with-rust

by torotime • 2 years ago

104 25 2 years ago

ctoth• 2 years ago

The writing has characteristics of content that might have been partially generated or assembled from multiple sources without smooth transitions between sections. While the technical information about Rust seems solid, the narrative structure and voice consistency aren't what you'd typically expect from a single-author technical blog post.

Arms race!

Spam-filters, actually. Once they became self-modifying, spam-filters and spam-bots got into a war to see which could act more human, and since their failures invoked a human judgement about whether their material were convincingly human, it was like a trillion Turing-tests from which they could learn. From there came the first machine-intelligence algorithms, and then my kind.

https://craphound.com/overclocked/Cory_Doctorow_-_Overclocke...

Groxx• 2 years ago

"Asking an LLM what it thinks about an article" is the new "judging a book by its cover".

Except it's even dumber.

emmelaich• 2 years ago

Where is that first quote from?

electromech• 2 years ago

No mention of Ferrocene other than a "further reading" bullet point at the end. Are they using it? Does that help with respect to getting a device safety certified?

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).

Xylakant5• 2 years ago

Disclaimer: I’m one of the founders of Ferrous Systems, the company behind Ferrocene.

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.

torotime• 2 years ago

We are already talking :)

nostradumbasp3• 2 years ago

Really glad you all are out there doing what you do. In my opinion it is the most important thing for Rusts long term success and longevity. No clue what the costs are like for running on Ferrocene but maybe one day I will have a project that'd benefit from it.

jdiez173• 2 years ago

Thank you for your work on Ferrocene! I particularly appreciate that you're open about the price, at least for a starter license.

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!

cdaringe• 2 years ago

I tried using async rust on my esp32 last year, and though i got some functionality working, any little victory was always followed seconds later by big, productivity halting, hard-to-overcome hurdles. Im glad people smarter than me are making it happen

Arch-TK2• 2 years ago

I'm writing firmware for my espresso machine in Rust right now and I was also pretty blown away at how easy it is. I am writing code across two micro-controllers (I'm re-using existing hardware) and I am using no-std RTIC2+Embassy on an STM32 inside machine and std Embassy on a ESP32-S3 on the outside of the machine. I don't know C++ (although C++ for embedded would probably have been fine, except I don't like C++ anyway) and it would have been a lot more work to get this working in C.

Using Rust I get so many static guarantees that it makes it trivial to get things working. And things have matured a lot since the last time I checked about a year ago.

Things are still a bit rough, for example I am maintaining my own version of embassy-stm32 so I can make a few things work the way I want to, but it's not really a problem for an embedded project.

Developing rust for xtensa is also a bit painful at times, but it still beats writing C or C++.

Moreover, RTIC2 allows me to write high performance real time code the way I would have written it in C with a mountain of boilerplate removed from sight just down to the way async works in rust as well as the things RTIC handles.

gregoryw32• 2 years ago

Just wondering why you decided to use Embassy and RTIC? Was there any specific reasons? I’m doing an Embassy project on an esp right now so wondering if you have any issues or insights worth mentioning?

From my understanding Embassy and RTIC are two different models of concurrency so I’m not sure of any benefit of using both at the same time.

Arch-TK2• 2 years ago

So, on the STM32 (which is the only place I am using RTIC), I don't use the Embassy executor. I just use the embassy-stm32 hal crate for all my peripherals and embassy-futures for some of the executor-agnostic no_std and non-alloc futures utilities.

A lot of embassy (except quite unsurprisingly, the executor) is executor agnostic. In fact, I think it might be _all_ of embassy that is executor agnostic. There's some information here: https://rtic.rs/dev/book/en/rtic_and_embassy.html

While my code is not public yet, here is an example (written by someone else) of STM32 code using the embassy-stm32 I2C peripheral wrapper with RTIC:

https://github.com/andresv/rtic_arbiter_demo/blob/master/src...

nostradumbasp3• 2 years ago

I love articles like this. Team of engineers try something new to them and win long term. All of the bullet points were the experience I've had in my professional and hobby projects. It's a great language and ecosystem. There is a lot of hate on here about the technology but the proof is in the pudding.

groby_b• 2 years ago

Now how to build a web site that doesn't keep 60% of the screen as whitespace is the next frontier of software.

Well, that, and writing articles that aren't mostly content-free.

gpcz• 2 years ago

I'm interested in knowing how they achieve requirements traceability to code and the requisite level of code coverage (certain SILs require MC/DC coverage, which usually requires expensive tooling). Also which hazards they identified and their mitigations.

Xylakant5• 2 years ago

They are aiming for SIL 2 which to the best of my knowledge requires no MC/DC coverage. MC/DC support in rustc is being worked on, but I would not expect the required features to land before end of 2025 or even mid 2026.

tonyhart7• 2 years ago

this is me or the web is broken ??? (all text align to the right side)

cjk• 2 years ago

I see the same thing (Safari, macOS 15.2). It seems to be a design choice.

Building a 3D safety sensor with Rust

Related Stories