DCS Migrations – Comparing the Process for Two Approaches
07.30.2021When approaching a distributed control system (DCS) migration, you might decide to approach it with a from-scratch approach, designed from the ground up, or a one-for-one approach, replicating the legacy system as closely as possible. We outlined the arguments for each in this blog.
There are valid reasons to take one approach or the other. But how does the process for each differ?
The Process: From Scratch
If fully-updated and complete documentation does not exist for the legacy system, the design of a from-scratch system begins with discovering what is the intent of the legacy controls. This can be through reverse engineering (studying the existing code) combined with intensive interviews with operators and other personnel. Controls engineers will use an intensive reverse engineering process to reveal the needed functionality as well as to identify dead code that doesn’t need to be put back into the system. Depending on the system, this could turn into a lengthy investment of time up front but saves configuration/implementation time later in the process.
In addition to studying the functionality of the system, engineers will investigate the state of legacy graphics on the HMIs. Through interviews with operators and a deep understanding of the system, controls engineers will be able to build graphics that easily bring forward pertinent information to operators. Modernized graphics with an increased focus on the user interface (UI) often make it easier to manage alarms and to identify abnormal situations more quickly and effectively. By understanding the needs of the operators, the new graphics can make the operators’ efforts more efficient and reduce errors.
In addition to functioning efficiently and improving abnormal situation management, a from-scratch system will be less expensive going forward for maintenance and improvements as compared to a one-for-one system. The lean code allows use of the latest technology and faster optimization with fewer considerations. Occasionally the legacy system was so convoluted that some modifications or improvements are not possible. A one-for-one system requires a dramatic increase in effort to maintain the system going forward, is more difficult to startup, and requires additional processing capacity in the controllers.
Troubleshooting a from-scratch system will most certainly be faster resulting in less downtime due to the lean code, with the added benefits of up-to-date system documentation and a team that has a deeper understanding of the system that is implemented.
Still deciding? Download our DCS Migration Approach Whitepaper
The Process: One-For-One
If the migration is to a similar type of system, there is the opportunity to review the code, labeling relevant sections as “in use” or “obsolete,” thus streamlining for future ease of maintenance, although this task could be time consuming depending on the complexity of the system. The client also shares in the responsibility in identifying and/or confirming that sections of code are obsolete. An important consideration in the removal of dead code is creating accurate records of all changes, including fully documenting what code has been removed.
Despite the fact that the framework has been decided by the choice to create a one-for-one system, controls engineers can use the opportunity during the project to identify areas that are not working well and look for improvement in those places.
“While you are going through the migration process on a one-for-one system, you are identifying everything that’s been programmed and making a determination on how those things are going to get programmed in the new system,” said Karen Griffin, P.E., VP of Controls & Automation. “Take advantage of the new system’s capabilities where you can. Sometimes we have the opportunity to use slightly different controls strategies that are compatible with the new system and create efficiencies.”
How far do you take the reverse engineering process? “We’ve had clients that want everything that is in the old system to be present in the new system. Once we have evaluated what’s in the old system, we can make a determination on what to keep. For example, you may have created complex structured text in legacy systems to perform a function that is built into newer systems. Instead of re-creating that structured text, take advantage of the new system’s advanced capabilities,” said Griffin.
