Emulated Digital Control System Validation in Nuclear Power Plant Training Simulators

Transcription

1 Digital Control System Validation in Nuclear Power Training s Gregory W. Silvaggio Westinghouse Electric Company LLC silvaggw@westinghouse.com Keywords: Validation, nuclear, digital control systems Abstract Methods for validating an emulated digital control system () 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 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 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 vendor, validation of the simulated control becomes necessary Full Emulation An emulated 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. simulations can be created manually or by using a code generator which reads 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 vendor. Figure 1 is an example architecture of a full emulation. Client HMI + Control Figure 1. Full Emulation Architecture simulations typically require less CPU resources, and a full scope Instrumentation and Control (I&C) system can be simulated on a single computer,

2 simplifying the overall simulation architecture. simulations are also highly repeatable, a requirement of [2]. The fidelity of an emulated can vary depending on the quality of the modeling of the software. In some cases, modeling of software is done using platform documentation such as user reference manuals, while in other cases the source code of the platform can be used as a reference. simulated I/O driver provided by the vendor. With a simulated I/O interface, the controller is typically repackaged into a rack mounted computer, with all the vendor software packages running as is. Figure 4 is an example architecture for full stimulation using simulated I/O Partial Stimulation/Emulation This type of simulation is sometimes referred to as a hybrid simulation. In a partially stimulated architecture, some pieces of the 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 to the stimulated HMI. Figure 2 is an example architecture for partial stimulation/emulation. + Control (1) Controller I/O Signals I/O System Figure 3. Full Stimulation (Real I/O) Architecture Figure 2. Partial Stimulation/Emulation Architecture 2.3. Full Stimulation In a full stimulation architecture, the equipment from the 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 hardware with electrical signals which simulated the sensor inputs into the. 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 I/O acquisition system and replace it with a software interface. This reduces the amount of hardware, but this requires a (1) Controller Figure 4. Full Stimulation (Sim I/O) Architecture 2.4. Virtual Stimulation With virtual stimulation, the vendor provides a subset and/or a repackaged form of the software. The virtual stimulation typically makes use of the virtual machine concept in which one or more computing nodes can

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. Virtual Host Virtual Control (N) Figure 5. Virtual Stimulation Architecture 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 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 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 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

4 stimulated system and evaluating the response using the HMI. If no noticeable differences are observed, the test is passed. Virtual Stimulation + Virtual Host Partial Stimulation software developed for this paper supports data collection during steady state conditions only. C&C software must be designed to compare all of the variables without user specification to which variables are to be collected. This is because of the large number of variables used in implementations. For example, in the tested turbine control system, there were approximately 350,000 variables for the. It is impractical to require the user to select which are variables to be compared. Host Laptop Virtual Controller + Control Virtual Figure 6. SBS Configuration with Multiple Machines 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 Collect and Compare (C&C) Validation C&C is a dynamic validation technique which relies on software to compare the variables rather than using a human to observe the state using the HMI. Just as in SBS validation testing must start from the same initial condition for each system. Currently, the C&C Figure 7. SBS Configuration with a Single Machine 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 Filtering Filtering provides a way for the user to limit the comparison to specific types of variables or variables from specific controllers which may be required if the system is very large as in full scope upgrades or new plant designs 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 and are equal, but a comparison statement (i.e. if x == y) would result in false. Additionally, if the variables have defined ranges such as 4-20mA, rpm, or 0-3 mils, then these ranges can be used to normalize the values before applying the user defined tolerance. This is

5 useful when the variables have either very small or very large ranges 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 variables as a difference in any future tests 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 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 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 variables matched the emulated 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 Virtual C&C Server Application Host Laptop C&C Client Application C&C User Interface C&C Server Application Figure 8. Example C&C Architecture of 342,824 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 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.

6 Condition Table 1. Tested Conditions and Results C&C Match [%] 1800 RPM Ready to Sync to Grid MW Steady State (MW Feedback) MW Steady State (MW Feedback) MW Steady State (MW Feedback) MW Steady State (MW Feedback) MW Steady State (MW Feedback) MW Steady State (FSP Feedback) MW Steady State (FSP Feedback) MW Steady State (FSP Feedback) MW Steady State (FSP Feedback) MW Steady State (FSP Feedback) MW Steady State (Open Loop) MW Steady State (Open Loop) MW Steady State (Open Loop) MW Steady State (Open Loop) MW Steady State (Open Loop) Valve Mode Full to Partial Arc Transfer Valve Test Main Stop Valve Valve Test Throttle Control Valve Valve Test Intercept Valve FSP Transmitter Out of Service (A) FSP Transmitter Out of Service (B) FSP Transmitter Out of Service (C) FSP Transmitter Selector (A) FSP Transmitter Selector (B) FSP Transmitter Selector (C) FSP Transmitter Selector (Median) Trip System Solenoid Test Manual Turbine Trip (Control Room) Manual Turbine Trip (Front Standard) Overspeed Trip SBS Diffs. Noticed 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 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 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 s. 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 HMI 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 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 s: State of the Art and Basic Guidelines. ISA Transactions, 45, no. 2, (April): [2] American Nuclear Society, Nuclear Power s for Use in Operator Training. # North Kensington Avenue, La Grange Park, Illinois [3] Balci, O., Verification, Validation and Accreditation of Simulation s. In Proceedings of the 1997 Winter Simulation Conference, [4] Balci, O., How to Assess the Acceptability and Credibility of Simulation Results. In Proceedings of the 1989 Winter Simulation Conference, [5] Johnstone, M., Creighton, D., and Hahavandi, S., Enabling Industrial Scale Simulation/Emulation s. In Proceedings of the 2007 Winter Simulation Conference, [6] Davis, W., Distributed Simulation and Control: The Foundations. In Proceedings of the 2001 Winter Simulation Conference, [7] Sargent, R., Verification and Validation of Simulation s. In Proceedings of the 1998 Winter Simulation Conference [8] Carson J., Verification and Validation. In Proceedings of the 2002 Winter Simulation Conference [9] Robinson, S Simulation Verification and Validation: Increasing the Users Confidence. In Proceedings of the 1997 Simulation Conference 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.