ɫ��ֱ��

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 stimulation solution provides the highest possible fidelity, but at the highest cost due to the modifications and the cost of hardware acquisition and software licenses. 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 fully controlled by 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.

In the case of the DCS 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/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.