What to log, poll intervals, and alerting basics.
Build observability into every automatic HVM bollard lane. Define what to log (states, faults, EFO events), how to transmit heartbeats, and which counters support KPIs (542) and maintenance planning (734, 842). Fault classes should mirror alarm philosophy (536). Choose connectivity that survives site conditions (535, 347) and set retention/privacy rules that flow into SCADA/BMS reporting (533) and SLA commitments (738). This page sits under this section and the chapter hub. For UAE authority reviews where in scope, see SIRA Bollards (UAE). Optional installation context: 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.
541.1 What to log remotely
States, faults, EFO events, mode changes, counters, and power anomalies. Logs prove HVM bollard behavior and support crash rated bollard audits (525, 518).
Start with a concise Change-of-State (COS) log capturing lane states, mode transitions, interlock results, and latched alarms. Record EFO initiations with operator ID, reason, and outcome, plus safety device outcomes (e.g., loop/photo-eye inhibits). Include power events (phase loss, brownouts), local/remote commands, and fail-state decisions for auditability.
Tag each log point with a consistent I/O list name and alarm priority (see Alarm Philosophy). For reporting, stream summaries to historians used by SCADA/BMS.
| Aspect | What matters | Where to verify |
|---|---|---|
| Performance | Tested system (bollard + footing) | Global crash ratings |
| Operations | Duty cycles, fail-state, safety measures | Installation Guide |
541.2 Connectivity options
Hardwired LAN, fiber, or LTE with VPN. Choose links that keep HVM bollard data reliable without exposing crash rated bollard controls (535).
Prefer site VLAN over dedicated LTE where feasible; use fiber where distance/EMC demands it. For remote sites, LTE with an IPsec VPN plus ACL whitelisting and jump-server access reduces attack surface. Define comms-loss behavior (fail-safe local mode, buffered logs), and align with Networks & Cyber Basics.
541.3 Heartbeat health
Send periodic pings with timestamps and firmware IDs. Heartbeats reveal silent HVM bollard failures across crash rated bollard lanes (537).
Implement a lightweight health ping from each lane controller containing time (NTP-synced), firmware/build ID, error flags, and queue depth. Typical intervals: 10–60 s to SCADA; 1–5 min to central cloud. Alarm on missed pings (e.g., 3 consecutive), excessive jitter, or rising retransmits; route to SIEM if security-relevant.
541.4 Counters & reset rules
Track ops/hour, cycles-to-service, EFO count; reset only after sign-off. Counters drive HVM bollard maintenance and crash rated bollard KPIs (542, 734).
Log operations per hour, raise/lower cycle time, aborted cycles, obstruction reversals, and EFO activations. Derive next-service estimates and MTBF from counters, and expose them on dashboards (see 544). Resets require an engineer role and a signed maintenance record; never auto-reset on reboot or firmware change.
541.5 Fault classification
Group by safety, performance, and communication. Clear classes focus HVM bollard triage and crash rated bollard risk (536).
Use three buckets: (a) Safety (safety relay trips, loop/photo-eye faults), (b) Performance (slow cycle, thermal alarms, pressure anomalies), and (c) Comms (loss, stale data, time sync drift). Map each to priorities, latching rules, and operator recovery hints per the Alarm Philosophy. Keep a short list (<7) to avoid alarm floods.
541.6 Alerting & notifications
Route SMS/email/SCADA alerts with priorities (533). Alerts shorten HVM bollard downtime and protect crash rated bollard availability.
Route P1 safety faults to on-call via SMS/app plus control-room annunciation; send P2/P3 to email and daily digest. Integrate with SCADA/BMS Signals & Reporting and expose an escalation path and response window aligned to the Service Levels & Availability page. Log Mean Time to Acknowledge (MTTA) and repair (MTTR) for KPI tracking (542).
541.7 Data retention
Define local buffer and central archive durations (938). Retention preserves HVM bollard evidence for crash rated bollard reviews (444).
Typical policy: device buffer 7–30 days; site historian 6–12 months; central archive 2–5 years depending on risk. Document what is stored (logs, counters, trends) and where (on-prem vs cloud) in the Submission-Pack Guidance and final archive plan (Final Archive & Retrieval).
541.8 Privacy/compliance
Anonymize plates/users where captured (534). Compliance maintains HVM bollard trust.
Where ANPR/credentialing data is linked to events, mask or hash identifiers in telemetry and restrict access via roles and ACLs. Retain only what’s necessary for safety and maintenance, document lawful basis, and reflect this in the Access Control/CCTV Coordination plan. For UAE projects, confirm any authority-specific retention or access requirements (see SIRA hub).
541.9 Sample dashboards
Provide lane tiles, trends, and fault funnels (544). Dashboards turn crash rated bollard data into action.
Design clean operator tiles per lane: state, mode, last raise/lower, counters to service, and health ping age. Add trends for cycle time, faults/day, and comms latency. Include a fault-funnel view (by class → by lane → by cause) for prioritization, and a maintenance widget fed by counters (see Operational Dashboards & Reporting).
Related
External resources
- NPSA — Hostile Vehicle Mitigation (overview)
- FEMA 426 / DHS — Reference Manual to Mitigate Potential Terrorist Attacks
- ASIS — Security Risk Assessment Standard
541 Remote Fault Logging, Counters, Health Pings — FAQ
What should an HVM bollard system log remotely?
At minimum: state/mode changes, interlock outcomes, latched alarms, EFO initiations, obstruction reversals, cycle times, and power events (phase loss, brownouts). Tie every point to your I/O list and alarm priorities for consistent reporting.
How often should health pings be sent?
Use 10–60 seconds to site SCADA and 1–5 minutes to any central cloud. Alert if three consecutive pings are missed, if jitter spikes, or if latency exceeds your response window.
Which counters matter most for maintenance and KPIs?
Operations per hour, raise/lower cycle time, aborted cycles, obstruction reversals, and EFO count. These feed MTBF/MTTR and cycles-to-service planning; resets should require engineer sign-off.
How do alerts integrate with SCADA/BMS without creating alarm floods?
Route P1 safety alerts to on-call SMS/app plus control-room annunciation; send lower priorities to email/digest. Keep fault classes short (safety/performance/comms) and align latching, shelving, and escalation with your Alarm Philosophy.