Managing automation upgrades, retrofits
From minor modifications to major overhauls, an automation system will significantly change during its lifecycle. Good planning, research, and following these guidelines can ensure a successful upgrade.
Upgrades can be tricky, especially in automation systems. They come in many varieties, each with unique challenges. Sorting through a plethora of technical and operational issues while keeping budgets and schedules under control is a tough course to navigate, but great outcomes are more than possible. When pursuing an upgrade, consider these guidelines.
Form and function
Not all upgrades are created equal. Some can be done with simple swaps with little to no impact on operations. Others fundamentally alter the composition and behavior of the system, requiring extensive installation, training, and monitoring to complete. Usually, upgrades entail some change to the physical or logical structure of the system. New application functionality is often thrown in the mix. First, consider the different aspects of an automation upgrade before exploring the best approach for managing each.
The most common type of migration is minor version/model upgrades to the hardware or software components in a system. This may include physical replacement of components, firmware updates to these items, or service-pack updates to commercial off-the-shelf (COTS) software. This class of retrofit typically requires little-to-no application software rework. Other than the upgraded items, the remainder of the physical automation infrastructure usually remains intact.
All systems are based on some hardware and software technology platforms. Major upgrades to these platforms—even when staying with the same manufacturer—usually entail some amount of application software rework. While such changes might be limited to simple configuration and scripting changes, they could require complete translations of the application software. Translation tools and prescribed upgrade paths may exist to make this easier, but the entire application will always need to be completely retested to ensure proper operation.
Application software changes often accompany automation migrations. These changes may be associated with new processing equipment, new ways of interacting with existing equipment, new analysis of operations, and new ways to share and report on everything. While the focus of this article is functional application changes in the context of larger automation upgrades, it is important to note that such changes often take place absent of any other factors.
Just because a minor component upgrade is the simplest type of retrofit does not necessarily mean it is simple. Subtle differences between components can cause major headaches if you are not careful. Consider these guidelines when migrating components.
Upgrading controller processors and modules is a common type of migration (see Figure 1). Upgrades within the same product line often do not require application programming changes, or at worst, they may need slight configuration changes. An important factor to watch for is processor firmware changes that might affect the behavior of certain functions. For example, changes to a proportional-integral-derivative (PID) control algorithm may require reconfiguration of the PID tuning parameters. While changes such as these are often documented by the manufacturer, that is not always the case. Thoroughly testing and monitoring your system after this type of upgrade should be part of your planning.
Upgrading control panel components is another common type of migration you are likely to encounter. Traditional electrical/pneumatic component swaps are fairly straightforward. A bit of assembly, mounting, and wiring may be needed, but the downtime requirements tend to be small. Of particular interest is migration to smart components. These devices can be operated, monitored, and configured remotely, while providing a variety of diagnostic and maintenance capabilities. In most cases, you need to rework the addressing scheme in your control system to access these devices. Further changes to the application layer software will be required to unlock and use their enhanced capabilities. Traditional control wiring (discrete or analog) usually is replaced with network cabling, which will have different requirements with regard to electronic noise, shielding, and other factors. Remember to take that into account for reliable operation.
The lifecycle of computer workstations and servers can be relatively short compared to other elements in the control system. Updates to hardware, operating systems, historians, databases, and a host of COTS software items on your workstations and servers are a common theme. The trick here is to get everything to play nicely together. A simple antivirus software upgrade might induce unexpected problems in another crucial part of your system. Start by researching the COTS software approved-installation specifications. Next, stage the updates offline and thoroughly test your applications before deploying them to your production system. This is the best way to manage these upgrades and avoid unpleasant surprises down the road.
There will eventually come a time when you have to consider upgrading your input/output (I/O) subsystems (see Figure 2). This activity is almost a class in itself. While application software requirements might be light, the physical installation issues can be significant.
In for out
There are several factors to consider when planning an I/O system upgrade. Ask yourself these questions:
- What type of downtime windows is available for the cutover?
- Does part of the old I/O system need to stay operational while the new system is being installed?
- Can the field wiring remain intact or does that need replacement?
The downtime window will drive how much I/O can be replaced at one time. If your cutover time is tight, don't lose heart. There are ways to reduce your installation time.
If physical space and wiring pulls permit, replacing an entire enclosure with a new one often will be the quickest path through a cutover. The new enclosure should be placed next to the existing one and should be thoroughly assembled and tested prior to the cutover. In the existing enclosure, ensure the field side of the terminals are properly tagged and confirmed. When it is time to cutover, disconnect the field side of the terminals in the existing panel and terminate them to the field side of the terminals in the new one.
If a new enclosure is not an option or only a portion of an enclosure can be cut over at a time, new panel subplates can be preassembled and prewired to new terminal strips. When the downtime window occurs, disconnect the field side of the terminals on the old subplate, completely remove the old subplate, install the new subplate, and reconnect the field wiring sides of the new subplate terminals. This approach may require installing new subplate mounting studs in the existing enclosure.
If changing subplates is not an option, it may be possible to mount and wire the new I/O system on the existing subplate. In this case, you would keep the field side of the terminal strip intact. If available on your new I/O modules, prewiring and tagging the module swing arms will save time. When field wiring must be replaced, wire can be pre-pulled, tagged, and spooled on the field-device side, control panel side, or both to allow for a faster cut-in.