MELDASH: a diagnostic application-specific expert systems shell for network fault diagnosis

MELDASH: a diagnostic application-specific expert systems shell for network fault diagnosis Kenji Komai, Keinosuke Matsumoto and Toshiaki Sakaguchi Industrial Systems Laboratory, Mitsubishi Electric Corporation, 8-1-1, Tsukaguchi Honmachi, Amagasaki, Hyogo, 661 Japan

Expert systems are receiving considerable interest, but there seems to be a credibility gap between the state-of- the-art technology offered by artificial intelligence and expectations fuelled by potential applications. This is because the emerging technology provides us with very sophisticated programming tools and environments, but with almost no basis on which to program. The computing procedure to be implemented must be specified by the applications. This paper emphasizes the need for an algorithm generation tool and discusses the prospects for the task- and domain-specific expert systems shell MELDASH. A prototype expert system for network fauh diagnosis is described to explain the methodology.

Keywords." power system diagnosis, protective relays, tools, domain shells, model-based reasoning, hypothetical reasoning

I. I n t r o d u c t i o n Tools for building expert systems are now commercially available, but in the authors' opinion they are too general to match individual problems. This is because the emerging technology provides us with very sophisticated programming tools and environments, but with almost no basis on which to program. The computing procedure to be implemented must be specified by applications L2, such as network fault diagnosis. Each time an expert system is developed, the knowledge base has to be designed from the very beginning. Unlike designing mathematical algorithms, standard modules for knowledge algorithms are not defined yet. In other words, no knowledge libraries are available. This increases the cost of system development.

Received 5 October 1991 ; revised 16 January 1992

It has been emphasized that the architecture of an expert system provides us with a convenient way to modify a knowledge base, because the knowledge part is separated from the inference engine. This is true for a small system, but it ceases to be true as the system gets bigger. Dealing with the large-scale knowledge base generated by a real problem is harder than we had expected, essentially because of the use of too general an inference engine and representation schemes that are too uniform to handle a large number of different tasks. For example, the same engine was used both for diagnosis and design tasks. These two tasks have different compu- tational structures, and the use of uniform representation schemes makes it difficult to match each task-specific structure to the uniform format.

This paper considers fault diagnosis 3. Most diagnostic systems fall into one of two categories: symptom-based 4 or model-based L6. In symptom-based diagnosis, knowledge is required in the form of symptom-fault associations. All symptom-fault associations are catalogued in a symptom-indexed table (or diagnostic tree) for later reference. In model-based diagnosis, knowledge is required in the form of a model describing the behaviour of a system. Faults are detected or diagnosed by recognizing discrepancies between the real output of a system and the behaviour of the model.

Symptom-based diagnosis is able to diagnose correctly a fault that has been catalogued. However, it cannot handle faults that have not been catalogued. It has proved adequate for small systems, but it cannot be applied to large systems, because generation of the table of symptom-fault associations requires considerable time and effort.

Model-based diagnosis is suitable for power system diagnosis, because the protective relay systems, which are the objective systems of network fault diagnosis, can be modelled as discrete-event systems, in which each component of the system has discrete states which are

Vol 14 No 2/3 Apri l /June 1 992 0142-0615/92/2/30217-08 © 1992 Butterworth-Heinemann Ltd 21 7

common to all similar components. The components will interact with each other and alter the state of one or several components.

This paper describes a new task-specific and domain- specific shell called MELDASH (Mitsubishi ELectric corporation Diagnostic Application-specific expert system SHell) 7 which reflects and utilizes the nature of model-based diagnosis. In this context a task-specific shell is one that has a special problem-solving method for the specific task, and a domain-specific shell is one that has knowledge about the application domain. These two types of shell are expected to replace existing general use shells. For the task-specific shell, MELDASH deals with model-based diagnosis of discrete-event systems. For the domain-specific shell, MELDASH deals with knowledge about power systems.

MELDASH has the following merits:

• A diagnostic system can be constructed simply by inputting system models, because a diagnostic algorithm which has a generality beyond one domain is prepared.

• Verification is easy because only the model must be checked.

• The performance of the diagnostic system depends entirely on the level of detail of the model.

II. The mode l l ing m e t h o d of M E L D A S H The modelling method has the following characteristics.

The domain model is implemented using an object- oriented technique. Structural relations with other components and functions which are common to all objects of the same kind are modelled using an object-oriented technique. Models of individual systems are easily created by making instances of classes.

An easily analysable functional model is used. A function is expressed in the form of state transitions, not in the form of methods and message-passing, which are used to express the function in object-oriented programming, because causal relations are difficult to explain in this way. To facilitate analysis, a transition is restricted to a change in the state of one component, as shown in Figure 1. We will call the diagram of state transition of one component a transition network.

The model incorporates both a normal mode and a fault mode. We can estimate the ability of diagnostic systems by checking the fault mode in the model description.

Figure 1. A sample transition network

• Transition

( ~ State

J - ~ Transition condition

(defrule 50S-1 :backward T :timer-index 70 :b~f0re (50-RELAY

^status passive ^fault-type <FTYP> ^protect <L> ^trip-cb <CB> )

:~fter (50-RELAY

^status satisfy ) , ;~ondi l ion (Sand

(DOUBLE-LINE <L> "status faulty ^fault-type <FTYP> )

(CB <CB> ^status <> open ) )

)

;rule of a selective relay ;available for backward reasoning ;Timer index is 70. ;state before state transition ;class name for this object ;operable ;to set fault type <FTYP> ;This relay protects <L>. ;This relay send trip signal to ;state after state transition

;Operation condition is satisfied. ;conditions of other components

;Two-circuit transmission lines ;are faulty. ;Fault type is <FTYP>. ;Circuit breaker <CB> ;is not open.

Figure 2. A causal rule for a selective relay

I1.1 Structural models Structural data are expressed through the use of object-oriented programming techniques. First, classes are defined describing a structural relation that is common to all components of the same kind, making use of an inheritance mechanism. Classes have structural data similar to actual objects. Second, methods to refer to structural data are defined. Finally, individual system data are input by making instances of classes.

11.2 Functional models 11.2.1 The transition networks. Systems to be diagnosed are modelled as discrete-event systems. The Petri net 8 is well known for its use in this context. It has a high capability for modelling many systems, but it is difficult to analyse its reachability. Through reachability analysis, a check is made of whether all components can reach the observed final states from current states in a current hypothesis simulation. Hence reachability analysis is very important in diagnosis. This analysis is difficult in a Petri net since it allows one transition to cause state changes in many other components. As a result, all the components must be taken into account at the same time.

To facilitate reachability analysis, a transition network considers transitions of one component only. The transition conditions are described by the states of other components, and express the relationship between components. In the transition network, we can easily analyse reachability for each component separately. For example, suppose that the current state is SO and the final state is $3 in Figure 1. When all transitions can occur, $3 is reachable from SO. If condition D3 has proved not to be satisfied, $3 becomes unreachable from SO.

11.2.2 The causal rules. States and conditions peculiar to each kind of component are identified; then rules that describe the causal relations of the state transition of the components are defined for each class.

The features of causal rules may be explained by the sample rule shown in Figure 2. This rule describes the operational condition of selective relays. Causal rules must have :before, :after and :condition elements. The :before part describes the status which is to be met for the relay to operate. The :after part describes the new

218 Electrical Power & Energy Systems

state after the relay's operational condition is satisfied. The :condition part specifies the status of other components which allow the relay to operate. The first element of the :before part list indicates the class of component whose state changes.

The :condition part has a combination of patterns that other relevant objects must satisfy when the state transition occurs. Each pattern has the class name of the objective component, an index variable whose value is set to the component name in the :before part or previous patterns in the :condition part, and the body of the pattern description. The syntax of the pattern description, such as a variable, is similar to OPS5, one of the production systems. The pattern is checked so that it matches the current state of the component whose name is the value of the index variable. The pattern body contains both the state description and reference to structural data. There are four combination types of patterns: and, or, not, exist. Exist means that a component that is matched to the pattern in some component sets exists.

An alarm, that is, the detection of a fault, is described by special rules which are interpreted in reverse to generate fault hypotheses. Backwards-interpretable rules are defined with a T value of the keyword :backward, as shown in Figure 2.

The timer index is used to select one transition among those that are available at the same time. The transition with the highest timer index is selected. The timer index is coordinated so that events occur in the same order as in the real system.

The form in Figure 2 is interpreted in two different ways. One is the forward interpretation such that if the relay is normal and a fault has occurred to the component which the relay is protecting, then the relay's operational condition is satisfied. The other is the backward one (reverse direction of actual event sequence). When the relay operation has been observed, the computer will create a fault hypothesis on the component which the relay is protecting.

11.2.3 Relation of the causal rules and the transition networks. A functional model of an individual system has as many transition networks as there are components in the system. Transition networks are automatically created by combining causal rules and structural data, as follows.

First, several states are created for each component. Second, states are checked to be matched to the :before part of causal rules, that are defined for the component 's class. When a state is matched to the :before part of a rule, a transition is created. When no state is matched to the :after part of the causal rule, a new state is also created. A newly created state is also checked to be matched to the :before part of the causal rules. Finally, transition conditions are created by interpreting the :condition part of the causal rules. Each pattern in the :condition part is transformed to states of other components, which are decided using component structural data. For a sample rule as shown in Figure 2, the :condition part is transformed to the faulty state of the protecting line and states of the tripping circuit breaker.

Because transition networks are created from causal rules, they may be interpreted in two ways in the diagnostic procedure. Hypothesis generation is performed by backward marking on transition networks

Q

Figure 3. A special state to express a type of fault: SO, operable; $1, operational condit ion is satisfied; $3, special fault state; $4, operated

observed information. In simulation, each component changes its state.

11.3 The modelling of faults Faults are expressed as states in the transition network. Transitions to fault states are treated as hypotheses, and they come true only when they are assumed to have occurred.

There are two types of faults state. One expresses the fault state after some disturbance, such as a short circuit; the other is reached only when it is necessary to explain observed data. A sensor fault state is a typical example of the second type: it means that a sensor is not operating as it should, owing to a malfunction. The sensor fault state is shown as a double circle in Figure 3. The transition to a sensor fault state occurs after a transition to a state which indicates that the operational condition is satisfied when the sensor operation is not observed. We call the second type of fault state a sensor fault state, although strictly speaking such second-type states can express things other than sensor faults.

III. S o f t w a r e s t r u c t u r e o f M E L D A S H Figure 4 depicts the software configuration of MELDASH. Parts enclosed with bold lines are specific to network fault diagnosis. Other parts are specific to the task, that is model-based diagnosis of discrete-event systems. MELDASH consists of diagnostic task, domain model, developing interface, and diagnosis interface.

The diagnostic procedure is represented by a hierarchy of procedural knowledge. MELDASH provides the domain-independent diagnostic task and schemes to represent domain models.

II1.1 The diagnostic algorithm Diagnosis is performed using a generate-and-test strategy. Fault hypotheses are generated from observed data, and the hypotheses are tested using event simulation. In this section, the diagnostic algorithm will be outlined.

Disturbance hypotheses are generated by backward tracing of the transition network using observed data when no normal transition can occur. First, alarm states, which are recognized as observed final states on several

Vol 14 No 2/3 Apr i l /June 1992 219

r~ Developing interface

Causal rule editor

. . . . . . . . . . , . . . . . . . , . . . . . . . . : . . . . . : . : 9 . . . . . . . , . . . . . . . . . . . . , . . . .

~I network monitor

Domain L

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: !:i:?i - ? Structural data ........ , . . . . . . . . . ::

Causal rule

::::::;:;:::;:::;: li i!!!iliiiiiiiiiiiiilil

Transition network

Element I

~ Transition

C) State Element 5 " ~ ' ' ~ [ ] Transition condition

Figure 4. Software structure of MELDASH

Diagnostic task

m ~ |:::;:::

Testing li:iiiil hypotheses :::::::::::::::::::::::::

Hypotheses space

J Domain- specific

Diagnosis interface

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . , . . . . . . , . . , . . . . . . . . . . . . . . . . . . . . . . . . . . . ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

i2 transition networks, are marked. When the marked state is not the current state, states, transitions and transition conditions that are in the path from the current state to the alarm states are marked. Second, states that exist in marked transition conditions are marked. For these newly marked states, the same marking procedure is repeated until no state is marked. Finally, marked transitions to disturbance fault states are generated as hypotheses.

Sensor fault hypotheses are generated to eliminate contradiction between a simulated event and the observed data. The transition condition to the sensor fault state is treated exceptionally. It is satisfied only when the transition is needed to explain the observed data and the logical condition described with states is satisfied.

In the simulation, transitions occur one by one. One simulation step is separated into three phases: transition occurrence, adjusting reachable state set of each transition network, and determining the transition to occur at the next step.

After a transition occurs, transition conditions are evaluated which contain states in the transition network whose current state is changed. When the transition condition is proved not to be satisfied, it is removed and the reachable state is adjusted. When the transition condition is satisfied, the transition that uses the

condition becomes the transition that may occur at the next simulation step. In determining the next transition, the transition that has the highest timer index is selected among transitions that can occur in that situation.

The timer index is decided as follows. The upper limit of the timer index for normal rules is 99, and the lower limit is - 9 9 . The timer index of the sensor fault rule is 100, which doesn't need a rule description. The timer index of the disturbance fault rule is - 100.

A hypothesis test is repeated after every step of the simulation by analysing the reachability problem on each component. Hypotheses are accepted if the current states of all transition networks belong to the observed final data set. When no final state belongs or will belong to a reachable state set in any transition network, the hypothesis is rejected. In other cases, the simulation continues.

111.2 Development and diagnosis interface The development interface includes editors for structural data and causal rules. The transition network monitor, which displays a transition network graphically, is also prepared. These tools support the modelling process. The diagnosis interface is used for setting observed data or for showing diagnostic results via a graphic display.


IV. Appl icat ion to ne twork faul t diagnosis The proposed method is applicable to network fault diagnosis. Simple and detailed models are created to show that the proposed method can perform diagnosis according to the level of the model.

IV.1 A network structural model The structure of power networks is modelled by defining classes for various levels of components in the network. The structural relationship between classes is expressed by having other instances as values of their instance variables. For example, the class relay has its protecting component in the instance variable protect.

Figure 5 summarizes the structural relationships between classes. The solid lines show structural relation-

Network \

Component : : : : : : . . . . . Stat ion N

Connector I group group group group

I Component :":':??':?':':'.:t::- - -:::_::_ " . . . . ~.].... /

Figure 5. Structural relationships among classes to express power system. Solid lines, structural relationships; dotted lines, inheritance relationships

ships and the broken lines show inheritance relationships. These classes have proved able to model the real network shown in Figure 6. Various terms in Figure 5 merit explanation. The class network manages all the structural data of the network. It consists of stations and transmission line groups just as in real networks. A station consists of bus groups, transformer groups, generator groups and connectors.

Line groups or bus groups are groups of components that are located at the same places, and are generally called component groups. A connector is a group of circuit breakers that exist between similar component groups. Connectors and component groups are used to obtain fault current flow information, that is, whether one component can supply a fault flow if a fault occurs on the other component. Fault current flow information is recorded at the circuit breaker (CB) between components.

Because relays protect components, and trip circuit breakers, relay has a structural relationship with component and CB. Since a current transformer (CT) exists near CB, and transformers are used as input signal to the relays, CT has a structural relationship with CB and relay.

Specialized classes of component, for example bus, inherit a structural relationship with CB and relay from component. In addition bus group inherits a structural relationship with connector from component group.

Many structural relationships between classes are bidirectional. For example, relay has its protecting component data, and component has data on the relays that protect it. Methods are defined for referring to data of a class that has no direct relationships. For example, station may be referred to by bus through bus group. Neighbouring components may be referred through CBs via component.

-t rT

m

_L.L

TT J i i I I

I

J_.L

II

t i ,

ii

,}-

13

Figure 6. An example of a real network to be modelled

t J

v

t i

Vol 14 No 2/3 Apri l /June 1992 221

IV.2 A simple functional model In a simple functional model, the network components (transmission line, bus, transformer, and generator) are regarded as the minimum unit area to be protected by relays. In other words, this model does not consider at which part of the component a fault would occur. No exceptional operations or malfunctions by special fault are taken into account in this model. Figure 7 shows the transition networks for a simple model.

Figure 7(a) shows the transition network of a component. The states of this transition network may be divided into four groups (normal, discharged, faulty and influenced by a fault). A transition to the faulty state is treated as a disturbance. States that are influenced by a fault are created to describe the operational condition of remote backup relays. If a fault cannot be cleared by simply cutting off the faulty component from the network, the remote backup relay will operate to remove the fault. The operational condition of a remote backup relay is described as follows:

A remote backup relay operates if the component that it is protecting either becomes faulty or is influenced by a fault

A component which exists in the path from the faulty component to the generator changes state to 'influenced by a fault'. These states are distinguished by the number of components that exist between the influenced component and the faulty component. The transition condition to the discharged state is the same for all the other states.

A circuit breaker (CB) is modelled as shown in Figure 7(b). If a breaker receives a trip signal from a relay, it

b

a

Transition O State

[ ] Transition condition C ) Disturbance ( ~ Special fault state fault state

Figure 7. Transition networks for a simple model. (a) Transition network of component: EO, normal; El, outage; E2, short fault; E3, influenced by short fault, reach 1; E4, influenced by short fault, reach 2; E5, influenced by short fault, reach 3; E6, ground fault; E7, influenced by ground fault, reach 1 ; E8, influenced by ground fault, reach 2; E9, influenced by ground fault, reach 3. (b) Transition network of circuit breaker: CO, closed; C1, received trip signal; C2, open; C3, malfunction. (c) Transition network of relay: RO, operable; R1, satisfied; R2, operated; R3, malfunction; R4, locked

0 State ~ Transition ,...._,~ r--]k~ 0 Disturbance

fault state

Q Special fault state C

[] Transition condition

Figure 8. Transition networks for a detailed model. (a) Transition network of transmission line: EO, normal; El, outage; E2, short fault in centre zone; E3.1, short fault in near bus zone 1; E4.1, short fault in close CB zone 1; E5, influenced by short fault, reach 1; E6, influenced by short fault, reach 2; E7, influenced by short fault, reach 3; E8, ground fault in centre zone; E9.1, ground fault in near bus zone 1; E10.1, ground fault in close CB zone 1; E l l , influenced by ground fault, reach 1 ; E1 2, influenced by ground fault, reach 2; E13, influenced by ground fault, reach 3. (b) Transition network of CT that monitors a line: TO, normal; T1, zero; T2, short, out; T3, short, in, large; T4, short, in, small; TS, short, in, close CB zone; T6, short, in, not monitoring component; T7, ground, out; T8, ground, in, large; T9, ground, in, small; TIO, ground, in, close CB zone; T l l , ground, in, not monitoring component. (c) Transition network of remote backup relay: RO, operable; R1, satisfied; R2, operated; R3, malfunction; R4, locked; R5, operated, fast

changes to the receive trip signal state. If the breaker trip is observed, the current state is changed to the open state. Otherwise, the current state is changed to the malfunction state.

A relay is modelled as shown in Figure 7(c). The shape is similar to that in Figure 7(b), except in a locked state. The transition condition to satisfied state is described for each type of relay.

IV.3 A detailed functional model Exceptional operation or malfunction is introduced in a detailed function model. A current transformer is added to the simple model. The fault current that is measured by current transformers is also taken into account. In addition, the models of components and relays are made more detailed. Figure 8 shows the transition networks for a detailed model. The faulty states of the components


CT

Out Double Major Major Minor Remote

Figure 9. Relationships between fault points and CT states

are divided into several states, depending on the fault location. Figure 8(a) is a model for transmission lines.

The fault current measured by the CT is modelled as several states depending on the fault location. Figure 9 shows the correspondences between the fault locations and the states of the CT. If a fault is located closer than the central part of the transmission line, the CT takes the in-major (in, large) state. If a fault is located in the closer part of the other side bus of the line, the CT takes the in-minor (in, small) state. Relays that protect only 70% of the line operate only when the CT takes the in-major state. If a fault occurs inside the CT at an unprotected component, the CT takes the in-double (in, close CB zone) state. If a fault is located in the unprotected component, the CT takes either the in- remote (in, not monitoring component) or the out state, depending on the direction of the fault current observed by the CT. The state zero is taken only when it is relevant to the exceptional operation of selective relays. Selective relays operate if the currents of two CTs differ by more than a set value. Therefore, when the two CTs of double lines take out states and one of them takes a zero state because the breaker of the other side has been tripped earlier by a remote backup relay, the selective relay at the zero side line operates.

The transition networks of relays are similar to those in the simple model. The operational condition of a relay is described by means of CT states and not by means of component states. For example, the operational condi- t ion of differentiating relays is:

If there is a CT which is in the in state and there is no CT which is in the out state in the input CTs, the differentiating relay operates

For an over-current relay which has no directional speciality, the operation is described as follows:

An over-current relay operates if one of the input CTs takes a state other than zero or normal

In the transition network of a remote backup relay, the operated state is divided into two states, taking into account operational timing, as shown in Figure 8(c). One state means that the relay operates earlier than the other relay. This state is taken only when the operation of the selective relay is explained by exceptional operation caused by a time difference in the remote backup relay operations. This state is then expressed as a sensor fault state.

IV.4 A diagnostic example To compare diagnostic results for the simple and the detailed models, we used the accident case shown in Figure 10. In this sample network, bus E is not protected

by any relays. Figure 11 shows a partial output of the diagnosis.

Five diagnostic results are obtained for the simple model. The most plausible result among them is the multiple short-circuit faults occurring at AE-1L and E- 1 B, with malfunctions of the two relays of AE- 1L. This requires that multiple faults and relay malfunctions exist at the same time. However, this situation rarely occurs in the real world.

Fifteen results are generated for the detailed model. The most feasible solutions are shown in Figure 11. First, a short-circuit fault occurred at E-1B and the 44S2 (backup distance) relay of AE-1L operated faster than that of AE-2L. Then the 50S (selective) relay operated during this time difference. Second, a short-circuit fault occurred first at a part of AE-1L which is close to E-1B bus. Under this condition, the primary relays of AE-1L located at the side of the A bus cannot work through their mechanical behaviour. This is also taken into account in the detailed model. Then, the next short-circuit fault occurred at E-lB. Third, a short-circuit fault occurred at a part of E-1B which is inside the CT area that observes AE-1L. Under this condition, the primary relays of AE-1L located on the E-1B side operated. The fault propagated to AE-2L, because E-1B has no relays. Then the 44S2 relay of AE-IL at the side of E-1B operated. Then, the next short-circuit fault occurred in a part of AE-1L which is close to the E-1B bus.

More reasonable results are obtained for the detailed model. Because multiple faults and relay malfunctions for the simple model are interpreted as exceptional relay actions, exceptional operations or malfunctions which are described independently are combined in the diagnostic results. It seems that the diagnostic results correspond to the description level of the models. Therefore, the diagnostic power depends only on the precision of the models, because the same diagnostic tasks was used for these two models.

A-IB ~ ' I A-2B i J

AB-. AB-2, AG-. I IAG'2 -L G-2T" •

iLi B-IE 5OS

~ :~7 : 7,',,.,~ E-IB

II I ,: : Active retays

!Ji lli = D 18 breakers BC-IL BC- ~ '~ EF-IL~iili ilili EF-ZL D breokersOpen circuit

;1~ ,~1~ <'¢'('~'~', Discharoed - - ,~i ~i " " ' " " ' " ' : " equipment

C - I B r,,l.-,J ~,.~ F-IB

Figure 10. A sample fault case

Vol 14 No 2/3 April/June 1992 223

Diagnose

Pane-B ID = ANS~I Eva1= 1 tE

I I ¢ I

.k.l. T T

P a n e - 2 ID = RNS-4 Eva1= 4

Clear Data S e t Data

N e t w o r k Diagnos is S y s t e m

Show Answers Redraw Load Save

i } I . L ID = RNS-2

' ' I t

LL , T T T

B|plNI

- 3 1

lJ 44

TT

JDiagnosl s connand :

~ia I t u n t i l on l.b}

Figure 11. D iagnos is result

T T'

Edi t , Command

i i ¢ ¢

T T ° .

l]t aonn~ ~ _~ An~u~r~ TO Pan~" Fv~I F~ultPH ~nmnnnPnt.~ RNS-1 g 1 Short E-1B

Deta i led

i!

,T I T

RHS-2 1 3 Short RE-2L Hear EmlB, Short E-1B RNS-3 4 Short RE-2L Near E-1B, Short RE-1L Near E-1B RRS-4 2 4 Short E-IB Clo=e E-2CB, Short RE-2L Near E-IB RNS-5 G Short RE-2L, Short E-1B RNS-6 7 Short RE-2L, Short RE-1L Near E-1B RHS-7 13 Short EFm2L RNS-8 13 Short EF-1L RHS-g Z5 Short RE-2L Near E-1B, Short EF-2L RHS-I8 15 Short RE-2L Near E-IB, Short EF-IL RNS-II IB Short RE-2L, Short EF-2L RNS-12 iS Short RE-2L, Short EF-1L

~ fault

V. C o n c l u s i o n s This paper has proposed a development methodology and a shell MELDASH for model-based diagnosis of discrete-event systems. The domain model to apply MELDASH to network fault diagnosis is also explained. The simple model and detailed model of power networks are explained.

Next three advantages of the methodology and the shell MELDASH have been shown: (a) a diagnostic system can be constructed simply by inputting system models; (b) verification is easy because only the model must be checked; (c) the performance of the diagnostic system depends entirely on the level of detail of the model.

It is expected that the implementation, verification and maintenance of the system by MELDASH might be easy because of the use of high-level and task-specific building blocks of expert systems.

MELDASH is applied to a fault-restoration system in a joint research project with an electric power company. The prototype system is being tested by connecting with a power system training simulator. The target power system has about 1100 nodes and 1400 branches for power flow calculation. The number of components that have discrete states is about 11 000, and 166 causal rules

describe the functions of all kinds of component. Test results have shown that the prototype system can diagnose properly even in rare fault cases.

V l . R e f e r e n c e s 1 Chandrasekaran, B 'Generic tasks in knowledge-based

reasoning: high-level building blocks for expert system design', IEEE Expert Vol 1 No 3 (1 986) pp23-30

2 Bylander, T and Mit ta l , S "CSRL: A language for classifi- catory problem solving and uncertainty handling', AI Magazine Vol 7 No 3 (1986) pp66 77

3 Komai, K, i a t s u m o t o , K and Sakaguchi, T "Development method of knowledge based systems by integration of tasks', Trans. lEE of Japan Vol 109-C No 9 (September 1989) pp 645-652

4 Short l i f fe, E H Computer-based Medical Consultation: MYCIN, American Elsevier, N¥ (1976)

5 Davis, R 'Diagnostic reasoning based on structure and behavior', Artificial Intelligence Vol 24 (1984) pp 347-410

6 Genesereth, i R "The use of design descriptions in automated diagnosis', Artificial Intelligence Vol 24 (1984) pp411-436

7 Matsumoto, K, Komai, K and Sakaguchi, T 'DASH: A diagnostic application-specific expert systems shell', Tenth International Workshop on Expert Systems and their Appli- cations, Avignon, France (May 1990) pp 197-211

8 Peterson, J L Petri Net Theory and the Modeling of Systems, Prentice-Hall, Englewood Cliffs, NJ (1981)

224 Electr ical Power & Energy Systems

Documents

MELDASH: a diagnostic application-specific expert systems shell for network fault diagnosis