A PLC functional specification describes, in plain language, how a machine or process must behave under control: its modes, sequences, interlocks, alarms and interfaces. It is written before the code, agreed by the process owner, and used afterwards to write test cases. A good one lets a programmer who has never seen the plant build the right software, and lets an operator check that it is right.
Different industries call it different things: functional design specification (FDS), control philosophy, control narrative or functional requirements. In regulated sectors it sits within a wider lifecycle such as ISPE GAMP 5. The content is broadly the same everywhere.
A section-by-section structure for a PLC functional specification
| Section | What it contains |
|---|---|
| 1. Scope and references | What is in and out of scope, drawings, P&IDs, standards, related documents |
| 2. System overview | Process description, equipment list, control architecture, network sketch |
| 3. Operating modes | Auto, manual, maintenance, cleaning, and how the operator moves between them |
| 4. Sequences | Step-by-step logic for each unit, with entry and exit conditions |
| 5. Interlocks and permissives | What must be true before anything moves, and what stops it |
| 6. Alarms and events | Each alarm, its trigger, priority, operator action and reset |
| 7. HMI requirements | Screens, navigation, user levels, trends |
| 8. Interfaces | Signals and data exchanged with SCADA, MES, other PLCs and package units |
| 9. Safety functions | Reference to the risk assessment and safety requirements specification |
| 10. Data and reporting | Counters, batch records, OEE, energy, retention |
| 11. Test approach | How each section will be verified at FAT and SAT |
Writing sequences that cannot be misread
Sequences cause most arguments, so be precise. For each step, state the action, the condition to move on and what happens if that condition is not met within a time limit. A table works better than prose.
| Step | Action | Next step when | Fault if |
|---|---|---|---|
| 10 | Open infeed gate, start infeed conveyor | Product sensor B12 on | B12 not on within 8 s |
| 20 | Stop conveyor, clamp product | Clamp closed switch S21 on | S21 not on within 2 s |
| 30 | Start labeller cycle | Labeller done signal | Labeller fault or 5 s timeout |
| 40 | Unclamp, start outfeed | Product clear of B14 | B14 blocked for more than 4 s |
What is a Functional Design Specification (FDS)?
RealPars
This video is hosted on YouTube. Playing it loads content from Google, which may set cookies.
Watch on YouTubeUse existing models rather than inventing your own
For batch processes, structure the specification around the ISA-88 physical and procedural models: units, equipment modules, phases. For packaging and discrete machines, consider the PackML state model from OMAC, adopted by ISA as ISA-TR88.00.02. Using a recognised model means programmers, integrators and the next maintenance engineer share a vocabulary, and machines from different builders behave consistently.
The mistakes that cause rework
- Describing the code instead of the behaviour. 'Use a TON timer in FB12' belongs in the design, not the specification.
- Leaving out abnormal operation. Power loss, e-stop recovery, partial batches and manual intervention are where most bugs live.
- Vague alarms. 'Alarm if pressure is high' needs a value, a delay, a priority and an operator action.
- No owner. If operations never signs it, the first real review happens at SAT.
- Never updated. Changes agreed on site must flow back into the document, or it becomes fiction.
From specification to test cases
Number every requirement. Each sequence step, interlock and alarm should map to at least one test case. This traceability is what makes a factory acceptance test objective rather than a demonstration, and it is the input you need to test code against a simulated machine before site. It is also the best prompt you can give an AI coding assistant, as we discuss in AI for PLC programming.
Example: an alarm table that leaves nothing to guess
| Alarm | Trigger | Priority | Effect | Operator action |
|---|---|---|---|---|
| Infeed jam | B12 on for more than 4 s while conveyor running | Medium | Infeed stops, upstream held | Clear jam, press reset |
| Clamp fault | S21 not on 2 s after clamp command | High | Station stops in step 20 | Check air, inspect clamp, reset |
| Low air pressure | PS01 below 5.5 bar for 3 s | High | Controlled stop at end of cycle | Check supply, call maintenance |
Written this way, the programmer knows exactly what to build, the HMI designer knows the text and priority, and the tester has a ready-made test case for each line. It also exposes gaps early: if nobody can say what should happen to upstream equipment during a jam, better to find out in a review meeting than during start-up.
Who should write it?
Ideally, a controls engineer writes it with the process owner, and operators review the modes and alarms. When a supplier writes it, the buyer must still own the review; a specification written only by the party being paid to meet it tends to be easy to meet. On remote projects the specification matters even more, because it replaces many of the informal conversations that happen on site.
Wartens can write or review functional specifications as the first phase of a project, then engineer and test the software against them. See our automation engineering service or send us your current document for a review.
