Time To Update?

Automation - Migration could be the biggest single issue facing automation end users today. ARC estimates the value of the installed base of automation systems reaching the end of their useful lives at approximately $65 billion. This represents a big opportunity for both end users and suppliers.

Process automation suppliers have significantly expanded their migration offerings compared to seven years ago. This is the case both for migrating from competitors' systems and for migrating from a legacy system to a new system from the same supplier. It has also become apparent that migration is no longer strictly a distributed control system (DCS) issue, but has grown to encompass other types of systems. These include quality control systems (QCSs) in the pulp and paper industry; supervisory control and data acquisition (SCADA) systems for oil and gas; water and wastewater; and power distribution applications; burner management systems; and other automation platforms.
Users can take any of a number of different approaches when evaluating potential migration suppliers. For many end users, migration represents a significant enough step change to warrant a complete review of all the supplier offerings in the marketplace. ARC advocates that you be just as rigorous in your approach for selecting a migration supplier as you would for control system selection. One thing end users should take into account is the potential supplier's ability to provide a solution that minimizes downtime and risk, while providing a tangible business value proposition that will have a positive economic impact on your business. No matter how smooth the implementation may have gone, if you simply end up with a like-for-like functional replacement, you failed to exploit an excellent opportunity to improve business performance.

Process Automation System Lifecycle
DCSs were first introduced in 1975. While the lifecycle of these systems can be quite long, this varies from component to component. The lifecycle of DCS hardware components, such as wiring and I/O, can be 30 years or more. Controllers have a slightly shorter lifecycle, but also tend to last upwards of 20 years or so. The workstation and application layer of the system has a much shorter lifecycle. Most major suppliers announce major version changes of their HMI and operator software every eighteen months or so. HMI workstations may not be able to run the latest OS after only a few years and must be regularly replaced.
Due to these different lifecycles for various system components, most older installed systems today represent an amalgam of older I/O and wiring infrastructure, combined with not-quite-so-old controllers and newer operator workstations, servers, and related applications. The closer you get to the I/O and wiring infrastructure, the more difficult it is to articulate a business value proposition for control system migration.

When Is The Right Time to Migrate?
It's becoming more and more difficult to justifying capital spending on automation as end users increasingly focus on getting the most out of their installed assets. Any automation project today requires a compelling business case. ARC has categorized several scenarios where migration is required. Like other capital assets, automation assets have a lifecycle. At the end of that lifecycle, it becomes necessary to plan and execute a system migration. Any or all of the following situations can mark the end of the lifecycle.

Reliability Issues
Reliability threatens operational continuity and threats can emerge in two ways.
Basic repair: frequency and criticality of failures. An increase can indicate the end of the lifecycle.
End of Support: Suppliers regularly obsolete or replace products with functional equivalents, or in the worst case, their businesses fail. Any of these can trigger end of life planning.

Unsupportable Opportunity
The capability of automation assets continuously increases and legacy assets often cannot satisfy new business opportunities. Many times, these opportunities become evident when functional requirements expand beyond fundamental manufacturing. When the existing automation cannot satisfy these new requirements, it may be time to consider migrating to automation assets that can.
Of course, the case for migration is most urgent when the old system reaches the point where an impending plant shutdown or incident is a real possibility. The system may be so old that replacement parts and support are unavailable or are extremely limited and cost prohibitive. The old system may not support many of the available new technologies that provide real economic advantages, such as plant asset management (PAM) applications, fieldbus, advanced production management applications, and Ethernet-based control networks.
Even worse, the old system can be burdened with a high volume of custom code and custom point-to-point integration that make long term support cost prohibitive, as companies struggle with shrinking labor resources and a lack of qualified personnel. The veteran who understood all the custom code in place (probably because he/she wrote it), will retire and be replaced by a worker who knows only open technologies and standards.
Of even greater importance is the opportunity cost associated with supporting an outdated system. This is the cost of a business opportunity missed when your system is not advanced, flexible, or functional enough to take advantage of a swiftly emerging or fleeting opportunity. Having an old or outdated system installed can actually result in direct losses. This is especially true if the end user lacks the visibility into plant operations that enables him or her to prevent abnormal situations and avoid supply chain disruptions. An inflexible system hinders the ability to react quickly to shifts in market demand.

Primary Migration Alternatives
Several approaches to migration exist in the marketplace today. These approaches usually vary according to the level of functionality to be provided in the target automation system. When choosing a migration approach, there are several possibilities, each with their own particular strengths and weaknesses. Usually, the first consideration is whether to stay with the incumbent supplier or move to a different supplier. Staying with the current supplier is, in many cases, the easiest migration to perform, especially if the incumbent remains a good business partner.
Five basic migration approaches and combinations are possible: replacement, gateways, I/O connect and wiring kits, I/O substitution, and encapsulation. How much of the system you want to replace will largely dictate the approach. The decision to stay with your existing supplier or migrate to a new supplier will also influence the approach you ultimately choose.

Replacement
The first and most obvious is the bulldozer style of migration. This eliminates all existing control system equipment and replaces it with new equipment. This is the most costly in terms of hardware, software, labor, downtime, and training. It also involves the greatest amount of risk, because you cannot go back to the old system if the new system does not perform as anticipated.

Gateways
Gateways are a well-established way of linking one control system to another. From a functional view, gateways can project added functionality; both from the legacy system to the target system and from the target system back to the legacy system. From a logical view, gateways perform protocol translation and throughput normalization.

I/O Connect and Wiring Kits
Many suppliers offer to migrate to a new system while preserving the user's existing I/O terminations and field wiring. Cabling solutions, otherwise known as wiring kits, involve mapping I/O from the existing termination assemblies to the new system through the new I/O. Suppliers also offer direct I/O bus interfaces that allow users to keep their legacy I/O while moving to a new control platform. While this preserves the user's investment in legacy I/O terminations and infrastructure, installation can take a long time and involves an increased footprint and possible problems in I/O mapping.

I/O Substitution
An alternate approach is to offer I/O cards that fit the installed system's form factor, allowing the user to migrate to a new system with no changes in wiring, installed cabinetry, or hardware infrastructure. This can be a very cost-effective option, but not one offered by all suppliers.

Encapsulation
Most suppliers also offer a software component solution that provides code translation or object wrapping. These solutions can be based on technologies such as OPC, or more proprietary in nature. This approach is functionally similar to a gateway. Suppliers with OPC offerings usually add their own proprietary extensions that provide additional security and/or reliability.

Supplier References Are Critical
Process automation system suppliers clearly understand the importance of their installed base. All the major suppliers focus on retaining their installed base by making sure that they have a path forward from their legacy system to their latest process control technologies. Some have a bigger challenge than others in this respect due to multiple system offerings, largely a result of industry consolidation. Ultimately, all suppliers want to get to an automation platform that is both scalable and "future proof."
However, the point at which existing users begin to consider migrating to a new platform also represents a point of vulnerability for suppliers. Even if the user is generally satisfied with their existing system supplier, it is likely that they will at least explore migration options from competing suppliers. From the user's perspective, when considering migrating an existing control system to a different supplier's platform, it's important to look under the covers. Users should ask the new prospective supplier for specific references from other users who have performed similar migrations and diligently follow up on these by discussing the implementations with those references. Be sure to ask what they liked and what they didn't like, and learn about potential pitfalls that could be avoided with their own implementation.
And, for that matter, it certainly couldn't hurt to ask for references from other users, even when considering migrating from one system to another within the same supplier's lineup.