You have just been handed a machine that runs — but nobody can explain it. The previous engineer left, the original documentation is gone, or the system was simply "commissioned in a hurry and never cleaned up".
The most natural move is also the most expensive one: open TIA Portal and start editing.
This is the sequence we use when a customer asks us to rescue or diagnose an inherited program. It is deliberately boring, and it exists because the exciting version fails.
Why you cannot start by fixing
In a program that runs, the "obviously redundant" logic is very likely a patch someone added after an incident. You can see the code; you cannot see the incident.
If you change it without a baseline and without evidence, you do not remove the problem — you replace it with a different one. And the new problem is usually harder to find, because you introduced it yourself. Two weeks later you are back at the starting point, now with a second unknown in the system.
The 4 things, in order
① Capture evidence before you touch anything
Archive everything you can currently get:
- the program uploaded from the PLC, as it is right now
- the diagnostic buffer
- the alarm history
- the actual state of the main I/O points
- the operator's description of when things go wrong (spoken words are data too)
This is the raw material for every judgement you will make later. Once you start editing, the state of the machine at handover is gone forever. It is the one thing you cannot re-create.
② Establish a version baseline
Save the uploaded program with a dated archive entry and one sentence: "This version was uploaded from the machine on , unmodified."
It feels trivial. It is the only basis on which you will later be able to say what you changed and why — and the only starting point the next person can take over from.
③ Shrink the search space with static analysis and reasoning
Do not guess from the symptom. Run the program through tooling first: division-by-zero risk, array access without bounds checks, block call depth, unused variables, naming inconsistencies. You are not looking for the bug yet — you are trying to convert "one large unknown program" into "four suspicious blocks".
Then list the plausible causes and rank them by likelihood. Resist the urge to work through them in the order they occurred to you.
④ Change only after the root cause is verified
Confirm the root cause in simulation or by single-stepping on site. Then change. Then run a regression pass, because breaking B while fixing A is the normal case, not the exception.
Every change gets the same archive treatment as step ②.
A ratio worth remembering: when taking over an inherited program, about 90% of the time belongs to "understanding what it currently is", and 10% to "making it what I want". Invert that ratio and you will be back at the start in two weeks.
What to ask the other side for
Ask even if the answer is "we don't have it" — a "no" is itself information about how the system has been maintained.
- A program backup. Any version, the older the better — old versions are what you compare against.
- PLC model and firmware version (the order number is the accurate one).
- I/O list or electrical drawings — even a draft.
- Which faults have occurred historically, and what was done about them.
- Who knows why a particular piece of logic is written the way it is. That person is worth more than any document.
Scope note (what remote work can and cannot cover)
Program-level investigation — uploading, static analysis, logic review, root-cause reasoning — can be done remotely, and that is how we usually start.
What cannot be done remotely: wiring and hardware replacement, capturing real machine traces, and independent verification of safety functions. Those need hands on the machine.
We publish this because we think the boundary should be stated up front rather than discovered in week three.
This is a cross-post. The original article lives at plc.aiepco.com/en/notes/takeover-checklist/, and our full engineering process is documented at plc.aiepco.com/en/process/.
Top comments (0)