Part of #283.
Real machines are mixed. Some modules have a dedicated stop input; some can only be de-energised; some sensors need no stop at all. A framework that assumes every device can be commanded to a safe state cannot describe the first and third kinds, and one that assumes power-cut cannot describe a Category 1 machine.
Today nothing in the inventory says which a device is. FunctionPolicy carries a free-text safety_profile that nothing consumes, and there is no way for a provider to state:
- this device self-safes on loss of bus traffic (firmware watchdog), and at what timeout
- this device has a hardware stop input wired to a machine-level interlock
- this device can be commanded to a safe state over the bus
- this device has no actuating outputs and needs no stop
Without that the runtime cannot compute honest coverage. It cannot answer "is every actuating output on this machine covered by some stop mechanism", which is the question behind #246 and #253 — those currently inspect config shape instead, because the inventory cannot tell them anything better.
Interaction with the safe-state design
The EnterSafeState proposal (Phase 4 of #283) is one of these mechanisms — the commanded, Category 2 one. Declaring capability is what lets the runtime fall back sensibly for devices that will never implement it, rather than making machine safety a function of the least-conformant provider binary on the bus.
Note on the reference machine
Its DCMT and RLHT firmware both implement a hardware stop input, and both are deliberately left unwired because the machine uses a total power cut instead. So "the device supports a mechanism" and "this machine uses it" are separate facts, and both need to be expressible.
Part of #283.
Real machines are mixed. Some modules have a dedicated stop input; some can only be de-energised; some sensors need no stop at all. A framework that assumes every device can be commanded to a safe state cannot describe the first and third kinds, and one that assumes power-cut cannot describe a Category 1 machine.
Today nothing in the inventory says which a device is.
FunctionPolicycarries a free-textsafety_profilethat nothing consumes, and there is no way for a provider to state:Without that the runtime cannot compute honest coverage. It cannot answer "is every actuating output on this machine covered by some stop mechanism", which is the question behind #246 and #253 — those currently inspect config shape instead, because the inventory cannot tell them anything better.
Interaction with the safe-state design
The
EnterSafeStateproposal (Phase 4 of #283) is one of these mechanisms — the commanded, Category 2 one. Declaring capability is what lets the runtime fall back sensibly for devices that will never implement it, rather than making machine safety a function of the least-conformant provider binary on the bus.Note on the reference machine
Its DCMT and RLHT firmware both implement a hardware stop input, and both are deliberately left unwired because the machine uses a total power cut instead. So "the device supports a mechanism" and "this machine uses it" are separate facts, and both need to be expressible.