Search Knowledge Base Articles

Controls Change Management

CE-SOP-004 — CONTROLS CHANGE MANAGEMENT

Department: Engineering – Electrical Controls & Automation
Document Type: Standard Operating Procedure
Document ID: CE-SOP-004
Revision: Rev. 1.0
Status: Active Standard
Process Owner: Electrical Controls Engineering
Related Documents: CE-SOP-001, CE-SOP-002, CE-SOP-003, CE-SOP-006, CE-SOP-007

1. PURPOSE

The purpose of this Standard Operating Procedure is to establish a controlled, traceable, safe, and recoverable process for making changes to production controls and automation systems.

This procedure establishes requirements for:

PLC program changes
HMI application changes
SCADA changes
VFD configuration changes
Servo configuration changes
Industrial network changes
Remote I/O changes
Field I/O changes
Alarm changes
Setpoint changes
Sequence modifications
Interlock modifications
Permissive modifications
Controls hardware replacement
Firmware changes
Software upgrades
Temporary controls modifications
Emergency controls changes
Online PLC edits
Program downloads
Bypass logic
Test logic

The objective is to prevent uncontrolled or undocumented modifications from becoming a source of:

Production downtime
Safety risk
Equipment damage
Quality problems
Lost PLC/HMI programs
Unknown machine behavior
Troubleshooting difficulty
Configuration drift

2. CORE CHANGE MANAGEMENT PRINCIPLE

NO UNCONTROLLED CHANGES TO PRODUCTION CONTROL SYSTEMS.

Every significant change should answer:

WHAT is changing?

WHY is it changing?

WHO is making the change?

WHEN is it changing?

WHAT systems are affected?

WHAT could go wrong?

HOW will it be tested?

HOW will it be reversed?

WHAT documentation must be updated?

3. SCOPE

This SOP applies to production and facility controls systems including:

Allen-Bradley PLCs
Siemens PLCs
Other industrial controllers
PanelView HMIs
Siemens HMIs
C-More HMIs
SCADA systems
VFDs
Servo systems
Remote I/O
Industrial Ethernet devices
Managed switches
Gateways
Protocol converters
Instrumentation
Field devices
Control panels
Machine control systems

This SOP applies regardless of whether the change is performed by:

Controls Engineering
Maintenance
OEM
System Integrator
Contractor
Vendor
Outside Engineering firm

Outside personnel shall not be permitted to make uncontrolled production program changes simply because they supplied the equipment.

4. DEFINITION OF A CONTROLS CHANGE

A Controls Change is any modification capable of altering the behavior, configuration, operation, communication, diagnostics, or documentation of an automation system.

Examples:

Adding ladder logic
Removing logic
Changing a timer preset
Changing a counter preset
Adding an HMI button
Modifying an alarm
Changing an IP address
Replacing a PLC
Changing firmware
Changing drive parameters
Adding a sensor
Adding an output
Modifying an interlock
Adding a bypass
Changing a sequence
Modifying a recipe
Changing communication settings
Replacing hardware with a different model

5. CHANGE CLASSIFICATION

Every significant Controls Change should be classified before implementation.

CLASS 1 — MINOR

Low-risk modification with limited functional impact.

Examples:

HMI text correction
Non-functional screen layout change
Comment correction
Documentation correction
Minor diagnostic addition
Non-critical alarm wording change

CLASS 2 — STANDARD

Normal functional Controls Engineering modification.

Examples:

New PLC logic
Timer change
New alarm
New sensor
HMI command
Sequence modification
New I/O
VFD parameter modification

CLASS 3 — MAJOR

Significant modification with broad operational impact.

Examples:

Major sequence redesign
PLC replacement
HMI replacement
Network architecture change
Multiple-machine modification
Major firmware upgrade
Safety-related control modification
Major process control change

CLASS 4 — EMERGENCY

Unplanned modification required to address an immediate production, equipment, quality, or safety-related event.

Emergency status does not eliminate documentation requirements.

It may temporarily change their timing.

6. CHANGE REQUEST

Every planned Class 2 or Class 3 change should have a documented Change Request or linked Controls Project.

Minimum information:

Change ID
Project ID
Support Ticket
Date
Requestor
Equipment
Current Revision
Change Classification
Description
Reason
Expected Benefit
Production Impact
Safety Impact
Quality Impact
Downtime
Engineer
Planned Implementation Date

7. CHANGE IDENTIFICATION NUMBER

Recommended format:

CE-CHG-YYYY-####

Example:

CE-CHG-2026-0031

Link the Change ID to:

Support Ticket
Controls Project
PLC backup
HMI backup
Change Log
Commissioning record

This creates traceability:

SUPPORT TICKET

↓

PROJECT

↓

CHANGE

↓

BACKUP

↓

TEST

↓

FINAL REVISION

8. CHANGE DESCRIPTION

The Change Description shall clearly explain what is being modified.

Poor:

Changed Line 5 program.

Better:

Added infeed jam timer and Can Stop control.

Best:

Added five-second infeed photo-eye blockage monitoring. When blockage remains continuously present for five seconds during Auto operation, the PLC activates Can Stop, generates an HMI alarm, and requires the photo eye to clear before operator reset is accepted.

The Change Description should be understandable without opening the PLC program.

9. CHANGE JUSTIFICATION

Every significant change shall answer:

WHY ARE WE CHANGING THIS?

Examples:

Reduce downtime
Correct recurring failure
Improve operator diagnostics
Improve machine reliability
Add requested functionality
Address obsolescence
Improve quality
Replace failed hardware
Correct design deficiency
Improve maintainability

Avoid changes without a defined engineering purpose.

10. CHANGE AUTHORIZATION

Before implementation, determine who must authorize the change.

Possible authorization levels:

MINOR CHANGE

Controls Engineer approval may be sufficient.

STANDARD FUNCTIONAL CHANGE

Controls Engineer + appropriate operational stakeholder.

MAJOR CHANGE

Engineering Management + Operations + other stakeholders as required.

SAFETY-RELATED CHANGE

Follow applicable company safety review and authorization procedures.

The Controls Engineer shall not approve a change outside their authority.

11. PRE-CHANGE TECHNICAL REVIEW

Before modifying the system confirm:

☐ Correct equipment identified

☐ Correct PLC identified

☐ Correct HMI identified

☐ Correct project file identified

☐ Current-state logic understood

☐ Future-state requirement understood

☐ Affected routines identified

☐ Affected I/O identified

☐ Affected alarms identified

☐ Interlocks reviewed

☐ Permissives reviewed

☐ Failure modes considered

☐ Testing requirements established

12. PRE-CHANGE BACKUP

A RECOVERABLE BACKUP SHALL EXIST BEFORE SIGNIFICANT PROGRAM MODIFICATION.

Complete:

☐ Upload current PLC

☐ Save PRECHANGE PLC file

☐ Upload HMI where applicable

☐ Save PRECHANGE HMI file

☐ Verify files open

☐ Record software version

☐ Record firmware

☐ Record current revision

☐ Record IP addresses where applicable

☐ Verify rollback file

Recommended naming:

Equipment_Project_YYYY-MM-DD_PRECHANGE

Example:

Line5_DialOut_2026-10-07_PRECHANGE

13. KNOWN-GOOD VERSION

The engineer shall identify the:

LAST KNOWN-GOOD VERSION

This is the program/configuration known to have successfully operated the equipment before the planned change.

The known-good version shall not be overwritten.

14. ROLLBACK PLAN

Before implementation answer:

HOW DO WE RETURN TO THE PREVIOUS CONDITION?

Document:

PLC file
HMI file
Hardware configuration
Firmware
Required software
Required cables
Expected rollback time
Rollback decision authority
Rollback trigger

15. ROLLBACK TRIGGERS

Examples:

Machine cannot complete normal cycle.
Critical alarm cannot be resolved.
Unexpected equipment motion occurs.
Quality requirements cannot be maintained.
Communications become unstable.
Required commissioning cannot be completed within approved downtime.
New logic causes unrelated production failure.

Do not continue troubleshooting indefinitely during limited production downtime simply because considerable effort has already been invested.

Rollback is an engineering control—not a failure.

16. RISK REVIEW

Before implementation evaluate:

Personnel safety
Unexpected motion
Motor operation
Valve operation
Pressure
Temperature
Process chemicals
Automatic restart
Equipment damage
Product quality
Communication failure
Sensor failure
Output failure
PLC failure
HMI failure
Power loss

Higher-risk changes require greater review and testing.

17. SAFETY SYSTEM CHANGES

Changes involving:

Emergency Stops
Guard switches
Safety relays
Safety PLCs
Light curtains
Safety scanners
Safety-rated outputs
Safety interlocks

shall follow applicable company safety procedures, machine-safety requirements, validation requirements, and authorization processes.

Standard PLC logic shall not be used casually to defeat safety functions.

18. ONLINE PLC EDITS

Online edits are permitted only when appropriate for the platform, application, production condition, and risk.

Before performing an online edit:

☐ Confirm correct controller

☐ Confirm current operating state

☐ Confirm correct routine

☐ Understand affected logic

☐ Confirm backup

☐ Determine expected behavior

☐ Determine rollback method

☐ Determine whether production should be stopped

19. ONLINE EDIT RULE

DO NOT USE ONLINE EDITING AS A SUBSTITUTE FOR ENGINEERING DESIGN.

Online edits should implement a defined change.

They should not become uncontrolled experimentation on live production equipment.

20. ONLINE EDIT VERIFICATION

After accepting an online edit:

Immediately verify:

Expected rung behavior
Inputs
Outputs
Timers
Interlocks
Alarms
Machine response

Do not assume:

EDIT ACCEPTED

means:

CHANGE SUCCESSFUL

21. DOWNLOADS

Before downloading a PLC program:

☐ Verify correct PLC

☐ Verify correct project file

☐ Verify revision

☐ Verify processor compatibility

☐ Verify firmware

☐ Verify communication path

☐ Verify production status

☐ Verify downtime authorization

☐ Verify PRECHANGE backup

☐ Verify rollback file

☐ Understand download consequences

Be especially cautious where a download may:

Stop processor execution
Clear values
Reset states
affect outputs
cause equipment restart
modify communication configuration

22. HMI CHANGES

Before downloading or transferring an HMI application:

☐ Backup current HMI

☐ Record application name

☐ Record software version

☐ Record firmware

☐ Verify communication paths

☐ Verify PLC shortcuts/connections

☐ Verify startup display

☐ Verify alarm configuration

☐ Verify security

☐ Verify replacement application

After download test:

Navigation
PLC communication
Buttons
Indicators
Numeric entries
Alarms
Security
Startup behavior

23. VFD / SERVO CHANGES

Before changing drive parameters:

☐ Save existing parameters

☐ Record drive model

☐ Record firmware

☐ Record communication address

☐ Record changed parameters

☐ Understand motor/application requirements

☐ Establish rollback values

Never change drive parameters without recording the original values.

24. NETWORK CHANGES

Network changes include:

IP address
Subnet
Gateway
Managed switch configuration
VLAN
Port configuration
Device replacement
Communication path
PLC messaging
Produced/Consumed data
Remote I/O

Before implementation:

☐ Review network documentation

☐ Verify address availability

☐ Record existing configuration

☐ Identify affected devices

☐ Determine communication impact

☐ Coordinate with responsible IT/OT resources where required

Update network documentation after successful implementation.

25. I/O CHANGES

For new or modified I/O:

Document:

Device
Signal
PLC
Rack
Slot
Channel
Physical Address
Internal Tag
Voltage
Normal State
Active State
Fail State
Terminal
Wire Number
Drawing Reference

Test both:

PLC RESPONSE

and

PHYSICAL DEVICE RESPONSE

26. INTERLOCK CHANGES

Interlock changes require deliberate review.

Before changing an interlock determine:

Why does the interlock exist?
What condition activates it?
What equipment does it protect?
Is it process-related or safety-related?
What happens if removed?
What happens if bypassed?
What recovery is required?

Never remove an interlock solely because:

"It keeps stopping the machine."

Repeated interlock activation may be evidence of another problem.

27. PERMISSIVE CHANGES

Before removing or modifying a permissive determine:

What operation requires it?
Why was it originally required?
What failure does it prevent?
What happens when missing?
Does the HMI identify the missing permissive?

Where possible, improve diagnostics rather than simply eliminating the permissive.

28. TIMER CHANGES

A timer preset may appear to be a minor change but can significantly affect process behavior.

Before changing a timer:

Document:

Timer
Current Preset
Proposed Preset
Purpose
Reason
Minimum Acceptable Value
Maximum Acceptable Value
Testing Requirement

Avoid undocumented:

"I changed it from 5 seconds to 2 seconds."

29. HMI-ADJUSTABLE PARAMETERS

Where appropriate, frequently adjusted process parameters may be moved from hard-coded PLC values to controlled HMI setpoints.

When doing so define:

Default
Minimum
Maximum
Engineering units
Security level
Retention
Operator access
Maintenance access

Do not expose unrestricted engineering parameters without considering consequences.

30. BYPASS LOGIC

All bypasses require documented purpose and boundaries.

Record:

Bypass Name
Function
Reason
Activation Method
Authorized Users
Conditions Required
Functions Bypassed
Functions NOT Bypassed
HMI Indication
Alarm/Warning
Power-Cycle Behavior
Removal Requirement

31. BYPASS GOLDEN RULE

BYPASS THE PROCESS CONDITION ONLY WHEN ENGINEERING HAS DETERMINED IT IS APPROPRIATE.

DO NOT CASUALLY BYPASS SAFETY.

A bypass should be:

VISIBLE

CONTROLLED

DOCUMENTED

REVERSIBLE

and where appropriate:

TIME-LIMITED

32. TEMPORARY LOGIC

Temporary logic shall be tracked.

Examples:

Temporary bypass
Temporary timer
Temporary force
Test bit
Diagnostic rung
Temporary output command

Record:

Change ID
Date
Engineer
Reason
Equipment
Logic Added
Risk
Removal Date
Permanent Solution

Temporary logic shall not silently become permanent logic.

33. TEST BITS

Test bits may be useful for troubleshooting and commissioning.

They should:

Use clear names
Include comments
Be restricted where appropriate
Not unintentionally remain active
Be removed or intentionally retained after commissioning

Example:

TEST_AV19_Open

is preferable to:

TestBit3

34. FORCING I/O

Forcing physical I/O shall be treated as a controlled troubleshooting or commissioning action.

Before forcing:

☐ Understand physical consequence

☐ Verify correct point

☐ Determine equipment state

☐ Notify affected personnel where required

☐ Ensure safe condition

After testing:

☐ Remove force

☐ Verify all forces removed

☐ Confirm normal logic control restored

☐ Document significant force activity where appropriate

35. FORCE GOLDEN RULE

NEVER LEAVE A FORCE ACTIVE UNINTENTIONALLY.

Before leaving the equipment:

VERIFY THE CONTROLLER HAS NO UNINTENDED ACTIVE FORCES.

36. CHANGE COMMENTS

Where supported, significant program changes should include meaningful comments.

Recommended format:

Date – Change ID – Engineer – Reason

Example:

10/07/2026 – CE-CHG-2026-0031 – Added infeed jam timer and Can Stop control.

Comments should explain the reason for logic—not simply restate instructions.

37. DEVELOPMENT STANDARD

Changes should follow applicable department programming standards.

The modified logic should be:

Readable
Structured
Descriptive
Maintainable
Commented
Consistent
Testable

Avoid unnecessary cleverness.

The goal is not to create logic only the original programmer can understand.

38. CHANGE WINDOW

Planned functional changes should have an identified implementation window.

Document:

Date
Time
Expected Duration
Required Downtime
Production Contact
Maintenance Contact
Engineer
Vendor/Integrator
Test Duration
Rollback Duration

39. PRE-IMPLEMENTATION COMMUNICATION

Before significant implementation notify applicable stakeholders.

Communicate:

What is changing
Equipment affected
Planned time
Expected downtime
Expected behavior
Testing requirements
Potential risks
Who is responsible

Avoid surprising Operations with an unexpected PLC download.

40. PRE-CHANGE CHECKPOINT

Immediately before making the change ask:

AM I CONNECTED TO THE CORRECT MACHINE?

DO I HAVE THE CORRECT PROGRAM?

DO I HAVE A CURRENT BACKUP?

DO I KNOW WHAT I AM CHANGING?

DO I KNOW WHAT SHOULD HAPPEN?

DO I KNOW WHAT COULD GO WRONG?

DO I KNOW HOW TO TEST IT?

DO I KNOW HOW TO ROLL IT BACK?

If any critical answer is:

stop and resolve it.

41. IMPLEMENTATION

Perform the change according to the approved plan.

During implementation:

Make only required changes.
Avoid unrelated cleanup unless necessary.
Track deviations.
Record unexpected findings.
Maintain communication.
Monitor system behavior.

Do not expand project scope casually during commissioning.

42. UNEXPECTED CONDITIONS

If an unexpected condition is discovered:

Stop if necessary.
Make equipment safe.
Determine impact.
Document finding.
Determine whether original scope remains valid.
Determine whether change should continue.
Escalate where necessary.

Do not improvise major additional changes simply because the equipment is already down.

43. CHANGE DEVIATION

If the implemented change differs materially from the approved design, record:

Original Plan
Actual Change
Reason
Risk
Testing Impact
Documentation Impact
Approval where required

The final documentation must represent what was actually implemented.

44. COMMISSIONING

Every functional change shall be tested according to:

CE-SOP-007 – Controls Commissioning

At minimum verify applicable:

☐ Inputs

☐ Outputs

☐ Auto

☐ Manual

☐ Interlocks

☐ Permissives

☐ Timers

☐ Counters

☐ Alarms

☐ Reset

☐ HMI

☐ Communications

☐ Failure conditions

☐ Recovery

45. FAILED CHANGE

If commissioning fails:

Do not immediately continue making uncontrolled changes.

Determine:

CAN THE PROBLEM BE CORRECTED WITHIN THE APPROVED WINDOW?

If YES:

Correct and retest.

If NO:

Execute rollback.

Restore the known-good configuration.

Document:

Failure
Findings
Rollback
Next Action

46. POST-CHANGE VALIDATION

Following successful testing:

Confirm with applicable stakeholder:

☐ Requested functionality works

☐ Production can operate

☐ Operator understands change

☐ Maintenance understands relevant diagnostics

☐ No unexpected behavior identified

Record validation.

47. POST-CHANGE BACKUP

After successful commissioning:

CREATE A NEW PRODUCTION MASTER.

Complete:

☐ Upload final PLC

☐ Upload final HMI

☐ Save drive parameters where changed

☐ Save network configuration where changed

☐ Assign revision

☐ Update Change Log

☐ Archive PRECHANGE version

☐ Identify POSTCHANGE version as current master

Recommended:

Equipment_Project_YYYY-MM-DD_POSTCHANGE_REVX.X

48. CHANGE LOG

Every significant permanent change should appear in the Change Log.

Record:

Change ID
Project ID
Date
Engineer
Equipment
Previous Revision
New Revision
PLC Routines Changed
HMI Screens Changed
Hardware Changed
Description
Reason
Testing
Approval
Final Backup Location

49. DOCUMENTATION UPDATE

Update applicable:

☐ PLC program

☐ HMI application

☐ Electrical drawings

☐ I/O map

☐ Alarm list

☐ Network register

☐ Controls Asset Database

☐ Hardware inventory

☐ Software inventory

☐ Sequence of Operation

☐ Change Log

☐ Support Ticket

☐ Controls Project

☐ Knowledge Article

50. TEMPORARY CHANGE REVIEW

Before closing the project ask:

ARE ANY TEMPORARY CHANGES STILL ACTIVE?

Review:

Forces
Test bits
Temporary bypasses
Temporary timers
Temporary outputs
Debug logic
Temporary alarms
Maintenance overrides

Every temporary item shall be:

REMOVED

FORMALLY ACCEPTED AS PERMANENT AND DOCUMENTED.

51. EMERGENCY CHANGE PROCESS

Emergency changes may be required when immediate action is necessary.

Examples:

Production outage
Failed PLC hardware
Critical controls fault
Critical quality condition
Urgent equipment protection issue

Emergency process:

MAKE SAFE

↓

IDENTIFY PROBLEM

↓

BACKUP IF POSSIBLE

↓

ESTABLISH MINIMUM REQUIRED CHANGE

↓

IMPLEMENT

↓

TEST

↓

RESTORE OPERATION

↓

DOCUMENT

↓

CREATE POSTCHANGE BACKUP

↓

PERFORM FORMAL REVIEW

52. EMERGENCY CHANGE RULE

Emergency status does not mean:

"Anything goes."

It means:

The required engineering controls may occur faster, with some documentation completed immediately afterward.

Safety, backups, testing, and traceability remain important.

53. EMERGENCY CHANGE FOLLOW-UP

Within an appropriate period after stabilization:

☐ Complete Change Request

☐ Document root cause

☐ Document actual modification

☐ Complete risk review

☐ Complete Change Log

☐ Verify final backup

☐ Review temporary logic

☐ Determine permanent corrective action

☐ Update documentation

☐ Create Knowledge Article where useful

54. VENDOR / INTEGRATOR CHANGES

External personnel making changes shall follow site Controls Engineering requirements.

Before vendor work:

☐ Obtain current program

☐ Create PRECHANGE backup

☐ Understand planned change

☐ Establish scope

☐ Establish deliverables

☐ Establish final file requirements

After vendor work:

☐ Obtain modified PLC program

☐ Obtain modified HMI application

☐ Obtain source files

☐ Obtain passwords/credentials according to company policy

☐ Obtain configuration files

☐ Obtain Change Log

☐ Obtain updated drawings where required

☐ Verify final program

Never allow the only current source code to leave with the vendor.

55. PASSWORD-PROTECTED OR LOCKED PROGRAMS

Before accepting new equipment, determine whether:

PLC code is locked
AOIs are protected
HMI source is available
Drive configuration is accessible
Safety program access is available
Required passwords are company-controlled

Controls Engineering should understand maintainability limitations before equipment acceptance.

56. CHANGE FREEZE

Management or Controls Engineering may establish a Change Freeze during:

Critical production periods
Major product launches
Audits
High-volume periods
Known unstable conditions
Major network work

During a Change Freeze:

Only approved critical changes should be implemented.

57. UNAUTHORIZED CHANGES

If an undocumented or unauthorized controls change is discovered:

Do not immediately assume it should be removed.
Determine what changed.
Determine why.
Assess current risk.
Identify responsible personnel if possible.
Compare with known-good program.
Determine whether change should remain.
Document the decision.
Create current master backup.
Update records.

The priority is restoring control and traceability.

58. PROGRAM COMPARISON

Where supported, compare:

CURRENT RUNNING PROGRAM

against

LAST CONTROLLED MASTER

when unexplained behavior or suspected undocumented changes are identified.

Investigate differences.

Document legitimate differences.

Do not automatically overwrite the running program without understanding why it differs.

59. CHANGE MANAGEMENT STATUS

Recommended web-system statuses:

REQUESTED

Change identified.

UNDER REVIEW

Engineering evaluating change.

APPROVED

Change authorized.

DEVELOPMENT

Change being developed.

READY FOR IMPLEMENTATION

Required preparation complete.

IMPLEMENTING

Change currently being installed.

COMMISSIONING

Testing underway.

MONITORING

Change operating under observation.

DOCUMENTATION

Technical work complete; records being finalized.

CLOSED

Change fully documented and controlled.

ROLLED BACK

Original configuration restored.

CANCELLED

Change no longer required.

60. WEB SYSTEM — CHANGE MANAGEMENT TAB

Each project should contain a:

CHANGE MANAGEMENT

section containing:

CHANGE IDENTIFICATION

Change ID
Project ID
Support Ticket
Classification
Engineer
Date

DESCRIPTION

Current Condition
Proposed Change
Reason
Expected Result

RISK

Safety
Production
Quality
Equipment
Network

BACKUP

PLC PRECHANGE
HMI PRECHANGE
Drive Backup
Network Backup
Current Revision

ROLLBACK

Known-Good File
Rollback Method
Rollback Time
Rollback Trigger

IMPLEMENTATION

Date
Downtime
Stakeholders
Engineer
Vendor

TESTING

Commissioning Record
PASS/FAIL
Issues

FINAL

POSTCHANGE PLC
POSTCHANGE HMI
Final Revision
Change Log
Validation
Close Date

61. WEB SYSTEM AUTOMATION RULES

Recommended system logic:

IF CHANGE CLASS = STANDARD OR MAJOR

Require:

PRECHANGE BACKUP

before:

READY FOR IMPLEMENTATION

IF PLC CHANGED = YES

Require:

PRECHANGE PLC
POSTCHANGE PLC
Revision
Change Description

IF HMI CHANGED = YES

Require:

PRECHANGE HMI
POSTCHANGE HMI

IF INTERLOCK CHANGED = YES

Require:

Interlock Review

IF BYPASS ADDED = YES

Require:

Bypass Purpose
Authorized Conditions
Warning/Indication
Removal/Permanent Status

IF SAFETY IMPACT > NONE

Require:

Safety Review

IF CHANGE STATUS = ROLLED BACK

Require:

Rollback Reason
Restored Revision
Verification
Next Action

IF STATUS = CLOSED

Require:

POSTCHANGE backup
Final revision
Commissioning result
Change Log
Validation
Documentation confirmation

62. CHANGE MANAGEMENT DASHBOARD

Track:

OPEN CHANGES

CHANGES READY FOR IMPLEMENTATION

CHANGES IN COMMISSIONING

CHANGES ROLLED BACK

EMERGENCY CHANGES

TEMPORARY CHANGES

ACTIVE BYPASSES

CHANGES MISSING DOCUMENTATION

CHANGES MISSING POSTCHANGE BACKUPS

CHANGES BY EQUIPMENT

CHANGES BY ENGINEER

This gives Engineering Management visibility into the health of the controls environment.

63. TEMPORARY CHANGE REGISTER

Maintain a dedicated dashboard/register showing:

Change	Equipment	Type	Owner	Installed	Remove By	Status
CE-CHG-####	Line 5	Bypass	Engineer	Date	Date	Active

Highlight overdue temporary modifications.

A temporary change should never disappear inside a PLC program.

64. ACTIVE BYPASS REGISTER

Maintain a visible list of active process bypasses.

Include:

Equipment
Bypass
Reason
Activated By
Activation Date
Authorized By
Risk
Expected Removal
Status

This becomes particularly important as the plant grows.

65. CHANGE AUDIT

Periodically review selected changes.

Verify:

☐ Change Request exists

☐ PRECHANGE backup exists

☐ POSTCHANGE backup exists

☐ Revision correct

☐ Change Log updated

☐ Testing documented

☐ Drawings updated

☐ Temporary changes removed

☐ Final master identified

The goal is process improvement—not paperwork for its own sake.

66. CONFIGURATION DRIFT

Configuration drift occurs when:

WHAT IS RUNNING

no longer matches:

WHAT ENGINEERING BELIEVES IS RUNNING.

Examples:

Online edits never uploaded
Vendor changed program
Drive parameter changed
HMI changed without backup
IP address changed
Drawing not updated

CE-SOP-004 exists partly to prevent configuration drift.

67. CHANGE MANAGEMENT METRICS

Future dashboard metrics may include:

Changes per month
Emergency changes
Successful first-pass commissioning
Rollback rate
Temporary changes open
Temporary changes overdue
Active bypasses
Changes missing backups
Changes missing documentation
Average change closeout time

These metrics can identify weaknesses in the engineering process.

68. PRE-IMPLEMENTATION GATE

A planned functional change should not move to:

READY FOR IMPLEMENTATION

until applicable items are complete:

☐ Change ID created

☐ Scope defined

☐ Current State understood

☐ Future State defined

☐ Change authorized

☐ Risk reviewed

☐ Safety reviewed where applicable

☐ PRECHANGE backup created

☐ Known-good version identified

☐ Rollback plan established

☐ Development complete

☐ Offline verification complete

☐ Test plan prepared

☐ Downtime coordinated

☐ Stakeholders notified

69. POST-IMPLEMENTATION GATE

A change should not be considered controlled and complete until:

☐ Commissioning passed

☐ Stakeholder validation completed

☐ POSTCHANGE backup created

☐ Revision assigned

☐ Change Log updated

☐ Documentation updated

☐ Temporary logic reviewed

☐ Forces removed

☐ Active bypasses documented

☐ Current master identified

☐ Monitoring completed where applicable

70. STOP CONDITIONS

Stop implementation when:

Unexpected unsafe condition occurs.
Wrong controller is identified.
Correct backup cannot be confirmed.
Program revision is uncertain.
Change behavior differs significantly from design.
Unplanned equipment begins operating.
Production conditions prevent safe testing.
Required stakeholder support is unavailable.
Scope has materially changed.
Rollback capability is lost.

Resolve the condition before proceeding.

71. THE FIVE-MINUTE CHANGE TRAP

Avoid thinking:

"This will only take five minutes, so I don't need the process."

A five-minute online edit can create months of troubleshooting if:

It is undocumented.
It is never uploaded.
The backup is outdated.
Another engineer later downloads an older program.
The reason for the change is forgotten.

Process rigor should be proportional to risk, but traceability still matters.

72. THE MIDNIGHT DOWNLOAD TEST

Before finalizing the change documentation, ask:

If another Controls Engineer had to restore this machine at midnight six months from now, would they know which program is correct and what changed?

If the answer is:

the change is not sufficiently documented.

73. QUICK-REFERENCE CHANGE WORKFLOW

1. IDENTIFY IT

Create Change ID.

2. DEFINE IT

Document what and why.

3. CLASSIFY IT

Minor / Standard / Major / Emergency.

4. REVIEW IT

Assess risk and safety.

5. AUTHORIZE IT

Obtain appropriate approval.

6. BACK IT UP

Create PRECHANGE files.

7. PLAN IT

Establish implementation, testing, and rollback.

8. BUILD IT

Develop the change.

9. VERIFY IT

Perform offline review.

10. COMMUNICATE IT

Notify affected stakeholders.

11. IMPLEMENT IT

Make controlled change.

12. TEST IT

Commission the system.

13. VALIDATE IT

Confirm with stakeholders.

14. BACK IT UP AGAIN

Create POSTCHANGE master.

15. DOCUMENT IT

Update Change Log and engineering records.

16. MONITOR IT

Observe production.

17. CLOSE IT

Confirm all controls are satisfied.

74. CONTROLS CHANGE GOLDEN RULES

RULE #1

Never risk the only known-good program.

RULE #2

Know what you are changing before changing it.

RULE #3

Online editing is not a substitute for engineering design.

RULE #4

Every significant change requires a rollback strategy.

RULE #5

Test abnormal conditions, not only successful operation.

RULE #6

Never casually remove an interlock because it is inconvenient.

RULE #7

Bypasses must be visible, controlled, and documented.

RULE #8

Temporary logic must have an owner and exit plan.

RULE #9

Never leave unintended forces active.

RULE #10

Vendor changes belong to the company too—obtain the source files.

RULE #11

The running production program must become the controlled POSTCHANGE master.

RULE #12

If another engineer cannot understand the change history, the documentation is incomplete.

75. DEFINITION OF SUCCESS

CE-SOP-004 is successful when Controls Engineering can answer for every significant production change:

Who changed it?

What changed?

Why was it changed?

What version existed beforehand?

Where is the backup?

What risks were considered?

How was the change tested?

Did commissioning pass?

What is the current production revision?

How would we roll back?

Were temporary changes removed?

Were drawings and documentation updated?

A production controls system should never depend upon someone remembering:

"I think I changed that a few months ago."

The history should exist.

The backups should exist.

The reason should exist.

The testing should exist.

The current master should be identifiable.

That is controlled Controls Engineering.

76. REVISION HISTORY

Rev. 1.0

Initial release of CE-SOP-004 – Controls Change Management.

Owner: Electrical Controls Engineering

Review Frequency: Annual or following significant changes to Controls Engineering change-management practices.