Distributed control systems (DCSs), sometimes known as digital control systems, are now being applied extensively to nuclear power plant refurbishments and new plant builds. L-3 MAPPS has been engaged in numerous simulator projects—both modernizations and new full scope simulators―that require the implementation of DCSs from various vendors. There are different techniques for adding DCSs to the process simulation and for ensuring that the process simulation and the DCS interact correctly. Through our meetings with people in the power generation industry, we have found that these techniques are not always that apparent. Some of these techniques are reviewed below.

What is a DCS?

The following (adapted from Wikipedia) adequately describes a DCS:

A DCS typically uses custom-designed processors as controllers with vendor-specific control software and uses both proprietary interconnections and communications protocols for communication. Controllers have extensive computational capabilities and in addition to proportional, integral and derivative control, can perform logic and sequential control. Input and output (I/O) modules form component parts of the DCS. The processor receives information from input modules and sends information to output modules. The input modules receive information from input instruments in the process (a.k.a. field sensors) and the output modules transmit control signals calculated by the controller to actuators in the field. Computer buses connect the processor and I/O modules. Buses also connect the distributed controllers to the human-machine interface (HMI) or control consoles.

Incorporating DCSs on simulators

The three techniques that are commonly used for adopting DCSs on simulators are stimulation, emulation and simulation. The following definitions are adapted from the IAEA publication IAEA-TECDOC-1500, Guidelines for upgrade and modernization of nuclear power plant simulators:

Stimulation Implementation of a replica of the reference plant DCS on the simulator using actual DCS hardware and application software as installed on the reference plant.	Emulation Implementation of the reference plant DCS on the simulator using the same application software installed on the reference plant but running on the lower cost simulator hardware and operating system. In the case of DCS controls, emulation is sometimes referred to as “virtual machine,” “virtual stimulation” or “virtual controllers.”	Simulation Implementation of the reference plant DCS by simulating the DCS functionality using simulator vendor tools.

On the surface, these definitions appear straightforward enough. However, each of these techniques has advantages and disadvantages, and the right choice for a particular project will depend on a number of factors including the architecture of the DCS, the availability of a simulator-ready solution from the DCS vendor, the availability of upstream proprietary DCS data, the data delivery schedule, the cost, end-user preferences and whether the simulator is intended for engineering, training or both. It should also be noted that a particular project may use different techniques for different DCSs and even different techniques (a hybrid solution) for the control and HMI parts of the DCS. Advantages and disadvantages of each technique are they apply to DCS controls and HMI explored below as.

DCS Control

Stimulation and emulation have the advantage of running the same control software (as generated by the DCS configuration tools) that runs in the DCS controllers of the actual plant. This provides maximum fidelity, facilitates updating the simulator when the plant DCS software changes and is of course particularly useful if the simulator is being used as a validation tool for the DCS. Nevertheless, stimulation and emulation typically appear as external applications to the simulator environment, and as such modifications are required to be compatible with the simulator environment. The proprietary nature of the software and hardware dictates that the modifications are available, if at all, only from the DCS vendor or its partners. For a simulator, the DCS application software must be adapted to support simulator functions such as freeze, run, backtrack and store/restore either by adding this functionality to the DCS software itself or by adapting the DCS software to run as an application within the simulator environment. These modifications must be extensively evaluated. In addition, a stimulated solution may also require specialized hardware and software to interface the process simulation to the control application software running on the DCS controllers. The design of this interface is dependent on the design of the DCS itself. In the case of emulation, a communications interface is also required between the process simulation environment and the emulation, unless the emulation has been adapted to run in the simulation environment.

Of the three techniques, the modifications and the cost of hardware acquisition and software licenses make stimulation the solution that provides the highest possible fidelity—but at the highest cost. In fact, the high cost of the proprietary DCS hardware means that this solution is in practice rarely chosen for the control application software on the simulator. Emulation of the control application software addresses this problem by eliminating the need to use the actual DCS controllers, though the cost of software licenses from the DCS vendor may still be substantial. This is an important consideration when the simulator consists of a suite of simulation instances such as the full scope simulator, development platforms and classroom simulators.

With simulation, the logic represented by the DCS function plans is reproduced using the modeling tool. Simulation can take place either by manually redrawing the function plans or by automatically importing (translating) the function plans. The latter is more efficient, but requires that the function plans contain all interface information and be available in a known electronic format. Simulation also requires object libraries that reproduce the functionality of the DCS functions blocks. Most DCS vendors use a combination of off-the-shelf function blocks (AND, OR, etc.) and custom function blocks. For the latter, access to a functional specification (or ideally the code itself) is required to accurately reproduce the functionality of the controls.

The fact that stimulation and emulation use the same application code as the real station has the potential of facilitating engineering simulator applications and simulator maintenance in terms of commissioning the plant DCS, validating future DCS changes and implementing plant changes on the simulator. There are nevertheless potential disadvantages related to whether the DCS vendor’s implementation of initial conditions (ICs) allows efficient updates of existing ICs and whether there is support for multiple configurations and configuration rollbacks. Another possible disadvantage if the simulator is implemented in parallel to the plant controls is the cycle time required to receive the application software and modifications that address logic errors detected on the simulator, since this is typically determined by the plant design cycle.

On the other hand, a major advantage of simulation is the built-in compatibility with the simulation environment including IC management tools and configuration management. The imported functions plans can be used to generate simulation code directly, either through a purpose-built code generator or by generating editable graphic schematics for the model building tool, provided all the topological data is available in the upstream data. The latter facilitates graphical modifications and debugging. An additional advantage for engineering simulators is that modifications to the logic can be implemented, interfaced to the process and tested directly within the simulation environment faster, before they are implemented on the DCS itself. In addition, licensing multiple copies of a simulation is usually more economical since it is in the full control of the simulation vendor. This makes simulation the tool of choice during the basic design phase of the DCS. In fact, for new builds, early simulation followed by eventual emulation delivers the best of both worlds.

DCS HMI

In the case of the HMI, a stimulated or emulated solution also requires a communication interface and adaptation for the simulator functions. Emulation is particularly of interest when the HMI runs on expensive, safety qualified hardware. For HMIs that run on commercially available computer hardware, the choice between stimulation (or emulation) and simulation depends on the sophistication of the HMI itself. Simulation requires the faithful reproduction of all aspects of the look and feel of the HMI. While some parts of this process can be automated―such as the reproduction of operational pages—a fair amount must be manually reproduced. While simulation is technically feasible, the increasingly sophisticated nature of the HMI graphics usually makes stimulation the solution of choice. Nevertheless, as is the case for controls, simulation is a good choice for engineering applications for the initial design and verification and validation of the HMI, due to its rapid prototyping features and modest licensing costs