BLEPS-1: utility-level vs device-level fault classification

[decarlof]

BLEPS-1: utility-level vs device-level fault classification

Title: BLEPS-1: utility-level vs device-level fault taxonomy at 2-BM (Supply vs Asset)

Body:

Question

Which BLEPS faults are utility-level (vacuum via IP/IG/GV, cooling-water via the Flow channels) versus tied to a specific device?

CORA assumes utility faults map to Supply and device faults map to Asset condition.

Answer

The assumption is correct. Walking the deployed IOC's fault taxonomy (from bleps.substitutions in the 2bmBLEPS IOC, and cross-referenced against the fault-flag list in 2bm-docs manual/item_025.rst),
every latching fault falls cleanly into one of the two buckets.

Utility-level (→ Supply condition)

Shared utility inputs, not tied to one Asset. Each channel maps to a Supply that potentially feeds many Assets.

Fault channel	Supply	Notes
FLOW1_TRIP	Filter + upstream Slits cooling water	trip if flow < setpoint
FLOW2_TRIP	M1 Mirror + DMM cooling water	serves both optics
FLOW3_TRIP	Window 1 + Missteer Mask cooling water
FLOW4_TRIP	Windows 2 & 3 cooling water
FLOW5_TRIP	White Beam Mask + SBS Shutter cooling water
FLOW6_TRIP	Station B entrance-slits cooling water
FLOW7_TRIP	Window 4 (Station B) cooling water
FLOW8_TRIP	Station B Photon Stop cooling water
VS1_TRIP .. VS7_TRIP	Vacuum sections 1..7	trip on vacuum-section pressure fault
IP1_STATUS / IP1_WARNING .. IP7_STATUS / IP7_WARNING	Vacuum (per ion-pump controller)	pump health signals from ion-pump controllers
IG1_STATUS / IG1_WARNING .. IG8_STATUS / IG8_WARNING	Vacuum (per ion-gauge controller)	gauge health signals from ion-gauge controllers
TEMP1_TRIP .. TEMP3_TRIP	M1 mirror-tank thermocouples (Lower / Middle / Upper)	over-temperature trips
COMMUNICATIONS_FAULT	BLEPS-PLC ↔ EtherNet/IP gateway	infrastructure-level, not an Asset fault
POWER_SUPPLY_1.WARNING, POWER_SUPPLY_2.WARNING, OR_MODULE.WARNING	BLEPS PLC power / redundancy	infrastructure-level

Cooling-water and vacuum-section boundaries map to physical piping / vacuum-space topology, not to a specific Asset. Ion-pump / ion-gauge health is a per-instrument utility datum (the pump is a Supply-level de
vice from the beamline's Asset perspective).

Device-level (→ Asset condition)

Faults that are properties of a specific Asset — each fault refers unambiguously to one component and cannot be shared across Assets.

Shutter Assets (BIV, FES, SBS — three separate shutters):

Fault	Asset
BIV_FAIL_TO_CLOSE	Beamline Isolation Valve (BIV)
FES_FAIL_TO_CLOSE	Front-End Shutter (FES)
SBS_FAIL_TO_CLOSE	Station-B Shutter (SBS)

Each shutter also has a _PERMIT output (BIV_PERMIT / FES_PERMIT / SBS_PERMIT) that reflects the interlock chain's command to the shutter. Not a fault, but a per-Asset controllable output.

Gate-valve Assets (GV1, GV2, GV3 — three separate valves along the beam path):

Each of the three valves publishes an overall GVx_FAULTED plus 9 per-cause sub-flags (GVx_FAULT_*):

Sub-fault	Meaning
GVx_FAULT_BOTH_SWITCH	Both limit switches active simultaneously (physically impossible → wiring / switch fault)
GVx_FAULT_OPENED_SWITCH	Opened-limit switch alone in an inconsistent state
GVx_FAULT_CLOSED_SWITCH	Closed-limit switch alone in an inconsistent state
GVx_FAULT_FAIL_TO_OPEN	Motion command issued, no opened-limit response within timeout
GVx_FAULT_FAIL_TO_FULLY_OPEN	Reached partial-open state but did not complete
GVx_FAULT_FAIL_TO_CLOSE	Motion command issued, no closed-limit response within timeout
GVx_FAULT_FAIL_TO_FULLY_CLOSE	Reached partial-close state but did not complete
GVx_FAULT_BEAM_EXPOSURE	Beam present while valve mid-motion (interlock violation)
GVx_FAULT_NO_SWITCH	No limit switch reporting at all (wiring / power issue)

All are properties of the specific gate valve Asset. Each valve also has GVx_EPICS_OPEN / GVx_EPICS_CLOSE write PVs (per-Asset commandable outputs).

Boundary conditions worth flagging

• A_FAULT_EXISTS, A_TRIP_EXISTS, WARNING_EXISTS are neither utility nor device — they are system-level aggregate booleans ("any fault / trip / warning latched anywhere"). See BLEPS-3 for how thes
  e map into CORA's model.
• Fault / trip / warning FIFOs (Faults.Number[0..9] with timestamp fields, ditto Trips and Warnings) are historical event records, not conditions. They belong to the BLEPS system as a whole, not any sing
  le Supply or Asset.
• A_FAULT_RESET, TRIP_RESET are commandable system-level actions, not conditions. See BLEPS-3.

Cora impact

• CORA can proceed with the assumed mapping (utility → Supply, device → Asset). Full per-channel PV list to feed into the model is in 2bm-docs manual/item_025.rst "BLEPS PV inventory" section, split by cla
  ss (FIFOs / Faults / Trips / Warnings / Info / Flows / Temps / Inputs / Outputs / Display / EPICS_Inputs).
• One nuance: gate-valve per-cause flags multiply the fault-flag count per Asset (9 sub-flags each). CORA can either roll them up into a single "GVx faulted" condition (and expose the sub-flags for diagnostics
  ), or model each sub-flag as its own condition — CORA-side design choice.

Related

• BLEPS-2 — PV readability + concrete PV-to-Supply/Asset mapping for the specific CORA-referenced tags.
• BLEPS-3 — system-level aggregate state (which does not fit either the Supply or Asset axis).

Sources

• IOC substitutions file: /net/s2dserv/xorApps/epics/synApps_6_3/ioc/2bmBLEPS/iocBoot/ioc2bmBLEPS/bleps.substitutions (authoritative for the fault definitions).
• Deployed PV list: dbl-all.txt in the same directory (385 PVs under 2bmBLEPS:BLEPS:* plus 214 iocAdminSoft admin PVs).
• Documentation: 2bm-docs manual/item_025.rst "Physical assignments at 2-BM" (utility / device mapping) and "BLEPS PV inventory" (per-class PV tables).
• Support-team communication: EPICS integration completed 2026-07-14.

/cc @xmap