By Chad Harper
Those systems don’t look like they did when they were initially installed. Hard disk drives, monitors and keyboards that receive constant use simply don’t survive over decades, and such old equipment isn’t available anymore.
If you ask your local computer store for an IBM XT motherboard and 20 MB hard drive, you’ll get some puzzled looks. So unless your automation systems are brand-new, they are likely multigenerational due to obsolescence and devices wearing out, if nothing else.
In some cases, old subsystems and components were replaced for higher functionality equipment, such as with the human-machine interface (HMI). Making that kind of upgrade probably includes adding PCs, with operating systems that support functionality not available when the original HMI was installed.
Automation systems can be problematic due to system providers going out of business or being acquired by other companies. In the 1980s or even 1990s, the landscape of companies providing control systems was much different than now. If you work with an automation system from a more-or-less extinct supplier, you are probably all too aware.
Getting multigenerational and multivendor components to work together can be a challenge. But that approach may be the only option when there aren’t any practical alternatives, and end-users must be prepared to deal with the inherent challenges.
Limping along versus upgrading
At some point, an old automation system that has not been upgraded will become a serious threat to production. As printed circuit boards and network devices get older, individual components begin to fail and systems fault more often. That leads to unscheduled shutdowns and outages that are especially disruptive when replacement parts aren’t available.
Companies specialize in recycling parts for old systems. There’s always eBay, but supplies get tighter and tighter over time. Individual components, especially chips, are often long out of production and cannot be replaced. Vendors may try to create some sort of functional replacement, but redesigning an old board with new components is expensive.
If a plant is going to shut down for a defined period of time in the near future, you can limp along with an old system until then. But that’s not an appropriate long-term strategy, and eventually some type upgrade or migration must be at hand.
An upgrade adds newer elements, but largely sticking with the same automation system vendor and platform. A migration is a major platform change.
Two project patterns
Replacing some part of an automation system with something else typically follows one of two patterns:
The first encompasses multigenerational systems. The original company is typically still in business and has upgrade strategies that allow users to add to an old platform, gradually bringing up the whole system on a modular basis without major disruptions. This is not easy, and successful execution requires strategic planning.
A multigenerational platform isn’t possible in every case. Even if still with the original vendor, be aware of the support dates for each automation piece. Often, certain controllers or nodes lose support before others.
In the second pattern, elements from a different vendor are "bolted on" to an existing automation system. This is difficult to pull off in the real world. Such a system can be buggy, and it won’t have the greatest vendor support.
Based on personal experience working with many automation platforms, these bolt-on solutions are rarely successful over the long term. MAVERICK views bolt-on solutions as temporary bandages, used either to add a few years to the older system or as a part of a larger phased migration plan that will change the bolt-on components to an integral part of an entirely new automation system.
Bolt-on solutions may be necessary for discontinued legacy systems, but often we instead see them as the result of a vendor’s aggressive cross-platform competitive attack. In our experience, one supplier trying to dislodge another often uses a bolt-on solution as a means to get in the plant and establish a position for getting deeper into the system. Unfortunately, we have seen too many situations where the effectiveness of these solutions was over-promised.
So if you need to upgrade but aren’t ready for rip-and-replace, follow the path of a cross-platform, multigenerational upgrade or migration. There will be complications, but they can be managed with a comprehensive project plan.
Evaluate a project
Why do people upgrade or migrate? Today, the biggest drivers are lifecycle issues. And, unfortunately, adding functionality is usually a distant second priority. We show customers where there can be improvements, but adoption of those recommendations during a migration project is pretty rare. The justifications for adding improvements don’t often make it into the business case argument in a compelling manner — or there may be other corporate financial issues that preclude all but the essential expenditures.
Pre-Great Recession, managers might ask to begin migrating before a complete collapse of the old system. They would point out the new capabilities they were getting and how they would improve production and cut operating costs. That sort of thing doesn’t happen as much today. Companies rarely even discuss an upgrade or migration until the old system is coughing up blood.
To run a plant reliably and safely for years, a solution has to be considered as permanent and appropriate. That’s one reason bolt-on solutions will tend to disappoint; they often become permanent.
Once word gets out you’re considering some improvements, vendors will come with sales pitches, simulations and lots of promises. Cross-platform, multigenerational projects are not easy. All vendors can show you good projects, but each one has also had unmentioned disasters.
We believe an independent system integrator can speak freely bout both successes and failures.
As you consider your latest project, basic questions need to be answered:
- Functionality — What will be expected at the completion of a successful transition? What new capabilities do you expect to add? Smart I/O? APC? Better enterprise connections?
- Cost — Is the company willing to spend for production improvements?
- Operators — What will the operators see? Modern HMIs with improved alarm management — or the same old thing?
- Schedule — Is there time to plan, or is this an emergency project due to major plant failures? Can the project be timed to accompany a shutdown, or will everything need to be cut-over hot?
Some suppliers oversell bolt-on approaches and can be the voice of reason. This can mean dumping cold water on some of the sales pitches ¾ a necessary, if often unpleasant, task.
What should be delivered?
Don’t underestimate the value of equipment kept in stock. Think about the purchase in the context of a 15 to 20 year lifespan and total cost of ownership.
Does the platform have a guaranteed support date? Does the vendor have a record of sticking to it? Is the vendor itself getting ready to switch to a new platform?
We often bring in operators early in a project to educate them as to how a new system can be used to improve operations. This typically includes better graphics, improved interaction with HMIs, simpler alarm management and so forth. We explain the concepts of high-performance graphics, supported by findings from the Abnormal Situations Management Consortium, and show what they should expect to see with a system up and running.
It’s OK to keep basic control strategies, I/O and field devices constant, but you don’t want to replicate the functionality of the old system. Making a new system behave like an old one ignores many useful improvements, can create a maintenance nightmare and usually requires going to great lengths just to make everything work.
Even so, we sometimes preach to customers to use the built-in capabilities they get with a new automation system. For one thing, deviating from a vendor’s preferred path can be very expensive.
Taking the first steps
Know such things as:
- Is the plant continuous or batch, "manual" or "automatic?"
- What type production? Long product runs? Short ones? Lots of variations?
- How much money is available?
- What is the condition of the existing automation system infrastructure?
- Does the scope consider immediate needs and future expectations?
- If new controllers go in one part of the plant, will those talk to the old controllers?
- Are there supervisory controls that need to talk to both generations?
Companies frequently get in trouble right out of the gate because they don’t evaluate their controllers and networks adequately. New systems invariably create more network traffic and require more processing power, and not all existing systems can handle the extra load.
Here is an example of the kind of thing that can and does happen. A process unit wants to install a new HMI to work with existing controllers. The plant doesn’t study network traffic and controller loading, not realizing they’re already on the edge of capacity. Based on a snazzy supplier-supplied simulation, old equipment is taken out and new HMIs installed. The system crashes when they cut over.
Another company might have both HMI systems work in parallel so that the old one can serve as a temporary backup, but instead both crash because they together reuire even more network resources.
There’s no substitute for proper planning and testing upfront, as a relatively small amount of time and money spent on these tasks can prevent disastrous results down the road.
There’s no universal best platform or solution because each one has its particular strengths for specific types of applications. There’s also no single leading automation system or migration path, as many factors lead to the best choice for each project.
There is much at stake in such projects because even a couple days production can easily be worth far more than the project costs. In fact, downtime costs often make a true rip-and-replace approach infeasible due to the economics of lost production, forcing a phased upgrade or migration.
As senior director, Chad Harper serves as the leader of MAVERICK’s Technology Group. Chad earned his Bachelor of Science, Chemical Engineering (BSChE) at the University of Arkansas. He is also a certified Project Manager Professional (PMP) and Certified Automation Professional® (CAP®).
MAVERICK’s Technology Group comprises subject matter experts within the organization. They provide content for training programs, reuse strategies, and ensure quality on projects on those platforms.
