IEEE Transactions on Power Delivery, Vol. PWRD-2, No. 3, July 1987

AN EXPERT SYSTEM AS A DISPATCHERS' AID FORTHE ISOLATION OF LINE SECTION FAULTS

Kevin Tomsovic, Student MemberChen-Ching Liu, Member

Depart-ment of Electrical EngineeringUniversity of Washington

Seattle, WA

ABSTRACT

Between power circuit breakers at the twoends of a transmission line, automaticswitches have been installed in utilitysystems to sectionalize the line in case of afault. Often the operation of automaticswitches is not able to isolate the faultedsection exactly. In this situation, systemdispatchers need to apply reasoning and someheuristics to determine a set of actions whichwill isolate the faulted section precisely.An expert system to aid decision-making in anoperating center environment is developed inthis study. The required knowledge has beenobtained from discussions with dispatchers.Main issues in the expert system development,such as rule base organization, implementationin control center, interface with a database,and computational efficiency, are discussed.

1. INTRODUCTION

Faults may occur in transmission lines dueto stormy weather conditions, trafficaccidents, etc. Typically, each line isequipped with power circuit breakers on bothsides which are designed to trip within cyclesafter a fault occurs in order to protectequipment from damage. Transmission lines inthe 115KV range often have substation tapsbetween these power circuit breakers. Atripping of the breakers will lead tointerruption of customers supplied throughtaps along the faulted line. To minimize thepower interruption during the line faults, aneffective scheme is to install automaticswitches between some sections of the line.These switches are designed to close or opendepending on the status(hot or dead) of thecomponent(line or bus). Some types of theautomatic switching are: Open Dead Line (ODL),Close Dead Line (CDL), Close Hot Line (CHL),Open Dead Bus (ODB), Close Dead Bus (CDB),Automatic Transfer Dead Bus (ATDB) andAutomatic Transfer Dead Line (ATDL). Theswitches are provided with a delay timesetting for the operation. For example, ODL +4 seconds means that the switch is set to openfour seconds after a dead (deenergized) lineis detected. System designers can coordinatethe time settings among switches in order to

86 T&D 607-6 A paper recommended and approvedby the IEEE Substations Committee of the IEEE PowerEngineering Society for presentation at the IEEE/PES1986 Transmission and Distribution Conference,Anaheim, California, Septemnber 14 - 19, 1986.Mianuscript submitted March 21, 1986; made availablefor printing July 9, 1986.

Paul Ackerman and Steve PopePuget Operating Center

Puget Sound Power and Light Co.Bellevue, WA

achieve minimal power interruptionsspecified fault conditions.

under

Upon the occurrence of a fault, theoperation of supervised automatic switcheswill result in alarms presented to systemdispatchers. Unsupervised automatic switchesrequire communication from the field before adispatcher has an indication of the deviceoperation. In practice, dispatchers need toexamine the system configuration following thefault and possibly they will need to perform aset of test actions to determine the faultedsection. The decision-making process involvesreasoning based on system status, functions ofautomatic switches and empirical judgementsrelated to specific line conditions. Sincethe dispatchers also have to retrieve systemdata from handbooks and/or computer storage,the decision-making process can betime-consuming, depending on the complexity ofthe line and the fault event.

This problem solving approach followed bythe dispatchers, i.e. heuristics, operationalguidelines, etc., suggests an expert systemsolution. Expert systems applied to powersystem problems is a relatively new area ofresearch. In [1], Wollenberg proposed asystem for processing alarms in order toreduce the burden of unnecessary informationbeing supplied to dispatchers. A knowledgebased program for assisting in planning wasdeveloped by Fujiwara, et al. [2]. Liu andTomsovic suggested an expert system approachto incorporate heuristics and assist operatorson the reactive power/voltage management ofthe power system[3]. Talukdar, et al. [4],developed a system for diagnosing networkproblems; transmission line faults and/orrelay or breaker misoperations which canaccount for the observed initial and finalstate are determined. In this paper, wepresent an expert system for assistingdispatchers in a control center when linesections become faulted and automaticswitching is insufficient to maintain serviceto all customers on the line in question. Arule based representation was chosen since thedispatchers' knowledge could be expressednaturally in terms of rules.

The development of an expert systemconsists of a knowledge acquisition phase andan implementation of the gathered knowledge.Discussions with dispatchers at Puget SoundPower and Light (PSPL) Company, Bellevue,Washington, have identified the methodologyused to manage automatic switching. Theacquired knowledge is incorporated into a rulebase which has been partitioned into thevarious tasks needed to analyze a line faultproblem. In the proposed scheme, the expertsystem observes the power system by monitoringa database which is assumed to be updatedcontinually by SCADA operations. The rulebase has been implemented in OPS83, a

0885-8977/87/0700-0736$01.00O©1987 IEEE

736

737

production system language developed as asuccessor to OPS5. Extensive testing hasshown that the expert system is able tosuggest correct action in a variety of faultscenarios. Actual implementation in a controlcenter has not been attempted but thecomputing environment of the proposed expertsystem is made similar to that encountered inmodern operating centers.

The organization of this paper is asfollows: the computing environment for theexpert system is discussed in Sec. 2. Sec. 3presents the knowledge gleaned from systemdispatchers for analyzing problems arisingfrom line faults. Sec. 4 shows the detailsinvolved in implementing the gatheredknowledge. A brief comparison between theproduction system languages OPS83 and OPS5 ismade. Practical examples are presented todemonstrate the capability of the developedexpert system.

2. EXPERT SYSTEM IN OPERATING ENVIRONMENT

The structure of an expert system, i.e.knowledge contained in rules, is such that itprovides capabilities and features which aredifficult for conventional programmingtechniques to achieve. These capabilities andfeatures have been extensively discussed inthe literature[e.g. 5,6]. A number of expertsystems for power systems have been developed.However, the issue of embedding these expertsystems in a modern control center has notbeen thoroughly investigated. Existingcontrol centers typically have a number ofmainframes, a customized data base and anumber of application programs written intraditional languages, such as FORTRAN. Anexpert system can be most easily written inArtificial Intelligence languages such asLISP, Prolog, OPS5 and OPS83. Thus, softwarecompatibility is an issue. When compilers orinterpreters of the required AI languages areavailable for the control center hardware,then computational efficiency and the designof appropriate interfaces to existing softwaremust be considered. It may also be possibleto make specialized hardware additions, e.g. apossible approach to implementation for PSPLis to use a microcomputer and an interfacebetween the microcomputer and existingmainframes.

Fig. I shows the structure of the proposedexpert system within the modern control centercompuiting environment. The system has beenwritten in a production system language,OPS83. Specialized production systemlanguages, such as OPS83, provide manyfeatures which facilitate development of anexpert system. However, the *high level ofthese languages may present difficulties whencommunicating with other software. Asmentioned previously, other computer support,such as the SCADA system, is typically writtenin more conventional languages, e.g. on-linecode in assembly language and applicationsprogrammi ng i n FORTRAN. Communication betweenthese various processes must be established.For the application of this study, it isproposed that the expert system views thepower system by monitoring the database. As

Pfoblem Solvers

Fig. 1 Expert System in Operating Center Environment

alarms which indicate line faults are posted,the expert system gathers the most recent dataand begins to work on the problem withdispatchers. While the proposed expert systemis not actually implemented in the controlroom, this issue of interfacing an expertsystem to a database is addressed. The expertsystem has been developed on a VAX 11/780processor using the VMS operating system.Extensive discussions on database managementsystems (DBMS), and the literature containedwithin, can be found in [8,9]. The interfaceto the database will be discussed in light ofthe expert system development.

3. KNOWLEDGE ACQUISITION RESULTS

In this section, we present the knowledgeincorporated into the expert system. It isimportant to develop the expert system in asgeneral a framework as possible for severalreasons. To begin, portability to other powersystems can be achieved. Extensions of thecurrent solution approaches or expansions intonew problem areas will be straightforward.Furthermore, general rules simplifydevelopment in that fewer rules are needed togovern a class of problems.

Discussions with Puget Power dispatchershave identified the reasoning and severalheuristics which are typically utilized insolving the fault isolation problem. A fewassumptions are needed, and are listed here:

a) All power circuit breakers operateaccording to design and thus isolate theline fault to within a single line, i.e.the possibility of miscoordination is notconsidered.

b) All other automatic switching devicesfunction normally as well.

c) All faults are single line faults, i.e.no bus faults and not more than one faultedsection on any particular line.

d) All switches and breakers have reachedtheir final configuration, i.e. anyautomatic switching operations which aregoing to occur have already taken place.

e) Through SCADA or communication withfield personnel any device openings orclosings are known to the dispatcher andupdated in the system database.

These assumptions define the most commonscenarios that PSPL dispatchers face. As such

738

- Reclosure

- Closed

- Open

Customer

Customer2

A

2R10 & 15 Sec

CustomerI

Customer2

ODB + 7 Sec

Customer3

lR16 Sec

Fig. 2 Example System for Item (b) Fle

it was felt that assistanceoperating conditions wouldbeneficial. In the following,

Customer

Customer2

2R5 & 10 Sec

1R5 Sec

B B

g, 3 Examole System for Item (e) Fig. 4 Example System for Item (h)

during thesebe the mostwe identify a

number of the empirical rules our system isbased on:

a) The line fault must lie between openbreakers or switches.

b) For any unsuccessful breaker reclosures,the fault must lie between the breaker andthe nearest open device at the instant thereclosure is attempted. For the indicatedfault in Fig. 2, breaker 6 will attempt toreclose 16 seconds after the fault occurs.Before this attempted reclosure occurs, ODBswitch 4 will have opened, the breakerreclosure will be unsuccessful, whichimplies the fault must lie between devices4 and 6.

c) If any customer is without power and thefault location is not known precisely, thenin order to obtain further informationabout the fault location, testing of theline, i.e., opening or closing breakersand/or switches to attempt to restore thecustomer, may be considered.

d) Test closing a breaker or a switchshould not be done if a failure willinterrupt service to customers currentlywith power.

e) As many customers as possible should bebrought on line by any successful test. InFig. 3, one has several alternatives fortesting the line. For in-stance, supposeone decides to restore customer 1 andcustomer 3 by opening 3 and 6 and closing 1and 8. Then, the situation exists where anunsuccessful attempt to energize customer 2through either device 1 or 8 will interruptservice to a customer. Such aninterruption violates the previous rule,(d). According to rule (e), one shouldattempt to bring back all 3 customers inthe first test, i.e. open 7 and close 1 oropen 2 and close 8.

f) Stormy weather may result in a

Customer2

2

3

4

5

Fig. 5 Example for Item (k)

significant number of line outages. Inorder to maintain strong ties to the powersystem, dispatchers may be more aggressivein testing lines to avoid vulnerable systemconfigurations, including riskinginterruption of power to customerscurrently with service. It is assumed thatweather information is available.

g) When energizing a line which may befaulted, it is preferable to close abreaker into the line rather than switchingin load breaks or section switches which,in general, are more likely to be damagedby closure into a fault.

h) When attempting to restore a substation,supply power from the "stronger"source(end) of the line available. Thestrength of a source is a heuristicjudgement based on the amount of powertypically delivered through that end of theline. The stronger side often has morebreaker reclosures, in an attempt byplanning engineers to keep this source inservice. Consider the line in Fig. 4, ithas only circuit breakers for automaticswitching. For any fault that occurs onthis line, a dispatcher will have thechoice of supplying power through either ofthe two breakers. In the absence of otherinformation, switch 5 would be opened andbreaker 1 closed (instead of opening 2 andclosing 6) so that if possible customersare picked up through the stronger tie atA.

i) Substations usually have isolationswitches (e.g. switches 2 and 3 in Figs.2-4). The relatively short distancebetween these devices makes it highlyunlikely for a fault to occur on thesection of line connecting them.

j) 3-terminal lines can be analyzed bydividing the line into .2-terminal linesections, then selecting one of thesesections and proceeding as before. (A3-terminal line is terminated by threepower circuit breakers which encompass abranching point on the line, see Fig. 5).

R

739

k) Within a 3-terminal line, branches withsubstations are considered first forpurposes of locating the fault. In Fig. 5,barring other information, the linesections between B and C are consideredfirst.

1) Closing a switch into a fault puts atrisk of personal injury any persons whomight be in the vicinity of the line inquestion. Safety is of top priority.

m) Other specific line conditions affectthe priority of line testing. For example,faults on lines that run through busyintersections are often the result ofcar-pole accidents. Thus, it is likelythat there will be people in thesurrounding area and testing would not beappropriate.

n) A variety of miscellaneous informationis known to dispatchers, includingbehavioral information about specific powersystem components, SCADA operation, etc.

The proposed expert system also containsknowledge so as to enable dispatchers to workon several problems simultaneously. That is,the dispatcher can suspend work on a givenproblem in order to analyze other alarmedlines. The above empirical rules along withprocedural information extracted fromdispatchers form the knowledge base which hasbeen written as approximately 200 productionrules.

4. EXPERT SYSTEM DEVELOPMENT

In this section, we describe the design ofthe developed expert system. Sec. 4.1presents the programming strategy used forimplementing the knowledge presented in Sec.3. Relative merits of the productions system,OPS83, language is discussed in Sec. 4.2. Anapproach for interfacing to a database isshown in Sec. 4.3. The computationalefficiency of the system is considered in Sec.4.4 and finally the expert system validationis discussed.

4.1 Rule Base OrganizationConsistent with the goal of generality and

ease of modification for expert systems,certain techniques are employed inimplementing the aforementioned knowledge.For instance, the overall logical flow of thedeveloped expert system is to form ahypothesis of a single line fault and thenvalidate and analyze this conjecture furtherthrough reasoning and/or physical testing ofthe power system. In addition to thistop-level framework, rules are grouped undertasks (or goals). Table 1 identifies thesetasks for the proposed expert system whileFig. 6 gives an indication of how processingof a problem might proceed. Rules under eachtask are selected until the task is completedor until no more rules are applicable.

Undercan seeproblem,actions

the first task 'process alarms', onein Table 1 four subtasks: classifyresolve alarms, approve proposedand perform bookkeeping. The

Table 1 Tasks in Rule Base

TASK 1: Process AlarmsSubtasks: Classify Problem

Resolve AlarmsApprove Prosposed Actions

TASK 2: Form HypothesisTASK 3: Validate Hypothesis

Subtasks: Gather DataFormulate DataLocate FaultSet Up TestingAnalyze Test Results

TASK 4: Check TimingTASK 5: Test LineTASK 6: Suggest Solution

'classify problem' subtask determines that thealarms being received indicate a line problem.This information is passed to 'formhypothesis', Task 2, which will initiate thesearch for a solution. 'Approve proposedactions' allows the dispatcher to examine aset of actions the expert system recommendsbefore actual implementation of a solution forthe problem is to take place. Once a solutionhas been implemented, the system removes thosealarms that can be accounted for by thedetermined fault. Unresolved alarms are shownto the dispatcher for further consideration.'Bookkeeping' creates a log of information forutility records.

The formation of a hypothesis creates thethird task 'validate hypothesis'. 'Validatehypothesis' contains the bulk of the empiricalrules presented in Sec. 3. The first step isto gather relevant data, switch operations,substations on the line, etc., and put it in aform suitable for further analysis. If theline of interest is a 3-terminal one a2-terminal line representation is constructed.When data has been gathered, control is passedto the subtask 'locate fault'. 'Locate fault'is the central focus for verifying the linefault hypothesis. When automatic switching ispresent 'locate fault' posts Task 4, 'checktiming operations', which is used to furthernarrow down possible fault locations. As seen

Fig. 6 Solution Process In Fault Isolation

740

from empirical rule (c), testing may benecessary if the fault is not located exactly.If testing is necessary, subtask 'setup test'determines which switches or breakers need tobe opened or closed. Once all actions fortesting have been determined and approved bythe dispatcher 'test line', Task 5, performsthe test under the constraints on safetyprocedures and obtains the results of thetesting. The remaining procedure under'validate hypothesis' is to analyze the testresults. This analysis will also narrow downthe possible fault locations. It may happenthat more testing is needed depending on thecomplexity of the event. If at any point inthe process of looking for a single line faultan inconsistency is found, e.g. all possiblelocations are eliminated, a breaker fails torespond to a SCADA command, etc., thehypothesis is deemed invalid. If noinconsistency is found and the fault has beenlocated the 'validate hypothesis' task iscomplete.

Task 6, 'suggest solution', will determineany further actions which must be performed tocomplete isolation of the fault. A completeset of actions is presented to the dispatcherwhich the expert system believes will solvethe problem, dispatchers can utilize theseresults or rely on their own judgement. Thetask 'test line' requires implementation ofswitching actions by the dispatcher.

Notice, in the course of working on a taskit is often necessary to create subtasks whichdefine corresponding subproblems. Bysuccessively creating tasks and subtasks theproblem can be solved in stages similar to theprocess made use of by dispatchers. Insummary, two types of rules are embedded inthe system. One, those rules directinglogical flow, i.e. removing or establishingtasks. Two, those rules which representbehavioral information and form conclusions.Fig. 6 shows how the solution process flows inthe proposed expert system. One of the mainadvantages of expert systems is theflexibility in the solution process. In thisrespect, Fig. 6 could be misleading in that itappears that the solution process followsstep-by-step, similar to that in a FORTRANprogram. Actually, in a production system thesolution process is data driven. In otherwords, at each step the rule to be selected,and thus the action to be taken, depends onthe current working memory elements. Thewhole rule base will be searched (in anefficient manner) to find the specific rulesthat match the working memory data. Toemphasize this, a view of the logical flow ofthe system is shown in Fig. 7, where aconflict resolution scheme is required toselect the most applicable rule.

Data Conf I ictSet

SelectedRule

|Working Rul _ ConfIi ctMemory j Se-arch Resolution

1

Rule BaseTasks 1-6 (Table 1)

Fig, 7 Data-Driven Mechanism in Rule-Based Systems

Portability is accomplished byinicorporating general principles into the rulebase, leaving utility specific information inthe data base to the extent possible.

4.2 Selection of a Production System Languag0Specialized production system languages

such as OPS5 and OPS83 are effective tools fordeveloping expert systems[6]. They provide aninference engine, debugging routines and afast pattern matching (rule searching)algorithm. In this study, OPS83 has beenselected due to its flexibility andimprovements over its predecessor OPS5. Majorimprovements are briefly summarized here[7]:

1. OPS83 has simplified interfaces tosubprograms written in other languages suchas FORTRAN. This would be a majoradvantage in power system applications.

2. According to information from thedistributor, OPS83 is 30 times faster thanthe LISP based version of OPS5 and 4 to 5times faster than the BLISS based versionof OPS5.

The syntax of OPS83 rules is similar tothat in its predecessor OPS5. An example ruleis given below in English. The OPS83implementation is given in Fig. 8.

Rule l: (Related to rules b, c in Sec. 3)IF the task is to locate a single faultAND a substation is within the possiblefaulted sectionsAND no automatic switching lies within thepossible faulted sections (and therefore notiming information needs to be checked)THEN modify task to set up test switching

4.3 Database Interface

Power system control centers often havecustomized database systems. To address thedatabase issue of the expert systemimplementation we have chosen the relationaldatabase due to advantages of dataindependence, community view of common data,and simple data access in applicationprograms[8]. In particular, the relationaldatabase language used is UWRIM (University ofWashington Relational Information Management).

An approach for communicating between thedatabase and the expert system has beendeveloped. The essential problem in passingdata to the expert system arises from

{atask (task id-test-hypothesis;

status=locate. faul t; ) ;

&hypo (hypothesis id=single_fault;status-test; );

&fault (line fault status-radlal; );&sub (substation status=out;

from.--&fault.start; to-8&fault.end;);-(device automatic-yes;

location>-&fault. start;location.cafault.end; );

modify &task (status=setup-test; );

Fig. 8 OPS83 Implementation of Rule I

741

different data structures available in OPS83and FORTRAN (UWRIM is FORTRAN based). Morespecifically, symbolic (alphanumeric) data isincompatible. In FORTRAN, character stringsof fixed lengths provide the basis forsymbolic data. OPS83 relies on variablelength character strings called symbols. As asimple example, in FORTRAN the switch statusinformation 'closed' or 'open' could not beassigned to the same variable without addingblank characters as filler, i.e. 'closed' and'open '. OPS83 requires no such characterpadding. Thus for names and other descriptiveinformation, some data translation must beperformed. An efficient translation could beaccomplished by performing low leveloperations on data. Alternatively, and theapproach taken in this project, software maytranslate symbolic information into a standardformat readable by both programs. Thesimplest method is to use a temporary textfile. Since all programming languages providestandard input/output procedures for accessingdata in sequential text files, this approachaffords greater clarity and portability. Withthe issue of compatibility resolved, data canbe retrieved from the database by callingsubroutines which read from and write to atext file as a means of communication.

4.4 Efficiency Issues

The operator assistant we have proposed isintended for an on-line system andconsequently time efficiency is of importance.Keys are used in the database to improve dataaccess time. OPS83 itself has an efficiental.gorithm for pattern matching to enhance timeperformance. CPU time consumed in reaching asolution was measured to indicate theefficiency of the developed system. Whenthere are a number of lines which are faulted,it is important to consider how dispatchersapproached the problems. For example, it ismore time consuming to alternate the linefault which is under analysis. In our system,if one problem is worked to completion beforeconsidering other lines, the CPU time requiredfor each problem was less than 500 millisecswith approximately 250 millisecs of this timespent retrieving data from the database. Itis important to note that for large systemsthe database access time will increase butsince the consideration of line section faultproblems is restricted in a single line, thetime spent analyzing the fault will remainsmall. In other words, for large scalesystems the time bottleneck is expected to bethe database access.

4.5 Validation

It is often more difficult to evaluate theperformance of knowledge based systems thanconventional algorithmic software. For oursystem, a rule-based simulator of about 50rules has been built to facilitate thetesting. Dispatchers are relied on toevaluate the response of the expert system tovarious simulated fault scenarios.

5. SIMULATION RESULTS

Several case studies are presented toillustrate the capabilities of the developedexpert system. In the first example, adetailed analysis of the solution methodologyand the required empirical knowledge areidentified for clarification. For otherexamples, only the problem and the proposedsolution are provided here. In all cases, anysuggested actions require the dispatcher toimplement the action through SCADA or fieldpersonnel.

Case 1 (Fig. 9)

Faulted Section:

The line section between switches 874 and 485.

Final_configuration of protection devi ces:

Circuit breaker 361 openLoad break 483 openLoad break 794 openAll other devices are closedAnalysis:

This example illustrates a variety ofcapabilities in the present system. The'classify problem' task identifies thepresence of a line fault due to alarms on theopening of protection devices. The singleline fault hypothesis is then formed. Thefirst step in analyzing the problem is toretrieve data about the line in question. Inthis case, a 2-terminal line needs to beconstructed. Neither the branch to Starwoodnor to White River contains substation taps,thus either branch can be chosen and added onto the section leading from O'Brien to loadbreak 422. The branch to White River ischosen arbitrarily. Now, control passes tothe 'locate fault' subtask. The fault isfirst identified as lying somewhere betweenbreaker 361 and load break 794 (empirical rule'a'). Note that load breaks 794 and 483 openon a dead bus. Both devices would be openbefore the time of the second attempt toreclose 361. The 'check timing operations'task applies empirical rule 'b' and deducesthat the fault must lie between breaker 361and load break 483. 'Locate fault' eliminatesas a possible fault the line section betweenswitch 485 and load break 483 since it ishighly unlikely (empirical rule 'i') that thissection will be faulted. Testing is deemednecessary in order to determine whether tosupply power to the industrial customerWeyerhauser from White River/Starwood or fromnO'Brien (empirical rule 'c'). The systemsuggests supplying power from O'Brien as ates t .

If the attempt had been made to supplypower from White River and the test failed,power would be interrupted for customersBelmore and Kitts Corner thus violatingempirical rule 'd'. In this scenario, thetest from O'Brien would be successful.Subtask 'analyze test results' then eliminatesthe line sections between breaker 361 andswitch 874 as a possible faulted section sincethese sections have been successfullyreenergized. At this point, the fault

742

MARINE VIEW

BELMORE

KrTTS CORNER

ODB+ 8 SEC

ODB + 8 SEC

ODi. + 2 SECCHL + 3 SEC

IRI8 SEC

Fig. 9 O'BrIen-White River Linefor Cases 1 and 2

location has been narrowed down to the sectionof line separating switches 874 and 485. Withthis much known about the fault location, asolution can be suggested which will restoreall customers on the line. 'Suggest solution'indicates that load breaks 483 and 794 can beclosed to pick up substation Marine View. Thedispatcher has the option to accept or discardthis result. If the closures of 483 and 794are implemented, 'test line' serves to detectunexpected system response which may resultfrom inaccurate fault analysis. Lastly, anyrequired reports of the analysis are createdfrom the fault location information. Updatesto the database are made to show this linesection is under maintenance. In summary, theproposed actions are:

TsteQsOpen section switch 874Close breaker 361Test successful

Final solution:

The following actionssequentially:

s h o u l d be taken

Open section switch 485Close load break 794Close load break 483Status- Fault isolated between switches 874and 485.

Case 2 (Fig. 9)

Faulted Section:

The line section between switches 727 and 728.

ATOB +2 SEC

ODB +18 SEC

EVERGREEN

:KEN LWORTH

LAKEHILLS

UMIDLAKES

2R& 22 SEC

LAKESIDE

Fig. 10 SanuIsh-Lakeslde Linefor Cases 3 and 4

Final configuration of protection devices:

Load break 483 openLoad break 794 openAll other devices are closed

Final solution:

Fault is isolated between load breaks 794 and483. All customers have service. Note thatin this case switches 727 and 728 are neitherautomatic nor supervised. Since no customersare affected by the fault, no further testaction will be suggested.

Case 3 (Fig. 10)Faulted Section:

The line section between switches 287 and 866.

Final confi_qurationof-protection devices:

Switch 618 remains openLoad break 944 openAll other devices remain closed

Testing:

None- no testing can be performed withoutrisking power loss to customers with service.

Final solution:

Send field personnel to inspect line betweenswitch 618 and load break 944. Power is outat Lake Hills; other substations will beserved when all automatic switching actionsare complete.

743

Case 4 (Fig. 10)

Faulted Section:

Same as Case 3.

Weather:

High wind.

Finalconfjkuration of protection devices:

Same as Case 3.

T est i_g_Open section switch 287Close section switch 618Test successful

Final solution:

Fault is isolated between section switch 287and load break 944. All customers haveservice. The severe weather condition resultsin a test action whose failure will causeinterruption of Evergreen and Kenilworthsubstations.

6. DISPATCHERS' EVALUATION

The expert system was demonstrated to PSPLdispatchers a number of times in order toevaluate the system performance. Many of thedispatchers' comments related to theman/machine interface, for example usingfamiliar terminology and concise messages. Inall tested scenarios, the expert systemsuggested a correct solution. Comments fromthese demonstrations resulted in adding theability to handle multiple lines at the sametime. Dispatchers use their judgement as towhich line they want to work on first. Thisextension was deemed necessary since theexpert system would be most helpful duringabnormal weather conditions where severalfaulted lines may be expected.

In general, dispatchers are quiteenthusiastic about the developed expert systemand see several potential advantages forthemselves and customers. It was felt thatthe developed system could reduce tedious andredundant manual tasks and therefore shouldlead to efficient restoration in emergencyconditions. An immediate result is that theexpert system helps minimize customer outageduration. Even in situations where theproblem is simple, the expert system is usefulin that it serves as a double check for theirdecision. On the actual implementation incontrol centers, however, a primary concern ofdispatchers is to limit the amount of workthey must perforin to maintain system data byinputting untelemetered system information.The reason is that if they must spend asignificant amount of time entering data inemergency situations, the usefulness of theproposed system will be greatly reduced.

Research Institute, Palo Alto, CA, undercontract no. RP 1999-9. The authors wouldlike to thank Professors Mark Damborg andAlistair Holden for many helpful discussions,and Mr. Mike Hunter for facilitating theparticipation of Puget Operating Center inthis project.

8. REFERENCES

[1] B. F. Wollenberg, "Feasibility Study foran Energy Management System Intelligent AlarmProcessor", PICA conference, May 1985,pp.249-254.

[2] R. Fujiwara, T. Sakaguchi, Y. Kohno, andH. Suzuki, "An Intelligent Load Flow Enginefor Power System Planning", PICA conference,May 1985, pp. 236-241.

[3] C.C. Liu and K.L. Tomsovic, "An ExpertSystem Assisting Decision-Making of ReactivePower/Voltage Control", PICA conference, May1985, pp. 242-248.

[4] S.N. Talukdar and E.Cardozo, ArtificialIntell_ience Technololiies For Power F7iieOperations-- Some DemonstratioWTns An- d NnAssessment of pportunities Tina eport, P

[5] W.B. Gevarter, An Overview of EpertSystems, NBSIR 82-2505, Nati6naf- Bureau TStdanT ads, Washington D.C., May 1982.

[6] F. Hayes-Roth, D.A. Waterman and D.B.Lenat, Building Expert Systems, Addison-WesleyCo., 1983.

[7] C. Forgy, OPS83 Users Manual, ComputerScience Department, Carnegie-MellonUniversity, 1983.

[8] M. Damborg and S.S. Venkata, pecificationof Computer Aided Des in of -Transm-ssionProtecti-oWn-tems, Fnal Report EL-3337, 7V1764 6, EPRI, Jan. 1984.

[9] C.J. Date, An Introduction to Databasees, Vol. 1, 3rdE Tondi son-WesTey,

APPENDIX: NOTATION

ATDBATDLCDBCDLCHLHLRNO0DBODLRS

Automatic Transfer Dead BusAutomatic Transfer Dead LineClose Dead BusClose Dead LineClose Hot LineHot Line RecloseNormally OpenOpen Dead BusOpen Dead LineAutomatic ReclosingSupervisory

7. ACKNOWLEDGEMENT

This work is sponsored by Electric Power