New IEC 61850 Protocol - Mapping based on XMPP

Henry Dawidczak and Thierry Dufaure, Siemens AG, Energy Management, Germany

While the first edition of the IEC 61850 series, published in 2003, focused on standardizing communication between applications within a Substation Automation Domain, the second edition published in 2010 extends its domain of application up the Power Utility Automation System. The IEC 61850 series specify:

  • An Abstract Communication Service Interface (ACSI)
  • A semantic model based on an object oriented architecture
  • Specific Communication Service Mappings (SCSM)
  • A project engineering workflow including a configuration description language (SCL) based on the XML language

All those aspects allow the engineering and the deployment of interoperable multivendor systems. IEC TC57 standardizes with the IEC 61850-8-2 part a new SCSM of the IEC 61850 using the XMPP communication technology. This new mapping will neither replace nor compete with the existing IEC 61850-8-1 SCSM (Mapping of IEC 61850 to MMS and ISO/IEC 8802-3). The scope of the new SCSM is to address the Smart Grid specific challenges and use cases, which quite deviate from the classical substation automation use cases and environment as illustrated in Table 1.

To begin with, the new SCSM shall continue granting the interoperability of systems. It shall provide a uniform communication solution between different applications.  The standardization effort from the requirement analysis to the solution specification involved the coordination of several working groups within TC57. The use of technologies supported by open source tools and the lack of IP or license restrictions related to the communication technologies are additional criteria that were uncompromisingly considered. Open international standardization projects are the prerequisite of a successful realization and deployment of interoperable Smart Grid projects, for the user as well as for the system integrator as for the manufacturer.

The standardization effort started with the requirement engineering: the identification of the requirements based on the use cases. The results were published in the draft TR IEC 61850-80-3. The requirements were prioritized, and the degree of fulfillment of the candidate technologies assessed. The results are published in the final version of the TR IEC 61850-80-3. The XMPP technology (Extensible Messaging and Presence Protocol) has been elected as the communication solution, as it was identified as the only candidate to offer a 100 % coverage of the high rated cyber security requirements.
The second step has been the development of the specification of the mapping of the IEC 61850-7-2 Abstract Communication Service Interface (ACSI).

XML messaging will be the container for the transmission of the Payload data. Additional required services such as the time synchronization interface will rely on existing and approved technologies. The SCSM is available as a first committee draft CD of the IEC 61850-8-2.

Use Case Microgrid
The basis for all use case descriptions are the Smart Grid Architecture Model (SGAM) (Figure 1), and the traffic light concept. DER-Systems consist of electrical production sites, storages and controllable loads. DER-Systems can contain one or more DER Units, and in a hierarchy one or more DER-Systems. The DER-Units can be of one type (homogeneous system like PV-farms, Wind farms), or of different types (heterogeneous system deploying PVs, wind turbines, electrical storages, etc…). The DER Management System (DER MS) controls the DER-System. It can be located at the Energy Management System of the Prosumer, or at an aggregator level (e.g. at a Virtual Power Plant (VPP), or at a facility operator of a Microgrid (FDEMS). A Microgrid is a special deployment/application of a DER System. It consists in at least a distribution network, several controllable loads (at least partially controllable),  and several DER units. It is characterized by the following properties:

  • A Microgrid can, on demand, follow an islanding mode, e.g. be isolated / disconnected from the distrbution / transport grid its Point of Common Coupling (PCC) is connected to
  • As a direct consequence, a Microgrid shall include a frequency stabilization unit
  • Each DER generator within a Microgrid shall support network protection in case of a fault (fault-ride-through)
  • A Microgrid shall support the black-start capability, i.e. allowing the system restoration in the islanding mode
  • In the islanding mode, a Microgrid shall supervise the balance between the electrical generation and load, i.e. a Microgrid shall include a local balancing authority during both the islanding mode as well as the normal mode
  • A Microgrid Control Center controls all major electrical loads and generators and shall therefore dispose on a secure communication connection with them; a secure communication connection between the DER-MS of the Microgrid and the associated DSO/TSO Control Center shall be availabe at least in normal mode; in islanding mode, the connection to the assoicated DSO/TSO is required for performing the transition to the normal mode (connection to the electrical grid)


The two main modes of the Microgrid are therefore:

  • Islanding mode (autonomous)
  • Normal mode (PCC connected to the electrical grid)

The islanding mode is setup by opening the PCC, and therefore the Microgrid has been disconnected from the electrical grid. Mostly, these are unwanted transitions, as an isolated Microgrid has rarely a perfect balance between its generation and all its consuming loads.
While in normal mode, the Microgrid follows the same energy management rules as any other DER Systems; particularly, the DSO/TSO operator is entitled to overrule in an emergency situation, i.e. to reduce the maximal active power feeded at the PCC from the Microgrid (red traffic light).

The Microgrid operator is entitled, as any other DER System, to market its active power surplus.
Nanogrids are very similar to bigger Microgrids. A single facility or smaller industrial plant could deploy its own low-voltage nanogrids, while determining an emergency configuration, following their safety policy, and running it in case of faulty external power supply (to preserve the functionality of essential pumps, control systems).
However emergency configurations should remain weather-independent, i.e. involving diesel generators or batteries. An automation process would start disconnecting the secondary/less important consumers, and would supervise the operation of the remaining ones.

The balance between generation and load should be computed at the project design time and be used as setpoint in the automation system. In all cases, a reliable and secure communication needs to be established between all the major system components.

XMPP Basics

The decision criteria used in the standardization committee lead to elect XMPP (Extensible Messaging and Presence Protocol) technology as a network layer in the SCSM. XMPP is originally created for developing Chat platforms, i.e. systems with a high number of participants being all connected to a WAN.
XMPP is a communication protocol that enables two entities (XMPP clients) to exchange pieces of XML data called stanzas. As shown in Figure 2, both the DERs (IEC 61850 servers) and the VPP or DNO control centers (IEC 61850 clients) are then deployed as XMPP clients. IEC 61850 clients and servers are not directly connected together but can ex-change XML messages over the XMPP server(s) they are connected to.

Each XMPP client is responsible for initiating a TCP/IP connection to the XMPP server of the domain the XMPP client belongs to. The XMPP servers are located in the WAN and their location can either be statically configured in the DERs or can be discovered by the DERs via the use of DNS-SRV records.
Since DERs are located behind (most of the time unmanaged) firewalls, the XMPP servers cannot reach/connect to them (requirement – blocked inbound connection); nevertheless DERs can reach/connect to the XMPP server of their domain over the stateful firewall of their infrastructure. Stateful firewalls keep track of the state of network connection when filtering packets traveling across it: only packets matching a known active connection will be allowed by the fire-wall, others will be rejected (Stateful Packet Inspection (SPI)). XMPP clients can connect to XMPP servers; XMPP servers can respond to the connection request from XMPP clients but XMPP servers cannot cross the firewalls unless they respond to the connection request that went through the firewall.

As soon as the TCP/IP connection (TLS should be used additionally) to its XMPP server is established, each XMPP client uses it to negotiate a bi-directional XML stream with its XMPP server over which the XMPP Clients and Servers will exchange XML messages.

Communication between XMPP clients occurs over the XML streams each client has negotiated with their XMPP server, the server acting then as router forwarding the message exchange from the source XMPP client to the destination XMPP client. 
Each XMPP client becomes an XMPP address, a unique system identifier so-called JIDs, which format is quite similar to the well-known email addresses format: entity@domain.tld. XMPP server also becomes an XMPP address, its JID being limited to the domain identifier: domain.tld.

Communication domains can be hosted either by DSO entities, by VPP entities and/or by third party entities such as telecommunication providers. It is to note that an IEC 61850 participant can be configured with multiple JIDs, one per communication domain it is enrolled in. Each JID will lead to TCP/IP connection, i.e. to an XML Stream to the XMPP server of the domain indicated in the JID itself. XMPP technology is IPv6 transparent, as an XMPP client implementing IPv4 can easily communicate with an XMPP client implementing IPv6, using an XMPP server that implements a dual stack IPv4/IPv6, the server being responsible for the routing/forwarding of the message to the end point.

The XMPP series define three different XML message formats called stanza. Similar to the mail message, each stanza contains an attribute “from” (from=”JID of the source of the message”) and an attribute “to” (to=”JID of the destination of the message”). The three different message formats are of type:

  • <iq> (dedicated for request/response exchange - solicited service)
  • <message> (dedicated for push-exchange - unsolicited communication)
  • <presence> (dedicated for presence announcement)

Presence announcement and presence monitoring are useful features in a system with a high number of participants, especially in systems with limited communication capability. If a DER connects sporadically to its XMPP server, the control center may be interested in receiving a notification of its presence to update for instance its schedule. As an IEC 61850 client, trying to reach such a DER as long as it has not connected to the system is not optimal, but trying to reach it after a presence notification change is optimal. Of course, the IEC 61850 association to the IEC 61850 client can be initiated by the IEC 61850 server also to realize the sporadically connection use case.

Mapping of IEC 61850 to XMPP

The task force elected the XMPP technology for taking advantage of the solutions offered by the XMPP series to solve communications challenges within the WAN:

  • The native NAT capability (IEC 61850 servers and IEC 61850 clients can exchange messages to each other without consideration of resolving IP addressing and communication path in the WAN)
  • The DNS address resolution for reaching the XMPP server within the WAN (as any internet browser uses to resolve the domain behind an URL location)
  • Not requiring a specific firewall configuration (incoming connection architectures require that communication ports are opened for accepting connection request both at the IEDs as at the firewalls used to protect the IEDs)

XMPP has been introduced in the current CD IEC 61850-8-2 as a network layer, as its adoption solves the reachability of the system participants.

The IEC 61850-8-1 SCSM maps the IEC 61850-7-2 abstract classes and associated services to MMS components and associated services. The serialization of the exchanges defined by MMS is ASN.1 BER (Basic Encoding Rules).  Instead of defining a mapping of the IEC 61850-7-2 to a pure XML messaging, the standardization committee has elected a serialization based on MMS following the ASN.1 XER (XML encoding rule) for the IEC 61850-8-2 SCSM in order to profit of the maturity of MMS as well as to profit of XML technology. The message, and any variable type definitions will be standardized and distributed in form of a schema document. The advantages of the elected approach are among others:

  • Reducing the time to publish of the standardization document as the mapping of IEC 61850-7-2 to MMS is already available
  • Reducing the conformity effort as the test procedures for testing an IEC 61850 implementation based on a MMS mapping are already available
  • Reducing the time to market as the standard is sooner available
  • Increasing the interoperability with the existing mapping
  • The layer "use of XMPP" in Figure 3 consists in the mapping the MMS services to the XMPP stanzas:
  • Request/response services will be mapped to the <iq> stanza (e.g. associate_req, associate_resp, operate_req, operate_resp,...)
  • Reporting services will be mapped to the unsolicited <message> stanza (e.g. report_req, commandTermination_req, ...)


Table 2 illustrates the mapping in steps, first of the IEC 61850-7-2 abstract services to MMS services and then of the MMS services to the XMPP type of stanzas.

Further Investigations
The standardization committee is investigating on further usage of the XMPP technology. The XMPP standard provides protocol extensions (so called XEPs), i.e. optional technical specifications to solve additional communication requirements. The developments of the specifications are hosted and coordinated by the XMPP foundation. For example, the XEP-0045 specifies the Multi-User Chat environment, with which XMPP clients can exchange messages in the context of an administrated room. The IEC 61850 multicast application association defined in the abstract model could easily be mapped to a moderated room, where the moderator is the publisher of the unidirectional information, and the subscribers are dynamically invited to join the room in which the information is being published.

The XEP-0065 specifies an out-of-band bytestream between any two XMPP clients. The bytestream can be either direct (peer-to-peer) or mediated (though a SOCKS5 proxy server). The bytestream is negotiated between the XMPP Clients over their connection to their XMPP server(s). The use of SOCKS5 proxy allows overcoming stateful firewall, as the incoming connection to the IEC 61850 Server will occur on the SOCKS5 proxy in the WAN and not directly to the resources behind the firewall.

Another challenge of the communication within the Smart Grid is the multi-domain communication, i.e. communication between a VPP, a DSO and the DER connected to the DSO grid and contracted with the VPPs.
Multi-domain communication can be established via the use of XMPP federation or via the use of multiple JIDs at the XMPP clients. The principle of XMPP federation is that XMPP servers of different domains establish an XML stream between each other in order to forward XMPP stanzas from an XMPP Client located in one domain to another XMPP client located in another domain as illustrated in Figure 4.

An alternative way to achieve multi-domain communication is to configure multiple-JIDs to the XMPP client entities enrolled in multi-domain (Figure 5).
XMPP servers will most likely be clustered due to the number of connections that are held and due to redundancy considerations that are currently also being investigated.
Discovering the IP addresses of the XMPP server of a domain can be done dynamically by using the DNS-Srv record. The DNS response could include a list of connection managers used for the deployment of the XMPP infrastructure.

The list can be weighted, following a communication load management principle, a hierarchical aggregation scheme of the system, a geographical consideration connect to the next in the list in case of path outage or of communication failure.
The important aspect is that the XMPP client that tries to connect to the first connection manager could connect to the next in the list in case of path outage or of communication failure.
This philosophy offers redundancy concepts as a network path outage to a connection manager could be overcome connecting another connection manager of the XMPP server.


Henry Dawidczak finished his study of Business Administration and Engineering in Moscow in 1983 and received the “Dipl.-Ing.-Ök.” Graduate degree. He worked as software developer in substation automation in Dresden before he started his job in different positions in the Siemens company in Nuremberg. Since 2003 he has been involved in standardization projects regarding IEC 61850. Since 2004 he is responsible editor of IEC 61850-7-4. For some years he leads a task force of working group 17 of IEC TC57 regarding Grid Integration of DER with IEC 61850. He is member of national and international standardization bodies, e.g. IEC TC57 WG10, WG17 and WG19.


Thierry Dufaure received his master’s degree in Electrical Engineering at SUPÉLEC – École Supérieure d’Électricité in Paris (France) in 1995. He has been involved in development of Embedded Systems ever since first in Thomson C.S.F. until 2001 before joining Siemens AG in Berlin in the development of substation automation systems, as a developer, project manager and currently as system architect. Thierry is a member of both WG10 and WG17 from TC57, and co-editor of several IEC 61850 core parts.


Let?s start with organization in protection testing