Outsourcing PLC programming: the 6 documents to ask for
Many plants pay for a program that runs — and never receive what they need to maintain it themselves. Here are 6 deliverables worth writing into the contract, and what goes wrong when each one is missing.
It starts with one sentence
When a line stops, the first two questions are always: do we have a copy of the program, and does anyone understand it? This list 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.
The 6 documents
- ① The program itself (SCL / LAD / FBD)
- Complete source you can open and recompile in TIA Portal. Note: not "the version currently running in the PLC" — if all you hold is what is on the device, every change becomes an online edit, with multiplied risk and cost.
- ② I/O allocation table
- Address, symbolic name, process meaning and signal type. This is the dictionary between the electrical drawings and the program; without it, tracing a single signal is guesswork and fault-finding takes many times longer.
- ③ POU structure description
- Which block does what, and how blocks call each other. 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.
- ④ Compile log
- The real compilation output from TIA Portal, plus how each warning was handled. "No errors" and "does it compile" are two different statements; the log is hard evidence, not a promise.
- ⑤ Static analysis report
- Rule-based automated checks (division-by-zero risk, array bounds, magic numbers, nesting depth, comment ratio) — and an explicit statement of which layer it did and did not check.
- ⑥ Verification records and the open-items list
- Simulation trace comparisons, state-transition and timer-timing checks; and a list of site conditions still unconfirmed, each stating the branch action for "if yes" and "if no". Almost nobody hands this over unprompted — but it tells you which assumptions the program makes about your plant.
One honest statement that has to be made: static analysis cannot see semantic errors. Flip the AND in a start condition to OR — 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".
Put these three sentences in the contract
- Deliverables list: enumerate the 6 items above, with file formats
- Acceptance criteria: write them as verifiable assertions (e.g. "executes the sequence in section 3.2 correctly, 10 consecutive runs") rather than "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
How we work
We develop and verify Siemens S7-1200/1500 PLC programs (SCL, LAD, FBD), and the 6 documents above are part of our standard delivery list — not an add-on. We also state our boundaries up front: programs and verification only, no electrical design, no signing off on functional safety.