521.1 Central vs distributed controls

Central panels ease maintenance; distributed reduces cable runs. Choose an architecture that keeps automatic HVM bollard latency low while preserving crash rated bollard interlocks (352).

A centralized architecture concentrates control in one or two main panels. Benefits include simpler spares, fewer program variants, and easier SAT evidence. Risks are single points of failure and long field runs. A PLC/Controller can supervise multiple lanes with clear partitioning and a documented interlock matrix.

A distributed architecture places smaller panels near each lane or cluster. You reduce voltage drop and loop/sensor cable lengths, which helps noise immunity and troubleshooting. The trade-off is more enclosures to protect (see 516 Enclosure Protection) and tighter version control across nodes (see 537 Change Control & Versioning).

Hybrid designs are common: a central panel handles shared functions (EFO, alarms, site modes) while lane panels drive actuators. Document which functions live where and enforce unambiguous “source of command” rules (see 525 Modes of Operation).

521.2 Networked panels

Define topologies, addressing, and supervision. Reliable links stop orphan states in HVM bollard lanes (535, 533).

Standardize your fieldbus/Ethernet choices and topology (ring, star, or redundant links). Assign deterministic addressing and implement link-supervision “heartbeats” so a panel never stays in an undefined state if comms drop. Report link loss as a latched alarm with a clear operator recovery hint (see 533 SCADA/BMS Signals & Reporting).

Use a small “network ICD” that lists ports, VLANs, QoS, and allowed protocols. For mixed vendors, define message maps and timeouts in an Interface Control Document (ICD). Validate supervision during commissioning (link pull tests, switch power cycles) and capture this in 638 Witness Procedure.

521.3 Authority & priority layers

Map who can command what, when. Priority prevents conflicting orders to a crash rated bollard portal (525).

Define roles, credentials, and a site-wide priority matrix so EFO, emergency egress, and operator commands never conflict. Typical order: life-safety > EFO > emergency egress > steward panel > remote SCADA. Show this order graphically on the HMI (524) and confirm it in your state diagrams (526).

Every elevated command should be auditable (who/when/where). Log the winning source and the suppressed source so operations can tune workflows. Prove priority handling in 634 Interlock Verification with paired, conflicting inputs.

521.4 Local/remote control split

Local wins during commissioning; remote for ops. Clear splits avoid unsafe HVM bollard actions (524, 632).

Provide a physical Local/Remote selector or secure software mode on each lane set. In Local, on-panel devices and test tools are authoritative (see 529 Commissioning Tools), while remote commands are inhibited except critical alarms. In Remote, SCADA/BMS and steward consoles govern daily operations with clear indications on both sides.

Protect mode changes with keys or role-based access and show status prominently on the HMI. Log every transition, including the operator and reason, for SAT traceability (638) and later KPI analysis (542).

521.5 Safety separation

Keep safety IO independent and testable (343). Separation protects crash rated bollard safeguards.

Implement an independent safety path using certified relays or safe I/O where practical (see 343 Safety Circuits). Maintain galvanic separation between command logic and safety-stop chains, and document proof-test intervals in the maintenance plan (734).

Design for testability: include Test/Isolate switches, safe bypass keys with timers, and obvious status lamps. Capture all safety dependencies in 352 Interlock Matrix and verify category 0/1/2 stop behaviors in 635 Intrusion Tests and 637 EFO & Failure Modes.

521.6 Time sync & logging

Use NTP/GPS so events align (542). Sync lets HVM bollard KPIs be trusted (541).

Adopt a single time source (primary/secondary NTP or GPS) for all panels, HMIs, SCADA, and logging endpoints. Without alignment, counters and alarms can’t form reliable KPI trends. Include time health in your 541 health pings, and alert when drift exceeds a small threshold.

Standardize log fields: lane ID, command source, mode, COS timestamp, and result (success/fail + reason). Store summaries locally and forward to the site historian/PSIM if used (534). Validate log completeness during SAT: pull random samples and reconcile with witness sheets (638).

521.7 Resilience & redundancy

Add failover, watchdogs, and heartbeats (342). Resilience sustains crash rated bollard availability.

Resilience combines hardware choices (dual power feeds, UPS ride-through) with software behaviors (retry windows, queue draining). Use a watchdog timer and panel heartbeats to detect hangs early. Define safe degraded states (e.g., hold bollards up with alarms) and display operator recovery steps on the HMI.

Apply redundancy only where it improves availability measurably: dual controllers on shared I/O are complex—often dual power + spare panel + rapid swap is better. Record availability targets in 738 Service Levels & Availability and track actuals with 541/542.

521.8 Cyber basics

Unique creds, VLANs, and updates (535). Cyber hygiene protects HVM bollard control.

Harden panels: unique credentials, least-privilege roles, secure password storage, and documented update windows. Segment traffic with VLANs, lock management ports, and restrict remote access to allow-listed endpoints. Keep an offline recovery image and a change log (see 537 Change Control & Versioning).

Integrations should be minimal and explicit. Publish a “signals we expose” list (533) and insist on read-only links unless there’s a clear, tested need. Capture cyber assumptions in the ICD and review them at CRR (Commissioning Readiness Review) before SAT.

521.9 Architecture diagram set

Deliver block/IO/network drawings (539). Diagrams speed crash rated bollard review.

Produce a consistent diagram pack: (a) block architecture; (b) lane state machine overview (526); (c) I/O list with addresses (523); (d) network map with addressing/VLANs (535); (e) alarm & reporting map (536/533); and (f) SAT witness scripts linkage (638). Each diagram should name the as-tested configuration (415/421 dependencies) and the document version.

Bind the pack into 539 Integration Documentation and cross-reference 433 Specification Template. This shortens authority and client reviews and prevents “like-for-like” substitutions that erode safety or availability (see 435 Anti-Downgrade / Equivalence Clauses).

521 Control Architecture — FAQ