Alarm classes, latching, escalation, and silencing.
Alarms should drive action, not noise. Define classes and priorities, annunciation rules, and latching/reset behavior aligned with control logic (342) and interlocks (352). Reduce nuisance alarms through detection quality (344–345) and clear operator workflows (524, 545). Link reporting to KPIs (542) and schedule drills/testing (547). Regular review/tuning protects HVM bollard availability and reviewer confidence (444). This page sits within this section and the wider Automatic HVM Bollard Controls hub.
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. See our UAE note under Emergency Modes & Incident Response.
536.1 Alarm classes
Classify safety, process, and advisory. Classes focus HVM bollard operators.
Start by separating safety devices & measures events from process and advisory. Safety class alarms relate to states that could endanger people or defeat security intent (e.g., EFO faults, gate/bollard conflict). Process alarms cover degraded operation that affects throughput or availability. Advisory alarms inform operators about low-severity conditions (trends, maintenance due) that don’t require immediate intervention.
Each class should define: purpose, operator obligation, time-to-acknowledge, escalation behavior, and evidence requirements for close-out. Map classes to the interlock matrix and to the remote fault logging model so that alarms, inhibits, and latched alarms are consistently recorded.
| Aspect | What matters | Where to verify |
|---|---|---|
| Safety class | Immediate action; clear reset hierarchy | Control Logic |
| Process class | Uptime impact; timed escalation | Operational Dashboards |
| Advisory | Awareness; trend to KPI | Crash Ratings (context) |
536.2 Priorities & escalation
Route by severity/time. Priorities preserve crash rated bollard safety.
Define a small, memorable set of priorities (e.g., P1–P4). P1 inhibits unsafe actions or signals a security-critical condition; P2 affects service with tight time windows; P3/P4 are routine. For each priority, specify acknowledgement target (e.g., MTTA), response window, and the escalation path (HMI banner → SMS/team chat → duty manager). Escalation should be time-based and cancel automatically on resolution to avoid duplicate notifications.
Integrate priorities with the SCADA/BMS tags and alarm routing (e.g., email/SMS gateways, on-call rotas). Capture escalation events in the KPI set so recurring P2s at a site trigger a problem management review.
536.3 Annunciation rules
Consistent tones, colors, and messages (353). Rules reduce HVM bollard confusion.
Annunciation covers what operators see and hear. Standardize the alarm banner, status tiles, and audible cues. Keep colors consistent with Safety Signalling—avoid “legacy mapping” drift. Messages must be short, unique, and actionable: “Lane 2: Bollard 3 travel timeout — check photo-eye; see Reset step (b)”. Provide clear inhibit indicators and an audible silence that mutes sound without clearing the alarm.
Where integrations exist (fire, BMS, access control), align text and codes with those systems to reduce handover friction during incidents and acceptance testing.
536.4 Latching & reset
Latch critical faults with guided reset (342). Latching prevents repeat crash rated bollard hazards.
Use latching for hazards that must not self-clear (e.g., bollard/vehicle obstruction, EFO hydraulic faults). Present a guided reset-to-normal checklist on the HMI so operators confirm steps (area safe → clear obstruction → verify induction loop state → test cycle). Combine a local physical reset (panel key) with role-based software reset to enforce the reset hierarchy.
Document latching behavior in the I/O list and in SAT scripts. First-out capture (the initial cause that triggered downstream alarms) helps avoid chasing symptoms.
536.5 Nuisance alarm reduction
Tune detectors, debounce inputs (344–345). Reduction increases HVM bollard trust.
Nuisance alarms erode confidence and lead to silenced HMIs. Reduce them by improving detection quality and filtering: (a) apply debounce times on chattering inputs; (b) use loop presence vs pulse modes appropriately; (c) shield and separate noisy cables; and (d) set persistence windows on trend-based alarms to prevent “false peaks.”
Track nuisance rates per input and per lane in the historian. Any point exceeding the threshold for two consecutive review cycles becomes a corrective action with an owner and due date.
536.6 Operator workflow
Provide prompts and checklists (545). Workflows standardize crash rated bollard response.
Design the workflow so a trained operator can: see the top issue, acknowledge responsibly, act with guided steps, and log the outcome. Embed prompts (photos, diagrams, “where to stand”) and a short operator recovery hint on each alarm. Provide one-click access to Operator Workflows & Error-Proofing and to the site’s Runbook sections.
When a lane is put in Safe Local Mode for troubleshooting, show a persistent banner and require a second person verification to re-enable remote control.
536.7 Reporting & KPIs
Track alarm rates and clear times (542). Reporting improves HVM bollard reliability.
Minimum measures: alarm rate per lane/day, top 10 recurring alarms, mean time to acknowledge (MTTA), mean time to clear (MTTC), and percent resolved within priority targets. Feed these into the operational dashboard and trigger alerts when thresholds are breached. Tie alarm IDs to the BMS/SCADA tag list and to the asset register for traceability.
536.8 Drill/testing
Schedule drills with evidence (547). Drills harden crash rated bollard behavior.
Run quarterly drills that simulate credible scenarios: EFO demand during peak traffic, power brownout with queued vehicles, or comms loss between panels. For each, pre-state success criteria, evidence to capture (screenshots, event logs, photos), and the witness procedure. Publish findings and actions in the site’s after-action review.
536.9 Review & tuning
Periodic reviews trim noise. Tuning sustains HVM bollard performance.
Hold a monthly alarm review. Retire alarms that add no decision value, split ambiguous ones, and re-classify mis-prioritized items. Keep a change log that links edits to the Change Control & Versioning page so controllers and HMIs stay aligned across firmware updates and site rollouts.
Related
External resources
536 Alarm Philosophy — FAQ
What’s the difference between a safety alarm and a process alarm?
Safety alarms signal states that could harm people or defeat security intent and usually require latching and guided reset. Process alarms indicate degraded performance (e.g., slow raise) with timed escalation but without immediate hazard.
When should an alarm be latched?
Latch any alarm where auto-clear could hide an unsafe condition—obstruction, EFO faults, or contradictory interlock states. Latching ensures a deliberate, checklist-based reset by an authorized role.
How do we prevent alarm flooding during incidents?
Use first-out capture, persistence windows for trend alarms, input debounce, and message deduplication. Escalate on the primary cause only, and suppress repeats until the root event is cleared.
Which KPIs matter for alarm management?
Track alarm rate per lane/day, mean time to acknowledge (MTTA), mean time to clear (MTTC), top recurring alarms, and SLA compliance by priority. Use breaches to trigger review and tuning.