FEATURE APPLICATIONS IN IRELAND
MANAGING YOUR PLANT’S ASSETS
With more plant floor automation it is vital that companies ensure that proper safeguards are in place to manage changes to control logic across the plant. Andy Thorogood, Product Manager at MAC Solutions, explains
P
lant floor automation control systems often involve an array of PC
workstations, programmable logic controllers (PLCs), HMIs (human machine interfaces) and robotic controllers. Control logic is stored either in the device or on an associated workstation and can involve a large number of associated files and executable programs. This complexity poses a challenge to detecting unauthorised – and potentially hazardous – program changes, especially where systems from multiple vendors and the associated variety of program development and device management tools exist. Until recently, proprietary protocols and network isolation provided adequate security from external threats. However, many vendors are abandoning proprietary communication mechanisms in order to lower costs and improve reliability. Similarly, more and more device management is moving to PC- based workstations and other ‘open’ systems. This transition to standard protocols and operating systems is making modern devices and systems more vulnerable to attack. Fortunately, software solutions are now
available that can help to safeguard plant-wide automation and control assets. An automation Change Management Systems (CMS) such as Autosave from MDT Software, is a centralised system that manages changes to program logic for controls programs and devices such as PLCs, CNCs, HMIs, PC control systems, robots, drives and general automation programs. A typical small plant will have a few hundred programs that should be managed, while large plants will have several thousand. Over the life of a facility the investment in program logic alone represents a significant expenditure that should be preserved and optimised. In order to do this, a CMS should have the following features: 1. A backup/archive of prior revisions of programs.
2.The ability to detect changes.
26 SUMMER 2014 | IRISH MANUFACTURING
3.Tools for documenting changes and making these visible to users. 4. A historical record of who made the change, when, and from where it was made. 5. Secured user and workstation access. 6. Features for controlling editor operations mapped to user permissions. 7. Disaster recovery/procedures for recovering from hardware failures.
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 the current device program and configuration are lost, and an old version of the device program must be used, the result is decreased machine performance, decreased quality and/or downtime. While this situation is costly enough, consider the ramifications to plant operation if there are no older versions of a lost program available and the program must be completely rewritten. This can and does happen, and the effects can significantly impact safety and plant throughput for months. These impacts added to the cost to re- rewrite, test and commission a single program are often greater than the cost to implement a plant-wide CMS solution. There are many events that can have a
negative affect on plant performance, and some that represent serious safety hazards. Reliable automation control logic can be compromised by human error or equipment failure. Equipment can and does fail. If the hardware fails and the only good copy of the program logic was in that hardware, the plant has
a problem. With a CMS, the hardware is replaced and maintenance staff download the latest version of the program to the processor resulting in only a few minutes of downtime. Sabotage: as unfortunate as this threat
is, someone can connect directly to many devices (especially those in remote, unsecured locations) and modify the program with harmful results. A CMS is designed to store processor passwords so these are not available without going through the CMS. Also, the CMS will periodically upload the logic from the processor for comparison with a copy on file. Changes can be identified in graphical detail, and immediate notification can be sent to responsible individuals. Power issues can cause equipment to
lock up or go off-line. If these situations result in a loss of the program, it can be downloaded from the CMS after the hardware is reset. Fire: having all program logic stored in
“Control logic complexity
poses a challenge to modern plants looking to detect unauthorised program changes”
a central, organised CMS repository accelerates the time and decreases the cost associated with resuming production. Insurance underwriters are beginning to factor in the use of a CMS in assessing the risk profile of facilities. 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 on the 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. While a manual backup approach may appear adequate at first glance, experience has shown that plant personnel have too many tasks that compete for the time to manually back up programs on a consistent basis. Also the increased visibility of changes through better reporting and the potential for process improvement brought about by the effective use of a CMS application can quickly pay for the CMS. Each plant has a unique set of change
types and frequencies that can affect a CMS strategy and as long as they are taken into account a proper implementation of a CMS will be possible and desirable.
MAC Solutions
www.mac-solutions.co.uk Enter 210
/ IRISHMANUFACTURING
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32