|L|CTRIC POW|n 8 lST[m$
ELSEVIER Electric Power Systems Research, 29 (1994) 27-33
Use of an expert system shell to develop a power plant simulator for monitoring and fault diagnosis
Alvin C.B. Wong, H.K. Ho and C.Y. Teo Division of Electrical Engineering, School of Electrical and Electronic Engineering, Nanyang Technological University,
Nanyang Avenue, Singapore 2263 (Singapore)
(Received May 5. 1993; accepted October 6, 1993)
A prototype real-time knowledge based system, SPARES (Steam Plant Analysis using a Real-time Expert System and Simulation) has been developed to act as an operational and diagnostic aid to operators of steam power plants. This system enables abnormal and inefficient operating conditions such as high stack temperature and low boiler efficiency to be detected, analysed and diagnosed. Some special features of the system include the simulation of the power plant process at any unit loading and under a wide range of normal and abnormal conditions. SPARES is implemented on an engineering workstation using Gensym's G2 object oriented real-time expert system shell modelled on a 250 MW generating unit in Singapore. The knowledge acquired for SPARES has been encoded in the form of engineering models and objects, rules, and mathematical simulations and formulae. Efforts have been made to make the representation and reasoning structures and methods as generic as possible so that similar systems for other power plants can be developed with minimal effort.
Key words': Expert systems; Power plant simulation; Fault diagnosis
The need for real-time diagnosis of steam power plants has been recognized for many years. Current economic and social factors put a stringent requirement on steam power plants to be operated at a high level of efficiency and safety at minimum cost. The result has been an increase in the complexity of power control system operations. Present control systems do not provide the means for intelligent interpretation of sen- sor data, diagnosis of problems, coping with large process disturbances or predicting the consequences of control actions. In a steam power plant, a human operator has to monitor several hundred measurements and alarms. In a major upset, the operator may be confronted with large number of alarms but very lim- ited intelligence concerning the underlying plant condi- tions. To understand the plant condition will require the time consuming task of analysing the incoming data before any action is taken. While their abilities may match the demands of day-to-day operations, even the most rigorously trained operators can be overwhelmed
Elsevier Sequoia SSD1 0378-7796(93)00796-S
by the flood of alarms and upset indications generated by a process interruption or fault.
As a result, there is a strong tendency towards the development of knowledge based systems in the power generating industries dealing with real-time monitoring and fault diagnosis. Few of these systems for time critical processes are in daily operation because they do not include special real-time requirements. This paper reports research into the real-time complex domain of steam power plant operation by developing SPARES (Steam Plant Analysis using a Real-time Expert System and Simulation) which combines the strength of frame based representation and a rule based paradigm to provide process system modelling, causal reasoning and temporal inferencing. The development of SPARES was motivated by an immediate need for a powerful and flexible real-time knowledge based system for the power generation industries.
The research goal is to develop a prototype real-time knowledge based system to act as an operational and diagnostic aid to operators of steam power plants. The developed system enables abnormal and inefficient
28 A.C.B. Wong et al./ Electric Power Systems Research, 29 (1994) 27 33
operating conditions to be detected, analysed and diag- nosed. Experiments are carried out to find a balance between explicit, user oriented knowledge representa- tion and real-time performance for complex engineering systems.
2. Implementation of SPARES
Structurally, SPARES, which is implemented using a G2 object oriented real-time expert system shell [1,2], has six main subsystems, namely, the knowledge base, the real-time inference engine, the plant simulator, the fault simulator, the plant data interface and the user interface. The architecture of SPARES is shown in Fig. 1.
2. 1. The knowledge base
Knowledge in SPARES is organized as objects, rules and formulae segregated into workspaces. The two main classifications of workspace are the plant-area workspace and the developer workspace. The plant-area knowledge base consists of seven workspaces: boiler drum, superheater, reheater, economizer, feedwater supply system, turbine/condenser and combustion con- trol. Each of these plant-area workspaces is a collection of process equipment related to its plant area. For example, the boiler-drum workspace contains objects such as the boiler drum, pump, valve, sensor-transmit- ter, controller blocks and their associated display and graphs. Besides the plant-area knowledge base, specific knowledge for object definitions, rules and simulation formulae are contained in the developer workspaces.
As illustrated in Fig. 2, vessels, valves, pumps and sensors are represented in the knowledge by objects. Each object has a table of attributes (e.g. Table 1) and
every object belongs to a class. For example, LCV401 and ACV103 are valves belonging to the throttling- valve class. All classes of objects exist within an hier- archy of classes. Each class in the hierarchy inherits the attributes of its superior class. If the process equipment class has an i;~/tow attribute, then all subclasses of the process equipment such as a valve or pump inherit that in[tow attribute.
Each class of objects is defined by an object d~'[inition that specifies the icon, the connection stubs and the attributes. The object definition is an abstraction of the object. Actual application objects are instances of a class. The following is a list of object definitions in the SPARES knowledge base: valves, pumps, containers or vessels, heat transfer devices, turbines, sensors and con- trol blocks. The pipes and signal lines connecting ob- jects are called connections. A connection is an item that graphically links two objects together and thus indicates a relationship between them. Fluid flow through these connections is simulated using rules found in the colour simulation workspace.
A variable is an object that can change its values. Sensor variables are designed for real or simulated measurements. The SPARES variables are designed for computed values. Table 2 shows the level attribute associated with the fuel-tank-1 object. The level of fuel tank 1 in Table 2 is a quantitative variable and has the value 9, as shown by its last recorded vahw attribute. Variables have a validio' interval attribute, the length of time that the last recorded value attribute of a variable will remain valid. Also, variables have a histo O, keeping spec attribute that can be used to store histories of values that change over time. Variables can get values from a number of sources such as the inference engine, the SPARES simulator, formula or external data serv- ers. The data server attribute of a variable indicates the source for SPARES to obtain the values for the
Text Books Design Manuals
Operating and test data from plant
::::::::::::::::::::::::::::::::: ........................................... :(::| 13:!:3:3:3:3:3:3:3:1:!:!:3:3:1ii:3::!:4~:!:::::::i 3~ :!::!:::~:~ ~
Kn~lu~ldg~rB as L~iiiiiiii!iiiiii!iii ~ i:iiiiiiiiiiii!iiiii:i/
Foreign Function Interface
I Steam Property I
Fig. 1. The schematic architecture of SPARES.
,...,......-.... -.-.-..- - - ~ . . .~ . . . . . . . . . . . . . . . . . . . . . . . .
Iii::::i:~i~i~ i~ ~iiiiii[::ii::::ii::::::l
~ ~ G2 File Interface [
G2 Standard Interface | I (nOt i~len,~ntedyet) ]
~ff-line Plant Data
A.C.B. Wong et al./Electric' Power Systems Research, 29 (1994) 27 33 29
i j @FYI03A - - _&
12"-A~LIC103 FYI03B(~ ! @FTI03A To Superheater
- Boi ~ACV103
-1 :- I P103
Blowdown To Valve Treatment Tank
Furnace ] Gas to Gas from burner ~ ~ Tube ] ~ secondary superheater
Fig. 2. Boiler drum workspace.
TABLE 1 Attribute table for an object named fuel-tank-1
Names fuel-tank- l Level 9 Area 20 Max-level 10 Inflow 2.4 Outflow 2.6
TABLE 2 A quantitative variable, the level of fuel-tank-1
Options do not forward chain, depth first backward chain
Names none Tracing and breakpoints default Data type quantity Last recorded value 9 Validity interval 5 seconds Formula none Simulation deta i l s continuous-state, with initial
value 5 Data server use simulator Default update interval none History keeping spec. keep history with max. points
variable. The validity and data server aspects of vari- ables will be elaborated in the following sections.
Rules contain an expert's knowledge about what to conclude and how to respond to given sets of condi- tions. Within SPARES, most rules are generic in form and they apply to a whole class of objects, as illustrated by the equipment validation rules in section 3.
A formula is an equation that provides a value for a variable or parameter. Two types of formulae, specific and generic, are used in the knowledge base. A specific formula is a formula that applies to just one variable.
SPARES uses a specific formula to calculate the value for a variable if the data server for the variable indi- cates the inference engine, as shown in this example. Formulae for numeric, truth valued, symbolic and text variables using arithmetic, logical, symbolic or text expression can be applied. A generic formula applies to a whole class of variables. An example of a generic formula for any fuel tank is "the volume of any tank = the level o J" the tank x the area of the tank". SPARES uses this generic formula to calculate the volume of any vertical tank, if one exists for the vari- able. If the variable has a specific formula, SPARES uses it instead. The knowledge structure described above is used to implement the knowledge of SPARES described in section 3.
2.2. The real-time inference engine
The real-time inference engine in SPARES reasons about the current state of the application, and commu- nicates with the operator or initiates another activity based on the state it has inferred. The inference engine operates on the knowledge contained in the knowledge base, simulated values and values that it has received from sensors and other external sources. The inference engine has the following functions: it scans the rules at the rates associated with each rule, focuses on the key objects by trying rules that are associated with each object regularly, invokes rules of a particular category for a particular class of object and backward chains or forward chains to other rules to find the values.
2.3. The plant simulator
SPARES has a simulator of a hypothetical, dynamic steam power plant model built within itself. Access to
30 A.CB. Wong et al./Electric Power Systems Research, 29 (1994) 27 33
the plant simulator can provide users with the oppor- tunity to experience dynamic situations in a way real systems do not allow. For example, it shows through animation how various fluids travel through a steam plant. In addition, users can use the simulator to re- produce various situations in order to review relevant events. The plant simulator emulates the process dy- namics of key control variables such as flow, pressure and temperature for valves, pumps, vessels, heat ex- changers and other process equipment.
Time based simulation in SPARES is possible due to time based representation of data in the develop- ment software. Every variable in the system, including all object attributes, has an associated validity interval which specifies how long the value remains valid be- fore another value must be requested. An internal time base is used to time-stamp all data, to react to expired validity intervals in variables, and to scan rules accord- ing to their specified scan intervals. Each variable in the system also has a data server specification which tells it where to get updates to its value. When the validity interval for a variable has expired, a number of options are pursued for obtaining a new value, depending on the data server specification. One option for obtaining a new datum is to specify a value or evaluate a formula based on another object's value. For example, the value for the flow to an outlet valve of a tank can be specified as the outflow of the tank connected to it. Another option to determine the value of the object is to use backward chaining or forward chaining. A third option is to obtain the value from an external source such as a sensor interface or a data file.
SPARES makes use of both shallow and deep simu- lation knowledge. A shallow simulation is a collection of simple heuristics that model observed behaviour. In contrast, a deep simulation models the principles un- derlying observed behaviour. These principles are the causal knowledge that drives surface behaviour. Shal- low simulation in SPARES is constructed using actual data from a steam power plant operating at steady- state conditions embedded into mathematical functions and equations. Deep simulation in SPARES is con- structed using simulation formulae based on physical principles such as (volume x pressure/temperature) and discrete-state simulation formulae. An example of the latter category of formulae is "state variable: next
TABLE 3 Simulation subtable of a variable
Time increment for update Simulation formula
History keeping spec.
5 seconds the input-I of FY103 + the input-2 of FYI03 do not keep history
value of the pressure-out of any pump = the pressure-in off the pump + the pump-delta-pressure of the pump, with initial value 1.015". These formulae can be ap- plied as either generic or specific simulation formulae.
A generic simulation formula provides values for attributes across a class of objects. For example, the following is a dependent generic simulation formula: "the bh)ck-output of any summing-controller = the in- put-1 of the summing-controller + the input-2 o/" the summing-controller". The G2 simulator uses this for- mula to evaluate any summing controller that needs a value and does not have specific simulation formulae. Alternatively, specific simulation formulae for vari- ables are recorded in optional simulation subtables of variables as shown in Table 3.
2.4 The .fault simulator
The fault simulator is used to simulate faults manu- ally by triggering certain fault conditions. When a fault condition...