Emulated Digital Control System Validation in Nuclear Power Plant Training Simulators

(1)

Emulated Digital Control System Validation in Nuclear Power Plant Training Simulators

Gregory W. Silvaggio

Westinghouse Electric Company LLC [email protected]

Keywords: Validation, nuclear, digital control systems Abstract

Methods for validating an emulated digital control system (DCS) are discussed. Results are presented from a digital turbine control system in which the validation methods have been executed. The focus of this paper is on the validation of emulated control logic rather than the validation of the entire integrated control system, human machine interface (HMI), and plant dynamics simulation.

1. INTRODUCTION

Nuclear training simulators have been in use for many years to train power plant operators in the operations of nuclear power plants. Traditional nuclear power plant control systems are analog, and the control room design includes hard components such as switches, lights, meters, etc. Over the past decade, digital control systems have become prevalent in nuclear power plants as the analog systems are gradually replaced. Along with the replacement of the analog controllers, the hard control room components are also being replaced with soft components such as flat panel computer displays, keyboards, touch screens, trackballs, and mice. Consequently, the simulations of the control systems require more sophisticated models in order to properly replicate the control room to the operator. One control system modeling technique is known as emulation.

Because emulation involves modeling the control system in something other than its native format, a validation step should be performed to increase the user’s confidence that the emulation is accurate. In this paper we investigate and propose a method to validate emulated digital control systems in a nuclear power plant training simulator.

2. SIMULATION ARCHITECTURES

There are a number of ways to simulate the DCS portion of the training simulator. [1] gives a comparison and overview of these methods. Each is discussed below to give further clarification. When comparing simulation architectures, there are a different set of pros and cons. [1]

Provides a table to compare the architectures and lists some of the tradeoffs involved in choosing a simulation architecture. A review of the pros and cons is not provided

here; rather the focus is on the validation of emulated control logic. In the stimulated architectures in which the control scheme simulation is provided by the DCS vendor, control logic validation is not usually a concern. This is due to the fact that the controller software is used intact from the vendor platform. However, in an emulated or partially stimulated architecture, where the controller software is emulated with software outside the scope of supply from the DCS vendor, validation of the simulated control becomes necessary.

2.1. Full Emulation

An emulated DCS simulation is one in which the control scheme is simulated in the modeling environment using tools provided by the modeling platform or by using a programming language such as C or FORTRAN. Emulated DCS simulations can be created manually or by using a code generator which reads DCS data in its native format and converts it into a format which is compatible with the modeling environment. For a typical full emulation, no software is used intact from the DCS vendor. Figure 1 is an example architecture of a full emulation.

Emulated DCS simulations typically require less CPU resources, and a full scope Instrumentation and Control (I&C) system can be simulated on a single computer,

Plant Dynamics

+ Emulated

Control Model Computer Client

Workstation Emulated

HMI Graphics

Simulator Network

Figure 1. Full Emulation Architecture

(2)

simplifying the overall simulation architecture. Emulated DCS simulations are also highly repeatable, a requirement of [2]. The fidelity of an emulated DCS can vary depending on the quality of the modeling of the DCS software. In some cases, modeling of DCS software is done using DCS platform documentation such as user reference manuals, while in other cases the source code of the DCS platform can be used as a reference.

2.2. Partial Stimulation/Emulation

This type of simulation is sometimes referred to as a hybrid simulation. In a partially stimulated architecture, some pieces of the DCS vendor’s software are used in the simulations. Typically, the stimulated equipment consists of the HMI, while the control logic is emulated. This architecture provides a high-fidelity interaction for the simulator user. In this architecture a specialized software interface is needed to connect the emulated DCS to the stimulated HMI. Figure 2 is an example architecture for partial stimulation/emulation.

2.3. Full Stimulation

In a full stimulation architecture, the DCS equipment from the DCS vendor is used. In this architecture, the input output (I/O) interface can be either real or simulated. A real I/O interface is hardware intensive and requires driving the DCS hardware with electrical signals which simulated the sensor inputs into the DCS. This architecture is not usually found on full scope training simulators, but can be found on partial scope maintenance and test systems in order to train technicians on the I/O system and associated wiring. Figure 3 is an example architecture for full stimulation using real I/O.

Another form of full stimulation uses a simulated I/O interface which can eliminate the DCS I/O acquisition system and replace it with a software interface. This reduces the amount of hardware, but this requires a

simulated I/O driver provided by the DCS vendor. With a simulated I/O interface, the controller is typically repackaged into a rack mounted computer, with all the DCS vendor software packages running as is. Figure 4 is an example architecture for full stimulation using simulated I/O.

2.4. Virtual Stimulation

With virtual stimulation, the DCS vendor provides a subset and/or a repackaged form of the DCS software. The virtual stimulation typically makes use of the virtual machine concept in which one or more computing nodes can

+ Emulated

Control Model Computer DCS

Workstation DCS HMI

Graphics

Simulator

Network Plant

Dynamics Model Computer

(1) DCS Controller

DCS Workstation

DCS HMI Graphics

DCS Network

Figure 2. Partial Stimulation/Emulation Architecture

Model Computer

I/O System

I/O Signals

(1) DCS Controller

DCS HMI Graphics

DCS Network

Figure 3. Full Stimulation (Real I/O) Architecture

Figure 4. Full Stimulation (Sim I/O) Architecture

(3)

be executed on a single server. The computing nodes are inherently segmented from each other even though they are sharing the same physical hardware. A virtual stimulation uses repackaged forms of the controller hardware and software, while the HMI portion of the system is fully stimulated. Figure 5 is an example architecture for virtual stimulation.

3. SIMULATION VALIDATION TECHNIQUES Verification and validation is a popular topic with respect to simulation models. [3] Presents a listing of 77 verification and validation techniques for conventional simulation models. Those 77 techniques are grouped into 4 categories: informal, static, dynamic, and formal. In this paper, we propose using both an informal and a dynamic method. Both methods require execution of the simulation models. The informal method present, we call “side by side” (SBS) validation. The dynamic method we present we call “collect and compare” (C&C). Both methods are used to validate the emulation of the DCS against some benchmark or reference data.

Reference data or a benchmark system is required for the validation to be performed. There are two possibilities for obtaining the reference data, 1) collecting data from the actual plant control system while it is controlling the plant, or 2) generating the data from a simulation using stimulated or virtually stimulated controllers.

Collecting data from plant controllers is feasible, only if the plant control system matches the emulated control system. Unfortunately, this means that the validation of the emulated simulation can only be done after the plant I&C system has been installed. Additionally, there is a very

limited subset of plant conditions that actually occur in an operating power plant, especially in the area of malfunctions.

Using stimulated or virtually stimulated controllers in conjunction with a plant model is the ideal method for generating reference data to which the emulated control system is compared. Here, the simulation engineer has complete control of initial conditions, plant evolutions, and can create data for any scenario. Note, that in order to compare the stimulated and emulated control systems, the same plant dynamics model must be used so that the discrepancies between the data can be isolated to the emulated control system.

3.1. Side by Side (SBS) Validation

SBS is a subjective validation technique. It is subjective in the sense that the comparison is done through human observation. This is similar to Face Validation and Turing Tests presented in [4]. Face Validation consists of knowledgeable people evaluating the behavior of the simulation in order to give preliminary approval or disapproval. Turing Tests require output data from the true system and simulated system. If an expert cannot distinguish between the real and simulated system, it has passed the Turing Test.

Although this validation is subjective it is still a valuable method. Furthermore, [2] defines the term noticeable difference as: “Any difference in the physical attributes or dynamic response between the simulator and the reference unit that can be distinguished by an observer and confirmed by a subject matter expert.” The testing requirements presented in [2] are included to ensure that no noticeable differences exist between the simulator and the referenced unit. From this, we conclude that SBS validation, although subjective, is a reasonable way to conduct validation.

In order for SBS validation to be performed, the two simulations (emulated and stimulated) need to have the DCS HMIs physically next to each other so that the tester can easily interact with each HMI. Figure 6 and figure 7 show two possible architectures for SBS. The first step is for the tester(s) to maneuver the simulated plant to the same condition for each simulation. For a nuclear power plant simulation, a common starting point is the 100% power condition. During this step, the tester uses the HMI tools to align and compare the emulation to the stimulated system.

The primary comparison point is the HMI graphics in created by the control system designer. Secondary tools may also be available for comparison such as alarm displays. During this step, the tester may find discrepancies in the emulation. Testing can proceed once the tester has established the same initial condition. Testing consists of maneuvering the system by using operator actions or inserting plant events on both the emulated system and the

DCS HMI Graphics

DCS Virtual Host

Virtual DCS Control (N)

DCS Network

Figure 5. Virtual Stimulation Architecture

(4)

stimulated system and evaluating the response using the HMI. If no noticeable differences are observed, the test is passed.

Figure 7 shows another configuration which can be used for SBS validation. This configuration is ideal if the user can take advantage of a tie-back simulation model. A tie-back simulation model is defined as a simplified model of the plant dynamics which is done within the control logic. If this type of model is available, then the architecture does not require a full scope plant dynamics model computer and it is likely that both the stimulated system and the emulated system can be set up to run on a single laptop. In figure 7, we see that each system is contained in a virtual machine that creates a software based separation between the two systems. This type of configuration is ideal for testing in which the user only wants to work on one physical machine for the purpose of convenience and mobility.

3.2. Collect and Compare (C&C) Validation

C&C is a dynamic validation technique which relies on software to compare the DCS variables rather than using a human to observe the DCS state using the HMI. Just as in SBS validation testing must start from the same initial condition for each DCS system. Currently, the C&C

software developed for this paper supports data collection during steady state conditions only. C&C software must be designed to compare all of the DCS variables without user specification to which variables are to be collected. This is because of the large number of variables used in DCS implementations. For example, in the tested turbine control system, there were approximately 350,000 variables for the DCS. It is impractical to require the user to select which are variables to be compared.

At a minimum the C&C software must have the following features: 1) filtering, 2) user defined tolerance, and 3) ability to ignore user specified variables. Each of these software features are described in the next three sections.

3.2.1. Filtering

Filtering provides a way for the user to limit the comparison to specific types of DCS variables or DCS variables from specific DCS controllers which may be required if the DCS system is very large as in full scope DCS upgrades or new plant designs.

3.2.2. User Defined Tolerance

A user defined tolerance is necessary because of the inaccuracy of floating point values. For example, it seems reasonable to say that the two values 99.999999999 and 99.999999998 are equal, but a comparison statement (i.e. if x == y) would result in false. Additionally, if the DCS variables have defined ranges such as 4-20mA, 0-1800 rpm, or 0-3 mils, then these ranges can be used to normalize the values before applying the user defined tolerance. This is

Host Laptop

Virtual Machine

DCS HMI Graphics

Virtual Machine

DCS HMI Graphics

Virtual Controller &

Tie-Back Model

Emulated Controller &

Tie-Back Model

Virtual Stimulation

DCS Workstation + Virtual Host

DCS HMI Graphics

Virtual DCS Controller

Partial Stimulation

+ Emulated

Control Model Computer

DCS HMI Graphics

Figure 6. SBS Configuration with Multiple Machines Figure 7. SBS Configuration with a Single Machine

(5)

useful when the variables have either very small or very large ranges.

3.2.3. Ignoring Variables

It is possible that some inequalities may be discovered by the C&C software but can be explained by the user. For example, a controller may generate a “flash” signal that repeatedly turns on for 2 seconds and turns off for 2 seconds. If using a configuration like in figure 6, then the two models will be running asynchronously. This means that system 1 can have the flashing variable on, while system 2 can have the flashing variable off. Overall, the waveforms are the same, but they are time shifted. In cases like this where the user can explain the differences, they should be able to configure the C&C software to not report those DCS variables as a difference in any future tests.

3.2.4. Example C&C Architecture

Figure 8 depicts a deployed C&C application applied to the system shown in figure 7. When designing the C&C software the designer must account for any transformations required to compare a stimulated system with an emulated system. If the emulated system is a hybrid emulation/stimulation in which only the control logic is emulated and the HMI is stimulated, it may not be necessary to do any transformations if the data collection interface can be used on the HMI side of the simulation rather than on the control side.

In the architecture shown in figure 8, the C&C server applications collect the DCS variables and send them to the C&C client for comparison. Results are displayed on the user interface. The data transfer mechanism must be a network based protocol such as TCP/IP or a high level mechanism such as Java remote methods or Microsoft dot net remote objects. By using a client/server architecture the same C&C software can be deployed on a single machine or on a network of machines such as in figure 6.

4. RESULTS

The two validation methods described above were implemented in a proof of concept manner on a real world digital turbine control system. The architectures shown in figure 7 and figure 8 were utilized to reduce the amount of hardware required for the proof of concept.

The validation processes were executed at different steady state conditions. SBS validation was performed to ensure that the HMIs showed the same state, and C&C validation was performed to verify that the stimulated DCS variables matched the emulated DCS variables. Some discrepancies were found throughout the validation process, but ultimately, these discrepancies were either explained or resolved. A summary of the results are shown in table 1.

MW indicates megawatt and FSP indicates first stage pressure. During C&C, 4 variables were ignored and a total

of 342,824 DCS variables were compared. For SBS, 15 HMI graphics were compared. A tolerance of 0.1% was used for comparing analog values. In all tested conditions there was 100% match in the C&C analysis and zero noticeable differences during the SBS comparisons.

4.1. Discrepancies

During the preliminary validation process discrepancies were discovered and resolved. The discrepancies can be grouped into five categories: misconstructed code, algorithm error, interface error, initial state mismatch, and ignorable difference.

Host Laptop

Virtual Machine

DCS HMI Graphics

Virtual Controller &

Tie-Back Model

C&C Server Application

Virtual Machine

DCS HMI Graphics

Emulated Controller &

Tie-Back Model

C&C Server Application

C&C Client Application

C&C User Interface

Figure 8. Example C&C Architecture

(6)

Table 1. Tested Conditions and Results

Condition C&C

Match [%]

SBS Diffs.

Noticed 1800 RPM Ready to Sync to Grid 100 0 50 MW Steady State (MW Feedback) 100 0 250 MW Steady State (MW Feedback) 100 0 500 MW Steady State (MW Feedback) 100 0 750 MW Steady State (MW Feedback) 100 0 1000 MW Steady State (MW Feedback) 100 0 50 MW Steady State (FSP Feedback) 100 0 250 MW Steady State (FSP Feedback) 100 0 500 MW Steady State (FSP Feedback) 100 0 750 MW Steady State (FSP Feedback) 100 0 1000 MW Steady State (FSP Feedback) 100 0 50 MW Steady State (Open Loop) 100 0 250 MW Steady State (Open Loop) 100 0 500 MW Steady State (Open Loop) 100 0 750 MW Steady State (Open Loop) 100 0 1000 MW Steady State (Open Loop) 100 0 Valve Mode Full to Partial Arc Transfer 100 0 Valve Test – Main Stop Valve 100 0 Valve Test – Throttle Control Valve 100 0 Valve Test – Intercept Valve 100 0 FSP Transmitter Out of Service (A) 100 0 FSP Transmitter Out of Service (B) 100 0 FSP Transmitter Out of Service (C) 100 0 FSP Transmitter Selector (A) 100 0 FSP Transmitter Selector (B) 100 0 FSP Transmitter Selector (C) 100 0 FSP Transmitter Selector (Median) 100 0 Trip System Solenoid Test 100 0 Manual Turbine Trip (Control Room) 100 0 Manual Turbine Trip (Front Standard) 100 0

Overspeed Trip 100 0

4.1.1. Misconstructed Code

Misconstructed code arises from errors made by the modeling engineer if the emulation is created by hand, or by code generator errors if the emulation is created by an automatic code converter. The result of the error is that the emulated code does not match the intent of the original control system. For example if the control system uses signal A to set a flip-flop and signal B to reset a flip-flop, but the emulation does the reverse, then this is a misconstructed code error.

4.1.2. Algorithm Error

Algorithm error can be found if the control system and control system emulation utilize reusable blocks of logic known as algorithms. These could also be subroutines or functions. The downside is that if the modeled algorithm contains a discrepancy it will be replicated in each instance of the algorithm. The upside is that once the algorithm is updated, it is fixed in every instance.

4.1.3. Interface Error

This type of error can be found specifically in a hybrid stimulation/emulation architecture. In this architecture, a software interface is needed to exchange signals between the computer with the plant dynamics and control emulation and the stimulated DCS HMIs. If any signals are not properly interfaced then errors can arise. The errors ultimately prevent an operator from maneuvering the control system or result in a lack of or incorrect display on the DCS HMI.

4.1.4. Initial State Mismatch

Initial state mismatch occurs when the two systems which are being compared are not in the same starting condition. This is not an error in as much as it is a source of differences that can be found by C&C. When initial state mismatch occurs, the test engineer must take some action to get the two systems into alignment.

4.1.5. Ignorable Difference

This is a category that may be applied after careful analysis by the test engineer. As mentioned in section 3.2.3,

“flashing” signals may cause differences to be detected.

Other types of variables include count variables that are used to keep track of how many times some event has occurred. For example, a count might be used to track how many times a valve has been tested and the test may have been executed more times on the stimulated system as compared to the emulated system. In this case, the test engineer can try to realign the systems, or just ignore the difference and continue with other tests.

5. FUTURE WORK

The main area of future work is to expand the capabilities of the C&C software to account for comparison of transient conditions. The analysis must compensate for the fact that the simulations are running asynchronously and will result in time-shifted data. An optimization technique should be able to automatically perform this time-shifting compensation.

6. CONCLUSION

Simulation validation is not a new topic. Within this paper, we have focused on the validation on the control logic portion of a digital control system emulation. This type of emulation is common in nuclear power plant training simulators. Because emulation involves a conversion step between the control system logic and the simulation, a validation of the emulation should be conducted to ensure a high fidelity simulator. With the methods presented here, we have demonstrated a practical approach to validating these types of systems.

(7)

REFERENCES

[1] Carrasco, J. and Dormido, S., 2006, “Analysis of the Use of Industrial Control System Simulators: State of the Art and Basic Guidelines.” ISA Transactions, 45, no. 2, (April):

295-312.

[2] American Nuclear Society, 1998. Nuclear Power Plant Simulators for Use in Operator Training. # 3.5 555 North Kensington Avenue, La Grange Park, Illinois 60625.

[3] Balci, O., 1997. “Verification, Validation and

Accreditation of Simulation Models.” In Proceedings of the 1997 Winter Simulation Conference, 135-141.

[4] Balci, O., 1989. “How to Assess the Acceptability and Credibility of Simulation Results.” In Proceedings of the 1989 Winter Simulation Conference, 62-71.

[5] Johnstone, M., Creighton, D., and Hahavandi, S., 2007.

“Enabling Industrial Scale Simulation/Emulation Models.”

In Proceedings of the 2007 Winter Simulation Conference, 1028-1034.

[6] Davis, W., 2001. “Distributed Simulation and Control:

The Foundations.” In Proceedings of the 2001 Winter Simulation Conference, 187-198.

[7] Sargent, R., 1998. “Verification and Validation of Simulation Models.” In Proceedings of the 1998 Winter Simulation Conference. 121-130.

[8] Carson J., 2002. “Model Verification and Validation.” In Proceedings of the 2002 Winter Simulation Conference. 52- 58.

[9] Robinson, S. 1997. “Simulation Model Verification and Validation: Increasing the Users’ Confidence.” In

Proceedings of the 1997 Simulation Conference. 53-59.

BIOGRAPHY

Gregory Silvaggio is a principal engineer for Westinghouse Electric Company LLC. He has 8 years of experience in modeling and simulation. He has served as technical lead on several digital control system simulator upgrade projects, and is also involved in the development of full scope simulators for new nuclear power plants. He was previously employed by Electric Boat Corporation where he primarily developed real time simulation models. He is also a part time PhD student at the University of Pittsburgh where he is studying control systems, software, and simulation.