What the FDS Is — and What It Isn't
The Functional Design Specification is the engineer's answer to the user's requirements. Where the URS says what the system must achieve — in plain language, technology-neutral — the FDS says exactly how the system will achieve it, in engineering detail, using the specific platform chosen. It is the primary design document for your PLC/SCADA system and the reference that your FAT protocol is written against.
A well-written FDS makes every subsequent document easier to produce. The FAT test cases practically write themselves from a good FDS — because every function is described in enough detail to know what to test and what the expected result should be. A poorly written FDS creates ambiguity that compounds through the entire project: vague test cases, traceability gaps, and OQ deviations that trace back to design decisions that were never clearly stated.
If a sentence in your FDS doesn't reference a specific technology, platform, tag name, version number, or engineering parameter — it probably belongs in the URS, not the FDS. The FDS is where PLC block names, SCADA tag addresses, alarm setpoints, and network IP ranges live. The URS is where "maintain temperature within ±2°C of setpoint" lives.
FDS Document Structure
A GAMP 5 Category 4 FDS for a PLC/SCADA system should follow a consistent structure that allows both engineers and QA reviewers to navigate it. The standard sections:
Writing the Functional Description — The Core Section
Section 3 is where most of the engineering work lives. It describes every control function in enough detail that a test engineer can write a test case from it without asking questions. The minimum required for each function:
- Function name and URS reference — e.g. "Temperature Control Loop TIC_101 [URS-FUN-001]"
- Normal operating description — what the function does in automatic mode under normal conditions
- Control parameters — PID tuning values, setpoint ranges, scan rates, deadbands
- Operating modes — manual/auto/cascade, how mode changes are initiated, any mode interlocks
- Alarm conditions — each alarm tag, the setpoint that triggers it, the action taken (cross-reference to alarm section)
- Interlocks and safety functions — conditions that cause automatic actions, with logic description
- Failure modes — what the system does if a sensor fails, communication drops, or a limit is exceeded
The Alarm Section — What Gets Missed
The alarm section of the FDS is the document that drives your audit trail design and your OQ alarm test cases. For each alarm in the system, the FDS should define:
If the alarm section of the FDS is incomplete, the OQ alarm test cases will be incomplete. An OQ test that says "verify alarm activates" when the FDS says "alarm activates within 0 seconds with Priority 1 banner and initiates emergency cooling sequence" is testing a fraction of what was specified.
The Access Control Section — User Role Matrix
The access control section of the FDS defines every user role in the system and what each role can and cannot do. This section drives both the 21 CFR Part 11 access control OQ test cases and the system configuration during commissioning. It must be specific enough to configure the SCADA UMC directly from it.
The minimum content is a role permissions matrix — rows are user roles (Operator, Engineer, Supervisor, Administrator, QA), columns are system functions (acknowledge alarms, change setpoints, change alarm limits, modify recipes, create users, view audit trail, export reports). Each cell is either Permitted, Not Permitted, or Permitted with additional confirmation.
URS Traceability — Built Into the FDS
The most important structural feature of a good FDS is the URS reference column or reference tag in every section. Every functional description, every alarm, every access control rule should reference the URS requirement it implements. This is not administrative overhead — it is what allows the traceability matrix to be populated accurately and what allows a QA reviewer to confirm that every URS requirement has been addressed in the design before testing begins.
If a section of the FDS has no URS reference, it means either: something was designed that was never required (scope creep), or a requirement was missed and the URS needs to be updated via a controlled change before the FDS is approved.
The FDS must be approved before the FAT protocol is written. A FAT protocol written against an unapproved FDS is a finding — it means the test cases were defined before the design was confirmed. In practice this means the FDS approval date must be earlier than the FAT protocol authoring date. QA reviewers check document dates.
FDS Version Control — Why It Matters Post-Validation
After validation is complete, the approved FDS version is part of the validated system baseline. Any change to the system that affects the functional description requires a change control that includes an FDS update. The FDS version recorded in the VSR must match the version deployed on the system.
Engineers sometimes update the FDS to reflect "as-built" changes after the FAT without going through change control, treating it as a document correction rather than a change. If the change to the FDS reflects a change to the system's function — not just a correction of a description error — it is a change control event. The distinction is whether the system behaviour changed, not whether the document changed.
The FDS template is pre-structured with all six sections, including the alarm table with all required columns, the user role permissions matrix, and a URS traceability column in every functional description section. Section 3 includes sub-templates for PID control loops, batch sequences, and interlock logic — the three most common function types in pharmaceutical SCADA systems. Every section uses the same requirement ID format as the URS template, so the trace between documents is consistent from day one.