DCS Migrations – Is a One-for-One System More Costly to Install?

08.5.2021

As experts in control systems integration, at Hargrove, we have successfully completed hundreds of upgrade and retrofit projects, and many of them involved migrations from one platform to another in a distributed control system (DCS).  The design philosophy question that nearly always starts off these discussions is, “Should we recreate the current system as it exists today, or should we design it from the ground up?”

Download our DCS System Comparison Guide

No matter how the question is answered, the first step in a migration is normally reverse engineering, which we define as inspecting the existing system and control system to gain knowledge of what it is trying to accomplish.  Reverse engineering normally entails an intensive study of the legacy system’s software code and hardware.

Most often, our customers ask us to reverse engineer the legacy system to determine the intricacies of its control logic and to replicate that structure and code completely on the new DCS, which we refer to as a one-for-one type of migration.  In a one-for-one migration, you take everything in the legacy system – every wire, every loop, every piece of code, every piece of logic, and recreate it exactly in the new system.

An additional facet of a one-for-one upgrade is that since the legacy system logic is being replicated, advancements in technology are not necessarily incorporated into the modern system.  The opposite of a one-for-one system, the from-scratch system is designed from the ground up to optimize and modernize the hardware, software, and manufacturing processes.  It fills the intent of the control system in the best way possible, but can take more time up front to implement.

Customers usually request a one-for-one migration because they feel that the new system will have the exact same operation and contain all the knowledge and functionality of the old system.  While this may be true, it is not as straightforward of a decision as that.

FROM SCRATCH: The Argument for a From-Scratch Migration

“The most successful DCS migration I’ve ever been a part of was a from-scratch batch system,” said Alan Polk, PE C+A Technical Innovation Leader.  “We pulled the interlocks out of the old system because those were related to safety, although we did review them. But everything else: every other piece of sequencing, automated code, all the batch… We threw it out and we sat down with their best operator and said, ‘If you were going to run this unit to its optimum, how would you do it?’ Then we wrote brand new narratives for how you would operate it without duplicating the original code other than for spans, ranges and interlocks.”

Your existing DCS may be decades old, and is likely bloated with long and complex code, what is referred to as “dead code,” blocks that were used in the past and are no longer needed or functional.  The older the code is, the more people who likely were in the system writing and editing it.  The more convoluted it is, the more difficult and time consuming it is to understand, maintain, and make changes to.

“There are likely better ways to control the legacy system,” said Jim Yongue, C+A Senior Technical Consultant. “That system has been there 30, 40, or 50+ years. There’s a lot of controls engineers that have had their hands in it. Maybe you had an engineer or technician that was called in to get the system running in the middle of the night. They may not have understood all the intricacies and put something in to make it do what operations they needed to do that night. It was “temporary” and 20 years later, it’s still “temporarily” in there. Then the next guy that came through maybe didn’t fully understand everything that was going on because it’s already been convoluted once, and so when they needed to do something to it, they added in what they needed it to do. And the next person did the same thing, and the next person…  Now your controls may have 100 blocks of code to perform the functions, where if you sit down and write it today in a from-scratch system, may have only ten.”

If this lengthy legacy code is brought forward to the new DCS, it could work well enough, but it is not cost effective to do extensive edits on it for optimal function; any errors, workarounds, “temporary fixes,” etc. will remain present and prevent optimization.  To further complicate the question, if you are upgrading to a dissimilar system, it will take extra time to translate and troubleshoot the legacy code on the new system.

A true one-for-one migration also freezes the clock at whatever era your old technology was from, and does not take advantage of the modernization and incorporate advancements in alarming, sensing, , and the like.  Although the idea of starting from scratch with the modern DCS may at first seem like a waste of the IP that was developed over years or decades, taking a fresh look at the system will result in a more efficient design, both in its operation as well as in its future maintenance.  A from-scratch system has the added benefit of being able to incorporate technology advancements for additional functionality and optimizing the process to create the most efficient solution.

ONE-FOR-ONE: The Argument for a One-for-one Migration

With such a strong case for the from-scratch system, why are so many one-for-one migrations still being implemented?  Many customers believe the one-to-one solution will be more cost effective and lower risk. Certainly, there is some validity to these beliefs and there are cases where a one-to-one would produce a successful migration, for example moving from a legacy system to a new system on the same vendor platform may have built in efficiencies for a migration.  Another example may be a system that lacks complex configuration. Generally speaking, low level points and simple PID loops are very easy to migrate in a one-for-one migration strategy, many System Integrators have tools to automate this process.  If you are not looking to change the layouts of your graphics, those are also excellent candidates for one-for-one migrations.  Even when employing a from-scratch migration strategy, there is value in evaluating what types of points and graphics can be automatically migrated utilizing a one-for-one approach.  Depending on how similar or dissimilar configuration strategies are implemented from the legacy system to the new system will help determine how successful a one-for-one strategy will be at reducing cost and risk.

Depending on how similar or dissimilar configuration strategies are implemented from the legacy system to the new system will help determine how successful a one-for-one strategy will be at reducing cost and risk.  First, do not assume all code needs to be migrated. With legacy systems, even the best kept, we almost always find code that is no longer functional.  Sometimes this is due to updating a control strategy, modifying instrumentation, or adding or removing parts of an operating unit.  Migrating this code can lead to unintended complications and can make troubleshooting at startup cumbersome.  It is best to clearly document any code that is believed to be non-functional and leave it out of the new system.  A well-designed Factory Acceptance Test will validate that the remaining code functions correctly with this code removed.  If proper documentation is in place, it will be easy to add this back in if the need arises.  Second, it is tempting to force legacy system control strategies into a new system as-is even though the new system has a built-in, off-the-shelf, option to handle the legacy logic.  Ensure a proper understanding of new features and how they are properly implemented is accounted for.  Creating extra configuration in a new system that is unnecessary to accomplish the old strategies can be kludgy and lead to “bit flipping”.  For example, leaving configuration in structured text format when the new system has built-in functionality to accomplish the same control is unnecessary, can lead to difficulty when troubleshooting, and often requires more processing power.  Thirdly, just because your overall implementation strategy is one-for-one, do not assume that everything can be migrated one-for-one.  Simple to moderately complex control schemes can be migrated one-for-one, and one can often utilize tools that will convert the old system to the new system.  For the more complex control strategies, there are advantages to stepping back to ensure the overall functionality of the control scheme is understood and the configuration is implemented in the new system utilizing as much built-in functionality as possible.  This is often a less time-consuming approach, and usually leads to fewer complications at startup.

Utilizing a one-for-one strategy can also save time on graphics.  If the same layouts are used, then it will not take as much time to convert.  Like with configuration activities, integrators should ensure that the built-in functions of the new graphics package are understood.  One example some of the more seasoned Systems Integrators can relate to is when faceplates first started appearing.  Some companies put time and effort into creating the old change zone because that was the way graphics were configured in the legacy system.  Most will now agree that faceplates are superior, and the effort put into re-creating change zones was unnecessary.

When the appropriate boundaries are set around what is migrated utilizing a one-for-one strategy, the time required for implementation can be significantly reduced while still producing a clean system that is easy to maintain moving forward.

Summary

When completing a DCS migration, there are many factors to consider when deciding between a one-for-one or a from-scratch strategy.   With either strategy there is no substitute for working with an expert who knows what to look for in your system’s intricacies, who also has extensive knowledge with both the legacy and new platforms who can guide you to the optimal solution for your particular situation.

Download our DCS System Comparison Guide

Back to News