Proposal
Carry the alarms of a SIMATIC PLC onto the ROS 2 graph through the node that ROXSIE generates, and map them onto the existing fault model. Three message definitions in a small interface package:
Alarm - one alarm: identifier, source, class, priority, producer, active and acknowledged flags, the PLC timestamp, and the values latched when the alarm fired.AlarmList - every alarm that is active or waiting for acknowledgement, published cyclically.DiagnosticsStatus - one condition back into the PLC, plus a heartbeat.
A bridge compares consecutive lists and reports the difference to the fault manager, so a PLC alarm gets the same debounce, freeze-frame and audit trail as any other fault.
Motivation
ROXSIE already generates the PLC blocks and a ROS 2 package for the data you declare in the YAML config. That covers process values. It does not cover alarms, because alarms live in the CPU message system and not in a data block.
So on a machine with a SIMATIC PLC and ROS 2 you still have two separate lists of what is wrong. To join them today you either read alarm bits over a protocol and rebuild their meaning from an engineering export, or someone copies the alarms by hand into a second list on the panel. Both drift.
The list is a picture of the current state rather than a stream of events, for two reasons. The transport is cyclic anyway, so a picture is what it naturally has. And a picture survives a restart: the next cycle carries the full truth again, while a stream loses whatever happened while the consumer was away.
The two directions are not the same size, on purpose. Alarms come out in full. Back the other way goes one condition and a heartbeat, because fault text is dynamic, a PLC that handles strings loses determinism, and a fault list inside the PLC would be a second copy that drifts from the first. The machine needs something it can act on; whoever wants the detail reads it over REST.
Alternatives considered
- Push fault text into the PLC and show it in the native alarm list. Rejected: dynamic strings are the wrong payload for a deterministic controller, and it creates a second fault list to keep in sync.
- Drive the signal column directly from the diagnostics side. Rejected: machines already have a state machine and, where PackML is used, a block that turns machine state into signal column bits. Two writers on one lamp is a fault of its own.
- Read the alarms over a protocol instead. Works where the option is licensed and enabled, but it is a second connection to configure and maintain next to the data path that already exists.
- Model alarms as
/diagnostics. DiagnosticStatus has no acknowledgement state, no source timestamp and no latched values, so the parts that make an alarm an alarm would be lost.
Additional context
Design note, message definitions and the open questions are in the draft PR that references this issue.
Proposal
Carry the alarms of a SIMATIC PLC onto the ROS 2 graph through the node that ROXSIE generates, and map them onto the existing fault model. Three message definitions in a small interface package:
Alarm- one alarm: identifier, source, class, priority, producer, active and acknowledged flags, the PLC timestamp, and the values latched when the alarm fired.AlarmList- every alarm that is active or waiting for acknowledgement, published cyclically.DiagnosticsStatus- one condition back into the PLC, plus a heartbeat.A bridge compares consecutive lists and reports the difference to the fault manager, so a PLC alarm gets the same debounce, freeze-frame and audit trail as any other fault.
Motivation
ROXSIE already generates the PLC blocks and a ROS 2 package for the data you declare in the YAML config. That covers process values. It does not cover alarms, because alarms live in the CPU message system and not in a data block.
So on a machine with a SIMATIC PLC and ROS 2 you still have two separate lists of what is wrong. To join them today you either read alarm bits over a protocol and rebuild their meaning from an engineering export, or someone copies the alarms by hand into a second list on the panel. Both drift.
The list is a picture of the current state rather than a stream of events, for two reasons. The transport is cyclic anyway, so a picture is what it naturally has. And a picture survives a restart: the next cycle carries the full truth again, while a stream loses whatever happened while the consumer was away.
The two directions are not the same size, on purpose. Alarms come out in full. Back the other way goes one condition and a heartbeat, because fault text is dynamic, a PLC that handles strings loses determinism, and a fault list inside the PLC would be a second copy that drifts from the first. The machine needs something it can act on; whoever wants the detail reads it over REST.
Alternatives considered
/diagnostics.DiagnosticStatushas no acknowledgement state, no source timestamp and no latched values, so the parts that make an alarm an alarm would be lost.Additional context
Design note, message definitions and the open questions are in the draft PR that references this issue.