- Email: [email protected]
The design characteristics of an advanced alarm system for SMART
Available online at www.sciencedirect.com annals of
NUCLEAR ENERGY Annals of Nuclear Energy 35 (2008) 1006–1015 www.elsevier.com/locate/anucene
The design characteristics of an advanced alarm system for SMART Gwi-sook Jang a,*, Duk-hyun Seong b, Jong-yong Keum a, Heui-youn Park a, Young-Kuk Kim c a
I&C HFE Department, Korea Atomic Energy Research Institute, 1045, Daedokdaero, Yuseong-Gu, Daejeon 305 353, Republic of Korea b Samchang Enterprise Co., Ltd, 974-1, Goyeon-ri, Woongchon-myon, Ulju-gun, Ulsan 689 871, Republic of Korea c Department of Computer Science, Chungnam National University, Daejeon 305 764, Republic of Korea Received 27 February 2007; received in revised form 12 November 2007; accepted 12 November 2007 Available online 21 December 2007
Abstract An advanced alarm system (AAS) is primarily a digital system employing advanced alarm process logics and a VDU (visual display unit) based control and display for the alarms. The SMART-AS (system-integrated modular advanced reactor-alarm system) is an AAS. The role of SMART-AS is to provide the information necessary to safely shutdown the reactor under all plant conditions, to monitor the plant parameters approaching or exceeding the operating limits and to minimize the number of alarms, and to group and prioritize the alarms. The purpose of the alarm processing is to extract only the most important and the most relevant data out of the large amount of available information. This is achieved by using active database technologies for alarm data to form the alarms. An active database is able to monitor special situations represented by events and conditions. Hence, active database system (ADS) can recognize specific situations and react to them without direct explicit user or application requests. ADS is very useful for timely applications such as an advanced alarm processing. This paper describes the design characteristics of the SMART-AS and the results of prototyping of the SMART-AS for improving the system’s reliability and availability by using a reliability prediction. Also this paper proposes a new approach to an advanced alarm processing by using event–condition–action (ECA) rules that can be automatically triggered by an active database. Ó 2007 Elsevier Ltd. All rights reserved.
1. Introduction An AAS (advanced alarm system) of NPP (nuclear power plant) is to assist the operator to monitor the systems and processes and to take the necessary actions required to preserve the normal operating conditions. The AAS is primarily a digital alarm system employing advanced alarm process logics and a VDU (visual display unit) based control and display for the alarms. Ideally, the AAS must only present meaningful information, and must not flood the operator with miscellaneous data that he/she does not have to act upon. Also, irrelevant or unnecessary alarms have to be eliminated and the less important alarms are suppressed (Lee and Hur, 1996).
*
Corresponding author. Tel.: +82 42 868 8626; fax: +82 42 861 9618. E-mail address: [email protected] (G.-s. Jang).
0306-4549/$ - see front matter Ó 2007 Elsevier Ltd. All rights reserved. doi:10.1016/j.anucene.2007.11.009
The SMART-AS (system-integrated modular advanced reactor-alarm system) is an AAS and a computer-based information system. The need for an automated extraction of useful knowledge from huge amounts of data has become widely recognized. A database plays an important role in ensuring reliable alarms. A database for monitoring applications has the capability to store the input data from the monitors and to correlate this data to determine the action necessary. The AAS is a database driven information system. To efficiently manage data that varies rapidly over time and process event driven transactions, AAS requires database systems that support an active rule processing. Active databases are a combination of traditional static databases and active rules, meant to be automated mechanisms to maintain a data’s integrity and facilitate in providing database functionalities. Active database systems (ADSs) are able to monitor a special situation represented by an event and one or more conditions. When the
G.-s. Jang et al. / Annals of Nuclear Energy 35 (2008) 1006–1015
event occurs and the conditions are evaluated as true, the corresponding actions are executed. Hence, ADSs can recognize specific situations and react to them without direct explicit user or application requests. ADSs are very useful for timely applications such as an AAS. This would free these applications of the need to continuously monitor relevant events and as a result, the application code would be less complex, more manageable and more reliable. This paper describes the design characteristics of the SMART-AS and the results of prototyping for improving the system’s reliability and availability by using a reliability prediction. Also this paper proposes a new approach to the advanced alarm processing by using event–condition– action (ECA) rules that can be automatically triggered by an active database. And this paper describes the design considerations and solution plan for an advanced alarm processing by using active database techniques.
1007
ware) malfunctions. The malfunctions shall be indicated through the alarm display. The SMART-AS maintains a physical separation and electrical isolation of the redundant alarm systems. Independence of the data communication is as follows: – between redundant alarm systems; – between the SMART-AS and other information systems; – between the SMART-AS and the safety systems. The SMART-AS is isolated from the safety systems by using fiber optic cable to prevent an electrical fault propagation. The H/W and S/W used in SMART-AS are qualified in accordance with the H/W qualification procedure and S/W qualification procedure for the SMART MMIS. 2.2. Design strategies of SMART-AS
2. SMART-AS 2.1. Design requirements of SMART-AS The SMART-AS combines the annunciation and alarm functions in a single system. The role of SMART-AS is to provide the information necessary to safely shutdown the reactor under all plant conditions, to monitor the plant parameters approaching or exceeding the operating limits and to minimize the number of alarms, and to group and prioritize the alarms appropriately. The SMART-AS is designed according to the requirements of the control room alarm reliability of US NRC’s SECY-93-087, Item II.T. It has been reported that the alarm system for the ALWR should meet the applicable EPRI requirements for redundancy, independence, and separation. The redundant alarm systems should be provided. These redundant systems need not comply with the single failure criterion, but independence between the systems should be equivalent to that of the protection systems. The SMART-AS is based on a redundant architecture based on a dual concept. The redundant systems shall inherently minimize the consequence of a failure. The diversity shall allow for a continued plant operation with a failure in any of the information hierarchy elements. To avoid a common mode failure of the alarms, the SMART-AS uses IPS (information processing system) in the MCR (main control room) by means of a diverse mean of the alarms. And diversity is accomplished by using both the IPS and the SMART-AS implemented with different hardware and software to independently calculate and display the same validated process parameters and alarm conditions. The IPS shall independently check the alarm output of the SMART-AS and any discrepancies. The capability for the SMART-AS testing during power operation shall be provided. The hardware and software for the SMART-AS have surveillance and diagnostic test capabilities. Automatic on-line surveillance tests shall continuously check for selected system (hardware and/or soft-
Alarm functions of SMART-AS provide priority 1, priority 2, and some priority 3 alarms which use validated parameter signals based on the priority criteria of the information hierarchy for SMART. Alarm functions are presented in a manner which prioritizes them so that the operator’s response can be based on importance or urgency. Alarm functions are designed to minimize the number of alarms that occur during plant emergencies. Alarm functions of the SMART-AS encompass alarm reduction and suppression functions. Alarm functions reduce the number of alarm tiles to minimize the occurrence of information overload by using the following methods. – combining similar alarms under a single alarm tile; – combining separate channel alarms of the same parameter under a single alarm tile; – single alarm tile with a priority display; – alarm tile provides priority 1 and 2 conditions only. Alarm functions of the SMART-AS reduce the nuisance alarms by using dead band and time delay and they use the following techniques to help the operation quickly to correlate the impact of the alarm on the plant safety or performance: – alarms are arranged by system a group to achieve spatial dedication, – alarms based on plant mode, – alarms based on equipment operating status, – alarms prioritized into operational categories. SMART-AS alarms are displayed in accordance with the visual and audible code strategy of the alarm priority based on the principles of HSI (human system interface) for SMART. The SMART-AS alarms are designed to display spatially dedicated continuously visible alarms with VDU-based alarm tiles and alarm lists.
1008
G.-s. Jang et al. / Annals of Nuclear Energy 35 (2008) 1006–1015
2.3. Configuration of the SMART-AS
Table 1 Constraints of prototype of SMART-AS
SMART-AS is a part of the AIS (alarm and indication system) for SMART. Equipment of the SMART-AS consists of the alarm processor 1 and 2, the alarm test device 1 and 2, the alarm display processor 1 and 2, and alarm display device 1 and 2. Alarm equipment is connected via the safety and non safety networks (subnet A, B, C, D and subnet X, Y). The SMART-AS provides a high availability (99%) to support continuous plant operations. So, the SMART-AS shall be based on a redundant architecture. The sufficient redundancy of the SMART-AS is provided to allow hardware maintenance without taking the entire system into off-line. On line self-checks of the system health are periodically performed to allow for an early identification of the faults. SMART-AS is both flexible and expandable to adapt to the changing needs of the utility throughout the life of the plant. The SMART-AS provides extensive, reliable data communications to support the required system information exchange. Isolation is provided when a communication extends to the integrity of the transmitted data.
Item
Constraints
Requirements Selection for H/W and S/W Redundancy Communication
Apply code and standard conformance Set up selection criteria of H/W and S/W Except qualification requirements of H/W Single configuration Ethernet is temporarily used (communication under design) – Alarm reduction for partial alarms – Alarm suppression for partial alarms Ring-back alarm control based VDU Hyperbolic visualization techniques
Alarm processing Alarm control Alarm display
Table 2 The development environment information of prototype Item
H/W and S/W
Specifications
Alarm processor
Process board
– Processor: TI DSP (TMS320C40) – Memory: Local and global memory EPROM, flash memory VME Bus controller: VIC608A 7000A (ALTER)
System bus Control logic Test device
Personal computer
3. Prototype of the SMART-AS The prototype of the SMART-AS was developed to verify not only the major system functions and design requirements but the technologies which have not yet been implemented in conventional power plants. The technologies for SMART-AS are as follows: – H/W development of digital processing processor board based on VME Bus; – reliability prediction of the developed board; – improving system reliability and availability using the Relax RBD (reliability block diagram); – S/W structures for the advanced alarm processing;
DSP board S/W development
Sub rack
Standard (19”)
Alarm display
Flat panel PC
S/W development
– Pentium III 500 MHz, serial port to communication with alarm processor – 100/10-Base T –Cross development environment –TMS320C40 Assembler, C Compiler, linker – PC based DSP board emulation S/W: board support library, download DSP program, test of DSP board –VME bus backplane – 3U single height -Pentium III 500 MHz, 51 2KB Cache, 384 MB memory, 100/10Base T –TFT Color, 64 K color –Touch type: analog resistive Using QNX 4 OS and Photon MicroGUI
3.1. Hardware development Table 1 shows the constraints for the prototype of the SMART-AS. The development environment information of the hardware and software for the prototype is as in Table 2. Fig. 1 shows the board block diagram for the alarm processor board. 3.2. Reliability prediction The SMART-AS shall be designed for an operational availability goal of 99%. The MTBF (mean time between failure) of the SMART-AS is more than 10,000 h. Equipment that are easily accessible are assumed to be repaired within a short time period after the failure is detected. The MTBF should be confirmed by a reliability analysis based on the failure rate of the components.
3.2.1. Reliability prediction and analysis tool (Relax) A primary requirement for reliability analysis is the knowledge of the failure rate, or the number of failures expected during a certain period of time. Calculation of the equipment failure rate, and the related MTBF of the prototype, is the basis of the Relax reliability prediction software. Relax performs the reliability predictions and analyses on the electrical, electronic, mechanical, and electro-mechanical equipment. The Relax reliability prediction software is available based on various standards, including Telcordia (Bellcire), MIL-HDBK-217, CNET 93 and HRD5. 3.2.2. Prediction of the reliability Electronic systems involve the utilization of very large numbers of devices which are very similar. It is difficult
G.-s. Jang et al. / Annals of Nuclear Energy 35 (2008) 1006–1015
Interface
VME Control Signal
Control Logic (FPGA)
VMEbus Controller
VME Address Bus VME Data Bus
Address Data
Control Signal
B U F F E R
Global Address Bus Global Data Bus
JTAG Interface
Processor (TMS320C40) EPROM EPROM
Local Memory (SRAM)
Global Memory (SRAM)
B U F F E R
Backboard Connector
ISP
Reset Clock
Local Address Bus
Local Data Bus
Flash Memory Memory
Fig. 1. Board block diagram for alarm processor board.
to test for the electronic component defects that do not immediately affect the performance. Very close attention must be paid to the electronics part reliability. A reliability prediction is the analysis of the parts and components in an effort to predict the rate at which an assembly or system will fail. The basis of the analysis is generally a reliability prediction model. Reliability prediction models offer standard equations to calculate the failure rate of the components based on the component data and parameters. These parameters include the environment, temperature, quality and stress. When individual failure rates for the components are established, a simple summation of the component failure rates provides the failure rate for the higher level assemblies and systems. 3.2.3. MIL-HDBK-217 prediction method MIL-HDBK-217 was an original standard for the reliability predictions. It was designed to provide reliability math models for nearly every conceivable type of electronic device. It is used by both commercial companies and the defense industry, and is accepted and known worldwide. MIL-HDBK-217 includes the ability to perform a parts count analysis or a part stress analysis. A parts count analysis is not as detailed as a part stress analysis, and is normally used early in a design when detailed information is not available, or a rough estimate of the failure rate is all that is required. A part stress analysis takes into account more detailed information regarding the components, therefore, offers a more accurate estimate of the failure rate. The parts stress analysis method requires a significant amount of design detail. Many of the details were not available in the early design stages of the SMART-AS.
1009
3.2.4. Parts count reliability method The parts count reliability method can be used in the early design stage when detailed data is not available. The parts count reliability method is used for the generic part type, for the quality factor and the environmental factor. And the following information is required; generic part types (including complexity for microcircuits) and quantities, part quality levels, and the equipment environment. Equation of the parts count method is as follows: kEQUIP ¼
i¼n X
N i ðkg pQ Þi
i¼1
where, kEQUIP is the total requirement failure (failures/ 106 h); kg is the generic failure rate for ith generic part (failures/106 h); pQ is the quality factor for the ith generic part; Ni is the quantity of the ith generic part; n is the number of different generic part categories in the equipment. The prototype of the SMART-AS selected the parts count reliability method for its improvement by showing the highest contributors to a failure. The total equipment failure rate of the alarm processor board is 0.8205. The need for a redundant or back-up system may be determined with the aid of reliability predictions. Also the maintenance strategy can make use of the relative probability of a failure’s location based on the predictions, to minimize the downtime. Reliability predictions are also used to evaluate the probabilities of the failure events described in the failure modes, effects and criticality analysis. 3.3. Improving system reliability and availability using the relax RBD There are several techniques we can employ to improve the reliability, and/or availability of the SMART-AS design. Three common techniques that might be used are the parallel redundancy, standby redundancy, and spares. By using Relax’s reliability block diagram (RBD) tool, the effects of these methods can be investigated when determining if any of these techniques should be used before any design changes. Since one of the main purposes of the RBD is to calculate the reliability and availability of a system based on the redundancies, it is useful to only analyze the SMART-AS at the level that includes redundancies. A reliability prediction model assumed that the configuration of the system was a simple one. As a system configuration becomes more complex, more complex calculation methods are required to calculate values like the failure rate, MTBF, reliability, and availability. The Relax RBD was used to calculate complex redundant systems that cannot be computed by using the Relax Reliability Prediction portion of the program alone. Table 3 shows the failure rate of a component of an alarm processor board for the prototype. Table 4 shows the various parameters and variables chosen for the analysis, as well as the availability, reliability and failure rate at specific time intervals. Standby redundancy is more
1010
G.-s. Jang et al. / Annals of Nuclear Energy 35 (2008) 1006–1015
Table 3 Failure rate of component of a alarm processor board for prototype (N: count, FR: failure rate, CFR: combination of FR)
deviation comparison is secluded from the valid parameter calculation.
Part number
Function
FR
N
CFR
TMS320C40FL60 (TMS320C40) VIC068A-NC (VIC068A)
DSP processor
0.01528
1
0.015281
VME interface controller Flash memory EEPROM SRAM
0.00312
1
0.003120
0.52425 0.00571 0.00571
1 1 4
0.52425 0.005715 0.22860
FPGA
0.659031
1
0.659031
3.4.3. APX_Alarm_Create_Process Upon the detection of alarm conditions, the module processes the alarm processing algorithm based on the validated variables to reduce the nuisance alarms efficiently and to allow the operator to the best focus of his attentions. The applicable alarm logics are the plant operating mode dependency alarm with different setpoints, the equipment status dependency alarm, the deadband and the time delay.
AM29F080B-90EC 27C256-15 (27C256) K6R4016V1C-TC12 (K6R4016VIV-C) EMP7128STC100-15 (EPM7128EQI100-20)
Table 4 Result of reliability analysis Hour
0 20000 40000 60000 80000 100000 120000 140000 160000 180000 200000
Reliability
Failure rate
Availability
Parallel
Standby
Parallel
Standby
Parallel
Standby
1.00000 0.993435 0.975826 0.949867 0.917754 0.881270 0.841854 0.800658 0.758600 0.716402 0.674628
1.000000 0.995849 0.985806 0.970853 0.951851 0.929556 0.904625 0.877631 0.849074 0.819382 0.788928
0.000000 0.633273 1.136928 1.545742 1.883097 2.165296 2.404056 2.608012 2.783674 2.936038 3.069005
0.042247 0.365093 0.641669 0.881257 1.090811 1.275647 1.439893 1.586809 1.719000 1.838575 1.947256
1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 0.999000
1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000
effective than the parallel redundancy because the unit/ junctions are not always operating. The results of the standby redundancy show its suitability for the MTBF and the availability and reliability requirements of the SMART-AS through the use of the prototype. 3.4. Software structure The S/W of the prototype was developed with a topdown structure design approach using TeamWork (CASE tool). The S/W deign used a hierarchical design structure and principles of the modular design with coherence and cohesive modules to reduce the complexity of the verification and validation. High level language was mainly used and assembly language was used only where sufficient performance cannot be achieved through use of a high level language or where it is justified based on the requirements. 3.4.1. APX_Input_Data_Prcoess This module periodically collects the digitized data of an analog and contact type through a safety and non-safety network. 3.4.2. APX_Representative_Value This module executes the logic to determine a single value that can be representative of a given parameter which is being sensed by multiple sensors. As a part of the validation algorithm, any sensor(s) which fails a cross channel
3.4.4. APX_Alarm Suppression_Process Irrelevant or unnecessary alarms are eliminated and less important alarms are suppressed. The applicable alarm suppression logics are cause–consequence processing and multisetpoint relationships. And First-out processing is provided to support the operators in determining the initiating cause of a reactor or trubine trip in the alarm system. By suppressing the minor alarms for a period of time after a reactor trip, the operator’s attention would be directed towards the major problem when multiple alarms are present. 3.4.5. APX_Alarm_Order_Process Alarms are prioritized by their importance to plant safety and its operation. The model indicates the relative importance of the alarms based on a predefined set of conditions and relieves the operator of this time-consuming task when a major event is taking place. The alarm prioritization scheme depends on the alarm categorization strategy based on the information hierarchy for the MMIS. 3.4.6. APX_Management_Process This module is provided to allow for the modification to the existing software and to minimize the mean-time-torepair by generating meaningful error messages. The module recognizes a power failure and is capable of an automatic restart upon the power restoration. The cold start software module is executed when initially energizing the prototype hardware. The warm restart module attempts the continuation of the program without the hardware initialization. 3.4.7. APX_Fail_Over_State_Monitoring_Process Not implemented. 3.5. The advanced alarm processing based on the active database technologies The purpose of the alarm processing is to extract only the most important and the most relevant data out of the large amount of available information. This is achieved by using active database technologies for alarm data to form the alarms. An active database is able to monitor special situations represented by events and conditions. Active rules, which originate from production rules in expert systems, represent knowledge through event–condition–
G.-s. Jang et al. / Annals of Nuclear Energy 35 (2008) 1006–1015 Table 5 General form of an ECA rule On Event if Condition do Action The Event of an ECA rule determines when the rule should be evaluated The Condition of an ECA rule determines whether the action should be executed The Action of an ECA rule determines how to react if the condition is evaluated as true
actions (ECA) rules. Knowledge can be stored as event– condition–action (ECA) rules. Active database technology can, therefore, enable a system to have a reactive processing and autonomous response to an event that occurs inside or outside the system. The general form of an ECA rule is illustrated in Table 5 (Tan and Goh, 1999). Many applications, including classical ones like an inventory control, would run much more efficiently. This would free the applications of the need to continuously monitor relevant events and as result, the application code would be less complex, more manageable and reliable. In developing an active database system it is necessary to consider a number of issues (Jennifer, 1996): – An active database system must provide all the usual functionality of a conventional passive database system. Meanwhile, it is deseirable that the performance of conventional database tasks is not degraded by the fact that the database system is active. – Ac active database system must provide some mechanism for users and applications to specify the desired active behavior, and these specifications must become a persistent part of the database. – An active database system must efficiently implement any active behavior that can be specified; it must monitor the behavior of the database system and, when appropriate, automatically initiate additional behavior. – An active database system must provide database design and debugging tools similar to those provided by conventional database systems, extended to incorporate active behavior. 4. Design considerations of the active database system for the advanced alarm processing This section describes the design considerations of the ADS (active database system) for the advanced alarm processing, and it also describes the solution plan against each consideration. 4.1. Rule management The ADS for the advanced alarm processing includes a component for managing the set of rules in the system. The Rule Manger is used to implement the active concepts. In the Rule Manager, ECA rules are grouped in a class-hier-
1011
archy of alarm tiles and can be inserted, deleted and modified. Once rules are defined, they must become a persistent part of the database system, which is usually achieved by storing rules in the database itself. 4.2. Active database rules 4.2.1. Events for the advanced alarm processing The ADS is centered on the notion of rules. Rules in the ADS are defined by users, applications, or database administrators; they specify the desired active behavior. In an active database rule for the advanced alarm processing, the event specifies what causes the rule to be triggered. Useful triggering primitive events for an the advanced alarm processing are: – Time A temporal event might specify that a rule should be triggered at an absolute time (e.g., 1 Jan 2006 at 12:00), at a repeated time (e.g., every day at 12:00), or at periodic intervals (e.g., every 10 min). – Application-defined Application-defined events might be specified by allowing for an application to declare a name E as denoting an event (e.g., high-temperature) and allowing for an active database rule to specify E as its triggering event. Then, each time an application notifies the database system of the occurrence of event E, and the rules specifying E as its event is triggered. Using this approach, the application may perform any monitoring or computations it desires (with or without accessing the database) to detect when event E should occur, i.e., to detect when the rules associated with E should be triggered. 4.2.2. Conditions for the advanced alarm processing The condition part of a rule is usually a Boolean expression, a predicate, or a set of queries, and it is satisfied if the expression evaluates to true, or all the queries return nonempty results, respectively. In the ADS for the advanced alarm processing, values related to the condition can be passed to the action. And the ADS allow the condition part of a rule to be omitted, in which case the condition is always true. Like action execution, evaluating the conditions of triggered rules can involve executing large operations on the database, but in some cases these operations may be reduced or avoided. Two methods for reducing the overhead in rule condition evaluation are discrimination networks and incremental evaluation (Jennifer, 1996). In the ADS for the advanced alarm processing, rule conditions may be evaluated multiple times, and incremental evaluation techniques can be useful in optimizing the condition evaluation phase of rule processing. 4.2.3. Actions for the advanced alarm processing The action part of a rule is executed when the condition is satisfied. In general, an action can be database operations,
1012
G.-s. Jang et al. / Annals of Nuclear Energy 35 (2008) 1006–1015
transaction commands (e.g., abort transaction), or arbitrary executable routines. The action may access, besides the current database state, the database state at the time of event occurrence and the time of condition evaluation which can be accomplished by parameter passing. In the ADS for the advanced alarm processing, the action language includes a mechanism for referencing the values bound to the event’s parameters. And the ADS allows a rule to specify a set of actions, usually with an ordering so that the multiple actions are executed sequentially. 4.3. Rule define language There is a notable difference between AI rule languages and most active database rule languages. In active database rule language, usually it is sufficient to find one rule whose condition is true. One reason for this semantics is that in active database systems rule activation is usually based on triggering events rather than on true conditions; a second reason is to avoid the overhead involved in evaluating numerous, potentially expensive conditions. The desired behavior of the ADS is specified by using an active database rule language. Clearly, what can be specified in the rule language has a direct impact on the power and on the complexity of the ADS. The desired behavior of an active database system is specified by using an active database rule language. The SQL3 standard extends the assertion capabilities of SQL92, and it includes a relatively comprehensive trigger language. Triggers in SQL3 provide options for the time of a triggering (BEFORE, AFTER, or INSTEAD OF the triggering option), the granularity of a triggering (tuple-level or statement-level), and for a prioritization (ordering) of multiple triggers during the same operation. A number of commercial products already support relatively powerful active database (trigger) capabilities. The rule define language for the advanced alarm processing is based on SQL3 (ANSI99) and TSQL2 Temporal Query Language (Park, 2000). 4.4. Rule execution semantics While the rule language prescribes what can be specified in each active database rule, the rule execution semantics prescribes how the active database system behaves once a set of rules has been defined. Rule processing algorithm repeatedly finds a triggered rule, evaluates the rule’s condition, and, if the condition is true, executes the rule’s action. The algorithm for a rule processing is iterative. 4.4.1. Rule processing granularity The granularity of a rule processing specifies how often the points occur at which rules may be processed. The finest granularity is ‘‘always”-rules may be processed at any point during the database system’s execution, as soon as any rule’s triggering event occurs. In the finest granularity for the advanced alarm processing, rules may be processed after each occurrence of the ‘‘smallest” database operation.
In some database systems, data manipulation statement provides a granularity for a rule processing that is coarser than database operations. In ADS for the advanced alarm processing, the points at which rules maybe processed are delineated by the applications, although these systems usually provide a default granularity as well. 4.4.2. Coupling mode The most straightforward approach is for the triggered rule’s condition to be evaluated and its action execution within the same transaction and the triggering event at the soonest rule processing point. However, for some applications it may be useful to delay the evaluation of a triggered rule’s condition or the execution of its action until the end of the transaction; or, it may be useful to evaluate a triggered rule’s condition or execute its action in a separate transaction. These possibilities yield the notion of coupling modes. Coupled modes determine the execution of rules with respect to the transaction which triggers them. The event–condition (EC) and condition–action (CA) coupling modes, respectively, determine when the rule’s condition is evaluated with respect to the triggering event, and when the rule’s action is executed with respect to the condition evaluation. Three basic coupling modes are introduced; immediate, deferred, and decoupled. It has been pointed out by several researchers (Berndtsson and Hansson, 1995a,b) that immediate and deferred coupled modes have several negative properties to be supported in realtime databases. The ADS for AAS is soft real-time database system. Hence in ADS for the advanced alarm processing, we only consider the detached coupling mode, which does not impose additional unpredictable execution time to the triggering transaction. 4.4.3. Termination In almost all rule processing algorithms, regardless of whether the algorithm is iterative or recursive, sequential or concurrent, there is a danger of a nontermination. There is a fixed upper limit- perhaps established as a system parameter-on how many rules can be executed during rule processing. If the limit is reached, rule processing terminates abnormally. 4.5. Composite event support 4.5.1. Concepts of composite event The active functionality of the ADS is measured by the ability of the database to monitor various forms of primitive events. On the other hand, the expressive power of the database can be augmented by the ability to detect composite events, which can be made up of different combinations of primitive events. Composite events are made up of combinations of primitive or other composite events. The meaningful ways to build composite events from its constituent events are usually specified through an event algebra that defines certain event constructors (Dayal, 1988). There are six different kinds of event constructors that can be
G.-s. Jang et al. / Annals of Nuclear Energy 35 (2008) 1006–1015
used to construct composite events. These constructors are: disjunction, conjunction, sequence, history, negation and closure (Tan and Goh, 1999). (1) Disjunction (E1_E2) When either E1 or E2 occurs (2) Conjunction (E1^E2) When both E1 and E2 occur, regardless of the order (3) Sequence (E1, E2) When E1 occurs first followed by E2 (4) History When an event E occurs a specified n times, within a specified time interval I (5) Negation (:E) When E does not occur during a specified time interval I (6) Closure Whenever E occurs at least once during a specific time interval
4.5.2. Adapting composite event for advanced alarm processing Alarm processing techniques were developed to support operators in coping with the volume of alarms, to identify which are significant, and to reduce the need for operators to infer plant conditions. This section describes the test case used to demonstrate the advanced alarm processing by using the concepts of composite events. (1) Equipment-state dependency The alarms activated as a consequence of an equipment-state change (e.g., pump tripped) are lowered in priority (see Table 6). (2) Plant-mode dependency The alarms activated as a consequence of a plantmode change (e.g., reactor trip, safety injection, or cold shutdown) are lowered in priority (see Table 7). (3) Multi-setpoint relationship The lower level alarms are reduced in priority when the higher level alarms also are activated (see Table 8). (4) Cause–consequence relationship A fault occurring in a certain part of the plant process propagates through the process following a cause– consequential relationship. As a result of the fault
Table 6 Events defined for an equipment-state dependency Event of Interest
What triggers the event
Action to be taken
E1 E2 C1
Plant trip Low flow E1 and E2
Trigger C1 Trigger C1 Low flow alarm is lowered in priority
1013
Table 7 Events defined for a plant-mode dependency Event of interest
What triggers the event
Action to be taken
E1 E2 C1
Pump trip Low flow E1 and E2
Trigger C1 Trigger C1 Low flow alarm is lowered in priority
Table 8 Events defined for a multi-setpoint relationship Event of interest
What triggers the event
Action to be taken
E1 E2 C1
PZR pressure Hi PZR press Hi–Hi E2, followed by E1 (sequence)
Trigger C1 Trigger C1 Low alarm is reduced
Table 9 Events defined for a cause–consequence relationship Event of interest
What triggers the event
Action to be taken
E1
MFW pump trigger C1, Low suction flow Heater drain tank, low level E2, followed by E1 (sequence)
Trigger C1
E2 C1
Trigger C1 Consequence alarm is suppressed
propagation, an alarm occurring in a part of the process may cause another alarm in another part to be activated (see Table 9).
5. Process of the detection of event for alarm processing The ADS for the AAS should support primitive and composite events and response times for event detection, both primitive events and composite, are crucial for the performance of the ADS. We are developing a framework for applying data mining techniques to alarm processing. This framework consists of programs for establishing a classifier, association rules, frequent episodes and a clustering. Each mining system received the alarm data from a database and established useful rules. Association rule miner can find a correlation among the attributes in a record, although a frequent episode miner searches for event patterns in the records. In addition, a clustering analysis provides a data abstraction from the underlying structure. And it groups data objects into clusters such that the objects which belong to the same cluster are similar, while those belonging to a different cluster are dissimilar. Because we consider the characteristics of the alarm data, we improved the existing data mining algorithms to create candidate item sets that include only the interesting attributes. It is very important to point out that our framework does not eliminate the need to pre-process and analyze raw audit data. In fact, to build alarm processing
1014
G.-s. Jang et al. / Annals of Nuclear Energy 35 (2008) 1006–1015
models, our data mining programs use (pre-processed) alarm data where each record corresponds to a high level event. Each record normally includes an intensive set of features that describe the characteristics of the event. The rule controller consists of programs for establishing association rules, frequent episodes and a clustering. Association rule miner can find a correlation among the attributes in a record. The frequent episodes miner is used to search for a series of event sequences for frequently occurring episodes. An episode is defined by a sequence of specific events that occurs frequently, and events composing a sequence are closely related with one another. Here, exploring is done to find all the frequent episodes in a set of time windows of a user-defined size. A sequence pattern and an episode are similar in that they explore patterns in sequence. However, they are different in that an episode explores while using windows. Using episodes, SMART-AS can automatically detect frequently repeated patterns, and apply them to the rule or use them as guidelines for alarms. When the existing algorithms are used in applying data mining to search for useful patterns from the alarm data, correlations among the attributes must be considered. Alarm data comprises of various attributes, and each of these attributes has many values. Because all this data cannot be converted into a binary database, we propose an expanded algorithm using a row vector. Row vector is a data structure used in the search for frequent items, which contain bit recording transactions that include item sets. Using a row vector has the advantage of having to consider only the correlations among the tuples rather than the co-relationships among the attributes. In addition, as standard attributes are applied, only items including the standard attributes have to be considered in generating the candidate items. This reduces the number of unnecessary episodes in generating the rules. Clustering analysis is a technique to find the distribution or patterns of given data by classifying the data into groups based on a similarity. Such a clustering analysis technique improves the efficiency of the analysis of the alarm data, and abstracts high-level meanings through grouping the data. This technique is a process of grouping a set of individuals into clusters of individuals. The rule execution model is based on event detection. The steps enumerated in Fig. 2 are elaborated as follows: – When a signal (clock, application or user) causes a primitive event to trigger and the event is detected by a rule manager, a message is sent to the rule controller component. – The corresponding condition and actions are checked against the ECA Base by the rule controller component. If there are more than two rules to be fired, the rule controller uses their priorities to decide which of the rules should be fired. The corresponding condition and action are sent to the condition evaluator and action executor components respectively. This work is done inside the rule controller component.
Composite Composite Event Event Detector Detector Clock Event Detector
Condition Condition Evaluator Evaluator
Invoked Detected
Signal Event
Association Rule
External Event Detector
Clustering
Signal Event
Action Action Executer Executer
Frequent Episode
Signal Event
Rule Controller ECA Base
ECA Execute Application Operation
Application
Fig. 2. Process of the detection of event.
– If the condition is satisfied, the action is fired by the action executor. – After the action execution, the composite event detector will be invoked to check of this event can cause any composite events to trigger. This is done by the rule controller component.
6. Conclusion The SMART-AS design was attempted to resolve the problem that exists in the alarm system of the conventional plants and to support the SAMRT MMIS (man–machine interface system design). To achieve this, we introduced advanced alarm processing methods based on a digital system, and a new display method, and an alarm control method based VDU (visual display unit). The SMART-AS was designed as an integral part of the control room design and plant operation. For optimizing the design and to meet the current licensing issues, the evaluation activities for the SMART-AS design were performed in accordance with the verification and validation and through a prototype development. So, this paper described the strategies of the SMART-AS, results of the improvements of the system’s reliability and availability by using a reliability prediction and analysis tools. Also the development of an active database coincides with the rising need for databases, which recognize certain event occurrences and act upon them automatically without a user intervention. This paper proposed a new approach to the advanced alarm processing by using event–condition–action (ECA) rules that can be automatically triggered by an active database. This paper introduced the design considerations and solution plan of the
G.-s. Jang et al. / Annals of Nuclear Energy 35 (2008) 1006–1015
ADS for the advanced alarm processing. The predicting and understanding rule behavior can be very difficult, and it can be a significant task to develop a correct set of rules for the advanced alarm processing. We will implement a computer simulation model that captures the main elements of the ADS for the advanced alarm processing. References Berndtsson, M., Hansson, J., 1995. Issues in active real-time databases. In: Proceedings of the International Workshop on Active and Real-Time Database Systems.
1015
Berndtsson, M., Hansson, J., 1995. On providing soft and hard real-time capabilities in an active DBMS. In: Proceedings of the International Workshop on Active and Real-Time Database Systems. Dayal, U., 1988. Active database management systems. In: Proceedings of the 3rd International Conference on Data and knowledge Bases, Jerusalem. Jennifer, Widom, 1996. Active Database Systems Triggers and Rules for Advanced Database Processing. Morgan Kaufmann Publishers. Lee, C.K., Hur, S., 1996. Development of a new indicator and alarm system in NPPs. ANS. Park, J.S., 2000. An Active Temporal Database Model for NPP Monitoring Systems, Doctoral Dissertation of Chungbuk University. Tan, C.W., Goh, A., 1999. Implementing ECA Rules in an active database. Knowledge-Based Systems 12, 137–144.
NUCLEAR ENERGY Annals of Nuclear Energy 35 (2008) 1006–1015 www.elsevier.com/locate/anucene
The design characteristics of an advanced alarm system for SMART Gwi-sook Jang a,*, Duk-hyun Seong b, Jong-yong Keum a, Heui-youn Park a, Young-Kuk Kim c a
I&C HFE Department, Korea Atomic Energy Research Institute, 1045, Daedokdaero, Yuseong-Gu, Daejeon 305 353, Republic of Korea b Samchang Enterprise Co., Ltd, 974-1, Goyeon-ri, Woongchon-myon, Ulju-gun, Ulsan 689 871, Republic of Korea c Department of Computer Science, Chungnam National University, Daejeon 305 764, Republic of Korea Received 27 February 2007; received in revised form 12 November 2007; accepted 12 November 2007 Available online 21 December 2007
Abstract An advanced alarm system (AAS) is primarily a digital system employing advanced alarm process logics and a VDU (visual display unit) based control and display for the alarms. The SMART-AS (system-integrated modular advanced reactor-alarm system) is an AAS. The role of SMART-AS is to provide the information necessary to safely shutdown the reactor under all plant conditions, to monitor the plant parameters approaching or exceeding the operating limits and to minimize the number of alarms, and to group and prioritize the alarms. The purpose of the alarm processing is to extract only the most important and the most relevant data out of the large amount of available information. This is achieved by using active database technologies for alarm data to form the alarms. An active database is able to monitor special situations represented by events and conditions. Hence, active database system (ADS) can recognize specific situations and react to them without direct explicit user or application requests. ADS is very useful for timely applications such as an advanced alarm processing. This paper describes the design characteristics of the SMART-AS and the results of prototyping of the SMART-AS for improving the system’s reliability and availability by using a reliability prediction. Also this paper proposes a new approach to an advanced alarm processing by using event–condition–action (ECA) rules that can be automatically triggered by an active database. Ó 2007 Elsevier Ltd. All rights reserved.
1. Introduction An AAS (advanced alarm system) of NPP (nuclear power plant) is to assist the operator to monitor the systems and processes and to take the necessary actions required to preserve the normal operating conditions. The AAS is primarily a digital alarm system employing advanced alarm process logics and a VDU (visual display unit) based control and display for the alarms. Ideally, the AAS must only present meaningful information, and must not flood the operator with miscellaneous data that he/she does not have to act upon. Also, irrelevant or unnecessary alarms have to be eliminated and the less important alarms are suppressed (Lee and Hur, 1996).
*
Corresponding author. Tel.: +82 42 868 8626; fax: +82 42 861 9618. E-mail address: [email protected] (G.-s. Jang).
0306-4549/$ - see front matter Ó 2007 Elsevier Ltd. All rights reserved. doi:10.1016/j.anucene.2007.11.009
The SMART-AS (system-integrated modular advanced reactor-alarm system) is an AAS and a computer-based information system. The need for an automated extraction of useful knowledge from huge amounts of data has become widely recognized. A database plays an important role in ensuring reliable alarms. A database for monitoring applications has the capability to store the input data from the monitors and to correlate this data to determine the action necessary. The AAS is a database driven information system. To efficiently manage data that varies rapidly over time and process event driven transactions, AAS requires database systems that support an active rule processing. Active databases are a combination of traditional static databases and active rules, meant to be automated mechanisms to maintain a data’s integrity and facilitate in providing database functionalities. Active database systems (ADSs) are able to monitor a special situation represented by an event and one or more conditions. When the
G.-s. Jang et al. / Annals of Nuclear Energy 35 (2008) 1006–1015
event occurs and the conditions are evaluated as true, the corresponding actions are executed. Hence, ADSs can recognize specific situations and react to them without direct explicit user or application requests. ADSs are very useful for timely applications such as an AAS. This would free these applications of the need to continuously monitor relevant events and as a result, the application code would be less complex, more manageable and more reliable. This paper describes the design characteristics of the SMART-AS and the results of prototyping for improving the system’s reliability and availability by using a reliability prediction. Also this paper proposes a new approach to the advanced alarm processing by using event–condition– action (ECA) rules that can be automatically triggered by an active database. And this paper describes the design considerations and solution plan for an advanced alarm processing by using active database techniques.
1007
ware) malfunctions. The malfunctions shall be indicated through the alarm display. The SMART-AS maintains a physical separation and electrical isolation of the redundant alarm systems. Independence of the data communication is as follows: – between redundant alarm systems; – between the SMART-AS and other information systems; – between the SMART-AS and the safety systems. The SMART-AS is isolated from the safety systems by using fiber optic cable to prevent an electrical fault propagation. The H/W and S/W used in SMART-AS are qualified in accordance with the H/W qualification procedure and S/W qualification procedure for the SMART MMIS. 2.2. Design strategies of SMART-AS
2. SMART-AS 2.1. Design requirements of SMART-AS The SMART-AS combines the annunciation and alarm functions in a single system. The role of SMART-AS is to provide the information necessary to safely shutdown the reactor under all plant conditions, to monitor the plant parameters approaching or exceeding the operating limits and to minimize the number of alarms, and to group and prioritize the alarms appropriately. The SMART-AS is designed according to the requirements of the control room alarm reliability of US NRC’s SECY-93-087, Item II.T. It has been reported that the alarm system for the ALWR should meet the applicable EPRI requirements for redundancy, independence, and separation. The redundant alarm systems should be provided. These redundant systems need not comply with the single failure criterion, but independence between the systems should be equivalent to that of the protection systems. The SMART-AS is based on a redundant architecture based on a dual concept. The redundant systems shall inherently minimize the consequence of a failure. The diversity shall allow for a continued plant operation with a failure in any of the information hierarchy elements. To avoid a common mode failure of the alarms, the SMART-AS uses IPS (information processing system) in the MCR (main control room) by means of a diverse mean of the alarms. And diversity is accomplished by using both the IPS and the SMART-AS implemented with different hardware and software to independently calculate and display the same validated process parameters and alarm conditions. The IPS shall independently check the alarm output of the SMART-AS and any discrepancies. The capability for the SMART-AS testing during power operation shall be provided. The hardware and software for the SMART-AS have surveillance and diagnostic test capabilities. Automatic on-line surveillance tests shall continuously check for selected system (hardware and/or soft-
Alarm functions of SMART-AS provide priority 1, priority 2, and some priority 3 alarms which use validated parameter signals based on the priority criteria of the information hierarchy for SMART. Alarm functions are presented in a manner which prioritizes them so that the operator’s response can be based on importance or urgency. Alarm functions are designed to minimize the number of alarms that occur during plant emergencies. Alarm functions of the SMART-AS encompass alarm reduction and suppression functions. Alarm functions reduce the number of alarm tiles to minimize the occurrence of information overload by using the following methods. – combining similar alarms under a single alarm tile; – combining separate channel alarms of the same parameter under a single alarm tile; – single alarm tile with a priority display; – alarm tile provides priority 1 and 2 conditions only. Alarm functions of the SMART-AS reduce the nuisance alarms by using dead band and time delay and they use the following techniques to help the operation quickly to correlate the impact of the alarm on the plant safety or performance: – alarms are arranged by system a group to achieve spatial dedication, – alarms based on plant mode, – alarms based on equipment operating status, – alarms prioritized into operational categories. SMART-AS alarms are displayed in accordance with the visual and audible code strategy of the alarm priority based on the principles of HSI (human system interface) for SMART. The SMART-AS alarms are designed to display spatially dedicated continuously visible alarms with VDU-based alarm tiles and alarm lists.
1008
G.-s. Jang et al. / Annals of Nuclear Energy 35 (2008) 1006–1015
2.3. Configuration of the SMART-AS
Table 1 Constraints of prototype of SMART-AS
SMART-AS is a part of the AIS (alarm and indication system) for SMART. Equipment of the SMART-AS consists of the alarm processor 1 and 2, the alarm test device 1 and 2, the alarm display processor 1 and 2, and alarm display device 1 and 2. Alarm equipment is connected via the safety and non safety networks (subnet A, B, C, D and subnet X, Y). The SMART-AS provides a high availability (99%) to support continuous plant operations. So, the SMART-AS shall be based on a redundant architecture. The sufficient redundancy of the SMART-AS is provided to allow hardware maintenance without taking the entire system into off-line. On line self-checks of the system health are periodically performed to allow for an early identification of the faults. SMART-AS is both flexible and expandable to adapt to the changing needs of the utility throughout the life of the plant. The SMART-AS provides extensive, reliable data communications to support the required system information exchange. Isolation is provided when a communication extends to the integrity of the transmitted data.
Item
Constraints
Requirements Selection for H/W and S/W Redundancy Communication
Apply code and standard conformance Set up selection criteria of H/W and S/W Except qualification requirements of H/W Single configuration Ethernet is temporarily used (communication under design) – Alarm reduction for partial alarms – Alarm suppression for partial alarms Ring-back alarm control based VDU Hyperbolic visualization techniques
Alarm processing Alarm control Alarm display
Table 2 The development environment information of prototype Item
H/W and S/W
Specifications
Alarm processor
Process board
– Processor: TI DSP (TMS320C40) – Memory: Local and global memory EPROM, flash memory VME Bus controller: VIC608A 7000A (ALTER)
System bus Control logic Test device
Personal computer
3. Prototype of the SMART-AS The prototype of the SMART-AS was developed to verify not only the major system functions and design requirements but the technologies which have not yet been implemented in conventional power plants. The technologies for SMART-AS are as follows: – H/W development of digital processing processor board based on VME Bus; – reliability prediction of the developed board; – improving system reliability and availability using the Relax RBD (reliability block diagram); – S/W structures for the advanced alarm processing;
DSP board S/W development
Sub rack
Standard (19”)
Alarm display
Flat panel PC
S/W development
– Pentium III 500 MHz, serial port to communication with alarm processor – 100/10-Base T –Cross development environment –TMS320C40 Assembler, C Compiler, linker – PC based DSP board emulation S/W: board support library, download DSP program, test of DSP board –VME bus backplane – 3U single height -Pentium III 500 MHz, 51 2KB Cache, 384 MB memory, 100/10Base T –TFT Color, 64 K color –Touch type: analog resistive Using QNX 4 OS and Photon MicroGUI
3.1. Hardware development Table 1 shows the constraints for the prototype of the SMART-AS. The development environment information of the hardware and software for the prototype is as in Table 2. Fig. 1 shows the board block diagram for the alarm processor board. 3.2. Reliability prediction The SMART-AS shall be designed for an operational availability goal of 99%. The MTBF (mean time between failure) of the SMART-AS is more than 10,000 h. Equipment that are easily accessible are assumed to be repaired within a short time period after the failure is detected. The MTBF should be confirmed by a reliability analysis based on the failure rate of the components.
3.2.1. Reliability prediction and analysis tool (Relax) A primary requirement for reliability analysis is the knowledge of the failure rate, or the number of failures expected during a certain period of time. Calculation of the equipment failure rate, and the related MTBF of the prototype, is the basis of the Relax reliability prediction software. Relax performs the reliability predictions and analyses on the electrical, electronic, mechanical, and electro-mechanical equipment. The Relax reliability prediction software is available based on various standards, including Telcordia (Bellcire), MIL-HDBK-217, CNET 93 and HRD5. 3.2.2. Prediction of the reliability Electronic systems involve the utilization of very large numbers of devices which are very similar. It is difficult
G.-s. Jang et al. / Annals of Nuclear Energy 35 (2008) 1006–1015
Interface
VME Control Signal
Control Logic (FPGA)
VMEbus Controller
VME Address Bus VME Data Bus
Address Data
Control Signal
B U F F E R
Global Address Bus Global Data Bus
JTAG Interface
Processor (TMS320C40) EPROM EPROM
Local Memory (SRAM)
Global Memory (SRAM)
B U F F E R
Backboard Connector
ISP
Reset Clock
Local Address Bus
Local Data Bus
Flash Memory Memory
Fig. 1. Board block diagram for alarm processor board.
to test for the electronic component defects that do not immediately affect the performance. Very close attention must be paid to the electronics part reliability. A reliability prediction is the analysis of the parts and components in an effort to predict the rate at which an assembly or system will fail. The basis of the analysis is generally a reliability prediction model. Reliability prediction models offer standard equations to calculate the failure rate of the components based on the component data and parameters. These parameters include the environment, temperature, quality and stress. When individual failure rates for the components are established, a simple summation of the component failure rates provides the failure rate for the higher level assemblies and systems. 3.2.3. MIL-HDBK-217 prediction method MIL-HDBK-217 was an original standard for the reliability predictions. It was designed to provide reliability math models for nearly every conceivable type of electronic device. It is used by both commercial companies and the defense industry, and is accepted and known worldwide. MIL-HDBK-217 includes the ability to perform a parts count analysis or a part stress analysis. A parts count analysis is not as detailed as a part stress analysis, and is normally used early in a design when detailed information is not available, or a rough estimate of the failure rate is all that is required. A part stress analysis takes into account more detailed information regarding the components, therefore, offers a more accurate estimate of the failure rate. The parts stress analysis method requires a significant amount of design detail. Many of the details were not available in the early design stages of the SMART-AS.
1009
3.2.4. Parts count reliability method The parts count reliability method can be used in the early design stage when detailed data is not available. The parts count reliability method is used for the generic part type, for the quality factor and the environmental factor. And the following information is required; generic part types (including complexity for microcircuits) and quantities, part quality levels, and the equipment environment. Equation of the parts count method is as follows: kEQUIP ¼
i¼n X
N i ðkg pQ Þi
i¼1
where, kEQUIP is the total requirement failure (failures/ 106 h); kg is the generic failure rate for ith generic part (failures/106 h); pQ is the quality factor for the ith generic part; Ni is the quantity of the ith generic part; n is the number of different generic part categories in the equipment. The prototype of the SMART-AS selected the parts count reliability method for its improvement by showing the highest contributors to a failure. The total equipment failure rate of the alarm processor board is 0.8205. The need for a redundant or back-up system may be determined with the aid of reliability predictions. Also the maintenance strategy can make use of the relative probability of a failure’s location based on the predictions, to minimize the downtime. Reliability predictions are also used to evaluate the probabilities of the failure events described in the failure modes, effects and criticality analysis. 3.3. Improving system reliability and availability using the relax RBD There are several techniques we can employ to improve the reliability, and/or availability of the SMART-AS design. Three common techniques that might be used are the parallel redundancy, standby redundancy, and spares. By using Relax’s reliability block diagram (RBD) tool, the effects of these methods can be investigated when determining if any of these techniques should be used before any design changes. Since one of the main purposes of the RBD is to calculate the reliability and availability of a system based on the redundancies, it is useful to only analyze the SMART-AS at the level that includes redundancies. A reliability prediction model assumed that the configuration of the system was a simple one. As a system configuration becomes more complex, more complex calculation methods are required to calculate values like the failure rate, MTBF, reliability, and availability. The Relax RBD was used to calculate complex redundant systems that cannot be computed by using the Relax Reliability Prediction portion of the program alone. Table 3 shows the failure rate of a component of an alarm processor board for the prototype. Table 4 shows the various parameters and variables chosen for the analysis, as well as the availability, reliability and failure rate at specific time intervals. Standby redundancy is more
1010
G.-s. Jang et al. / Annals of Nuclear Energy 35 (2008) 1006–1015
Table 3 Failure rate of component of a alarm processor board for prototype (N: count, FR: failure rate, CFR: combination of FR)
deviation comparison is secluded from the valid parameter calculation.
Part number
Function
FR
N
CFR
TMS320C40FL60 (TMS320C40) VIC068A-NC (VIC068A)
DSP processor
0.01528
1
0.015281
VME interface controller Flash memory EEPROM SRAM
0.00312
1
0.003120
0.52425 0.00571 0.00571
1 1 4
0.52425 0.005715 0.22860
FPGA
0.659031
1
0.659031
3.4.3. APX_Alarm_Create_Process Upon the detection of alarm conditions, the module processes the alarm processing algorithm based on the validated variables to reduce the nuisance alarms efficiently and to allow the operator to the best focus of his attentions. The applicable alarm logics are the plant operating mode dependency alarm with different setpoints, the equipment status dependency alarm, the deadband and the time delay.
AM29F080B-90EC 27C256-15 (27C256) K6R4016V1C-TC12 (K6R4016VIV-C) EMP7128STC100-15 (EPM7128EQI100-20)
Table 4 Result of reliability analysis Hour
0 20000 40000 60000 80000 100000 120000 140000 160000 180000 200000
Reliability
Failure rate
Availability
Parallel
Standby
Parallel
Standby
Parallel
Standby
1.00000 0.993435 0.975826 0.949867 0.917754 0.881270 0.841854 0.800658 0.758600 0.716402 0.674628
1.000000 0.995849 0.985806 0.970853 0.951851 0.929556 0.904625 0.877631 0.849074 0.819382 0.788928
0.000000 0.633273 1.136928 1.545742 1.883097 2.165296 2.404056 2.608012 2.783674 2.936038 3.069005
0.042247 0.365093 0.641669 0.881257 1.090811 1.275647 1.439893 1.586809 1.719000 1.838575 1.947256
1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 0.999000
1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000
effective than the parallel redundancy because the unit/ junctions are not always operating. The results of the standby redundancy show its suitability for the MTBF and the availability and reliability requirements of the SMART-AS through the use of the prototype. 3.4. Software structure The S/W of the prototype was developed with a topdown structure design approach using TeamWork (CASE tool). The S/W deign used a hierarchical design structure and principles of the modular design with coherence and cohesive modules to reduce the complexity of the verification and validation. High level language was mainly used and assembly language was used only where sufficient performance cannot be achieved through use of a high level language or where it is justified based on the requirements. 3.4.1. APX_Input_Data_Prcoess This module periodically collects the digitized data of an analog and contact type through a safety and non-safety network. 3.4.2. APX_Representative_Value This module executes the logic to determine a single value that can be representative of a given parameter which is being sensed by multiple sensors. As a part of the validation algorithm, any sensor(s) which fails a cross channel
3.4.4. APX_Alarm Suppression_Process Irrelevant or unnecessary alarms are eliminated and less important alarms are suppressed. The applicable alarm suppression logics are cause–consequence processing and multisetpoint relationships. And First-out processing is provided to support the operators in determining the initiating cause of a reactor or trubine trip in the alarm system. By suppressing the minor alarms for a period of time after a reactor trip, the operator’s attention would be directed towards the major problem when multiple alarms are present. 3.4.5. APX_Alarm_Order_Process Alarms are prioritized by their importance to plant safety and its operation. The model indicates the relative importance of the alarms based on a predefined set of conditions and relieves the operator of this time-consuming task when a major event is taking place. The alarm prioritization scheme depends on the alarm categorization strategy based on the information hierarchy for the MMIS. 3.4.6. APX_Management_Process This module is provided to allow for the modification to the existing software and to minimize the mean-time-torepair by generating meaningful error messages. The module recognizes a power failure and is capable of an automatic restart upon the power restoration. The cold start software module is executed when initially energizing the prototype hardware. The warm restart module attempts the continuation of the program without the hardware initialization. 3.4.7. APX_Fail_Over_State_Monitoring_Process Not implemented. 3.5. The advanced alarm processing based on the active database technologies The purpose of the alarm processing is to extract only the most important and the most relevant data out of the large amount of available information. This is achieved by using active database technologies for alarm data to form the alarms. An active database is able to monitor special situations represented by events and conditions. Active rules, which originate from production rules in expert systems, represent knowledge through event–condition–
G.-s. Jang et al. / Annals of Nuclear Energy 35 (2008) 1006–1015 Table 5 General form of an ECA rule On Event if Condition do Action The Event of an ECA rule determines when the rule should be evaluated The Condition of an ECA rule determines whether the action should be executed The Action of an ECA rule determines how to react if the condition is evaluated as true
actions (ECA) rules. Knowledge can be stored as event– condition–action (ECA) rules. Active database technology can, therefore, enable a system to have a reactive processing and autonomous response to an event that occurs inside or outside the system. The general form of an ECA rule is illustrated in Table 5 (Tan and Goh, 1999). Many applications, including classical ones like an inventory control, would run much more efficiently. This would free the applications of the need to continuously monitor relevant events and as result, the application code would be less complex, more manageable and reliable. In developing an active database system it is necessary to consider a number of issues (Jennifer, 1996): – An active database system must provide all the usual functionality of a conventional passive database system. Meanwhile, it is deseirable that the performance of conventional database tasks is not degraded by the fact that the database system is active. – Ac active database system must provide some mechanism for users and applications to specify the desired active behavior, and these specifications must become a persistent part of the database. – An active database system must efficiently implement any active behavior that can be specified; it must monitor the behavior of the database system and, when appropriate, automatically initiate additional behavior. – An active database system must provide database design and debugging tools similar to those provided by conventional database systems, extended to incorporate active behavior. 4. Design considerations of the active database system for the advanced alarm processing This section describes the design considerations of the ADS (active database system) for the advanced alarm processing, and it also describes the solution plan against each consideration. 4.1. Rule management The ADS for the advanced alarm processing includes a component for managing the set of rules in the system. The Rule Manger is used to implement the active concepts. In the Rule Manager, ECA rules are grouped in a class-hier-
1011
archy of alarm tiles and can be inserted, deleted and modified. Once rules are defined, they must become a persistent part of the database system, which is usually achieved by storing rules in the database itself. 4.2. Active database rules 4.2.1. Events for the advanced alarm processing The ADS is centered on the notion of rules. Rules in the ADS are defined by users, applications, or database administrators; they specify the desired active behavior. In an active database rule for the advanced alarm processing, the event specifies what causes the rule to be triggered. Useful triggering primitive events for an the advanced alarm processing are: – Time A temporal event might specify that a rule should be triggered at an absolute time (e.g., 1 Jan 2006 at 12:00), at a repeated time (e.g., every day at 12:00), or at periodic intervals (e.g., every 10 min). – Application-defined Application-defined events might be specified by allowing for an application to declare a name E as denoting an event (e.g., high-temperature) and allowing for an active database rule to specify E as its triggering event. Then, each time an application notifies the database system of the occurrence of event E, and the rules specifying E as its event is triggered. Using this approach, the application may perform any monitoring or computations it desires (with or without accessing the database) to detect when event E should occur, i.e., to detect when the rules associated with E should be triggered. 4.2.2. Conditions for the advanced alarm processing The condition part of a rule is usually a Boolean expression, a predicate, or a set of queries, and it is satisfied if the expression evaluates to true, or all the queries return nonempty results, respectively. In the ADS for the advanced alarm processing, values related to the condition can be passed to the action. And the ADS allow the condition part of a rule to be omitted, in which case the condition is always true. Like action execution, evaluating the conditions of triggered rules can involve executing large operations on the database, but in some cases these operations may be reduced or avoided. Two methods for reducing the overhead in rule condition evaluation are discrimination networks and incremental evaluation (Jennifer, 1996). In the ADS for the advanced alarm processing, rule conditions may be evaluated multiple times, and incremental evaluation techniques can be useful in optimizing the condition evaluation phase of rule processing. 4.2.3. Actions for the advanced alarm processing The action part of a rule is executed when the condition is satisfied. In general, an action can be database operations,
1012
G.-s. Jang et al. / Annals of Nuclear Energy 35 (2008) 1006–1015
transaction commands (e.g., abort transaction), or arbitrary executable routines. The action may access, besides the current database state, the database state at the time of event occurrence and the time of condition evaluation which can be accomplished by parameter passing. In the ADS for the advanced alarm processing, the action language includes a mechanism for referencing the values bound to the event’s parameters. And the ADS allows a rule to specify a set of actions, usually with an ordering so that the multiple actions are executed sequentially. 4.3. Rule define language There is a notable difference between AI rule languages and most active database rule languages. In active database rule language, usually it is sufficient to find one rule whose condition is true. One reason for this semantics is that in active database systems rule activation is usually based on triggering events rather than on true conditions; a second reason is to avoid the overhead involved in evaluating numerous, potentially expensive conditions. The desired behavior of the ADS is specified by using an active database rule language. Clearly, what can be specified in the rule language has a direct impact on the power and on the complexity of the ADS. The desired behavior of an active database system is specified by using an active database rule language. The SQL3 standard extends the assertion capabilities of SQL92, and it includes a relatively comprehensive trigger language. Triggers in SQL3 provide options for the time of a triggering (BEFORE, AFTER, or INSTEAD OF the triggering option), the granularity of a triggering (tuple-level or statement-level), and for a prioritization (ordering) of multiple triggers during the same operation. A number of commercial products already support relatively powerful active database (trigger) capabilities. The rule define language for the advanced alarm processing is based on SQL3 (ANSI99) and TSQL2 Temporal Query Language (Park, 2000). 4.4. Rule execution semantics While the rule language prescribes what can be specified in each active database rule, the rule execution semantics prescribes how the active database system behaves once a set of rules has been defined. Rule processing algorithm repeatedly finds a triggered rule, evaluates the rule’s condition, and, if the condition is true, executes the rule’s action. The algorithm for a rule processing is iterative. 4.4.1. Rule processing granularity The granularity of a rule processing specifies how often the points occur at which rules may be processed. The finest granularity is ‘‘always”-rules may be processed at any point during the database system’s execution, as soon as any rule’s triggering event occurs. In the finest granularity for the advanced alarm processing, rules may be processed after each occurrence of the ‘‘smallest” database operation.
In some database systems, data manipulation statement provides a granularity for a rule processing that is coarser than database operations. In ADS for the advanced alarm processing, the points at which rules maybe processed are delineated by the applications, although these systems usually provide a default granularity as well. 4.4.2. Coupling mode The most straightforward approach is for the triggered rule’s condition to be evaluated and its action execution within the same transaction and the triggering event at the soonest rule processing point. However, for some applications it may be useful to delay the evaluation of a triggered rule’s condition or the execution of its action until the end of the transaction; or, it may be useful to evaluate a triggered rule’s condition or execute its action in a separate transaction. These possibilities yield the notion of coupling modes. Coupled modes determine the execution of rules with respect to the transaction which triggers them. The event–condition (EC) and condition–action (CA) coupling modes, respectively, determine when the rule’s condition is evaluated with respect to the triggering event, and when the rule’s action is executed with respect to the condition evaluation. Three basic coupling modes are introduced; immediate, deferred, and decoupled. It has been pointed out by several researchers (Berndtsson and Hansson, 1995a,b) that immediate and deferred coupled modes have several negative properties to be supported in realtime databases. The ADS for AAS is soft real-time database system. Hence in ADS for the advanced alarm processing, we only consider the detached coupling mode, which does not impose additional unpredictable execution time to the triggering transaction. 4.4.3. Termination In almost all rule processing algorithms, regardless of whether the algorithm is iterative or recursive, sequential or concurrent, there is a danger of a nontermination. There is a fixed upper limit- perhaps established as a system parameter-on how many rules can be executed during rule processing. If the limit is reached, rule processing terminates abnormally. 4.5. Composite event support 4.5.1. Concepts of composite event The active functionality of the ADS is measured by the ability of the database to monitor various forms of primitive events. On the other hand, the expressive power of the database can be augmented by the ability to detect composite events, which can be made up of different combinations of primitive events. Composite events are made up of combinations of primitive or other composite events. The meaningful ways to build composite events from its constituent events are usually specified through an event algebra that defines certain event constructors (Dayal, 1988). There are six different kinds of event constructors that can be
G.-s. Jang et al. / Annals of Nuclear Energy 35 (2008) 1006–1015
used to construct composite events. These constructors are: disjunction, conjunction, sequence, history, negation and closure (Tan and Goh, 1999). (1) Disjunction (E1_E2) When either E1 or E2 occurs (2) Conjunction (E1^E2) When both E1 and E2 occur, regardless of the order (3) Sequence (E1, E2) When E1 occurs first followed by E2 (4) History When an event E occurs a specified n times, within a specified time interval I (5) Negation (:E) When E does not occur during a specified time interval I (6) Closure Whenever E occurs at least once during a specific time interval
4.5.2. Adapting composite event for advanced alarm processing Alarm processing techniques were developed to support operators in coping with the volume of alarms, to identify which are significant, and to reduce the need for operators to infer plant conditions. This section describes the test case used to demonstrate the advanced alarm processing by using the concepts of composite events. (1) Equipment-state dependency The alarms activated as a consequence of an equipment-state change (e.g., pump tripped) are lowered in priority (see Table 6). (2) Plant-mode dependency The alarms activated as a consequence of a plantmode change (e.g., reactor trip, safety injection, or cold shutdown) are lowered in priority (see Table 7). (3) Multi-setpoint relationship The lower level alarms are reduced in priority when the higher level alarms also are activated (see Table 8). (4) Cause–consequence relationship A fault occurring in a certain part of the plant process propagates through the process following a cause– consequential relationship. As a result of the fault
Table 6 Events defined for an equipment-state dependency Event of Interest
What triggers the event
Action to be taken
E1 E2 C1
Plant trip Low flow E1 and E2
Trigger C1 Trigger C1 Low flow alarm is lowered in priority
1013
Table 7 Events defined for a plant-mode dependency Event of interest
What triggers the event
Action to be taken
E1 E2 C1
Pump trip Low flow E1 and E2
Trigger C1 Trigger C1 Low flow alarm is lowered in priority
Table 8 Events defined for a multi-setpoint relationship Event of interest
What triggers the event
Action to be taken
E1 E2 C1
PZR pressure Hi PZR press Hi–Hi E2, followed by E1 (sequence)
Trigger C1 Trigger C1 Low alarm is reduced
Table 9 Events defined for a cause–consequence relationship Event of interest
What triggers the event
Action to be taken
E1
MFW pump trigger C1, Low suction flow Heater drain tank, low level E2, followed by E1 (sequence)
Trigger C1
E2 C1
Trigger C1 Consequence alarm is suppressed
propagation, an alarm occurring in a part of the process may cause another alarm in another part to be activated (see Table 9).
5. Process of the detection of event for alarm processing The ADS for the AAS should support primitive and composite events and response times for event detection, both primitive events and composite, are crucial for the performance of the ADS. We are developing a framework for applying data mining techniques to alarm processing. This framework consists of programs for establishing a classifier, association rules, frequent episodes and a clustering. Each mining system received the alarm data from a database and established useful rules. Association rule miner can find a correlation among the attributes in a record, although a frequent episode miner searches for event patterns in the records. In addition, a clustering analysis provides a data abstraction from the underlying structure. And it groups data objects into clusters such that the objects which belong to the same cluster are similar, while those belonging to a different cluster are dissimilar. Because we consider the characteristics of the alarm data, we improved the existing data mining algorithms to create candidate item sets that include only the interesting attributes. It is very important to point out that our framework does not eliminate the need to pre-process and analyze raw audit data. In fact, to build alarm processing
1014
G.-s. Jang et al. / Annals of Nuclear Energy 35 (2008) 1006–1015
models, our data mining programs use (pre-processed) alarm data where each record corresponds to a high level event. Each record normally includes an intensive set of features that describe the characteristics of the event. The rule controller consists of programs for establishing association rules, frequent episodes and a clustering. Association rule miner can find a correlation among the attributes in a record. The frequent episodes miner is used to search for a series of event sequences for frequently occurring episodes. An episode is defined by a sequence of specific events that occurs frequently, and events composing a sequence are closely related with one another. Here, exploring is done to find all the frequent episodes in a set of time windows of a user-defined size. A sequence pattern and an episode are similar in that they explore patterns in sequence. However, they are different in that an episode explores while using windows. Using episodes, SMART-AS can automatically detect frequently repeated patterns, and apply them to the rule or use them as guidelines for alarms. When the existing algorithms are used in applying data mining to search for useful patterns from the alarm data, correlations among the attributes must be considered. Alarm data comprises of various attributes, and each of these attributes has many values. Because all this data cannot be converted into a binary database, we propose an expanded algorithm using a row vector. Row vector is a data structure used in the search for frequent items, which contain bit recording transactions that include item sets. Using a row vector has the advantage of having to consider only the correlations among the tuples rather than the co-relationships among the attributes. In addition, as standard attributes are applied, only items including the standard attributes have to be considered in generating the candidate items. This reduces the number of unnecessary episodes in generating the rules. Clustering analysis is a technique to find the distribution or patterns of given data by classifying the data into groups based on a similarity. Such a clustering analysis technique improves the efficiency of the analysis of the alarm data, and abstracts high-level meanings through grouping the data. This technique is a process of grouping a set of individuals into clusters of individuals. The rule execution model is based on event detection. The steps enumerated in Fig. 2 are elaborated as follows: – When a signal (clock, application or user) causes a primitive event to trigger and the event is detected by a rule manager, a message is sent to the rule controller component. – The corresponding condition and actions are checked against the ECA Base by the rule controller component. If there are more than two rules to be fired, the rule controller uses their priorities to decide which of the rules should be fired. The corresponding condition and action are sent to the condition evaluator and action executor components respectively. This work is done inside the rule controller component.
Composite Composite Event Event Detector Detector Clock Event Detector
Condition Condition Evaluator Evaluator
Invoked Detected
Signal Event
Association Rule
External Event Detector
Clustering
Signal Event
Action Action Executer Executer
Frequent Episode
Signal Event
Rule Controller ECA Base
ECA Execute Application Operation
Application
Fig. 2. Process of the detection of event.
– If the condition is satisfied, the action is fired by the action executor. – After the action execution, the composite event detector will be invoked to check of this event can cause any composite events to trigger. This is done by the rule controller component.
6. Conclusion The SMART-AS design was attempted to resolve the problem that exists in the alarm system of the conventional plants and to support the SAMRT MMIS (man–machine interface system design). To achieve this, we introduced advanced alarm processing methods based on a digital system, and a new display method, and an alarm control method based VDU (visual display unit). The SMART-AS was designed as an integral part of the control room design and plant operation. For optimizing the design and to meet the current licensing issues, the evaluation activities for the SMART-AS design were performed in accordance with the verification and validation and through a prototype development. So, this paper described the strategies of the SMART-AS, results of the improvements of the system’s reliability and availability by using a reliability prediction and analysis tools. Also the development of an active database coincides with the rising need for databases, which recognize certain event occurrences and act upon them automatically without a user intervention. This paper proposed a new approach to the advanced alarm processing by using event–condition–action (ECA) rules that can be automatically triggered by an active database. This paper introduced the design considerations and solution plan of the
G.-s. Jang et al. / Annals of Nuclear Energy 35 (2008) 1006–1015
ADS for the advanced alarm processing. The predicting and understanding rule behavior can be very difficult, and it can be a significant task to develop a correct set of rules for the advanced alarm processing. We will implement a computer simulation model that captures the main elements of the ADS for the advanced alarm processing. References Berndtsson, M., Hansson, J., 1995. Issues in active real-time databases. In: Proceedings of the International Workshop on Active and Real-Time Database Systems.
1015
Berndtsson, M., Hansson, J., 1995. On providing soft and hard real-time capabilities in an active DBMS. In: Proceedings of the International Workshop on Active and Real-Time Database Systems. Dayal, U., 1988. Active database management systems. In: Proceedings of the 3rd International Conference on Data and knowledge Bases, Jerusalem. Jennifer, Widom, 1996. Active Database Systems Triggers and Rules for Advanced Database Processing. Morgan Kaufmann Publishers. Lee, C.K., Hur, S., 1996. Development of a new indicator and alarm system in NPPs. ANS. Park, J.S., 2000. An Active Temporal Database Model for NPP Monitoring Systems, Doctoral Dissertation of Chungbuk University. Tan, C.W., Goh, A., 1999. Implementing ECA Rules in an active database. Knowledge-Based Systems 12, 137–144.