FDS (Functional Design Specification)

A Functional Design Specification (FDS) is an engineering document that describes exactly how an automation system will function to meet the requirements defined in the User Requirement Specification (URS). While the URS says what the system must do, the FDS describes how it will do it — covering control logic, sequence of operations, alarm handling, HMI screen layouts, and interface specifications.

**FDS vs Other Project Documents:**

| Document | Purpose | Written By | When | |----------|---------|-----------|------| | URS (User Requirement Specification) | What the system must do | End user / process engineer | Project start | | FDS (Functional Design Specification) | How the system will work | Control system engineer | After URS approval | | DDS (Detailed Design Specification) | Specific implementation details | PLC programmer | After FDS approval | | FAT (Factory Acceptance Test) | Verify system works as designed | QA / commissioning team | Before shipment |

**Typical FDS Structure (ISA-88 / GAMP5 Compliant):**

1. **System Overview** — Architecture diagram, hardware list, network topology 2. **Control Philosophy** — Operating modes (Auto/Manual/Maintenance), safety interlocks, startup/shutdown sequences 3. **Functional Descriptions** — Unit-by-unit description of every control loop, sequence, and interlock 4. **I/O List** — Every input and output with tag name, signal type, range, and engineering units 5. **Alarm Specification** — Alarm types, priorities, setpoints, and required operator actions 6. **HMI/SCADA Specification** — Screen layouts, navigation flow, color standards, access levels 7. **Interface Specifications** — Communication protocols, data exchange with MES/ERP, third-party systems 8. **Reporting Requirements** — Batch records, trend logs, production reports

**When to Write an FDS:** An FDS is required for any automation project that involves multiple stakeholders, regulatory compliance (FDA, GAMP5, ISA-88), or systems complex enough that the PLC programmer cannot hold the entire design in memory. In practice, projects above 200 I/O points almost always benefit from a formal FDS.

**Common Mistakes:** 1. Writing the FDS too vaguely — statements like 'the system shall control temperature' are useless without specifying the control method, setpoint source, PID tuning approach, and alarm limits. 2. Skipping the FDS and jumping straight to PLC programming — this leads to scope creep, rework, and disputes about what was agreed upon. 3. Not tracing FDS requirements back to URS requirements — every FDS section should reference which URS requirement it satisfies. 4. Treating the FDS as a one-time document — it should be updated whenever the control logic changes, serving as the living reference for the system.