IEEE TRANSACTIONS ON POWER SYSTEMS, VOL. 18, NO.

2, MAY 2003 639

A Multiagent Architecture for Protection

Engineering Diagnostic Assistance
John A. Hossack, Student Member, IEEE, Judith Menal, Stephen D. J. McArthur, Member, IEEE, and
James R. McDonald, Member, IEEE

Abstract—Protection engineers use data from a range of moni- McArthur et al. [5] have demonstrated how integration of
toring devices to perform post-fault disturbance diagnosis. In the standalone alarm processing and protection validation intelli-
past, heterogeneous intelligent systems have been developed to in- gent systems can significantly enhance the overall data interpre-
terpret the data and provide information to engineers to assist with
the disturbance diagnosis task. The majority of these systems re- tation functions performed by each system. Although possible,
main standalone due to the problems associated with systems in- integration of standalone systems (each with their own informa-
tegration. This paper proposes the use of multiagent systems for tion representation and protocols) can prove to be a significant
providing a flexible and scalable alternative to existing integration and time-consuming undertaking. Furthermore, traditional in-
approaches. tegration approaches can require significant development effort
A novel multiagent system (MAS) has been developed entitled
protection engineering diagnostic agents (PEDAs) which integrates and limit overall scalability and flexibility.
a legacy SCADA interpretation system with new systems for Dig- An alternative to traditional integration approaches is offered
ital Fault Recorder (DFR) record interpretation and for enhancing by multiagent systems (MAS) which provide standardized com-
fault record retrieval from remote DFRs. The use of MAS tech- munications and protocols between individual software mod-
nology provides a flexible and scalable architecture open to the in- ules called “agents” [6]. Numerous flexible and open archi-
troduction of new data interpretation systems. The paper discusses
the benefits of a multiagent approach and the design and imple- tectures can be implemented due to the provision of common
mentation of PEDA. system wide intergent communications. These integration ben-
efits are being realized by research into a novel MAS for pro-
Index Terms—Cooperative systems, decision support systems,
fault diagnosis, intelligent systems, knowledge-based systems, viding disturbance diagnosis assistance to protection engineers
power transmission protection. entitled Protection Engineering Diagnostic Agents (PEDA).
Adopting a multiagent approach has enabled a legacy alarm
interpretation system to be effectively and easily integrated
I. INTRODUCTION along with newly developed systems for automating and
optimizing fault record retrieval and interpreting retrieved
P ROTECTION engineers are one of the principal groups
using power system monitoring data. It assists with dis-
turbance diagnosis so that the root cause of a disturbance can
fault records. This integration of diverse systems within PEDA
allows timely automated disturbance diagnosis to be achieved
be determined or incipient problems identified. This requires an within a flexible and scalable architecture.
experienced engineer to undertake the retrieval, collation, and The paper commences with a summary of the disturbance
interpretation of data from a variety of sources. diagnosis process followed by a discussion on automation of this
Many in the research community have conducted research process and associated issues. The design process adopted for
concerning intelligent systems to assist engineers with data in- PEDA is then presented followed by a discussion on the agents
terpretation. Intelligent systems like those developed by Vale et currently within PEDA. Finally a case study using actual power
al. [1] and Burrel et al. [2] provide decision support assistance system data is presented to illustrate PEDA functionality and its
to control engineers by interpreting SCADA. Interpretation of associated benefits.
Digital Fault Recorder (DFR) records, to assist protection en-
gineers with fault classification and protection validation, have II. DISTURBANCE DIAGNOSIS
also been provided by intelligent systems developed by the au- Power system disturbance diagnosis is a laborious process un-
thors in [3] and [4]. The majority of existing systems, except dertaken post-disturbance by protection engineers. Each stage in
those developed by McArthur et al. [5], are standalone inter- the manual approach is illustrated in Fig. 1[7].
preting a single data source using a particular artificial intelli- Disturbance diagnosis commences with gathering of SCADA
gence (AI) technique. from around the time of a disturbance followed by manual inter-
pretation to identify the disturbance incident and related events.
Incidents can be considered as a grouping of alarms relating
to a disturbance on a particular circuit over a specific time pe-
Manuscript received September 6, 2002. This work was supported in part by
the Power Systems division of ScottishPower plc. U.K. riod. Events are a more focused look at what actually happened
The authors are with the Institute for Energy and Environment, during an incident (i.e., protection and plant operations). The
University of Strathclyde, Glasgow, U.K. (e-mail: john.hossack@ disturbance incident helps focus later data retrieval and interpre-
strath.ac.uk; nau95713@strath.ac.uk; s.mcarthur@strath.ac.uk; j.mcdonald@
eee.strath.ac.uk). tation by identifying the location and nature of the disturbance
Digital Object Identifier 10.1109/TPWRS.2003.810910 (e.g., transient circuit fault).
0885-8950/03$17.00 © 2003 IEEE
640 IEEE TRANSACTIONS ON POWER SYSTEMS, VOL. 18, NO. 2, MAY 2003

iii) Interpret retrieved DFR records

• extract key indicators of disturbance type (e.g.,
fault type, clearance times).
iv) Analyze protection performance
• validate protection operation;
• diagnosis protection failures.
Fig. 1. Manual approach to power system diagnosis. The task modeling process also generated a task hierarchy,
illustrated in Fig. 2, representing the tasks required to achieve
Given the disturbance location, the engineer identifies addi- required functionality. Note that only those tasks associated with
tional data sources in the disturbance vicinity that may contain the functions currently addressed by the research presented in
pertinent data and initiates retrieval (e.g., DFRs). Retrieval can this paper are included, hence the tasks associated with analysis
be a time-consuming and problematic task due to the large vol- of protection performance are omitted.
umes of data which must be retrieved from remote sources over In addition to the functional requirements and tasks, it was
sometimes unreliable communications. also noted from the knowledge elicitation that the following
Depending on data type, the engineer then commences fur- system requirements must also be met
ther data interpretation thereby increasing the amount of useful • timely notification of, and access to, information should
disturbance information. be provided;
It is clear that to perform disturbance diagnosis, engineers • intermittent availability of device communications, addi-
not only require access to data sources but also the experience tion of new data sources, removal of obsolete technologies
necessary to operate the associated retrieval software and the and integration of new systems should be effectively dealt
knowledge necessary to interpret the retrieved data. with.

III. AUTOMATED DISTURBANCE DIAGNOSIS B. Integration Issues

Providing an automated means of performing disturbance di- It is clear that a number of systems are required to retrieve
agnosis assistance would significantly reduce the data retrieval and interpret data in order to perform the required functions.
and collation burden on protection engineers. Furthermore, integration of existing legacy and future systems
must be achieved in a flexible and scalable manner.
A. Requirements The first systems integration problem comes when trying
Preliminary discussions with six protection engineers from to establish inter-system communications due to each system
the utility sponsoring this research indicated that, although pro- having proprietary communications languages. The next
viding welcomed assistance, the existing intelligent systems tri- problem is how to overcome different data and information
aled within the utility over the last decade did not adequately ad- representations. For example, in the context of SCADA alarms
dress the overall disturbance diagnosis requirements. Note that “protection” may refer to a particular type of alarm whereas in
each engineer had considerable experience in performing dis- a DFR context it may refer to the data recorded on a particular
turbance diagnosis and the design, implementation, and moni- channel in the DFR record. To overcome this data representa-
toring of protection. tion problem a common vocabulary must be developed, or a
Knowledge engineering, specifically the KADS method- translation mechanism established, so each system understands
ology [8], was used to capture a complete list of requirements what the other is referring to. An additional problem is that the
and the knowledge required to perform disturbance diagnosis integrated architecture is effectively closed to the integration
from these six engineers. This knowledge, once captured, was of new systems. This is mainly due to the requirement for each
then used to ascertain the tasks required to perform automated system to be effectively “hard-wired” to the other systems with
disturbance diagnosis and, consequently, the required function- which communication is required.
ality. Despite these problems, integration of intelligent systems has
The knowledge transcripts produced from a series of knowl- been successful [5]. However providing enhanced information
edge elicitation meetings were analyzed and task models gen- provision through integrated intelligent systems proves inflex-
erated illustrating the required tasks and disturbance diagnosis ible and nonscalable due to the significant development effort
functions, namely required for integration.
i) Perform SCADA interpretation
• identify incidents; C. Multiagent Systems (MAS)
• group incident related SCADA; MAS offer an effective solution to the limitations associated
• identify incident events. with the current approaches to systems integration by offering
ii) Assist with DFR retrieval a common communications language [6]. Each system can
• manage automated polling of DFRs and retrieval of be thought of as an “agent” operating within a community of
new records; agents, namely the MAS. An agent can be considered as a
• prioritize retrieval of records from DFR’s in the piece of software or system with enough intelligence to manage
vicinity of an incident to avoid records being over- its own processes and communications with other agents.
written by new data. Through a process of inter-agent communication, each agent
HOSSACK et al.: A MULTIAGENT ARCHITECTURE FOR PROTECTION ENGINEERING DIAGNOSTIC ASSISTANCE 641

Fig. 2. PEDA task hierarchy and agent assignments.

can cooperate to provide all the benefits of systems integration interpretation systems can require extensive redevelopment
in a flexible and open manner. work to integrate legacy systems. This problem is overcome
The agent research community has produced a number of within a MAS by “wrapping”’ agent functionality around the
standard Agent Communications Languages (ACLs) for MAS, legacy system and implementing it as a task within the agent
most notably Knowledge Query and Manipulation Language [9]. More detail on how agent tasks are realized by wrapping
(KQML) [9] and Foundation for Intelligent Physical Agents legacy systems is provided later.
(FIPA) ACL [10]. Common to each language is the separation It should be clear from the above discussion that MAS
of message type from message content. Message types have offer significant advantages over conventional integrated and
been standardized and specify the message intent, for example, distributed systems. The major advantage is the flexibility and
“inform” and “request.” These instructions can be considered open nature of a MAS architecture compared to the rigid and
as “human-speech” acts reflecting the ways humans obtain, closed nature of the majority of conventional integrated and
provide, and exchange information and indicate to an agent distributed systems. This advantage is due to the presence of
receiving the message how to deal with the content. In an utility agents and the system wide use of a common ontology
engineering context, “inform” and “request” could relate to the and “human-speech” acts enabling the interchange of informa-
passing of data between agents, where the message content tion. Therefore, the agents will be able to make use of condition
contains the information. The vocabulary, or “ontology,” used monitoring and fault analysis systems deployed in the future
for message content is left up to the MAS developer who will without any knowledge of their functionality.
specify a language which represents all of the core domain Some of the benefits associated with MAS have already been
terms (e.g., protection, circuit breaker, and fault record). exploited within the power industry through the ARCHON
One benefit offered by MAS is the distribution of agents [12] and COMMAS projects [13]. The ARCHON project
allowing for distribution of processing overheads, however this culminated in a MAS architecture for integration of reasoning
creates an information discovery problem (i.e., how do agents systems within a control room environment, however, the
within the MAS know what other agents are available and what environment was not truly flexible or scalable. The COMMAS
abilities/resources they can offer?). Conventional distributed project examined the application of MAS within condition
systems and integrated systems overcome this by hardwiring monitoring of gas turbines, transformers, and gas insulated
acquaintance knowledge into each system, which limits the switchgear (GIS), demonstrating how MAS can be used to
flexibility and scalability of the environment. MAS offer a enhance plant condition monitoring.
more effective solution by providing utility agents, namely a Research conducted by the authors indicates that the benefits
nameserver and a facilitator [11]. associated with MAS could be leveraged to provide effective,
The nameserver functions as an address book providing a flexible, and scalable integration of the systems used by protec-
record of the names and locations of each agent (e.g., IP ad- tion engineers for disturbance analysis. These benefits are being
dresses—information essential for inter-agent communication). realized through the novel PEDA MAS.
The facilitator functions as a “yellow-pages,” providing a list
of the abilities/resources each agent can offer )e.g., fault record IV. PROTECTION ENGINEERING DIAGNOSTIC AGENTS (PEDA)
interpretation or provision of SCADA alarms). Both of these
agents can be queried to ascertain the locations or abilities/re- Sections IV-A–E discuss the development of PEDA through
sources on offer within the MAS. The presence of utility agents to implementation of the prototype.
enhances systems integration by enabling agents to enter/leave
the MAS and register/deregister their locations and abilities. A. Identifying Required Agents
Provision of a common communications mechanism and Traditional software design methodologies don’t provide an
a flexible solution to the information discovery problem also adequate representation of core MAS concepts, namely: inter-
eases the integration of legacy systems into the MAS. Existing agent communications and agents’ reasoning capabilities. To
642 IEEE TRANSACTIONS ON POWER SYSTEMS, VOL. 18, NO. 2, MAY 2003

address this, a number of methodologies have been proposed In cases where legacy systems exist which perform the task,
for designing MAS, most notably DESIRE [14], Gaia [15], and MAS provide the opportunity to exploit this existing resource
MaSE [16]. by “wrapping” the legacy system with agent functionality [9]
Comprehensive review of these methodologies has indicated (e.g., a DFR interpretation system could be used to perform the
that some of the design concepts are more applicable to engi- “interpret” task of the FRI agent).
neering MAS than others. Consequently, the most appropriate Enabling the agent to control the execution of, input data to
aspects of each technique are being collated by the authors into and retrieve the output from the legacy system, requires minor
a design methodology for MAS within the engineering domain modifications to the legacy system’s code. Where this is not pos-
and this has been applied during the design of PEDA. It is hoped sible, software functions may be implemented which provide a
that continued research and development will result in a formal translation interface between the agent and the legacy system.
and robust methodology for designing engineering MAS, how- Conventional software design methodologies can be used to de-
ever, it is currently only in the prototype stage. sign the modifications or software functions.
The first stage in the proposed methodology is to perform
what the authors of the DESIRE methodology call task decom- C. Agent Interactions
position [14]. This process actually mirrors the knowledge en- It is evident from the task hierarchy in Fig. 2. that a number
gineering approach already outlined in Section III-A to identify of tasks require interactions with other agents to obtain data or
the required functionality and tasks used to produce the task hi- information (e.g., obtain identified incidents). The next stage
erarchy. in the methodology establishes the required message types and
Following the identification of required tasks the next stage interactions.
is to consider what tasks existing legacy systems already un- The interactions required within PEDA fall into three cate-
dertake. In PEDA a legacy SCADA interpretation system ex- gories specified by their ACL type, namely: subscribe, inform,
isted capable of providing incident and event information from and request.
SCADA interpretation [7]. To ensure the presence of this system Messages of type “subscribe” are used by agents to subscribe
is not overlooked during the design process, the tasks already to a provider of information. For example, the task hierarchy in-
performed by the legacy system are highlighted and grouped on dicates that IEI has an “identify incidents” task which enables
the task hierarchy in Fig. 2 with a shadowed box. it to be a provider of incident information. By subscribing to
The next stage is to identify the required agents and their asso- IEI, other agents, such as FRR and FRI, can obtain the infor-
ciated tasks. To avoid unnecessary duplication of functionality mation they require, in this case incident information. Adopting
across the agents comprehensive review of the tasks and their a subscription approach reduces the communications overhead
data requirements is required. within PEDA by avoiding the polling of agents to obtain new
Many of the tasks may require access to different data types information.
and application of different methodologies to provide the task Subscribed agents are informed of new information by mes-
functionality. For example the “identify incidents” task requires sages of ACL type “inform.” When new or requested infor-
access to SCADA alarms and implementation of the interpre- mation is available, the provider agent can inform subscribed
tation knowledge using expert systems compared to the “re- agents by sending an inform message with the message content
trieve fault records” task which requires access to a database of being the information.
available recorders and implementation of algorithmic code to In some cases, an agent may send an independent request
manage the retrieval process. This natural grouping and segre- for information to another agent, using a message of ACL type
gation of tasks combined with the grouping of some tasks under “request.” This is the case with the “obtain fault record” task
an existing legacy system enables the required agents to be iden- of the FRI agent, where the FRI agent may want to interpret
tified. records relating to an incident but has not received the records
Solid bars indicating the individual agents responsible for the from FRR yet.
tasks to the right of the bars are added to the task hierarchy in Note that inter-agent messaging is managed by a set of mes-
Fig. 2. In the case of PEDA, the following agents were identified sage handling rules within each agent. These rules monitor the
as being required agents mailbox for new messages and respond accordingly in
• incident and event identification (IEI); addition to sending inform messages to subscribed agents.
• fault record retrieval (FRR); To illustrate inter-agent messaging, collaboration and se-
• fault record interpretation (FRI). quence diagrams are used as presented in Fig. 3, Table I, and
Fig. 4.
The collaboration diagram enables the required messages and
B. Agent Task Realization
their type to be identified. However, inter-agent communica-
Each task has now been assigned to the appropriate agent, tions are not static and the evolution of the messaging over time
what remains is the design of each individual task. must also be modeled to avoid message bottlenecks being estab-
Task design must not only define the task inputs and outputs lished which may slow the entire MAS. Sequence diagrams are
but also the internal task reasoning or functionality. In the ma- used to illustrate the evolution of inter-agent communications
jority of cases the intelligent systems or algorithms required to over time [16].
achieve the task must be designed using conventional software The sequence diagram in Fig. 4. represents the sequencing
design methodologies. of inter-agent messages from startup of PEDA (top of the dia-
HOSSACK et al.: A MULTIAGENT ARCHITECTURE FOR PROTECTION ENGINEERING DIAGNOSTIC ASSISTANCE 643

Fig. 3. PEDA collaboration diagram. Fig. 5. Sample of PEDA ontology list.

TABLE I concepts necessary for the agents to interact and exchange in-
INTERACTIONS WITHIN PEDA
formation are defined at the outset.
The ontology is specified using data constructs called “facts”
which specify the type of data and its attributes. Review of the
task hierarchy and consideration of the data required to perform
each task and the data generated, resulted in the following facts:
“incident,” “fault record,” “interpreted fault record,” “incident
subscription,” “fault record subscription,” and “interpreted fault
record subscription.” The attributes of each fact type are then
determined based on the key parameters of, or concepts relating
to, the data type. A sample of the PEDA ontology indicating the
attributes associated with the “incident” and “fault record” facts
is presented in Fig. 5.
The authors are currently undertaking research into ex-
tending the PEDA ontology to form a comprehensive ontology
for power systems disturbance diagnosis.

E. Implementation
Having designed PEDA using the most appropriate features
of existing MAS design methodologies, the next stage was to
implement the PEDA prototype. To achieve this the multiagent
building toolkit, Zeus was used [17].
Zeus offers functionality for designing each individual agent
and provides utility agents. In the case of legacy systems Zeus
can generate software functions written in JAVA, which can be
configured and used by the developer to wrap legacy systems
Fig. 4. An example PEDA sequence diagram. with the required agent functionality. New agents can also be
developed with similar JAVA functions being generated to rep-
gram) through to achieving disturbance diagnosis by inter-agent resent each of the tasks the agent must perform.
subscription, requests and informs. Note that these agent inter-
actions will be described in more detail in the case study at the V. INCIDENT AND EVENT IDENTIFICATION (IEI)
end of the paper.
It should be noted that to fully model agent interactions, a Sections V-A–C discuss how the IEI agent is implemented
significant number of case studies may be needed which ade- by “wrapping” PEDA functionality around the legacy SCADA
quately represent the scenarios in which the MAS will operate. interpretation system described in [7].
These will normally be identified from engineers at the require-
ments capture stage. Generating a sequence diagram for each A. Legacy System
case study enables all the required agent interactions and mes- During periods of high network activity, such as during
sages to be identified. storms, tens of thousands of alarms can be generated over a
24-h period. In some cases, the time consuming manual inter-
D. MAS Ontology pretation of these alarms can reveal in excess of 100 separate
The final stage in the methodology is to define an appropriate incidents. Research conducted by the authors into automating
ontology which specifies all possible message contents. This this process, culminated in an intelligent system employing
ontology will be used in conjunction with the FIPA message rule-based system and JAVA technologies that enables the
types [10] to provide a flexible and open MAS. automatic interpretation of transmission network SCADA and
Although the ontology can be extended in the future, or addi- identification of incidents and events [7]. This system was
tional ontologies integrated, it is important that as many of the called the Telemetry Processor.
644 IEEE TRANSACTIONS ON POWER SYSTEMS, VOL. 18, NO. 2, MAY 2003

It is evident that the IEI agent must allow incident sub-

scription and provide incident information to subscribed
agents. This is provided by messaging rules which monitor
the IEI agents mailbox. On receiving “subscribe” messages
containing “incident subscription” Facts, the messaging rules
automatically reply with a message indicating successful
subscription. Subscribed agents are informed of new incidents
by the rules sending an “inform” message to each subscribed
agent with content being an “incident” Fact containing the
incident information.

VI. FAULT RECORD RETRIEVAL (FRR)

Sections VI-A and B discuss the development of the FRR
agent. Note that this agent has been developed for PEDA with
Fig. 6. Telemetry Processor java—JESS reasoning mechanism.
each task being implemented using JAVA and Zeus [17].
The principal objective of this agent is to autopoll available
The inference mechanism necessary to perform incident and DFRs for new records and to prioritize retrieval based on inci-
event identification was provided by the Java Expert System dent information received from IEI.
Shell (JESS). The JESS inference engine works in conjunction
with core JAVA functions for managing the overall Reasoning A. Task Implementation
process. The JAVA-JESS reasoning mechanism employed is
The functionality of the FRR agent can be described by its
illustrated in Fig. 6. A detailed description of this reasoning
mechanism can be found in [7]. Java tasks and the strategy applied for their control. The imple-
mented tasks are: monitor device availability, develop retrieval
Three separate rule-bases exist within the telemetry pro-
schedule, select next retrieval, retrieve, and reschedule retrieval.
cessor responsible for incident identification, incident closure,
For each one, we will detail their inputs, output, and function-
and event identification. Each rule-base contains JESS rules
ality.
looking for a particular pattern of alarms and upon matching,
Monitor device availability: This does not use any input but
the appropriate rules fire. Rule firings can result in the fol-
produces the list of DFR devices or “sources” that are available
lowing: generation of open incident JAVA objects representing
at the time of running. At present, it reads a database containing
the start of an incident, closure of open incident objects when
all possible sources and selects those categorized by engineers
the incident has finished and generation of JAVA objects
as available. In the future, a more accurate assessment of device
representing identified events. Within each incident and event
availability will be achieved by monitoring the communications
object, a concise textual summary is included for archiving and
to remote DFRs.
eventual viewing by an engineer. An example of the incident
and event summaries is presented in the case study at the end Develop retrieval schedule: The input is the list of available
of the paper. sources produced by the previous task and its output consists of
Offline testing revealed that 127 incidents and 2500 corre- a list of sources constituting the initial retrieval schedule—the
sponding events were successfully identified from interpretation order of sources dictates the retrieval order. Only when all new
of 15 000 alarms in 3 min and 17 s—a significant improvement records have been retrieved from a particular DFR source will
over the number of man days required for manual interpretation. retrieval move on to the next source.
Select next retrieval: The input is the schedule produced by
the Develop Retrieval Schedule task and its output is a request
B. Task Implementation for fault record retrieval. This task selects the next DFR source
To control execution of the Telemetry Processor within IEI a to initiate retrieval from, based on the ordering of sources within
JAVA task was included. This task was defined and implemented the retrieval schedule.
using the Zeus toolkit which generated the software function Retrieve: The input is the fault record retrieval request issued
used to integrate the Telemetry Processor into PEDA. With only by the previous task while its output is a reference to all the new
minor modifications to the original Telemetry Processor code, records retrieved from the DFR source. This task establishes
this task can now start the telemetry processor and output the the connection and communications with the remote DFR and
identified incidents and events in a suitable format for the IEI initiates retrieval of any new records. When the records have
agent. been retrieved from the DFR they are archived and the pathname
of each retrieved fault record held within the FRR agent. This
enables the FRR agent to reply to external requests for fault
C. Collaboration Functionality
records by forwarding a reference to the records avoiding the
Wrapping the Telemetry Processor within the IEI agent also need to pass large DFR records between agents.
requires the addition of inter-agent messaging functionality as Reschedule retrieval: The input can be either an incident or
indicated in Figs. 3 and 4. a fault record request from an external agent in addition to the
HOSSACK et al.: A MULTIAGENT ARCHITECTURE FOR PROTECTION ENGINEERING DIAGNOSTIC ASSISTANCE 645

present schedule while its output is a new schedule. The activity

of this task consists of the reorganization of the list of sources
to be retrieved based on a change of priorities due to external
influences such as incidents or requests.
Task execution is controlled by a set of rules within IEI, which
monitor for the existence or nonexistence of the information re-
quired for task input. Based on this information, the appropriate
rules fire and execute the required tasks.

B. Collaboration Functionality
The inter-agent messaging FRR must provide is indicated in
Figs. 3 and 4. The required fault record subscribe and inform
functionality is implemented in the same manner as in IEI with Fig. 7. Case study—transient fault on circuit SUB A/SUB B.
“fault record subscription” and “fault record” Facts being passed
within the “subscribe” and “inform” messages. when zero current is detected on all phases. Protection scheme
FRR must also be able to accept “request” messages components’ operating times are determined by interpreting the
requesting provision of records from a particular DFR—col- digital channels of the fault record and extracting the time pe-
laboration 7 in Fig. 3. Upon receipt of a “fault record request” riods each monitored digital is in a given state.
the reschedule retrieval task will be called and retrieval from Future work will see extension of the interpretation function-
the requested source scheduled. When retrieval from the ality to provide additional information such as fault type and
requested source has been completed, the requesting agent will circuit breaker duty.
be informed of each new retrieved fault record.
B. Collaboration Functionality
VII. FAULT RECORD INTERPRETATION (FRI) The inter-agent messaging FRI must provide is indicated in
Sections VII-A and B discuss the development of the FRI Fig. 3. and Fig. 4. The interpreted fault record subscribe and
agent. The principal objective of this agent is to obtain retrieved inform functionality is implemented in the same manner as in
fault records from the FRR agent and interpret them to generate FRR with “interpreted fault record subscription” and “inter-
information of interest to the protection engineers. preted fault record” Facts being passed within the “subscribe”’
and “inform” messages.
A. Task Implementation
Tasks are implemented in a similar manner to the FRR agent VIII. PEDA CASE STUDY
with rules controlling task execution. These JAVA tasks reflect To illustrate the PEDA approach to disturbance diagnosis, an
the tasks required for the FRI agent in the task hierarchy. The actual power system disturbance will be used as a case study.
implemented tasks are schedule interpretation, select next inter- Note that, to aid clarity, the network diagram in Fig. 7 has been
pretation, and interpret. simplified and the data presented in Fig. 8 reduced.
Schedule interpretation: The inputs to this task are the sets Manual retrieval and interpretation of the SCADA and DFR
of retrieved fault record information provided by the FRR agent data by a protection engineer revealed that the disturbance was
following a retrieval request and the incident information pro- caused by a transient fault on the SUB A/SUB B/SUB C circuit.
vided by IEI. The FRI agent is solely reliant on information re- The protection scheme detected the fault, isolated and restored
ceived from other agents and does not have an independent task the circuit using autoswitching. Ignoring that the engineer was
to perform like autopolling in the FRR. The task outputs an in- not made aware of the disturbance until arriving at work the next
terpretation schedule. morning, the total retrieval and interpretation time was in the
Select next interpretation: The input is the interpretation order of 2 to 3 h. The following discussion will illustrate how
schedule and the output is a request for fault record interpreta- PEDA can reduce the data retrieval and interpretation overhead
tion. The decision on which record to interpret is based on the on engineers by novel and flexible automation of the process
ordering in the interpretation schedule. using MAS to integrate retrieval and interpretation systems.
Interpret: The input to this task is the fault record interpre- It is important to note that agents within PEDA perform
tation request issued by the previous task, which specifies the their functions concurrently. So while IEI is retrieving and
pathname of the fault record to interpret. This task is the prin- interpreting new SCADA, FRR is autopolling DFRs and
cipal task within the FRI agent and is responsible for inter- retrieving any new fault records and FRI is interpreting any
preting the fault record and extracting information of relevance new fault records retrieved by FRR. Only when an agent’s
to protection engineers. The types of information extracted are internal reasoning determines that inter-agent communications
• fault inception and clearance time; is necessary are messages sent between agents.
• protection scheme components’ operating times. Assuming that the nameserver and facilitator agents have
The fault inception time is identified by determining the ear- started and each of the PEDA agents have registered their lo-
liest time of a phase current rising significantly above normal. cations and abilities appropriately, the next sequence of events
Fault clearance time is determined by identifying the latest time relates to the FRR and FRI agent identifying an agent within
646 IEEE TRANSACTIONS ON POWER SYSTEMS, VOL. 18, NO. 2, MAY 2003

Fig. 9. Sample of Telemetry Processor output from within IEI.

Having identified an incident, the IEI message handling rules

will automatically inform all subscribed agents of the new in-
cident. In this case both FRR and FRI will receive a message
indicating the date, time, circuit and a summary of the inci-
dent—collaboration 5.
Having subscribed to the IEI agent, FRR develops a retrieval
schedule and sequentially polls each of the DFR sources in
the schedule retrieving all new records and informing the
subscribed FRI agent of the new records—collaboration 6.
Note that FRI has also received the same incident information
and, realizing that it does not have any fault records relating to
the incident, decides to request retrieval of the incident related
records by sending a “request” message to FRI—collabora-
tion 7.
Fig. 8. Case study alarm and DFR data. Upon receipt of the incident message from IEI and the request
message from FRI, the FRR reschedule retrieval task is exe-
cuted, prioritizing retrieval of records from DFRs on the same
PEDA which can provide incidents via incident subscription. circuit as the incident. As records are retrieved from each DFR
Note that the sequence diagram for this case study is presented source on the incident circuit (i.e., DFR 1, DFR 2, and DFR 3),
in Fig. 4. messages are sent to the subscribed FRI agent informing it of
Both the FRR and FRI agents know that incident information the retrieved fault records. The FRI agent can then interpret the
is required for prioritizing retrieval and interpretation of fault received records, with records from the DFRs on the incident
records. They obtain this information by each sending a request circuit receiving interpretation priority.
message with content “incident subscription” to the facilitator,
thereby requesting who can provide incident subscription. The
facilitator returns IEI as a possible provider. Both the FRR and IX. ENGINEERING ADVANTAGES OF MAS FOR DIAGNOSIS
FRI agents then subscribe to the IEI agent, which, in turn, ac-
Configuring each of the standalone intelligent interpretation
knowledges subscription—(collaborations 1 and 2 in Table I).
systems to operate as agents does not improve their individual
A similar mechanism is employed by the FRI agent when diagnostic performance, however the overall disturbance diag-
determining a provider of fault records by asking the facilitator nosis assistance is enhanced from the engineers perspective,
for a provider of “fault record subscription”—(collaborations 3 with timely retrieval and interpretation of SCADA and DFR data
and 4). This eventually results in the subscription of FRI to FRR. being achieved. The integration of systems for monitoring and
On entering PEDA, the IEI agent will connect to the real-time analyzing faults is not trivial; therefore, MAS technology ame-
SCADA alarms database and start the Telemetry Processor in- liorates this problem. This not only eliminates the need for an
terpreting the alarms. Given the alarm stream in Fig. 8, the in- engineer to interrogate a number of standalone fault diagnosis
cident identification rules will recognize the “unit protection systems and manually collate the information but also reduces
optd,” “trip relays optd,” and “cb1 OPEN” alarms on the SUB the risk of DFR data being lost during storm scenarios due to
A SUB B circuit as indicating the start of an incident and gen- DFR buffers being overwritten by new data.
erate an incident object. Any alarms on this circuit, which are Adoption of a distributed MAS architecture also provides a
subsequently received, will be added to the open incident ob- basis for continual improvement of engineering decision sup-
ject, thereby grouping incident alarms. Incident closure rules port due to the flexibility and scalability achieved by the use of a
will then interpret the incident alarms for incident closure, rec- common communications mechanism (i.e., the ACL, and the ex-
ognizing a complete autoswitching sequence on the circuit. This istence of utility agents). This enables integration of further data
will close the incident and generate the incident summary indi- sources and interpretation agents in the future. These additional
cated at the top of Fig. 9. Event identification rules will then agents could be distributed across the power system providing
further interpret the incident alarms and generate information data retrieval and interpretation functionality at a substation or
on events of interest to the engineers. An example of four of the plant level, such as the condition monitoring agents COMMAS
generated events is presented in Fig. 9 below the incident sum- [13], providing automated local control of substations and plant.
mary. This approach also reduces the volume of alarm and diagnostic
HOSSACK et al.: A MULTIAGENT ARCHITECTURE FOR PROTECTION ENGINEERING DIAGNOSTIC ASSISTANCE 647

traffic on the utility communications network, while only trans- [10] FIPA ACL Specifications. [Online]. Available: http://www.fipa.org/
mitting summarized information. repository/index.html
[11] H. S. Nwana and D. T. Ndumu, “A perspective on software agents re-
Future work will include the integration of a protection val- search,” Knowl. Eng. Rev., vol. 14, no. 2, pp. 125–142, 1999.
idation and diagnosis agent which will use fault records to as- [12] L. Z. Varga, N. R. Jennings, and D. Cockburn, “Integrating intelligent
sess protection system performance [3]. A PEDA user interface systems into a cooperating community for electricity distribution man-
agement,” Int. J. Expert Syst. With Applicat., vol. 7, no. 4, pp. 563–579,
agent will be constructed which provides the combined conclu- 1994.
sions of all the diagnostic systems as a single, digestible, fault [13] E. E. Mangina, S. D. J. McArthur, and J. R. McDonald, “COMMAS
report for the engineers. This agent will automatically manage (COndition monitoring multi agent System),” J. Autonomous Agents and
Multi-Agent Syst., vol. 4, no. 3, pp. 279–281, 2001.
the dissemination of the disturbance reports to all relevant engi- [14] F. M. T. Brazier, B. M. Dunin-Keplicz, N. R. Jennings, and J. Treur, “DE-
neering personnel. SIRE: Modeling multi-agent systems in a compositional formal frame-
work,” Int. J. Cooperative Inf. Syst., vol. 6, no. 1, pp. 69–94, 1997.
[15] M. Wooldridge, N. R. Jennings, and D. Kinny, “The gaia methodology
X. CONCLUSIONS for agent-oriented analysis and design,” J. Autonomous Agents and
Multi-Agent Syst., vol. 3, no. 3, pp. 285–312, 2000.
A multiagent approach to the development and implementa- [16] M. F. Wood and S. A. DeLoach, “An overview of the multiagent systems
tion of systems to assist engineers with disturbance diagnosis engineering methodology,” in Proc. First Int. Workshop on Agent-Ori-
ented Software Eng., 2000, pp. 207–221.
was adopted. The agents within the MAS (PEDA) perform the
[17] J. C. Collis, D. T. Ndumu, H. S. Nwana, and L. C. Lee, “ZEUS agent
disturbance diagnosis roles normally undertaken by protection building tool-kit,” BT Technol. J., vol. 16, no. 3, pp. 60–68, 1998.
engineers by providing fault record retrieval and interpretation
and SCADA interpretation functions.
The work illustrates how a multiagent system can be used to John A. Hossack (S’99) received the M.Eng. (distinction) degree from the
effectively integrate existing stand-alone intelligent systems and University of Strathclyde, Glasgow, U.K., in 1999.
new interpretation approaches within an environment which of- Currently, he is a Research Assistant with the Institute for Energy and Envi-
ronment at the University of Strathclyde. His research interests include applica-
fers long term flexibility and scalability. Furthermore, the PEDA tion of multiagent systems and intelligent systems to power systems.
architecture enables timely disturbance diagnosis to be achieved
with generation of comprehensive information of benefit across
a utilities operation.
Judith Menal received the B.Eng. degree from the Universitat Ramon Llull,
Barcelona, in 1996.
REFERENCES Currently, she is a research student within the Institute for Energy and Envi-
ronment at the University of Strathclyde, Glasgow, U.K. Her research interests
[1] Z. A. Vale and M. F. Ferandes, “Better KBS for real-time applications in include intelligent systems and intelligent agents.
power system control centers: The experience of the SPARSE project,”
Computers in Industry, vol. 37, pp. 97–111, 1998.
[2] P. Burrell and D. Inman, “An expert system for the analysis of faults in
electricity supply networks: Problems and achievements,” Computers in
Industry, vol. 37, pp. 113–123, 1998. Stephen D. J. McArthur (M’96) received the B.Eng. (Hons) and Ph.D. de-
[3] S. C. Bell, S. D. J. McArthur, J. R. McDonald, G. M. Burt, R. Mather, and grees from the University of Strathclyde, Glasgow, U.K., in 1992 and 1996,
T. Cumming, “Model based analysis of protection system performance,” respectively.
Proc. Inst. Elect. Eng.—Gen. Transm. Dist., vol. 145, no. 3, pp. 547–552, Currently, he is a Lecturer within the Institute for Energy and Environment
1998. at the University of Strathclyde, Glasgow, U.K. His research interests include
[4] D. R. Sevcik, R. B. Lunsford, M. Kezunovic, Z. Galijasevic, S. Banu, and intelligent system applications in power engineering, hybrid intelligent systems,
T. Popovic, “Automated analysis of fault records and dissemination of and intelligent agent technology.
event reports,” in Proc. Texas A&M 53rd Annu. Conf. Protection Relay Dr. McArthur has many technical publications and is the co-editor of a book.
Eng., College Station, TX, Apr. 2000.
[5] S. D. J. McArthur, S. C. Bell, J. R. McDonald, R. Mather, and T. Cum-
ming, “The development of an advanced suite of data interpretation fa-
cilities for the analysis of power system disturbances,” in Proc. CIGRE James R. McDonald (M’90) received the B.Sc., M.Sc., and Ph.D. degrees from
1998, Paris, France, Aug. 1998. Strathclyde University, Glasgow, U.K.
[6] M. Wooldridge and N. R. Jennings, “Intelligent agents: Theory and prac- He was appointed as the Manager of the Centre for Electrical Power En-
tice,” Knowl. Eng. Rev., vol. 10, no. 2, pp. 115–152, 1995. gineering at Strathclyde University in July 1990 and took up the position of
[7] J. H. Hossack, G. M. Burt, J. R. McDonald, T. Cumming, and J. Stoke, the Rolls-Royce Chair in Power Engineering in February 1994. He is chairman
“Progressive power system data interpretation and information dissem- of the Institute for Energy and Environment and director of the Rolls-Royce
ination,” in Proc. 2001 IEEE Transm. Dist. Conf. Expo.. University Technology Centre in Electrical Power Systems at the University of
[8] G. Schreiber, H. Akkermans, and Anjwierden, Knowledge Engineering Strathclyde.
and Management: The CommonKADS Methodology. Cambridge, He is the Rolls-Royce Chair in Power Engineering at the University of
MA: MIT Press, 1999. Strathclyde. His research activities are in the areas of power system protection
[9] M. R. Genereth and S. P. Ketchpel, “Software agents,” Communications and measurement, expert system applications in power engineering, and energy
of the ACM, vol. 37, no. 7, pp. 48–53, 1994. management. He has published many technical papers and two books.