In the 1960’s, 1970’s and 1980’s those few plants that could afford a simulator to supplement their training efforts were required to pay a substantial amount of money to do so. This was necessary to provide the hardware and software necessary to emulate a plant. Besides the cost of a high-fidelity mathematical model to match plant performance, the programmers were required to interface with analog hardware (switches, lights, annunciators, controllers, meters, gages, etc.) to match the plant analog control systems.
Since the advent of modern Distributed Control Systems (DCS), simulators have become less costly to build. When plants were operated using large, analog control systems there was a sizable effort to “emulate” or match the hardware-based control systems. Once a mathematical model was developed that closely matched plant operation, it was tied to the physical controllers, switches, lights, meters, gages, and other hardware interfaces via low voltage relaying and direct connection. In the “old days” of hardware-based simulators, the instructors would load an initial condition that required them to do a “switch-check”. This would require the software to flash indicator lights above any switch that was in the wrong position for the initial condition chose by the instructor. Once the “switch-check” was complete, the instructor could then allow the simulation to go “active” without the process crashing due to critical switches being in the incorrect positions.
In the 30 + years since the utility industry has transitioned over to CRT and LCD display based Human Machine Interfaces (HMI), it has become easier to develop a simulator for a plant. This is because the interface between the mathematical model that emulates the plant and its physical systems is now connected to a software based graphic instead of hardware such as physical switches, buttons, meters, and lights. Therefore, we must still develop a mathematical model that looks and acts like the real plant but now we simply connect to dynamic visual displays and not large hardware panels.
The mathematical model that allows the simulator to respond as a real plant responds can have three major variations. Depending on these variations, we use the terms, “low-fidelity”, “medium fidelity”, and “high fidelity”. If the HMI is an exact replica of the actual DCS, but there is no real mathematical model behind the HMI, we consider this a “low fidelity” simulator. It is also called a “tie-back” or “loop-back” simulator. This is because its value as a simulator is primarily to check logic functions and to learn how to navigate the displays. There is little or no usable plant data being calculated or shown.
Some simulators are “medium fidelity”. Unlike the “low fidelity” simulator covered in the previous paragraph, they use a true mathematical model to drive the HMI. However, they are usually a generic mathematical model with little real plant detail and matching data. A medium fidelity simulator will allow users to experience temperature, pressure, and flow changes across the entire operating spectrum of the plant, but these parameters will not match the real plant in similar circumstances. A “medium facility” simulator is useful for generic training at a plant, but not plant specific training.
A ”high fidelity” simulator is one where the HMI and the mathematical model are specific to the plant being simulated. The mathematical model will respond, under all circumstances, very accurately to how the real plant responds to normal and abnormal plant evolutions and operator input.
There are several different ways to connect the HMI to the mathematical model(s). There are many different names and descriptions for these different connection methods. The most expensive and usually the most problematic is when the mathematical model is connected directly to the actual DCS software. This is sometimes called a STIMulation or an “embedded” simulator. Some DCS manufacturers push this method very aggressively. Unfortunately, they are extremely expensive and tend to be by far the most problematic. The DCS vendor will argue that the only accurate method to build a simulator is to connect the model directly to their product. This is baseless and untrue. The DCS manufacturers try and push or hard-sell the fact that the simulator can be used to make changes on the real unit. In this age of cyber-security issues, this is problematic at best and a violation of CIPS (Critical Infrastructure Protection) protocols at worst.
If the embedded simulator is used for operator training, especially after-hours and for non-supervised training, there is a constant threat of the DCS files being corrupted by connection to a thumb drive, the internet, or other method. Additionally and even more serious is the fact that if the simulator is being used in an unsupervised fashion, the user can make unauthorized or un-documented changes to the control configuration files. To then move these files directly onto the DCS can cause a unit outage or worse. Empirical
The big selling point of an embedded simulator is the ability to make changes on the simulator and then move them directly to the DCS. However, doing a proper “translation” of the DCS configuration files provides a highly accurate test-bed for the real plant, without the risks to the actual DCS. When a translation of the DCS configuration files is done correctly, the changes can be made and tested on the simulator just as they are done on the real DCS. If the changes are successful and desired to be made on the plant DCS, it is usually simple and quick to make them on the actual DCS without moving the control configuration files from the simulator to the actual DCS.
When using a high fidelity translator, the DCS configuration files can always be moved to the simulator from the plant DCS. They just can’t be moved back. It is only a one-way transition. However, by keeping the files separate and the actual DCS locked-out from students, instructors, and well-meaning engineers, the simulator truly becomes a safe test-bed without any risk to the DCS. In most cases, the tuning, logic and control changes that are tested on the simulator can be repeated directly in the DCS in far less time than actually moving the entire control database from the simulator to the DCS and with substantially less risk of an upset to the real unit.
In closing, a translation provides all the benefits of an “embedded” simulator with substantially less cost and risk to the unit. The simulator can truly be used as a training tool without risk of contaminating the actual DCS and can still be used to test tuning and logic/control changes. If the simulator is going to be used to train operations and maintenance personnel on an unsupervised or minimally supervised basis, it is highly recommended that the translation route be considered.
