PLC Software Revision History : What Should Engineers Record

 

 1st November, 2026.

In this post, we will see the concept of recording and defining PLC software revision history.

Throughout the lifetime of an industrial automation system, there will often be changes made to your PLC software. These could be to fix any programming issues, improve equipment sequencing, improve machine performance, add new features, or to solve any issues found during commissioning. If software revisions aren’t logged then engineers will find it difficult to know which version is currently in use, what changes were made and how to roll back to a previous version. Having a PLC software revision log will help engineers know what changes have been made to their control program, who made the changes, and compare versions. This will help give a reliable history of the automation system.

 In this article we will look at the vital information engineers should log when making changes to their PLC software.

1. PLC Project

The first thing to log will be what PLC project relates to the revision. Without knowing what project the revision relates to, it can get confusing especially if you are looking for after multiple machines, lines or areas. Log the following information:

1.      Project/Plant Name

2.      Equipment/System ID

3.      PLC Tag/controller name

4.      PLC Type/Manufacturer and Model

5.      Software Project File Name

6.      Location of controlled project files

For example, your project may have multiple PLC programs within it for your Raw Water Pump Station, Chemical Dosing System and Filtration System. By logging equipment IDs, engineers will know what controller the revision relates to. If applicable, log the PLC firmware version and programming software version. This can help identify any compatibility issues should you try to open/download the project onto another engineering workstation.

2. Software Revision Number & Date

Each approved software revision should have a unique identifier. An example of this could be:

1.      Rev 00 – Initial Software Release

2.      Rev 01 – Fixed pump-start sequence

3.      Rev 02 – Added low level protection

4.      Rev 03 – Changed how communication failure is handled

Your revision number should be consistent throughout the project; some organizations use numbers whilst others may use a mix of letters and numbers. Log the date the changes were made. Where possible, also log when the revised program was tested. These may not be the same date as the changes that may have been made during commissioning but not approved until later. Don’t rely on naming your files PLC_Final, PLC_Final_New, PLC_Final_Updated etc. This won’t give a reliable history of what revisions you have.

3. Changes Made

This is one of the most important items to log in to your revision. You should clearly state what changes were made and if needed what part of the program was changed. Examples of poor revision descriptions:

1.      Pump Logic Changed: Improved Pump Start Logic to stop pump starting when wet well level falls below configured minimum.

2.      Alarm Fixed: Fixed high-pressure alarm setpoint and updated SCADA alarm.

3.      A good revision description should answer the following questions:

a)      What change was made?

b)     What equipment, function or part of the program was changed?

c)      What was the aim of the change?

When making larger changes, log what routine/function block or part of program was changed. This will help future engineers locate the relevant logic quickly.

4. Reason for Changes

Whilst knowing what changes were made is useful, knowing why they were made adds more value. The reasons for changes may include:

1.      Programming errors

2.      Process has changed

3.      Equipment has changed

4.      Improvements

5.      Customer request

Examples of this could be adding to the pump start permissive as the pump was starting without the valve open feedback being confirmed. Adding a communication failure alarm as it wasn’t easy to identify if communication had failed with the remote I/O. Changing the analog scaling as the installed transmitter range was different to the PLC. Where possible, relate your changes to a change request, defect report, commissioning observation or approved design document. This will help give traceability between your initial requirements, the issue identified and the software change and verification.

5. Who Made the Changes

Your revision should clearly show who made the changes. Depending on your organization’s processes, it can be useful to log:

1.      Who made the changes

2.      Who reviewed the changes

3.      Who approved the changes

4.      Who tested the changes

Depending on the size of the change, you may have different people doing each task. In smaller changes, one engineer may do all the tasks. This isn’t to blame anyone but so that the maintenance/project team can contact the right person. If your system needs to follow any formal quality/change control processes, make sure you follow your organization’s approved process for reviewing and approving changes. A revision shouldn’t be used as a substitute for approvals/testing.

6. Testing

All changes to your software should be tested to make sure they work as intended and that they don’t cause any issues with other functions. Briefly log what testing was done and what the outcome was. More detailed testing can be logged onto a test report.

For example, if you have added a valve open permissive to your pump start sequence, you should test that the pump starts when the valve open feedback is healthy and all permissive are met. Ensure that the pump doesn’t start when there is no valve open feedback. Check the relevant HMI and ensure that the changes don’t affect the approved pump stop sequence. The outcome of your testing should be logged as either passed, failed or pending.

If your testing fails, log this and what was done to overcome the issue. Don’t just assume that because the program didn’t throw any errors it has been tested successfully. Your testing should be appropriate to the risk and scale of the changes. Where applicable, include regression testing, hardware testing and relevant communications interfaces.

7. Backup Location & Version Released

Your revision log won’t be very useful if you don’t know where your software file is. Log where your released revisions are stored or reference to your controlled repository. Also log what version was deployed to your PLC.

For example, you may have developed and tested changes to a revision but not downloaded it to the live controller. Or you may have downloaded changes during commissioning but not yet released them. These will be two different scenarios. It can be useful to log:

1.      File Name of released project

2.      Reference to repository/backup

3.      Status of release

4.      Date of deployment

5.      Backup Created

If possible, include a checksum or other reliable method of identifying that the file stored is the correct one for your release. Once you have made changes to your software, ensure you have a verified backup of your software in accordance with your project’s backup and recovery procedure. Ensure your backup can’t be changed by unauthorized people and can be retrieved by authorized personnel.

8. Example PLC Software Revision Log

Suppose you have a wastewater pumping station with multiple pumps, valves and level instruments controlled by a PLC. Your revision log could look like:

1.      Rev 00 - Initial PLC Program

Date - 05 January 2026

a)      Description - Initial PLC Program developed and released as per approved functional specification.

b)     Reason - Initial project development.

c)      Status - Released after successful verification.

2.      Rev 01 - Pump Start Sequence Changed

a)      Date - 12 January 2026

b)     Description - Valve Open Feedback added as a permissive.

c)      Reason - Issue identified with sequence during FAT.

d)     Testing - Checked pump can start with healthy valve feedback. Checked pump will not start with no valve feedback.

e)      Status - Released after successful testing.

3.      Rev 02 - Remote I/O Communication Failure Alarm

a)      Date - 18 January 2026

b)     Description - Communication failure alarm added to remote I/O station. SCADA updated.

c)      Reason - Improving fault identification for operators.

d)     Testing - Checked alarm which triggered loss of communication. Cleared after communication regained.

e)      Status - Released.

4.      Rev 03 - Level Transmitter Scaling Changed

a)      Date - 21 January 2026

b)     Description - Analog scaling of level transmitter LT-101 changed.

c)      Reason - PLC configured to match installed instrument range.

d)     Testing - Under verification.

e)      Status - Under testing.

This is just an example. What is important is that each revision shows what, why, how it was tested and if it was released. For larger projects, if your process requires it, keep separate logs for your software development, testing, approval and deployment. Don’t expect your revision log to be a substitute for all your change control throughout your project.

9. Things To Avoid

1.      Overwriting previous program without having an authorized backup.

2.      Files with unclear names such as Final_Final2.

3.      Only stating the date of the change.

4.      Not knowing what has been tested and what has been deployed to the PLC.

5.      Making changes online without documenting and reviewing them.

6.      Keeping your revisions separate to your project files.

7.      Not updating your revisions after an approved emergency change.

8.      Assuming that, because it downloaded successfully means the application is working correctly.

By having a consistent process for your revisions, you will reduce the risk of these issues and will make it easier to maintain your software history.

PLC software revisions are an essential part of documenting your industrial automation systems. As an engineer you should log: Project, Revision Number, Date of change, Changes Made, Reason for changes, who made the changes, Test Results, Approved Status and where your software was released. Most importantly, each revision should give another engineer enough information to know what changes were made, why they were made, how they were tested and what version of the program was deployed. Having this information consistently logged will make it easier to troubleshoot, have reliable backups, improve project handover and keep the integrity of your automation system throughout its lifetime.

I have covered the general theory on understanding the PLC software revision history. I have also not attempted to cover all the topics related to it, as it can vary from case to case. Once you are familiar with this type of technology, you can easily troubleshoot any issues related to it.

Thank you for reading the post. I hope you liked it and will find a new way in this type of technology.

Written by Viral Nagda, Industrial Automation Engineer with 12+ years of experience…