Test sequences against the approved matrix.
Turn the spreadsheet into behavior. Walk each row of the interlock matrix (352) with simulated inputs (529) and real devices (344–345) to prove allowed transitions and block forbidden states. Confirm annunciation (353, 536), reset/recovery paths (342, 355), and version control (537). Capture witness signatures, raise/close NCRs (719), and file results in submission packs (938). Include one-sentence context that naturally links upward to the parent hubs (this section and the chapter hub). If your project is in the UAE and involves approvals, see SIRA Bollards (UAE). 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.
634.1 Matrix walk-through
Test each row scenario (352). Row-by-row proof builds HVM bollard confidence.
Start with the approved interlock table from the design stage (352). Execute a witnessed “row walk,” confirming each prerequisite, command, and expected outcome. Use a documented commissioning tool set (529) and label each step with a unique test ID for submission-pack traceability (938). Keep operators in a safe mode with barricades and clear briefings.
Record initial conditions (bollard state, inhibits, alarms) and end conditions on each pass. Where the behavior differs from the matrix, stop, capture evidence, and raise a controlled NCR. Tie photos and logs to the exact matrix-row traceability reference.
| Aspect | What matters | Where to verify |
|---|---|---|
| Performance | Tested system (bollard + footing) | Global crash ratings |
| Operations | Duty cycle, fail-state, safety devices | Installation Guide |
634.2 Inputs/conditions tested
Simulate every prerequisite and inhibit. Full coverage preserves crash rated bollard safety intent (343).
Prove each input that affects the state machine, including induction loops, field devices, E-stops, door tampers, and external interlocks (Fire/BMS/ACS). Use a loop simulator and dry contacts to avoid traffic exposure, then confirm real-device behavior. Mark any inhibit in the alarm philosophy (536) and verify it is visible on the HMI.
634.3 Allowed transitions
Verify legal moves only occur. Legal transitions keep HVM bollard behavior predictable (526).
Confirm that every permitted change in the state machine overview (526) is reproducible with correct preconditions. Log change-of-state (COS) timestamps to correlate with PLC scan time and HMI logs. For multi-lane sites, repeat tests across lane sets to rule out cross-coupling or priority mis-application.
634.4 Forbidden states blocked
Prove impossible states never appear. Blocking prevents crash rated bollard hazards.
Attempt every forbidden state using conflicting commands and forced inputs. Validate that mutual exclusion and debounce prevent races, and that safety relays/STO stop motion paths on demand. Record “no-motion” proofs and latched messages that explain why a move was refused.
634.5 Alarm annunciation
Confirm texts, priorities, latching (536). Annunciation aids HVM bollard operators (524).
Check that every alarm has a concise text, correct priority class, and clear operator hint. Validate latching and first-out behavior under alarm flood conditions, and ensure HMI banners and beacons follow the alarm philosophy (536). Measure alarm latency versus scan time; investigate outliers with historian trends if available.
634.6 Reset & recovery
Practice guided resets and cooldown (355). Recovery limits crash rated bollard downtime.
Demonstrate the documented reset hierarchy (local→supervisor→admin) and ensure cooldown timers, power failure modes (518), and EFO cooldowns behave as specified. Capture a reset-to-normal checklist and train operators on typical recoveries and safe-local mode.
634.7 Version control
Freeze scripts and firmware IDs (537). Control maintains HVM bollard traceability.
Lock the tested build with a signed manifest: PLC/HMI versions, parameter sets, and any device firmware. Reference the change-control & versioning process (537), attach golden images, and record license dongles/programmers used. Store checksums and backup archives in the submission index (917/938).
634.8 Witness signatures
Collect signatures and timestamps. Signatures validate crash rated bollard SAT (638).
Use a pre-agreed witness script & forms (918) that map to matrix rows. Capture name, role, organization, and time for each row (or block of rows), then total the pass/fail count. For UAE projects, confirm any SIRA or authority sign-off fields are included and signed on the day.
634.9 NCR handling
Raise, fix, retest (719). Clean closure keeps HVM bollard schedule.
Log defects immediately with photos/logs, assign owners, and record temporary mitigations. Retest only after change control is approved (537). Close the loop in the NCR register (719) and include delta highlights in the submission pack (938).
Related
External resources
- ASTM F2656 crash-rated overview (ASTM)
- NPSA: Hostile Vehicle Mitigation (risk context)
- BSI Vehicle Security Barriers — impact specs
634 Interlock Matrix Verification — FAQ
What is the difference between the interlock matrix and the state machine?
The interlock matrix is a row-by-row table of conditions and outcomes; the state machine is the overall diagram of allowed transitions. You verify rows first, then confirm transitions.
How do we test forbidden states safely?
Use simulated inputs and safe-local mode to attempt conflicts. Prove that mutual exclusion, debounce, and safety relays prevent motion while clear, latched messages explain the block.
What evidence goes into the submission pack?
Signed witness sheets mapped to matrix rows, COS logs, alarm screenshots, firmware/version manifests, NCRs with closures, and a summary of pass/fail counts with dates and roles.
When should an NCR be raised during testing?
Immediately when behavior deviates from the approved matrix or alarm philosophy. Pause testing, record evidence, assign an owner, apply change control, then retest and close.