Your Control System Is Not a Simulator
The old practice of adding IO tiebacks and simulation into the control system configuration is still being promoted by some companies in the automation industry. It’s a bad direction for a process company to take and here is why.
Back in the Mid 1980’s…
Munger Company, a St. Louis based automation company, had a problem on automation projects startups. Their engineers had no real way to test the control system configuration well before startup and mistakes and design errors in process control were killing them on plant startups. They tried adding IO simulation to the control system configuration but that only added additional errors when they removed the IO simulation before delivery to the plant. On top of this problem, the plant managers wanted to train operators before startup and there was no real way to build even simple process models. Rick Story (VP of Munger Company at the time) came up with the idea of an IO and process simulation system that was external and non-intrusive to the control system. He recruited a young software engineer named Nobin William (now MYNAH VP of Technology) to develop a product named SIMVOX. Using SIMVOX, project performance and customer satisfaction changed overnight. Control system configuration quality improved and they even had a solution for building process models for operator training.
Nobin William and Rick Story, Developers of SIMVOX, with Mart Berutti in December 2002
SIMVOX was a breakthrough technology in its time. It ran under Digital Equipment Company’s VMS operating system, required the user to build models in Fortran files, and was, by today’s software standards, primitive, but it was better than the flawed practice of adding IO and process simulation into the control system. Yet this same flawed practice is still being used and even promoted under the name of a “native” simulation offering.
It is incredulous that this approach is even considered with the current tools available for dynamic simulation of automation systems. Almost every automation company had a control system simulation or emulation offering that allows the user to run control strategies, operator graphics, and complete configuration in a PC environment unchanged. These control system simulators have open interfaces using OPC, Modbus TCP/IP, or EtherNet/IP for IO stimulation and training snapshot and speedup/slowdown controls. They are built to be used with a non-intrusive, external IO and process simulator. The integration of these two systems using open protocols is a trivial task.
A Flawed Approach to IO and Process Simulation
In spite of the advances in product offerings and technology, some users and solutions providers still try to convince process users to add simulation to their control systems. This flawed approach should be avoided for the following reasons:
- The solution will be difficult to update and maintain. Adding simulation to the control system requires additions to the control system configuration. In some cases the developer of this type of solution will also delete portions of the control system configuration to make it work. This makes the process of keeping the control system in the simulation environment updated with the on-line control system very difficult and time consuming. The white paper Control System Integrity and Operator Training covers the best practice of keeping the configuration of the training control system identical to the on-line control system.
- The process model will be inferior. Process control systems are made for process control not process simulation. In the function sets of control systems, the process modeling tools required to even build a decent medium fidelity model are absent. To develop even a simple model, the use of custom calculations and complicated modules is a necessity. The result is a complicated solution that provides inferior model performance.
- The operator training tools will be inferior. Process control systems are not made for operator training scenarios either. Adding process or instrument malfunctions, evaluating the operator performance, and generating sessions reports have to be done in custom calculations and complicated control instructions sets not built for operator training scenarios. Instructor screens have to be built in the control system HMI graphics adding another point of modification to the control system configuration.
- The solution cannot be used for control system testing and optimization. A key requirement of using simulation for control system testing and optimization is to have the offline system configuration identical to the plant control system. Adding simulation to the control system adds error and impedes the user from being able to “freeze” the configuration following testing. We cover the requirements for frozen code in our white paper on GAMP4 and Process Simulation.
- Maintaining or adding to the model will be very difficult without having the original developer under contract. An implementation of IO or process simulation in the control system is a custom, be-spoke solution. Inevitably the user will need to employ the original developer to make changes or add to the system. Upgrades, enhancements, and additions will be more expensive than using a dynamic process simulator made for operator training and control system testing.
The Virtual Plant – A Better Choice
Instead of adding IO and process simulation to the control system configuration, consider the virtual plant. The Virtual Plant uses the automation company’s control system emulator with a dynamic IO and process simulator. It overcomes the issue with “native” DCS simulator deployments while providing a proven infrastructure for operator training and control system optimization and testing. The value of this approach to process plant operators is explained in the Business Case for the Virtual Plant Using MiMiC Simulation Software.
Other Resources to Review
I look forward to your comments, questions, or suggestions.
Hope to hear from you soon.
Mart Berutti, 03/23/12