All logic crammed into OB1
The main program spans hundreds of networks with no functional separation; any change requires reading the whole thing to judge its impact.
Capability 01 · PLC Program Refactoring & Standardization
The program still runs, but nobody dares to touch it
The program still runs, but nobody dares to touch it
Refactoring is not rewriting — it's bringing the structure back under control
A line that has run for eight years, through four engineers' hands: the same action implemented in three places, timer numbers remembered by rote, an alarm list of nothing but abbreviations, and a single parameter change requiring three line stops to test. Refactoring isn't a rewrite — it's organizing the program into a form someone else can take over, without changing process behavior.
¥28,000+ (≈US$3,900+)Single machine / single station
4–8 weeksTypical timeline; can be done in staged shutdowns
Rollback at every stepEach replacement keeps the previous version
Process logic untouchedOnly structure changes; behavior differences itemized
What kind of program needs refactoring: not one that "looks poorly written," but one that has started generating real costs — change one thing and three others break, new hires take three months to become productive, line-down troubleshooting comes down to guessing, the same fault keeps recurring, or there's no obvious place to add a new feature. If three or more of these apply, refactoring usually pays for itself within a year through reduced downtime and labor.
Six typical symptoms
Variables are bare addresses
M10.3, DB2.DBD14, VW100 written directly into logic — no symbolic names, no units, no range documentation.
The same action implemented in multiple places
The same process written separately at each station; fix one place and miss three, and the versions start to drift.
Alarms are abbreviations only
Alarm messages like "E-07" and "Fault 3" that operators can't read; troubleshooting relies entirely on veteran employees' memory.
Parameters aren't in recipes
Process parameters scattered across DBs, the HMI, and paper records; changeovers are done by hand-copying, which invites errors.
No version control
The program lives on a single laptop, with filenames like "final-rev3-really-final."
How refactoring works
Six stages, each with a verifiable output; no requirement to do it in a single line shutdown.
- Baseline archive (1–2 days): read and archive the original program, record cycle times and parameters of key motions, and capture screen recordings as evidence. Every later comparison is against this baseline.
- Structure mapping (3–5 days): map the actual call tree and data flow, flag duplicated implementations, dead code, and cross-block coupling points, and produce a "Refactoring Scope & Risk List."
- Convention definition (2–3 days): together with your maintenance lead, define naming rules, block granularity, interface conventions, and alarm numbering rules — conventions your own team can follow, not ones we impose unilaterally.
- Staged refactoring (the bulk of the work): split the program by machine unit or station into FBs, unify interfaces, move parameters into recipe DBs, and consolidate alarms into a single alarm list. After each segment, compare behavior in simulation or on a spare CPU.
- Verification & regression: verify action sequence, interlocks, E-stop, and safety circuits station by station; produce a "Behavior Difference List" where anything different from the original is itemized with its reason.
- Delivery & handoff: program package, variable dictionary, functional specification, version repository, and change guide; half a day walking your engineers through the code.
Deliverables
Refactored programComplete project + uploadable archive package
Variable dictionarySymbolic name / address / type / unit / range / owning unit
Block structure documentationCall tree, and each FB's responsibility and interface
Alarm listNumbering rules, trigger conditions, handling suggestions
Behavior difference listItemized comparison with the original program, with reasons
Version repositoryGit repository or versioned archive, with commit messages
Change guideWhere to change and where not to change when adding features later
Three tiers (excl. tax)
Determined by line count, number of stations, and coupling; the final written quote after assessment is authoritative.
| Tier | Applies to | Reference price |
|---|---|---|
| Small | Single machine, ≤3,000 lines, ≤2 stations | ¥28,000–45,000 (≈US$3,900–6,300) |
| Medium | Single line, 3,000–10,000 lines, 3–8 stations | ¥45,000–120,000 (≈US$6,300–16,900) |
| Large | Entire line or workshop, >10,000 lines, multi-unit coordination | ¥120,000–300,000 (≈US$16,900–42,300) |
Worth doing
The equipment will run for 5+ more years; program-related downtime exceeds 3 incidents a year; you need to connect MES / HMI/SCADA / data acquisition; you want to hand maintenance to an internal team or a third party; you're preparing for export or localization.
The equipment will run for 5+ more years; program-related downtime exceeds 3 incidents a year; you need to connect MES / HMI/SCADA / data acquisition; you want to hand maintenance to an internal team or a third party; you're preparing for export or localization.
Not recommended
The equipment will be scrapped or replaced within two years; you just want it to "look tidy" without a real problem; the program is small (a few hundred lines) with no expansion needs — in that case documentation alone is enough.
The equipment will be scrapped or replaced within two years; you just want it to "look tidy" without a real problem; the program is small (a few hundred lines) with no expansion needs — in that case documentation alone is enough.
One boundary: refactoring changes structure, not process. If the assessment finds defects in the process logic itself (missing interlocks, safety circuits dependent on software, cycle time mismatched to mechanics), we list them separately and let you decide whether to open a separate modification project — we won't quietly change them and tell you later.