Paper accepted for presentation at the 2011 IEEE Trondheim PowerTech
Integration of Distributed Energy Resources in
the Grid by Applying International Standards to
the Inverter as a Multifunctional Grid Interface
S. Jaloudi, Student Member, IEEE, E. Ortjohann, A. Schmelter, W. Sinsukthavorn, Student Member,
IEEE, P. Wirasanti, Student Member, IEEE, N. Alamin, D. Morton
Abstract—Distributed Energy Resources (DERs) are rapidly
penetrating in power systems including their accompanying
software and hardware (SW/HW) systems that are also
distributed and related to different manufacturers and owners.
Information integration and interoperability are two problems in
distributed systems. This paper presents a comparison between
the available integration middleware and standards for inter-
application interoperability of distributed SW/HW systems
accompanying DERs such as Common Object Request Broker
Architecture (CORBA), Web Services, multiagent systems
(MASs), and recently IEC 61850. In addition, the paper shows
the possibility of mapping the information objects of IEC 61850
to the data objects of legacy SCADA protocols for physical
control and integration of DERs interfaces, namely inverters, into
the future Smart Grid over IP-based networks, to achieve inter-
device and device-to-application interoperability. Moreover,
billing functionality can be added to the inverter to count for
injected power into the Smart Grid, and hence the inverter has
business-related functions.
Index Terms--Distributed power generation, IEC standards,
IEEE standards, multiagent systems, power systems, SCADA
systems, Smart Grids, web services.
I. INTRODUCTION
C onventional power systems include centralized power
plants, the power mainly flows in one direction, and the
active control takes place only in the high voltage levels. In
contrast, smart power systems include centralized power
plants, distributed energy resources (DERs) as well as
renewable energy sources (RESs) in all voltage levels, and
characterized by actively controlled bidirectional power flow
[1]. The energy converting system (ECS) of the RES converts
the energy from one form to dc current, which must be
converted into ac in order to be fed to the grid. This can be
This research work is supported by the German “Federal Ministry of
Education and Research” and administrated by “Arbeitsgemeinschaft
industrieller Forschungsvereinigungen "Otto von Guericke" e.V. (AiF)”.
S. Jaloudi, W. Sinsukthavorn, P. Wirasanti, and N. Alamin are pursuing
their PhD degrees at South Westphalia University of Applied Sciences
through the joint program with the University of Bolton (UK), Soest,
Luebecker Ring 2, 59494 Germany (e-mail: jaloudi@fh-swf.de).
E. Ortjohann is a professor at South Westphalia University and head of
Power Systems and Power Economics department, Soest, Luebecker Ring 2,
59494 Germany (e-mail: ortjohann@fh-swf.de).
D. Morton is a research professor in the School of Business and Creative
Technologies at the University of Bolton, Deane Road, Bolton, BL3 5AB,
UK.
978-1-4244-8417-1/11/$26.00 ©2011
done by the inverter, which is the interfacing unit that provides
decoupling between frequency and voltages across the
terminals of the ECS from one side and the voltage and
frequency from the grid side; using grid forming, grid
supporting, and grid parallel topologies [2]. This interface unit
can act as a multifunctional device, including ac to dc
conversion, primary control, intelligent electronic device
(IED) functionality based on IEC 61850 for physical control
and offer billing functionality to count for injected power into
the Smart Grid. The last two functionalities can be achieved
via IEC and IEEE standards in order to introduce a
multifunctional grid interface device, for future Smart Grids.
This insures standardized interoperability, physical control and
business-related functionalities.
On the other hand, future power systems can be considered
as distributed systems because they could contain multiple
operating systems and diverse communication networks. In
addition, ECSs based on RESs are penetrating in power
systems including their associated software and hardware
(SW/HW) systems. These systems are geographically
dispersed, and related to different manufacturers and owners.
System integration is a serious problem in such distributed
systems, which mainly covers interoperability between
interconnected systems and communication protocols. While
power utility device-to-device interoperability is recently
proposed via IEC 61850, application-to-application
interoperability can be achieved via middleware architecture
such as Distributed Object Computing (DOC) middleware,
Component Object Middleware (COM), and Message
Oriented Middleware (MOM). On the other hand, IEEE has
adopted the Distributed Network Protocol version 3 (DNP3)
as a communication protocol for future Smart Grids under the
name IEEE P1815™ [3]. Traditionally, DNP3 and IEC 60870-
5-104 are considered as legacy SCADA protocols that offer
communication between remote terminal units (RTUs), as
field devices, and the SCADA system as control center
application. The National Institute for Standards and
Technologies (NIST) has recently launched a project for
mapping the information objects of IEC 61850 to the data
objects of DNP3 [4], which will offer the device-to-
application interoperability.
Therefore, application-to-application interoperability is
discussed in section II, entitled information integration in the
Smart Grid as a distributed system. Standard communication

protocols for conventional and future power systems are
discussed in section III. Device-to-device interoperability and
application-to-device interoperability depending on IEC and
IEEE standards are discussed in section IV, which is entitled
comparison between international standards and middleware
for interoperability and control of DERs. Section V introduces
a general strategy for the inverter as a multifunctional grid
interface device by applying specific IEEE and IEC standards
to it. Finally section VI concludes the whole paper.
II. INFORMATION INTEGRATION IN THE SMART GRID AS A
DISTRIBUTED SYSTEM
A new trend in power systems is developing toward
distributed generation (DG), which means that energy
conversion systems (ECS) are suited close to energy
consumers and large units are substituted by smaller ones [5].
In general, DG is geographically distributed across the grid
and their accompanying information and communication
technology (ICT) systems are distributed as well among
different stakeholders. Hence, the Smart Grid is a distributed
system that could be a collection of heterogeneous
components and unrelated software systems communicating
over different networks through an intelligent integration
middleware, which enables these components, systems and
devices to share the resources of the power system and to
organize their activities, so that the interconnected systems
look like a single integrated grid. This gives Smart Grids some
characteristics related to distributed systems such as:
1) Future Smart Grid has multiple points of control,
2) Different systems will be able to interoperate through
well-defined interfaces that mandates the Smart Grid
to be an open system,
3) Components, objects and resources of Smart Grids
may not be shared or accessible by all stakeholders,
4) Smart Grid will be scalable; size scalability (number
of users/applications), geographical scalability
(distance between nodes), and administrative
scalability (number of administrative domains).
In general, three technologies are developed to support
distributed systems [6]: Ad hoc network programming,
structured communication and middleware architecture.
A. Ad hoc network programming
Inter-process communications (IPC) is an example of this
technology that includes pipes, shared-memory and sockets
programming. It enables components from different address
spaces (clusters) to intercommunicate. Clustering is the
process of partitioning a network into subnets of nodes, and it
is a way of making ad hoc networks more scalable [7]. Using
e.g. sockets, directly within application code, tightly couples
this code to the socket API. Adding new application to the
system becomes costly, and needs manual effort. On the other
hand, programming directly to an IPC can cause a paradigm
mismatch, e.g., one side uses method invocations while the
other uses message passing.
2
B. Structured Communication
Remote procedure calls (RPC) is an example of this type of
technology. The Sun RPC and distributed computing
environment (DCE) are tow examples of the RPC technology.
RPC-based technique allows procedures in one application to
call procedures in remote applications as if they were local
calls. Structured communication offers higher-level
communication than the ad hoc programming. However,
disadvantages of ad hoc networks were not fully overcome.
Moreover, tightly coupled components in the network, is a
serious problem in this technology.
C. Middleware Architecture
It is the bridge infrastructure software that interconnects
distributed applications and components to ensure
interoperability. It resides between the application layer and
the underlying operating system, network infrastructure, or
database. The main goal of a middleware is to enable
distributed heterogeneous SW/HW systems to
intercommunicate and interoperate via integration
architecture. Distributed Object Computing (DOC)
Middleware, Component Object Middleware (COM) and
Message Oriented Middleware (MOM) are all examples of
this middleware.
The DOC technologies are based on Object-Oriented
techniques (Object-Oriented Middleware: OOM), and
consider each entity in the distributed system as an object with
no distinction between clients and servers. Moreover each
object provides services to other objects and receives services
from other objects through a communication middleware
called an object request broker (ORB) [8]. CORBA 2.x and
remote method invocation (RMI) are examples of DOC
technology. CORBA also defines communication protocols
and object information models to enable interoperability
between heterogeneous applications [9]. DOC technologies
focus on interfaces, and the object models treat these
interfaces as client/server and tightly couple the
intercommunicating objects [10]. This means that
programmers must explicitly program the connections among
the objects, which limits the flexibility of CORBA-based
applications.
COM middleware tried to overcome the limitations of the
DOC middleware by creating a virtual boundary around
application components, with well-defined interfaces,
composing and executing components in generic application
servers [10]. It encapsulates services to provide reusable
building blocks, and looks at each implementation entity as a
component and defines a set of connection points and
interfaces to synchronously intercommunicate with other
components. Some component models also support
asynchronous message passing. These components represent
clients, whereas a container represents the server. To associate
clients with their servers, connection points are joined with
named interfaces provided by other components [6].
Microsoft’s COM and DCOM that are deprecated in the .NET,
Enterprise Java Beans (EJB), Java 2 Enterprise Edition (J2EE)
and CORBA 3.x Component Middleware (CCM) are all

examples of this type of middleware. In fact, CCM is a
technical improvement on EJB, and joins the best of .NET and
J2EE component models. The .NET is multi-language, single-
platform, while J2EE is single-language and multi-platform.
Apache ActiveMQ and Java Messaging Server (JMS)
provide loosely coupled exchange of messages and represent
MOM products. Simple Mail Transfer Protocol (SMTP) can
be used to offer the functionality of this middleware as a
firewall-friendly standard. Nevertheless, it needs more
programming efforts. More details can be found in section IV.
On the other hand, two communication mechanisms exist,
the request/response and the asynchronous messaging, which
includes publish/subscribe topic messaging and point-to-point
message queuing. COM and DOC Middleware are examples
of the request/response pattern, whereas, MOM is an example
of the asynchronous messaging pattern. The request/response
pattern introduces synchronous communication between client
and server. The main characteristics of this pattern are point-
to-point communication, which means that the client
communicate with only one server at a time, and clients are
tightly coupled to servers, which means that the client must
know the identity or the address of the server, (i.e. designated
communication). The Publish/Subscribe and message queuing
mechanisms introduce asynchronous communication, where
senders transmit data to receivers without blocking to wait for
a response. Furthermore, it supports group communication,
where multiple subscribers can receive events sent by one
publisher. Moreover, Publishers are loosely coupled to
subscribers, where the publisher must not know about the
existence of the receiver (i.e. anonymous communication).
D. Enterprise Service Bus
Web services can be used to implement the Service
Oriented Architecture (SOA), and together with a MOM can
build an effective enterprise service bus (ESB), which is a
distributed system that integrates heterogeneous SW/HW
systems. The ESB in this case groups both the SOA together
with the Event Driven Architecture (EDA) to build seamless
information integration architecture. EDA can complement
SOA because services can be activated by triggers fired on
incoming events. However, the main technologies used by
web services are the Web Service Description Language
(WSDL) and the Simple Object Access Protocol (SOAP).
SOAP is the XML-based communication protocol used for
exchanging structured information in a decentralized
distributed environment, and hence the naming, SOAP-based
web services. It is used for accessing a Web Service via HTTP
and hence, passes through firewalls. In addition, it allows
communication between applications running on different
operating systems, with different programming languages. In
fact, Web services offer synchronous communication via
SOAP/HTTP and represent an SOA, whereas, asynchronous
communication can be implemented using SOAP/JMS,
SOAP/Apache ActiveMQ or even SOAP/SMTP in order to
represent an EDA. However, SMTP is a standard protocol,
whereas, JMS and Apache ActiveMQ are industry products.
3
III. STANDARD COMMUNICATION PROTOCOLS FOR
CONVENTIONAL AND FUTURE POWER SYSTEMS
More and more power-related applications utilize
information and communication technologies (ICTs) and
standard protocols for information exchange that intelligently
integrates the SW/HW components of new DERs into the
existing conventional power systems. This comes by the
application of standard communication protocols between
different stakeholders of the power system. Some of these
protocols are already in use. The most popular are the legacy
SCADA protocols, such as the IEC 60870-5-104 (T104) and
the distributed network protocol version 3 (DNP3). New
standards are emerging such as the IEC 61400-25 for wind
power plants, the IEC 62056 for telemeter, and the IEC 61850
for communication and data modelling in substations, DERs
and hydroelectric power plants. These standards are explained
in the following subsections.
A. IEC 60870-5-104
The IEC 60870 standard defines communication protocols
between control center (CC) and substation. Part 5 consists of
6 sections, under the general title “Telecontrol equipment and
systems – Part 5: Transmission protocols” [11]. Part 5-104
represents a legacy SCADA protocol and widely used for
telecontrol between the control center and RTUs in Europe.
This protocol can be used over Internet WAN because it was
built according to the IEEE model, and hence web-based
SCADA systems can be built in hierarchical way.
The IEC 60870-5-104 (T104) data units are application
service data units (ASDUs) in the IEEE 802 model (RFC
2200), as shown in Fig 1. This means that they are services in
the application layer that are divided into data units. These
ASDUs are associated with control frames called application
protocol control information (APCI). The APCI together with
the ASDU form the application protocol data unit (APDU),
which is the main transferred data unit from the CC to the
RTU in the control direction, and from the RTU to the CC in
the monitoring direction, in vertical communication way as
shown in Fig. 2. The minimum size of the APDU is 6 bytes,
while the maximum size is 255 bytes including control and
header frames [11]. This limits its usage to transfer large
amount of small sized data units. However, the server,
controlled station, always uses TCP port number 2404, while
the client, controlling station, uses ephemeral TCP ports. In
addition, an IPv4 address must be assigned to each client as
well as each server in order to be used in a WAN such as the
Internet. The hardware part of the RTU may or may not exist.
This totally depends on the application that may use a
database (DB) instead of a HW device, or may use both of
them together in a LAN with other SW/HW entities.
B. DNP3
It is the American version of the early IEC 60870-5
version, and originally designed as a general SCADA
protocol. It was developed in the 90s while it was in public
use, and later, its ownership is given to the DNP3 users group.
In January 2010, the IEEE announced that work is underway
for the formal recognition of DNP3 as an IEEE standard.

Fig. 1. IEC 60870-5-104 in the IEEE 802 model.
Named as IEEE P1815™, the IEEE claims that the standard
will promote interoperability across hundreds of operational
systems with thousands of installed devices, as well as
strengthening security protocols while maintaining
compatibility with existing object models [3]. However, the
size of its APDU can vary between 0 and 2048 bytes, which
limits its usage to transfer small amount of large sized data
units. In spite of that, the IEEE claims that it is an extremely
robust and flexible methodology for optimizing data
transmission between mission-critical devices in process
automation settings [3].
C. IEC 61850
IEC 61850, the standard protocol for "Communication
networks and systems for power utility automation" [12], is a
communication and data modeling standard for the design of
substation automation systems using the object oriented data
model, substation configuration language (SCL), and abstract
communication service interface (ACSI) that specifies the
models and services used for access to the elements of the
domain specific object model. The SCL has many types of
XML-based files, which include the IED Capability
Description (ICD) file, the Substation Configuration
Description (SCD) file, and the Configured IED Description
(CID), etc. These files are constructed in the same method and
format but have different scopes depending on the need. They
are used for offline configuration, which reduces cost and
effort, yet, eliminate inconsistencies in system configuration.
The standard divides inter-substation communication into
three levels: the substation level, which includes the human-
Fig. 2. The IEC 60870-5-104 protocol philosophy – vertical communication.
4
machine interface (HMI) and the interfaces with outside the
substation, the bay level (unit level), which includes the
protection and control intelligent electronic devices (IED), and
the process level, which includes intelligent sensors, actuators
and other I/O devices. In addition, the standard utilizes
different network technologies and communication
mechanisms for exchanging information in the substation, via
several protocols, as shown in Fig 3:
1) Client/server communication protocol that uses the
mapping of the application models and objects to
manufacturer message specification (MMS) for
transmission outside the substation,
2) Generic Object Oriented Substation Events (GOOSE)
for real- time messaging between substation devices,
3) Sampled Analogue Values (SAV) for transmitting
measured binary data from current and voltage
transformers (CTs/VTs).
The GOOSE messages and sampled values are in use
within the substation, sent from the application layer directly
to the real-time Ethernet. In contrast, the client/server
mechanism uses the whole stack of the ISO model, uses the
specific communication service mapping (SCSM) for mapping
the information models to a communication protocol, and can
be synchronized via simple network time protocol (SNTP). All
these properties make it suitable for SCADA systems.
However, the MMS, by itself, is not the right protocol for
SCADA systems and hence, the mapping of IEC 61850
information models to a legacy SCADA protocol, such as the
IEEE P1815 and T104, is proposed as explained in section V.
While the IEC 61850-7-420 define information objects and
models for the communication with DERs logical nodes
(LNs), the IEC 61850-7-410 is used for the same purpose in
hydroelectric power plants. However, both are parts of the IEC
61850 that adopted the IEC 61400-25 for wind power plants.
Fig. 3. Approach of the IEC 61850 protocol stack.

D. IEC 61400-25
According to [3], the IEC 61400-25 series defines
communications for monitoring and control of wind power
plants. The architecture of this standard has been selected to
provide an abstract definition of classes and services such that
the specifications are independent of specific protocol stacks,
implementations, and operating systems. It mainly includes:
1) Part 25-1: description of principles and models,
2) Part 25-2: information models,
3) Part 25-3: information exchange models,
4) Part 25-4: mapping to communication profile ,
5) Part 25-5: conformance Testing,
6) Part 25-6: logical node classes and data classes for
condition monitoring.
Part 25-4 specifies the specific mappings to protocol stacks
of MMS, DNP3, IEC 60870-5-104, web services and OPC
XML-DA. Hence, the focus of the IEC 61400-25 series is on
the communications between wind power plant components
such as wind turbines and actors such as SCADA systems.
Internal communication within wind power plant components
is outside the scope of this standard [13].
E. IEC 62056
The IEC 62056 is a standard for “Electricity metering –
data exchange for meter reading, tariff and load control”. Part
52, communication protocols for management distribution line
message specification (DLMS) server, is dedicated for
electricity supply systems including electric energy meters in
buildings, emergency electrical supplies, etc. [14]. This part is
used for load telecontrol and telemeter in a SCADA, which
makes it compatible with telemeter between the DER metering
equipment and the control center. The Companion
Specification for Energy Metering (COSEM) contains
metering specific objects based on Object Identification
System (OBIS) codes for use with DLMS and xDLMS, which
is an extension to DLMS and describes how to access
attributes and methods of COSEM objects. OBIS naming is
used to identify COSEM objects in order to make them self-
describing. The advantage of using DLMS/COSEM is the
interoperability that they can offer. In addition, part 47 of the
standard specifies the communication over IPv4 (like
Internet).
IV. COMPARISON BETWEEN INTERNATIONAL STANDARDS AND
MIDDLEWARE FOR INTEROPERABILITY AND CONTROL OF DERS
As mentioned above, the middleware is the bridge
infrastructure software that interconnects distributed
applications and components to ensure interoperability. DOC,
COM and MOM are all middleware industry standards. In
some cases the middleware is a product (such as RMI, JMS,
etc.) that can not be used for Smart Grids, because it is not a
standard which is a requirement for future smart power
systems.
CORBA is an industry standard developed by Object
Management Group (OMG) that defines object information
models and communication protocols for interoperability. In
addition, CORBA 3.x joins the best of .NET and J2EE in
5
order to support multi-language and multi-platform to insure
interoperability. Moreover, it supports synchronous and
asynchronous communication via Internet Inter ORB Protocol
(IIOP) and Multicast Inter ORB Protocol (MIOP) respectively.
It uses an Interface Definition Language (IDL) as a description
language in order to obtain client stubs and server skeletons.
Web services are World Wide Web Consortium (W3C)
standard that can be used to implement the SOA. They use
WSDL as a description language and SOAP messages over
HTTP for synchronous communication that supports
request/reply mechanism. EDA can complement SOA by
using SMTP for asynchronous communication that includes
publish/subscribe topic messaging and point-to-point message
queuing as well. However, JMS and Apache ActiveMQ are
two alternatives that can provide asynchronous
communication with no programming efforts as with SMTP.
Nevertheless, HTTP and SMTP are firewall friendly standards
and can build light-weight applications, which are advantages
over JMS and Apache ActiveMQ products. Some of these
products, which are not even industry standards, guarantee the
delivery of messages that is not guaranteed with SMTP.
However, the SMTP as a standard is proposed here to
complement the SOA, as shown in section V.
Multi Agent Systems (MASs) are adopted by the IEEE-
FIPA (Foundation for Intelligent Physical Agents) and IEEE-
PES (Power & Energy Society) as well, nevertheless, they can
not be used for the control of DERs interfaces because they
are not yet standardized and rely on high-performance
systems. In addition, no industrial community adopted MASs
in their devices, i.e. there are no MAS-enabled IEDs.
However, they use Agent Description Ontology (AD
Ontology) as a description language and Agent
Communication Language (ACL) messages. Moreover, they
use many middleware technologies in order to achieve the
high performance.
Although, CORBA 3.x defines object models and
communication protocols, these objects can not be directly
used for utility devices and DERs interfaces. In contrast, IEC
61850 defines information objects and mapping to a
communication protocol that are specifically defined for utility
devices, which offer device-to-application interoperability.
Despite of the high performance of IIOP-based applications
compared to those of SOAP-based applications, mapping IEC
61850 information models to IIOP is impossible without an
ORB that is compatible with the needs of IEC 61850. Hence,
there is no way to use one middleware for both device and
application integration. Timing requirements may be used to
split device-to-application integration and control via IEC
61850 information models mapped to IEEE P1815 (DNP3),
and inter-application integration via an ESB that represents an
effective middleware for business-to-business integration as
well. While, traditional middleware often solves
interoperability problems with tightly coupled systems, web
services introduce loosely coupled architecture for the same
purposes.
A comparison between all these technologies is shown in
Table 1 below.

TABLE 1
COMPARISON BETWEEN IEC 61850, WEB SERVICES, CORBA 3.X AND MAS
V. APPLICATION OF STANDARDS TO THE INVERTER
As mentioned above, information integration in distributed
power systems mainly covers communication networks and
standard communication protocols. Therefore, the available
standard protocols that can be applied for communication
between the control center and SW/HW systems (RTU/IED,
DB, PC) of an ECS, in vertical communication over IP-based
WAN, are shown in Fig. 4. Each DER is shown in a LAN
together with its related SW/HW systems as mentioned in
section III, part A, communicating in vertical way to the
control center via IEC 60870-5-104 (T104).
While the IEC 61850-7-4 and 61850-7-420 define
information models for the communication with DERs logical
nodes, the IEC 61850-7-410 is used for the same purpose in
hydroelectric power plants. The IEC 61400 parts 25-2 and 25-
3 are also used for information modeling and information
exchange modeling respectively in wind power plants.
Legacy SCADA protocols, such as IEEE P1815 (DNP3)
and T104, are not fully capable of fulfilling the requirements
and all expected functions of future smart power systems.
Moreover, both are designed for low bandwidth control and
monitoring operations. In addition, the semantic content of
their messages are not machine readable. At the same time, the
new SCADA standard, IEC 61850, uses the MMS as a
communication protocol that is not suitable for
communication with control centers (SCADA systems). On
the other hand, future smart power system devices will require
high bandwidth and rapid communications that are better
supported by the IEC 61850 and hence, the information
models of IEC 61850-7-4 and 61850-7-420 mapped to the data
objects of T104 or IEEE P1815 are proposed here for DERs
control and monitoring. For the wind power plant, this is
specified by the IEC 61400-25-4 standard. For IEC 61850-7-4,
the standard IEC 61850-80-1 can be used for the mapping to
T104 and for mapping to IEEE P1815 the National Institute of
Standards and Technology (NIST) has recently launched a
project for this purpose called Priority Action Plan (PAP 12)
[4].
Choosing the right legacy protocol, for mapping, depends
on many factors. Although both have the same origin, which is
IEC 60870-5-101, the IEEE P1815 is a general SCADA
protocol. On the other hand, the amount of data to be sent and
received from the DER interface, to the SCADA system may
influence the efficiency of the whole system. While, the
maximum size of the APDU in the T104 is 255 bytes
including the header and control bytes, its minimum size is 6
6
IEC 870-5-104 (T104)
IEC 61400-25-2/3
Fig. 4. Standards for RESs interfaces in vertical communication.
bytes. In the IEEE P18115, the size of the APDU may vary
between 0 and 2048 bytes. Hence, T104 may require a large
number of ASDUs to send data, which may lead to a loss of
efficiency, in this case. In the same sense, the IEEE P1815
usage is limited to small amount of data that have large-sized
packets.
An important difference between both protocols is the type
of data sent in each ASDU. While IEEE P1815 allows
multiple data objects in one ASDU frame, only data objects of
the same type can be transmitted in one T104 ASDU. In
contrast to T104 that uses request/response mechanism, IEEE
P1815 can use both request/response and event mechanisms,
via TCP/IP connections and UDP/IP connections respectively.
Which protocol to be chosen, depends on the application
and on the needs of the customer, especially the amount of
traffic between the control center and the DER interface unit.
As the IEEE P1815 protocol has variable length ASDUs, can
carry different data types in the same frame, and supports both
communication mechanisms, it would be the right choice for
mapping the IEC 61850 information objects.
As shown in Fig. 4, SCADA/EMS (Energy Management
System) supervises, controls, optimizes and manages
generation and transmission systems. However, SCADA/DMS
(Distribution Management System) performs the same
functions for power distribution networks. Both systems
enable utilities to collect, store and analyze data from
thousands of data points in national or regional networks,
perform network modeling, simulate power operation,
pinpoint faults, preempt outages, and participate in energy
trading markets [15]. In general, the main functionalities of the
control center can be summarized as follows: load frequency
control (LFC)/automatic generation control (AGC), economic
dispatching, state estimation, contingency analysis, security
alerts and alarms [16]. These functionalities must be
automated in Smart Grids to achieve a reliable and stable
power system. This can happen by applying international
standards to the inverter and between the inverter and other
associated DER SW/HW applications, components and
networks for physical control as well a business functions.
 7

As shown in Fig. 5, the inverter can act as a multifunctional hence, be able to connect to the advanced meter infrastructure
grid interface device, by converting it into an IED, and (AMI), for billing purposes as a business-related function.
applying specific information models of the IEC 61850-7-4 Moreover, the database of the inverter may contain owner
and 61850-7-420 to an IED inside the inverter. Fortunately, information, latitude, longitude, and other customer data.
the logical nodes of the IEC 61850 can be modeled using the These can be communicated to the customer information
functional blocks (FBs) of IEC 61499 and enhanced with system (CIS) and geographic information system (GIS) via
intelligence, which results in an executable model of an Web Services. The outage management system (OMS) may
automation agent. According to [17], they were able to apply use SCADA information, GIS information, CIS information,
this architecture for simple fault location. Here we are trying and AMI information among other information in order to
to apply the same idea on the inverter for physical control. As complete its functionality. This mandates the usage of ESB
MASs are not standardized yet, this approach could convert based on EDA and SOA (MOM and Web Services)
the inverter into an automation agent that mimics MAS, acts architectures for business integration and inter-application
autonomously and collaborates with other inverters to achieve integration, as shown in Fig 5. This architecture can be built
the power system reliability and stability, as shown in Fig. 5. based on IEC 61968 (DMS), which is dedicated for
Using this architecture, vertical and horizontal application integration at electric utilities [18]. It defines
communications can be achieved, and therefore, inverters can interfaces for the DMS that consists of various distributed
communicate in peer-to-peer for physical control, in addition application components for the utility to manage electrical
to the hierarchical structure that can be achieved as well. distribution networks. These capabilities include monitoring
On the other hand, the IEC 62056 standard can be applied and control of equipments for power delivery, management
for metering between DER meter equipment and the control processes to ensure system reliability, voltage management,
center. Adding the metering functionality to the inverter gives demand-side management, outage management, work
it the ability to count the injected power into the main grid and management, automated mapping and facilities management.

Distributed control and management based on IEC 61968 (DMS) Legend

GIS Geographic Information System
OMS GIS DR
Outage Geo-spatial DR DR Demand-Response
XML-Based Data XML-Based Data XML-Based Data
OMS Outage Management System

AMI Advanced Meter Infrastructure

ESB = EDA + SOA = MOM (SMTP) + SOA (Web Services: WSDL, SOAP/HTTP)
CIS Customer Information System

SCADA Sup. Control & Data Acq.

XML-Based XML-Based XML-Based
Operation MDMS ESB: Enterprise Service Bus
Customer AMI
SCADA CIS
Data Data Management Repository EDA: Event Driven Architecture

SOA: Service Oriented Architecture

SOAP/HTTP

7
IE

MOM: Message Oriented Middleware

6-4
SMTP
EE

05
P1

62

SOAP: Simple Object Access Protocol

815

C
IE

MDMS Meter Data Mngment System

DERs Grid 1 DERs Grid 2
IP-based WAN
(Internet / Intranet) Mapping IEC 61850 Information
Objects to IEEE P1815 Data Objs
IEC 61850-7-4/420 IEC 61850-7-4/420
3~ Inverter as IED/RTU
IEEE P1815 for Physical Control & Web Services for Business Functions 3~ 3~ =
IEC 61499

IEC 62056

3~ 3~
IEC 62056
IEC 61499

= =
= =
- +
Local Area Network (LAN)
DB DB
DB Database
DB

DERs Grid 3 Photovoltaic (PV)

IEC 61850-7-4/420 IEC 61850-7-4/420 Fuel Cell

IEC 61499

IEC 62056

3~ DB
IEC 62056
IEC 61499

3~ DB IEC 61850-7-4/420 IEC 61850-7-4/420

= = - + Battery
IEC 61499

IEC 62056

IEC 61499

IEC 62056

3~ DB 3~ DB
= =
Diesel Generator
- + - + - +

Fig. 5. Application of standards to the inverter for control and integration of DERs, vertical and horizontal communications over IP-based WAN.
 8

According to [18], the IEC 61968 is relevant to loosely
coupled applications with more heterogeneity in languages,
operating systems, protocols and management tools. It is
intended to support applications that need to exchange data on
an event driven basis. The standard is intended to be
implemented with middleware services that broker messages
among applications, and will complement, but not replace
utility data warehouses, database gateways, and operational
stores. Hence, the ESB introduces its architecture for the DMS
in order to implement all these functionalities.
In the ESB, the EDA architecture complements the SOA
architecture because services can be activated by triggers fired
on incoming events, which satisfies the intended
implementation of the IEC 61968.
VI. CONCLUSION
This paper introduced the inter-application, inter-device,
and application-to-device interoperability in future Smart
Grids that include many RESs and DERs together with their
accompanying SW/HW systems. The paper shows that inter-
device and device-to-application interoperability can be solved
via IEC 61850 information objects modeled with IEC 61944
functional blocks, mapped to IEEE P1815 data objects, and
applied to the inverter as an automation agent. This increases
the functionality of the inverter, converts it into an IED, and
gives it the ability to communicate horizontally in peer-to-peer
with other inverters for physical control, in addition to the
vertical communication that can be achieved as well.
Moreover, the billing functionality can be applied to the
inverter, as a multifunctional grid interface device; via the IEC
62056 to achieve business-related functions as well. On the
other hand, the ESB based on SOA and EDA, built according
to the IEC 61968 interfaces can solve the problem of inter-
application interoperability and information integration. In
addition the ESB offers business-business integration medium.
[9] S. Vinoski, "An Overview of Middleware," 9th International
Conference on Reliable Software Technologies Ada-Eroupe 2004, Palma
de Mallorca, 14-18 June 2004.
[10] A. Gokhale et al., "Applying model-integrated computing to component
middleware and enterprise applications," Communications of the ACM,
vol. 45, no. 10, pp. 65-70, Oct. 2002.
[11] Telecontrol Equipment and Systems-Transmission Protocols-Network
Access for IEC 60870-5-101 Using Standard Transport Profiles, IEC
Standard 60870-5-104-2006.
[12] Communication Networks and Systems in Substations, IEC Standard
61850-SER-2010.
[13] Wind Turbines: Communications for Monitoring and Control of Wind
Power Plants, IEC Standard 61400-25-2006.
[14] Electricity Metering: Data Exchange for Meter Reading, Tariff and Load
Control, IEC Standard 62056-2006.
[15] The evolution of SCADA/EMS (from ABB). [Online]. Available:
http://www.abb.com/cawp/gad02181/7ff771bfb4d81e96c1256e3900525
82f.aspx. Last accessed Sep. 2010.
[16] Anjan Bose, "Power System Control Centers: New Vision," EPCC
workshop, Duplin, Ireland, June 2009. [Online]. Available:
http://www.epcc-workshop.net/pdf/final/33%20BOSE.pdf
[17] V. Vyatkin, G. Zhabelova, N. Higgins, K. Schwarz, and N.–K. C. Nair,
"Towards Intelligent Smart Grid Devices with IEC 61850
Interoperability and IEC 61499 Open Control Architecture," IEEE Conf.
on Transmission and Distribution, New Orleans, 2010, pp. 1–8.
[18] Application Integration at Electric Utilities: System Interfaces for
Distribution Management, IEC Standard 61968-1-2003.

VII. REFERENCES
[1] E. Ortjohann, W. Sinsukthavorn, A. Mohd, M. Lingemann, N. Hamsic,
and D. Morton, "A Hierarchy Control Strategy of Distributed Generation
Systems," IEEE Int. Conf. on Clean Electrical Power, Capri, 2009, pp.
310–315.
[2] W. Sinsukthavorn, E. Ortjohann, M. Lingemann, S. Jaloudi, and D.
Morton, "Grid integration strategy for multifunctional grid front-end
based distributed generation," EPE-PEMC, Ohrid, 2010, pp. T11-1–
T11-7.
[3] An IEEE announcement “IEEE lays groundwork for adoption of DNP3
protocol as new IEEE standard”. [Online]. Available:
http://standards.ieee.org/announcements/2010/pr_DNP3newstandard.ht
ml. Last accessed Sep. 2010
[4] IEC 61850 Objects/DNP3 mapping (6.2.2). A proposed project of NIST
in 2009. [Online]. Available: http://www.nist.gov/smartgrid/upload/12-
IEC_61850_DNP3_Mapping.pdf
[5] A. Mohd, E. Ortjohann, W. Sinsukthavorn, M. Lingemann, N. Hamsic,
D. Morton, "Isochronous Load Sharing and Control for Inverter-based
Distributed Generation," IEEE International Conference on Clean
Electrical Power ICCEP, Capri, Italy, August 2009, pp. 324-329.
[6] Douglas C. Schmidt, Software Technologies for Developing Distributed
Systems: Objects and Beyond. (2007). [Online]. Available:
http://www.cs.wustl.edu/~schmidt/PDF/CSI-article.pdf
[7] Michel Barbeau, Evangelos Kranakis, Principles of ad hoc networking.
John Wiley and Sons, 2007.
[8] Ian Sommerville, Software Engineering. Addison-Wesley, 2006.