The use of standards within power engineering applications is particularly important, perhaps more so than in other fields of research. The software developed for power systems operation, control, monitoring, and diagnosis must be capable of interacting with other systems, allowing plug-and-play capabilities for different functionality. Agents are well suited to systems of this type, but only if they adhere to open standards for communication, meaning that agents from different developers can interact in a meaningful way.

Recently within the industry, utilities are making standardization an increased priority, as evidenced by the development of standards such as the Common Information Model (CIM) for energy management system (EMS) communications (1), and IEC 61850 for substation communications (2). Therefore, to be palatable technology for utilities, agents must also be developed with interoperability in mind.

Since agents are autonomous entities, interaction occurs by message-passing. This differs significantly from other software techniques, where interaction is enabled by publication of the Application Programmer’s Interface (API) for a software module, which allows developers to instantiate and make calls directly to the software module. In comparison, an agent responds to messages that are sent to it from other agents, meaning that interaction is enabled by knowing the format of the messages the agent expects. Since there are a number of standards for agent messaging, the sender agent need only know which standards the receiver agent adheres to in order to send a valid message.

As with any communication system, there are different layers at which messaging can be considered, and a corresponding standard for each layer. These are message transport (the delivery of a message), message format (the agent communication language), and message content (both grammar and vocabulary), each of which is considered in detail below.

The Foundation for Intelligent Physical Agents (FIPA) have created a suite of standards that cover the full stack of agent communication. FIPA was accepted as a standards committee of the IEEE Computer Society in 2005, and the FIPA standards have become the de facto standards for agent development within the power domain. As a result this page deals with the FIPA standards in most detail, but highlights other standards that have support.

Message Transport

FIPA enables message transport and delivery to agents by specifying the FIPA Agent Management Reference model, which defines:

“the normative framework within which FIPA agents exist and operate. It establishes the logical reference model for the creation, registration, location, communication, migration and retirement of agents.”

In other words, FIPA agents reside on a platform which handles message transport and addressing by keeping track of the agents within the platform. This is separated into two tasks: the Agent Management System (AMS) is tasked with registering each agent that joins the platform and assigning it a unique name; while a message transport protocol such as HTTP or IIOP is employed for delivery.

In order to find an agent to interact with, agents often use the directory facilitator (DF), an optional platform agent which keeps a directory of the agents and services on offer within the system. A typical pattern of interaction would be as follows:

• Agent A desires some service S, and queries the DF for agents offering S
• The DF responds to Agent A with the unique platform names of agents X, Y, and Z
• Agent A sends a message requesting service S, addressed to agent X
• The platform, through the AMS and message transport protocol, handles any required conversion of the name of agent X to a network address, and delivers the message to agent X.

Messaging appears as a black box to the agents: they simply send and receive messages to and from the platform, which seamlessly takes care of message delivery. The agents are unaware of whether they are co-located on one computer or distributed across a network.

The platform model, and specifically the AMS and DF, is the foundation of open, extensible multi-agent systems. Early systems had communications paths hard-wired between specific agents at design-time, but the decoupling of services and messaging from physical addresses allows agents to be added and removed from the system, and all agents on the platform are locatable.

Message Format

Message transport establishes a path between agents, but the format and sequence of the messages themselves must be standardized to allow meaningful interaction. Over time the approach to inter-agent communication has been refined, starting with proprietary communication languages, such as that used by ARCHON (3); moving to blackboard architectures (4); and then standardized communication languages such as Knowledge Query and Manipulation Language (KQML) (5), to open the architecture.

The FIPA Agent Communication Language (FIPA-ACL) has roots in KQML, and defines 12 fields of an agent message. The first, and the only required one, is the performative field, which indicates the intention behind the message and the communicative act it performs. Some examples of this are request, confirm, query if, inform, and not understood.

The optional parameters of a FIPA-ACL message include participant information (sending and receiving agents), conversation control headers (such as the conversation identifier), a content parameter, and content descriptors. All possible parameters of a FIPA-ACL message are shown in the table below. The content parameter is where the real meaning of the message is stored (discussed in the following section), with the content descriptor parameters indicating how the content should be parsed.

While an ACL message can stand on its own, there will often be a conversation between two agents, meaning a sequence of messages and replies. For example, if an agent sends a query-ref message, it is expecting an inform in reply, and may receive an intermediate agree message. FIPA specify a number of interaction protocols, the use of which is indicated by setting the protocol parameter.

A number of conversations may be on-going between two agents at any one time, and the conversation control parameters are used to direct this. If an agent sets the reply-with parameter, the immediate reply message in the conversation must copy this value into the in-reply-to parameter. The conversation-id remains constant throughout a conversation, but the reply-with tokens may change.

Message Content

The message payload occurs in the content field of the FIPA-ACL message. The syntax and semantics of the content are derived from a content language and ontology, with the content language giving the syntax (grammar) of the content, and ontology giving the lexicon (vocabulary) of the content. The content language and ontology used for a given message are named in the FIPA-ACL content and ontology fields.

The following sections describes these in turn.

Content Language

FIPA have specified four content languages:

• FIPA Semantic Language (FIPA-SL)
• Knowledge Interchange Format (KIF)
• Resource Definition Language (RDF)
• Constraint Choice Language (CCF)

There are also non-FIPA options for content language, such as Description Logics, DARPA Agent Markup Language (DAML), and OWL.

The content language chosen for agent messaging is important, since it shapes the ontology and therefore impacts on ontology technology choice. Of these options, only FIPA-SL is a FIPA standard, with the other FIPA specifications remaining experimental. To gain the engineering benefits of a stable standard, FIPA-SL may be generally preferable over other choices. However, some of the other specifications are tailored for particular types of application, which argues for their use in those situations.

Ontology

An ontology provides agents with a shared lexicon of terms for use within messages. As an agent can only meaningfully discuss concepts that it knows about (such as measurements it takes or plant that it monitors), there is no need for an agent ontology to be a complete classification of concepts, but rather a structured representation of the concepts and relationships between them within the domain the agents operate within. As a result, ontology is application-specific, and cannot be standardized by FIPA or any general agent body.

References

1. IEC, “Energy Management System Application Program Interface (EMS-API) – Part 301: Common Information Model (CIM) base”, 2005, document IEC 61970-301.
2. IEC, “Communications Networks and Systems in Substations”, 2005, document IEC 61850.
3. T. Wittig, N. R. Jennings, and E. M. Mandan, “ARCHON — A framework for intelligent co-operations”, IEE-BCS Journal of Intelligent Systems Engineering, vol. 3, no. 3, pp. 168–179, 1994.
4. S. Talukdar, “Asynchronous teams: Cooperation schemes for autonomous agents”, Journal of Heuristics, vol. 4, no. 4, pp. 295–321, 1998.
5. T. Finin, Y. Labrou, and J. Mayfield, “KQML as an agent communication language”, in Software Agents, J. Bradshaw, Ed. The MIT Press, 1997.

Citation

If you want to reference material on this topic, please consider citing these papers as appropriate:

• S. D. J. McArthur; E. M. Davidson; V. M. Catterson; A. L. Dimeas; N. D. Hatziargyriou; F. Ponci; T. Funabashi, “Multi-Agent Systems for Power Engineering Applications—Part I: Concepts, Approaches, and Technical Challenges”, IEEE Transactions on Power Systems, Vol. 22, No. 4, November 2007.
• S. D. J. McArthur; E. M. Davidson; V. M. Catterson; A. L. Dimeas; N. D. Hatziargyriou; F. Ponci; T. Funabashi, “Multi-Agent Systems for Power Engineering Applications—Part II: Technologies, Standards, and Tools for Building Multi-agent Systems”, IEEE Transactions on Power Systems, Vol. 22, No. 4, November 2007.