A PLC software specification describes what the control software must do, station by station and mode by mode, in enough detail that someone who has never seen the machine can program it and test it. In German practice it is the Pflichtenheft that answers the customer's Lastenheft, and VDI/VDE 3694 gives a recognised structure for both in automation projects (DIN Media, VDI/VDE 3694). If you plan to outsource PLC programming, the specification is the single document that most decides whether you get what you need.
Here is the structure we ask clients for, and the one we write ourselves when they do not have it.
What a PLC software specification must contain
| Section | Content | Typical source |
|---|---|---|
| Scope and interfaces | Machine boundary, upstream and downstream equipment, MES, robots, drives | Project lead |
| Platform and standards | PLC family, software version, libraries, coding rules | Controls lead |
| Operating modes | Automatic, manual, setup, maintenance, emptying; how modes change | Process engineer |
| Station descriptions | Sequence per station, step by step, with conditions and timeouts | Process engineer |
| Interlocks | What may not happen together, and why | Process and safety |
| Faults and alarms | Every fault, its detection, reaction and recovery; alarm texts | Maintenance |
| Safety functions | Reference to the risk assessment and required Performance Level | Safety engineer |
| HMI | Screen list, user levels, recipes, languages | Operations |
| Data and communication | Tags to MES or SCADA, OPC UA interface, counters, energy | IT and operations |
| Acceptance tests | Test cases derived from all of the above | Everyone |
Use a state model instead of prose
The weakest part of most specifications is the description of modes and states, written as paragraphs that contradict each other. A standard state model removes the ambiguity. PackML, developed by OMAC and adopted by ISA as ISA-TR88.00.02, defines machine states, modes and a set of standard tags, with the aim of a common look and feel across a plant floor (OMAC). Even if your machine is not a packaging machine, borrowing the PackML state model for Idle, Starting, Execute, Stopping, Aborted and so on gives every station a shared vocabulary.
Write station sequences as tables
For each station, a step table beats a narrative. One row per step: step number, action, condition to move on, timeout and fault reaction. Programmers can implement it directly, and testers can turn each row into a test case. For example, a capping station:
| Step | Action | Next when | Timeout and reaction |
|---|---|---|---|
| 10 | Wait for jar in position | Sensor B1 on and capper ready | None (idle) |
| 20 | Clamp jar | Clamp end position B3 on | 2 s: alarm 201, release clamp |
| 30 | Lower capping head, start torque | Torque reached on drive | 3 s: alarm 202, raise head |
| 40 | Raise head, release clamp | Head up B5 and clamp open B4 | 2 s: alarm 203, stop station |
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 YouTubeStandards that help
- VDI/VDE 3694 for the structure of requirements and specification documents in automation projects.
- IEC 61131-3, now in its fourth edition from 2025, for the programming languages and program structure.
- PLCopen coding guidelines for naming and code construction rules, if you have no in-house standard.
- PackML (ISA-TR88.00.02) for states, modes and standard tags.
- GAMP 5 if the machine serves a regulated pharmaceutical or medical environment, where the functional specification is part of a risk-based validation approach.
Who should write it
The best specifications are written by the people who know the process, reviewed by the people who will maintain the machine, and checked by the people who will program it. In a small machine builder that may be three people in one meeting room. What does not work is leaving the specification to the programmer alone, because the programmer will fill every gap with an assumption, and assumptions are invisible until commissioning.
Keep the specification under version control alongside the code, with a change log. When a requirement changes during the project, the specification changes first, then the test case, then the code. That order keeps a fixed-price work package fair for both sides.
Common gaps we find
- Manual mode is described in one line, although it is where most operator questions and accidents arise.
- Recovery after a fault or power loss is missing. What happens to a product halfway through a station?
- Alarm texts are left to the programmer, in one language only.
- Interfaces to the line controller or MES are listed by name but not by signal, data type and handshake.
- No acceptance tests, so acceptance becomes a discussion instead of a check.
When the specification does not exist yet
Many good machines run on knowledge that lives in a senior engineer's head. That is not a reason to delay outsourcing; it is a reason to make the first part of the work package a specification phase. We interview the process and maintenance team, read the existing code or a similar machine's program, and write the specification for your review before programming starts. It becomes the basis for the code, the virtual commissioning tests and the acceptance.
Read how this fits into a fixed-price package in outsourcing PLC programming in Germany, or see our automation engineering services. Next step: send us the specification you have, however incomplete, and we will mark the gaps that would affect price and schedule. Contact us.
