See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/4055111

Automating power system fault diagnosis through multi-agent system

technology

Conference Paper · February 2004

DOI: 10.1109/HICSS.2004.1265190 · Source: IEEE Xplore

CITATIONS READS
86 460

4 authors, including:

Stephen McArthur J.R. Mcdonald

University of Strathclyde University of Strathclyde
207 PUBLICATIONS 5,611 CITATIONS 349 PUBLICATIONS 7,182 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by J.R. Mcdonald on 23 May 2014.

The user has requested enhancement of the downloaded file.

 Proceedings of the 37th Hawaii International Conference on System Sciences - 2004

Automating Power System Fault Diagnosis through Multi-Agent System

Technology

S. D. J. McArthur, E. M. Davidson, J.A. Hossack and J. R. McDonald

Institute for Energy and Environment, University of Strathclyde, Glasgow, UK.
[email protected]

Abstract classification [4] and the assessment of protection

performance [4][5] from digital fault recorder (DFR)
Fault diagnosis within electrical power systems is a data. Although these standalone intelligent systems
time consuming and complex task. SCADA systems, assist with particular aspects of the diagnostic process,
digital fault recorders, travelling wave fault locators manual intervention is still required to collate and
and other monitoring devices are drawn upon to interpret much of the information generated.
inform the engineers of incidents, problems and faults. During storm conditions DFR data can be
Extensive research by the authors has led to the particularly problematic. Firstly there is the problem of
conclusion that there are two issues which must be data overload; DFRs on circuits other than those
overcome. Firstly, the data capture and analysis directly experiencing a disturbance may trigger due to
activity is unmanageable in terms of time. Secondly, voltage dips caused by the fault, and generate fault
the data volume leads to engineers being overloaded records of no immediate interest. Secondly, there is the
with data to interpret. problem of lost data; when fault records are retrieved
This paper describes how multi-agent system by ‘autopolling’ it may be several hours before the
technology, combined with intelligent systems, can be DFR of interest is polled. If the transmission network
used to automate the fault diagnosis activity. Within experiences a large number of disturbances over a
the multi-agent system, knowledge-based and model- short period, records can be overwritten by the DFR’s
based reasoning are employed to automatically ‘rolling buffer’ before they have been retrieved for
interpret SCADA system data and fault records. These analysis.
techniques and the design of the multi-agent system While existing protection analysis tools can be used
architecture that integrates them are described. to analyse disparate data sources, the entire process,
Consequently, the use of Engineering Assistant agents including data gathering and timely presentation of the
as a means of providing engineers with decision information to engineers, requires automation.
support, in terms of timely and summarised diagnostic Recognising that Multi-Agent Systems (MAS) [6]
information tailored to meet their personal provide an effective means of integrating protection
requirements, is discussed. . analysis tools into a flexible and scalable architecture,
the authors have undertaken research concerning the
1. Introduction design and implementation of a MAS to meet the
requirements for comprehensive and automated post-
Protection engineers use data from a range of fault diagnosis for utility protection engineers. The
monitoring devices to perform post-fault disturbance multi-agent architecture resulting from this research is
diagnosis. The objective is to identify faults or entitled Protection Engineering Diagnostic Agents
disturbances on the power system and ascertain (PEDA) [7]. This paper describes PEDA, which was
whether or not the relevant protection schemes designed for deployment in a UK utility, SP Power
responded correctly. Through this, maloperation and Systems. The paper also briefly details how each agent
faulty components can be identified and the relevant performs its data interpretation.
action taken, e.g. review of protection settings. 2. Post-fault Diagnosis Using SCADA and
A number of useful protection analysis tools have Digital Fault Recorder Data
been developed by the research community to provide
assistance with the tasks undertaken during disturbance The most common situation where engineers
diagnosis, such as alarm interpretation [1][2][3], fault experience an overload of data is during or just after a

0-7695-2056-1/04 $17.00 (C) 2004 IEEE 1

 Proceedings of the 37th Hawaii International Conference on System Sciences - 2004

storm. For example, for a storm lasting 24 hours, SP Protection

Protection
ProtectionEngineering
Engineering
EngineeringDecision
Decision
DecisionSupport
Support
Support
Power Systems monitoring systems can generate in
excess of 15000 alarms and hundreds of fault records. Interpreted Validated Interpreted
Assessment of protection operation begins with SCADA Protection Provide Fault Records
analysis of the SCADA data, which allows engineers MBR Analysis
Protection of
Validation Interpreted Fault
DataRecord
to: & Diagnosis
DFR data Disturbance Interpretation
Preparation
• Identify power systems disturbances and the Fault Records
Indicate
circuits affected by the disturbance; and Disturbance
Fault Records
• Validate some aspects of protection operation, e.g.
KBS
Incident
Analysis
& Event
of Circuit affected by the Fault
FaultRecord
Record
missing protection or inter-trip alarms suggest that Identification
SCADA Retrieval
Retrieval
fault
part of the protection scheme may have failed to
operate. DialupDFR’s associated with
SCADA the fault and retrieve records
Protection engineers at SP Power Systems currently
use a Knowledge-based System (KBS), known as the
Transmission
Transmission Network
Network DFR 3
‘Telemetry Processor’ to automate the analysis of
SCADA and produce this information. DFR 1 DFR 2 SubC
cb3
Knowledge of which circuits have been affected by a DFR 3
particular disturbance can then be used to focus the cb1 R-Y-E
R-Y-E cb2
retrieval of the relevant fault records. Once retrieved, SubA Fault
Fault SubD
SubB cb4
the operation of protection can be assessed using
detailed timing information derived from the records.
The authors have developed a software-based set of Fig 1. Post-fault disturbance diagnosis using existing
tools for analysis. Each tool produces information that is
tools [8] which employs model-based reasoning valuable for decision support and information that can be
(MBR) to validate the operation of protection using a used to focus the next stage of the analysis of the data.
library of protection models. The tool-set propagates
the DFR data through a model of the protection scheme Figure 1 shows the entire post-fault diagnosis process
under test, compares the actual relay behaviour with using these tools. Earlier research by the authors
that predicted by the model and identifies any showed how integrating these tools could automate and
protection scheme components that may not have enhance decision support for engineers [5]. However,
operated correctly. traditional software architectures for integrating these
However, before the DFR data can be analysed different tools proved too inflexible for the following
using MBR techniques, it requires some processing. reasons:
The data has to be transformed from the COMTRADE • Integrating new data sources and analysis tools
format to the format used by the tool-set. The module could prove difficult due to the hardwiring of
that prepares the fault records also provides interfaces between tools; and
interpretation of the fault records, identifying the type • Dealing with intermittent communications
of fault and clearance times. between the different tools could be problematic.
This led the authors to investigate the use of multi-
agent systems to overcome these difficulties.
.

3. Integration Using Multi-agent Systems

Multi-agent system technology provides an ideal
means of achieving systems integration by ‘wrapping’
disparate systems as ‘intelligent agents’ (Fig. 2).

0-7695-2056-1/04 $17.00 (C) 2004 IEEE 2

 Proceedings of the 37th Hawaii International Conference on System Sciences - 2004

The facilitator agent is one of two utility agents in

IS
the PEDA multi-agent system. It acts as a yellow pages
and provides a list of all the abilities and resources
IS which the agents within the multi-agent system can
Intelligent
provide. A PEDA agents uses the facilitator to find
System IS
agents which can provide it with the information it
needs in order to perform its particular core task.
Reasoning Knowledge
IS
Messaging Functionality
IS
4.2. The Nameserver Agent

The nameserver agent is the second utility agent

Intelligent Agent Multi-agent System used by the PEDA system. It contains the network
Fig. 2. Using agent wrappers, legacy intelligent systems locations of all the PEDA agents. A PEDA agent can
can be ‘wrapped’ as agents and introduced multi-agent query the nameserver to ascertain the location of other
systems. Each of the functional modules in fig. 1 are agents with which it wishes to communicate.
wrapped as agents as in this figure.

4.3. Incident and Event Identification Agent

The agent wrapper provides the system being wrapped
with rules and knowledge enabling it to react within its
The incident and event identification (IEI) agent is
environment and automate its internal function and
tasked with processing SCADA data to identify
reasoning. By giving the agent this autonomy, it
‘incidents’ and ‘events’, terms which protection
possible to overcome the problems associated with
engineers at SP Power Systems wish to interpret from
intermittent communications between tools.
SCADA data. An incident is a grouping of alarms that
Agents communicate with each other using a
relate to a disturbance on a particular circuit. Events
standardised agent communication language (ACL).
are alarms or groups of alarms that make up a part of
The mulit-agent system presented in this paper uses the
an incident.
Foundation for Intelligent Physical Agents (FIPA)
Agent Communication Language [9]. The flexibility The core functionality of the IEI agent is provided
of FIPA ACL means that new agents can be introduced by the Telemetry Processor, a rule-based expert system
to an agent community relatively easily. designed to analyze SCADA data for protection
A detailed description of the methodology used for engineers. The telemetry processor uses inference
the design of PEDA can be found in [10]. The engines provided by the Java Expert System Shell
following section describes the PEDA architecture, (JESS) [8] in conjunction with three separate rule-
agents within the architecture and a brief description of bases. Each rule-base contains JESS rules, derived
how each agent performs its analysis of the data. from knowledge elicited from protection engineers,
which are fired by certain patterns of alarms (Fig. 3).
These rule-bases are used for incident identification,
4. Protection Engineering Diagnostic incident closure and event identification.
Agents
The PDA system currently consists of 6 core agents:
• a Facilitator agent;
• a Nameserver agent;
• an ‘Incident and Event Identification (IEI) agent
that ‘wraps’ the KBS used for the analysis of
SCADA;
• a ‘Fault Record Retrieval’ agent;
• a ‘Fault Record Interpretation’ agent that ‘wraps’
data preparation module of the MBR tool-set;and
• a ‘Protection Validation and Diagnosis’ agent that
‘wraps’ the tools used for the MBR analysis of the
DFR data
The functionality of each agent is described below.
4.1. The Facilitator Agent

0-7695-2056-1/04 $17.00 (C) 2004 IEEE 3

 Proceedings of the 37th Hawaii International Conference on System Sciences - 2004

Alarms Maintained in Buffer Incident Start JESS Engine

Alarm Buffer
4.3.1. Incident Identification. A single inference Management alarm
Rule-base
engine scans the alarms for patterns indicating incident buffer
inception, i.e. protection relay operation followed by a Identified
Alarms Added
circuit breaker opening. When a new incident has been Incident to Incidents Open Incidents
identified, an ‘open incident’ is created. Subsequent Population Incidents
alarms are then added to the appropriate ‘open Open
incident’ group based on time and topology. Check Closed Incidents
IncidentClosure
Incident ClosureJESS
JESSEngines
Engines
Incident Incidents
Closure Rule-base
4.3.2 Incidents Closure. Each ‘open incident’ has its
own inference engine that uses the incident closure Closed Incidents
Closed
rule-base to identify patterns of alarms indicating Incidents
incident conclusion. Once an incident has deemed to be Incident Event
EventsIdentification
JESS Engines
closed, for example by the identification of a Event JESS Engines
Checking Check Closed Incidents Rule-base
completed delayed auto-reclose sequence, the open for Events
incident is closed and passed on for event Incident
Incidents with Events
identification. Events

4.3.3. Identification of Events within Incidents. A Fig. 3. Telemetry Processor reasoning mechanism.
new inference engine is created for each closed
4.4. Fault Record Retrieval Agent
incident. Operating on the grouped incident alarms, the
inference engine uses the event identification rule-base
The principal objective of the fault record retrieval
to identify important alarms, provide summary
(FRR) agent is to poll available DFRs for new records
information and diagnose any faults indicated by the
and to prioritise retrieval based on incident information
alarms (Fig. 7).
received from the IEI agent.
The FRR agent has the ability to perform the
The output of the telemetry processor is made available
following tasks:
to engineers as a web page across the company’s
• monitoring device availability;
intranet.
• creation of a polling schedule;
Only minor modifications to the original telemetry
processor code were required to allow the IEI agent • selection of the next fault to be retrieved ;
wrapper to start the telemetry processor and output the • retrieval of a fault record; and
identified incidents and events in a suitable format. • rescheduling of the retrieval of a fault
The IEI agent wrapper was also designed to allow record.
other agents to subscribe for the incident information
the telemetry processor produces. The IEI agent can 4.4.1 Monitoring Device Availability. At present, to
refuse to provide subscription services to a requesting monitor device availability, the FRR agent reads a
agent by sending a ‘refuse’ message. This is based on database containing all possible sources and selects
permissions, to prevent inappropriate access to incident those categorised by engineers as available. In the
data. Successfully subscribed agents are informed of future a more accurate assessment of device
new incidents by the IEI agent, which sends messages availability will be achieved by monitoring the
that contain the new incident information. communications to remote DFRs.

4.4.2. Creation of a Polling Schedule. To create a

polling schedule, the list of available sources produced
by the previous task is used. The order of sources on
this list dictates the retrieval order.

4.4.3 Selection of the Next Fault Record to be

Retrieved. Only when all new records have been
retrieved from a particular DFR source will retrieval
move on to the next source.

4.4.4. Retrieval of a Fault Record. When a fault

record is to be retrieved, the FRR agent establishes the

0-7695-2056-1/04 $17.00 (C) 2004 IEEE 4

 Proceedings of the 37th Hawaii International Conference on System Sciences - 2004

connection and communications with the remote DFR trims fault records to have the same number of pre-
and initiates retrieval of any new records. When the fault samples.
records have been retrieved from the DFR they are The main component of the tool-set is the diagnostic
archived and the pathname of each retrieved fault engine (Fig. 4). The diagnostic engine is responsible
record held within the FRR agent. This enables the for running models, comparing data sets and
FRR agent to reply to external requests for fault computing diagnoses. Protection schemes and
records by forwarding a reference to the records component models are described in a set of XML
avoiding the need to pass large DFR records between (eXtensible Mark-up Language) documents which the
agents. diagnostic engine uses to co-ordinate the running of the
models and the flow of data between models. Since
4.4.5. Rescheduling the Retrieval of Fault there is a substantial base of protection models already
Records.If the FRR agent receives information from in existence [12][13][14], the diagnostic engine
either the IEI agent or a request for a record from supports flexible integration of different model types,
another agent, it has to reschedule and prioritise the running on different simulation platforms [15].
polling of the relevant fault recorders. Synchronized DFR Data
MATLAB
DPM
The execution of these tasks is controlled by a set of
XML Diagnostic Model
rules within the agent wrapper. The agent wrapper also Library
docs Engine
controls communication with other agents and
response to requests of other agents.
Diagnosis
4.5. Fault Record Interpretation Agent

The Fault Record Interpretation (FRI) agent ‘wraps’ Fig. 4. Model-based reasoning diagnostic engine draws on
a library of protection models to validate protection
the fault record interpretation module of the model- operation.
based reasoning tool-set [8]. As mentioned earlier in
this paper, DFR records require processing before they Once the diagnostic engine has calculated a
can be analysed using MBR techniques. diagnosis, this diagnosis is passed to a report generator
Similarly to the IEI agent, only minor modifications which produced a report in the form of a web-page that
to the original code were required to allow the agent can be viewed over the company’s intranet.
wrapper to control the fault record interpretation In a similar manner to the other agents, the agent
module. wrapper contains the appropriated rules and logic form
The FRI agent’s wrapper also controls the managing the control of the tool-set modules and the
prioritisation of the interpretation of the fault records. communication with other agents.
When a fault records is interpreted, in addition to the
processing required for the MBR tool-set, the fault
type, fault inception and clearance times are identified. 5. Case Study
To illustrate the PEDA approach to disturbance
4.6. Protection Validation and Diagnosis Agent
diagnosis an actual power system disturbance will be
used as a case study.
The protection validation and diagnosis (PVD) agent
‘wraps’ elements of a model-based reasoning tool-set,
these include: 5.1. PEDA Initialisation
• a fault record synchronisation module;
Before PEDA can commence with disturbance
• a diagnostic engine; and
diagnosis it must go through an initialisation phase.
• a protection validation report generator.
This involves the following stages:
In order to assess the performance of some protection
5.1.1. Registration with the Utility Agents. Each
schemes, e.g. unit protection or intertrip schemes,
agent must register their location with the Nameserver
records from more than one circuit end may be
Agent and the types of resources and abilities they can
required. As fault recorder often run on their own
provide with the facilitator.
internal clock, synchronisation of the DFR data may be
necessary. Using the fault inception as a common point
5.1.2. Subscription. The FRR, FRI and PVD agent
of reference, the fault record synchronisation module
each know that they need incident information in order
to perform their individual functions. Each agent sends

0-7695-2056-1/04 $17.00 (C) 2004 IEEE 5

 Proceedings of the 37th Hawaii International Conference on System Sciences - 2004

a query to the facilitator to find an agent that can offer SCADA Alarms and Indications
incident information. The facilitator replies that the IEI 13:54:14:720 SUBA SUBB Unit Protection Optd ON
13:54:14:730 SUBA SUBB Trip Relays Optd ON
agent can provide them with this information. Before 13:54:14:730 SUBF Battery Volts Low ON
the other agents can subscribe to the IEI agent for 13:54:14:750 SUBF Battery Volts Low OFF
13:54:14:760 SUBA SUBB Second Intertrip Optd ON
information, they have to find its location. They obtain 13:54:14:760 SUBA cb1 OPEN
this by querying the nameserver. Each agent then sends 13:54:14:790 SUBB SUBA Distance Protection Optd ON
13:54:14:800 SUBC T1 Trip Relays Optd ON
a message to the IEI agent requesting subscription for 13:54:14:800 SUBD Pilot Faulty ON
incident information. The IEI agent responds with a 13:54:14:800 SUBB SUBA Trip Relays Optd ON
13:54:14:810 SUBD Pilot Faulty OFF
message indicating confirmation, failure or refusal of 13:54:14:810 SUBB SUBA Unit Protection Optd ON
subscription. 13:54:14:810 SUBE Metering Alarms ON
13:54:14:820 SUBB cb2 OPEN
In a similar manner, the FRI agent has to subscribe 13:54:14:830 SUBA SUBB Autoswitching in Progress
to with FRR for information about retrieved fault 13:54:14:850 SUBC cb3 OPEN
13:54:14:860 SUBB SUBA Second Intertrip Optd ON
records. 13:54:14:860 SUBB SUBA First Intertrip Optd ON
Once the subscription process is complete PEDA can 13:54:14:890 SUBB SUBA
13:54:14:900 SUBC T1
Autoswitching in Progress
Autoswitching in Progress
start performing online disturbance diagnosis.
13:54:35:470 SUBC T3 Autoswitching Complete
5.2. Disturbance Diagnosis Process 13:54:35:490 SUBC cb3
13:54:37:710 SUBB cb2
CLOSED
CLOSED
13:54:38:210 SUBA SUBB Autoswitching Complete
A disturbance on the circuit between substation A 13:54:38:300 SUBA cb1 CLOSED

and substation B causes monitoring systems to DFR Records

produces the SCADA and DFR data in Fig 5. 13:54:14.740 DFR1 Triggered on Protection
13:54:14.740 DFR4 Triggered on low volts
DFR 2 SUB C 13:54:14.740 DFR5 Triggered on low volts
DFR 6
13:54:14.810 DFR2 Triggered on Protection
cb3 13:54:14.810 DFR6 Triggered on low volts
13:54:14.850 DFR3 Triggered on CB OPEN
SUB F cb2 DFR 3
SUB B T1
Fig. 6. Case Study Alarm and DFR data
DFR CT
Schematic
I
On entering PEDA, the IEI agent connects to the
DFR V
VT real-time SCADA alarms database and starts the
n Digital
Inputs
Analogue
DFR 1 telemetry processor interpreting the alarms. Given the
Inputs
cb1 alarm stream in Fig. 6., the incident identification rules
SUB A recognise the ‘Unit Protection Optd’, ‘Trip Relays
DFR 4 DFR 5
Optd’ and ‘cb1 OPEN’ alarms on the SUBA SUBB
SUB D SUB E circuit. These indicate the start of an incident.
Subsequent alarms received for that circuit are added
Fig. 5. Case Study – Transient Fault on circuit SUBA / to the incident grouping of the alarms. Incident closure
SUBB rules then interpret the incident alarms for incident
closure, recognising a complete autoswitching
sequence on the circuit. This closes the incident and
generates the incident summary indicated at the top of
Fig. 7. Event identification rules will then further
interpret the incident alarms and generate information
on events of interest to the engineers.

Incident: “13:54:14.720 SUB A / SUB B / SUB C Autoswitching Sequence Complete”

Events: 13:54:14.720 “Unit Protection Operated Successfully at SUBA -> SUBB

13:54:14.810 “Unit & Distance Protection Operated Successfully ay SUBB -> SUBA
13:54:14.860 “1st and 2nd Intertrips received at SUBB from SUBA
13: 54:38.300 “Distance Protection at SUBA -> SUBB failed to operate

Fig. 7. Output of the telemetry processor given the data in

figure 6.

0-7695-2056-1/04 $17.00 (C) 2004 IEEE 6

 Proceedings of the 37th Hawaii International Conference on System Sciences - 2004

Having identified an incident, the IEI agent’s message 6. Engineering Assistant Agents
handling rules will automatically inform all subscribed
agents of the new incident. In this case the FRR, FRI Previous sections have described the data
and PVD agents will each receive a message indicating interpretation achieved by the PEDA system. However
the date, time, circuit and a summary of the incident. problem of data overload is not exclusive to protection
Having subscribed to the IEI agent, the FRR engineers. Engineers in operational and asset
Reschedule Retrieval task is executed, prioritising management roles often have to use information
retrieval of records from DFRs on the same circuit as produced by a number of different systems e.g. asset
the incident, i.e. DFR1, DFR2 and DFR3. The retrieval management databases, fault reporting systems and
process may take anywhere from tens of seconds to condition monitoring systems.
several minutes depending on the quality of the The authors are researching Engineering Assistant
communications to the remote fault recorders. Agents (EAA) as a means of providing engineers with
The FRI agent also receives the incident information information tailored to meet their requirements given
and queries the FRR agent to see if it has the fault their role in the business. Each engineer would have
records related to the incident. Since retrieval is still their own personal engineering assistant agent which
underway, the FRR agent replies with a message they would keep locally on their PC. The agent would
indicating that the fault records are not yet available. act as a personal interface to the company’s
As a result the FRI agent sends a message to the FRR information systems.
agent requesting the retrieval of the required fault
records. When the FRR agent has completed retrieval
from the requested devices a message is sent to the FRI 6.1. User Modelling
agent informing it of completed retrieval
To obtain the fault records retrieved from DFR1, Each EAA maintains a ‘user model’ of it owner. The
DFR2 and DFR3, the FRI agent sends a message to the purpose of the user model is to capture the engineer’s
FRR agent requesting the retrieved fault records. The responsibilities and operational functions. Based on
FRR agent then sends a message containing the this knowledge, the EAA could proactively and
location of the fault records to the FRI agent, which adaptively provide its user with information relevant to
then schedules interpretation of the records. particular business role.
The PVD agent also received the same incident Rather than simply using set profiles for different
information message as the FRR and FRI agents. types of engineer, the EAA would employ machine
Therefore, it proceeds to obtain the interpreted fault learning techniques to track the users interests over
records from the FRI agent. At this point in time the time; as a particular business role changes, then the
FRI agent will have requested, but not received, the engineer may become less or more interested in certain
fault records from the FRR agent. The PVD agent will information.
then send a ‘request’ message to the FRI agent When new agents are added to the agent community,
requesting interpretation of fault records from DFR1, the EAA is responsible for informing its user about the
DFR2 and DFR3. When the FRI agent has received information which is available. Using the user model,
and interpreted the fault records a ‘confirm’ message is the agent will be able to decide whether or not its
sent to the PVD agent in response to each ‘request’ owner may be interested in that data, If it lacks
message. knowledge on user preference it may communicate
To obtain the requested records the PVD agent sends with other EAAs whose users have similar roles, to see
a message to the FRI agent. The FRI agent responds if their user was interested or not.
with a message containing the paths to the fault record. 6.2. Engineers Assistant Agents within PEDA
Once the PVD agent has obtained all the fault records
required, it runs the diagnostic engine and generates a The authors are currently developing a prototype
protection validation report. engineer assistant agent that acts as an interface with
For the example in the case study the protection PEDA. In addition to protection engineers, asset
validation module found that all protection components managers, field engineers and those responsible for
operated correctly. Given that the telemetry processor administering the PEDA (IT support) are interested in
diagnosed the failure of distance protection to operate some of information PEDA provides. Field engineers
(Fig.7), further investigation may be required, e.g. may, for example be interested in the incident
review of the protection settings. information provided by the telemetry processor,
whereas this may be of less interest to asset managers.
On the other hand, asset managers may be interested
on statistics collated on correct/faulty protection

0-7695-2056-1/04 $17.00 (C) 2004 IEEE 7

 Proceedings of the 37th Hawaii International Conference on System Sciences - 2004

operation. IT support engineers may wish to be Protection Engineering Diagnostic Assistance”,

informed of any fault record retrieval problems. IEEE Transactions on Power Systems, Vol. 18, no.
When the EAA enters the PEDA community it can 2, May 2003.
use the facilitator agent to discover what information [8] E. Davidson, S.D.J. McArthur, J.R. McDonald, “A
Tool-Set for Applying Model Based Reasoning
the PEDA agents can provide. The user is presented Techniques to Diagnostics of Power Systems
with a list of this information and picks the ones he/she Protection”, IEEE Transactions on Power Systems,
is interested in. The EAA then subscribes with the Vol. 18, no. 2, May 2003.
PEDA agents for the appropriate information. When [9] “FIPA Communicative Act Library Specification”,
the other agents generate relevant information, it is XC00037H, Available:
automatically sent to the EAA (Fig. 8). http://www.fipa.org/repository/index.html
In the future the EAA may also be used to retrieve [10] S.D.J McArthur, J.R. McDonald, J.A. Hossack “A
data from fault reporting systems and asset multi-agent approach to power system disturbance
management databases. diagnosis” Book Chapter in Autonomous systems
and intelligent agents in power system control and
operation (ed. Christian Rehantz) Springer Verlag
Engineering Engineering 2003
Assistant Assistant
[11] E.J. Friedman-Hill, “Jess, The Java Expert System
Shell”, http://heerzberg.ca.sandia.gov/jess, version
6.1a5, 15th January 2003.
[12] A. Dysko, J.R. McDonald, G.M. Burt, J. Goody, B.
Protection Fault Record Gwyn, “Integrated
Validation Interpretation
Modeling Environment A Platform For Dynamic
Protection Modelling And Advanced
Functionality”, IEEE Power Engineering Society
Transmission and Distribution Conference, April
Incident/Event Fault Record
Identification Retrieval 1999
[13] M. Kezunovic, S. Vasilic, "Advanced Software
Environment for Evaluating the Protection
Fig. 8. Engineering assistant agents introduced to the Performance Using Modeling and Simulation,"
PEDA system
CIGRE SC 34 Colloquium Sibiu, Romania,
September 2001.
7. References [14] P.G. McLaren, C. Henville, V. Skendzic, A. Girgis,
M. Sachdev, G. Benmouyal, K. Mustaphi, M.
[1] Z.A. Vale, and M.F. Ferandes, “Better KBS for Kezunovic, Lj. Kojovic, M. Meisinger, C. Simon,
real-time applications in power system control T. Sidhu, R. Marttila, D. Tziouvaras, "Software
centers: the experience of the SPARSE project”, Models for Relays" IEEE Transactions on Power
Computers in Industry, vol. 37, pp. 97 –111, 1998. Delivery Vol. 16, No. 2, pp. 238-246, April 2001
[2] J. Jung, C-C. Liu, M. Hong, M. Gallanti, G. [15] S.D.J McArthur, E.M. Davidson, G.W. Dudgeon,
Tornielli, “Multiple Hypotheses and Their J.R. McDonald “Towards a model integration
Credibility in On-Line Fault Diagnosis”, IEEE methodology for advanced applications in power
Transactions on Power Delivery, v16, n2, April engineering” IEEE PES letter August 2003
2002, pp 225 – 230.
[3] J.H. Hossack, G.M. Burt, J.R. McDonald, T.
Cumming, and J. Stoke, “Progressive Power
System Data Interpretation and Information
Dissemination”, in Proc. 2001 IEEE Transmission
and Distribution Conference and Exposition.
[4] M. Kezunovic, I. Rikalo, B. Vesovic, S.L. Goiffon,
“The Next Generation System for Automated DFR
File Classification”, Fault & Disturbance Analysis
Conference, May 1998.
[5] S.C. Bell, S.D.J. McArthur, J.R. McDonald, G.M.
Burt, et. al., “Model Based Analysis of Protection
System Performance”, IEE Proc. Gen. Trans. &
Dist., vol. 145, n 3, pp 547-552, 1998.
[6] M. Wooldridge, et al, “Intelligent Agents: Theory
and Practice”, The Knowledge Engineering
Review, vol. 10, n 2, pp. 115-152, 1995
[7] .J.A. Hossack, J. Menal, S.D.J. McArthur, J.R.
McDonald, “A Multi-Agent Architecture for

0-7695-2056-1/04 $17.00 (C) 2004 IEEE 8

View publication stats