Field-by-field guidance and good examples.
Use this checklist to ensure every FDS has the right sections and the right level of detail. Tie states/transitions to modes (525) and interlocks (352), embed I/O tables (523), and reference HMI layouts (524). Include acceptance criteria aligned to ITP (714) and SAT (638). Revision history and distribution prevent outdated logic from reaching HVM bollard sites. Link back for context in this section and the chapter hub. If authority approvals apply in the UAE, see SIRA Bollards (UAE). For install-phase context only when useful, visit 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.
712.1 Administrative header
Project, site, rev, date, and IDs. Header traces HVM bollard documents (911, 115).
Use a consistent naming scheme that matches your File Index & Naming Rules (911) and the Versioning & Numbering (115). Include a unique Release ID and mark status (Draft, IFC, Issue-for-Use) to avoid configuration drift. Add project codes, lane IDs, and Lane identifier so every diagram, table, and SAT step can reference the same objects.
Where the project requires authority review, add an “Approvals” line linking to Authority Submittals (717) and note any bilingual policy for issued packs.
| Aspect | What matters | Where to verify |
|---|---|---|
| Identity | Project/site IDs, lane IDs, Release ID | Versioning & Numbering |
| Status | Draft/IFC/Issue-for-Use & distribution | Variations & Change Log |
| Traceability | Cross-refs to drawings & packs | Handover Pack Index |
712.2 System overview
One-page block diagram and narrative (521). Overview orients crash rated bollard reviewers.
Summarize the lane architecture from Control Architecture (521): bollard set, drive (hydraulic or electro-mechanical), safety devices & measures (343), and integrations (530–536). Keep it one page: a block diagram plus a short narrative that states the lane purpose and normal/exception modes.
Include environmental constraints (hot climate, acoustics, ingress protection) by linking to acoustic limits (546) and enclosure protection (516). This primes reviewers before they dive into detailed logic.
712.3 States & transitions
State table with entry/exit rules (526). Tables reduce HVM bollard ambiguity.
Define the state machine (526) in a tabular form: State, Entry Conditions, Actions, Exit Conditions, Timeout, and Next States. Tie each transition to modes of operation (525) and to interlock matrix rows (352) so there’s one source of truth.
Explicitly cover failure paths: movement timeout, comms loss, power failure modes (518), and EFO cooldown. Use a small diagram for EFO timing windows and add references to test steps in EFO & Failure Modes (637).
712.4 I/O point table
Tag, type, range, normal/abnormal (523). Table stabilizes crash rated bollard commissioning.
Build from the I/O list (523). Columns: Tag, Service, Type (DI/DO/AI/AO), Range, Engineering Units, Normal State, Abnormal State, Safety Class, Terminal, Cable/Core, and Notes. Add ferrules and terminal mapping to speed FAT/SAT.
Flag safety-related I/O (photo-eyes, edges, loops) and provide simulator references from Commissioning Tools (529) for repeatable proving in Loop & Sensor Proving (633).
712.5 Interlock matrix link
Embed matrix ID and storage path (352, 539). Link keeps HVM bollard logic aligned.
Insert the matrix filename, version, and repository path (e.g., Docs/Controls/Interlocks/…) plus a Matrix Row Traceability note so each FDS transition references a specific row. Cross-link to Integration Documentation (539) for where the live file is stored and governed.
Call out the witnessable steps that verify the matrix in the field and reference Interlock Matrix Verification (634) to avoid duplicated scripts.
712.6 HMI/alarms section
Screens, messages, colors, permissions (524, 536). Clarity prevents crash rated bollard operator error.
Provide the HMI screen list and navigation, roles/permissions (RBAC), and the alarm philosophy (536). Each alarm needs: text, priority, color, latching, inhibit rules, operator recovery hint, and KPI impact (e.g., Ops/hour freeze).
Include annunciation devices (beacons, sounders), night-mode behavior, and a summary of nuisance-alarm prevention (shelving, hysteresis). Provide example screenshots or wireframes so reviewers can visualize messages before SAT.
712.7 Acceptance criteria
Numeric thresholds and pass/fail notes (714). Criteria close HVM bollard disputes.
List measurable criteria for cycle time, stopping distance, EFO timing, alarm latency, and power ride-through, and tie each to the Inspection & Test Plan (ITP) (714). Where relevant, add references to Performance & Duty Tests (636), Obstruction & Intrusion Tests (635), and EFO & Failure Modes (637).
Add evidence requirements (log files, photos, videos) and point to Evidence Capture Standards (716) to keep submissions consistent.
712.8 Revision history
What changed, when, by whom (537). History protects crash rated bollard traceability.
Record every change with date, author, reviewer, reason, and affected sections. Reference Change Control & Versioning (537), and keep a delta-highlight list for reviewers. When logic or safety behavior changes, update the linked interlock matrix and the Change Log (718) so the SAT script stays aligned.
712.9 Distribution list
Recipients and access level. Control prevents HVM bollard version drift.
List recipients, role, and access (view/edit). Store the controlled PDF in your submissions repository and include a Snapshot PDF for reviewers. For UAE projects, note if the pack is submitted to authorities; see SIRA Bollards (UAE) for the approvals pathway.
Remind teams that only the “Issue for Use” copy is valid on site and that superseded files must be removed per the Final Archive & Retrieval (939) policy.
Related
External resources
- NPSA: Hostile Vehicle Mitigation guidance
- FEMA 426 / DHS: Building security reference
- ASIS: Security Risk Assessment Standard
712 FDS Fields — FAQ
What’s the minimum content an HVM FDS must include?
At minimum: an administrative header, a one-page system overview, states & transitions tied to the interlock matrix, a complete I/O table, an HMI/alarms section, measurable acceptance criteria linked to the ITP/SAT, a revision history, and a controlled distribution list.
How do I keep the FDS and interlock matrix in sync?
Give the matrix a unique filename/version, store it in a controlled repository, and reference its ID and path inside the FDS. Use row-level traceability and update both documents under the same change request before testing.
Where do acceptance criteria live—FDS, ITP, or SAT?
Authoritative thresholds should be listed in the FDS and mirrored in the ITP, while the SAT script references those same thresholds in its step-by-step checks. The three must agree word-for-word to avoid disputes.
Who should be on the FDS distribution list?
Designers, controls engineers, commissioning leads, the Owner’s Engineer, the main contractor, the vendor, and (where applicable) the authority reviewer. Assign edit vs view rights and remove superseded copies from site.