Turn operation into data you can trust. Define the exact points list for status, alarms, counters, and health pings so HVM bollard availability is measurable (541–542). Plan historians/trends, comms-loss behavior, and basic cyber/ACL rules (535). Align FAT/SAT activities with BMS teams (638) and provide O&M visualizations (544) that help operators sustain crash rated bollard performance and service levels (738, 842). 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.
533.1 Points list
Publish exact tags and data types. Precision keeps HVM bollard dashboards consistent (544).
Start with a master I/O list and add a SCADA/BMS mapping column for each tag (read/write, datatype, engineering units, scale, and update rate). Use a clear tag naming convention so integrators can filter by site, lane, or device. State defaults (e.g., “0=OK, 1=Alarm”) and include quality bits, timestamps, and source @id for audit.
Group points by function: lane status, mode, safety devices & measures, command authorisations, faults/alerts, and maintenance. Cross-reference each tag to the interlock matrix (352) so nothing is orphaned during commissioning.
For analogs (e.g., hydraulic pressure, enclosure temperature), declare ranges, deadbands, and limit thresholds in the same sheet. Keep a version column tied to change control & versioning (537).
| Aspect | What matters | Where to verify |
|---|---|---|
| Performance | Tested system (bollard + footing) | Crash ratings overview |
| Operations | Duty cycles, fail-state, safety | Installation Guide |
533.2 Status & alarms
Expose lane/mode/health plus alarm classes (536). Visibility preserves crash rated bollard availability.
At minimum, publish lane availability, current mode, command enable, safety chain health, and alarm philosophy class (e.g., critical trip vs advisory). Align alarm text with HMI messages for consistency and add latched vs transient flags to reduce noise.
Provide priority classes, escalation hints, and an operator recovery hint per alarm. Record first-in alarm and clear timestamps to support root cause analysis and KPI calculations.
533.3 Counters & KPIs
Send ops/hour, cycle time, MTBF (542). Data proves HVM bollard value.
Publish counters for raises/lowers, KPI ops/hour & cycle time, aborted moves, and MTBF. Include runtime accumulators and last-service timestamp so the BMS can trigger maintenance tickets before availability drops.
Define aggregation windows: 15-min, hourly, daily, and monthly rollups. Align thresholds with the KPI set & alert thresholds (542), then visualise on the operational dashboard (544).
533.4 Health/heartbeat
Regular pings detect comms loss (541). Heartbeats protect crash rated bollard monitoring.
Implement a health ping per panel and per lane device. Include a monotonic sequence number and time source (e.g., NTP aligned) so missed beats and clock drift are obvious to the BMS/SCADA.
Expose panel-internal watchdog status and last successful poll time. For remote links, add round-trip time and packet loss as diagnostic tags to help distinguish device faults from network issues.
533.5 Trend & historian
Trend energy, temperature, and timings. Trends drive HVM bollard maintenance (543).
Trend enclosure temperature, supply voltage, motor/HPU currents, raise/lower cycle times, and EFO energy readiness. Store raw at 1–5 s where practical, decimate to 1–5 min for long-term history. Normalise tag names so trends remain comparable across sites and product families.
Use trend alarms (rate-of-change, persistence) to predict failures—then route them to condition monitoring & predictive maintenance (543). Confirm historian retention, backup, and privacy policies with the client’s IT/OT teams.
533.6 Comms loss handling
Define buffer/retry and degraded modes. Handling prevents spurious crash rated bollard alarms (521).
Specify retry/back-off and data buffering at the controller/gateway. On communication loss, publish a single consolidated alarm and suppress secondary “symptoms.” Define safe behaviour in degraded modes: e.g., hold last safe state, raise local banner, and log a local event for post-mortem.
For architecture choices (centralised vs distributed), document how each segment behaves on isolation; reference control architecture (521) for fallback rules and authority layers.
533.7 Cyber/ACL basics
Restrict writes; segment networks (535). Cyber hygiene secures HVM bollard data.
Expose read-only status by default and strictly limit writes via network & cyber basics (535): VLAN segmentation, role-based access, and allow-lists on protocol gateways. Disable unused services, set unique credentials, and log all changes with user, time, and before/after values.
Document ports/protocols for Modbus/BACnet or PSIM integration, plus gateway firmware version and checksum in the submission pack.
533.8 FAT/SAT with BMS
Witness points end-to-end (715, 638). Joint tests validate crash rated bollard reporting.
Pre-agree a joint witness script: verify tag values, alarm priorities, KPI counters, time synchronisation, and historian ingestion. At FAT, prove mappings and message formats; at SAT, repeat with field wiring, witness procedures (638), and client BMS operators present.
Capture evidence (screens, exports, logs) per evidence capture standards (716). Note any authority specifics; in the UAE add a brief SIRA note and link to SIRA Bollards (UAE).
533.9 O&M visualization
Provide role-based views and exports (544). Visualization helps run HVM bollard sites.
Design role-based dashboards: operations (live lanes, queues, alarms), maintenance (health tiles, overdue services), and management (availability, incidents, SLA performance). Provide CSV/JSON exports and a reporting pack (544) schedule so stakeholders see consistent numbers monthly.
Use clear colour semantics and descriptive anchors for drill-downs. Mirror nomenclature with the HMI and O&M so training and on-the-job workflows align.
