[HN Gopher] Building a 3D safety sensor with Rust
___________________________________________________________________
Building a 3D safety sensor with Rust
Author : torotime
Score : 70 points
Date : 2024-12-26 05:29 UTC (2 days ago)
(HTM) web link (www.sonair.com)
(TXT) w3m dump (www.sonair.com)
| ctoth wrote:
| > 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 wrote:
| "Asking an LLM what it thinks about an article" is the new
| "judging a book by its cover".
|
| Except it's even dumber.
| electromech wrote:
| 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).
| Xylakant wrote:
| 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 wrote:
| We are already talking :)
| nostradumbasp wrote:
| 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.
| Xylakant wrote:
| So the cost for the basic level (quality managed, one
| target architecture) are pretty low - about 240 EUR/human
| per year. CI runners are free. Certification material is
| billed separately to allow speculative and experimental
| usage. You only pay for it if and when you need it.
|
| 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.
| jdiez17 wrote:
| 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!
| Xylakant wrote:
| We'd also be more open about the rest of the plans, but
| it's a hard information design problem more than anything
| else - the website desperately needs an update. Too much to
| do and too little time. If I just didn't spend so much time
| around here ;)
|
| 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.
| jdiez17 wrote:
| > Too much to do and too little time. If I just didn't
| spend so much time around here ;)
|
| 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"?
| Xylakant wrote:
| Dependencies. Hard topic. The question is less about the
| numbers, but rather in the amount of code you pull in. In
| the end, every line needs to be certified. The team that
| wrote sudo-rs blogged about their approach here
| https://www.memorysafety.org/blog/reducing-dependencies-
| in-s...
|
| 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)
| jdiez17 wrote:
| That makes a lot of sense, thanks!
| cdaringe wrote:
| 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-TK wrote:
| 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.
| nostradumbasp wrote:
| 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.
___________________________________________________________________
(page generated 2024-12-28 23:00 UTC)