[LawTalkingGuy]

> I [...] found a state that would be 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?

[eggy]

True, I was just offering up an example on the software end, but it has to do with hobbyist embedded people think they can make an Arduino sketch for safety-critical applications.

I am more concerned with hardware issues, since the plethora of ESPs and Arduinos being made do not go through a Six Sigma type process to control the process. Also, the piece I pointed out did not have other separate hardware or other safety watchdogs in the box, like a Pilz unit supervising Beckhoff i/o. It was an Arduino with some relays off of its GPIO pins. High-integrity systems need to include both the hardware and software. There are actually standards for high-integrity systems aside from the usual aerospace stuff that applies to show control or machinery control. Safety-Related Control Systems (SRCS) are being addressed more and more in ASTM F24 for Amusement Rides and Devices.

I loved my Basic Stamp, Pic-chip, and Propeller chip days. Fun, but I am glad I progressed beyond the hobby level before anyone let me put a piece of kit up! Window displays were fairly innocuous!

I've always tried to add actual physical, mechanical interlocks on some of the stage machinery I've designed where a flipped bit or faulty i/o would cause harm or death! See my Arduino reference below.

I wish SPARK2014 would get more love. It has been around for a while with real-world applications, but Rust is the darling of the tech crowd now. AdaCore and Ferrous Systems are teaming up to bring some Ada goodness to Rust along with the legacy experience and apps.

Cool article on drones and SPARK2014: https://blog.adacore.com/how-to-prevent-drone-crashes-using-...

Cubesats: https://www.cambridge.org/core/books/building-high-integrity...

Arduino and Safety-Critical Circuit: https://forum.arduino.cc/t/safety-critical-circuit/319986/2

[eggy]

Just caught your "curtain puller" reference. I have designed a stage lift that travels at 4 ft/s from below stage after a sloat moves 6 ft/s out of its way to reveal 7 performers on stage after a poof of smoke. A sloat is the piece of the stage floor that needs to run down and under the stage to make an opening. I put some beefy metal flags that would only release the lift to go up after the sloat had cleared the opening. A mechanical interlock. No software needed. This was the late 90s and I was already suspicious of bits flipping as the software guys started taking over the electro-mechanical effects. Don't get me wrong. I have been programming since 1978, but I have also been a machinist, welder, underwater technical diver, rope technician, and I build my own CNC machine back in 2001 before you could buy a $300 3D printer or an X-Y-Z table for less than $20k. I have theoretical and practical experience, and red flags go up when somebody (usually a hobbyist or artist's tech) tells me they use Arduinos or RPis for their controls. I am not against it, but I know this carries some attendant concerns. Who is programming the logic? What other secondary watchdog/safety hardware (if any) is being used to ensure another layer of safety, etc...

SPARK2014 the programming language and the dev tools include a verification toolset, automated proofs, and unit testing. Rust may eventually catch up ;)

[LawTalkingGuy]

I'd never heard of a sloat before. Yeah, that sounds like the kind of thing which could crush someone pretty easily if not done right.

I agree with the hardware safety interlocks, which I guess is why I don't think so much about the software - because I imagine it was programmed by a monkey (perhaps myself, late the previous night) and I don't trust it anyways. It's like a switch an untrained stagehand might hit which needs to be safe regardless.

(I've never made anything to be around a performance, but some of my things could certainly have hurt me or friends if we weren't careful.)

> SPARK2014 the programming language and the dev tools include a verification toolset

This is something that third-party FSM libraries often lack, decent controls and verification.

The cubesats are cool. Usually I can walk over and kick my creations when they need a reset, that's a whole 'nother level.