What to issue to close out: diagrams, configs, logs.
Put everything reviewers need in one coherent bundle. Provide block/I/O diagrams, an interface control document, address/point lists, and a clear sequence of operations that reflects modes (525) and interlocks (352). Include alarm philosophy, test scripts, and as-built updates with version history (537). Use the reviewer checklist to align with submission guidance (938) and protect HVM bollard and crash rated bollard intent from design to SAT (638). 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.
539.1 Block & I/O diagrams
Top-level and detailed IO maps (521, 523). Diagrams orient HVM bollard reviewers.
Provide a top-level block diagram that shows major subsystems (bollard lane, PLC/Controller, HMI, fire/BMS/SCADA interfaces) and a set of detailed I/O maps that enumerate each signal path. Use consistent I/O tag names (523) and match terminal numbering to the panel drawings (528). A clear “signal flow” view helps reviewers validate intent before they dive into the details.
Show communications links (e.g., Modbus, BACnet) and power segregation on the same sheet or as a paired pair of diagrams. Cross-reference each I/O symbol to the enclosure layout (528) to speed fault-finding during SAT (638).
| Aspect | What matters | Where to verify |
|---|---|---|
| Performance | Tested system (bollard + footing) | How to read crash ratings |
| Operations | Duty cycles, fail-state, safety | Installation Guide |
539.2 Interface control doc
Define signals, directions, and timing (531–533). ICD stabilizes crash rated bollard integrations.
The Interface Control Document (ICD) captures every external interface: point name, electrical type (dry contact, 24VDC, analog), normal/abnormal state, debounce/filtering, and timing/handshake rules. Include comms timeout behavior and recovery after power loss (518). Keep a column for matrix row traceability to the interlock matrix (352).
Agree ICD ownership and change control with BMS/Fire/ACS teams up-front (533–534). For UAE projects, note any SIRA-related behaviors in a clearly marked subsection and link the reader to SIRA Bollards (UAE) for authority context.
539.3 Address/point lists
Unique addresses with ranges. Lists prevent HVM bollard miswires.
Publish a master point list (digital/analog) with unique addresses, ranges/units, and tag naming. Add terminal mapping and cable/core references (515, 528) so technicians can trace a signal from field device to PLC input and back. For networked points, include node IDs, ACL and port usage to support cyber basics (535).
Include a “test method” column per point (e.g., loop simulator, force bit in PLC, physical trigger) to align with 634 Interlock Matrix Verification and 529 Commissioning Tools.
539.4 Sequence of operations
Readable SoO covering modes/faults (525, 342). SoO explains crash rated bollard behavior.
The Sequence of Operations (SoO) narrates how the lane behaves across modes (525): Automatic, Manual, Maintenance/Bypass, Emergency/EFO. Use plain language first, then reference the state machine (526) for precise transitions and guards (timeouts, heartbeats, mutual exclusion).
Cover fault behavior (342, 355), degraded states, and recovery steps. Include operator prompts and recovery hints that will also surface on the HMI (524). Tie each step back to SAT tests (638) so witnesses can tick off evidence without ambiguity.
539.5 Alarm philosophy
Embed the 536 ruleset. Philosophy keeps HVM bollard alerts consistent.
Summarize alarm classes/priorities, latching/reset rules, and annunciation targets as defined in 536 Alarm Philosophy. Map each alarm to a response (operator action, escalation path) and to reporting (542). Document suppression/shelving policy to avoid alarm floods while keeping safety intact.
539.6 Test scripts
Include 634–638 references. Scripts accelerate crash rated bollard SAT.
Write step-by-step scripts that mirror the interlock matrix (352) and the SoO. Include prerequisites (631–633), tools (529 Commissioning Tools), acceptance bands, and evidence capture (716). For witnessed tests use the format in 638 SAT / Witness Procedure with space for NCRs (719) and retests.
539.7 As-built updates
Revise drawings after changes (537, 731). Updates preserve HVM bollard truth.
After commissioning changes, update panel drawings, wiring schedules, and point lists. Mark deltas on redlines and roll them into 731 As-Built Drawings & Models. Ensure field labels match drawings to prevent future maintenance errors (734, 738).
539.8 Version history
Maintain deltas with dates/authors. History protects crash rated bollard traceability (115).
Keep a simple version log for each document and configuration: Release ID, date, author, change summary, and links to superseded files. Align with 115 Versioning & Numbering and 537 Change Control & Versioning. For PLC/HMI, store the golden image plus checksums and a signed manifest.
539.9 Reviewer checklist
One-page checks for completeness (444, 938). Checklist speeds HVM bollard approvals.
Create a single A4 “Review Pack Index & Checks” that points to each item in this page (diagrams, ICD, lists, SoO, alarms, tests, as-builts, versions). Include a short Submission-Pack Guidance (938) alignment note and an “issues log” space. For low-speed evidence, cross-link to 444 Evidence & Documentation.
Related
External resources
539 Integration Documentation — FAQ
What is the minimum documentation set to close out integration?
At a minimum: block & I/O diagrams, an ICD, a point/address list, a readable SoO, the alarm philosophy summary, witnessed test scripts/results, as-built drawings, and a version history log with golden images and checksums.
How does the ICD differ from the I/O list?
The I/O list is a catalogue of signals and addresses; the ICD goes further by defining directions, normal/abnormal states, timing/handshakes, comms-loss behavior, and ownership across systems (Fire, BMS, ACS, SCADA).
Who signs off the Sequence of Operations (SoO)?
Typically the integrator/controls engineer drafts it; the Contractor and the Owner’s Engineer review; Fire/BMS stakeholders confirm interface behavior; the witness authority signs it during SAT alongside the test scripts.
How do we control revisions during commissioning?
Use change requests tied to tests, maintain a configuration baseline and golden images, track deltas in a version log, and label panels/USB media. See 537 Change Control & Versioning for workflows and rollback plans.