Signals, priorities, and fail-safe integration patterns.
Integrations must be clear and testable. Define signal lists and priorities for fire/BMS/SCADA so emergency modes and overrides are unambiguous (354, 355). Choose protocols (531, 533), set isolation/testing methods, and split responsibilities across trades (247). Provide documentation packs that align with ITP (714) and witness steps (638) to secure approvals without rework. 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.
346.1 Signal lists & priorities
Define fire, BMS, and SCADA priorities. Fire commands override local requests; HVM bollard safety wins.
Start with a single master priority matrix that shows how fire, security and local controls arbitrate requests. High-priority inputs—such as building fire alarm global raise/drop or emergency egress—must pre-empt local calls, timers, and queued requests in the lane controller/PLC. Use unambiguous states (e.g., Normal, Alarm, Manual Overridden) and log every change of state with a timestamp to protect the secure perimeter.
Priorities should cover conflicting orders (e.g., fire wants drop, access control wants raise). Fire wins; next, life-safety interlocks; then operator commands; finally scheduled automation. Capture this in the Integration Documentation and the Interlock Matrix so commissioning teams can verify behavior.
| Aspect | What matters | Where to verify |
|---|---|---|
| Priority order | Fire > life-safety > operator > schedules | Integration Documentation (539) |
| Determinism | No race conditions during transitions | Control Logic (342) |
| Audit trail | Timestamped events/counters | Remote Logging (541) |
346.2 Fire alarm behavior
Set global raise/drop and egress protection (532). Behavior must not compromise a crash rated bollard perimeter during evacuation.
Agree early whether a confirmed building alarm triggers global drop (to clear vehicle routes for responders) or global raise (to lock down the perimeter). Many mixed-use sites choose drop on public routes but hold raise on sensitive perimeters—document the split by lane ID. When people egress across a lane, hold bollards lowered and disable automatic re-raise until a supervised reset is performed by facilities or security.
Interface with the Fire Alarm Control Panel per Fire Alarm Interface (532). Use supervised inputs, debounce, and a health ping to detect broken lines. For UAE sites, confirm the strategy with authorities; add a concise note and link to SIRA Bollards (UAE).
346.3 Emergency modes & overrides
Document who can trigger EFO and how it interlocks (354, 343). Overrides remain auditable to protect HVM bollard intent.
Define EFO, manual bypass keys, and modes in the safety design. EFO must respect Safety Circuits (343) and stop if an active person-in-gap signal is present. All overrides should latch alarms, generate an operator prompt to acknowledge, and auto-expire after a defined window.
Record authority to operate (who/when/why) with user IDs from the Access Control/CCTV coordination (534). If PSIM/SCADA issues overrides, require dual confirmation or role-based restrictions.
346.4 Status/health reporting
Expose health, counters, and alarms (541–542). Clear points help monitor crash rated bollard lanes.
Publish discrete bollard states (Up/Down/Moving/Fault), lane interlocks, KPI counters, and maintenance due flags. Use summary “lane healthy” plus granular fault codes to speed triage. Counters feed dashboards and alerts in KPI & thresholds (542) and Remote fault logging (541).
346.5 Protocols & wiring
Choose dry contacts or Modbus/BACnet (531). Provide isolation and surge protection (514) for HVM bollard panels.
Simple sites can use volt-free contacts for Alarm In and Status Out. Larger estates benefit from fieldbus or supervisory integration—e.g., Modbus TCP to SCADA or BACnet/IP to BMS—as covered in Interface Types (531) and SCADA/BMS Signals (533). Whichever path you choose, specify galvanic isolation, surge protection, screened cabling, and clear Electrical Supply & Protection (514).
346.6 Isolation & testing
Include test switches and permits (723). Isolated tests prevent accidental crash rated bollard motion.
Add a lockable Test/Isolate switch at the controller so fire/BMS/SCADA inputs can be simulated without energizing actuators. Require PTW (723), LOTO, and a witnessed reset before returning to service. Maintain a loop/signal simulator pack for safe SAT rehearsals (see Loop & Sensor Proving (633)).
346.7 Responsibility boundaries
Split IO/logic ownership across trades (247). Boundaries reduce HVM bollard commissioning disputes.
Draw a RACI that separates: (a) device layer (bollards, loops, photo-eyes), (b) controller logic and safety, (c) supervisory integration (BMS/SCADA/PSIM). Trade Coordination (247) should define who owns cables, terminations, addressing, and who raises RFIs if a third-party system changes point names or alarm IDs. Publish a single source-of-truth points list.
346.8 Documentation packs
Supply ICDs, points lists, and sequences (539). Packs accelerate approvals for crash rated bollard integrations (717).
Include an Interface Control Document, interlock matrix extract, points list with data types/ranges, sequence of operations, P&IDs/schematics, and SAT scripts. Submit alongside ITP (714) and Authority Submittals (717). Keep revision control aligned with Change Control & Versioning (537).
346.9 Witness & sign-off steps
Map interface tests to SAT (638). Witnessed results prove HVM bollard behavior under fire/BMS control.
Build your SAT around the documented priorities and sequences. Prove both Alarm → Action and Reset → Normal paths, including failure injection (broken cable, lost network, power dips). Capture evidence per SAT / Witness Procedure (638) and archive in the handover set with Handover Pack Index (736).
Related
External resources
346 Fire/BMS/SCADA interfaces for HVM Bollards — FAQ
What’s the correct priority order between fire, BMS/SCADA, and local controls?
Fire commands have the highest priority, followed by life-safety interlocks, then operator/local controls, and finally scheduled automation. This ensures evacuation and responder access are never blocked by routine operations.
Should a building fire alarm drop or raise automatic HVM bollards?
It depends on the perimeter strategy. Public routes often drop to allow responders, while sensitive perimeters may raise to lock down. Decide by lane, document it, and prove both alarm and reset paths during SAT.
When do I choose dry contacts versus a protocol like Modbus or BACnet?
Use dry contacts for simple, low-point integrations. Choose Modbus/BACnet for estates that need rich status, counters, and alarms at scale. In all cases, specify isolation, surge protection, and screened cabling.
How do we test integrations safely without moving bollards?
Provide a lockable Test/Isolate switch, a signal simulator, and enforce PTW/LOTO. Run witnessed SAT steps that simulate alarms, network loss, and resets, then record evidence in the handover pack.