352.1 Matrix structure

Rows = conditions; columns = inputs, states, outputs. Structure is the contract for automatic HVM bollard behavior and a crash rated bollard lane.

Treat the interlock matrix as a structured contract: each row states a condition and the resulting action. Columns group interlock matrix inputs (loops, beams, mode flags), the evaluated state machine state, and commanded outputs (raise/lower, signals). Keep column names consistent across projects to reduce errors.

Use one matrix per automatic bollard lane and add a short preface describing lane ID, modes of operation, and the applicable fail philosophy. Include references to controller pages (I/O list, priorities, timers) so reviewers can trace logic quickly.

352.2 Inputs & conditions

List loops, beams, E-stops, mode flags, ANPR (344–345, 525). Every input that can move an HVM bollard appears here.

Enumerate all field inputs: induction loops, photo-eyes, bypass key switches, E-stops, mode flags, and ANPR triggers. For each, specify debounce, faulted value, and whether it is safety-rated per Safety circuits (343).

Define derived conditions (e.g., “Vehicle present & clear gap OK”). Keep names short and unambiguous. Record priorities in a small alarm philosophy or SCADA/BMS signals annex so inhibit and alarm routing are predictable.

352.3 Allowed transitions

Define legal moves with timers and preconditions. Transitions prevent unsafe motion of a crash rated bollard post.

Base transitions on the state machine & interlocks overview. For each legal move (e.g., Lower→Raise), list preconditions (loops clear, signals red), timers (pre-raise dwell), and acknowledgements. Capture Request→Authorize→Execute so readers see who/what authorizes motion.

Include watchdogs and movement timeouts. If a transition fails, specify the safe stop category and annunciation target (HMI, SCADA, local sounder). Cross-reference Control logic (342) to keep timers and latching rules in one place.

352.4 Forbidden states

Block raise+lower, Auto+Bypass, or EFO+Maintenance conflicts. Forbidden sets protect HVM bollard safety integrity.

Explicitly list conflict sets such as Raise & Lower simultaneously, Auto & Maintenance Bypass, or EFO & Manual Hold. For each, define the controller response: which command wins, what is inhibited, and what alarm appears. This prevents race conditions and makes operator behavior predictable.

Document how conflicts reset (e.g., operator acknowledge, timer expiry, or power cycle). Align outcomes with Fail-safe/secure states (355) so the system always lands in a defensible safe state.

352.5 Alarm & inhibit logic

Tie inhibits to annunciation (536). Clear alarms shorten recovery for a crash rated bollard lane.

Pair every inhibit with a visible, logged alarm and an operator hint. Use a concise alarm philosophy (536) that assigns severity, audience (operator vs. maintenance), and escalation path. Show how latching works: which faults auto-clear and which require a reset.

Ensure SCADA/BMS points include COS logs for safety-critical changes. Provide a small alarm→action table to cut mean time to recovery (MTTR) and align with remote fault logging.

352.6 Test procedure mapping

Map each row to a SAT step (634–638). Mapping proves HVM bollard logic works in the field.

Add a “Verify via” column that references 634 Interlock Matrix Verification, 638 SAT / Witness Procedure, or a loop/sensor proving step. This creates a one-to-one trace from design to test script and reduces disputes on site.

For complex sites, add a pre-SAT dry run (operator walk-through) and attach the 633 Loop & Sensor Proving checklist to the matrix pack.

352.7 Versioning & change control

Tag matrix versions and distribute (537). Version control keeps a crash rated bollard site consistent.

Include a header with Release ID, author, date, and change control & versioning (537) link. Use a transmittal log and a single “Issue-for-Use” PDF per revision to prevent conflicting copies. If logic changes after SAT, raise a controlled variation and re-witness affected steps.

Maintain a “rating-critical dependencies” note pointing to 421 so no change undermines certified performance.

352.8 Sample matrix snippet

Include one worked example with inputs→outputs. Snippet teaches teams how to interpret HVM bollard logic.

The example below shows a typical Authorize Raise row. Names are illustrative—align with your I/O list (523) and control architecture.

Use descriptive alarm names and keep operator prompts short. Where applicable, include watchdog timers and stop categories in the action cell.

352.9 Approval workflow

Route draft→review→witness sign-off (717, 638). Approved matrices accelerate crash rated bollard acceptance.

Adopt a simple RACI: designer (draft), controls lead (peer review), Owner’s Engineer (approval), and authority or client representative (witness at SAT). Submit with an indexed submission pack (938) via the agreed portal. In the UAE, consider SIRA notes where scope intersects local approval pathways.

Archive the signed matrix with the handover pack index (736) so operators and maintainers always see the latest rules.

352 Interlock matrix for automatic HVM Bollards — FAQ