526.1 State definitions

Define Idle, Guarded, Request, Execute, Fault. States anchor HVM bollard logic (342).

Idle is a quiescent, power-healthy baseline: no motion command is active and the lane is stable. Guarded asserts protection (e.g., bollards raised) and applies any fail-state philosophy. Request captures a user or system intent (credential, loop presence, event mode) awaiting authorization. Execute is controlled movement with safety devices & measures active. Fault is a safe, latched hold with clear operator guidance (536, 545).

Keep state names short and unique, and show them on the HMI (524) with color and text. Map each state to lighting/traffic aspects (353) and to SCADA/BMS reporting (533) so operators and remote systems see the same truth.

526.2 Entry/exit conditions

List sensors/authorizations required. Conditions safeguard the crash rated bollard lane (352).

Define explicit entry rules for each state, e.g., moving from Idle→Guarded requires “no vehicle in capture zone, no inhibit, power healthy.” From Request→Execute, require authorization hierarchy success and green safety checks (loops, photo-eyes). Exit rules reverse this cleanly and include coast/stop windows for mechanical drives (513) and hydraulic pressure decay (512).

Show each condition next to the I/O tag that proves it (523), including normal vs abnormal sense and debounce/filter times. Where approvals apply (airports, embassies), note any local authority requirements and keep a reference to SIRA Bollards (UAE).

526.3 Permitted transitions

Only safe paths allowed. Transitions stop unsafe HVM bollard jumps.

Draw a simple state transition diagram. Disallow direct Idle→Execute or Fault→Execute jumps; require Request and authorization checks in between. For Emergency Fast Operation (EFO) permit a pre-authorized fast path that still evaluates minimum safety gates (e.g., EFO-safe zone clear).

Transitions should include time-bound guards (e.g., “Authorize within 10 s or return to Idle”), and they should log who/what initiated the change (544), enabling a clear audit trail for SAT/witnessing (638).

526.4 Interlocks & inhibits

Map each prevent/allow rule (343). Interlocks protect crash rated bollard users.

Develop the allow/stop matrix in page 352 Interlock matrix and keep it 1:1 with the PLC code. Typical allows: “Lower allowed only if capture zone clear, authority OK, no EFO latch.” Typical inhibits: “Raise inhibited if vehicle present or manual bypass active.” Safety relays and STO should enforce hard stops independent of logic (343).

Document inhibit reasons on the HMI with clear language and a link to operator guidance (545). Store inhibit codes centrally for dashboards and alert routing (544).

526.5 Timeout/heartbeat rules

Handle stuck signals and comms loss (541). Heartbeats stabilize HVM bollard control.

Use a controller watchdog timer and a periodic heartbeat across critical links (535). Define motion timeouts (e.g., “Raise must complete within X s”) and sensor persistence (e.g., “Loop occupied for > 5 min → alert”). On comms loss to remote HMI/SCADA, keep the lane safe and surface a local alarm (533, 541).

Record timeouts in a Change-of-State log (544) and trend them as KPIs (542) to spot drift (e.g., increasing raise time → service task from 734).

526.6 Fault/latched states

Latched until verified reset (536). Latching avoids repeated crash rated bollard hazards.

Define a latched fault family: motion over-time, safety tripped during motion, EFO energy low, phase loss (514), over-temp (516). Latch these until a reset hierarchy step is completed and the original cause is proven cleared. Provide a latched message with the plain-language reason and a short operator hint (536, 545).

Distinguish Fault from Alarm: alarms notify but may auto-clear; faults block motion until reset. Log both with stable codes for SAT evidence (638) and for post-incident review (735).

526.7 Recovery sequences

Ordered, human-readable resets (632). Recovery speeds HVM bollard uptime.

Publish short, ordered runbooks: (a) verify safe local mode, (b) check power/UPS ride-through (518), (c) clear zone, (d) reset safety relay, (e) acknowledge HMI alarm, (f) test single motion, (g) return to normal. Keep steps visible on the HMI with role-based gating (operator vs engineer) and capture a signed reset record (737).

For EFO or emergency overrides (354, 547), include cooldown/accumulator checks (512) and a mandatory reset-to-normal checklist before reopening the lane. Link to 632 Power-On & Controls Health for first-power recovery.

526.8 Race-condition guards

Debounce and mutual exclusion. Guards keep crash rated bollard logic deterministic.

Prevent race conditions with (1) input debounce filters for loops/eyes, (2) mutual exclusion on motion commands (one lane/actuator at a time unless designed otherwise), (3) request queues with priorities and time stamps, and (4) “forbidden state” assertions in code that fail-safe if invariants break (535, 343).

When lanes run in sets, apply a priority matrix and log losers for audit. Use COS logs (544) to prove determinism during SAT soak tests (638).

526.9 Validation checklist

Tie rows to SAT steps (634–638). Checklist closes the HVM bollard loop.

Bind each state, guard, and interlock to a SAT step and witness point: diagram reference, PLC rung/function, I/O tag, expected HMI text, and pass/fail band. Cross-index to the Interlock Matrix (352) and the I/O List Template (523) so evidence is traceable. Include edge-case tests (brownout during Execute, comms loss in Request) and record operator recovery timing for KPI baselines (542).

Create a one-page checklist index inside the SAT pack and store a snapshot PDF under the project’s file index rules (911). Route defects through Nonconformance logs (719) and close with retest evidence (639).

526 State machine & interlocks Overview — FAQ