Define fail-safe vs fail-secure and when to use.
Emergency fail behaviour is not a guess—agree it, design it, and prove it. This page defines fail-safe vs fail-secure, maps typical failure cases (power, sensors, communications), and ties each choice to approvals and operations so HVM bollard intent is preserved. See this section and the chapter hub for context. For UAE authority projects, also see SIRA Bollards (UAE) for approval nuances.
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.
355.1 Definitions (plain)
Fail-safe: default to open; Fail-secure: default to closed. Agree which protects the HVM bollard site best (233, 821).
In simple terms, fail-safe means the lane opens when something fails, while fail-secure means it stays secured. The correct default depends on purpose, users, and context set in emergency/service access and vehicle-access lanes.
Choose once, write it down, and reflect it in controls, hydraulics/electromechanics, and physical provisions so the whole system behaves consistently through faults.
| Aspect | What matters | Where to verify |
|---|---|---|
| Performance | Tested system (bollard + footing) | Global crash ratings |
| Operations | Duty cycles, fail-state, safety | Installation Guide |
355.2 Choosing fail philosophy
Use risk context (371–374). Public egress may prefer fail-safe; perimeter defense may require fail-secure around a crash rated bollard boundary.
Anchor the choice in a purpose-led risk picture: public squares and evacuation routes trend fail-safe; critical perimeters trend fail-secure to preserve protection zones. Tie the decision to Building Security vs Public Safety needs.
Record the rationale in the FDS/SAP and the Risk Assessment, and mirror it in the interlock matrix so operators and reviewers see one source of truth.
355.3 Power loss behavior
Define ride-through and what each unit does if power drops (518). Behavior must not widen HVM bollard gaps (232).
Specify minimum UPS/autonomy and explicit autonomy for controls and signaling; state ride-through targets for brief dips. In longer outages, define whether the bollards drop to safe (open) or secure (closed) and how arrays avoid creating a wider clear-gap than allowed.
Reference Power Failure Modes (518) and ensure the policy is testable during commissioning and SAT.
355.4 Sensor failure handling
Loss of beam/loop → inhibit motion and alarm (344–345, 536). Safe handling prevents collisions at a crash rated bollard lane.
If a loop or beam fails, movement must inhibit, a latched alarm must raise, and a safe recovery path must be shown on the HMI. Capture fallback strategies (e.g., stewarded mode, reduced speed) and add them to the Alarm Philosophy (536).
Prove detection integrity in Loop & Sensor Proving (633) and log settings in the handover pack.
355.5 Communication loss handling
Timeouts, local authority, and safe local mode (521, 535). Comms loss should not create unsafe HVM bollard states.
Define controller timeouts, who has local authority (521), and when a safe local mode is permitted if networks fail (link to Networks & Cyber Basics (535)). Use health pings (541) to detect silent failures and trigger fail indication.
355.6 Manual release procedures
Provide physical releases and checklists. Releases must not defeat crash rated bollard protection without authorization (717).
Document where releases live, who can use them, and the reset-to-normal checklist. Use Authority Submittals (717) to fix permissions, and add training steps in the Client Training Plan (737). Avoid designs that allow bystanders to defeat a secure perimeter.
355.7 Testing scenarios
Script brownout, phase loss, and PLC/HMI faults (632, 638). Tests prove HVM bollard resilience.
Include short dips, prolonged brownouts, single-phase loss, control reboots, and field-device disconnects in the commissioning plan. Execute in Power-On & Controls Health (632) and witness via SAT (638), logging evidence for approvals.
355.8 Documentation wording
Include explicit clauses in specs (433). Wording fixes expectations for a crash rated bollard site.
Write short, testable statements, e.g., “On mains failure > 5 minutes, automatic bollards shall move to the fail-secure position and maintain clear-gap compliance across the array.” Cross-reference Specification Template (433), the interlock matrix, and ITP hold/witness points.
355.9 Stakeholder agreement
Sign off with client, ops, and authorities (131, 717). Agreement prevents disputes during HVM bollard incidents.
Capture decisions in the RACI and meeting minutes, route for sign-off via Authority Submittals (717), and publish into the Handover Pack (736). This avoids later arguments about what the system “should have done.”
Related
External resources
355 Fail-safe/secure states for HVM Bollards — FAQ
What’s the practical difference between fail-safe and fail-secure for bollards?
Fail-safe defaults the lane open (bollards down) on fault or power loss to protect egress; fail-secure defaults closed (bollards up) to preserve the secure perimeter. Choose based on the site’s purpose and document it in the FDS/spec.
How do we prevent unsafe gaps during a power cut?
Set a power policy with UPS ride-through for controls, define the fail position, and verify that arrays maintain clear-gap limits. Test in commissioning (632–636) and witness at SAT (638).
What happens if a safety sensor fails?
Movement is inhibited, alarms latch, and a guided recovery is shown on the HMI. The interlock matrix should specify this path, and the alarm philosophy should define notifications and escalation.
Who can operate a manual release, and how is it controlled?
Only authorized roles defined in the Authority Submittals/Training Plan. Releases are documented, physically secured, and include a reset-to-normal checklist to restore safe operation.