Diagnostic Algorithms Based on Multilevel Flow Models

Human error is a common source of accidents in complex plants. We believe that many human errors really are caused by lack of intelligence in the instrumentation and control systems, putting the operators in situations, which humans realistically cannot be expected to cope with. Through history, several computer-based algorithms have been proposed and used for automated sensor fault detection, alarm analysis, and fault diagnosis, to support human operators. The main problem with such algorithms is that they demand a large effort to build, validate, and especially rebuild when the p lant is changed. We propose the use of algorithms based on Multilevel Flow Models (MFM), which are graphical models of goals and functions of technical systems. MFM provides a good basis for computer-based supervision and diagnosis, especially in real-time applications, were fast execution and guaranteed worst-case response times are essential. The expressive power of MFM is similar to that of rule-based expert systems, while the explicit representation of means-end knowledge and the graphical nature of the models make the knowledge engineering effort less and the execution efficiency higher than that of standard expert systems. If MFM -based measurement validation and alarm analysis had been used, the Three -Mile Island incident would not have happened. Introduction: Human Error There are several different kinds of causes of accidents in large industrial plants. Many accidents are caused by failures in the physical hardware or the control system software, while others are caused by insufficient or erroneous operation routines, training, and regulations. Yet another type of accident is caused by human error, which is the kind of accident where the human operators did not manage the plant correctly, even though the hardware was functioning, and the routines and training were fine. In fact, human error is a fairly common cause of accidents. Complex accidents often have several causes. For example, the infamous Three-Mile Island incident was caused by a malfunctioning valve (pilot-operated release valve, PORV), which remained open although the instruments showed that it had been closed. Thus, there were causes in both physical hardware (the valve), and the control system software (the erroneous indication). What really turned this into a serious incident, though, was that the operators did not understand the situation quickly enough. During several hours, they did not check the measurements downstream from the open valve, which would have told them that the valve had not closed, and that the reactor was loosing steam. Not until the next shift came on was the valve checked, and by then the core was almost uncovered. In the senate hearings, the failure to understand the situation and check whether the valve had indeed been closed was judged a human error, Lees (1983). An implicit conclusion may seem to be that when human error is the cause of an accident, there is nothing wrong with the hardware or software. However, we strongly believe that many human errors are partly caused by shortcomings in the design of the cont rol and presentation systems. For example, in order to quickly find small problems, plants are equipped with a large number of alarms. But in a large accident, this may mean that too many alarms are activated, so that the operators cannot keep up with them, and the alarm system may become counter productive or even useless. For example, in the TheeMile Island incident, the printer queue for the alarms was some three hours behind schedule, and more than 100 audio alarms were active simultaneously, Lees (1983). Alarm showers may consist of several hundred alarms in less than a minute. When operators fail to act correctly under such circumstances, we consider it wrong to speak of human error, because no human would be able to handle the situation correctly. Improving Instrumentation and Control Systems Several methods for improving instrumentation and control systems have been proposed. Among these are: • Sensor fault detection, based on local monitoring of each sensor or global comparison between multiple, partly redundant sensors. The latter could possibly have helped the operators to have some suspicions about the PORV in the Three-Mile Island incident. • Alarm analysis, that is, separation of alarms into primary and consequential ones, where the latter can be suppressed. It is believed that the number of alarms activated during the Three-Mile Island incident could have been reduced by many orders of magnitude by an alarm analysis algorithm. • Fault diagnosis, where a computerized system performs measurements and asks questions in order to systematically find the primary explanations for a problem. • Failure mode and effects analysis, where the consequences of breakdown of a certain physical component will be shown for other components and systems in the plant. Alarm analysis systems were in use on the nuclear reactors at Oldbury and Wylfa in the United Kingdom, Lees (1983). These systems were based on alarm tress, that is, graphical descriptions where the possible alarms are linked to each other, telling which alarms are causally connected with each other. However, these systems were not very successful. Referring to the Oldbury system, Long (1980) writes: “However, the performance of this and two related systems was reported at the meeting to be less than satisfactory. Specifically, the alarm trees were costly to develop, subject to error, and difficult to modify. ” In later years, and especially after the Three-Mile Island incident, people have tried to use rule-based expert systems for automated fault diagnosis of complex plants. Again, the conclusions have been that the effort to build and update the knowledge needed in such a system is too large. Still, systems are constructed by, for example, Gensym Corporation and Cogsys, where the latter has built a system for alarm analysis based on fuzzy rules for a blast furnace plant in Australia. In this paper, we present a set of algorithms for operator support, based on multilevel flow models. The main advantage is that the knowledge engineering effort needed is relat ively small. Thus, we believe that these methods may indeed form a practical solution to many of the problems described, and help to avoid several kinds of human error. Multilevel Flow Models Multilevel flow models (MFM) are graphical models of goals and functions of technical systems. The goals describe the purposes of a system or subsystem, and the functions describe the capabilities of the system in terms of flows of mass, energy, and information. MFM also describes the relations between the goals and the functions that achieve those goals, and between functions and the subgoals, which provide conditions for these functions. MFM was invented by Morten Lind at the Technical University of Denmark, see Lind (1990 a). Several new algorithms and implementations were contributed by Jan Eric Larsson at Lund Institute of Technology, see Larsson (1992, 1994 a, 1996). MFM provides a good basis for diagnostic algorithms. The work of Larsson (1996) describes three algorithms based on MFM: measurement validation, alarm analysis, and fault diagnosis. Other algorithms have been developed later, such as fuzzy alarm analysis, see Dahlstrand (1998), Larsson and Dahlstrand (1998), failure mode analysis, see Öhman (1999), and sensor fault detection. The measurement validation algorithm would have detected the discrepancy in the PORV flow at Threemile Island, and the alarm analysis would have drastically reduced the number of active alarms. Had these MFM algorithms been in use, the incident would never have happened. An Example of an MFM Model MFM has been thoroughly explained in Lind (1990 a) and Larsson (1992, 1996). Here a small example will be given, to show the basics of MFM modeling. We will use a part of the main circulation system of a nuclear power plant. A much simplified process graph, from an example in the master’s project Ingström (1998), is shown in Figure 1. Moderator tank Reactor Frequency converter Power