INTERNSHIP REPORT
USE OF IEC 61850 FOR ASSET MANAGEMENT
IN LOW VOLTAGE MICROGRIDS
TG PHAM (s1164163)
MSc Telematics EEMCS
01112012 to 28022013
Alliander
Utrechtseweg 68
6812 AH Arnhem
The Netherlands
Supervisor
Frans Campfens
Senior Innovative Manager
franscampfens@alliandercom
University of Twente
PO Box 217
7500 AE Enschede
The Netherlands
Academic supervisor
Dr ir Georgios Karagiannis
karagian@csutwentenl
i
Preface and acknowledgement
For four months from November 2012 till February 2013 I did an internship at Alliander an
energy distribution company which covers large areas in the Netherlands Alliander core
business involves distributing gas and electricity to a huge amount of customers which is
about nearly a third of the Netherland’s population This internship project is a part of my 2
year master program which I conduct at University of Twente the Netherlands
Figure 01 – Alliander electricity and gas distribution grid copied from [12]
I worked on an assignment project to investigate the use of the IEC 61850 standard for asset
management of LV Microgrids The main content of the project is to use the IEC 61850
standardized data model and services to model the smart electrical equipment and investigate
the interaction between different components within a network topology for Microgrids asset
management This topic suits my major in telematics and also brought me to a very new and
interesting area of using communication technologies in electricity network Through the
assignment I did not only gain a lot of knowledge but more importantly I also had a great
chance to sharpen my skills in a professional working environment Not less important than
the communication technologies that I have learnt is the communication skills that I have
ii
been trained and practiced through giving presentations discussing with the supervisors
experts in the field and other staffs within and outside the company
I am very appreciated to Mr Frans Campfens my supervisor at Alliander Frans gave me
very intime valuable instructions and put me in contact with experts in the field like Mr
Marco Janssen president and CEO at UTInnovative who gave me extensive guidance
regarding many practical issues I also would like to express my gratitude to Dr ir G
Karagiannis for his permission to be my academic supervisor and more importantly for his
enthusiastic encouragements and precious instructions during my internship period He gave
me intime feedback on my research and helped to organize an interesting presentation in
which I could present my ideas and achievements to other professors and researchers of the
faculty
Throughout the internship I have also learnt many things about the Dutch culture whose
benefits are far beyond what I could learn in a normal project In short I would like to thank
Alliander and University of Twente Internship Office for introducing me to this great
opportunity in which I have developed myself both academically professionally and socially
iii
Table of contents
List of Figures v
List of Tables vii
List of Abbreviations viii
Chapter 1 Introduction 1
11 Problem statement and research objectives 2
111 Problem statement 2
112 Research Objectives 2
12 Organisation of this report 3
Chapter 2 Technical descriptions 4
21 Description of IEC 61850 4
211 Scope of IEC 61850 4
212 Standardization approach 5
213 Content of the IEC 61850 series 6
214 Extensibility of IEC 61850 8
215 IEC 61850 data modelling principle 8
216 IEC 61850 communication services 10
217 Specific communication service mapping 13
22 Smart Grid and Microgrids 20
221 Smart Grid 21
23 Summary 22
222 Microgrids 23
Chapter 3 IEC 61850 network designing and data modelling for microgrids
components 25
31 Communication network designing 25
311 Microgrids power diagram 25
312 Communication network topology for LV Microgrids power control and asset
management 26
32 IEC 61850 data modelling 29
321 Extension rule for logical nodes 30
iv
322 IEC 61850 data modelling for Microgrids components 31
33 Summary 37
Chapter 4 Applying IEC 61850 data models and services for microgrids for LV
microgrid asset management 39
41 Overview on asset management 39
42 Asset management use case 42
421 Description of the Use Case 42
422 Actor (Stakeholder) Roles 43
423 Information exchanged 43
424 Step by Step Analysis of Function 44
43 Realization of use case with IEC 61850 49
431 Scenario 1 49
432 Scenario 2 63
433 Mapping ACSI services to MMS 66
44 Summary 68
Chapter 5 Conclusion and future work 69
References 71
v
List of Figures
Figure 21 – Scope of application of IEC 61850 copied from [1] 5
Figure 22 – Links between IEC 61850 parts copied from [1] 7
Figure 23 – IEC 61850 specifying approach copied from [1] 8
Figure 24 – Relationship between functions logical nodes and physical nodes copied from
[1] 9
Figure 25 – Overview of IEC 61850 functionality and profiles copied from [4] 14
Figure 26 – GOOSE and SV peertopeer data value publishing model copied from [4] 18
Figure 27 – Sampled value mapped to serial unidirectional multidrop point to point link
copied from [23] 19
Figure 28 – Transformation from traditional to future electricity grid copied from [12] 21
Figure 29 – Conceptual model of smart grid copied from [13] 22
Figure 210 – Microgrids architecture copied from [16] 23
Figure 31 – LV microgrids diagram 26
Figure 32 – Communication network topology for LV Microgrids power control and asset
management 28
Figure 33 – IEC 61850 data modeling copied from [1] 29
Figure 34 – Basic extension rules diagram copied from [3] 30
Figure 35 – Conceptual organization of DER logical devices and logical nodes copied from
[7] 32
Figure 36 Logical devices in proxies or gateways 37
Figure 41 Message flow for Scenario 1 of Asset Management use case 46
Figure 42 Message flow for Scenario 2 of Asset Management use case 48
Figure 43 TWOPARTYAPPLICATIONASSOCIATION (TPAA) class syntax [4] 49
Figure 44 Relations between classes in an IEC 61850 server 50
Figure 45 Instantiation of generic classes 51
Figure 46 IEC 61850 server structure and the related services 52
Figure 47 Example of GetServerDirectory and GetServerDirectory service used by HCMC
54
Figure 48 A reference with a functional constraint 56
vi
Figure 49 Example of GetDataValues service used by HCMC 57
Figure 410 Example of GetAllDataValues service used by HCMC 59
Figure 411 HCMC retrieves device name plate information 61
Figure 412 An example of report service configuration 63
Figure 413 HCMC performs health monitoring using GetDataValues service 64
Figure 414 HCMC uses reporting services on the device to perform health monitoring 65
Figure 415 HCMC uses reporting service on a switch to detect communication problems 66
Figure 416 Mapping GetDataValues to MMS Read service to get measurement value 68
vii
List of Tables
Table 21 – ACSI classes [4] 11
Table 22 – Service and protocols for GSE management and GOOSE communication A
profile [8] 16
Table 23 – GOOSEGSE Tprofile [8] 17
Table 24 – Time Sync AProfile [8] 20
Table 31 – Smart household appliances and their typical characteristics 33
Table 32 – ZAPL class 34
Table 33 – Extension to STMP class 35
Table 34 – ZHCM class 36
Table 41 Additional Bridgedata objects in LPHDB added to LN LPHD [17] 41
Table 42 Additional Bridgedata objects in LCCHB added to LN LCCH [17] 41
Table 43 Actor (Stakeholder) Roles 43
Table 44 Information exchanged between actors 43
Table 45 Preconditions and Assumptions 44
Table 46 Steps to implement function Scenario 1 45
Table 47 Steps to implement function Scenario 2 47
Table 48 MMS objects and services copied from [8] 67
Table 49 Mapping of GetDataValues service parameters copied from [8] 67
viii
List of Abbreviations
ASN1 Abstract Syntax Notation Number One
ACSI Abstract Communication Service Interface
BRCB BUFFEREDREPORTCONTROLBLOCK
CT Current Transformer
DER Distributed Energy Resource
DPWS Devices Profile for Web Services
EPRI Electric Power Research Institute
ES Energy Storage
EV Electric Vehicle
GOOSE Generic Object Oriented Substation Events
GSE Generic Substation Event
GSSE Generic Substation State Event
HCMC Home Control and Management Centre
HI Hybrid Inverter
HMI Human Machine Interface
ICMP Internet Control Message Protocol
IEC International Electrotechnical Committee
IED Intelligent Electronics Device
IEEE Institute of Electrical and Electronics Engineers
IP Internet Protocol
LN Logical Node
LD Logical Device
LV Low Voltage
MMS Manufacturing Message Specification
MV Medium Voltage
ix
OSI Open System Interconnection
PUAS Power Utility Automation System
PV Photovoltaic
RCMC Regional Control and Management Centre
RTU Remote Terminal Unit
SCADA Supervisory Control and Data Acquisition
SCSM Specific Communication Service Mapping
SG3 Smart Grid Strategy Group
SNTP Simple Network Time Protocol
SOE Sequence of Event
TC57 Technical Committee 57
TCP Transmission Control Protocol
UCA Utility Communication Architecture
UDP User Datagram Protocol
uPNP Universal Plug and Play
URCB UNBUFFEREDREPORTCONTROLBLOCK
VT Voltage Transformer
1
Chapter 1
Introduction
Many believe that there is a need for the current power grid to undergo a profound change to
evolve into a more modern grid The current oneway power distribution infrastructure has
existed for several decades and cannot cope with the emerging challenges nowadays for
examples the penetration of distributed energy resources (DERs) electric vehicles (EVs) the
need for higher resiliency against failures better security and protection etc This
modernized grid often termed as Smart Grid IntelliGrid GridWise etc [19] [20] is
considered the future of the electricity grid with the integration of advanced information
communication technologies (ICT) in order to efficiently deliver sustainable economic and
secure electricity supplies [1]
In fact communication networks have been in existence for several decades along with the
power grid for monitoring and protection control but the network architecture has not
changed much since the first day [21] Power utilities still do not have much insight into
distribution network where nearly 90 of all power problems come from [16]
In the distribution network the lowvoltage (LV) part (less than 1kV) is a challenge for the
control and management of the power grid as it involves the participation of households with
their various private assets such as DERs storages EVs A household may form a cluster
known as microgrid which includes the local generators storages loads and control These
microgrids may be integrated into a larger grid when power and information exchange among
them are available [16]
IEC 61850 emerges as the promising protocol for the future smart grid It was designed to
ensure interoperability of the communication between Intelligent Electronic Devices (IEDs)
in substation automation systems An IED is the microprocessor based device that performs
several protective control and similar functions The main idea of IEC 61850 to break down
the functions of IEDs into core functions called Logical Nodes (LNs) Several logical nodes
can be grouped into a Logical Device (LD) which provides communication access point of
IEDs By standardizing the common information model for each LN and the associated
services IEC 61850 provides the interoperability among IEDs of different manufacturers in
substation automation systems
2
IEC 61850 has been extended outside the scope of substation automation systems to cover
DERs EVs and the communication to control centre Therefore it can potentially be applied
to the power control and asset management of LV microgrids where private assets like
DERs EVs are present
Power control functions are important in LV microgrids as the system performs the
modulation of the equipment energy consumptionsgenerations Power control within LV
microgrids also supports Demand Response for dynamic load operation On the other hand
asset management involves the tasks of the system to obtain an overall status of the
equipment participating in the microgrid such as the list of devices within the scope and their
capabilities the health monitoring of the devices and alarm handling
11 Problem statement and research objectives
111 Problem statement
As briefly described IEC 61850 was originally designed for communication in substation
automation systems and later was developed to support communication to DER and to
control centre with the objective of solving the interoperability problem caused by the co
existence of multiple proprietary communication protocols However in the progress of
transforming from the traditional centralized grid to distributed smart gird the energy
consumers also play a notlessimportant role than the energy producers According to
European Technology Platform definition of smart grid [13] – the future electricity grid
smart grid should allow consumers to play a part in optimizing the operation of the system
Nevertheless in the area of communication in home automation systems and microgrids there
are still many different protocols for control and management of the smart appliances
therefore interoperability is still a serious problem to be solved
112 Research Objectives
Based on the observation that IEC 61850 has great flexibility and extensibility the main
research objective of this assignment is to use IEC61850 for low voltage Microgrids asset
management The goal is to apply the concepts of IEC 61850 to a different domain the LV
microgrid to perform inventory management configuration management device monitoring
and alarm handling
The main objective above can be decomposed to 3 smaller objectives
3
Objective 1 Designing a communication network topology in LV Microgrids
Objective 2 Modelling LV Microgrids electrical components
Objective 3 Applying IEC 61850 services for asset management in LV Microgrids
A welldesigned network topology is required for seamless communication between various
kinds of smart electrical components in a typical microgrid such as the RegionalHome
control and management centre the controllable Distributed Energy Resources (DER)
including Photovoltaic (PV) panel wind turbine energy storage (ES) electric vehicle
(EV)…and the smart household appliances
To allow those devices communicate with each other using IEC61850 protocol those devices
needs to be modelled as IEC61850 data objects The data objects which defined in a
standardized way also allow interoperable actions between different equipment inside a
microgrid Because the initial scope of IEC61580 is for substation automation many data
objects needed for smart appliances have not been defined yet and modelling those devices is
an important task in this project
Finally when the network topology and data objects of the equipment are available the
IEC61850 services will be applied to perform all the management functions such as getting
device information configuring reporting service on the device etc To illustrate how those
services can be applied for these tasks a use case will be firstly defined explain the capability
of the IEC61850 protocol to support asset management in LV microgrids
12 Organisation of this report
The report is organized as follows Chapter 2 will introduce a technical description about the
related concepts such as IEC61850 standard smart gird and microgrids Chapter 3 is about
communication network topology of LV Microgrids components Chapter 4 gives a specific
use case to demonstrate the usage of these models and services for asset management of LV
Microgrids The conclusion and future work will be given in Chapter 5
Chapters 2 and 3 in both the Internship reports of TG Pham and AD Nguyen are exactly
the same since they have been developed and written by both authors of these two reports
The reason of this is that the students worked during their Internship on solving issues
focussing on similar research areas and where the first part of their research activity was
identical
4
Chapter 2
Technical descriptions
This chapter describes the concept and architecture of IEC 61850 as well as the motivation
of transforming from the conventional centralized electricity grid to a distributed intelligent
electricity grid of the future which is called Smart Grid An important part of the Smart Grid
which supports the distribution automation of the Smart Grid is called Microgrids will also be
explained within this chapter This chapter is based largely on the official documents of the
international standard IEC 61850 [1 8] and a published document by the Smart Grid Strategy
Group – SG3 about the roadmap of Smart Grid [11]
This chapter is organized as follows Section 21 describes the IEC 61850 standards Section
22 explains the concept of Smart Grid and the origin of Smart Grid designing decision
Section 23 gives a description about Microgrids and the structure of a Microgrid Finally
Section 24 summarizes the technical descriptions provided in this chapter
21 Description of IEC 61850
211 Scope of IEC 61850
IEC 61850 was initially designed for communication in substation automation systems by
Institute of Electrical and Electronics Engineers – IEEEElectric Power Research Institute –
EPRI Utility Communication Architecture (UCA) and the working group Substation Control
and Protection Interfaces within the International Electrotechnical Committee (IEC)
Technical Committee (TC) 57 The development of advanced and powerful microprocessors
supported the possibility for building Power Utility Automation System (PUAS) [1] and
consequently several Intelligent Electronics Devices (IEDs) was created each of which
support proprietary communication protocol from its manufacturer However the coexisting
of various proprietary communication protocols led to the big challenge of interoperability
and therefore required investment for complicated and costly protocol converter when using
IEDs from different vendors [1]
IEC 61850 was initialized to solve the interoperability problem by defining standard
semantics abstract communication services which can be mapped to different protocols
5
configuration descriptions and engineering processes [1] From the original scope of
communication within substation automation systems IEC 61850 standard has been extended
to support communication to Distributed Energy Resources (DER) and are being developed
for communication to control centre and feeder automation domain [1]
Figure 21 – Scope of application of IEC 61850 copied from [1]
Figure 21 represents the scope of the IEC 61850 with updates about the possible extension of
the protocol in the future It shows that currently IEC 61850 has been adopted for the
communications inside substation and from control centre (SCADA – Supervisory Control
and Data Acquisition) to the Remote Terminal Unit – RTU and to the DERs In the future
the standard will be extended to support the communications between the Control Centre and
Power Utility substation as well as to the Medium Voltage – MV network
212 Standardization approach
IEC 61850 provides a huge variety of communication functions which allow telecontrol
teleprotection supervision and monitoring between different IEDs in an electric power
6
system The standardization approach of IEC 61850 series as mentioned in IEC 61850part 1
[1] is to blend the strength of three methods
Functional decomposition is used to understand the logical relationship between
components of a distributed function which is decomposed and represented as Logical
Nodes (LNs)
Data flow modelling is used to understand the communication interfaces that must
support the exchange of information between distributed functional components and
the functional performance requirements
Information modelling is used to define the abstract syntax and semantics of the
information exchanged
In short IEC 61850 decomposes and standardizes the functions as logical nodes classified
the communication interfaces between different functional levels and models the information
exchange in term of data objects data attributes and abstract communication services
213 Content of the IEC 61850 series
IEC 61850 consists of many parts which explain the standard stepbystep from general
information such as the introduction and overview in part 1 the glossary in part 2 the general
requirements in part 3 system and project management in part 4 to the communication
requirements and specifications in part 5 part 6 and part 71 to 74
As IEC 61850 is an internationally standardized abstract method of communication and
integration between multivendor IEDs it’s needed to be mapped to specific protocols to
support different functional requirements for protection control supervision and monitoring
Therefore parts 81 91 92 of the standard define the specific communication mapping
Additionally the standard also defines guidelines of using the logical nodes to models the
functions of a substation automation system (part 7500) a hydro power plant (part 7510)
and distributed energy resources (part 7520) The object models for hydro power plant and
distributed energy resources are defined respectively in part 7410 and 7420
As the standard is still in development it’s going to cover more areas such as power inverters
for DER systems (part 907) for electric mobility (part 908) for storage (part 909) DER
scheduling (part 9010) Figure 22 shows the overall structure of IEC 61850 standard
In short the basis rule of setting the numbers to documents in IEC 61850 is [1]
7
74xx documents are normative definition of domain specific name spaces
75xx documents are informative application guidelines of the 7x documents ie
providing guidance on how to model application functions based on part 7x
8x documents are normative definitions of the ACSI mapping (except
communication services related to sample values)
9x documents are normative definitions of the ACSI mapping dedicated to
communication services related to sample values
80x documents are additional informative Technical Specifications related to
communication mapping
90x are additional informative Technical Reports for further enhancementextensions
of the IEC 61850 domains
Figure 22 – Links between IEC 61850 parts copied from [1]
8
214 Extensibility of IEC 61850
A significant advantage of IEC 61850 is the split between the communication and application
as illustrated in Figure 23 By specifying a set of abstract services and objects IEC 61850
allows the user to design different applications without relying on the specific protocols As a
consequence the data models defined in IEC 61850 can be used on the diversity of
communication solutions
This fact is the source of motivation for me to propose an extension of IEC 61850 to support
communication between control centre and smart appliances and DERs which has not yet
been proposed by any parts or technical reports within IEC 61850 series The method of
using IEC 61850 data models and abstract services to manage microgrids electrical
components will be described in details in chapter 3 and 4
Figure 23 – IEC 61850 specifying approach copied from [1]
215 IEC 61850 data modelling principle
An important remark of applying IEC 61850 is the data modelling process which brings the
advantage of interoperability to IEC 61850 by modelling all the data in a standardized syntax
and format following an objectoriented method
There are two main levels of modelling [1]
9
The breakdown of a real device (physical device) into logical devices
The breakdown of logical device into logical nodes data objects and attributes
Logical device is the first level of breaking down the functions supported by a physical
device ie an IED A logical device usually represents a group of typical automation
protection or other functions [1] The Logical Device hosts communication access point of
IEDs and related communications services and provides information about the physical
devices they use as host (nameplate and health) or about external devices that are controlled
by the logical device (external equipment nameplate and health)
Logical nodes are the smallest entities decomposed from the application functions and are
used to exchange information It supports the free allocation of those entities on dedicated
devices (IEDs) It is illustrated in Figure 24
Based on their functionality a logical node contains a list of data with dedicated data
attributes which have a structure and welldefined semantic
Figure 24 – Relationship between functions logical nodes and physical nodes copied
from [1]
Figure 24 illustrates the decomposition of an application functions to multiple logical nodes
which represents the smallest entities to exchange information It also represents the
10
allocation of logical nodes to physical devices For example the Distance protection function
can be decomposed to 6 different logical nodes which are the Human Machine Interface
(HMI) to represent the data to user the Distance Protection and Overcurrent protection
logical nodes – DistProt and OC Prot to perform protection action the breaker to break the
circuit and the Bay Current Transformer (CT) and Voltage Transformer (VT) to provide
measurement data for identifying the problem These logical nodes can be placed on
individual devices such as HMI on station computer (physical device 1) breaker on Bay
control unit (physical device 4) and Bay CT and Bay VT on current and voltage transformer
respectively Or more than one logical node can be allocated in the same physical device such
as the Distance protection and Overcurrent protection logical nodes located on the same
physical device 3 Distance protection unit with integrated overcurrent function
Many definitions of the typical logical nodes for substation automation systems can be found
in IEC 6185074 [6] and further details about the data attributes are explained within IEC
6185073 [5]
216 IEC 61850 communication services
Besides standardizing the data format in an objectoriented manner IEC 61850 also defines a
set of abstract services for exchanging information among components of a Power Utility
Automation System These services are described in details in part 72 of the standard [4]
The categories of services are as follows [1]
retrieving the selfdescription of a device
fast and reliable peertopeer exchange of status information (tripping or blocking of
functions or devices)
reporting of any set of data (data attributes) Sequence of Event SoE – cyclic and
event triggered
logging and retrieving of any set of data (data attributes) – cyclic and event
substitution
handling and setting of parameter setting groups
transmission of sampled values from sensors
time synchronization
11
file transfer
control devices (operate service)
Online configuration
The complete Abstract Communication Service Interface – ACSI services are shown in Table
21 The description of these classes can be found in [4]
Table 21 – ACSI classes copied from [4]
GenServer model
GetServerDirectory
Association model
Associate
Abort
Release
GenLogicalDeviceClass model
GetLogicalDeviceDirectory
GenLogicalNodeClass model
GetLogicalNodeDirectory
GetAllDataValues
GenDataObjectClass model
GetDataValues
SetDataValues
GetDataDirectory
GetDataDefinition
DATASET model
GetDataSetValues
SetDataSetValues
CreateDataSet
DeleteDataSet
GetDataSetDirectory
LOGCONTROLBLOCK model
GetLCBValues
SetLCBValues
QueryLogByTime
QueryLogAfter
GetLogStatusValues
Generic substation event model –
GSE
GOOSE
SendGOOSEMessage
GetGoReference
GetGOOSEElementNumber
GetGoCBValues
SetGoCBValues
Transmission of sampled values model
MULTICASTSAMPLEVALUE
CONTROLBLOCK
SendMSVMessage
GetMSVCBValues
SetMSVCBValues
UNICASTSAMPLEVALUE
CONTROLBLOCK
SendUSVMessage
GetUSVCBValues
SetUSVCBValues
12
SETTINGGROUPCONTROLBLOCK
model
SelectActiveSG
SelectEditSG
SetSGValues
ConfirmEditSGValues
GetSGValues
GetSGCBValues
REPORTCONTROLBLOCK and LOG
CONTROL
BLOCK model
BUFFEREDREPORTCONTROL
BLOCK
Report
GetBRCBValues
SetBRCBValues
UNBUFFEREDREPORTCONTROL
BLOCK
Report
GetURCBValues
SetURCBValues
Control model
Select
SelectWithValue
Cancel
Operate
CommandTermination
TimeActivatedOperate
Time and time synchronization
TimeSynchronization
FILE transfer model
GetFile
SetFile
DeleteFile
GetFileAttributeValues
Data Set – permit grouping of data objects and data attributes
Substitution – support replacement of a process value by another value
Setting group control – defines how to switch from one set of setting values to
another one and how to edit setting groups
Report control and logging – defines conditions for generating report and log There
are two classes of report control BUFFEREDREPORTCONTROLBLOCK
(BRCB) and UNBUFFEREDREPORTCONTROLBLOCK (URCB) For BRCB
the internal events that trigger the report will be buffered so that it will not be lost due
to transport flow control constraints or loss of connection For URCB internal events
issues immediate sending of reports on a best effort basis ie if no association exits
or if the transport data flow is not fast enough events may be lost
13
Control blocks for generic substation event (GSE) – supports a fast and reliable
systemwide distribution of input or output data values peertopeer exchange of IED
binary status information for example a trip signal
Control block for transmission of sampled values – fast and cyclic transfer of
samples for example of instrument transformers
Control – describes the services to control for example a device
Time and time synchronization – provides the time base for the device and system
File system – defines the exchange of large data blocks such as programs
For implementation the abstract services will be mapped on different protocol profiles the
selection of an appropriate mapping depends on the functional and performance requirements
and will be described in the next section
217 Specific communication service mapping
As stated above the mapping of the services to different protocol profiles is based on the
functional and performance requirements Due to the different requirements for transfer time
of difference functions inside the substation IEC 61850 classifies the messages exchanged
between the devices to several types [4]
Type 1 (Fast messages)
Type 1A (Trip)
Type 2 (Medium speed messages)
Type 3 (Low speed messages)
Type 4 (Raw data messages)
Type 5 (File transfer functions)
Type 6 (Time synchronisation messages)
The required transfer times rely upon the requirements of the function for example the trip
message to open the circuit breaker for protection is very time critical (3 ms) in order to
prevent damage to the system however the transfer time for file transfer functions to transfer
a large amount of data is nontimecritical (can be 10000 ms)
14
Figure 25 provides the mapping of these messages to different protocol profiles Messages of
type 1 1A and type 4 which are timecritical are mapped directly on Ethernet Messages of
type 2 3 and 5 which are used for automation autocontrol functions transmission of event
records reading and changing setpoints…etc require message oriented services [2 4] The
Manufacturing Message Specification – MMS provides exactly the information modelling
methods and services required by the ACSI MMS services and protocol can operate over the
full OSI and TCPIP compliant communication profiles [4] This is also the only protocol that
easily supports the complex naming and services models of IEC 61850 [22] This protocol
also includes the exchange of realtime data indications control operations and report
notifications This mapping of ACSI to MMS defines how the concepts objects and services
of the ACSI are to be implemented using MMS concepts objects and services This mapping
allows interoperability across functions implemented by different manufacturers [4]
Figure 25 – Overview of IEC 61850 functionality and profiles copied from [4]
2171 Manufacturing message specification – MMS
MMS is a clientserver communication model MMS defines difference between the entity
that establishes the application association and the entity that accepted the application
15
association The entity that establishes the association is the client and the one that accepts
the association is the server
Due to the clientserver model the client can request for the data at any point of time when
the association is valid The message exchanged will follow a requestresponse manner
MMS also supports the report service For the report service instances of a report control
blocks which include the values of the data object to be reported to the client are configured
in the server at configuration time The server can restrict access to an instance of a report
control block to one or more clients
The report will be triggered based on the configured triggered conditions which represented
by the attribute TrgOp Some typical trigger options for report generation are datachange
which relates to the change in a value of DataAttribute representing the processrelated value
of the data object qualitychange which relates to a change in the quality value of a
DataAttribute and dataupdate which relates to a freeze event in a value of a DataAttribute
representing a freeze value of the data object (for example frozen counters) or to an event
triggered by updating the value of a DataAttribute [4]
The dataupdate triggered condition can be used to provide periodic report generation with
the statistics values that may be calculated or updated periodically
In MMS the triggered conditions are encoded as a PACKET_LIST with the datatype bit
string which represents an ordered set of values defined when the type is used
Bit 0 reserved
Bit 1 datachange
Bit 2 qualitychange
Bit 3 dataupdate
Bit 4 integrity
Bit 5 generalinterrogation
MMS is based on Open System Interconnection (OSI) model with an adaptation layer (RFC
1006) layer for emulating OSI services over TCPIP [22] MMS application protocol is
specified in Abstract Syntax Notation Number One (ASN1) format that is a notation for
describing the data structure
16
2172 GOOSE services communication profile
The Generic Object Oriented Substation Events – GOOSE provides fast and reliable system
wide distribution of data based on a publishersubscriber mechanism (Generic Substation
Event – GSE management) GOOSE is one of the two control classes within the GSE control
model (the other is Generic Substation State Events – GSSE)
GOOSE uses Dataset to group the data to be published The use of Dataset allows grouping
many different data and data attributes Table 22 shows the application profile (Aprofile) of
GSEGOOSE services
Table 22 – Service and protocols for GSE management and GOOSE communication A
profile copied from [8]
Instead of mapping to the TCPIP profile like MMS GOOSE is mapped directly to Ethernet
The transport profile (Tprofile) for GSEGOOSE can be found in table 23
17
Table 23 – GOOSEGSE Tprofile copied from [8]
GOOSE provides an efficient method of simultaneously delivery of the same generic
substation event information to more than one physical device through the use of multicast
services GOOSE messages contain information that allows the receiving device to know that
a status has changed and the time of the last status change [8] GOOSE sending is triggered
by the server by issuing SendGOOSEmessage service The event that causes the server to
invoke a SendGOOSEmessage service is a local application issue as defined in [4] such as
detecting a fault by a protection relay
2173 Sampled Value
Sampled Value or Samples of Measured Values (SMV) is the protocol for transmission of
digitized analogue measurement from sensors (temperature current transformer voltage
transformer)
Sampled value messages are exchanged in a peertopeer publishersubscriber mechanism
like GOOSE messages However GOOSE uses the multicast model while SMV can be
unicast or multicast Figure 26 sketches the comparison between GOOSE and SMV
communication models
18
Figure 26 – GOOSE and SV peertopeer data value publishing model copied from [4]
The transmission of sampled value is controlled by the MULTICASTSAMPLEVALUE
CONTROLBLOCK – MSVCB if multicast is used and by the UNICASTSAMPLE
VALUECONTROLBLOCK – USVCB if unicast is used
The transmission rate of the sampled value can be altered by configuring the Data Attribute
SmpMod which specifies the definition of units of samples ie unit of samples per nominal
period samples per second or seconds per sample and the SmpRate which specifies the
sample rate with the definition of units of sample defined by SmpMod
Basically SMV can be mapped to Ethernet with different configuration as defined in part 91
[23] and part 92 [24] of the IEC 61850 series
Part 91 maps the Sampled Value to a fixed link with preconfigure Dataset Figure 28
presents the communication profile defined in part 91
19
Figure 27 – Sampled value mapped to serial unidirectional multidrop point to point
link copied from [23]
Part 92 provides a more flexible implementation of SMV data transfer by allowing a user
configurable Dataset in which the data values of various sizes and types can be integrated
together
2174 Generic Substation State Events – GSSE
This control model is similar to GOOSE However the GSSE only supports a fixed structure
of status data to be published meanwhile the data for the GOOSE message is configurable by
applying data sets referencing any data [4]
2175 Time Sync
The time synchronization model must provide accurate time to all IEDs in a power utility
system for data time stamping with various ranges of accuracy eg millisecond range for
reporting logging and control and microsecond range for sample values [4]
20
Time synchronization protocol used by IEC 61850 to provide synchronization between IEDs
is Simple Network Time Protocol – SNTP Table 24 shows the application profile of the
Time Sync service
Table 24 – Time Sync AProfile copied from [8]
The transport layer uses the Internet Control Message Protocol (ICMP) and User Datagram
Protocol (UDP) over IP and Ethernet
22 Smart Grid and Microgrids
Traditionally the electricity grid was built as a centralized control network with the
unidirectional power flow from the massive electricity generation like hydrothermal power
plants via the transmission grids and distribution grids to the customers [13] This centralized
control network was suitable with the clear separation between customers who were almost
pure consumers and the massive power plants which generated all electricity for both
domestic and industrial demands
However the traditional energy resources such as gas oil and coal are nonrenewable The
massive electricity production has led to a global decline of gas oil and other natural
resources The rapid development of many developing countries alongside with the
population explosion led to the severe energy shortages in the late of 20th century More
importantly using these energy resources has led to seriously negative effects on human like
including CO2 pollution global warming climate change and etc For example the climate
change caused more than 36 million of displacement and evacuation in 2008 according to
United Nations Office for the Coordination of Humanitarian Affairs and the Internal Displace
ment Monitoring Centre [14]
As it was vital to find new energy resources for a sustainable future many renewable energy
resources have been explored during the last few decades including the wind turbine
Photovoltaic panel heat pump…leading to a great transformation of the electricity grid from
unidirectional power flow with centralized control network to bidirectional power flow with
distributed control centres
21
Figure 28 – Transformation from traditional to future electricity grid copied from [12]
Figure 28 illustrates the transform from a traditional electricity grid to an intelligent
electricity grid The traditional grid shown in the figure only requires the oneway
communication due to the unidirectional energy flow from the centralized power plants to the
consumers However with the rapid growth of the Distributed Energy Resources – DERs
such as wind farms solar panels the contribution of those distributed generations is
considerable It is desired to utilize these resources which provide many advantages such as
renewable and environmentfriendly nature However using these resources also introduces
new issues such as voltage stabilizing energy balancing pricing and so on These problems
require the construction of a bidirectional communication network to support all the
automation supervision and control as well as monitoring functions Therefore the second
generation of the electricity grid is being designed with a new communication infrastructure
to support the twoway communications between all the active intelligent components within
the grid and to the control centres
221 Smart Grid
According to European Technology Platform Smart Grid the definition of Smart grid is [13]
A Smart Grid is an electricity network that can intelligently integrate the actions of all users
connected to it – generators consumers and those that do both – in order to efficiently deliver
sustainable economic and secure electricity supplies
22
Smart grid consists of the smart elements from customer prosumer such as smart
consumption which enable demand response or home automation systems building
automation systems to bulk generation with increased use of power electronics and power
grid (Transmission and Distribution) including substation automation systems power
monitoring system energy management system asset management system and condition
monitoring distribution automation and protection [13] Figure 29 provides an overall
architecture of the Smart grid with the participation of many elements from the energy
generation the transmissiondistribution networks to the customers with the services and
managements from the markets operations and service provider
23 Summary
This chapter provided an overall picture of IEC 61850 standard including the scope of the
standard data models abstract services communication protocols and communication
profiles mapping These theories will be applied to achieve the objectives of the research in
chapter 3 and chapter 4 Moreover descriptions of the Smart Grid and Microgrids were also
described in this chapter This background information will help to clarify the new domain of
IEC 61850 proposed by this research
Figure 29 – Conceptual model of smart grid copied from [13]
23
In short the key idea of smart grid is the use of more and more intelligent controllable
devices with high level of interoperability to build a sustainable economic and secure
electricity network
222 Microgrids
Microgrids describe the concepts of managing energy supply and demand using an isolated
grid that can island or connect to the utility’s distribution Smart Grid [15] Therefore
Microgrids are crucial part in order to achieve an overall Smart Grid with the participation of
consumers
From the above definition of Microgrids we can decompose the three main parts of a
Microgrid as energy supply load and the control part for managing the energy supply and
demand It is illustrated in Figure 210
An important objective of building Microgrids is to create selfcontained cells with use of
distributed energy resources in order to help assure energy supply in distribution grids even
when the transmission grid has a blackout [11]
Figure 210 – Microgrids architecture copied from [16]
Basically there are three elements for control and management within a microgrid the
distributed energy generators the energy storages and the household appliances which
24
consume energy The design of the control algorithm and management system should be able
to provide best energy efficiency and resilience to failures
In addition to the energyrelated issues another very important aspect to be considered is the
privacy and convenience for the customers Therefore the functions like access control have
to be taken into consideration
25
Chapter 3
IEC 61850 network designing and
data modelling for microgrids
components
Chapter 3 describes the communication network designing and data modelling processes
which are the two very important research tasks in order to allow power control and asset
management of Microgrids through using IEC 61850 data models and services As being
emphasized above the current covering areas of IEC 61580 include communication in
substation automation systems between substations and to DERs Therefore for microgrids
distribution automation and home automation systems before we can use the IEC 61850
services for communication between devices we have to model those devices as IEC 61850
data models and design a network topology to support seamless communication between
different components Moreover although IEC 61850 facilitates modelling a lot by giving
many object models for common functions like measurement metering monitoring…etc
there are still some missing pieces for building a diversity of functions for household
appliances like tuning the temperature of an electric heater or refrigerator This chapter will
explain how to model new devices and new functions as IEC 61850 models
31 Communication network designing
In this part a simple but typical communication network will be presented to allow the
communication between different actors in a Microgrid which support the use of IEC 61850
data models and services for power control and asset management
311 Microgrids power diagram
Normally LV Microgrids consist of three building blocks the DERs including energy
distributed generators like PV panel and energy storage and the electrical loads which
consumes energy LV Microgrids can operate in islanding mode or grid connected mode but
26
the latter is chosen for the scope of this research Therefore a typical LV Microgrid can be
illustrated in the following figure
Figure 31 – LV microgrids diagram
Figure 31 illustrates a typical LV Microgrid which consists of the Smart houses and the
public Distributed Energy Resources (DERs) In this case the components of this LV
Microgrid can be classified to three types energy consumers energy generators and energy
storages The energy consumers are the household electrical appliances inside the houses
The energy generators are the public Low voltage DERs such as wind turbine or PV panel
and the possible DERs in the houses The energy storages which can be a controllable battery
systems are used to store the energy that can be used for emergency or other future plans A
special component here is the Electric vehicle (EV) which can be seen as both the energy
load and energy storage
312 Communication network topology for LV Microgrids power control and
asset management
According to the current version of IEC 61850 the underlying communication network
infrastructure is standardized is Ethernet Therefore we need to build an Ethernetbased
27
communication network to connect all the Microgrids equipment Within this research a
network topology was designed for that purpose
According to the current version of IEC 61850 the standardized underlying communication
network infrastructure is Ethernet Therefore we need to build an Ethernetbased
communication network to connect all the Microgrids equipment
This network was designed as a hierarchical topology in which each Smart house will be
represented as a subnet and these subnets create a kind of field area network The control and
management part of this regional microgrid is the Regional control and management centre
(RCMC) which is also connected to the field area network Physically the each subnet and
RCMC should connect to an Ethernet switch to establish communication links between
RCMC and each subnet
There can also be some public DERs Electric vehicles that should be managed by the RCMC
and therefore they should have an Ethernet connection with RCMC through connecting to
the Ethernet switch
Another important aspect is protection which is handled by the protection device and the
Circuit breaker (modelled by XCBR Logical Node) However because the messages for
protection are very timecritical they are handled by another protocol (GOOSE) instead of
the protocol for control and management purposes (MMS) which produces higher delay
Due to the scope of this research the protection part will not be analysed The protection
device and circuit breaker in Figure 32 is just for illustration of a typical LV Microgrid with
the control protection and asset management functions
28
Figure 32 – Communication network topology for LV Microgrids power control and
asset management
As shown in Figure 32 within a smart home there is a Home control and management
centre (HCMC) which is in charge of controlling and managing all the inhome private DERs
and smart household appliances
There are some motivations behind this hierarchical topology First by having HCMC
control and manage inhome the equipment we achieve a highly distributed management
layer which reduces the amount of information to be kept at the regional level Second the
users have their control over the information they share with the utility A HCMC can work
as a proxy or gateway in the homeneighbourhood boundary using the IEC 61850 proxy
feature that will be discussed later in this chapter
The Home control and management centre can handle the Demand Response Signal sent
from the Regional control and management centre to manage the energy
consumptionproduction of the house HCMC can control the household appliances to
modulate their energy consumption and the DERs to modify their power production ability
RCMC is capable of monitor and if permissible manage the HCMCs in order to efficiently
utilize the available energy of the grid
29
32 IEC 61850 data modelling
The main idea of IEC 61850 is to breakdown a physical device in to logical devices each of
which will be further broken down into logical nodes data objects and data attributes [1]
The Logical Device hosts communication access point of IEDs and related communication
services and is hosted by a single IED However there’s no rule on how to arrange Logical
Devices into a physical device which brings a great flexibility to the user
Logical Nodes are the smallest entities which are derived from the application functions
Logical nodes are the building blocks of the standard since they represents the smallest
functions of the device The scope of this project is about microgrids control and asset
management which is very different from the scope of substation automation systems
therefore many new functions must be modelled The next clause will describe how to model
a new function as IEC 61850 Logical Nodes
Figure 33 – IEC 61850 data modelling copied from [1]
Figure 33 illustrates the principle of IEC 61850 data modelling In this case a physical
device IEDx is composed of a logical device LDx in which there are two different logical
nodes XCBR and MMXU XCBR1 and MMXU1 are the two instances of the logical node
class XCBR and MMXU which represent the circuit breaker and the measurement unit
respectively
30
Each logical node is composed of many data object In this example logical node XCBR1
contains the data object Pos which represents the position of the circuit breaker This data
object consists of many data attribute among which are StVal attribute for setting the position
of the breaker to open or close q attribute stands for quality of the data and t stands for time
of operating the function
321 Extension rule for logical nodes
The rule for extension or definition of new logical nodes is defined in IEC 61850 part 71 [3]
Figure 34 – Basic extension rules diagram copied from [3]
The rules modelled in Figure 34 can be briefly summarized as follow [3]
If there is any Logical Nodes Class which fits the function to be modelled an instance
of this logical node shall be used with all its mandatory data (M)
31
If there are dedicated versions of this function with the same basic data different
instances of this Logical Node Class shall be used
If there are no Logical Nodes Classes which fit to the function to be modelled a new
logical node shall be created according to the rules for new Logical Nodes
322 IEC 61850 data modelling for Microgrids components
There are 3 types of equipment to be modelled in a typical LV Microgrid
Distributed energy resources (DER) Photovoltaic – PV panel electric vehicle energy
storage…
Smart household appliances LCD TV electric heater refrigerator…
Control and management centres RegionalHome control and management centre
3221 Distributed energy resources
Following the extension rule for logical nodes above we mostly utilize the existing logical
nodes defined in the standard part 7420 [7] the draft technical reports part 907 [9] and part
908 [10] for modelling the DERs Additionally the object models for wind turbine can be
found in series IEC 6140025 Communications for monitoring and control of wind power
plants In Figure 35 we can see many existing logical nodes defined for substation
automation systems were applied for DERs and also many new logical nodes defined to
represent the new functions of DERs
32
Figure 35 – Conceptual organization of DER logical devices and logical nodes copied
from [7]
Because there’s no strict rule on the arrangement of logical devices on physical device it’s
not necessary to implement all of the logical nodes in Figure 35 to a DER Actually depend
on the specific locations and application requirements of the DER only respective logical
nodes should be added
For simplification in home automation systems only the PV panel is used as the distributed
generator and the energy storage is the battery which also connects to the PV through a
hybrid inverter for charging purpose The hybrid inverter allows the reverse flow of power
from the PV and energy storage to the grid in case of emergency or in response to the
Demand Response signal issued by the RCMC as a consequence of peak demand periods
3222 Smart household appliances
As the household appliances are the very new devices to be modelled within IEC 61850 the
first step of modelling should be identification of their characteristics There are hundreds of
33
different household appliances therefore we only take into account the appliances that
consume much energy Table 31 summarizes the typical energyconsuming appliances and
their significant characteristics to be modelled
Table 31 – Smart household appliances and their typical characteristics
Household Electric
Appliances
Television
Electric cooker
Cooker Hood
Microwave
Electric Stove
Dishwasher
Refrigerator
Washing machine
Clothes Dryer
Bread maker
Coffeemaker
Air c
onditioner
Fan
Electric heater
Dishwasher
Electric water heater
Printer
Kettle
Lighting system
Properties
OnOff X X X X X X X X X X X X X X X X X X X
Voltage X X X X X X X X X X X X X X X X X X X
Current X X X X X X X X X X X X X X X X X X X
Frequency X X X X X X X X X X X X X X X X X X X
Energy consumption X X X X X X X X X X X X X X X X X X X
Product information
(serial number
manufacturer…)
X X X X X X X X X X X X X X X X X X X
Temperature
X
X X
X
X X
X
X
X
X
Speed
X
Energy modulation
X
X X
X X X
X X X
X
X
Regarding to the appliances parameters listed above the basic functions required for control
and management of household appliances should be
switching ONOFF the equipment
monitoring the device status
measuringmonitoring the energyrelated parameters (current voltage frequency
energy consumption)
monitoring other parameters (eg temperature)
moderating the energy consumption by alternating the operation modes of the devices
34
Firstly we can see that IEC 61850 provides the two Logical Nodes MMXN and MMTN for
measurement and monitoring of singlephase voltage current frequency and energy
consumption [6] Therefore we should utilize these Logical Nodes to model the energy self
measuring and monitoring functions of the household appliances
Secondly for monitoring the devices in term of physicalproduct information IEC 61850
defines the Logical Node LPHD [6] consist of the physical information of the equipment
which is mandatory for all IEDs Therefore with the Get and Report services it is possible to
get this kind of information for management purposes
Similarly for monitoring other operational parameters such as fan speed temperature
pressure heat…of the devices IEC 61850 also provisions the corresponding Logical Nodes
KFAN STMP MPRS MHET… [7]
Although there are many Logical Nodes existing in the standard that are applicable some
functions for control services not been defined due to the difference in scope between
substation automation systems and home automation systems Energy modulation is the most
important function needed to be modelled but it lacks from the standard Therefore a new
general logical node for all smart appliances named ZAPL was defined as table 32
Table 32 – ZAPL class
This new Logical Node allows retrieving information about the operation status of the
corresponding appliance such as the operation status and operating mode ie the appliance is
working autonomously or following a schedule or being controlled by the user
The function of turning ONOFF the device is also modelled in ZAPL Logical Node since it
is a basic and mandatory function for all devices
35
This Logical Node represents the energy tuning function which is indispensable to manage
the energy consumption of the appliances in order to assure energy efficiency By setting the
load target setpoint the Home control and management centre or the user can modulate the
energy consumption of the appliances
By setting the load target HCMC can manage the energy consumption of all smart
appliances however another way to tune the energy consumption of a device is to directly
change its operational threshold like changing the speed of a fan or the temperature of a
heater or refrigerator
IEC 6185074 defines a Logical Node called STMP for temperature supervision so it is
convenient to utilize this Logical Node and add more data objects to model the temperature
tuning function
Table 33 – Extension to STMP class
As shown in Table 33 a temperature setpoint to the STMP class was added to control the
temperature Therefore an instance of the STMP class with TmpSpt allows tuning the
energy consumption of a heater or refrigerator by changing its output temperature
3223 Control and management centre
Within the scope of this research management of the in home automation systems is the main
issue for concentration HCMC can use IEC 61850 services for communication with the
Logical Nodes in smart appliances to perform management tasks The models for the smart
appliances have been defined in the section above
36
In the regional area it is necessary to model the data and function of HCMC that RCMC can
access and manage For this purpose a new Logical Node ZHCM has been defined as in table
34
Table 34 – ZHCM class
ZHCM class
Data Object
Name
Common
Data Class
Explanation T M
O
C
LNName Shall be inherited from LogicalNode Class (see IEC 6185072)
Data Objects
EEHealth ENS External equipment health O
EEName DPL External equipment name plate O
OpTmh INS Operation time O
Status
Oper SPS Operation status of the Home control and management center M
OperMod ENS Operating mode
Value Explanation
1 Autonomous
2 Controllable
99 Other
M
Settings
MaxWh ASG Setpoint of maximum energy consumption O
In this Logical Node there is a data object OperMod which represents the operating mode of
HCMC If HCMC is configured to be controllable then RCMC can use the data object
MaxWh to change the allowed maximum energy consumption of the house
If there is no error and the control function succeeds HCMC will then control the inhome
DERs and appliances to reduce the energy consumption in response to the Demand response
signal sent from RCMC
As stated earlier in this chapter HCMC can be used to control the amount of information that
the users want to share with their utility HCMC can act as a gatewayproxy by hosting the
logical devices that it permits the outside world to see An illustration of this feature is shown
in Figure 36
37
Figure 36 Logical devices in proxies or gateways
The HCMC can be viewed as the physical device D in the figure A B and C can be different
smart appliances or DER within the home system If HCMC permits the devices to be viewed
by the outside world it can copy the logical device from them As only HCMC should
connect with the RCMC this feature can be employed to provide privacy for the users
33 Summary
This chapter fulfilled the two first objectives of the research Objective 1 – Designing a
communication network topology in LV Microgrids and Objective 2 – Modelling LV
Microgrids electrical components for power control and asset management
In section 31 a communication network topology was designed to allow the information
transmissions among the Home Control and Management Centre – HCMC to all the Smart
38
appliances inside the smart houses as well as connecting all the HCMCs and public DERs to
the Regional Control and Management Centre at regional domain Due to the current version
of IEC 61850 that standardizes Ethernet as the layer 2 protocol this network was built over
Ethernet However it is also possible for future research on applying another underlying
protocol for transmitting the IEC 61850 information such as wireless or cellular networks
Section 32 gives a further details about IEC 61850 data modelling principles which were
mentioned in chapter 2 More importantly this section described how to use those principles
in practice by modelling the LV microgrid electrical components with IEC 61850 data
objects This section also defined some new logical nodes to represent for the very important
control and management functions such as ZAPL and ZHCM logical nodes However it is
crucial to realize that this research has utilized almost the existing logical nodes defined in
IEC 61850 documents to model very different components in a very different area with the
substation automation systems This shows the great possibility of extending the scope of IEC
61850 to other area in order to provide interoperability to the future Smart Grid
39
Chapter 4
Applying IEC 61850 data models
and services for microgrids for LV
microgrid asset management
The goal of this chapter is to apply the IEC 61850 services on the object models that have
been defined in chapter 3 in order to support asset management within the LV microgrids in a
specific use case
The use case is not meant to cover all the functionalities of LV microgrid management tasks
as there have to be hundreds of use cases to achieve this Instead the use case is provided to
illustrate some typical behaviours and interactions of the components within smart home
system (considered as a LV microgrid) for the specific management tasks In the use case the
management tasks are performed by the Home Control and Management Centre (HCMC) It
is the entity that manages other equipment in the home system such as smart appliances
DER and also networking devices The advantage of this design is the HCMC has an overall
picture of the equipment to be managed inside the home and provides a single portal for the
users to keep track of their equipment (eg health operation status and settings) and notifies
the users when a problem happens via the alarm handling functions
IEC 61850 has been applied for the IEDs within substation automation systems and had
tremendous success Its object models have been extended to cover also DERs EVs power
plants etc The main contribution of this chapter and also of this report is to demonstrate that
with the IEC 61850 models defined in chapter 3 and the existing IEC 61850 services IEC
61850 is capable of performing management tasks which is a new application in a new
domain for IEC 61850
41 Overview on asset management
An asset management system is a crucial part in an electrical system as it provides a
systematic way to maintain and ensure normal operation of physical assets and also provides
an information base for other applications such as smart control system planning etc
40
In this report asset management is defined as the composition of the following tasks
Inventory management the management system keeps track of the list of devices to
be managed together with their related information eg vendor serial number
location etc
Configuration management the management system maintains the configuration and
settings of the devices
Device monitoring the management system acquires the current status of the devices
eg device health measurement data etc
Alarm management the management system handles the alarm generated by the
devices when certain problems occur
Within a smart home context the devices to be managed are smart appliances DERs and also
networking devices (such as switches) In order to do the management of these assets there
are two possible approaches [17]
The first approach is the HCMC uses SNMP for management tasks SNMP is a wellknown
protocol and is supported by almost all networking devices The management information is
structured into Management Information Base (MIB) objects SNMP an extensible protocol
as different vendors can define their private MIBs beside the list of standard MIBs To follow
this approach data objects and attributes of smart appliances and DERs need to be mapped to
SNMP MIBs and HCMC has to implement SNMP
The second approach is to use IEC 61850 MMS protocol for management tasks This
alternative to SNMP protocol requires the networking equipment to support IEC 61850 and
models for these devices have to be defined
The following sections will further describe the second approach which is using IEC 61850
MMS services for management tasks Considering IEC 61850 has been used for the control
functions using the same protocol for management tasks would enable the simpler design
and implementation of the system It also allows seamless integration of networking devices
smart appliances and DERs for both control and management functions
As stated above models for networking devices have to be defined IEC 61850904
describes the extension to existing Logical Nodes (LPHD LCCH) to support information
models for the physical bridge (LPHDB) bridge ports (LCCHB) and also the information
that these models contain in relation with SNMP MIB objects Some of these models are
listed in Table 41 and 42
41
Table 41 Additional Bridgedata objects in LPHDB added to LN LPHD [17]
In Table 41 the existing logical node LPHD is extended to add additional physical
characteristics of a bridge eg whether the bridge is the root of the layer 2 spanning tree or
the settings of VLAN ID or Mac address filtering
Table 42 Additional Bridgedata objects in LCCHB added to LN LCCH [17]
42
Table 42 provides some extensions to the existing LN LCCH (Physical Communications
Channel Supervision) including the port status (bit rate duplex mode port VLAN ID etc)
These additions shown in Table 41 and 42 are important especially for large layer 2 Ethernet
network where maintaining the forwarding spanning tree is important Within smart home
automation what we are interested in is the status of the bridge port connected to IEDs The
status is contained in the existing data object ChLiv (physical channel status) in LN LCCH
42 Asset management use case
The scope of this use case is about the management of smart appliances networking devices
DERs (referred to as managed devices or devices for the rest of this chapter) within
Smart Home Automation system The management system is implemented in the HCMC
The information exchange using IEC 61850 data models and services among the devices will
also be specified
421 Description of the Use Case
In IEC 61850 the configuration of devices must be done offline using engineering tools
Currently IEC 61850 does not specify the autoconfiguration or autodiscovery of the
devices This is considered disadvantages of IEC 61850 when applied to the Smart Home
domain where ideally the equipment should have the plugandplay capability This feature
is being proposed by [18] in which the combination of Universal Plug and Play (uPnP) and
Devices Profile for Web Services (DPWS) is investigated for a plugandplay reference
architecture of IEC 61850
This Use Case presumes that the HCMC and the managed device have been configured to be
able to exchange information and the Use Case is divided into two scenarios
In the first scenario the HCMC obtains the capabilities of the new managed device creates a
database entry for it and configures the device for additional services such as reporting This
is an important task for asset management as it provides a database of devices that are
working within the smart home context This information can then be used for other tasks
such as power control
43
In the second scenario the configured managed device interacts with the HCMC HCMC
keeps an uptodate database of the device when there is change to ensure normal operation
The HCMC generates alarms under abnormal conditions
422 Actor (Stakeholder) Roles
Below are the actors within this use case These are the entities that have interaction through
information exchange to perform the use case
Table 43 Actor (Stakeholder) Roles
Actor
Name
Actor Type (person
organization device system
or subsystem)
Actor Description
HCMC Subsystem Home Control and Management Centre
controls and manages DERs Smart
Appliances network devices
Managed
device
Device The device to be managed (smart appliances
DER network devices)
423 Information exchanged
The information exchange among the actors is listed in the table below
Table 44 Information exchanged between actors
Information Object
Name
Information Object Description
DeviceCapability
request
The request from HCMC to a managed device to obtain its
capabilities
DeviceCapability
response
The capabilities of a managed device sent to HCMC
NamePlateData request The request from the HCMC to the device to get name plate
information of the device
NamePlateData The name plate information provided by the devices to the
44
Information Object
Name
Information Object Description
response HCMC This information is defined in the IEC 61850 object
models The name plate contains information about the vendor
serial number location etc of the devices
StatusSetting request A command sent from the HCMC to request the status and
settings of the device
StatusSettingData A message which contains information about the status and
settings of the device
Configuration A command sent from the HCMC to configure the device (eg
reporting services)
ConfigurationConfirm A message which contains confirmation about the current
configuration of the device
Report A report contains a set of data attributes that are configured to be
sent from the device to the HCMC
424 Step by Step Analysis of Function
4241 Step to implement function – Scenario 1
In order to perform the function listed in Scenario 1 there are preconditions and assumptions
for HCMC and device see Table 45
Table 45 Preconditions and Assumptions
ActorSystemInformationContract Preconditions or Assumptions
Managed device Has been implemented with autodiscovery
functions to join discover and selfconfigure to
work with HCMC
HCMC Has known the existence of the device (eg having
the IP address of the device by the discovering
process) and needs to connect to the device to
acquire more information
45
The stepbystep analysis of the activities needed to perform the defined task in Scenario 1 is
shown in Table 46
Table 46 Steps to implement function Scenario 1
# Primary
Actor
Name of
ProcessAc
tivity
Description of
ProcessActivity
Informati
on
Producer
Informa
tion
Receiver
Name of Info
Exchanged
11 HCMC Browses
device
capabilities
HCMC browses
device for its
capabilities
HCMC Managed
device
DeviceCapability
request
12 Managed
device
Returns
device
capabilities
Managed device
returns its capabilities
to HCMC
Managed
device
HCMC DeviceCapability
response
13 HCMC Requests
name plate
information
HCMC polls the
device for name plate
information using an
IEC 61850 browser
HCMC Managed
device
NamePlateData
request
14 Managed
device
Responds
with name
plate
information
Managed device
responds with name
plate information
Managed
device
HCMC NamePlateData
response
15 HCMC Checks for
duplicate
devices
HCMC checks the
database for existing
device entry
HCMC HCMC
16 HCMC Creates a
database
entry for
the device
HCMC creates a
database entry for the
device
HCMC HCMC
17 HCMC Requests
status and
settings of
the device
HCMC polls the
device for status and
settings using an IEC
61850 browser
HCMC Managed
device
StatusSettings
request
18 Managed
device
Responds
with status
information
Device responds with
status information
Managed
device
HCMC StatusSettings
Data
19 HCMC Updates the
device
status and
settings in
the DB
HCMC updates the
status and settings of
the device in the DB
HCMC HCMC
46
# Primary
Actor
Name of
ProcessAc
tivity
Description of
ProcessActivity
Informati
on
Producer
Informa
tion
Receiver
Name of Info
Exchanged
110 HCMC Configures
additional
service on
the device
HCMC configures
additional service on
the device
HCMC Managed
device
Configuration
Data
111 Managed
device
Confirms
the new
configurati
ons
Managed device
confirms the new
configurations
Managed
device
HCMC Configuration
Confirm
Figure 41 shows the interaction between the actors with the activities defined in Table 46
HCMC Managed device
13 Request name plate information
16 Creates a database entry for the device
17 Requests status and settings of the device
18 Status and settings
19 Updates the device status in the DB
110 Send device configurations
111 Confirmation
14 Response name plate information
15 Check for duplication
11 Obtains device capabilities
12 Device capabilities
Figure 41 Message flow for Scenario 1 of Asset Management use case
47
4242 Step to implement function – Scenario 2
The stepbystep analysis of the activities needed to perform the defined task in Scenario 2 is
shown in Table 47
Table 47 Steps to implement function Scenario 2
# Primary
Actor
Description of
ProcessActivity
Informa
tion
Produce
r
Informa
tion
Receiver
Name of Info
Exchanged
11A1 Managed
device
Managed device sends report
to HCMC
Managed
device
HCMC Report
11B1 HCMC HCMC polls devices for status
and settings
HCMC Managed
device
StatusSettings
request
11B2 Managed
device
Managed device responds with
status information
Managed
device
HCMC StatusSettings
Data
12 HCMC HCMC updates the status and
settings of the device in the
DB
HCMC HCMC
13 HCMC HCMC notifies the user if an
alarm is detected
HCMC HCMC
14 HCMC HCMC loses communicate
with the managed device
HCMC HCMC
15 HCMC HCMC waits for a holddown
timer
HCMC HCMC
16 HCMC HCMC deletes the device
entry from the database
HCMC HCMC
(*) HCMC detects a timeout for communication link or get an alarm from network devices
(**) This is to prevent frequent database deleteinsert when there is a frequent change in
communication link between HCMC and the managed device
48
Figure 42 shows the interaction between the actors with the activities defined in Table 47
HCMC Managed device
11B1 (Periodic) Requests status and settings of the device
11B2 Responses with status and settings information
12 Updates the device status and settings in the DB
11A1 Sends reports (eventtrigger alarms etc)
13 Notifies users after an alarm is detected
14 Detects the communication link problems
15 Waits for a holddown timer
16 Deletes the device entry from database
Figure 42 Message flow for Scenario 2 of Asset Management use case
49
43 Realization of use case with IEC 61850
This section is the core of the chapter in which it describes how the IEC 61850 object models
defined in chapter 3 and existing IEC 61850 services can be integrated to realize the
management tasks in the 2 scenarios the use case An example will be given to show the
interaction between the HCMC and some managed devices working in a home automation
system using IEC 61850 The mapping between IEC 61850 models to underlying protocol is
also described
431 Scenario 1
In this scenario HCMC has to retrieve information about managed device to build the entries
for its device database IEC 6185072 provides multiple services to retrieve data However
before performing these services an application association needed to be established
An Application association can be considered an agreement between two parties in which the
party that sends associate message will be the client and the other will be the server In IEC
61850 the method of establishing an application association follows the TWOPARTY
APPLICATIONASSOCIATION (TPAA) class syntax defined in part IEC 6185072 [4]
Figure 43 TWOPARTYAPPLICATIONASSOCIATION (TPAA) class syntax [4]
Figure 43 shows the communication pattern of an IEC61850 client and server In this case
the managed device acts as an IEC 61850 server and the HCMC is the client within the
context of the Smart Home automation system The client can request data from the server in
a requestresponse fashion (confirmed method) or the server can send data to the client
50
without the client initiating the request (unconfirmed method) The confirmed method can be
used when the HCMC wants to get specific information from the devices such as polling the
operation status or getting the current settings on the devices The unconfirmed method can
be used in the reporting services where the manage devices are configured to send some
specific data to the client without having to wait for the client request
The structure of a server implementation is depicted in Figure 44
Figure 44 Relations between classes in an IEC 61850 server
The Meta Model in IEC 6185072 part defines several generic classes such as
GenServerClass GenLogicalDeviceClass GenLogicalNodeClass GenDataObjectClass
51
for the servers (7) logical devices (9) Logical Nodes (10) and data objects (11 12) as well
as services that are supported for each class
One important notice in IEC 61850 is that the services operate on instances of classes only
The generic classes have to be instantiated into entities that have unique identities (termed
instances or objects) Figure 45 shows some specific instances of generic classes MMXN1
is an instance of a generic logical node class MMXN the data object Amp is an instance of
the Common Data Class MV (Measured Values) etc
MMXN1
Amp MV
mag AnalogueValue
FLOAT32
MMXN
GenLogicalNodeClass
GenCommonDataClass
GenDataAttributeClassinstance
LN instance
Data Object class
Data Attributes
f
Sub Data Attributes Basic Type
Figure 45 Instantiation of generic classes
An IEC 61850 server (eg a washing machine) has an access point that determines how it can
be reached The server can serve one or more clients (associations) A server can host several
logical device instances each has different logical nodes instances (functions as defined in
chapter 3) For example a washing machine can have a logical device instance WM01 which
is broken down into logical nodes instances LPHD1 LLN0 MMXN1 MMTN1 ZAPL1
Each of these LN has its own data objects and attributes These attributes can be put in data
sets which can be used for other services such as MMS Services GOOSE SV etc
The next sections will described in details how IEC 61850 services can operate on these
instances to support information exchange as described in Scenario 1
4311 Device capabilities
As logical nodes represent specific functions of a device the HCMC can obtain the list of
LNs within a device to get its functional capabilities This is made possible thanks to the self
description of IEC 61850 in which several GetXXDirectory and GetXXDefinition services
52
are supported The services that are supported in each level of the information object tree is
shown in Figure 46
Figure 46 IEC 61850 server structure and the related services
The HCMC (client) can use the GetServerDirectory service to retrieve a list of the names of
all logical devices made visible on the washing machine (server) The parameters needed to
perform the GetServerDirectory service include
Request
ObjectClass shall contain an identification of the
selected class The client shall select one of the
following classes LOGICALDEVICE or FILE
SYSTEM
Response+ shall indicate that the service request
succeeded A successful result shall return the
following parameter
Reference [0n] shall contain the ObjectReference of the logical devices and file
systems Response
53
Response The parameter Response– shall indicate that the service request failed The
appropriate ServiceError shall be returned
After retrieving the list of logical device instances on the device the HCMC shall use the
GetLogicalDeviceDirectory service to retrieve the list of the ObjectReferences of all
Logical Nodes made visible and thus accessible to the HCMC by the referenced logical
device The parameters needed to perform the GetLogicalDeviceDirectory service include
Request
LDName shall contain the object name of a logical
device
Response+ shall indicate that the service request
succeeded A successful result shall return the
following parameter
LNReference [1n] shall contain the
ObjectReference of the logical devices and file systems
Response The parameter Response– shall indicate that the service request failed The
appropriate ServiceError shall be returned
Assuming that there are no errors with these 2 GetServerDirectory and GetLogicalDevice
Directory requests the HCMC obtains the list of logical nodes of the device hence it knows
its functional capabilities of the device Figure 47 shows an example of the interaction
between the HCMC with a washing machine an electric fan and an electric heater whose
logical nodes are different
54
Washing machineHCMC
GetServerDirectory Request
Param ObjectClass LOGICALDEVICE
GetServerDirectoryResponse+
Param Reference[0n] WM01
Fan Heater
GetLogicalDeviceDirectory Request
Param LDName WM01
GetLogicalDeviceDirectoryResponse+
Param LNReference[1n] [WM01
LLN0 WM01MMXN1 WM01
MMTN1 WM01ZAPL1]
GetServerDirectory Request
Param ObjectClass LOGICALDEVICE
GetServerDirectoryResponse+
Param Reference[0n] FAN01
GetLogicalDeviceDirectory Request
Param LDName FAN01
GetLogicalDeviceDirectoryResponse+
Param LNReference[1n] [FAN01
LLN0 FAN01MMXN1 FAN01
MMTN1 FAN01KFAN1]
GetServerDirectory Request
Param ObjectClass LOGICALDEVICE
GetServerDirectoryResponse+
Param Reference[0n] HEATER01
GetLogicalDeviceDirectory Request
Param LDName HEATER01
GetLogicalDeviceDirectoryResponse+
Param LNReference[1n] [HEATER01
LLN0 HEATER01MMXN1 HEATER01
MMTN1 HEATER01STMP1]
Figure 47 Example of GetServerDirectory and GetServerDirectory service used by
HCMC
55
4312 Device status and settings
After retrieving the list of Logical Node instances on the device the HCMC has several
options to retrieve the status and settings of the device
Option 1 HCMC uses GetDataValues service to retrieve individual data object value
A logical node may have many different data objects each with many data attributes This
option is suitable when HCMC only needs a single value for a particular data attribute (eg
only current power usage or the load setpoints of the device) This option provides the
selectivity for the data retrieval from HCMC and also suits the bandwidthlimited network
Currently Ethernet bandwidth is sufficient but in the future when the protocol is mapped
onto lower bandwidth protocol such as ZigBee this option will help reduce the bandwidth
consumption The parameters needed to perform the GetDataValues service
Request
Reference shall define the functional constrained
data (FCD) or functional constrained data attributes
(FCDA) of the data object whose data attribute values
are to be retrieved The Reference shall be FCD or
FCDA
Response+ shall indicate that the service request
succeeded
DataAttributeValue [1n] The parameter
DataAttributeValue [1n] shall contain the values of
all data attributes of a data object referenced by FCD
or the value of a data attribute referenced by FCDA
Response shall indicate that the service request
failed The appropriate ServiceError shall be returned
The Reference in the GetDataValues Request should have the functional constraint (FC) set
Functional constraint is the property of a data attribute that indicates the services eg read
56
value write value substitute value etc that may be applied to that data attribute Figure 48
shows a data attribute reference WM01MMXNWattmag that represents the power
consumption for the washing machine in Figure 47 This attribute has FCMX which means
the attribute represent a measurand information whose value may be read substituted
reported and logged but shall not be writeable
Figure 48 A reference with a functional constraint
For example the HCMC uses GetDataValues service to retrieve the power usage and
operation status of the washing machine the speed set point of the fan and the temperature
set point of the heater These values are contained in the logical nodes of the appliances that
have been defined in Chapter 3 Specifically the power usage of the washing machine can be
obtained by getting the value of the Watt data object in LN MMXN the operation status is
visible by getting the Oper data object in LN ZAPL (newly defined) the speed set point of
the fan is represented by the Spd data object in LN KFAN and the temperature set point is
included in TmpSpt data object in LN STMP (extended from existing LN) The message
flows and parameters are shown in Figure 49
WM01MMXN1Wattmag [MX]
Instance of MMXN Data Attribute
LDName DataObject
Functional
constraint
MX Functional constraint data attribute (FCDA)
57
Washing machineHCMC
GetDataValuesRequest
Param Reference WM01MMXN1Wattmag [MX]
GetDataValuesResponse+
Param DataAttributeValue [1n] [700] (700 Watts)
Fan Heater
GetDataValuesRequest
Param Reference FAN01KFAN1Spdmag [MX]
GetDataValuesResponse+
Param DataAttributeValue [1n] [10] (10 rotations per second)
GetDataValuesRequest
Param Reference HEATER01STMP1TmpSptsetMag [SP]
GetDataValuesResponse+
Param DataAttributeValue [1n] [24] (24 degrees)
GetDataValuesRequest
Param Reference WM01ZAPL1OperstVal [ST]
GetDataValuesResponse+
Param DataAttributeValue [1n] [TRUE]
Figure 49 Example of GetDataValues service used by HCMC
The HCMC can recursively use the GetDataValues service to get the needed data values
However this is not a very effective method as the HCMC typically needs a lot more data
object values Therefore it can use the GetAllDataValues service (Option 2)
Option 2 HCMC uses GetAllDataValues service in GenLogicalNodeClass to retrieve all
data object values of a Logical Node instance in the washing machine
58
The parameters needed to perform the GetAllDataValues service include
Request
LNReference shall contain the ObjectReference of
the Logical Node (which shall be
LDNameLNName)
FunctionalConstraint (FC) shall contain the
functional constraint parameter (FC) to filter the
respective data attributes of all data objects contained
in the Logical Node
Response+ shall indicate the request
succeededfailed
DataAttributeReference [1n] shall contain the ObjectReference of a data attribute
contained in the Logical Node that shall be returned according to the value of the
FunctionalConstraint received in the request
DataAttributeValue [1n] shall contain the value of a data attribute of the data object
contained in the referenced Logical Node If the parameter FunctionalConstraint is present
in the service request then only values of those data attributes that have the Functional
Constraint as given in the service request shall be returned
Response shall indicate that the service request failed The appropriate ServiceError shall
be returned
For example Figure 410 illustrates the the HCMC using GetAllDataValues service to
retrieve all the measurand values of the measurement function (Functional Constraint MX)
from Logical Node instance MMXN1 of the washing machine KFAN1 of the fan and
STMP1 of the heater
59
Washing machineHCMC
GetAllDataValuesRequest
Param LNReference WM01MMXN1
FunctionalConstraint [01] [MX]
GetAllDataValuesResponse+
Param LNReference WM01MMXN1
DataAttributeReference [1n] [
WM01MMXN1Ampmag WM01MMXN1Ampq
WM01MMXN1Ampt
WM01MMXN1Volmag WM01MMXN1Volq
WM01MMXN1Volt
WM01MMXN1Wattmag WM01MMXN1Wattq
WM01MMXN1Wattt etc ]
DataAttributeValue[1n] [3
220
600
Fan Heater
GetAllDataValuesRequest
Param LNReference FAN01KFAN1
FunctionalConstraint [01] [MX]
GetAllDataValuesResponse+
Param LNReference FAN01KFAN1
DataAttributeReference [1n] [
FAN01KFAN1Spdmag FAN01KFAN1Spdq
FAN01KFAN1Spdt]
DataAttributeValue[1n] [10
GetAllDataValuesRequest
Param LNReference HEATER01STMP1
FunctionalConstraint [01] [MX]
GetAllDataValuesResponse+
Param LNReference HEATER01STMP1
DataAttributeReference [1n] [
HEATER01STMP1Tmpmag HEATER01
STMP1Tmpq HEATER01STMP1Tmpt]
DataAttributeValue[1n] [24
Figure 410 Example of GetAllDataValues service used by HCMC
60
(*) The represented values are for illustrative purposes only The actual data format has to
conform to specific data types defined in IEC 618503 Common Data Classes
4313 Device name plate
The name plate (information about vendor serial number hardwaresoftware revision etc)
of the washing machine is included in the LPHD and LLN0 Logical Nodes This information
will be used to keep track of the device in the database The HCMC can use the
GetDataValues or GetAllDataValues services that have been described in section 3312 to
retrieve the name plate information of the device
For example the HCMC can retrieve the information about the vendor and serial number of
the washing machine fan and heater (Figure 411)
61
Washing machineHCMC
GetDataValuesRequest
Param Reference WM01LPHD1PhyNamvendor [DC]
GetDataValuesResponse+
Param DataAttributeValue [1n] [Toshiba]
Fan Heater
GetDataValuesRequest
Param Reference WM01LPHD1PhyNamserNum [DC]
GetDataValuesResponse+
Param DataAttributeValue [1n] [TOWM1234]
GetDataValuesRequest
Param Reference FAN01LPHD1PhyNamvendor [DC]
GetDataValuesResponse+
Param DataAttributeValue [1n] [Philips]
GetDataValuesRequest
Param Reference FAN01LPHD1PhyNamserNum [DC]
GetDataValuesResponse+
Param DataAttributeValue [1n] [PLFA0001]
GetDataValuesRequest
Param Reference HEATER01LPHD1PhyNamvendor [DC]
GetDataValuesResponse+
Param DataAttributeValue [1n] [Philips]
GetDataValuesRequest
Param Reference WM01LPHD1PhyNamserNum [DC]
GetDataValuesResponse+
Param DataAttributeValue [1n] [PLHT1234]
Figure 411 HCMC retrieves device name plate information
4314 Device configuration
This section only discusses the reporting service configuration of the device It is because the
configuration of the operating status and set points is in the scope of equipment control
within home automation system not asset management The reporting service is important
because it does not require the HCMC to keep polling the devices to get data values Instead
if a report control block is configured in the device (this is the presumption described in
section 321) HCMC can use ACSI services to change the configuration of the report control
block so that when a triggering event happens the reports are sent automatically to the
62
HCMC However HCMC cannot create a new report control block in the device as this has
to be done by IEC 61850 engineering tools This is considered a disadvantage of IEC 61850
We assume there is an UNBUFFEREDREPORTCONTROLBLOCK (URCB)
configured in the device Then the HCMC can use the SetURCBValues service to change
some parameters for this URCB
RptEna enabling or disabling the report service on the device
TrgOps triggering options of the report whether it is due to data change data update
quality change of the attributes
DatSet the data set that comprises of different data attributes which are of interest to be
included in the report
For example the HCMC can enable the report with data change triggering options and a data
set on the heater so that when a temperature rises above the defined threshold a report is sent
(See Figure 412)
63
HCMC Heater
SetURCBValues
URCBRef HEATER01
LLN0AlmRpt
rptEna TRUE
DatSet HEATER01
STMP1DS1
TrgOps datachange
Alarm Temperature Value set point 30 deg
Current Temperature Value 31 deg
Report
RptID AlmRpt1
OptFlds
sequencenumber 123
reporttimestamp 143158
reasonforinclusion datachange
dataset
datasetreference HEATER01STMP1DS1
entrydata
DataAttRef HEATER01STMP1AlmstVal [ST]
Value
(Reporting service configured)
Figure 412 An example of report service configuration
432 Scenario 2
In Scenario 2 the HCMC monitors the operation status of the devices (by polling or by
receiving reports from the devices) The HCMC generates alarms under abnormal conditions
In this Scenario the HCMC also has to monitor the communication link to the devices and
update the device database accordingly
4321 Device health monitoring
Health monitoring is a critical task within asset management as it ensures the normal
operation of the devices The devices have the capability to selfassess and report the current
64
problem it might have eg with the physical (hardware) or logical (software) aspects This
information is contained in PhyHealth data object in LN LPHD and Health data object in
LN LLN0 which can be value 1 (OK green no problems normal operation) 2 (Warning
yellow minor problems but in safe operation) or 3 (Alarm red severe problem no
operation possible)
The HCMC can use the GetDataValues or GetAllDataValues services for health monitoring
of the devices by retrieving the attributes values of the health data objects
Washing machineHCMC
GetDataValuesRequest
Param Reference WM01LPHD1PhyHealthstVal [ST]
GetDataValuesResponse+
Param DataAttributeValue [1n] [1]
Fan Heater
(OK)
GetDataValuesRequest
Param Reference FAN01LPHD1PhyHealthstVal [ST]
GetDataValuesResponse+
Param DataAttributeValue [1n] [2]
GetDataValuesRequest
Param Reference FAN01LPHD1PhyHealthstVal [ST]
GetDataValuesResponse+
Param DataAttributeValue [1n] [3]
(Warning)
(Alarm)
Notifies the user about the alarm
Notifies the user about the warning
Figure 413 HCMC performs health monitoring using GetDataValues service
If the HCMC can use reporting services for health monitoring of the devices by including the
health data object attributes in the report In this case whenever there is a change to the
health data object attribute the device will send reports to the HCMC This option brings less
overhead for the health monitoring as only the changes are sent and the HCMC does not
have to perform polling This method is illustrated in Figure 414
65
HCMC Heater
Report
RptID AlmRpt1
OptFlds
sequencenumber 234
reporttimestamp 173158
reasonforinclusion datachange
dataset
datasetreference HEATER01LPHD1DS1
entrydata
DataAttRef HEATER01LPHD1PhyHealthstVal
[ST]
Value <2>
Device health OK
Device health Warning
Figure 414 HCMC uses reporting services on the device to perform health monitoring
4322 Communication link monitoring
Communication links from the HCMC to the devices have to be continuously monitored to
ensure normal operation of the system The HCMC has to know whether it can reach the
devices it manages If a device is unplugged from the network then the HCMC has to notice
that as well The HCMC can employ the existing keepalive mechanisms of the transporting
protocol in order to detect link failures with the devices
The HCMC can also detect layer 1 and layer 2 problems via communicating with the switch
using IEC 61850 We assume that the switch supports IEC 61850 and it has LN LCCH
implemented as described in section 41 The switch has an instance of LN LCCH for every
switch port and then can represent the communication status of the ports connecting to the
devices The data object attributes ChLiv in the LN LCCH instances can be put in a data set
and be sent as report to the HCMC when there is any change to the data value (port status
changes) Upon receiving this report the HCMC knows of the changes in the communication
links
Figure 415 shows an example in which the washing machine is unplugged from the network
The HCMC notices the communication link is broken after receiving the report from the
switch
66
HCMC Switch
Report
RptID SwRpt1
OptFlds
sequencenumber 1
reporttimestamp 193158
reasonforinclusion datachange
dataset
datasetreference SW01LCCH1DS1
entrydata
DataAttRef SW01LCCH1LCCH1ChLivstVal
[ST]
Value
Unplugged
Washing Machine
Datachange
In LN
LCCH1ChLiv
SW01LCCH1ChLivstVal TRUE
Figure 415 HCMC uses reporting service on a switch to detect communication problems
433 Mapping ACSI services to MMS
In section 332 we have seen that the ACSI services of IEC 61850 are capable of performing
management tasks within the home automation system Since ACSI services are abstract
services they must be mapped to an underlying protocol to allow communication between
HCMC and the devices As described in chapter 2 there are several message types within
IEC 61850 Because management service does not require fast message exchange and
employs the clientserver interaction between the HCMC and the managed devices the ACSI
services are mapped to MMS services as shown in Table 48 [8]
67
Table 48 MMS objects and services copied from [8]
Mapping of IEC 6185072 and IEC 6185073 data attributes can also be found in IEC
6185081 [8] For example Table 49 lists the mapping of the GetDataValues service to
MMS Read service
Table 49 Mapping of GetDataValues service parameters copied from [8]
68
HCMC Washing Machine
initiateRequest
Initiate
Data
Parameters
Presentation Address
ACSI Authentication Value
Parameter
PresentationEndPoint
initiateResponse
Readresponse
Readrequest
VariableAccessSpecification
mmsWM01MMXN1Wattmag
listOfAccessResult 700
ConcludeRequest
ConcludeResponse
Conclude
Figure 416 Mapping GetDataValues to MMS Read service to get measurement value
Figure 416 sketches the mapping of ACSI GetDataValues service to MMS Read service
that allows the HCMC to establish a twoparty association with the washing machine and
retrieve the power consumption in the logical node instance MMXN1 For other services used
in this use case such as GetAllDataValues service SetURCBValues etc a detailed
mapping can be found in IEC 6185081 [8] The MMS PDU (Protocol Data Unit) will be
encoded using ASN1 to have the format of TLV (Tag Length Value) and will be
transported through communication links by the TCPIP transport profile (TProfile) that
MMS supports [8]
44 Summary
This chapter is the core of the report where a typical management tasks are introduced in a
specific use case IEC 61850 services are applied on the object models that have been defined
in chapter 3 in order to support asset management within the LV microgrids including the
inventory management health monitoring device reporting service configuration and alarm
handling functions
69
Chapter 5
Conclusion and future work
IEC 61850 is an extensible protocol to support a growing demand in different domains
Initially it was designed for interoperability of different IEDs within Substation Automation
Systems and then was further extended to support object models for power plants DER and
intersubstation communication
The main goal of the research is to apply the concepts of IEC 61850 to a different domain
the LV microgrid to perform inventory management configuration management device
monitoring and alarm handling Each chapter has fulfilled a specific objective to achieve the
main goal
Specifically a communication network topology is presented in chapter 3 which allows for
the distributed control and management of the LV microgrid with user privacy taken into
account The object models for the components within the LV microgrid are also analysed in
chapter 3 Some of the existing logical nodes for substation domain can be reused while the
missing models are defined either by extending the data objects of the existing logical nodes
or defined as new logical nodes
Based on the defined logical nodes in chapter 3 the IEC 61850 services shown in chapter 4
allow the asset management of the LV microgrid components in a specific use case that
covers typical management tasks The IEC 61850 services that can be used to fulfil these
management tasks are also presented in chapter 4 with the associated parameters of the
services and the mapping to the communication protocol
This research contributes to the development of IEC 61850 by introducing a new domain that
the standard has not yet covered the low voltage network microgrid Within the research
IEC 61850 originally used for substation automation is shown to be capable of performing
asset management within the LV microgrid
There is room for improvement of the standard within the scope of LV microgrid asset
management Future work can define more use cases for different purposes such as voltage
stabilization microgrid islanding etc to see whether IEC 61850 can be used to support these
use cases
70
One shortage of IEC 61850 is the lack of autoconfiguration and device discovery process
that have been described in chapter 4 Currently IEC 61850 requires the use of engineering
tools to configure the devices in offline mode and it would not be convenient within a Smart
Home context More work can be done on the plugandplay features of IEC 61850 such as
[18]
IEC 61850 defines the mapping between ACSI services and underlying protocols such as
Ethernet MMS etc The next step is to investigate how communication technologies such as
ZigBee 80211 3G LTE etc can support the use of IEC 61850 for different applications
from different domains eg metering control and automation
71
References
[1] IEC 618501 TR Ed2 Communication networks and systems for power utility
automation – Part 1 Introduction and Overview 2012
[2] IEC 618505 Communication networks and systems for power utility automation –
Part 5 Communication requirements for functions and device models 2012
[3] IEC 6185071 Ed2 Communication networks and systems for power utility
automation – Part 71 Basic communication structure – Principles and models 2008
[4] IEC 6185072 Ed2 Communication networks and systems for power utility
automation – Part 72 Basic information and communication structure – Abstract
communication service interface (ACSI) 2008
[5] IEC 6185073 Ed2 Communication networks and systems for power utility
automation – Part 71 Basic communication structure – Common data classes 2008
[6] IEC 6185074 Communication networks and systems for power utility automation
– Part 74 Basic communication structure – Compatible Logical Node classes and
data classes 2008
[7] IEC 618507420 Final Draft International Standard (FDIS) Communication
networks and systems for power utility automation – Part 7420 Basic
communication structure – Distributed energy resources Logical Nodes 2008
[8] IEC 6185081 Ed2 Communication networks and systems for power utility
automation – Part 81 Specific Communication Service Mapping (SCSM) – Mapping
to MMS (ISO 95061 and ISO 95062) and to ISOIEC 88023 2009
[9] IEC 61850907 Ed1 Draft Technical Report Communication networks and systems
for power utility automation – Part 907 IEC 61850 object models for photovoltaic
storage and other DER inverters 2012
[10] IEC TR 61850908 Draft Communication networks and systems for power utility
automation – Part 908 IEC 61850 object models for electric mobility 2012
[11] SMB Smart Grid Strategic Group (SG3) IEC Smart Grid Standardization Roadmap
[12] Frans Campfens the Role of the DNO in Smart Grid Cyber Security European
Smart Grid Cyber Security and Privacy Amsterdam November 2011
[13] SMB Smart Grid Strategic Group (SG3) IEC Smart Grid Standardization Roadmap
Edition 10 June 2010
72
[14] United Nations Office for the Coordination of Humanitarian Affairs and the Internal
Displacement Monitoring Centre Monitoring disaster displacement in the context of
climate change 2008
[15] httpsmartgridsherpacomblogdefiningmicrogridstheenablerforlocal
distributedenergyinfrastructuredevelopment
[16] Hassan Farhangi The path of the Smart Grid IEEE power & energy magazine
2010
[17] IEC 61850904 TR Ed1 Communication networks and systems for power utility
automation – Part 904 Network engineering guidelines for substations Draft
Technical Report 2012
[18] Juergen Carstens A Plug & Play Concept for IEC 61850 in a Smart Grid
SIEMENS AG 2011
[19] EPRI's IntelliGridSM initiative [Online] Available httpintelligridepricom
[20] GridWise Architecture Council [Online] Available httpwwwgridwiseacorg
[21] Ericsson Smartgrid communications enabling nextgeneration energy networks
EBR #1 2012
[22] Javier Juárez Carlos RodríguezMorcillo José Antonio RodríguezMondéjar
Simulation of IEC 61850based substations under OMNeT++ Proceedings of the
5th International ICST Conference on Simulation Tools and Techniques 2012
[23] IEC 61850901 Ed 10 Communication Networks and Systems in Substations –
Part 91 Specific Communication Service Mapping (SCSM) – Serial Unidirectional
Multidrop Point to Point Link 2001
[24] IEC 6185092 Ed2 Communication networks and systems for power utility
automation – Part 92 Specific Communication Service Mapping (SCSM) – Sampled
values over ISOIEC 88023 2009
《香当网》用户分享的内容,不代表《香当网》观点或立场,请自行判断内容的真实性和可靠性!
该内容是文档的文本内容,更好的格式请下载文档