Manufacturers are dependent on automated assets such as programmable logic controllers (PLC), PC control systems and computer numerical controllers (CNC). As vital as these devices are to the throughput of today’s manufacturing plants, there is an unrecognized source of risk associated with these devices. Often, their control programs aren’t protected from loss, human error, unauthorized changes, security breaches, equipment failure and power surges, to name a few.
If these incidents compromise a control device’s data, the costs and downtime can be considerable. For these reasons, it’s important to ensure you have the proper safeguards in place to protect and manage any change in these assets, as well as to have current backup copies of the device configuration easily accessible.
One effective way to meet these goals and minimize the risks to your automated production is to implement software that manages all the plant’s Industrial Internet of Things (IIoT) devices and their data, allowing you to safeguard your plant’s IioT assets, instantly recover control program backups and more.
The Case For Change Management
Change management, as it applies to plant automation, is the set of processes that ensures any adjustments to control systems are implemented in an organized, controlled fashion. Change management software (CMS) functions as a centralized system that manages any changes to the control system or to devices’ programming logic. Small plants will typically have a few hundred programs that must be managed, while large plants can have several thousand.
Because automated devices have become more complex in recent years, owing to the incorporation of large amounts of plant data, there is an ongoing need to adjust variables and logic more frequently. Although minor on an individual basis, these adjustments — when taken together — are directly linked to equipment throughput and uptime. Should you lose your current device program, for example, you may need to use an older version, causing machine performance, product quality and uptime to suffer. And while this scenario is costly enough, consider the operational ramifications if no older versions of the lost program are available. While completely rewriting programs can and does happen, the effects can significantly impact your plant’s safety and productivity levels for months.
With proper management of all automation devices and data, you can protect your plant from the following:
- Human error. A CMS makes prior program versions readily available, which comes in handy if someone makes undesirable changes to a program or corrupts it.
- Equipment failure. If a machine fails and the only good copy of the program was in that hardware, then you have a problem. With a CMS, maintenance personnel simply replace the hardware and download the latest version of the program to the processor, resulting in only a few minutes of downtime.
- Sabotage. Unfortunately, anyone can connect directly to devices and modify the program at any time. A CMS can store processor passwords, making them inaccessible by any other means. It will also periodically upload the logic from the processor and compare it to the copy on file, identifying and alerting individuals of any changes.
- Power surges or interruptions. If these situations lead to the loss of the program, users can simply download the program from the CMS after resetting the hardware.
- Fire. Whether a single device or an entire facility is lost to, having all the programs stored in a central, organized CMS repository accelerates the return to production.
- Cybersecurity attacks. Not only can a CMS identify unknown or unauthorized program changes and quickly bring back the right system configuration, there are software solutions that can also identify vulnerabilities and provide recommendations on mitigating those risks.
The ability to quickly recover from these events depends on backing up the control program — something the CMS provides with current, complete and easily accessible backup copies. Although manual backups may appear to be an adequate option, plant personnel often have too many tasks that compete for their time. The CMS also offers additional value in the form of reporting, which increases plant visibility and the potential for process improvement.
Typical Device Programs
PLCs are the most common device type supported by a CMS. There are many PLC vendors out there, and each one has its own proprietary software package for PLC program editing. Your CMS application should be able to interact with all major brands of the PLC software to capture and detect changes, as well as to provide an alternate method of capturing project files on the editor workstation. A newer variant of the PLC — called the programmable automation controller (PAC) — can perform the same tasks as traditional PLCs, all while managing multiple applications simultaneously.
A second common device type is the CNC for machine tools. In this case, the CMS needs to be able to access the machine control logic, G-Code that describes tool paths and process parameters as part of the backup process. You can find this information in standard locations, as defined by the manufacturer, or in custom locations developed by the OEM. File locations can also differ based on the types of CNCs within a model. For example, a single- or dual-axis CNC machine within the same model can have different file locations. Before installing the CMS, it’s important to define and document these variables.
In addition to PLCs and CNCs, other common device types for CMS applications include:
- Robots. When it comes to change management, robots that have file transfer protocol (FTP) communications are often straightforward devices. The robot manufacturer or plant controls group should provide the file list for each robot type.
- Human machine interfaces (HMI). CMS applications typically provide integrated support for common HMI packages. If the CMS doesn’t have a unique driver for a particular HMI, then you can use the generic module that backs up the development environment for the PC workstation.
- PC controls. These devices, which are common in machining operations, run the control program that mimics a PLC’s operation. Some differ slightly from the PLC programming software they are emulating, while others are custom applications. In all cases, pay attention to device communications and the PC control file structure, which is required for successful CMS installation. Typically, you can use either a unique driver or a generic module that backs up the development environment.
Key Features of a CMS
When it comes to selecting the right CMS application, it’s important to weigh the features of the CMS against your plant’s unique requirements. Key characteristics and capabilities include the following:
Backup archive. Many facilities set retention parameters to maintain a certain number of prior program versions. These parameters often include the number of copies to maintain, as well as the minimum age of deletable copies. The age requirement can be useful if you’ve made multiple unsuccessful attempts to correct a program issue; sometimes, reverting to an older copy of the program is a better starting point compared to recently edited versions.
Change detection. Going through the CMS to make any and all program changes ensures you have a complete change history. In addition, the CMS can interrogate devices and compare the program running in a particular device to the reference copy within the CMS. If the CMS detects any changes, it will identify them and notify personnel.
Change documentation. Program editor software packages can vary in their ability to identify changes. On the other hand, the CMS provides a consistent, intuitive platform to compare changes between any two versions of a program — whether between a master copy, prior version or current version in the processor.
Historical tracking. When assessing areas for process improvement, it’s helpful to be able to identify device changes in light of the device type, production line and individuals making the changes. Understanding these patterns can help you evaluate whether or not excessive changes are being made and what the root cause might be.
Secure user and workstation access. The CMS authenticates each user. Some facilities even place line-of-sight restrictions on which workstations can be used to edit device programs.
Controlled editor operations. You can assign CMS users to groups with permission profiles that map to the individual’s authority within the plant. We recommend keeping the role structure as simple as possible.
Disaster recovery. If a device fails, you’ll need to obtain a replacement device and connect it to the network. CMS users can download the latest copy of the program to the device to easily resume operation.
Getting Started: Implementing a CMS
Selecting a commercial off-the-shelf (COTS) product that supports many hardware and software control types can reduce the cost of implementing and running a CMS, while offering flexibility in your controls strategy. CMS implementation often includes the following tasks:
- Pre-installation tasks — e.g., gathering stakeholders for kickoff meetings, documenting project milestones, gathering device information, etc.
- Installing software on the server and associated support workstations
- Identifying device communication routes
- Configuring communication routes for managed devices
- Configuring the devices that will be supported
- Documenting the as-configured topology
An example of a CMS software platform is octoplant, which ensures greater data consistency and protection in production plants. This modular package offers comprehensive asset and device management, as well as program backups, all of which are easily customizable according to your plant’s unique requirements.
In addition, octoplant centralizes the management of your entire production environment in one system, unlocking the following benefits:
- Ensure all devices are configured correctly
- Make more informed decisions
- Improve your operational uptime
- Quickly bring back the right system configurations
- Know and manage what is going on with your IoT devices
- Take proactive action to prevent security breaches
- Fulfill regulatory requirements and streamline production audits
To learn more, please visit: auvesy-mdt.com.
Author: Name: Gary Gillespie, President at AUVESY-MDT, Americas
Bio: Gary Gillespie joined MDT Software (now AUVESY-MDT) in 2004 and led the business for 17 years. Gary began his career as an engineer at the NASA Johnson Space Center in Houston, Texas. In the mid-1990s he moved into the software market, working in the Maintenance Management/EAM space, among others. Gary has extensive experience providing software solutions for mining, energy, food and beverage, petrochemical and automotive companies. He holds a Bachelors in Mining Engineering and a Masters in Mechanical Engineering from the University of Alabama. AUVESY-MDT secures the world’s automation with solutions that reduce downtime, errors and security threats.