|
|
|
|
|
by eggy
1191 days ago
|
|
Having worked on safety-critical, custom circuitry and programming, particularly in the entertainment engineering field, I find the prolific use of Arduinos, RPis, and ESPs, to be concerning. You pay more for an equivalent industrial board, but there's been a lot more QA/QC done on it. Don't get me wrong, I started with Basic Stamps from Parallax back in the 90s to control window display animatronics in NYC department stores. Great stuff. Fun. But with all the emphasis on high-integrity hardware and software, Rust (I prefer Ada/SPARK2014 for such things until Rust matures in this field), and hobbyist programmers creating show control or machinery controls, I worry that people don't realize that you don't have the same assurances you do with industrial-grade equipment. I opened a very large box a vendor created to control their overhead rigging for a show I was running and found an Arduino and when I had the code audited found a state that would be unsafe. Most tech workers in entertainment would not catch this sort of thing. Yet, this is machinery being deployed above an audience. Greatfully, there are new standards being developed to catch this sort of thing, but these standards/guidelines lag behind, and with the pace of production, I am sure there is a lot being done out there that is unsafe. |
|
That seems separate from the hardware issue with the raspi, like something that would happen with better hardware as well.
It feels like this needs to be handled in the dev tools where going into a dangerous state is automatically followed up by exiting it once an operation is performed and you can't mistakenly stay in the dangerous state. And then have an exhaustive analysis of the FSM to show it performs as expected with the correct state transitions.
What was it (an automated curtain puller?) and did the machine have useful hardware lockouts, such as physical rope-speed limiters or whatever, to make sure it couldn't do bad stuff even if commanded to?