Useful KPIs, thresholds, and dashboards.
Prove performance, don’t just claim it. This page defines standard KPIs—operations/hour, cycle time, MTBF—and ties them to reliable data sources (541, 533). We document calculation rules, alert thresholds, and trend analysis so operators see issues before failures. Visualizations (544) and a review cadence feed VE and upgrade discussions (338, 446) while protecting crash rated bollard availability targets in SLAs (738). 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.
542.1 KPI definitions
Ops/hour = completed strokes; Cycle time = up/down + dwell; MTBF per lane. KPIs quantify HVM bollard performance at crash rated bollard sites (636).
Start with precise, field-testable definitions. KPI “Ops/hour” counts completed rising/falling strokes, not commands. MTBF is tracked per lane to avoid masking weak assets. “Cycle time” is the full up→dwell→down sequence as measured at the controller, not the HMI animation. Keep these aligned with Performance & Duty Tests (636) and your acceptance criteria.
Relate KPI definitions to real availability targets in Service Levels & Availability (738). If a lane’s MTBF dips while ops/hour rises, you may be over-utilizing a single lane; rebalance via mode or schedule (see Modes of Operation, 525) before failures cascade.
| Aspect | What matters | Where to verify |
|---|---|---|
| Performance | Tested system (bollard + footing) | Global crash ratings overview |
| Operations | Duty cycles, fail-state, safety | Installation Guide |
542.2 Data sources
Use controller counters and SCADA tags (533, 541). Trusted sources prevent HVM bollard KPI drift.
Prefer native controller counters and timestamped SCADA/BMS tags over manual logbooks. Lock time via NTP and send heartbeat/health pings (541). Define a read-only points list in SCADA/BMS Signals & Reporting (533) and mirror it in your Integration Documentation (539) so reviewers and operators trust the numbers.
542.3 Calculation rules
Exclude maintenance/bypass periods (525). Rules keep crash rated bollard metrics honest.
Establish filters in the historian so cycles during Maintenance/Bypass don’t count toward ops/hour, and faulted intervals don’t depress MTBF. Document the exact formulae (e.g., MTBF = operating time with no faults ÷ number of faults) and maintain a calculation change log in the versioning pack (see Change Control & Versioning, 537).
542.4 Threshold setting
Set warnings at trend deltas, alarms at hard limits. Thresholds catch HVM bollard degradation before crash rated bollard failure.
Use two bands: (a) trend-based warnings triggered by persistent deltas (e.g., cycle time +10% for 7 days) and (b) hard limits (e.g., >25% over baseline). Route threshold breaches via your alarm philosophy (536) to avoid floods and ensure action.
542.5 Trend & seasonality
Account for event peaks and climate cycles (239, 337). Trends explain HVM bollard variance.
Segment the data by time-of-day, weekday/weekend, and event periods (239). In hot climates, viscosity and thermal limits (337) can stretch cycle time—compare lanes with similar exposures for fair baselines. Mark “special causes” (site works, power events) in the timeline to avoid false alarms and to improve post-incident reviews.
542.6 Alert routing
Ops to onsite, systemic to engineering. Routing accelerates crash rated bollard fixes (536).
Send immediate operational alerts (stopped lane, fault not cleared) to onsite responders; aggregate, systemic alerts (declining MTBF across lanes) to engineering. Map each class to an escalation path and document ack/clear rules to control alarm latency. Keep roles/sign-offs visible in the RACI grid.
542.7 Review cadence
Weekly ops, monthly engineering, quarterly leadership. Cadence improves HVM bollard availability (738).
Adopt a rhythm: weekly lane health with the ops team; monthly MTBF/MTTR deep-dives with engineering; quarterly KPI and SLA review with leadership (738). Feed actions into the maintenance plan (734) and update thresholds if the baseline shifts after upgrades (446).
542.8 Visualizations
Sparkline per lane, Pareto by fault, SLA gauge (544). Visuals clarify crash rated bollard health.
Keep screens scannable. Use per-lane sparklines for cycle time and ops/hour; a faults-by-type Pareto to target the vital few; and a clear SLA/availability gauge. Consolidate all in Operational Dashboards & Reporting (544) so operators and reviewers see the same truth.
542.9 Continuous tuning
Refine bands as data matures. Tuning stabilizes HVM bollard KPIs.
As data volume grows, re-baseline seasonally and after significant changes (e.g., firmware, hydraulics, or traffic pattern). Document edits through versioning (537) and keep a one-page change summary in the reviewer pack (539) to maintain trust.
Related
External resources
- NPSA: Hostile Vehicle Mitigation (overview)
- BSI: Impact test specifications for VSB systems
- ASTM F2656: Crash testing overview
542 KPI Set (Ops/Hour, Cycle Time, MTBF) & Alert Thresholds — FAQ
What counts as an “operation” for ops/hour?
An operation is a completed stroke sequence (up and down). Commands without movement don’t count. Partial moves during maintenance or bypass modes are excluded from KPI totals.
How do we measure cycle time consistently?
Use controller timestamps from rise start to fall complete (including dwell). Time sources must be NTP-synced; avoid manual stopwatch methods except during SAT correlation checks.
Is MTBF calculated per lane or across the whole site?
Track MTBF per lane to expose weak assets. You can add a site-level roll-up for leadership, but don’t let it mask a repeatedly failing lane or HPU string.
How should we set alert thresholds at the start?
Begin with conservative baselines (e.g., warn at +10% cycle-time change sustained 7 days; alarm at +25%). Refine bands after a few weeks of stable data and update the version log.