The following discussion is part of an occasional series, "Ask the Automation Pros," authored by Greg McMillan, industry consultant, author of numerous process control books, and 2010 ISA Life Achievement Award recipient. Program administrators will collect submitted questions and solicits responses from automation professionals. Past Q&A videos are available on the ISA YouTube channel. View the playlist here. You can read all posts from this series here.
Looking for additional career guidance, or to offer support to those new to automation? Sign up for the ISA Mentor Program.
What are the most critical points to consider related to instrumentation and control systems when migrating a project from obsolete to modern versions?
Avoid control issues; consider differences in PID algorithms. The proportional–integral–derivative (PID) controller algorithm could vary from the obsolete to the modern version. There are three common PID forms that a control system could offer: parallel form, standard, also known as ISA form, and series, also known as classical form. Be aware that obsolete and modern control systems versions could default or use a different PID form, if tuning parameters are not “translated,” control issues are to be expected. In some, the integral action is in repeats per minute, in others, in seconds per repeat. The Derivative term could be required in minutes versus seconds. James Beall does a great job summarizing the differences in PID forms and provides formulas to convert series to tandard PID tuning in his presentation, “Interesting and Useful Features of the DeltaV PID Controller."
Scaling of devices. The importance of verifying the scaling of your devices cannot be stressed enough. List them and confirm the scaling is correct before start up. It is painful realizing a specific scale had not been properly set when fine tuning product ratios and rates, especially if the change requires a shutdown to correct. Make sure your devices list includes speed ranges and amperages, plus any other information considered valuable.
Communication protocols barrier. In cases where migration is conducted in phases, keep in mind virtual points that get shared between the to-be-migrated controllers and evaluate peer-to-peer communications between them. Build a spreadsheet containing all important details of these peer-to-peer virtual connections and validate these are still needed. Be specific about all changes required to remove these references. If still needed, determine the best way to keep that info between controllers. When minimal, hardwiring them between both systems could be an option with the use of auxiliary termination panels.
When the amount of shared information is considerable, using a hub concentrating all cross-communications is a good option. One of the replaced obsolete controllers acts as the hub. This controller maintains communication with the still-in-operation obsolete controllers and brings information back and forth between both obsolete and modern systems via a serial interface.
Working on a virtual machine minimizes cutover time and allows for testing. When a migration is conducted in a phased approach, the next controllers to be replaced are deleted from the virtual machine database to identify and correct all resulting errors from missing references. The corrected and free of errors database is imported to the production system, spending minimum time to instill the required modifications at cutover, and at minimum downtime.
Adding to Hector’s response, although some features of the existing control strategies and their implementation might be better retired in the new system, the importance of understanding the functionality of the existing system cannot be underestimated. This may involve adding to existing documentation (if it exists at all), which can add to project costs. Adding this step may be resisted, but it increases the probability of a successful execution of the project. Not to be neglected are the discrete controls interfacing to motor control centers (MCCs) for pumps, fans, etc., since overlooking the interface requirements can result in unexpected and hazardous behavior.
To take advantage of the control system modernization as an opportunity to improve plant performance and operability, records such as loss control reports and recorded observations relating to major upsets should be taken into consideration. There is significant benefit in engaging operators in identifying where improvements can be made.
Well-developed written procedures for “swing over” should be considered essential for the successful commissioning of complex systems. This may involve identifying which systems are to be swung over on line and what temporary provisions are required to be put in place to make this possible.
I have done a bunch of migrations, and one of the critical differentiators is schedule. If schedule is less of a concern, you want to invest in a quality job using technology that is proven but also will have a long shelf life. The design and software component is where a lot of additional effort is required to make a state of the art system. Understanding the way functionality can be best implemented for performance and maintainability in a control system can require a lot of training and reading documentation. I have witnessed many poorly implemented migrations caused by failure to understand the native functionality built into a system. These are cases where startups are a nightmare, and once you finally have operation nobody wants to touch anything because the configuration and programming are a mess. Putting the effort into optimizing the implementation has huge benefits that can persist for the life of the system.
If you have a tight schedule, you may need to descope the effort. There are migration tools that can quickly convert configurations, but there will be some fixing required afterward. This may result in sub-optimal yet functional software. There are ways to reuse field terminations with adapters to more modern processors. The result can be a system that closely resembles the prior system, but the new system may have the same limitations that you wanted to improve with a more modern system. Beyond the technical methods, agile project management can compact a schedule. In agile, your team ideally co-locates, has daily updates and plans, implementation is presented continually for review and test instead of testing everything when done, and the design effort is reduced because you and the customer are designing continually in real time. For example, I managed a project that rebuilt a system destroyed by fire in two months with a modern system that the customer has loved for the last three years.
Sometimes the existing software logic and configuration isn’t entirely helpful for a migration. A written sequence of operations/functional specification, updated piping and instrumentation diagrams (P&ID), and input/output (I/O) lists can go a long way toward ensuring that the new system hits the mark.
As others have said, simulations (which we now call digital twins) are enormously beneficial to ensuring that you can go from factory acceptance test to site commissioning efficiently.
The answers above offer a lot of good advice. I will expound on Pat Dixon’s comments and then add a number of other suggestions that have not been covered.
Pat Dixon mentioned “schedule” – I’ll extend that concept by discussing shutdown logistics. Like the experts above, I have personally managed hundreds of control system migrations ranging from < 100 points to over 10,000 points. At our kick off meeting I always ask these questions:
Once I know the time frame, I can start looking at the existing system and begin formulating a plan for the job. Invariably the schedule will drive the design as well as the cost. A tight schedule can cost significantly more for a variety of reasons. For instance:
Another piece of advice I will offer is to do your homework on I/O compatibility. I have seen many a conversion project fail spectacularly because the design team did not fully understand how the existing I/O functioned. One must study the existing I/O in depth to fully understand all of its electrical characteristics to make sure the new I/O cards will work with the existing loops. Things to consider include:
My parting advice is put your top people on the retrofit hardware design. Software can usually be adjusted relatively easily and quickly. Hardware design errors are expensive and often very difficult to resolve.
Take this opportunity to use advances in control valve precision and measurement accuracy and rangeability. For better control valves this means staying away from on-off valves that are enticing due to lower leakage and large capacity and seeking true throttling valves, such as globe valves with low friction packing, diaphragm actuators sized for at least 150% of max thrust or torque requirement and smart positioners. ISA-TR75.25.02 Annex A can provide the guidance needed as to the details and benefits of better throttling valves. For better measurements, this means using resistance temperature detector (RTD) sensors in spring-loaded stepped thermowells where possible, Coriolis and magnetic flowmeters where feasible, radar level where beneficial, and eliminating the many potential problems posed by impulse lines, purges, diaphragm seals, and capillaries.
Further reading:
The many advances in PID technology should be tapped including the use of two degrees of freedom structure to improve setpoint response, directional move suppression via external-reset feedback and valve position control to eliminate the oscillations caused by split range point and an enhanced PID to provide much tighter, smoother control for wireless measurements and analyzers. ISA-TR5.9-2023 should be studied to get the most out of modern PID control capability.
Copy jobs should be avoided. Projects should take advantage of the increased capability offered by modern instrumentation and control systems by better feedforward and feedback control strategies including override control, procedure automation, and state-based control. Take advantage of dynamic simulations using the digital twin to spur innovation and provide the path to the development, testing, training, continuous improvement, and online metrics for success.
Further reading: