What's the reason behind using the "Off"/"Not-Off" notation for "on-off status" instead of "On"/"Off" or even "On"/"Non-On"? I see some "state" parameters marked as "ON".
I am a controls engineer and saying something is CLOSED when it is actually only observed to be NOT OPEN is my personal windmill I tilt at regularly. People have deied before because what the screen said was that the valve is closed, but what the PLC actually observed is that the valve had left the open position, which was the only limit switch present. Maybe the valve is travelling slowly, jammed halfway open, etc. When operators make the complaint you just did I tell them that what I've told them is reality and if they want a true closed we need a closed limit switch.
Ugh! I've had to deal with this in a situation where we needed two sensors to tell if an object was present or not, but there was only space for one. So we could tell if the payload was not present, but not if it was.
This meant that we would have to make assumptions like "you (other subsystem) say you had the payload and you gave it to me, and I believe you, but I can't prove that you did until much later in time."
And if it turns out that we weren't actually holding it, then recovering from that state required unwinding a whole series of decisions and actions made some time in the recent past.
Suffice to say, it made error handling for certain cases... challenging!
This was my first guess, although I do not have explicitly experience in life-or-death type of control systems. In such systems, does it make sense to have more than two states? Something like "open", "unknown but not open", "unknown but not closed", "unknown", "closed"? (Assuming that you have enough limit switches.)
That's exactly what you do. In all systems you should have two switches, and you annunciate on / off / travelling / error to the operator. Often you inherit something that doesn't have that.
In anything that really matters you have a continuous position transmitter instead of switches so your state is more obvious. In safety systems you might have 2 or 3 of those transmitters so you can have a backup or a vote
Certain controls -- like valves or vent dampers -- are not binary. Even if normal operation is either fully-closed or fully-open, it can technically be anywhere in between.
Having an absolute position sensor would tell you this, but is complex and expensive compared to having two binary state switches (fully-open vs fully-closed) which is also more expensive than a single state switch.
Probably in many cases it just isn't worth it to instrument beyond the single state, especially if the affect of the control is being monitored (eg: flow, temperature, power). However, communicating the state as accurately as possible is important to avoid confusion ("This valve says ON, so that's not the problem" vs "I can see this valve is NOT OFF, but let's double check it's fully-on?").
Guessing here: If you have a breaker switch after an additional switch, labelling the breaker with 'on/off' may be misleading as 'on' doesn't necessarily mean the connected device is powered. It may be off because the other switch is off.
Reading this post led to one of those moments of realization about "no shutdown" in Cisco IOS and similar environments.
The config file can't guarantee the interface will be up when it's loaded as that depends on external factors but it can guarantee the interface will not be shut down.
I've used "no shutdown" as an example of illogical UI for decades because it seems backwards as the user, especially when new to IOS and trying to learn by exploring, but from this perspective it makes sense.
