Call tree & block responsibility table
The actual call relationships (not the as-designed assumptions), plus each OB/FB/FC's responsibility, callers, callees, and execution conditions.
Capability 02 · Program Structure Analysis & Documentation
Only one engineer can read the program
Only one engineer can read the program
That's the plant's biggest single point of failure
The equipment works. The drawings are lost, the I/O list is hand-copied, and only one person can change the program. When that person takes leave, quits, or just gets sick, the whole line enters a "don't touch it" state. What documentation does is simple: it writes the facts in the program into a form anyone can look up.
¥12,000+ (≈US$1,700+)Single machine (≤2,000 lines)
5–10 business daysTypical timeline
Usable without usDocumentation stands alone, not tied to our service
Fact-basedGrounded in the on-site program, not the original drawings
Documentation is not "translating the program into plain language." Many "program descriptions" just narrate each network one by one, and after reading them you still don't know where to change anything. Useful documentation answers four questions: where does this signal come from, what does it pass through, and where does it go; what conditions trigger this action; when this alarm fires, what do you check first; and which block should you touch to add a feature.
Five things we deliver
Variable dictionary
Symbolic name, absolute address, data type, unit and range, read/write party, and owning machine unit; covers DB, M, I/O, and HMI-linked variables.
I/O list rebuild
Rebuild the input/output list based on actual on-site wiring and program usage, marking spare points, jumpered points, and points unused by the program.
Functional specification
Described segment by segment: start conditions, interlocks, timing, and fault handling; with timing diagrams or flow charts — no code dumps.
Maintenance manual
Diagnostic paths for common faults, a list of adjustable parameters with safe ranges, backup and restore steps, and items to confirm before making changes.
How we produce trustworthy documentation
- Ground truth is the field, not the drawings. First verify actual modules, firmware versions, and wiring, then read the program. Discrepancies between drawings and field are listed separately as a "Discrepancy Table" — which is itself a hazard-identification exercise.
- Map first, write later. Use cross-references to list every write and read point of every variable; the logic diagram grows out of the data flow, not out of impressions.
- Cross-verify. Every key conclusion is verified at least two ways: program cross-reference plus field motion confirmation, or plus HMI screen behavior.
- Have the person who owns it read it. The draft goes to whoever currently maintains the machine; when they say "this is wrong," we go back and check — this step catches most assumed mistakes.
Tiers (excl. tax)
Line counts are based on actual program blocks; on-site verification is billed separately as travel.
| Scope | Includes | Reference price |
|---|---|---|
| Single machine | ≤2,000 lines, incl. I/O list and maintenance manual | ¥12,000–20,000 (≈US$1,700–2,800) |
| Single production line | 2,000–8,000 lines, 3–8 stations, incl. functional specification | ¥20,000–48,000 (≈US$2,800–6,800) |
| Whole plant / multiple lines | >8,000 lines, cross-line relationships, incl. asset register | ¥48,000+ per line (≈US$6,800+) |
| Incremental maintenance | Documentation kept in sync with changes (annual) | ¥6,000+/year (≈US$800+) |
How this differs from "program rescue": rescue solves "the program doesn't exist yet / can't be extracted"; documentation solves "the program exists, but nobody can explain it." The two are often done together — first extract the program, then do structure and documentation. If you don't even have the original project, see Program Rescue & Custody first.
Frequently asked questions
After the documentation is done, do we still need you?
No — that's the design goal. The documentation, variable dictionary, and I/O list are standalone deliverables in Excel / Word / PDF, unencrypted and not tied to our tools. You'd only call us again if you need someone to handle future changes — which is a different engagement.
What if the OEM won't provide drawings?
Rebuild from the field. Module models, wiring, and sensor types can all be verified on site, and the addresses and symbols in the program let us infer the meaning of most signals. The rebuilt I/O list marks each point as either "field-confirmed" or "program-inferred," with inferred items recommended for point-by-point verification during the next shutdown.
Will you write out our process secrets?
No. The documentation describes only signals and control relationships, not actual recipe values or process parameter settings (those are written as "provided by recipe DB"). We sign an NDA before delivery, and the documentation goes only to the people you designate.