BLEPS-3: beamline-level "BLEPS state" that operators act on

[decarlof]

BLEPS-3: beamline-level "BLEPS state" that operators act on

Title: BLEPS-3: system-level BLEPS state (fault/trip/warning aggregates + reset commands) — CORA assumption partially wrong

Body:

Question

Is there a beamline-level "BLEPS tripped / armed / recovering" state that operators act on as a whole?

CORA assumes no system-level state is needed and that it should be decomposed onto existing axes.

Answer

Yes — there is a system-level state, and operators do act on it as a whole. CORA's assumption ("no system-level state needed") is partially wrong. Pure decomposition onto Supply / Asset axes would miss wha
t current beamline practice actually uses.

The three system-level aggregate PVs

The BLEPS PLC publishes three "any-latched-somewhere" booleans that OR across every per-channel fault / trip / warning:

PV	Semantics	Behaviour
2bmBLEPS:BLEPS:A_FAULT_EXISTS	Any latched fault anywhere in the BLEPS system	High if any per-channel fault is latched; low when all clear + acknowledged
2bmBLEPS:BLEPS:A_TRIP_EXISTS	Any latched trip anywhere (vacuum-section / flow / temp trips)	Same semantics, one-severity-lower than fault
2bmBLEPS:BLEPS:WARNING_EXISTS	Any latched warning anywhere (IP/IG warnings, flow under-range, temp over-range, PSU warnings, OR-module warning)	Latching — stays high after the underlying condition
clears until reset

Severity hierarchy (from the PLC): A_FAULT > A_TRIP > WARNING. Each severity has its own reset.

These are what operators use

On the deployed MEDM operator summary (bleps_status.adl, see the "MEDM status summary" section of 2bm-docs manual/item_025.rst), the very top row of the screen is three coloured indicators driven directl
y by these three PVs:

• FAULT box — grey when clear, red when A_FAULT_EXISTS = 1.
• TRIP box — grey when clear, orange when A_TRIP_EXISTS = 1.
• WARNING box — grey when clear, yellow when WARNING_EXISTS = 1.

Operator practice is to glance at this row before opening shutters. If anything is coloured, they investigate the specific channel that latched (via the caQtDM full panel or the vacuum / flow / temp sub-rows o
n the same summary). This is a "single glance decides whether the beamline is ready" indicator — the definition of a system-level state.

System-level commands, too

The system-level state comes with system-level actions:

PV	Action
2bmBLEPS:BLEPS:A_FAULT_RESET	Write 1 — clear all latched faults on the PLC (may cascade to trips + warnings in some PLC configurations)
2bmBLEPS:BLEPS:TRIP_RESET	Write 1 — clear all latched trips

(There is no dedicated WARNING_RESET PV. Warnings clear via the underlying condition returning to normal, or via the physical BLEPS panel button, or — in some configurations — as a side effect of A_FAULT_RE SET.)

Both reset PVs are wired to buttons on the MEDM summary (Reset FAULT and Reset TRIP), so operators can acknowledge from the same page they read the state on.

Suggested CORA model

Rather than a single "BLEPS tripped / armed / recovering" state, the deployed BLEPS actually exposes a three-severity aggregate plus two reset actions:

• Aggregate state: three independent booleans (fault_latched, trip_latched, warning_latched) that OR across every per-channel condition.
• Aggregate actions: two commandable reset pulses (reset_faults, reset_trips).

CORA can either:

• (a) Model these as a new system-level "BLEPS Health" object exposing the three aggregates and the two reset commands — matches operator practice most cleanly.
• (b) Model only the per-channel Supply / Asset conditions and derive the aggregates from an "any-of" query — mathematically equivalent for read-side, but loses the reset-command surface (there's no per-ch
  annel reset — the PLC only offers system-wide reset PVs).

Recommendation: (a). The system-level reset PVs are commandable state that has no natural home on Supply or Asset (they act across many at once), so a dedicated system-level object is the honest representa
tion.

What CORA got right

CORA's implicit position — that most per-channel conditions decompose to Supply / Asset — is correct (see BLEPS-1 and BLEPS-2). What was missed is that BLEPS also has three genuinely-system-level PVs and two g
enuinely-system-level actions that don't fit the decomposition.

Related

• BLEPS-1 — utility (Supply) vs device (Asset) fault taxonomy — the per-channel decomposition that CORA already got right.
• BLEPS-2 — PV availability + PV-to-Supply/Asset mapping.

Sources

• Deployed IOC + operator screens: 2bm-docs manual/item_025.rst "EPICS IOC" section, including screenshots of the top-row aggregate indicators on bleps_status.adl and the Trip / Fault / Warning FIFO stac
  ks with Reset buttons on the caQtDM full panel.
• Reset PVs: bleps.substitutions in the IOC dir defines A_FAULT_RESET and TRIP_RESET as binary-output records writing 1 (CLOSE) to the PLC A_Fault_Reset_EPICS / Trip_Reset_EPICS tags. Confirmed wit
  h caget against the running IOC.

/cc @xmap