Many plants pay for a program that runs — and never receive what they need to maintain it themselves.
When a line stops, the first two questions are always: do we have a copy of the program, and does anyone understand it? The list below exists to answer both. It is not moral advice about suppliers working harder — every item can be written into a contract as an acceptance criterion.
We write PLC programs for a living (Siemens S7-1200/1500). This is what we hand over, and why each piece matters.
1. The program itself (SCL / LAD / FBD)
What it is: complete source you can open and recompile in TIA Portal.
Why it matters: many sites only ever receive "the version currently running in the PLC." If all you hold is what is on the device, every future change becomes an online edit — with multiplied risk and cost.
Without it: the next maintenance job goes to whoever wrote it last, at whatever price they name.
2. I/O allocation table
What it is: a cross-reference between physical addresses (I0.3) and real meaning ("clamp cylinder position sensor") — address, symbolic name, process meaning, signal type.
Why it matters: this is the dictionary between the electrical drawings and the program. Without it, tracing a single signal is guesswork.
Without it: fault-finding takes many times longer and depends entirely on someone's memory.
3. POU structure description
What it is: the hierarchy of function blocks — which block handles a cylinder, which handles alarms, which handles communications, and how they call each other.
Why it matters: PLC programs are not hard because of syntax. They are hard because you must hold dozens of causal relationships in your head at once. A good structure diagram turns that into reading a map.
Without it: a new engineer spends days just working out how the program is organised.
4. Compile log
What it is: the actual compilation output from TIA Portal, plus how each warning was handled.
Why it matters: "no errors" and "does it compile" are two different statements. The log is hard evidence, not a promise.
Without it: you have no way to confirm the program really compiles cleanly before it goes on the machine.
5. Static analysis report
What it is: rule-based automated checks (division-by-zero risk, array bounds, unnamed constants, nesting depth, comment ratio), and an explicit statement of which layer it did not check.
Why it matters: it catches one layer of defects. Equally important is saying which layer it cannot see.
⚠ An honest reminder: static analysis cannot see semantic errors. Flip an AND to OR in a start condition — the logic is now exactly backwards — and no text- or structure-based tool will catch it. Never let "it passed static analysis" be used to imply "the logic is correct."
6. Verification records + the open-items list
What it is: two parts.
- Verification records: simulation trace comparisons, state-transition and timer-timing checks.
- Open-items list: the site conditions that were never confirmed, each stating the branch action for both "if yes" and "if no."
Why it matters: that second part is what almost nobody hands over. It tells you which assumptions the program makes about your plant — and what happens if an assumption is wrong.
Without it: you receive a program that "works" without knowing what it depends on.
Put these three sentences in the contract
- Deliverables list — enumerate the six items above, with file formats.
- Acceptance criteria — write them as verifiable assertions. "Executes the sequence in section 3.2 correctly, 10 consecutive runs" beats "logic is correct."
- Scope statement — state what is out of scope: electrical design, switchgear assembly, and functional safety (SIL/PL) sign-off must be done by a qualified party.
That last one is not about pushing work away — it is about avoiding the misunderstanding that, in our experience, is the single most common reason a job drags on.
We develop and verify Siemens S7-1200/1500 PLC programs — and we hand over all six documents above as part of the standard scope, not as an add-on. How we work: plc.aiepco.com
Top comments (0)