- Email: [email protected]
Coast - Computerised Alarm System Toolbox
COAST - COMPUTERISED ALARM SYSTEM TOOLBOX A.BYE, S. NILSEN, F. HANDELSBY and T. WINSNES InstltutT for energlteknlkk, OEeD Halden Reactor Project, Po. Box 173, N-1751 Halden , Nom 'ay
Abstract. The OECD Halden Reactor Project has for several years been working with computer-based systems for determin ation of plant status including alarm filtering, earl y fault detecti on. and fun ction-oriented plant surveillan ce. The methods explored complement each other in different plant operating regime s and provide di versit y in plant monitoring systems. A new toolbox, COAST, has been made to enable integration of these different methods int o an alarm system. Coast will be easy to couple to different processes. It will be an integral part of the final alarm syste m and not only act as a tool for building dedicated systems. Key words. Alarm systems; failure detection; guidance systems ; man -machine systems ; on-line operati on; operator suppon; so ftware tools
1.
INTRODUCTION
In case of major disturbances in a plant with a large number of alarms issued, a function-oriented approach is in many cases recommended . Instead of looking at single systems or variables and alarms within a system, one monitors critical safety functions in terms of whether these functions are challenged. The Halden Project has explored this concept through several systems, like CFMS (Critical Function Monitoring System) and SPMS (Success Path Monitoring System), and the post trip guidance system SAS-IT (0wre et al., 1991).
One of the main tasks for operators in nuclear power plants is to identify the statu s of the process when unexpected or unplanned situations occur. The alarm system is the main infOlmation source to detect disturbances in the process, and alarm handling has received much attention after the Three Mile Island accident in 1979 (Kemeny , 1979). It was realized that conventional alarm systems created cognitive overload for the operators during heavy transients . The Halden Project developed an alarm filtering system called HALO (Handling Alarms using LOgic) using logic filtering to reduce the number of active alarms during process transients (0wre and Marshall , 1986). HALO has been subject to a number of validation experiments with different presentation techniques, as described by Marshall et al. (1987) .
Effectively handling and integrating different types of alarms into one system would improve the operator' s overview and thereby the overall safety of any industrial plant. This was a major motivation for initiating the development of the COmputerised Alarm System Toolbox, COAST. The experience gained from the work with various alarm systems was utilised when designing the basic functionality of Coast. It should thus be possible to utilize Coast to make most kinds of alarm systems. The goal is to reach solutions that can minimize the cognitive overload of the operating crew , but still fulfil the basic philosophy of alerting, informing and guiding the operator, as well as confirming whether his/her actions have the desired result.
Another approach is taken in the EFD (Early Fault Detection) system. The method used is to run small, decoupled models which calculate the state of the process assuming no faults , in parallel with the process. The behaviour of these models is then compared with the behaviour of the real process , and if there is a deviation, an alarm is issued. In this way false alarms are avoided , and one will only get one alarm for one fault. Prototypes developed for simulators and installations in real power plants e.g. the Imatran Voima owned plant in Loviisa, Finland, have demonstrated the feasibility of this methodology, provided that enough measurements are available for the process area considered (S0renssen , 1990).
An alarm system tool box which can be used on different processes, applying different alarm handling methods, has to be generic. The tool box must be easy to use to tailor-make alarm systems for many different processes, e.g . nuclear power plants or oil production platforms, and it must possess a flexible
159
development environment, to improve and simplify the task of the alarm system designer.
2.
internal leakages may be inferred by the alarm system. Let us illustrate this by considering the simple example given in Fig. I.
FUNCTIONALITY OF COAST
2.1 Integration of Alarms Level One aim is to combine the functionalities of the different alarm systems explored by the Halden Project into one integrated alarm system. This can be done in several ways, where the most generic way is to make a general software-package which is capable of making all types of alarms. Equally important is to facilitate the handling of these different alarms by making relations among them. The objective with Coast as such is to make the integration of different types of alarms possible. Coast will include the different functions needed, and it will be generic, such that it will be possible to use it to implement alarm systems for many different processes and plants. In an integrated alarm system, the alarm processing may be divided into three stages : alarm generation, alarm structuring and alarm presentation. Alarm generation is the phase where all new alarms are generated from process measurements. All types of alarms should be generated by this "module", conventional alarms, function-oriented alarms, as well as modelbased alarms . The advantage of having different types of alarms available when the operator investigates the status of the plant, is the diversity in the underlying methods, which contributes to a broader view and possibly a more robust conclusion . Model based alarms may be more sensitive than conventional alarms, and useful in dynamic situations , while function-oriented alarms are most useful in severe transients.
Pipe-C Valve-D
fooIIl-_SU_P_P_Orl_--l Flow-in- Pi pe- B
Valve-O-cJosed
event: Leak-in-Pipe-C
Fig. I Event / alarm network for hypothesis related alarms. In this network the shaded box represents a non-observable event, and the others represent alarms or observable status events.
The arrows without the crossing line are relations which indicate explanatory alarms or events , for example jlow-in-pipe-B combined with valve-Dclosed may explain the alarm high-level-heater-A. The arrow with the crossing line indicates the opposite, i.e. that a low-level-heater-A alarm probably not supports the event leak-in-pipe-C. For the alarm high-level-heater-A in the example in Fig. 1, lists of explanatory alarms and events are specified :
However, if only more information is presented to the operator, based on more information sources, the danger of cognitive overload may increase. In the alarm structuring phase one tries to cope with this problem. Structuring includes what normally is known as filtering of conventional alarms, and will thereby reduce the amount of information automatically presented to the operator, in this way clarifying the disturbance situation .
high-Ievel-heater-A: Explanatory alarms and observable events: flow-in-pipe-B, valve-D-closed Explanatory non-observable event: leak-in-pipe-C
F1ow-in-pipe-B combined with valve-D-closed may then explain why the alarm high-level-heater-A has appeared. Leak-in-pipe-C refers to a non-observable condition. This hypothesis could be the diagnosis if no other alarms or observable events are present.
It will be possible to couple Coast to an existing alarm system. Existing alarms will then be structured or filtered by Coast before presentation.
The main idea is that when the operator is searching for a solution to a problem he can make a hypothesis . This can either be an alarm which has not yet occurred, or a non-observable event. The a priori established relationships between the alarms can be used to confirm or disconfirm this hypothesis. The
2.2 Flexibility The results of advanced alarm structuring may support the operator with different types of alarm lists, which he can use interactively in his status identification task. Further, non-observable events such as
160
hypothesis must be present either as an alann not yet observed. or as a non-observable event. Alann lists can be generated and presented for the operator when he proposes a hypothesis:
grammer's interface (AP}) provides easy coupling of external systems to Coast. A library of API-function~ must be. included in the application. and all exchange of data IS done through these function s.
Hypothesis: leak-in-pipe-C:
Coast Language. The alann system designer defines the specific alann system by writing definitions according to the specific syntax provided by the COast LAnguage (COLA) . This can be done in two ways : Writing the Cola definitions in text-files. which are fed into the kernel. or by using a graphic . syntax sensitive editor. Pure text-files will be useful in cases where parts of the definitions are already prepared and stored. It may then be read into the kernel with minor modifications to fit the Coast language.
Supporting alarms: 12:03: 15 Low-flow-in-pipe-C Opposing alarms: 11 :45:20 Low-Ievel-heater-A Not yet observed alarms: ??:??:?? Low-temperature-in-heater-A
The presence of both confinning and disconfinning alanns cannot be excluded. because the relations are only normative. For instance if both low-jlow-inpipe-C and low-level-h eater-A have occurred . the operator may ask himself whether really leak-inpipe-C is true .
0-0 Design. Coast offers an object-oriented way to construct alann systems for the alann system designer. Object-oriented design includes classes with attributes. instances of the classes. methods and relations . The attributes may have dynamic behaviour. which may be given default on class level. or overridden by specific behaviour on instance level. Typical attributes of an alann object may be the type and the priority of the alann . Typical methods may be the updating of status etc. The alarm objects may be related to other alarm objects through relations . The relations are also defined by the alarm system designer, and may be considered as active or nonactive pointers between the objects. A set of basic alann classes can be collected in a library.
In this very simple example. it is straightforward to keep the overview of the relations . But in a realistic situation . the number of relationships and active alarms will be too many to handle for the operator. The system aims to offer the operator help in selecting those alanns which seem to confinn or disconfirm his hypothesis. In this situation the operator will use the alarmlevent network interactively on-line. by interrogating the system with respect to some particular hypothesis . This network could even be subjected to a systematic search to find those hypotheses which are most supported by the active set of alanns .
Allowed constructs in Cola comprise arithmetic , conditional and logic expressions, including "for every", and other first order logic. The actions of methods includes very powerful selections, and in addition time dependen!constructs are available for filterin oo · The definitions of these dynamic elements thus describe the dynamic alann system.
Coast offers a number of facilities to handle the above example. Alarm objects and relations between the alarm objects are the basic building blocks in the tool box . This facilitates a flexible structuring of alarms. which may be used both for conventional filtering. and for the more general structuring purposes as shown in the example above. It will be possible for the alann system designer to make different dynamic relations between alanns. Together with very strong on-line selection capabilities. different lists can be made available to the operator. which he can use in his diagnostic reasoning task. This provides a best possible tool for the operator to search for and test different hypotheses .
The first task of the alann system designer is to define alann classes with attributes and methods, and relations. A very simple example of a class definition and a relation definition with the Coast language is shown below: Classdef StatHiAlarm Attr Priority: string Attr HiAlarmStatus : string Attr System: string Attr Time: int Attr Meas : real with history Attr HiAlarmLimit : real Method whenever Meas > HiAlarmLimit assign "on" to HiAlarmStatus assign clock to Time EndMethod EndClassDef
2.3 Use of COAST Configuration. The alann system designer will use the toolbox to make a specific alann system. It is possible to operate Coast without active external connections. so classes etc. can be defined before the tool box is coupled to any external system. However. one may also run with all external systems connected . The designer has to configure the alann system and decide which external systems that are going to be connected to the toolbox . An application pro-
RelationTypeOef x : StatHiAlarm member-of Group1 if x.HiAlarmStatus == "on"
161
The attributes , relations and methods are the dynamic elements of Coast. In the example above the attribute HiAlarmStatus gets a new value whenever the condition in the method is true . Another way to write this
File
Edit
Utilities •.•
Help
IS:
Attr HiAlarmStatus:string = if (Meas > HiAlarmLimit) then "on" else "off" Coast is an event-driven program, and updates all necessary values whenever something happens , e.g. when process measurements are fed into the kernel. In the above example ':=' means "is always the same as". Coast does not execute as a sequential program. The updating of necessary attributes etc. is done by a kind of forward chaining. Consistency of values is ensured automatically. such that no cycles are present in the definitions. Also no value is updated more than once , and this ensures the best possible efficiency, which is highly needed , as the Coast language itself offers flexible and computational heavy constructs. The evaluation in the kernel is however fully deterministic. which is required from a system which shall be used to make alarm systems.
Priority := " Severe " System := " RL10" HIAlarmLimit := 3.0
Fig. 2 Example of instantiation of an alarm class. and coupling between alarm objects , via relations. The alarm class StatAl4 is selected from a library, instantiated, and given the id RLl OLOO I. information , and selectable displays , which the operator can use interactively in his investigation task.
The graphic MMI equivalent of the above example will be to activate a C1assDef window , click on new .. in an attribute popup window , and write the names of the attributes.
Coast offers a very strong functionality to enhance the operator' s diagnostic task. The operator may want to look at dynamic alarm lists of various types interactively. The selective constructs comprise a subset of Cola (Cola light), which is made available for the end user. Cola light is interpreted , so it is possible to write in new selection criteria for new , dynamic alarm lists on-line. This feature will only offer the possibility to search among existing alarm objects , it will not produce new objects in the kernel, i.e., it is a reading, not a writing facility.
After having defined alarm classes , the next step for the designer is to instantiate alarm objects from the classe s. Initial values and expressions may be given for attributes which are not going to keep the default beha\'iour given on class level. Using text-definitions according to the allowed syntax, it may look like: ObjectDef RL 1OL001 : StatHiAlarm Priority := "Severe" System := "RL 1 0" HiAlarmLimit = Basic.HiAlarmLimil EndObjectDef
In practical use the operator will thus be in an X-windows environment, clicking on icons, or he may even write in new selection criteria on-line, to get up different alarm lists. This enables himlher to find out as much as possible about the current alarm situation and the state of the plant. It is however important to emphasize that Coast also can be used with great success in more "conventional" types of alarm systems, maybe only to filter alarms. Coast will then provide the filtered alarm lists for the conventional display system. The selective functionality in an alarm system described above is a type of advisory system which might be more common in the future . In any case Coast will feed the process displays with alarm information, and these displays have to be made to optimize the performance of the operator regardless of where they get the alarm information from.
In Fig. 2 the instantiation of an alarm class using the graphic MMI is illustrated . Popup windows with defined alarm classes and attributes are shown. The user may type in the initial values of the attributes. In addition the example shows how limit check objects which generate alarms , can be coupled together in a group alarm. The arrows indicate the relations, and this is the same functionality as described by the relation definition in the textual Cola language.
2.4 Alarm Presentation The alarm display system is not a part of Coast, and it is looked upon as an external system. However, during a concept study one proposed the alarm presentation done in three types of displays : Overview display , the ordinary process displays with alarm
3.
STRUCTURE AND INTERFACES
Coast will contain facilities for building specific alarm systems, as well as facilities for alarm system
162
execution. It will be an integral part of the final alarm system . and not only act as a tool for building dedicated systems. Coast is shown in its final environment in Fig. 3.
potential alarm signals is almost 5000, and Picasso-3 is used for graphical interfaces. 3.1 Maill Modules
The main modules of Coast are shown in Fig. 4.
External operator support systems
B ~\ Operator MMI
Text-file with Coast language code. Designer's MMI
12:01:33 HiLevel tank23 12:02:40 PSI stopped 12:03:50 Liquid in area2
Communication Module Designer's MMI
COAST kernel OblectDef RL10L001 :StatAI4
Fig. 4 Main modules of Coast.
The configuration module reads text-files with alarm codes given in the COast LAnguage (COLA) , or interacts with the designer's MM!. The module checks the syntax of the Cola code, and sends a compiled version into the kernel. The communication module is generic , to take care of different types of systems to be coupled to Coast.
Fig. 3 The COmputerised Alarm System Toolbox. COAST. with interfaces to external systems.
Coast is meant to be an add-on possibility to conventional process control systems. As shown in Fig. 3, it receives process measurements from the process computer (PCDA - Process Control & Data Acquisition) , updates all necessary statuses, and sends updated alarm information to the display system for the operators in the control room. Coast itself does not possess graphic capabilities, but will be easy to couple to different graphical systems . It has been coupled to the PICASSO-3 user interface management system developed in Halden (Barmsnes et al., 1994). Coupling to all external systems is done through an application programmer's interface. which includes simple functions to get data in and out of Coast. e.g. process data must be provided as input to the alarm objects.
We consider incoming events as one out of two types: Either process-events, which contributes to new evaluations and updating of the data structures in the kernel, or operator-events, which are commands to select desired structures , or combinations of structures, from the kernel. The Coast kernel thus consists of two main modules , a process-event-module, including methods for updating the alarm objects and relations, and an operator-event-module, including methods to extract the desired alarm objects and relations for presentation. The process-event-module covers all the alarm generation and structuring. while the operator-event-module is dealing with all operator-requests and preparation for presentation.
The designer's MM! will be designed as an alarm editor. but it will also be possible to operate Coast through text-files.
4.
CONCLUSION
The main difficulty with existing alarm systems is the cognitive overload of the operators in heavy transients. Coast offers the possibility to structure and make relations among alarms to reduce this problem.
Coast will be tested in a full scope training simulator in the Halden man-machine laboratory, HAMMLAB. In this application the number of
163
Structuring includes both filtering the alarms automatically presented to the operator, and supporting the operator with different types of alann lists , which he can use interactively in his status identification task in case of disturbances . The alann presentation may thus include selectable displays, which the operator can use interactively, in addition to other alarm display s and the ordinary process displays.
vative Computer Applications in the Nuclear Industry, Snowbird, Utah , USA. S~renssen ,
A. (1990). Early Fault Detection at the Loviisa Nuclear Power Plant by Simulation meth ods. In : Modelling & Simulation, Proceedings of the 1990 European Simulation Mu lticonference, Nuremberg , Gennany .
Coast will contain facilities to build specific alann systems for many types of processes. However, it is not only a toolbox for building the alann system, it is also an integral part of the final on-line alarm system. The on-line system interacts with the display system and other external systems, updating and evaluating the data structures which initially are made by the alarm system designer.
0wre, F. and E. Marshall (1986). HALO - Handling of Alanns using LOgic: Background, Status and Future Plans. In: Proceedings of the International ANSIENS Topical Meeting on Advances in Human Factors in Nuclear Power Systems, Knox ville, Tennessee, USA. 0wre, F., S. Nilsen, T. Forsman and J.E. Stenmark (1991). An Operator Support System for a Swedish Nuclear Power Plant Control Room . In: Proceedings, EPRI conference on Expen System Applications for the Electric Power Industry, Boston, Massachusetts, USA.
Coupling Coast to external systems is a simple task with the application programmer's interface. This provides a set of remote functions for data exchange. Coast is able to generate most types of alanns , and the different methods may depend on plant state and type of plant. Coast is also able to read already generated alanns from other systems to modify its own behaviour. Coast input may be done in two ways : 1) through an interactive graphic Man Machine Interface, or 2) by means of text-files. The text-files must contain source code according to the specific alarm syntax defined in the COast LAnguage COLA. A subset of Cola provides strong selection capabilities, for on-line selections among the automatically updated set of alann objects. The data driven kernel of Coast ensures consistency of all data, and best possible efficiency.
5.
REFERENCES
Bannsnes , K.A. , 0. Jakobsen , T. Johnsen and H.O. Randem (1994). Developing Graphics Applications in an Interactive Environment. In: Proceedings, 1994 SCS Simulation Multiconference, San Diego , California, USA. Kemeny, J.G. (1979). Final Report of the President's Commission on the Accident at Three Mile Island. Washington, D .e. Marshall, E ., e. Reiersen and F. 0wre (1987) . Operator Performance with the HALO II Advanced Alarm System for Nuclear Power Plants - A Comparative Study . In : Proceedings of the ANS Topical Meeting on Artificial Intelligence and Other Inno-
164
Abstract. The OECD Halden Reactor Project has for several years been working with computer-based systems for determin ation of plant status including alarm filtering, earl y fault detecti on. and fun ction-oriented plant surveillan ce. The methods explored complement each other in different plant operating regime s and provide di versit y in plant monitoring systems. A new toolbox, COAST, has been made to enable integration of these different methods int o an alarm system. Coast will be easy to couple to different processes. It will be an integral part of the final alarm syste m and not only act as a tool for building dedicated systems. Key words. Alarm systems; failure detection; guidance systems ; man -machine systems ; on-line operati on; operator suppon; so ftware tools
1.
INTRODUCTION
In case of major disturbances in a plant with a large number of alarms issued, a function-oriented approach is in many cases recommended . Instead of looking at single systems or variables and alarms within a system, one monitors critical safety functions in terms of whether these functions are challenged. The Halden Project has explored this concept through several systems, like CFMS (Critical Function Monitoring System) and SPMS (Success Path Monitoring System), and the post trip guidance system SAS-IT (0wre et al., 1991).
One of the main tasks for operators in nuclear power plants is to identify the statu s of the process when unexpected or unplanned situations occur. The alarm system is the main infOlmation source to detect disturbances in the process, and alarm handling has received much attention after the Three Mile Island accident in 1979 (Kemeny , 1979). It was realized that conventional alarm systems created cognitive overload for the operators during heavy transients . The Halden Project developed an alarm filtering system called HALO (Handling Alarms using LOgic) using logic filtering to reduce the number of active alarms during process transients (0wre and Marshall , 1986). HALO has been subject to a number of validation experiments with different presentation techniques, as described by Marshall et al. (1987) .
Effectively handling and integrating different types of alarms into one system would improve the operator' s overview and thereby the overall safety of any industrial plant. This was a major motivation for initiating the development of the COmputerised Alarm System Toolbox, COAST. The experience gained from the work with various alarm systems was utilised when designing the basic functionality of Coast. It should thus be possible to utilize Coast to make most kinds of alarm systems. The goal is to reach solutions that can minimize the cognitive overload of the operating crew , but still fulfil the basic philosophy of alerting, informing and guiding the operator, as well as confirming whether his/her actions have the desired result.
Another approach is taken in the EFD (Early Fault Detection) system. The method used is to run small, decoupled models which calculate the state of the process assuming no faults , in parallel with the process. The behaviour of these models is then compared with the behaviour of the real process , and if there is a deviation, an alarm is issued. In this way false alarms are avoided , and one will only get one alarm for one fault. Prototypes developed for simulators and installations in real power plants e.g. the Imatran Voima owned plant in Loviisa, Finland, have demonstrated the feasibility of this methodology, provided that enough measurements are available for the process area considered (S0renssen , 1990).
An alarm system tool box which can be used on different processes, applying different alarm handling methods, has to be generic. The tool box must be easy to use to tailor-make alarm systems for many different processes, e.g . nuclear power plants or oil production platforms, and it must possess a flexible
159
development environment, to improve and simplify the task of the alarm system designer.
2.
internal leakages may be inferred by the alarm system. Let us illustrate this by considering the simple example given in Fig. I.
FUNCTIONALITY OF COAST
2.1 Integration of Alarms Level One aim is to combine the functionalities of the different alarm systems explored by the Halden Project into one integrated alarm system. This can be done in several ways, where the most generic way is to make a general software-package which is capable of making all types of alarms. Equally important is to facilitate the handling of these different alarms by making relations among them. The objective with Coast as such is to make the integration of different types of alarms possible. Coast will include the different functions needed, and it will be generic, such that it will be possible to use it to implement alarm systems for many different processes and plants. In an integrated alarm system, the alarm processing may be divided into three stages : alarm generation, alarm structuring and alarm presentation. Alarm generation is the phase where all new alarms are generated from process measurements. All types of alarms should be generated by this "module", conventional alarms, function-oriented alarms, as well as modelbased alarms . The advantage of having different types of alarms available when the operator investigates the status of the plant, is the diversity in the underlying methods, which contributes to a broader view and possibly a more robust conclusion . Model based alarms may be more sensitive than conventional alarms, and useful in dynamic situations , while function-oriented alarms are most useful in severe transients.
Pipe-C Valve-D
fooIIl-_SU_P_P_Orl_--l Flow-in- Pi pe- B
Valve-O-cJosed
event: Leak-in-Pipe-C
Fig. I Event / alarm network for hypothesis related alarms. In this network the shaded box represents a non-observable event, and the others represent alarms or observable status events.
The arrows without the crossing line are relations which indicate explanatory alarms or events , for example jlow-in-pipe-B combined with valve-Dclosed may explain the alarm high-level-heater-A. The arrow with the crossing line indicates the opposite, i.e. that a low-level-heater-A alarm probably not supports the event leak-in-pipe-C. For the alarm high-level-heater-A in the example in Fig. 1, lists of explanatory alarms and events are specified :
However, if only more information is presented to the operator, based on more information sources, the danger of cognitive overload may increase. In the alarm structuring phase one tries to cope with this problem. Structuring includes what normally is known as filtering of conventional alarms, and will thereby reduce the amount of information automatically presented to the operator, in this way clarifying the disturbance situation .
high-Ievel-heater-A: Explanatory alarms and observable events: flow-in-pipe-B, valve-D-closed Explanatory non-observable event: leak-in-pipe-C
F1ow-in-pipe-B combined with valve-D-closed may then explain why the alarm high-level-heater-A has appeared. Leak-in-pipe-C refers to a non-observable condition. This hypothesis could be the diagnosis if no other alarms or observable events are present.
It will be possible to couple Coast to an existing alarm system. Existing alarms will then be structured or filtered by Coast before presentation.
The main idea is that when the operator is searching for a solution to a problem he can make a hypothesis . This can either be an alarm which has not yet occurred, or a non-observable event. The a priori established relationships between the alarms can be used to confirm or disconfirm this hypothesis. The
2.2 Flexibility The results of advanced alarm structuring may support the operator with different types of alarm lists, which he can use interactively in his status identification task. Further, non-observable events such as
160
hypothesis must be present either as an alann not yet observed. or as a non-observable event. Alann lists can be generated and presented for the operator when he proposes a hypothesis:
grammer's interface (AP}) provides easy coupling of external systems to Coast. A library of API-function~ must be. included in the application. and all exchange of data IS done through these function s.
Hypothesis: leak-in-pipe-C:
Coast Language. The alann system designer defines the specific alann system by writing definitions according to the specific syntax provided by the COast LAnguage (COLA) . This can be done in two ways : Writing the Cola definitions in text-files. which are fed into the kernel. or by using a graphic . syntax sensitive editor. Pure text-files will be useful in cases where parts of the definitions are already prepared and stored. It may then be read into the kernel with minor modifications to fit the Coast language.
Supporting alarms: 12:03: 15 Low-flow-in-pipe-C Opposing alarms: 11 :45:20 Low-Ievel-heater-A Not yet observed alarms: ??:??:?? Low-temperature-in-heater-A
The presence of both confinning and disconfinning alanns cannot be excluded. because the relations are only normative. For instance if both low-jlow-inpipe-C and low-level-h eater-A have occurred . the operator may ask himself whether really leak-inpipe-C is true .
0-0 Design. Coast offers an object-oriented way to construct alann systems for the alann system designer. Object-oriented design includes classes with attributes. instances of the classes. methods and relations . The attributes may have dynamic behaviour. which may be given default on class level. or overridden by specific behaviour on instance level. Typical attributes of an alann object may be the type and the priority of the alann . Typical methods may be the updating of status etc. The alarm objects may be related to other alarm objects through relations . The relations are also defined by the alarm system designer, and may be considered as active or nonactive pointers between the objects. A set of basic alann classes can be collected in a library.
In this very simple example. it is straightforward to keep the overview of the relations . But in a realistic situation . the number of relationships and active alarms will be too many to handle for the operator. The system aims to offer the operator help in selecting those alanns which seem to confinn or disconfirm his hypothesis. In this situation the operator will use the alarmlevent network interactively on-line. by interrogating the system with respect to some particular hypothesis . This network could even be subjected to a systematic search to find those hypotheses which are most supported by the active set of alanns .
Allowed constructs in Cola comprise arithmetic , conditional and logic expressions, including "for every", and other first order logic. The actions of methods includes very powerful selections, and in addition time dependen!constructs are available for filterin oo · The definitions of these dynamic elements thus describe the dynamic alann system.
Coast offers a number of facilities to handle the above example. Alarm objects and relations between the alarm objects are the basic building blocks in the tool box . This facilitates a flexible structuring of alarms. which may be used both for conventional filtering. and for the more general structuring purposes as shown in the example above. It will be possible for the alann system designer to make different dynamic relations between alanns. Together with very strong on-line selection capabilities. different lists can be made available to the operator. which he can use in his diagnostic reasoning task. This provides a best possible tool for the operator to search for and test different hypotheses .
The first task of the alann system designer is to define alann classes with attributes and methods, and relations. A very simple example of a class definition and a relation definition with the Coast language is shown below: Classdef StatHiAlarm Attr Priority: string Attr HiAlarmStatus : string Attr System: string Attr Time: int Attr Meas : real with history Attr HiAlarmLimit : real Method whenever Meas > HiAlarmLimit assign "on" to HiAlarmStatus assign clock to Time EndMethod EndClassDef
2.3 Use of COAST Configuration. The alann system designer will use the toolbox to make a specific alann system. It is possible to operate Coast without active external connections. so classes etc. can be defined before the tool box is coupled to any external system. However. one may also run with all external systems connected . The designer has to configure the alann system and decide which external systems that are going to be connected to the toolbox . An application pro-
RelationTypeOef x : StatHiAlarm member-of Group1 if x.HiAlarmStatus == "on"
161
The attributes , relations and methods are the dynamic elements of Coast. In the example above the attribute HiAlarmStatus gets a new value whenever the condition in the method is true . Another way to write this
File
Edit
Utilities •.•
Help
IS:
Attr HiAlarmStatus:string = if (Meas > HiAlarmLimit) then "on" else "off" Coast is an event-driven program, and updates all necessary values whenever something happens , e.g. when process measurements are fed into the kernel. In the above example ':=' means "is always the same as". Coast does not execute as a sequential program. The updating of necessary attributes etc. is done by a kind of forward chaining. Consistency of values is ensured automatically. such that no cycles are present in the definitions. Also no value is updated more than once , and this ensures the best possible efficiency, which is highly needed , as the Coast language itself offers flexible and computational heavy constructs. The evaluation in the kernel is however fully deterministic. which is required from a system which shall be used to make alarm systems.
Priority := " Severe " System := " RL10" HIAlarmLimit := 3.0
Fig. 2 Example of instantiation of an alarm class. and coupling between alarm objects , via relations. The alarm class StatAl4 is selected from a library, instantiated, and given the id RLl OLOO I. information , and selectable displays , which the operator can use interactively in his investigation task.
The graphic MMI equivalent of the above example will be to activate a C1assDef window , click on new .. in an attribute popup window , and write the names of the attributes.
Coast offers a very strong functionality to enhance the operator' s diagnostic task. The operator may want to look at dynamic alarm lists of various types interactively. The selective constructs comprise a subset of Cola (Cola light), which is made available for the end user. Cola light is interpreted , so it is possible to write in new selection criteria for new , dynamic alarm lists on-line. This feature will only offer the possibility to search among existing alarm objects , it will not produce new objects in the kernel, i.e., it is a reading, not a writing facility.
After having defined alarm classes , the next step for the designer is to instantiate alarm objects from the classe s. Initial values and expressions may be given for attributes which are not going to keep the default beha\'iour given on class level. Using text-definitions according to the allowed syntax, it may look like: ObjectDef RL 1OL001 : StatHiAlarm Priority := "Severe" System := "RL 1 0" HiAlarmLimit = Basic.HiAlarmLimil EndObjectDef
In practical use the operator will thus be in an X-windows environment, clicking on icons, or he may even write in new selection criteria on-line, to get up different alarm lists. This enables himlher to find out as much as possible about the current alarm situation and the state of the plant. It is however important to emphasize that Coast also can be used with great success in more "conventional" types of alarm systems, maybe only to filter alarms. Coast will then provide the filtered alarm lists for the conventional display system. The selective functionality in an alarm system described above is a type of advisory system which might be more common in the future . In any case Coast will feed the process displays with alarm information, and these displays have to be made to optimize the performance of the operator regardless of where they get the alarm information from.
In Fig. 2 the instantiation of an alarm class using the graphic MMI is illustrated . Popup windows with defined alarm classes and attributes are shown. The user may type in the initial values of the attributes. In addition the example shows how limit check objects which generate alarms , can be coupled together in a group alarm. The arrows indicate the relations, and this is the same functionality as described by the relation definition in the textual Cola language.
2.4 Alarm Presentation The alarm display system is not a part of Coast, and it is looked upon as an external system. However, during a concept study one proposed the alarm presentation done in three types of displays : Overview display , the ordinary process displays with alarm
3.
STRUCTURE AND INTERFACES
Coast will contain facilities for building specific alarm systems, as well as facilities for alarm system
162
execution. It will be an integral part of the final alarm system . and not only act as a tool for building dedicated systems. Coast is shown in its final environment in Fig. 3.
potential alarm signals is almost 5000, and Picasso-3 is used for graphical interfaces. 3.1 Maill Modules
The main modules of Coast are shown in Fig. 4.
External operator support systems
B ~\ Operator MMI
Text-file with Coast language code. Designer's MMI
12:01:33 HiLevel tank23 12:02:40 PSI stopped 12:03:50 Liquid in area2
Communication Module Designer's MMI
COAST kernel OblectDef RL10L001 :StatAI4
Fig. 4 Main modules of Coast.
The configuration module reads text-files with alarm codes given in the COast LAnguage (COLA) , or interacts with the designer's MM!. The module checks the syntax of the Cola code, and sends a compiled version into the kernel. The communication module is generic , to take care of different types of systems to be coupled to Coast.
Fig. 3 The COmputerised Alarm System Toolbox. COAST. with interfaces to external systems.
Coast is meant to be an add-on possibility to conventional process control systems. As shown in Fig. 3, it receives process measurements from the process computer (PCDA - Process Control & Data Acquisition) , updates all necessary statuses, and sends updated alarm information to the display system for the operators in the control room. Coast itself does not possess graphic capabilities, but will be easy to couple to different graphical systems . It has been coupled to the PICASSO-3 user interface management system developed in Halden (Barmsnes et al., 1994). Coupling to all external systems is done through an application programmer's interface. which includes simple functions to get data in and out of Coast. e.g. process data must be provided as input to the alarm objects.
We consider incoming events as one out of two types: Either process-events, which contributes to new evaluations and updating of the data structures in the kernel, or operator-events, which are commands to select desired structures , or combinations of structures, from the kernel. The Coast kernel thus consists of two main modules , a process-event-module, including methods for updating the alarm objects and relations, and an operator-event-module, including methods to extract the desired alarm objects and relations for presentation. The process-event-module covers all the alarm generation and structuring. while the operator-event-module is dealing with all operator-requests and preparation for presentation.
The designer's MM! will be designed as an alarm editor. but it will also be possible to operate Coast through text-files.
4.
CONCLUSION
The main difficulty with existing alarm systems is the cognitive overload of the operators in heavy transients. Coast offers the possibility to structure and make relations among alarms to reduce this problem.
Coast will be tested in a full scope training simulator in the Halden man-machine laboratory, HAMMLAB. In this application the number of
163
Structuring includes both filtering the alarms automatically presented to the operator, and supporting the operator with different types of alann lists , which he can use interactively in his status identification task in case of disturbances . The alann presentation may thus include selectable displays, which the operator can use interactively, in addition to other alarm display s and the ordinary process displays.
vative Computer Applications in the Nuclear Industry, Snowbird, Utah , USA. S~renssen ,
A. (1990). Early Fault Detection at the Loviisa Nuclear Power Plant by Simulation meth ods. In : Modelling & Simulation, Proceedings of the 1990 European Simulation Mu lticonference, Nuremberg , Gennany .
Coast will contain facilities to build specific alann systems for many types of processes. However, it is not only a toolbox for building the alann system, it is also an integral part of the final on-line alarm system. The on-line system interacts with the display system and other external systems, updating and evaluating the data structures which initially are made by the alarm system designer.
0wre, F. and E. Marshall (1986). HALO - Handling of Alanns using LOgic: Background, Status and Future Plans. In: Proceedings of the International ANSIENS Topical Meeting on Advances in Human Factors in Nuclear Power Systems, Knox ville, Tennessee, USA. 0wre, F., S. Nilsen, T. Forsman and J.E. Stenmark (1991). An Operator Support System for a Swedish Nuclear Power Plant Control Room . In: Proceedings, EPRI conference on Expen System Applications for the Electric Power Industry, Boston, Massachusetts, USA.
Coupling Coast to external systems is a simple task with the application programmer's interface. This provides a set of remote functions for data exchange. Coast is able to generate most types of alanns , and the different methods may depend on plant state and type of plant. Coast is also able to read already generated alanns from other systems to modify its own behaviour. Coast input may be done in two ways : 1) through an interactive graphic Man Machine Interface, or 2) by means of text-files. The text-files must contain source code according to the specific alarm syntax defined in the COast LAnguage COLA. A subset of Cola provides strong selection capabilities, for on-line selections among the automatically updated set of alann objects. The data driven kernel of Coast ensures consistency of all data, and best possible efficiency.
5.
REFERENCES
Bannsnes , K.A. , 0. Jakobsen , T. Johnsen and H.O. Randem (1994). Developing Graphics Applications in an Interactive Environment. In: Proceedings, 1994 SCS Simulation Multiconference, San Diego , California, USA. Kemeny, J.G. (1979). Final Report of the President's Commission on the Accident at Three Mile Island. Washington, D .e. Marshall, E ., e. Reiersen and F. 0wre (1987) . Operator Performance with the HALO II Advanced Alarm System for Nuclear Power Plants - A Comparative Study . In : Proceedings of the ANS Topical Meeting on Artificial Intelligence and Other Inno-
164