A logic programming approach to fault diagnosis in distribution ring networks

A logic programming approach to fault diagnosis in distribution ring networks

Electric Power Systems Research, 15 (1988) 77 - 87 77 A Logic Programming Approach to Fault Diagnosis in Distribution Ring Networks K. P. W O N G * ...

794KB Sizes 2 Downloads 21 Views

Electric Power Systems Research, 15 (1988) 77 - 87

77

A Logic Programming Approach to Fault Diagnosis in Distribution Ring Networks K. P. W O N G *

and C. P. T S A N G * *

*Department of Electrical and Electronics Engineering and **Department of Computer Science, University of Western Australia, Nedlands, W.A. 6009 (Australia) (Received February 22, 1988)

ABSTRACT

The prime objective in the operation o f a distribution system is to supply power to the customers and to meet their load demands. Whilst the probability o f fault in high voltage and extra high voltage networks is low, the chance o f fault in distribution networks is relatively high. When a fault occurs in a distribution network, it must be identified and removed immediately so that power can be restored as soon as possible. This paper develops a logic model for diagnosing faults in distribution ring networks. Methods in the model for representing network configurations, faults, symptoms o f faults and defects are presented. Fault-finding rules are developed from the relations between the faults and their symptoms, including the effects o f hidden defects due to battery failures and open-circuited pilot-wire circuits in the feeder protection systems. A logic program is developed based on the logic model and it is implemented by a goal-directed language, Prolog. The power o f the logic program system for fault diagnosis is demonstrated through its application to an 11 k V distribution network.

1. INTRODUCTION

When a fault occurs in a distribution ring network, it must be located and isolated immediately so that power supply can be restored to the loads and the outage time reduced. Operations engineers are usually involved in diagnosing the fault from known or reported fault s y m p t o m s given by the tripping of circuit-breakers. From the known symptoms, engineers determine the location of the fault using a human reasoning prodess. 0378-7796/88/$3.50

Whilst this method is satisfactory, the human reasoning process is not always reliable and some factors such as defects in batteries and pilot-wires may be overlooked. The fault finding process can be very time consuming. One of the ways to reduce the fault-finding time is to use the table look-up method. In this method, tables relating fault s y m p t o m s to different fault types are predetermined and tabulated manually. However, when all possible faults and defects are considered, the tables becomes very large and complex. Hence the process is still susceptible to human errors. Moreover, different tables have to be established for different network configurations. In practice, distribution network topology changes frequently owing to network modification and there can be a large number of different configurations. This method then requires many tables to cover all the possible network configurations and it may not be practical. Recently, rule-based expert system methodology [1, 2] has been applied to extra high voltage network fault diagnosis [3, 4] and to other areas such as power system planning [5], control of reactive power and voltage level [6] and control room alarm processing [7]. The application of logic programming methods [8] to fault diagnosis in distribution ring networks has not been attempted. Based on the logic programming approach, this paper develops a logic model for diagnosing faults which may occur in distribution ring networks. The model includes the representation of network topologies, network components, faults, defects and symptoms. Using the cause and effect reasoning, rules for diagnosing feeder faults, busbar faults and t r a n s f o r m e r faults are developed and implemented b y a goal-directed language, Prolog [8]. The developed Prolog program can be executed- in a 'forward' manner for © Elsevier Sequoia/Printed in The Netherlands

78

diagnosing faults from a set of known symptoms. It can also be executed in a 'reverse' manner to find symptoms from a specified fault. The usefulness and power of the software are demonstrated through its application to the problems of fault diagnosis in an 11 kV distribution ring network.

2. FAULTS, SYMPTOMS AND DEFECTS

Closed ring distribution networks are normally adopted for supplying power to highly populated areas and to major load centres because of their high degree of power supply security. Figure 1 shows a typical 11 kV ring circuit configuration. Power is delivered to the ring networks 'a' and 'b' through the 132/11 kV transformers T1 and T2 respectively. Each ring circuit can have two, three or four parallel feeder circuits and each feeder circuit is protected using pilotwires. Each parallel circuit is also protected b y an overcurrent relay. The overcurrent relay is installed on the busbar of the 11 kV substation. Power is supplied to the loads through the distribution transformers in the ring circuits.

T2 ~

132/IikV

2. I. Fault types and symptoms The various types of fault that may occur in the ring networks are busbar fault, feeder fault and transformer fault. When a busbar fault occurs in network 'a' of Fig. 1, the symptoms are indicated by the tripping of the circuit-breakers at locations A, B, and C due to the action of the overcurrent relays in the substation. When a fault occurs in a feeder, the circuit-breakers at both ends of that feeder will normally discriminate the fault: Under normal conditions, a transformer fault at location D in Fig. 1, for example, will be isolated through the opening of the transformer circuit-breaker. Fault s y m p t o m s given by the tripping of circuit-breakers are the usual direct consequences of a fault occurring in a network. In the rule-based system approach, the symptoms are resolved into faults b y the use of a set of complex production rules. These symptoms are then matched to the rules which produce some fault events or combination of fault events. The fault events are then further resolved into other fault events. The process terminates when a set of suspect faults is found. One of the problems with this approach is that the rules can be extremely

TI~ 132Jllkv

11 kV substation

rear busbar A

B

front busbar

9

~

m

L :o other [IkV system closed ring 'b

closed ring 'a' tO other llkV system

Fig. 1. Typical 11 kV substation and ring networks.

79 complex when hidden defects are included. As for the table look-up method, this approach requires a large number of rules to exhaust all the possible fault occurrences and combinations of symptoms.

2.2. Defects Defects such as battery failures and opencircuited pilot-wires may exist in a network system without warning. When there is a fault in the network, the defects give rise to a set of symptoms which is different from that expected in their absence. In the network in Fig. 2, if there is a short-circuit fault in feeder cd and there is a battery defect at c, the feeder breaker at c will remain closed, although the circuit-breaker at d on feeder cd will trip. This then causes the overcurrent relays to operate the circuit-breakers at locations j and m. A transformer fault at c will not be isolated if the battery at c is defective. When the pilot-wire in the protection system of feeder gh is on open-circuit, a feeder fault on cd will lead to tripping of the circuit-breakers at locations c and d as well as that of the two breakers on feeder gh.

3. R E P R E S E N T A T I O N S

The fault-finding rules are to be developed in §4. In this section, a brief summary of the Prolog syntax is given and the execution of llkV

f

substation busbar

j

c

R

b

Fig. 2. A s a m p l e d i s t r i b u t i o n ring n e t w o r k .

ta

Prolog clauses described. This is followed b y the methods developed to represent networks, faults, defects and symptoms.

3.1. Prolog clauses and execution The Prolog notation adopted in the present work follows the Edinburgh Prolog syntax [8, 9]. Constants are indicated by identifiers starting with a lower case character. Variables are identifiers beginning with an upper case character. A Prolog program clause has the following form:

A :- B1,..., Bn.

(i)

where the A and B are predicates and the symbol :- takes the meaning 'if'. The predicate A is called the head and the predicates to the right of :- comprise the body. The meaning of the program clause in (1) is: If all the B predicates are true, then the head predicate A is true. A predicate consists of an identifier which begins with a lower case character and a list of first-order terms [8] as arguments. The clause in (1) is sometimes referred to as a rule. If the b o d y of the clause is empty, then the head predicate will always be true and the clause is called a fact. Alternatively, a clause without a head is called a goal. The aim of executing a Prolog program is to find an instantiation of the variables such that the goal is true. During execution, the truth values of the subgoal predicates B are evaluated in the sequence of their appearance. A subgoal B is unified with another clause having the same head in the same program b y unification [10, 11]. Unification is the method of finding the instantiation of variables in the terms such that t h e y are identical to each other. When the unification is successful, the subgoal B is replaced b y the b o d y of the unified clause and its variables are instantiated. The evaluation process is then applied to the subgoal predicates in the unified clause. This procedure is repeated until all the subgoal predicates in the original goal clause have been evaluated and it is referred to as the depth-first search strategy [10]. If the current subgoal is false, the subgoal immediately prior to it has to be re-evaluated before the current subgoal is evaluated again. This evaluating procedure is called backtracking [10]. The depth-first search, backtracking and unification are the

80 basic execution mechanisms in the Prolog language [8]. These mechanisms and their properties are fully exploited in the subsequent development of the representation of the networks and the generalized fault-finding Prolog rules in this paper.

3.2. Network representation In some earlier works [12], the representation of a network either uses individual connectivity facts or a list of connected nodes. This representation is lengthy and may lead to human errors in describing the network topology. A new approach to the representation of networks and the components in the networks is developed below. The busbars in a ring network are represented by nodes and the parallel feeder circuits are represented b y legs. Each leg consists of a sequence of nodes. The nodes in a leg are connected together in a linear string b y edges. A feeder in a network is identified b y an edge which is represented b y the term u+v, as shown in Fig. 3. The atomic symbols such as u and v are used to represent the nodes whilst the diadic operator + is employed to represent the connectivity between any two nodes. The structure of the complete network is represented b y the facts o f the legs in the network. Using the above methods of representation, the 11 kV tl~ree-leg ring network in Fig. 2 is described b y the following facts: network(a+b+c+d+e+f). network(a+g+h+i+j). network(a+k+l+m).

(2a) (2b) (2c)

, busbar

feeder

feeder

transformer

breaker

v+w

busbar

v

v-u

breakerLu-v

breaker

feeder

w

t

Overcurrent relays are represented b y nodes. To distinguish overcurrent relays from busbars, extra facts are required. The additional facts for the network in Fig. 2 are: overcurrentrelay(f). overcurrentrelay(j). overcurrentrelay(m).

(3a) (3b) (3c)

At each busbar location, there are t w o feeder breakers and one transformer breaker. A transformer breaker is represented b y the node name of the busbar to which it is connected and a feeder circuit-breaker is represented by u--v. The expression u - - v further indicates that the circuit-breaker is located at the end u of feeder u+v. Figure 3 shows this method of representation.

3.3. Representation of fault, defects and symptoms Feeder faults are represented by the names of the edges of the faulty feeders. For example, a+b denotes a feeder fault on the feeder between nodes a and b. A fault on a busbar is represented b y the node name of that faulty busbar. A defective battery is named b y the node name of the busbar to which it is located. An open-circuited pilot-wire in the protection system of a feeder is represented by the name of the edge connecting t w o adjacent nodes. Thus, a pilot-wire defect given b y g+h means that the pilot-wire between nodes g and h is on open-circuit. S y m p t o m s are described by the names of the circuit-breakers and the overcurrent relays which have operated and they are grouped in a s y m p t o m list. The s y m p t o m list [c--b, j, m], for example, indicates that the circuit-breaker c--b and the overcurrent relays j and m in the network of Fig. 2 have operated.

4. FORMULATION OF FAULT DIAGNOSIS feeder

u+v

busbar

u

feeder

t+u

busbar

t

Fig. 3. Representation of network and components.

Essential to the fault diagnosis formulation are the rules which relate the faults to the symptoms. In the following development of the fault-finding rules, it is assumed that only a single fault may occur at any one time. The effects of a single battery failure and a single pilot-wire open-circuit defect on the symptoms are included.

81

4.1. Feeder faults Under normal conditions, a fault on a feeder gives rise to tripping of the circuit-breakers at the feeder terminals. A Prolog clause, feederfault, describing this can be defined as feederfault(X+Y, S) :- innet(X+Y),

only(S, X--Y, Y--X).

(4)

In clause (4), the predicate innet checks that the feeder X+Y is in the network under examination. If it is true, then the predicate only checks that the symptoms in the symptom list S are the only symptoms. For a fault on feeder X+Y, the symptoms must only be the tripping of breakers X--Y and Y--X. However, this clause is invalid when there is a battery defect on either node X or node Y, regardless of whether there is a pilot-wire open-circuit defect or not. The clause in (4) is therefore modified to feederfault(X+Y, S, B, P) :- innet(X+Y),

only(S, X--Y, Y--X),

B=nil.

(5)

in which the sign = denotes the unification of the terms on both sides of the sign. The symbols B and P designate a battery failure and a pilot-wire open-.circuit defect respectively.

4.1.1. Inclusion of pilot-wire defect With a pilot-wire open-circuit defect in the protection system of feeder U+V, a fault on feeder X+Y causes breakers X--Y, Y--X, U--V and V--U to trip, provided that the batteries at nodes U and V are sound. The clause, defect, for this is defect(X+Y, S, B, P) :- innet(P), not match(P, X+Y), member(V--U, S), B=nil.

P=U+V,

member(U--V, S), (6)

where the predicate not match checks that the feeder with a defective pilot-wire denoted by the value of P is not the faulty feeder X+Y and that the pilot-wire is U+V. The member predicates then confirm that the tripping of the breakers U--V and V--U is in the symptom list S. When there is a battery failure at end U of the defective pilot-wire U+V, the circuit-breaker U--V will remain stable. The defect clause implementing this is defect(X+Y, S, B, P) :- innet(P),

B\==Y,

not match(P, X+Y), member(V--U, S).

P=U+V,

B=U,

B\==X, (7)

where symbol \== denotes that the terms on the two sides of it are not equivalent. Similarly, the effects of a battery defect at node V can be accounted for by the defect clause below: defect(X+Y, S, B, P) :- innet(P), not member(P, X+Y), B\==Y, member(U--V, S).

P=U+V,

B=V,

B\==X, (8)

Using the symbol ; for 'or', clauses (6) - (8) can be combined to give defect(X+Y, S, B, P) :- innet(P), not match(P, X+Y), P=U+V, ((member(U--V, S), member(V--U, S), B=nil); (B=U, B \ = = X , B \ = = Y , member(V--U, S)); (B=V, B\==X, B \ = = Y , member(U--V, S))).

(9)

The rule for finding a feeder fault with the effects of a battery defect at either end of a defective pilot-wire can therefore be formed as feederfault(X+Y, S, B, P) :- innet(X+Y), member(X--Y, S), defect(X+Y, S, B, P).

member(Y--X, S),

(10)

Combination of the feederfault clauses in (5) and (10) then gives: feederfault(X+Y, S, B, P) :- innet(X+Y), ((only(S, X--Y, Y--X), B=nil); (member(X--Y, S), member(Y--X, S),

defect(X+Y, S, B, P))).

(11)

82

4.1.2. Battery defect at a feeder terminal A battery defect may exist at either end of a feeder on which there is a fault. For a fault on feeder c+d in Fig. 2 and a battery defect at node c, the breaker d--c will open and breakers j and m will trip owing to the detection of the fault currents in circuits jc and mc b y the overcurrent relays at j and m. The symptoms at j and m can be found b y a search procedure nodesearch which searches the network nodes starting from node c. This procedure will be developed in the next subsection. The Prolog rule for finding a feeder fault with a battery defect at either end of the feeder can be established as feederfault(X+Y, S, B, P) :- innet(X+Y), cases(X, Y, X1, Y1), member(X1--Y1, S), B=Y1, nodesearch(Y1, [X1], S, B, P).

(12)

The predicate cases in clause (12) accounts for the fact that a battery defect may exist at node X or Y of the feeder X+Y. Denoting the node having a defective battery b y Y1 and the other node b y X1, the tripped circuit-breaker is X1--Y1, as shown in the member predicate. Owing to the battery failure at Y1, which is represented by the predicate B=Y1, the breaker Y I - - X l remains closed. This leads to identical symptoms as those in the case of a fault at node Y1 excluding those which appear in the circuit between node X l and the substation busbar. To find the symptoms, the search procedure nodesearch is called in clause (12) with node Y1 as the starting node from which the search begins. S y m p t o m s introduced by a hidden pilot-wire defect in the circuit being searched can also be found b y nodesearch. The clauses (11) and (12) form a complete set of fault-finding rules for a feeder fault.

4.2. Searching network nodes for symptoms Figure 4 shows a tree graph of the feeder circuits of a ring network from a fault node or a node at which there is a battery defect to the substation busbar where the overcurrent relays i, j, k and 1 are located. To determine the operational status of the overcurrent relays, the nodes in the tree are to be searched until all the overcurrent relays are found. The following Prolog clause searches for a neighbouring node, Z, of node X: nextneighbour(X, L, Z) :- innet(X+Z),

not member(Z, L).

(13)

where L is a list of nodes which have previously been searched. The innet predicate utilizes unification in Prolog to instantiate Z from the network facts. For the tree in Fig. 4, when node X is node a, node Z can be node b, node c, or node d. fault

node

or node

-b~

m

with

battery

defect a

Jcl substation - " busbar

Fig. 4. Tree graph of a ring network (i, j, k and 1 are overcurrent relays).

83 Starting at node X, symptoms in one trace of the tree between X and the substation busbar are determined by using the following recursive procedure: nodesearch(X, _, S, _, _) :- overcurrentrelay(X),

!,

nodesearch(X, L, S, B, P) :- nextneighbour(X, L, Z),

member(X, 8). !,

(14)

nodesearch(Z, [XIL], S, B, P). (15)

The search in clause (15) is terminated by clause (14) when an overcurrent relay is found and its related symptom is included in the list 8. The symbol ! in the last two clauses is a control mechanism called the 'cut' which prevents backtracking from occurring. The symbol _ in the argument of clause (14) indicates that this clause is independent of the values of the variables L, B and P. To search all the branches in the tree, an extra level of recursion is introduced in clause (15) as follows: nodesearch(X, L, S, B, P) :- nextneighbour(X, L, Z), !, nodesearch(X, [ZlL], S, B, P).

nodesearch(Z, [XIL], S, B, P), (16)

The above clause can either be terminated by clause (14) or by the clause below when all the nodes in the tree are searched: nodesearch( . . . . . . . . .

).

(17)

4.2.1. Inclusion of pilotowire defect As outlined in §4.1.1, when a pilot-wire defect X+Z exists in the feeder protection system, extra fault symptoms will appear depending on the following cases. (a) The breakers X--Z and Z--X will trip when there is no battery defect at X and Z. (b) The breaker Z--X will trip when the battery at X is defective. (c) The breaker X--Z will trip when the battery at Z is defective. The symptoms due to a pilot-wire defect in (a), (b) and (c) above can be incorporated in clause (16) as in nodesearch(X, L, S, B, P) :- nextneighbour(X, L, Z),

!,

((P=X+Z), ((nonvar(B), B\==X, member(X--Z, S), B\==Z, member(Z--X, S)); (B=X, member(Z--X, S)); (B=Z, member(X--Z, 8)))); nodesearch(Z, [XlL], S, B, P)), nodesearch(X, [ZlL], S, B, P).

(18)

The built-in predicate nonvar tests whether B is instantiated or not. Clauses (14), (18) and (17) then give the complete recursive search procedure including the effects of pilot-wire open-circuit and battery defects.

4.3. Busbar and transformer faults When a fault occurs at any busbar in a ring network, fault currents will flow along all the feeder circuits to the faulty busbar. The feeders will be overloaded and the overcurrent relays in the substation will operate. These symptoms can be determined b y the nodesearch clauses. Prior to the use of these clauses, any busbar under investigation must be a node in the network. This can be checked by the clause below: node(X) :- setof(A, Y^innet(A+Y), N),

member(X, N).

(19)

The setof predicate in the above clause is a built-in predicate in the Prolog interpreter and it assembles all the nodes of the network in list N. The m e m b e r predicate is used to verify that node A is in the given network. Using clauses (14) and (17) - (19), a busbar fault can be found from

84 busfault(X, S, B, P) :- node(X),

nodesearch(X, [ ], S, B, P),

not overcurrentrelay(X).

(20)

In the nodesearch predicate in (20), node X is the starting node from which the search begins. The list L is initially set to null. As a substation busbar is not considered to be a busbar in a ring network, it is excluded b y the use of the not overcurrentrelay predicate in clause (20). For a fault on a transformer, the transformer circuit-breaker will trip. When a battery failure exists on the busbar to which the transformer is connected, the breaker will remain closed, leading to a similar fault condition as a busbar fault. A fault-finding rule for a transformer fault can therefore be established as trfault(X, S, B, P) :- node(X). ((S=[X], B=nil); (B=X, nodesearch(X, [ ], S, B, P))), not overcurrentrelay(X).

(21)

5. RESULTS AND EXECUTION OF THE LOGIC PROGRAM The fault-finding rules and network representation developed in §§3 and 4 are completely general and can be applied to ring networks of different topologies. For different configurations, only the network facts (2) and (3) in §3.2 need to be modified. In this section, the developed logic program is applied to the 11 kV distribution network in Fig. 2.

5.1. Finding faults from symptoms One of the main applications of the developed logic program is for diagnosing faults in ring networks from a given list of symptoms. For the network in Fig. 2, if a s y m p t o m list [c--b, j, m] is given, then the location of the feeder fault can be determined by querying the system with the following goal: ?- feederfault(X, [c--b, j, m], B, P). After the execution, the system returns an instantiation of the variables as in X=b+c,

B=b,

and

P=_

This is one of the solutions. The value of X indicates a fault on feeder b+c and that of B denotes a battery defect at node b. However, there is no pilot-wire defect since P is uninstantiated. The solution is correct because the battery defect at busbar b prevents breaker b - - c from tripping and, as a result, circuit-breakers at j and m are tripped b y the actions of overcurrent relays at those locations. The feeder circuits between nodes c and f carry no fault current because breaker c - - b has tripped. Similarly, queries can be made b y using the goals busfault and trfault for diagnosing busbar and transformer faults. To find all the possible faults which may occur in the network, the faultfinding rules for the three types of faults can be combined to form a new clause, findfault, as follows: findfault(S, LF, BF, TF, B, P) :- (feederfault(LF, S, B, P); busfault(BF, S, B, P); trfault(TF, S, B, P).

(22)

The values of the variables LF, BF and TF denote the locations of the feeder fault, the busbar fault and the transformer fault respectively. For the last set of symptoms, all the possible faults and their associated defects can be found b y executing the following goal: ?-findfault( [c--b, j, m], LF, BF, TF, B, P). Table 1 summarizes the nine fault solutions generated b y the system. The first solution is a feeder fault and is identical to the one found previously. All possible busbar faults are given in the second to eighth solutions in the Table. These faults have a c o m m o n battery defect in busbar b

85 TABLE 1 Sample of s o l u t i o n s f r o m the goal findfault Fault type

Feeder

Busbar

Transformer

Battery defect

Pilot-wire defect

Feeder

b+c

--

--

b

--

Busbar

Transformer

--

1

--

b

b+c

--

k

--

b

b+c

--

a

--

b

b+c

--

i

--

b

b+c

--

h

--

b

b+c

--

g

--

b

b+c

--

b

--

b

b+c

--

--

b

b

b+c

and a c o m m o n pilot-wire defect along feeder b+c. With the same defects, the last solution is a transformer fault at busbar b. F r o m these results, it can be deduced that there must be a battery failure in node b and that a pilotwire defect in the protection system of feeder b+c is highly probable.

5.2. Finding symptoms from faults Another application of the developed logic program is to find all the s y m p t o m s and the associated defects from a specified fault by executing it in a 'reverse' manner. For a fault on feeder b+c in the network of Fig. 2, the symptoms and defects can be found b y the following query: ?- findfault(S, c+b, nil, nil, B, P). In this enquiry, LF is set to c+b. Busbar and transformer faults are excluded from the query b y setting BF and TF to nil. There are 45 solutions found b y the system and t h e y are summarized in Table 2. The first solution corresponds to the normal case that breakers c - - b and b - - c trip to discriminate the fault on feeder b+c. When there is a battery defect in b, breaker c - - b will operate, b u t breaker b - - c will remain closed. Fault currents will then flow along circuits ab, ja and ma. The overcurrent relays at j and m will therefore operate. This is shown in the second solution in Table 2. The s y m p t o m s in the third solution are due to the given fault condition and a battery defect at node c. The remaining solutions can be grouped into t w o classes. The first class of 31 solutions is due to the combined effects on the feeder fault b+c and the possible defects which are not located at the faulty feeder or its nodes. The

second class of 11 solutions shown in Table 2 comprises the s y m p t o m s due to the fault with a battery defect at either end of the faulty feeder and a pilot-wire open-circuit defect.

5. 3. Other applications Whilst the findfault clause in (22) can be viewed as a definition of the relationships among all its arguments, it can be queried with some of its arguments initially instantiated as in the two applications described in §§5.1 and 5.2. In general, some, all or none of the variables in the arguments of findfault can be instantiated before it is called. The Prolog clauses (4) - (21) in §4 have been developed to satisfy this specific requirement b y careful consideration of the use of the control facilities [8] and negation [11] in Prolog. Owing to the generality of the developed system, it can also be applied to generate tables which relate the different fault t y p e s to the s y m p t o m s and the defects as required in the table look-up approach discussed in §1. Another application of the developed system is to diagnose faults from incompletely specified symptoms. This is achieved b y forming a new goal consisting of findfault with no instantiation and a predicate subsettest which is used to filter off those solutions not related to the specified symptoms. If the tripping of breaker b - - a is the only known symptom, for example, all the possible faults can be found from ?- findfault(S, LF, BF, TF, B, P), subsettest( [ b - - a ] , S). The system then returns the fault solutions in which the tripping of breaker b - - a is an element of the s y m p t o m list S. From the

86 TABLE 2

6. CONCLUSIONS

Symptoms and defects for a fault on feeder bc of Fig. 2

A general logic formulation for fault diagnosis in distribution ring networks has been developed and it has been implemented using the logic programming language Prolog. The network representation method outlined in this paper is completely general and highly flexible. Any change in the network topology can be accompanied by changing the network fact clauses. The method of describing the structure of the networks exploits the associativity and the non-evaluating properties of the Prolog terms, such that explicit and complicated search procedures for network busbars and feeders are avoided. The behaviour of a distribution ring network under a feeder fault, busbar fault or transformer fault has been formalized into the relations between a fault and its symptoms. These relations have been expressed in the form of Prolog faultfinding rules in §4. The effects of hidden battery and open-circuited pilot-wire defects in the network system have also been included. When a list of s y m p t o m s is specified, the logic program system in this paper not only identifies the fault, but also determines all the possible faults and defects which may occur in the network. In this way, the possibility of failing to detect a possible fault is minimized. The execution time required for finding the solutions in the sample test case of §5.1 was 15 s on a VAX 750 computer. The present system can also be used to generate all the possible symptoms and defects associated with a given fault condition. The value of this fault diagnosis system is twofold. Firstly, it can be employed as a fault diagnosis aid to operations engineers for rapid identification of a network fault. Secondly, it can be used as a training aid for inexperienced engineers. Although the logic program in this paper has been written in C-Prolog [9] and has been run on a VAX 750 computer, it can easily be implemented b y commercially available Prolog interpreters which run on personal computer systems.

Symptoms

Battery defect

Pilot-wire defect

[e--b, b--e]

--

--

[ c - - b , j , m] [b--c, f]

b c

---

-e f -d e --

e+f e+f e+f d+e d+e d+e e+d

[c--b, [c--b, [c--b, [e--b, [c--b, [c--b, [e--b,

b--c, b--c, b--c, b--c, b--c, b--c, b--c,

e--f, f - - e l f--e] e--f] d--e, e--d] e--d] d--e] c--d, d--e]

[c--b, b--c, c--d]

d

c+d

[c--b, [c--b, [c--b, [c--b, [c--b, [c--b, [c--b, [c--b, [c--b, [c--b, [c--b, [c--b, [c--b, [c--b, [c--b, [c--b, [c--b, [c--b, [c--b, [c--b, [c--b, [c--b, [c--b,

b--c, b--c, b--c, b--c, b--c, b--c, b--c, b--e, b--c, b--c, b--c, b--c, b--c, b--c, b--c, b--c, b--c, b--c, b--c, b--c, b--c, b--c, b--c,

-a -i j -h i -g h -a g -1 m -k l -a k

a+b a+b i+j i+j i+j h+i h+i h+i g+h g+h g+h a+g a+g a+g l+m l+m l+m k+l k+l k+l a+k a+k a+k

[c--b, [c--b, [c--b, [c--b, [c--b, [c--b, [c--b, [e--b, [b--e, [b--c, [b--c,

a--b] a--g, g--a, m] g--h, h--g, m] h--i, i--h, m] i--j, j - - i , m] j, a - - k , k - - a ] j, k - - l , l - - k ] j, l - - m , m - - l ] d--c ] d--e, e--d] e--f, f - - e I

b b b b b b b b e c c

a+b a+g g+h h+i i+j a+k k+l l+m d+e d+e e+f

a--b, b - - a ] b--a] i--j, j - - i ] j--i] i--j ] h--i, i - - h ] i--h] h--i] g--h, h - - g ] h--g] g--h] a--g, g - - a ] g--a] a--g] l--m, m--l] m--l] l--m] k--l, l--k] l--k] k--l] a--k, k--a] k--a] a--k]

ACKNOWLEDGEMENTS

solutions, the likelihood of a certain fault or defect can be estimated b y counting the number of its occurrences. This is particularly useful in some practical situations when a complete list of symptoms may not be available.

The authors are grateful to S.K. Ho of the China Light and Power Company Limited, Hong Kong, for his valuable discussions. This research work was supported b y a grant from the Electrical Research Board, Australia.

87 NOMENCLATURE

S y m b o l s f o r variables in Prolog clauses X+Y

X--Y S B P L LF BF TF

n a m e o f e d g e in n e t w o r k r e p r e s e n t i n g feeder or pilot circuit between busbars X and Y name of circuit-breaker at end X of feeder X+Y list o f f a u l t s y m p t o m s defective battery defective pilot-wire list o f n e t w o r k nodes previously searched feeder fault busbar fault transformer fault

REFERENCES 1 F. Hayes-Roth, D. A. Waterman and D. B. Lenant, Building Expert Systems, Addison-Wesley, Reading, MA, 1983. 2 B. G. Buchanan and E. H. Shortliffe, Rule-Based Expert Systems, Addison-Wesley, Reading, MA, 1985. 3 S. N. Talukdar, E. Cardozo and T. Perry, The

operator assistant - - an intelligent, expandable program for power system trouble analysis, IEEE Trans., PWRS-1 (3) (1986) 182 - 187. 4 I. Sugiyai and K. Ishikawa, Knowledge realization and transformation in KRISP, in E. Wada (ed.),

Proc. 4th Conf. on Logic Programming '85, Springer-Verlag, Berlin, 1985, pp. 299 - 311. 5 R. Fujiwara, T. Sakaguchi, Y. Kohno and H. Suzuki, An intelligent load flow engine for power system planning, IEEE Trans., PWRS-1 (3) (1986) 3 0 2 - 307. 6 C. Liu and K. Tomsovic, An expert system assisting decision-making of reactive power/voltage control, IEEE Trans., PWRS-1 (3) (1986) 195 201. 7 B. F. Wollenberg, Feasibility study for energy management system intelligent alarm processor, IEEE Trans., PWRS-1 (2) (1986) 241 - 247. 8 W. F. Clocksin and C. S. Mellish, Programming in Prolog, Springer-Verlag, Berlin, 1981. 9 F. Pereira (ed.), C-Prolog Manual Version 1.5, Edinburgh Computer Aided Architectural Design, University of Edinburgh, 1986. 10 N. J. Nilsson, Principles of Artificial Intelligence, Tioga, Palo Alto, CA, 1980. 11 J. W. Lloyd, Foundations of Logic Programming, 2nd edn., Springer-Verlag, Berlin, 1987. 12 W. D. Humpage, K. P. Wong and T. T. Nguyen, Prolog network-graph generation in system surveillance, Electr. Power Syst. Res., 9 (1985) 37 - 48.