Standard I/O list structure with naming conventions.

The I/O list is your contract between design and commissioning. Standardize tags and names, define types/ranges and normal/abnormal states, and pre-assign alarms/priorities that align with signalling (353) and dashboards (544). Include test methods per point, cable/core cross-references (515), and terminal mapping (528). Revision control ties to change management (537) and witness evidence (716, 638). This page sits within this section and the broader chapter hub. Where authority approvals apply in the UAE, coordinate I/O point naming and alarms with SIRA Bollards (UAE) submission expectations.

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.

523.1 Tagging rules

Consistent, human-readable tags. Good tags reduce HVM bollard commissioning friction.

Adopt a short, readable tag pattern that encodes device, function, and location—for example LN1-HPU-PRES_OK. Keep tags stable from design through the SAT. Use a single PLC/Controller tag namespace across all panels to avoid duplicates. Document allowed characters, max length, and case rules in the front matter of the I/O sheet.

Reserve suffixes for state qualifiers (e.g., _CMD, _FB, _ALM) and keep them consistent across bollard lanes. Align lane identifiers with the site’s people flow plans and signage so operators can correlate HMI messages quickly.

AspectWhat mattersWhere to verify
Naming patternDevice–Function–LocationControl Architecture
UniquenessOne ID per physical pointVariations & Change Log
TraceabilityTag ↔ drawings ↔ testsEvidence Capture Standards

523.2 Signal naming

Name by device–function–location. Naming clarity speeds crash rated bollard SAT (638).

Use descriptive signal names on top of the compact tag so the HMI (Human–Machine Interface) is plain English. Example: Tag LN1-LOOP-ENTRY_PRES, Signal name “Lane 1 entry loop — vehicle present”. Keep verbs consistent (e.g., “Active”, “Healthy”, “Authorized”) to support filtering and KPIs later (542).

For integrations (Fire/BMS/SCADA), include a cross-system alias column so SCADA/BMS signals match your I/O list and the ICD.

523.3 Type & range

Record DI/DO/AI/AO with scaling. Correct ranges prevent HVM bollard misreads.

Declare type (DI, DO, AI, AO) and electrical standard for each point—e.g., DI 24 VDC sink, AI 4–20 mA with 250 Ω shunt. Capture engineering range and units for AIs (e.g., 0–250 bar oil pressure) and specify the raw-to-engineering scaling applied in the PLC. For AOs, state resolution and ramp/limit rules (e.g., 0–10 V valve command, 100 ms rate limit).

Note environmental ratings impacting transducers (see 516 Enclosure Protection) and plan spare channels for future sensors linked to condition monitoring.

523.4 Normal/abnormal states

Define true/false and failsafe. States protect crash rated bollard safety (343).

Make the “normal” and “abnormal” definitions explicit per point: contact logic (NO/NC), active level, and what counts as a fault. For safety devices & measures like photo-eyes and induction loops, choose wiring that yields a safe failure (e.g., loss-of-signal = demand to stop). Link these to the safety circuits and the interlock logic (352 Interlock matrix).

Document power-up defaults and degraded modes (e.g., bollards hold down on brownout) consistent with fail-safe/secure philosophy.

523.5 Alarms & priorities

Attach class and escalation (536). Priorities focus HVM bollard operators.

Assign an alarm class and priority to each point that can fault (e.g., Class A — safety critical, Class B — operational, Class C — maintenance). Define latching, acknowledgement, and escalation paths aligned with the site’s Alarm Philosophy (536). Include operator guidance text and a short recovery hint (e.g., “Check HPU oil level; if low, isolate and call maintenance”).

For integrations, record which alarms are mirrored to BMS/SCADA and which remain local only. Map each to the dashboard widgets used in Operational Dashboards (544).

523.6 Test method per point

Document simulate/observe criteria (529). Methods fast-track crash rated bollard proving (634).

For every point, provide a brief test method: how to simulate/stimulate, expected indication on the HMI, and the witness criteria. Example: “Entry loop present — place loop simulator, expect ‘Vehicle present’ bit = 1, red beacon on, inhibit raise command; record screenshot + COS log entry.” Reference the applicable step in Commissioning Tools (529) and 634 Interlock Matrix Verification.

Include pass/fail tolerances for analog points (e.g., 4–20 mA = 0.0–20.5 mA acceptable) and any post-test reset required (e.g., latched messages demand operator reset).

523.7 Cable/core cross-refs

Link terminal, cable, and core IDs (515, 527). Cross-refs simplify HVM bollard fault-finding.

Create columns for cable ID, core number, and destination so technicians can trace faults without flipping drawings. Match IDs to the Cable & Routing schedule (515) and the panel wiring standard (527). Add a note for spare cores and termination of shields (e.g., earth at one end only for analog loops to reduce EMC noise).

Where trunking/duct banks are congested, include a route hint that aligns with the Ducting & Trench Details (934) drawing index.

523.8 Panel/terminal mapping

Map to panel, row, terminal. Mapping reduces crash rated bollard wiring errors (528).

Provide panel name, backplate row, and terminal number for each I/O point. If using marshalled terminals, list marshalling tag and the final PLC channel. Keep physical order left-to-right/top-to-bottom to match the Enclosure Layout & Access (528) layout so technicians can work without guesswork.

Flag safety circuits and Emergency Fast Operation (EFO) terminals distinctly and state any test/isolate provisions to support 356 testability.

523.9 Revision control

Version every change (537). Control keeps HVM bollard evidence clean (444).

Assign a Release ID, date, and editor for each change to the I/O list. Track deltas in a “Change Notes” column (what changed and why) and sync versions with the Change Control & Versioning (537) process. Store signed PDFs in the submission index and reference them in your evidence chain for SAT witnessing (638).

Lock the sheet during commissioning windows to avoid mismatches with as-loaded PLC code and capture a post-SAT “Issue-for-Use” snapshot for the Asset Register.

Related

External resources

523 I/O List Template — FAQ

What columns must every I/O list include?
At minimum: Tag, Signal name, Type (DI/DO/AI/AO), Electrical spec, Engineering range/units, Normal/abnormal state, Alarm class/priority, Test method, Panel/terminal mapping, Cable/core IDs, Revision fields (Release ID, date, notes).
How do I make alarms meaningful for operators?
Use plain-language signal names, consistent verbs (“Active”, “Healthy”), clear recovery hints, and a priority scheme aligned with your Alarm Philosophy (536). Configure latching/acknowledge behavior and escalation paths so critical issues are never missed.
What’s the best way to handle analog scaling?
State raw input format (e.g., 4–20 mA), engineering range/units, and the exact scaling block used in the PLC. Include acceptable tolerances for tests and note any filtering or rate limits to avoid nuisance alarms during transients.
How is the I/O list used during SAT?
It drives the test scripts: each point’s method, expected indications, and pass/fail thresholds are executed and witnessed. The signed I/O list snapshot, screenshots, and logs become part of the SAT evidence and the handover pack.