Modes, states, sequences, timers, and feedbacks.
Control logic turns hardware into a safe system. Define states, transitions, and the Request→Authorize→Execute chain so HVM bollards behave predictably in normal, maintenance, and emergency modes (525, 355). Add watchdogs, latched faults, and clean recovery paths. Log events for KPIs (542) and verify logic through the interlock matrix (352) and SAT procedures (634–638). Include one-sentence context that naturally links upward to the parent hubs (this section and the chapter hub). Add SIRA context with a link to SIRA Bollards (UAE) when relevant. Link installation pages only if helpful: What to Expect and Installation Guide.
Important: This is a general guide. For live projects we develop a tailored
Method Statement & Risk Assessment (MS/RA) and align with authority approvals (e.g., SIRA) where in scope.
342.1 States & transitions
Define Idle, Request, Authorize, Execute, Fault, and EFO. Clear states keep automatic HVM bollard behavior consistent with the interlock matrix (352).
A disciplined state model (see state machine) makes crash-rated lanes predictable. Each transition must reference prerequisites: valid credential, clear mode, and no active faults. Emergency Fast Operation (EFO) is modelled as a privileged, time-bounded state.
Keep transitions atomic: a single input leads to one next state. Avoid “hidden” parallel paths that can re-enter Execute from Fault. Tie each transition to a row in the interlock matrix and tag with the exact inputs (e.g., Loop-A clear, photo-eye clear, stop pressed = false).
| Aspect | What matters | Where to verify |
|---|---|---|
| Performance | Transitions are single-step, no skipped checks | Crash-Rated standards overview |
| Operations | Modes, fail-state, indicators | Installation Guide |
342.2 Mode of operation (Auto/Manual)
Document permissions and indicators (525). Modes prevent unsafe overrides around a crash rated bollard lane.
Modes of operation must be latched with visible feedback on the HMI and reported to BMS/SCADA. In Manual, require LOTO and a spring-return “deadman” control. In Auto, suppress unsafe commands if any safety device is open.
342.3 Request→Authorize→Execute chain
Gate movement by credentials, safety inputs, and timers (534, 343). Chain enforces predictable HVM bollard actions.
The chain separates intent from action: Request (e.g., ACS/ANPR) → Authorize (all interlocks true; queue clear) → Execute (drive moves the automatic bollard). Failed authorization cancels with a clear message and no movement. Tie timeouts (below) to each phase.
342.4 Timeouts & watchdogs
Add deadman, heartbeat, and stall timers. Timeouts stop stuck automatic HVM bollard posts safely.
Implement (a) request timeout (no credential retry loop), (b) authorize window (interlocks must be true within N seconds), (c) movement timeout (no position change ⇒ safe stop). A controller heartbeat and device-level watchdog relay should drop power to motion on loss of scan/comms. Surface these as distinct alarms (not a generic “fault”).
342.5 Fault detection & latching
Detect sensor/drive faults and latch until reset (536). Latching avoids unsafe oscillations near a crash rated bollard.
Classify alarms (Safety trip, Drive fault, Sensor disagree, Position unknown). Safety trips (signalling plus stop) are latched and require a supervised reset sequence. Non-safety faults can auto-clear only after a healthy cycle. Expose cause/help text on HMI and publish to telemetry (541).
342.6 Reset & recovery paths
Define reset buttons, sequences, and post-fault checks. Recovery restores HVM bollard availability quickly (632).
Require a local reset button plus role-based remote reset. The sequence: acknowledge → prove interlocks healthy → test jog in Manual → return to Auto. After power-loss, force a homing/position reconcile before accepting new Requests. Document steps in the Power-On & Controls Health checklist.
342.7 Alarms & event logs
Log commands, faults, EFO, and KPIs (541–542). Logs prove automatic HVM bollard performance to reviewers (444).
Event logs should capture: command source, granted/denied, interlock snapshot, start/finish timestamps, cycle time KPI, and reason codes. Count health pings and failed heartbeats (541). Store enough history to support audits and the evidence & documentation trail; export to an operational dashboard.
342.8 Edge cases & race conditions
Guard against double-requests, mode flips, and comms blips (518, 535). Guards keep a crash rated bollard lane safe.
Common races: two credentials within one authorize window; Manual selected during Execute; comms dropout mid-travel. Fixes: queue requests FIFO; inhibit mode changes while moving; on comms loss, freeze state and time-out to safe stop. For power failure (518), define a deterministic fail-safe/secure rule (e.g., fail-secure down for emergency egress lanes).
342.9 Verification approach
Map each logic row to SAT steps (634–638). Verification closes the loop for HVM bollard acceptance.
Use the interlock matrix (352) as the test script: each row becomes a SAT step with pre-conditions, action, expected indicators, and pass criteria. Include intrusion/obstruction tests, duty/performance, and KPI thresholds. Capture evidence per the evidence capture standards and file in the submission pack (938). Where projects are within the UAE, note any reviewer requests tied to SIRA acceptance.
Related
External resources
- NPSA — Hostile Vehicle Mitigation guidance
- FEMA 426 / DHS — Reference Manual to Mitigate Potential Terrorist Attacks
- ASIS — Security Risk Assessment Standard
342 Control logic for automatic HVM Bollards — FAQ
What is the Request→Authorize→Execute chain and why is it mandatory?
It’s a three-step gate that separates intent from motion. A user or system requests movement, the controller authorizes it only if credentials and all safety interlocks are healthy, and the drive then executes the movement within time limits. This prevents unsafe motion from bad inputs or stale conditions.
How should Auto vs Manual modes be enforced on site?
Latch the selected mode, show it clearly on the HMI, and report it to BMS/SCADA. In Manual, require LOTO and deadman controls. In Auto, block commands whenever a safety device is open or an alarm is latched.
What faults must latch, and what can auto-clear?
Safety-related trips (e.g., photo-eye open during travel, E-stop pressed) must latch and require a supervised reset sequence. Non-safety faults (e.g., transient comms loss) may auto-clear after a successful health check and cycle, provided no safety inputs remain open.
How do we verify the control logic during SAT?
Convert each interlock matrix row into a SAT step with defined pre-conditions, operator action, indicators, and pass criteria. Include intrusion/obstruction trials, duty tests, KPI checks, and evidence capture. File all results in the submission pack.