537.1 Drawing/version rules

Title blocks, rev clouds, and logs. Rules keep HVM bollard drawings current (931).

Use a clear drawing status (e.g., IFC, IFT, IFU) and a visible revision code tied to a CAD/BIM standard (931). Every issued set adds a delta list with matrix-row traceability back to the interlock matrix (352). Mark up changes with revision clouds and update the transmittal log so reviewers can verify intent quickly.

Define where “minor/editorial” vs “technical” changes land. Editorial changes (typos, layout) can batch into the next release; technical changes that affect safety devices & measures must raise a change request and new revision. Cross-reference the state machine overview (526) when logic graphics are redrawn.

Keep a live revision index on the sheet and a master index in the submission index (917). For any change that touches as-tested configuration, add a short “Release Notes” paragraph on the drawing register entry.

537.2 Firmware/software control

Unique IDs, checksums, and storage. Control preserves crash rated bollard logic integrity (522).

Assign each controller build a unique Release ID and store the PLC/HMI binaries with hashes (e.g., checksum) in a read-only archive. List supported hardware/firmware dependencies in the FDS (711) and capture programming toolchain versions (IDE, libraries) in the change log (718).

For portability and audits, export source files, compiled binaries, and a signed manifest that lists modules, watchdog settings, and compile dates. Enforce role-based access; changes must go via the request workflow below—no “on-panel” edits.

537.3 Parameter set baselines

Freeze PLC/HMI parameters per release. Baselines stabilize HVM bollard behavior (524).

Create a signed parameter snapshot for each release—timeouts, movement timeouts, alarm thresholds, debounce values, indicator mappings, and alarm priority classes. Store it with the Release ID, and show key read-only values on the HMI “About” screen for field verification (524). Any deviation in commissioning must be raised as a change request with rationale and re-tested.

Link baseline parameters to the I/O list template (523) and health counters (541) so KPIs (542) remain comparable across releases.

537.4 Request/approval workflow

CR forms, approvers, and impact notes (717). Workflow prevents risky crash rated bollard changes.

Use a lightweight Request→Authorize→Execute flow with a numbered Change Request (CR) form. Capture problem statement, scope, affected assets, risk impact (safety, availability, compliance), and test plan. Approvers include the accountable owner and (for safety-affecting changes) an independent reviewer. Reference authority submittal needs (717) and note if a SIRA notification applies for UAE sites (SIRA Bollards).

Classify changes: editorial change (docs only), configuration change (parameters), functional change (logic/HMI), and breaking change (affects interfaces or authority constraints). Breaking changes require a release note and stakeholder communication plan.

537.5 Test before deploy

Bench simulate and staged site tests (631–634). Tests avoid HVM bollard regressions.

Prove logic on a bench rig with loop simulators (633) and replayable witness scripts. Run a soak test for stability and alarm latency. On site, perform staged testing: power/health (632), loop & sensor proving (633), interlock matrix verification (634), and performance/duty tests (636). Document evidence in the SAT pack (638) and attach to the CR.

For integrated sites, coordinate BMS/SCADA tags (533) and fire interface behaviors (532). If any KPI regression appears (542), halt the rollout and escalate per rollback plan.

537.6 Rollback plans

Defined reversion steps and backups. Rollback protects crash rated bollard uptime.

Before deployment, export current binaries and parameter snapshots and verify a rollback runbook: restore process, required tools, and expected states. Keep a portable UPS and firmware loader in the commissioning kit (529) so panels can be safely reverted if power is unstable.

Define a time-boxed “fast-revert” window (e.g., first business day) with clear decision gates. If rollback is executed, update the change log (718) and record the root cause in the hazard log if safety was touched.

537.7 Audit trail

Stamp who/when/why. Trails prove HVM bollard compliance (444).

Maintain a tamper-evident audit trail that logs editor identity, timestamp, affected files, and reasons. Store the audit together with the Release ID and include a short “what changed/why” summary suitable for the evidence & documentation page (444). For field changes under Permit to Work, attach CR number on the PTW and toolbox talk notes (723).

537.8 Labelling in panels

Apply firmware labels inside doors (528). Labels aid crash rated bollard audits.

Inside each enclosure, affix a durable label listing controller type, firmware build, Release ID, and date. Place it near the door card with emergency contacts and the reset-to-normal checklist. Ferrule the program port and tag the terminal mapping reference so technicians can cross-check configurations during SAT and maintenance (734).

537.9 Archive & retention

Store securely per 911/115. Archives protect HVM bollard traceability (938).

Use the file index & naming rules (911) to archive source, binaries, parameter sets, drawings, SAT evidence, and release notes. Keep an immutable “golden” snapshot per live site and a superseded file list for retrieval audits (939). Retention periods should meet contract and authority requirements; ensure self-canonical links and a one-page index for handover packs (736).

537 Change Control & Versioning — FAQ