Best Practices for the Installation and Operation of an Automation Change Management Software (CMS) System

Transcription

1 Best Practices for the Installation and Operation of an Automation Change Management Software (CMS) System

2 Abstract...3 Introduction...3 CMS Vendor and Product Considerations...4 Vendor Criteria...5 Point Solutions...5 Product Criteria...5 General Implementation Overview...5 Turnkey Implementation...6 Pre-Installation Tasks...6 Pre-Installation Meeting(s)...6 Identification of the Client team...6 Identification of the Software Vendor s Implementation team...6 Preparation of the Device Catalog...7 Plant Hierarchy Layout and File Definition...7 Server pre-load...7 Compare Computer pre-load...7 Client pre-load...8 Network definition...8 Loading of Baseline device programs...8 Miscellaneous Device directory definition...8 Privilege definition...8 Capture of Data and Preparation of Training Material...9 CMS Installation...9 Server Install...9 Client Install...9 Compare Computer Install...9 Add users to the system...9 Implement the Plant Hierarchy...9 Add devices to the system...10 CMS Tailoring and Tuning...10 Compare group definition...10 Image Backup of Critical PCs...10 User Education...10 User Training Best Practices...11 System Administrator Training Topics...11 End User Training Topics...11 Disaster Recovery...11 Standard Operating Procedure...11 System Acceptance and Signoff...12 Lifecycle Management of the System...12 Conclusion...12 About MDT Software...12

3 Abstract The increase of plant floor automation has created a dependency on PLCs, PC control systems and programmable automation. These devices and their logic programs are costly in their development, vital to the running of the plant, and are viewed by most companies as corporate assets. It is incumbent on plant and corporate management to insure that proper safeguards are in place to protect and manage change in these assets. This document explores best practices for the planning, implementation and ongoing lifecycle maintenance of a Change Management Software (CMS) system in a manufacturing facility. Other industries that use a CMS system will find similar benefits from the practices outlined in this document. Introduction Automation Change Management Software has matured over the past 20 years along with the increases in sophistication and capability of the automation devices and control software developed by automation vendors. As automation devices have grown more complex and have incorporated more plant data in their operation, there is an increase in the need to make adjustments to variables and logic to continue smooth operation. These adjustments may be minor individually, but are directly linked to machine throughput and uptime. If these changes are lost, and an old version of the device program must be used, or even worse the device program must be rewritten, the result is decreased machine performance, decreased quality and/or downtime. Each of these is very costly. Appropriate procedures to assure adequate security and control, as well as the installation of a CMS system can greatly reduce the risk of extended downtime. Reliable automation control logic can be compromised by the following events: Human Error Equipment failure Sabotage Power surges / interruptions Fire Without proper system safeguards these events can lead to increased downtime, and an increase in mean time to repair (MTTR). Recovering from these events quickly requires adequate planning regarding hardware and maintenance strategy, and a reliable and recent backup of the automation control program logic. Current and complete backup copies of the program logic require the features of a CMS system. While a manual backup approach may appear adequate at first glance, experience has shown that plant downtime can quickly pay for the cost of a CMS system, in addition to the reporting and process improvements brought about by effective use of a CMS system. The general definition of an Automation Change Management Software (CMS) system is a centralized system that manages program logic for controls systems and devices such as PLCs, CNCs, HMIs, PC control systems, robots and general automation programs. Basic functionality of the CMS system should provide: Archival backups Change detection Change documentation Historical tracking Secured user and workstation access Controlled editor operations Disaster recovery Automatic change notification

4 As most manufacturing facilities today utilize advanced and varied automation technologies, it is important to begin with an accurate inventory of the types and numbers of devices to be managed. This inventory should also review the control software. From this inventory, the facility can identify: An accurate count of devices for planning purposes Islands of automation that need to be factored into the implementation plan A complete list of control (editor) software and opportunities for version standardization Types of devices to be maintained on a CMS system will vary from manufacturing facility to manufacturing facility. With all of these devices there are a wide variety of manufactures, network configurations, models, support software, and versions of support software. To properly manage these programs and devices, all these factors have to be understood. The most common devices are defined as follows: PLCs Programmable Logic Controllers. Most common type of device supported by a CMS system. CNCs - Computer Numerical Controllers. These can be highly complex and often require custom development within the CMS to provide adequate change management. The CMS system will need to access the control ladder, part programs, and process parameters as part of the backup process. These can be located in standard locations as defined by the manufacturer, or the can be located in custom locations as developed by the OEM. Secondly, file locations can be different based on types of CNCs within a model. For example, a single or dual axis CNC within the same model can have different file locations. Prior to the installation of a CMS system these factors should be defined and documented. Company standards for OEM code design can greatly standardize the logic designs, and reduce CMS costs for supporting these devices. Robots To properly support these the Robot manufacturer or plant controls group should provide the file listing for each type of robot. HMI Human Machine Interface. CMS systems typically provide integrated support for commonly used HMI packages. If these are not available a generic module to support general PC files can be used. PC Controls These types of devices are typically used in machining operations. These are PCs that are running a control program that mimics the operation of a PLC. Some of these differ slightly from the PLC programming software they are emulating; others are custom applications. In all cases careful consideration to device communications and understanding their file structure is required for a successful CMS installation. Welders, Drives, and Misc. PC Control Applications These can be supported by a generic module that provides support for general PC applications and files. Some premier CMS systems provide user configurable modules for these applications. Word, Excel, AutoCAD, and general Windows files - These can be supported by a generic module that provides support for general PC applications and files. Some premier CMS systems provide specialized modules for these applications that address document management. Non-networked devices These can be supported by a check out and check in procedure. This approach would give the controls engineer access to the latest program and the ability to update the CMS system as needed. Another option is for the plant to investigate the use of a wireless network. The device and software inventory should identify: The type and model of each device Types of data and file locations for programs on each device The type and version of each programming software used to program this systems Its network path and address The version of firmware The machine builder or OEM that delivered it (to identify multiple code development standards that must be accounted for) CMS Vendor and Product Considerations The selection of the best CMS system to meet a facility s needs requires a careful assessment of current and future needs, and an evaluation of the product offerings in the marketplace. While

5 several products exist in the marketplace, once the device support requirements are identified, there are typically only a few product offerings that are well suited to meet the plant s needs. Vendor Criteria A vendor should have a broad understanding of controls technologies (software and hardware) and a depth of experience in the devices used in your facility. A single CMS solution is preferable in many respects to a series of point solutions. Some vendor considerations are: Years in business Sufficient independence in the market to work effectively with a wide variety of controls vendors. Priority of the CMS product line vs. other products Market presence with the CMS offering The vendor (and integrator network) should be able to implement and support the CMS regardless of location References with similar facilities Point Solutions While some controls vendors offer basic version control within their packages, there are a number of disadvantages to these point solutions. The reliance on these individual packages for program backup has a number of limitations, including: Backups and program revisions are located in multiple, inconsistent locations Only selected systems are backed up Inadequate security and access controls are in place to ensure programs are not lost The IT department will not be able to manage file backups in an orderly fashion, and a single hard drive failure could result in the loss of all backups. Product Criteria An ideal CMS solution should meet the following criteria: A proven package that provides strong support for current and many legacy applications. Support for most common controls technologies with little or no on-site coding Ability to tailor and expand the CMS to meet unique plant needs Support for generic file structures, documents, images, etc. Flexible architecture to allow controls technologies to be added or removed over the life of the system without re-implementation. This will offer the user flexibility in their controls strategy. Solid product support and upgrades General Implementation Overview If the selected change management application meets the definition of a Commercial Off The Shelf (COTS) software product (vs. a toolkit with features and scripts) the implementation project is similar to other plant-wide software implementations. The selection of a COTS product that supports a wide variety of hardware and software control types will reduce the cost of implementation, and life cycle costs while providing the company with flexibility in their controls strategy. The major components of implementation are: Pre-Installation Tasks Software installation on server and associated support processing machines and workstations Identification of the device communication routes Configuration of these communication routes for the various managed devices

6 Configuration of the devices to be supported, with copies of resent program files Documentation of the As-Configured topology User Education Acceptance and Signoff The remainder of this White Paper is available by request to We hope you find it to be of use in managing change and safeguarding your automation assets!

7 Conclusion With clear requirements, sponsorship from corporate and plant management, careful product selection and focused implementation, a CMS solution will deliver tremendous value. Rapid recovery from device failures, secure access, compliance with corporate and regulatory policies, and process improvement are all among the benefits of a CMS solution. About MDT Software MDT Software is the world leader in change management solutions for automated manufacturing assets. Founded in 1987, MDT Software has grown into a trusted provider of disaster recovery and change management solutions for leading manufacturers. Learn more at