Search Knowledge Base Articles

PLC/HMI Backup, Version Control & Disaster Recovery

CE-SOP-006 — PLC/HMI BACKUP, VERSION CONTROL & DISASTER RECOVERY

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

1. PURPOSE

The purpose of this Standard Operating Procedure is to establish a controlled and repeatable method for backing up, identifying, versioning, storing, verifying, restoring, and recovering industrial controls software and configuration files.

This procedure ensures that critical automation systems can be restored following:

PLC failure
HMI failure
Hardware replacement
Program corruption
Failed modification
Firmware failure
Storage failure
Accidental overwrite
Vendor modification
Cybersecurity incident
Equipment replacement
Controls computer failure
Loss of engineering personnel

The objective is simple:

THE FACILITY SHALL ALWAYS KNOW WHICH CONTROL PROGRAM IS RUNNING AND HOW TO RECOVER IT.

2. CORE BACKUP PRINCIPLE

A backup is not simply:

"There is a PLC file somewhere."

A controlled backup must answer:

WHAT equipment does this belong to?

WHEN was it captured?

WHO captured it?

WHAT software created it?

WHAT firmware does it require?

WHAT revision is it?

IS it the current production master?

HAS it been verified?

CAN another engineer restore it?

3. SCOPE

This SOP applies to:

PLC programs
HMI applications
SCADA applications
Safety controller programs
VFD configurations
Servo configurations
Remote I/O configurations
Managed switch configurations
Industrial gateway configurations
Barcode scanners
Vision systems
Motion controllers
Robot programs where applicable
Instrument configurations
Recipe databases
Industrial communication configurations
Other programmable production equipment

Applicable platforms may include:

Allen-Bradley
Siemens
AutomationDirect
Rockwell Automation
FactoryTalk
Studio 5000
RSLogix 500
RSLogix 5000
TIA Portal
CCW
C-More
OEM software
Vendor-specific configuration utilities

4. BACKUP TYPES

Controls Engineering shall distinguish between different backup types.

BASELINE

Known controlled starting configuration.

PRECHANGE

Program captured immediately before a planned modification.

POSTCHANGE

Program captured after successful commissioning.

PRODUCTION MASTER

Current approved configuration representing the production system.

Last known-good production revision before the current master.

DEVELOPMENT

Engineering files not approved for production.

DISASTER RECOVERY

Verified files and supporting information specifically retained for restoring failed equipment.

5. THE PRODUCTION MASTER

Every programmable controls asset should have one clearly identifiable:

CURRENT PRODUCTION MASTER

The Production Master represents the configuration approved for current production operation.

The Production Master shall not be identified merely by:

File modification date
Who created it
"Latest"
"Final"
Desktop location
Engineer memory

It shall be explicitly controlled.

6. SOURCE OF TRUTH

The official backup repository shall be considered the:

CONTROLS ENGINEERING SOURCE OF TRUTH

Local laptop copies are working copies.

USB drives are transfer tools.

Email attachments are communication copies.

Vendor laptops are external copies.

None should automatically be considered the official master.

7. PRECHANGE BACKUP

Before significant PLC/HMI modification:

☐ Connect to correct controller

☐ Verify equipment identity

☐ Upload current PLC

☐ Upload/retrieve current HMI where appropriate

☐ Save configuration

☐ Verify file opens

☐ Record software version

☐ Record firmware

☐ Record processor/HMI model

☐ Record current revision

☐ Record date

☐ Record engineer

☐ Save as PRECHANGE

Recommended:

Equipment_Project_YYYY-MM-DD_PRECHANGE_REVX.X

8. PRECHANGE RULE

NEVER MODIFY OR DOWNLOAD OVER THE ONLY KNOWN-GOOD COPY.

The PRECHANGE file protects against:

Failed commissioning
Incorrect logic
Unexpected machine behavior
Corrupted development
Wrong assumptions
Production time limitations

It is the rollback foundation.

9. POSTCHANGE BACKUP

After successful commissioning:

UPLOAD THE ACTUAL RUNNING SYSTEM AGAIN.

Do not automatically assume the offline development file is identical to what ultimately entered production.

Complete:

☐ Upload final PLC

☐ Capture final HMI

☐ Save final configurations

☐ Verify files

☐ Assign revision

☐ Update Change Log

☐ Identify Production Master

☐ Archive previous revision

Recommended:

Equipment_Project_YYYY-MM-DD_POSTCHANGE_REVX.X

10. WHY POSTCHANGE UPLOADS MATTER

During commissioning, engineers may perform:

Online edits
Timer adjustments
Setpoint changes
Alarm modifications
Tag corrections
Communication corrections
Minor logic changes

Therefore:

OFFLINE DEVELOPMENT FILE

may not equal:

FINAL RUNNING PRODUCTION FILE

The final upload resolves this uncertainty.

11. REVISION NUMBERING

Recommended standard:

REV 1.0

Initial controlled release.

REV 1.1

Minor functional modification.

REV 1.2

Additional minor modification.

REV 2.0

Major functional revision.

REV 3.0

Future major revision.

Avoid uncontrolled revision names such as:

Final
Final2
New
Newest
Latest
Fixed
Working
UseThis
ActualFinal
FinalFinal

12. FILE NAMING STANDARD

Recommended format:

Equipment_Project_Date_Status_Revision

Example:

Line5_CanStop_2026-10-07_POSTCHANGE_REV1.1.ACD

Other examples:

RO_Skid_Bypass_2026-10-07_PRECHANGE_REV2.3.RSS

Lathe8_HMI_2026-10-07_POSTCHANGE_REV1.4

Names should allow an engineer to understand the file without opening it.

13. FILE NAME REQUIREMENTS

Where practical include:

Equipment
Project/function
Date
Backup type
Revision

Avoid characters incompatible with required software or storage systems.

Use consistent date formatting:

YYYY-MM-DD

This keeps files naturally sortable.

14. FOLDER STRUCTURE

Recommended:

Controls Engineering

→ Facility

→ Area

→ Equipment

→ PLC

→ HMI

→ DRIVES

→ NETWORK

→ DRAWINGS

→ DOCUMENTATION

Within PLC/HMI:

CURRENT

PREVIOUS

ARCHIVE

PRECHANGE

DEVELOPMENT

15. CURRENT FOLDER

The CURRENT folder should contain only the controlled current production master and required supporting files.

Do not allow CURRENT to become an archive containing dozens of versions.

The objective is immediate identification.

16. PREVIOUS FOLDER

PREVIOUS should contain the most recent prior known-good revision.

This provides fast rollback access.

17. ARCHIVE FOLDER

ARCHIVE contains older controlled revisions.

Archived programs shall retain:

Revision
Date
Change reference
Historical traceability

Do not delete older controlled versions solely because a newer revision exists unless retention policy specifically allows it.

18. DEVELOPMENT FOLDER

DEVELOPMENT may contain:

Offline modifications
Experimental logic
Incomplete changes
Simulation files
Future revisions

Development files shall never be confused with approved production masters.

Where practical identify:

NOT FOR PRODUCTION

19. PLC BACKUP RECORD

For each PLC maintain:

Asset ID
Equipment
Manufacturer
Controller
Catalog Number
Serial Number
Firmware
IP Address
Software
Software Version
Program Name
Current Revision
Last Backup Date
Last Backup By
Current Master Location
Previous Master Location
Recovery Notes

20. HMI BACKUP RECORD

Maintain:

Asset ID
Equipment
Manufacturer
Model
Serial Number
Firmware
IP Address
Programming Software
Software Version
Application Name
Current Revision
Runtime File
Editable Source File
Last Backup Date
Backup Location
Recovery Notes

21. HMI SOURCE VS. RUNTIME

Controls Engineering shall understand the difference between:

EDITABLE SOURCE

and

RUNTIME APPLICATION

A runtime application alone may not provide full maintainability.

Where platform capabilities permit, retain the editable source project required to make future changes.

For systems where runtime-to-source restoration is possible, do not depend on that capability as the primary backup strategy.

22. SOFTWARE VERSION RECORD

A PLC/HMI backup may be unusable if the required programming software is unavailable.

Record:

Software Name
Major Version
Minor Version where relevant
Service Pack/Patch where relevant
Required Communication Software
Required Drivers
Required Activation/License
Required Operating System

23. FIRMWARE RECORD

For programmable hardware record:

Manufacturer
Model
Catalog Number
Firmware Revision

Firmware matters because project files may not open, download, or function correctly with incompatible revisions.

24. ENGINEERING SOFTWARE LIBRARY

Maintain a controlled inventory of required engineering software.

Examples:

Studio 5000 versions
RSLogix 500
FactoryTalk View Studio
TIA Portal versions
CCW
C-More Programming Software
Vendor utilities
Drive configuration tools

Record:

Software
Version
Purpose
Equipment Supported
License Requirement
Installation Source
Compatibility Notes

25. LEGACY SOFTWARE

Older production equipment may depend on software that no longer runs properly on modern engineering computers.

For legacy systems, maintain where permitted:

Installation media
Installation packages
License information
Required drivers
Operating system information
Communication adapter information
Recovery instructions

Do not wait until the legacy PLC fails to discover the programming software is no longer available.

26. VIRTUAL MACHINES

Where appropriate, legacy software may be maintained in controlled engineering Virtual Machines.

Record:

VM Name
Operating System
Software Installed
Versions
Supported Equipment
Date Updated
Storage Location
Recovery Method

VMs should themselves be backed up according to company IT requirements.

27. COMMUNICATION HARDWARE

Disaster recovery may require more than software.

Maintain awareness of required:

USB adapters
Serial cables
Ethernet adapters
USB-to-serial converters
Proprietary programming cables
Memory cards
SD cards
CompactFlash
Vendor-specific adapters

Document special communication requirements.

28. BACKUP VERIFICATION

A FILE THAT EXISTS IS NOT AUTOMATICALLY A VERIFIED BACKUP.

Verification should include applicable:

☐ File opens

☐ Correct software opens it

☐ Controller model correct

☐ Firmware identified

☐ Program name correct

☐ Equipment identity correct

☐ Revision recorded

☐ HMI source accessible

☐ Communication path documented

☐ No obvious corruption

29. BACKUP CONFIDENCE LEVEL

The web system may classify backups:

VERIFIED

Opened and confirmed.

CAPTURED

Backup exists but full verification incomplete.

STALE

Backup age exceeds established review interval or known changes occurred afterward.

UNKNOWN

File exists but relationship to running production system is uncertain.

MISSING

No usable backup identified.

This makes backup risk visible.

30. BACKUP AGE

Track:

DAYS SINCE LAST VERIFIED BACKUP

Recommended dashboard indicators:

GREEN

Current verified backup.

YELLOW

Backup aging or verification due.

RED

Backup missing, unknown, or known to be outdated.

Backup age alone does not determine validity.

A five-year-old program may still be current if no changes occurred.

A one-day-old program may already be outdated after an undocumented online edit.

31. SCHEDULED BACKUP AUDIT

Perform periodic backup reviews.

Recommended minimum:

ANNUAL CONTROLS BACKUP AUDIT

Higher-criticality equipment may warrant more frequent review.

Audit:

☐ PLC backup exists

☐ HMI source exists

☐ Revision known

☐ Firmware known

☐ Software known

☐ IP address known

☐ Backup opens

☐ Current master identifiable

☐ Previous version available

☐ Recovery method documented

32. CHANGE-TRIGGERED BACKUP

Regardless of scheduled audit frequency, create a new controlled backup after significant changes.

Triggers include:

PLC logic change
HMI change
Drive parameter change
Network change
Firmware upgrade
Hardware replacement
Vendor modification
Major troubleshooting modification

33. BACKUP AUDIT DASHBOARD

Track:

TOTAL PLC ASSETS

VERIFIED BACKUPS

MISSING BACKUPS

STALE BACKUPS

UNKNOWN REVISIONS

MISSING HMI SOURCE

UNKNOWN FIRMWARE

UNKNOWN SOFTWARE VERSION

LEGACY SYSTEMS

DISASTER RECOVERY READY

This turns backup management into measurable reliability work.

34. DISASTER RECOVERY READINESS

A system is considered Disaster Recovery Ready when applicable:

☐ Current PLC master available

☐ Previous PLC master available

☐ HMI source available

☐ Required configurations available

☐ Firmware known

☐ Software known

☐ Programming software accessible

☐ Communication method known

☐ IP configuration documented

☐ Replacement hardware identified

☐ Recovery procedure understood

35. DISASTER RECOVERY PACKAGE

For critical equipment consider maintaining a recovery package containing:

PLC master
HMI master
Drive configurations
Network configuration
Firmware information
Software requirements
IP addresses
Hardware part numbers
Electrical drawings
Recovery instructions
Replacement hardware information

The objective is:

REDUCE TIME FROM FAILURE TO RECOVERY.

36. PLC FAILURE RECOVERY

If a PLC fails:

Make equipment safe.
Confirm PLC failure.
Identify controller model.
Identify firmware.
Locate current Production Master.
Locate replacement hardware.
Verify replacement compatibility.
Configure required network settings.
Install hardware.
Download controlled master.
Restore communication.
Verify I/O.
Verify critical setpoints.
Commission system.
Document replacement.
Create new backup record.

37. HMI FAILURE RECOVERY

If an HMI fails:

Identify HMI model.
Locate replacement hardware.
Identify firmware.
Locate current HMI application.
Verify editable source/runtime.
Configure IP address.
Transfer application.
Verify PLC communication.
Verify navigation.
Verify buttons.
Verify indicators.
Verify alarms.
Verify setpoints.
Verify security.
Document replacement.

38. DRIVE FAILURE RECOVERY

For VFD/servo replacement:

Identify exact model
Record motor information
Locate parameter backup
Confirm firmware
Configure communication
Restore parameters
Verify motor direction
Verify speed reference
Verify start/stop
Verify faults
Verify PLC communication
Verify safe operation

Do not assume a factory-default replacement drive will operate correctly.

39. NETWORK DEVICE RECOVERY

For managed switches, gateways, or communication devices:

Identify hardware
Locate configuration
Record IP
Record subnet
Record gateway
Record VLAN where applicable
Record port configuration
Restore configuration
Verify communication
Update asset record

40. PROGRAM RESTORATION

Before restoring a program to a controller:

VERIFY THAT THE FILE IS APPROPRIATE FOR THE ACTUAL MACHINE.

Check:

Equipment identity
Controller
Firmware
Revision
Date
Change history
Hardware configuration
I/O configuration
HMI compatibility
Network configuration

Do not simply download the newest-looking file.

41. SAFE DOWNLOAD DECISION

Before downloading a recovery file ask:

IS THIS THE CURRENT PRODUCTION MASTER?

WAS IT CAPTURED AFTER THE LAST KNOWN CHANGE?

DOES IT MATCH THIS EXACT MACHINE?

DOES THE HARDWARE CONFIGURATION MATCH?

DOES THE FIRMWARE MATCH?

ARE REQUIRED SETPOINTS/RECIPES ACCOUNTED FOR?

DO I UNDERSTAND THE DOWNLOAD CONSEQUENCES?

If uncertainty remains, investigate before downloading where conditions permit.

42. UNKNOWN RUNNING REVISION

If the running PLC revision cannot be confidently matched to the repository:

Do not immediately overwrite it.

Instead:

Upload current running PLC.
Save as controlled investigation copy.
Compare against known master.
Identify differences.
Determine legitimacy of differences.
Update Change Log.
Establish new controlled master.

This restores configuration control without unnecessarily destroying useful running logic.

43. PROGRAM COMPARISON

Where software supports comparison:

Compare:

RUNNING PLC

against

CURRENT MASTER

during:

Backup audits
Unknown-revision investigations
Suspected undocumented changes
Vendor work review
Major troubleshooting

Document significant differences.

44. VENDOR BACKUPS

Before vendor/integrator work:

☐ Capture PRECHANGE backup

☐ Record current revision

☐ Define expected vendor deliverables

After vendor work:

☐ Obtain PLC source

☐ Obtain HMI source

☐ Obtain drive configurations

☐ Obtain network configurations

☐ Obtain drawings

☐ Obtain Change Log

☐ Upload running production system

☐ Establish POSTCHANGE master

Do not depend on the vendor to permanently maintain the company's only current source code.

45. OEM MACHINE ACCEPTANCE

Before accepting new automated equipment, obtain applicable:

PLC source
HMI source
Safety program
Robot source
Drive parameters
Servo parameters
Vision configuration
Network configuration
Electrical drawings
Software/version information
Firmware information
Password/access information according to company policy
Recovery instructions

Maintainability should be part of machine acceptance.

46. PASSWORDS AND CREDENTIALS

Passwords, software activations, and credentials shall be handled according to company cybersecurity and credential-management policies.

Do not place sensitive passwords directly into:

PLC comments
HMI screens
Public Knowledge Articles
Unprotected spreadsheets
File names

Backup documentation may reference the approved credential-storage location without exposing the credential itself.

47. STORAGE REDUNDANCY

Critical backups should not exist only on:

One engineering laptop
One USB drive
One local hard drive
One employee's personal storage
One vendor's computer

Use approved company storage with appropriate redundancy and access controls.

48. ENGINEERING LAPTOP FAILURE TEST

Ask:

If the Controls Engineering laptop failed permanently today, could we still recover the plant's PLC/HMI programs?

If the answer is:

the backup architecture is inadequate.

49. ENGINEER AVAILABILITY TEST

Ask:

If the original programmer were unavailable, could another qualified engineer identify and restore the correct program?

If:

improve documentation.

50. FACILITY DISASTER TEST

Ask:

If local engineering files were lost, where is the recoverable copy?

Critical systems should have backup protection consistent with company IT/OT disaster recovery requirements.

51. LOCAL WORKING COPIES

Engineers may maintain local working copies during development.

After project completion:

Final files go to controlled repository.
Local copies are not treated as master.
Development copies should be clearly identified.
Sensitive or obsolete local copies should be handled according to company policy.

52. USB STORAGE

USB storage may be necessary for certain industrial equipment.

Where used:

Use approved devices.
Follow cybersecurity procedures.
Do not treat USB as primary archive.
Transfer final files to controlled repository.
Verify file integrity.

53. FILE INTEGRITY

Where practical:

Verify files open.
Verify archive extraction.
Verify project dependencies.
Verify linked files.
Verify source completeness.

A compressed archive that cannot be opened is not a useful backup.

54. RECIPES AND RETENTIVE DATA

Some critical operating information may not exist solely in the offline PLC program.

Consider:

Recipes
Retentive tags
Calibration values
Operator setpoints
Production counters
Drive parameters
HMI recipes
Device-specific configuration

Determine whether separate backup methods are required.

55. RECIPE BACKUP

Where recipes are critical:

Document:

Recipe Location
Backup Method
Export Format
Last Backup
Restore Method
Ownership

Do not assume PLC source automatically contains every production recipe.

56. HARDWARE INVENTORY LINKAGE

Every backup record should link to the applicable Controls Asset.

Example:

Asset: PLC-L5-001

Current Program: Line5_Main_REV3.2

Firmware: 32.xxx

IP: Documented in Network Register

Last Verified Backup: Date

This connects software configuration to physical hardware.

57. BACKUP OWNERSHIP

Controls Engineering owns the technical accuracy of the controls backup library.

IT may provide:

Storage
Server infrastructure
Backup services
Access control
Cybersecurity

Controls Engineering remains responsible for determining:

Which program is correct
Which revision is current
Which files are required for recovery
Whether recovery information is technically complete

58. BACKUP ACCESS

Backup systems should balance:

AVAILABILITY

with

CONTROL

Qualified engineers should be able to access recovery files when needed.

At the same time, uncontrolled users should not casually modify or delete production masters.

59. READ-ONLY ARCHIVE

Where supported, historical controlled releases may be stored with restricted or read-only access.

This helps prevent accidental modification.

60. DELETING BACKUPS

Do not casually delete old controls programs.

Before deletion consider:

Historical value
Rollback requirement
Audit requirement
Equipment history
Regulatory requirements
Storage policy

Follow applicable company retention policy.

61. BACKUP AFTER EMERGENCY WORK

Following emergency troubleshooting involving program modification:

Restore stable production.
Upload current PLC.
Capture HMI where changed.
Assign revision.
Document change.
Identify POSTCHANGE master.
Review temporary logic.
Update repository.

Emergency work is one of the highest-risk sources of undocumented configuration drift.

62. CONFIGURATION DRIFT

Configuration drift occurs when:

RUNNING PRODUCTION CONFIGURATION

differs from:

CONTROLLED ENGINEERING MASTER

Common causes:

Online edits
Vendor modifications
Drive parameter changes
HMI downloads
Network changes
Emergency repairs
Temporary modifications

Scheduled audits and mandatory POSTCHANGE uploads help prevent this.

63. BACKUP EXCEPTION

If a PRECHANGE upload cannot be obtained:

Document:

Why
Risk
Existing backup available
Date of existing backup
Decision to proceed
Authorization

Proceeding without a current backup should be the exception, not routine practice.

64. MISSING BACKUP ESCALATION

If critical equipment has no recoverable program:

Create a high-priority engineering action.

Record:

BACKUP STATUS: MISSING

Determine:

Can program be uploaded?
Is source available from OEM?
Is HMI source recoverable?
Is software available?
Is hardware obsolete?
What happens if the equipment fails tomorrow?

This becomes a Controls Reliability risk.

65. OBSOLETE SYSTEM RECOVERY RISK

For obsolete equipment document:

Controller lifecycle
HMI lifecycle
Spare availability
Software availability
Firmware availability
Communication hardware availability
Replacement path

High-risk obsolete systems should feed the:

Upgrade Opportunity Register

66. WEB SYSTEM — BACKUP RECORD

Recommended fields:

ASSET

Asset ID
Equipment
Area

PLC

Manufacturer
Model
Serial
Firmware
IP
Software
Version

PROGRAM

Program Name
Revision
Backup Type
Backup Date
Engineer
Change ID
Project ID

VERIFICATION

File Opens
Controller Verified
Firmware Verified
Revision Verified
Verification Date
Verified By

STORAGE

Current Master
Previous Master
Archive Location

RECOVERY

Replacement Hardware
Software Required
Communication Method
Recovery Instructions

67. WEB SYSTEM — BACKUP STATUS

Recommended statuses:

CURRENT / VERIFIED

CURRENT / UNVERIFIED

STALE

UNKNOWN REVISION

MISSING

RECOVERY RISK

OBSOLETE SYSTEM

Use these statuses on the Controls Asset dashboard.

68. WEB SYSTEM AUTOMATION

Recommended rules:

IF PLC CHANGED = YES

Require:

POSTCHANGE PLC Backup

before project closure.

IF HMI CHANGED = YES

Require:

POSTCHANGE HMI Backup

before closure.

IF BACKUP STATUS = MISSING

Create:

Controls Reliability Risk

IF REVISION = UNKNOWN

Flag:

Configuration Verification Required

IF LEGACY SOFTWARE REQUIRED

Flag:

Legacy Recovery Dependency

IF LAST VERIFIED BACKUP EXCEEDS REVIEW PERIOD

Create:

Backup Verification Task

69. DISASTER RECOVERY READINESS SCORE

The web system may calculate:

DR READINESS

Example criteria:

PLC Master = 20%
HMI Master = 15%
Software Known = 10%
Firmware Known = 10%
Network Configuration = 10%
Hardware Replacement Identified = 10%
Drawings Available = 10%
Recovery Procedure = 10%
Backup Verified = 5%

Example:

Line 5 DR Readiness: 95%

Missing:

Replacement HMI spare identification

This creates a measurable reliability program.

70. BACKUP AUDIT PROCESS

For each equipment asset:

STEP 1

Identify controller.

STEP 2

Locate current master.

STEP 3

Confirm revision.

STEP 4

Confirm software.

STEP 5

Confirm firmware.

STEP 6

Verify file opens.

STEP 7

Confirm HMI source.

STEP 8

Confirm IP information.

STEP 9

Confirm replacement hardware.

STEP 10

Update backup record.

71. RESTORE DRILL

For highly critical equipment, Controls Engineering may periodically perform a non-production restore verification or controlled recovery exercise where appropriate.

The objective is to verify:

Files are usable
Software is available
Recovery procedure is understood
Required hardware exists
Required communication tools exist

Do not perform unnecessary production downloads merely to prove recovery capability.

Use safe methods appropriate to the system.

72. RECOVERY TIME OBJECTIVE

Critical equipment may be assigned an estimated:

RECOVERY TIME OBJECTIVE — RTO

Example:

Critical Packaging Line PLC

Target controls recovery capability:

2 Hours

This can help determine:

Spare requirements
Backup quality
Software availability
Training needs

73. CRITICALITY CLASSIFICATION

Assets may be classified:

CRITICALITY A

Failure causes major production/safety/business impact.

Highest backup and recovery priority.

CRITICALITY B

Significant operational impact.

Standard DR requirements.

CRITICALITY C

Limited operational impact.

Standard backup requirements.

This allows Controls Engineering to prioritize backup work intelligently.

74. NEW EQUIPMENT BACKUP GATE

New automated equipment should not be considered fully accepted until applicable:

☐ PLC source obtained

☐ HMI source obtained

☐ Safety source obtained

☐ Drive parameters obtained

☐ Network configuration obtained

☐ Software versions documented

☐ Firmware documented

☐ Password/access ownership addressed

☐ Drawings obtained

☐ Production master established

75. PROJECT CLOSEOUT BACKUP GATE

A project shall not normally reach:

CLOSED

if required final backups are missing.

Minimum:

☐ POSTCHANGE PLC

☐ POSTCHANGE HMI where changed

☐ Revision

☐ Change Log

☐ Production Master designation

This requirement links directly to:

CE-SOP-005

76. THE WRONG-PROGRAM SCENARIO

One of the most dangerous backup failures occurs when someone downloads an older program believing it is current.

Potential result:

Months of online edits disappear.
Interlocks disappear.
Alarm improvements disappear.
New I/O disappears.
Process changes disappear.
Troubleshooting begins on problems that were previously solved.

The backup system shall be designed specifically to prevent this scenario.

77. THE VENDOR-ONLY SCENARIO

Another major risk occurs when:

"The vendor has the program."

Controls Engineering shall work toward ensuring the company possesses the required maintainable source files for company-owned equipment, subject to applicable contractual and licensing restrictions.

Vendor support should be a resource.

It should not unnecessarily become the only recovery strategy.

78. THE LAPTOP-ONLY SCENARIO

If someone says:

"The latest version is on my laptop."

the program has not yet been properly controlled.

Move the controlled version to the approved repository.

79. THE MEMORY-ONLY SCENARIO

If the only method of identifying the correct program is:

"Ask Nathan; he knows which one it is."

the backup process has failed.

The objective of this SOP is to make correct recovery independent of individual memory.

80. BACKUP QUALITY TEST

A qualified engineer unfamiliar with the machine should be able to determine:

Which PLC file is current?

Which HMI file is current?

Which revision is running?

Which software is required?

Which firmware is required?

What IP address is used?

Where is the previous revision?

How is the system restored?

If this information cannot be determined, the backup is incomplete.

81. QUICK-REFERENCE BACKUP WORKFLOW

BEFORE A CHANGE

1. IDENTIFY

Correct equipment.

2. UPLOAD

Current running program.

3. VERIFY

File opens.

4. LABEL

PRECHANGE + revision.

5. STORE

Controlled repository.

6. CONFIRM

Rollback available.

AFTER A CHANGE

1. COMMISSION

Verify functionality.

2. UPLOAD AGAIN

Capture actual running system.

3. VERIFY

Open final files.

4. VERSION

Assign new revision.

5. STORE

Move into controlled repository.

6. DESIGNATE

Identify Production Master.

7. ARCHIVE

Retain previous revision.

8. LOG

Update Change Log.

82. DISASTER RECOVERY WORKFLOW

MAKE SAFE

↓

IDENTIFY FAILED DEVICE

↓

LOCATE CONTROLLED MASTER

↓

VERIFY HARDWARE/FIRMWARE

↓

INSTALL REPLACEMENT

↓

RESTORE CONFIGURATION

↓

RESTORE NETWORK

↓

VERIFY I/O

↓

COMMISSION

↓

VALIDATE PRODUCTION

↓

DOCUMENT RECOVERY

↓

CREATE NEW BACKUP

83. BACKUP GOLDEN RULES

RULE #1

Never risk the only known-good program.

RULE #2

Always create PRECHANGE backups for significant modifications.

RULE #3

Always create POSTCHANGE backups after successful commissioning.

RULE #4

The final running upload—not memory—defines the production master.

RULE #5

One current master should be clearly identifiable.

RULE #6

Keep the previous known-good revision.

RULE #7

A backup is incomplete if nobody knows which software opens it.

RULE #8

Firmware matters. Record it.

RULE #9

HMI runtime files are not always equivalent to editable source files.

RULE #10

Vendor possession of source code is not a substitute for company recovery capability.

RULE #11

Do not allow the only current program to live on one laptop.

RULE #12

Test that important backups actually open.

RULE #13

Configuration changes require new controlled backups.

RULE #14

Unknown revisions are engineering risks.

RULE #15

Disaster recovery must be possible without depending on one specific engineer.

84. DEFINITION OF SUCCESS

CE-SOP-006 is successful when Controls Engineering can answer for every critical automated system:

What controller is installed?

What firmware is running?

What software is required?

What PLC program is current?

What HMI application is current?

What revision is production running?

When was it last verified?

Where is the previous version?

Where are the source files?

What hardware replaces the failed device?

How do we restore the system?

How long should recovery take?

The ultimate goal is not merely:

"WE HAVE BACKUPS."

The goal is:

"WE CAN RECOVER."

85. REVISION HISTORY

Rev. 1.0

Initial release of CE-SOP-006 – PLC/HMI Backup, Version Control & Disaster Recovery.

Owner: Electrical Controls Engineering

Review Frequency: Annual, after significant changes to backup infrastructure, or following a controls recovery event.