Functional Design Specification structure and acceptance.
The Functional Design Specification is the contract for behavior. It defines modes, I/O, interlocks, alarms, and Emergency Fast Operation for automatic HVM bollards in a way operators, vendors, and reviewers can all verify. Build it from architecture (521), interlock matrix (352), I/O list (523), alarm philosophy (536), and SAT steps (638) so crash rated bollard intent is maintained through commissioning. This page sits under this section and the chapter hub HVM Bollards Documentation. Where UAE approvals apply, also see SIRA Bollards (UAE). For installation context, refer to What to Expect and the 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.
711.1 Purpose & scope
Define how the HVM bollard system behaves in all modes. Scope anchors crash rated bollard safety, interfaces, and acceptance (521, 352, 638).
The FDS explains control architecture (521), functional behavior, and the evidence the team will produce to prove compliance. It must trace each requirement to a testable outcome (e.g., SAT step numbers) and make safety intent obvious to non-programmers. Keep language plain; reserve code details for the software repository and the alarm philosophy (536).
State what’s included (automatic lanes, ancillary devices, interfaces) and excluded (e.g., third-party ACS logic). Tie every promise to an objective acceptance check in the Inspection & Test Plan (714) and SAT / witness procedure (638). Use a simple RACI table to make ownership clear.
Write for readers: the Owner’s team & reviewers, maintainers, and integrators. Avoid vendor-specific jargon unless essential; where it’s needed, define it once and link to the glossary.
| Aspect | What matters | Where to verify |
|---|---|---|
| Performance | Tested system (bollard + footing) | Global crash ratings |
| Operations | Duty cycles, fail-state, fail-state, safety | Installation Guide |
711.2 Functional states & modes
List Auto, Manual, Bypass, EFO, Night/Event (525). Clear states prevent unsafe HVM bollard transitions.
Define each mode with a mode authority, entry/exit conditions, and state machine diagram. Example: “Auto” accepts ACS releases and safety permits; “Bypass” requires keyed consent and restricts speed with on-device deadman control; “Night/Event” enforces minimum-risk behavior with prominent annunciation (353).
Use a Request→Authorize→Execute pattern for all actuation. List forbidden states (e.g., bollard down while lane unsafe) and show operator recovery with concise HMI hints.
711.3 Inputs/outputs list
Reference the I/O register with tags, ranges, and fail states (523). Accurate I/O protects crash rated bollard logic.
Point to the master I/O list template (523). For each point, define tag, type (DI/DO/AI/AO), scaling, fail-state philosophy, debounce, and diagnostics. Include tag naming convention and terminal mapping to reduce wiring ambiguity.
Mark safety-related I/O and watchdogs explicitly. Log all change-of-state (COS) events to the historian or a protected audit file with time sync per site policy.
711.4 Interlocks & safety
Describe inhibits, permissives, and watchdogs (343, 352). Interlocks keep HVM bollard motion predictable.
Interlocks combine permissives and matrix rows into a simple truth table. Show inputs (loops, photo-eyes), lane status, and outputs (raise/lower, stop). Add watchdog timer and movement timeouts for fail-to-safe behavior.
Provide a one-page “state transition diagram” and a cross-reference to the SAT script (638) so each interlock row is verifiable in the field.
711.5 Alarms/events
Priorities, latching, messages, and routing (536, 544). Alarms guide crash rated bollard response.
Standardize messages and priorities per the alarm philosophy (536). Distinguish latched from self-clearing alarms, define routing, and specify throttle/shelving to prevent alarm floods. Include operator “first-out” indication and a clear recovery hint on the HMI.
Every alarm/event must land in the operational dashboards (544) and historian with cause, time, lane ID, and user attribution (RBAC).
711.6 EFO & overrides
Authorize, time, and log EFO sequences (354). Overrides must not weaken HVM bollard safety.
Define who can initiate EFO, the EFO timing window, cooldown intervals, and evidence logging (who/when/why). EFO must respect safety devices & measures: if an obstruction is present, the system should reject or apply guarded raise with enforced warnings as defined in the risk assessment.
Lock all maintenance/override paths (keyed bypass, guarded switch). Document reset hierarchy after EFO and ensure the SAT includes repeatable EFO demonstrations with timing capture.
711.7 Environmental limits
Heat, dust, ingress, and acoustic constraints (337, 516, 546). Limits sustain crash rated bollard availability.
State temperature/humidity ranges, IP rating (516), sun-load, and local sand exposure. Reference Hot Climate Design (337) for derating curves, and set acoustic caps aligned with HMI/HPU noise limits (546). Define any local mitigations (acoustic lining, ventilation, bug screens).
711.8 Testing references
Point to FAT/SAT scripts and acceptance bands (715, 638, 714). Tests verify HVM bollard behavior.
Link each FDS clause to test evidence: FAT vs SAT readiness (715), SAT / witness procedure (638), and the ITP with acceptance bands (714). Include special tests for duty/throughput (636) and failure modes (637).
711.9 Sign-off page
Version, approvers, and distribution (537). Sign-off freezes crash rated bollard baseline.
Finish with a sign-off matrix: version ID, approver names/roles, date, and distribution list. Declare the change control & versioning (537) path and where superseded files are archived. After approval, enforce design freeze and control changes via formal CRs with impact assessment and updated SAT references.
Related
External resources
- NPSA — Hostile Vehicle Mitigation (HVM)
- FEMA 426 / DHS — Reference Manual
- ASTM F2656 — Vehicle impact testing
711 FDS — FAQ
What’s the difference between the FDS and the ITP?
The FDS defines how the system must behave, while the ITP lists inspections/tests and acceptance bands to prove the behavior. The FDS is the “what/why”; the ITP is the “how/when/thresholds.” Each FDS clause should point to a matching ITP or SAT step for verification.
Who signs off the FDS and when?
Typically the Owner’s Engineer (Accountable), system integrator, security lead, and operations lead. Approval should happen before panel build/PLC coding and be revisited at FAT readiness to capture late clarifications, then frozen under change control.
How is Emergency Fast Operation handled in the FDS?
The FDS defines EFO initiators, authority, timing window, cooldown, and evidence logging. It also states safety devices & measures that must remain active during EFO and the reset path after activation, with timed demonstrations in SAT.
What happens if a requirement changes after FDS approval?
Use the change control process: raise a CR, assess impact (logic, tests, drawings, training), obtain approvals, version the documents, and update ITP/SAT links. Superseded versions move to the archive with a clear audit trail.