How should a plant control PLC logic changes during maintenance?
A small online logic edit can change how a machine starts, stops, alarms or protects itself. Treat controller logic as an engineered configuration, not a technician's private file. The maintenance process should prove what changed, why it changed, who approved it and how the plant can safely recover.
Start with a controlled baseline
Identify the controller, asset tag, project file, software and firmware versions, I/O configuration, network dependencies and last approved backup. Record who can read, edit, download and approve logic. The source project should have a controlled location and revision history. A file copied from an unknown laptop or an old commissioning drive is not a reliable baseline.
Describe the intended behavior before editing
The change request should explain the observed problem, affected operating modes, expected sequence, safety and environmental implications, affected alarms and interlocks, and the planned verification. Compare the proposed change with the approved functional description, cause and effect matrix and drawings. If the site has a covered process, evaluate whether OSHA PSM management of change applies. Even when it does not, the change still needs a documented technical review.
Require a defined test and rollback plan
- Before: capture and verify a restorable backup, compare online and offline versions and confirm controller health.
- Approval: obtain operations and engineering authorization, with the intended maintenance window and risk controls.
- Test: use simulation or an offline test environment where practical; define safe field tests and acceptance criteria.
- Recovery: identify the exact rollback file, responsible person and conditions requiring rollback.
- Closeout: archive the approved as left logic, test evidence, changed drawings and handover record.
Protect the live controller and its access path
Use named accounts, least privilege, approved engineering workstations, controlled removable media and documented remote access. Coordinate with OT security. NIST SP 800-82 Revision 3 describes OT security practices that must account for physical process reliability and safety. Cybersecurity checks should not become an excuse to skip functional safety review, and a successful download does not prove that the process behaves correctly.
Practical example: nuisance motor trip
An engineer proposes increasing a PLC timer to prevent nuisance trips. Before editing, the team checks whether the timer protects equipment, whether a failed sensor or process upset caused the trips, and whether changing the delay would permit damage. The revised logic is compared with the baseline, reviewed, tested in the permitted operating envelope and documented. If the evidence is insufficient, the timer stays unchanged while the underlying cause is investigated.
Measure configuration discipline
Track unapproved online edits, missing backups, failed restore tests, change packages without functional verification and overdue as built documentation. Review a sample of completed changes during reliability and OT security audits. The goal is an auditable chain from defect to approved configuration and verified operating behavior.
Explore KANE consulting
Discuss practical maintenance and reliability improvements for your facility.
Request a consultation →Related answers: management of change handover · obsolete control system spares
Technical references
NIST SP 800-82 Revision 3, Guide to OT Security · OSHA Process Safety Management, 29 CFR 1910.119