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