If you work in a manufacturing or utility plant, you already know that making changes to automation program logic is an everyday occurrence when making process enhancements, recipe changes, etc. However, do you know what happens to the previous program when a new one was made? Perhaps you are thinking “who cares?” since you are no longer using that old program. What if the new program doesn’t quite work the way you thought it would and you end up with bad product? What if the program you thought you were using is not the one running in the device? These are just some of the common plant scenarios that have led many manufacturers and utility providers to look for ways to manage changes in their automation assets.
But how, exactly, do these plants use Change Management Software (CMS) to protect against harmful effects of unmanaged automation changes? Here is just a short list of use cases for implementing a CMS:
Managing Changes in Networked Devices
For devices that are on a plant network, all changes to device programs can be tracked by the CMS when the changes are made in the program and loaded into the devices. Rather than launching the device editor package, connecting to the device over the network, and making changes, you first login to the CMS and select the program to edit. The CMS launches the editor package for you, locks the program while you are editing it, and captures changes and your comments when edits are complete.
A CMS maintains accurate records of which software version is in use, when changes were made and who made the changes. It retains a designated number of previous copies. When a change is made, a new current copy is saved, and the oldest copy is marked for later deletion. To ensure all copies are retained for as long as needed, a minimum amount of time during which ancestors will be maintained is established for the facility.
Managing Changes in Non-networked Devices
A good CMS supports customers who wish to manage remote or non-networked automation devices. While there may be some telemetry from the device, by “non-networked” we mean there is insufficient bandwidth or connectivity to enable you to upload the program/project files for editing or comparison. In these cases, the CMS has a Field Client designed to support off-line editing of devices directly, and then automate the check-in of these changes to the CMS server once the user has a connection.
Controlling User Permissions
Only authorized users can access programs and make changes. Access is controlled by logins and passwords, which authenticate privileges according to the user’s group (e.g., maintenance, engineering). Privileges are designated by area and/or by device for each user group. Passwords can be authenticated to the Active Directory domain, local CMS system or the workstation’s current user.
Also, client workstations can be configured to control access to a program or area of the plant. This ensures that only specified programming workstations can be used for editing purposes when a safety or line-of-sight requirement exists.
Tracking Electronic Signature and Workflow Approval of Changes
There can be numerous disks and laptops located throughout the plant, each containing different program versions. Inefficiencies are inevitable, costly, and even dangerous. A CMS with change control features for regulated (e.g., life science, energy, etc.) sites include compliance with 21 CFR 11 (the FDA’s electronic signature regulations). These features can be used selectively at any site. For example, it could just be used on a small number of highly sensitive devices. A CMS' electronic approval and audit trail capability ensures manufacturers that changes to critical devices are properly tested, documented and approved before put into production use.
Auditing Devices for Changes Made Outside of the CMS
A CMS can detect and identify changes between the program running in a processor and the program on file in the CMS. This situation happens when someone makes an edit to a device without going through the CMS to track and record the change. Depending on your company’s business process this may be acceptable or unacceptable. Either way, the CMS has you covered. Comparisons can be scheduled and automatically performed or performed on-demand. Also, program records in the CMS can be updated when a change is found, or simply alert users for follow-up. This process of auditing devices to compare code protects your products, people, and equipment.
Reporting Device Configuration and Change Activity
An extensive set of reports exists in AutoSave providing insights into many aspects of your plant activity. As part of normal AutoSave usage, you build up records regarding device configuration, editor and firmware version, change history, etc., which can be very valuable in providing insights into plant dynamics. For example, you can spot change activity that is abnormal (e.g., many more changes to one device than similar devices) which will enable you to explore the underlying causes of the need for these changes.