A QIP Course on Smart Grid Technology:

Smart Grid Protocols

Ankush Sharma
Assistant Professor
Dept. of EE, IIT Kanpur
E-mail: ansharma@iitk.ac.in
Contents

Various Smart Grid Protocols

IEC 61850 Protocol

Tele-Control Protocols

DLMS/COSEM Protocols
Smart Grid Protocols and Standards
- IEEE C37.118:IEEE Standard for Synchrophasor
- IEC 61850: Power Utility Automation
Measurements for Power Systems
- IEC 61968: Common Information Model (CIM) /
- IEC 61970: Common Information Model (CIM) /
Distribution Management
Energy Management
- IEC 62056: Data exchange for meter reading,
- IEC 60870-6: Inter-Control Center
tariff and load control
Communications Protocol
- DNP 3.0: Interoperability between substation
- IEC 60870-5-104: Network access for IEC 60870-
computers, RTUs, IEDs and master stations
5-101 using standard transport profiles

Major Smart
Grid Protocols/
Standards

- IEC 62351: Security

- IEC 62325: Deregulated energy market
communications standards - IEC 61508: Functional safety of
electrical/electronic/ programmable electronic
- AS 4777: Grid connection of energy systems
safety-related systems
via inverters
- IEEE 1588: Standard for a Precision Clock
- AS 4577: Framework for the control of electrical
Synchronization Protocol for Networked
devices for DRM
Measurement and Control Systems
Smart Grid Protocols and Standards
Other Smart Grid Protocols/ Standards –

Green Button - Initiative to provide utility customers with

easy and secure access to their energy usage information in
a consumer-friendly and computer-friendly format

MultiSpeak - The specification is a standard for the exchange

of data among enterprise application software commonly
applied in utilities

SunSpec - Open interoperability specifications and

information models to achieve plug-and-play
interoperability between Distributed Energy Resource
(DER) components and smart grid applications

SEP 2.0 - Standard for applications that enable home energy

management via wired and wireless devices that support
Internet Protocol
IEC 61850
IEC 61850
Before IEC 61850 -
 Power substations were mostly managed by substation
automation systems that -
 Utilize simple, straightforward and highly specialized communication
protocols
 Less concerned about the semantics of the exchanged data
 Devices from different manufacturers used different
substation automation protocols, disabling them to talk
to each other
 Utilities were paying enormous money and time to
configure the devices to work together in a substation
 Hence, device manufacturers recognized the need for a
unified international standard to support seamless
cooperation among products from different vendors
 The IEC 61850 international standard, drafted by
substation automation domain experts from 22 countries
IEC 61850
 Takes advantage of a comprehensive object-oriented
data model and the Ethernet technology
 Part 1 to Part 3 - general ideas about the standard
 Part 4 – defining the project and management
requirements in an IEC 61850 enabled substation
 Part 5 - specifying the required parameters for physical
implementation
 Part 6 - defining an XML based language for IED
configuration
 Part 7 - elaborating on the logical concepts
 Part 8 – mapping of the internal objects to the
presentation layer and to the Ethernet link layer
 Part 9 - mapping from sampled measurement value
(SMV) to point-to-point Ethernet
IEC 61850 – Substation Architecture
IEC 61850 based Substation Architecture
IEC 61850 – System Overview

Source: ABB
IEC 61850 - Virtualization
Logical Representation of Device in IEC 61850-
IEC 61850 – Object Naming
Anatomy of an IEC61850 Object Name

V A
Functional Constraint
MX MX

Logical Nodes
MMXU1 MMXU2

Logical Device
(e.g. Relay1)

“MMXU2$MX$A” =
Physical Device
(network address)
Feeder #2 Current Measurements
IEC 61850 – Object Naming
Logical node groups

M Metering and measurement

L System LN
S Sensor and monitoring
P Protection
X Switchgear
R Protection related
T Instrument transformers
C Control
Y Power transformers
G Generic
Z Further power system
I Interfacing and archiving equipment
A Automatic control (4)
Examples:
PDIF: Differential protection CSWI: Switch controller
RBRF: Breaker failure MMXU: Measurement unit
XCBR: Circuit breaker YPTR: Power transformer
IEC 61850 – Communication Profile
Application IEC 61850 Communication Profile
Domain
Communication
Stack
IEC 61850 – Communication Profile
IEC 61850 Communication

Source: ABB
IEC 61850 Interface Model

Source: ABB
IEC 61850 - ACSI
Abstract Communications Service Interface - ACSI

 Defines a set of Objects

 Defines a set of Services to manipulate and access those

objects

 Defines a base set of data types for describing objects

 Example ACSI services – GetDataSetValue, CreateDataSet,

DetDataDirectory
IEC 61850 - SMV
Sampled Measured Values (SMV)
IEC 61850 - GOOSE
IEC61850 Generic Object Oriented Substation Event - GOOSE

 Device to multi-device GOOSE Header:

communication – Local or Wide
Area • Multicast Address
 Bridgeable but Non-routable • Name
• Time Until Next GOOSE
 User-defined Dataset sent in an
Ethernet Multicast message • Etc.
 Message sent on change of state as
well periodically to enable
detection of device failure User-Defined Dataset
 Reliability effected through message • Status Information
repeat
• Analog Values
• Data Quality
• Time
IEC 61850 – GOOSE Messaging
IEC 61850 – GSSE/MMS
Generic Substation State Events (GSSE)
 Only Status data can be exchanged through GSSE and it uses a status list
(string of bits) rather than a dataset as is used in GOOSE
 GSSE messages are transmitted directly over IEC/ISO 8802-2 and 8802-3
(IEEE 802.3) using a similar mechanism to GOOSE messages
 As the GSSE format is simpler than GOOSE it is handled faster in some
devices.
 GSSE is being progressively superseded by the use of GOOSE and support
for it may eventually disappear
Manufacturing Message Specification (MMS)
It is a messaging system for transferring real time process data and supervisory
control information between networked devices and/or computer applications.
MMS Defines the following -
 A set of standard objects which must exist in every device, on which
operations like read, write, event signaling etc. can be executed.
 A set of standard messages exchanged between a client and a server
stations for the purpose of monitoring and/or controlling these objects.
 A set of encoding rules for mapping these messages to bits and bytes
when transmitted.
IEC 61850 - SCL
SCL – Substation Configuration Language

 Description language for communication in electrical

substations related to the IEDs

 XML based language that allows a formal

description of -
– Substation automation system and the switchyard and the
relation between them
– IED configuration
– IEC 61850 language used in the XML files is called SCL
language
IEC 61850 - SCL
SCL File Types

SSD: System Specification Description.

 XML description of the entire system.
SCD: Substation Configuration Description.
 XML description of a single substation.
ICD: IED Capability Description.
 XML description of items supported by an IED.
CID: Configured IED Description.
 XML configuration for a specific IED.
IEC 61850 - SCL
SCL File Sample

SSD: System Specification Description.

 XML description of the entire system.
SCD: Substation Configuration Description.
 XML description of a single substation.
ICD: IED Capability Description.
 XML description of items supported by an IED.
CID: Configured IED Description.
 XML configuration for a specific IED.
IEC 61850: The SCL language (IED Modelling)
IEC 61850: The SCL language (IED modelling)
SCL
Bay A Bay Unit (IED)

PTRC (Trip, Operate)

 IEC 61850: The SCL language (IED modelling)
SCL SCL
It is possible to “structure”
the Logical Nodes, and group
them under different Logical
Devices.
The “rules” of this structure
are described in the XML file.
 IEC 61850: Services (IED modelling)
The SCL file also describes what
the IED can do (services).
In this case it seems that the IED
cannot offer upload of
disturbance recorder file, as the
“FileHandling Service” is not
listed:

While this IED allows to upload

the disturbance recorder files
(FileHandling Service” is
listed):
IEC 61850 - CID
CID File Generation
IEC 61850 - CID
CID File Generation
IEC 61850 - SSD
SSD File
IEC 61850-90-5: Mapping with C37.118
IEC 61850-90-5: Mapping with C37.118
IEC 61850
Benefits of IEC 61850

• IEC 61850 normally uses the approach of common information model 
(CIM) of real devices in terms of logical nodes (LN) for standardization
• High‐level services enable self‐describing devices & automatic object 
discovery saving money and effort in configuration and maintenance
• Standardized naming conventions with power system context 
eliminates device dependencies and tag mapping
• Standardized configuration file formats enables seamless exchange of 
device configuration
• Higher performance multi‐cast messaging for inter‐relay 
communications enables functions not possible with hard wires
• Multi‐cast messaging enables sharing of transducer (CT/PT) signals
Tele‐Control Protocols
Tele-Control Protocols for SCADA
 IEC 60870‐5‐101 protocol (Serial mode communication from RTU
to Control Center)
 IEC 60870‐5‐104 protocol (network mode communication from
RTU to Control Center)
 IEC 60870‐6‐502 ( ICCP) protocol (between two Control Canters)
 IEC 60870‐5‐103 protocol (for communication between IEDs in a
Substation)
 DNP 3.0 Protocol (Serial)
 DNP 3.0 Protocol (TCP/IP)
Communication Channel for Information flow

RLDC

Wide Band
Commn
(MW / FO)
SLDC SLDC
Wide Band
Commn
Area-LDC Area-LDC
Wide Band /
PLCC Commn
RTU RTU RTU
Three of the most important part of a SCADA system: Master Station, Remote
Terminal (RTU, PLC, IED), and communication between them
Remote Terminal Unit
 A microprocessor‐controlled electronic device that interfaces
objects in the physical world to an SCADA system
 Transmits telemetry data to a master SCADA system, and control
connected objects based on SCADA Command.
 SCADA master station gets status of a certain circuit breaker from
the mapped status point of an RTU.
 SCADA protocols consist of two message sets or pairs –
 Master protocol, containing the valid statements for master station
initiation or response
 RTU protocol, containing the valid statements an RTU can initiate and
respond to

 the message pairs are considered a poll or request for information

exchange
RTU Dataflow
RTU Communication
 Standard polling 
The master station continuously requests the real‐time data 
values.
 Exception reporting
The RTU is polled but only reports values that have changed 
since the prior poll
 Push Communications
The RTU initiates messages on an event or time basis.
 Peer to peer communications
RTUs can communicate with the master station and also with 
each other if there is a communication path.
RTU Connectivity Options
Normal RTU LAN-B Critical RTU LAN-B

LAN-A
LAN-A

CFE CFE CFE CFE

S
M M
M

M M
M

RTU RTU
IEC 60870-5 Protocol
 Based on the reduced communication reference model called 
Enhanced Performance Architecture (EPA)
 Companion standards IEC 60870‐5‐101 and IEC 60870‐5‐104 
are derived from the IEC 60870‐5 protocol standard definition
 EPA includes three layers of the OSI model –
 Application layer
 Data Link layer
 Physical layer
101
104

* The ITU ( International Telecommunication Union ) Telecommunication Standardization (ITU-T)

Protocol Structure
7‐Layer 3‐Layer

Application Application

Presentation
Session
Transport
Network
Data Link Data Link
Physical Physical

OSI  EPA

Reason for 3‐Layered Structure of EPA ‐
1)  Short Reaction Time
2)  Reduced Transmission Bandwidth
IEC 60870-5-101
 Supports unbalanced (master initiated message) & balanced 
(master/slave initiated message) modes of data transfer
 supports point‐to‐point and multidrop communication links carrying 
serial‐bit low‐bandwidth data communications
 Link address and application service data unit (ASDU) addresses are 
provided for classifying the end station and sectors under same n/w
 Data is classified into different information objects and each 
information object is provided with a specific address
 Facility to classify the data into high priority (class‐1) and low 
priority (class‐2) and transfer the same using separate mechanisms
 Possibility of classifying the data into different groups (1‐16) to get 
the data according to the group by issuing specific group 
interrogation commands from the master 
 Cyclic & Spontaneous data updating schemes are provided
 Facility for time synchronization schemes for transfer of files 
IEC 60870-5-101 Layers
Physical Layer  :  Data Link Layer
Information (data) bit  : 8 bit Standard Frame Format  :  FT 1.2 (frame format 
Start bit:1 , Stop bit : 1 of IEC 101 which is suitable for 
asynchronous communication)
Parity bit  :  Even
Data Transmission at Link Layer ( Station address field Length : 1 or 2 bytes )
Unbalanced Mode :
Transmitted messages are categorized on two priority classes( Class 1 & Class 2 )
Balanced Mode :
All the messages are sent, No categorization of Class 1 and Class 2
Network Layer :  Not defined as  870‐5‐101 as it is not IP based
Application Layer Selection of ASDUs
ASDU 1 : Single point information
Length of header fields of data structure are: ASDU 2 : Single point information with time tag
ASDU 3 : Double point information
‐ Station address 1 or 2 byte ( User defined ) ASDU 4 : Double point information with time tag
ASDU 9 : Measured value, Normalized value
‐ ASDU Address : 1 or 2 bytes ASDU 10 : Measured value, Normalized value with time
tag
‐ Information Object address : 2 bytes ASDU 11 : Measured Value, Scaled value
ASDU 12 : Measured value, Scaled value with time tag
‐ Cause of Transmission : 1 byte ASDU 100 : Interrogation Command
ASDU 103 : Clock Synchronization Command
ASDU 120 ‐ 126 : File transfer Command
IEC 60870-5-101 Data Frame
Frame Length

Control Field

Address

• As balanced communications are point‐to‐point the link address is redundant, but 
may be included for security
• ASDU contains address of the controlling station in the ‘control direction’, and the 
address of the controlled station in the ‘monitoring direction’
• Unique address for each data element
IEC 60870-5-101 Data Exchange
Link Layer Balanced Transmission
 At the link layer, all devices are equal
 restricted to point‐to‐point and to 
multiple point‐to‐point configurations
 Collision avoidance by‐
 Full duplex point to point connection 
(RS232 or four wire RS485)
 Designated master polls slaves on n/w
Link Layer Unbalanced Transmission
 Only Master device can transmit primary 
frames
 Collision avoidance is not necessary since 
slave device cannot initiate exchange
 If the slave device responds with NACK: 
(requested data not available) the master 
will try again until it gets data, or a 
response time‐out occurs
IEC 60870-5-104
 Based on data transmission via Ethernet (TCP/IP)
 An extension of IEC 101 protocol with the changes in transport, network, link & 
physical layer services to suit the complete network access
 Application layer of IEC 104 is same as that of IEC 101 with some of the data 
types and facilities not used
 offers considerable benefits compared with the serial data transmission ‐
 Higher level safety
 Flexible network layout
 Numerous network utilities
 Simplified management of connected devices
 Reduced time and cost for maintenance and servicing 
 The security of IEC 104, by design has been proven to be problematic
IEC 60870-5-104

 Operation of the lower layers of IEC 60870‐5‐104 is completely different from that 
of the IEC 60870‐5‐101. 
 These layers correspond to all the layers below the application layer, 
 Architectures of these layers are concerned with how message transports happen.
ICCP Protocol
• Inter‐Control Center Communications Protocol (ICCP or IEC 60870‐6‐502)
• To provide data exchange over wide area networks (WANs) between utility
control centers, utilities, power pools, regional control centers, and Non‐
Utility Generators.
ICCP Protocol
Associations
An application Association needs to be established between two ICCP instances before any
data exchange can take place. Associations can be Initiated, Concluded or Aborted by the
ICCP instances.
Bilateral Agreement and Table for Access Control
A Bilateral Agreement between two control‐centers (say A and B) for data access. A
Bilateral Table is a digital representation of the Agreement.
Data Values
Data Values are objects that represent the values of control‐center objects including
points (Analog, Digital, and Controls) or data structures.
Data Sets
Data Sets are ordered‐lists of Data Value objects that can be created locally by an ICCP
server or on request by an ICCP client
Information Messages
Information Message objects are used to exchange text or other data between Control
Centers.
Transfer Sets
Transfer Set objects are used for complex data exchange schemes to transfer Data Sets (all
elements or a subset of the Data set elements) etc.
Devices
Devices are the ICCP objects that represent controllable objects in the control center.
ICCP Protocol
Conformance Blocks
• ICCP divides the entire ICCP functionality into 9 conformance block subsets
• Implementations can declare the blocks that they provide support for
• Specify the level of ICCP supported by the implementation
• Any ICCP implementation must necessarily support Block 1
Block 1 – Basic Services
Status and analogue points, quality flags, time‐stamp, protection events, association, data set
Block 2 – Extended Data Set Condition Monitoring
Provides report on exception of the data types that block 1 is able to transfer periodically
Block 3 – Blocked Transfers
Provides a means of transferring Block 1 and Block 2 data types as block transfers instead of point
by point
Block 4 – Information Message
Information Message objects, Simple text and binary files
Block 5 – Device Control
Control requests: on/off, trip/close, raise/lower etc. and digital setpoints
Block 6 ‐ Program Control
Allows an ICCP client to remote control programs executing on an ICCP server
Block 7 ‐ Event Reporting
Extended reporting to a client of error conditions and device state changes at a server.
Block 8 ‐ Additional User Objects
Scheduling, accounting, outage and other plant information.
Block 9 ‐ Time Series Data
Allows client to request server a report of historical time series data between start & end date
Secure ICCP Protocol
• Secure ICCP is an extension of the existing standard ICCP.
• Transport Layer Security (TLS) is inserted into the appropriate layer of 
the standard communications profile
• TLS is a certificate‐based cryptographic protocol that provides 
encryption and authentication
• Secure ICCP provides application layer authentication and message 
encryption between ICCP servers. 
DNP 3 Protocol
 Distributed Network Protocol (DNP), an open protocol, used between 
components in process automation systems 
 Based on Enhanced Performance architecture  ( EPA) model
 Primarily used for communications between a master station and IEDs or 
RTUs
 Supports multiple‐slave, peer‐to‐peer and multiple‐master 
communications
 DNP contains Application and Data Link Layers, with a pseudo‐transport 
layer
 DNP protocol is simply encapsulated within TCP/IP
 widely used over a variety of physical layers, including RS‐232, RS‐422, RS‐
485, and TCP/IP
 Supports the operational modes of polled and quiescent operation
DNP 3 Protocol
 Pseudo‐transport layer(OSI Layer 4) used to build application data 
messages larger than a single data link frame
 Uses FT3 frame format
 Can request and respond with multiple data types in single messages
 segment messages into multiple frames to ensure excellent error detection 
and recovery
 designed to optimize the transmission of data acquisition information and 
control commands from one computer to another
 Respond without request (unsolicited)
 provides interoperability between different vendor’s equipment
 provides multiplexing, data fragmentation, error checking, link control, 
prioritization, and layer 2 addressing services for user data
 not designed to be secure from attacks by hackers
DNP 3 Protocol Layers

The pseudo‐transport layer
• To allow for the transmission of larger blocks of data 
• Network functions for routing and flow control of data packets over networks. 
• Transport functions provide network transparent end‐to‐end delivery of messages
• Disassembly and reassembly, and error correction of messages.
DNP 3 Message Buildup
DNP 3 Protocol - FT3 frame format

• 10 byte header, followed optionally by up to 16 data blocks

• Overall message size limited to 292 bytes, maximum data capacity of 250 bytes
• Fully packed frame will comprise the header plus 16 data blocks, with the last
block containing 10 data bytes
• START - 2 bytes: Start of frame
• LENGTH - Count of user data in bytes
• CONTROL - Frame control byte
• DESTINATION - 2 byte destination address (LSB, MSB)
• SOURCE - 2 byte source address (LSB, MSB)
• CRC - 2 byte cyclic redundancy check code
DNP 3 - Message Communication

• In SCADA, some stations may be identified as master stations, and others as slave stations
• There may be some devices that act both as slave stations and master stations
• Master/slave distinction applies at the application level
• At the data link level, the terms balanced and unbalanced 
• In ‘unbalanced’ systems, only master stations will initiate communications
• The DNP3 protocol supports balanced communications at the data link level to provide 
greater flexibility by allowing non‐master stations to initiate communications
• In DNP3 any station can be an originator or primary station (Not necessary to be master)
• Master/Slave used at the link level for setting of a message direction bit, the DIR bit.
DNP 3 Vs. IEC 60870-5-101
DNP 3.0 IEC 60870‐5‐101
Standard Open Standard IEC Standard
Dominant Market North America Europe
Architecture 4‐layer architecture supports  3‐layer EPA architecture
TCP/IP
Application Layer  messages encapsulated in  Application functions specified in a 
function data link frames data link layer message
Frames application layer message Single application function require 
consist of many data link  several messages to be sent to 
frames complete function
Transmission Only balanced Balanced and unbalanced
Device pairs of devices may swap  pairs of devices will not  swap 
Addressing master and slave roles master and slave roles
Frame Format FT3 FT1.2
Smart Meter Protocols
IS 16444
IS 16444 was adopted by the BIS in 2015 and consists of Two parts –

IS 16444 (Part 1): 2015

• Static Watthour direct connected meters consisting of measuring element(s), time of use
register (s), display, load switch, and built in / plug in type bidirectional communication
module all integral with the meter housing.
• Smart meter for indoor use & capable of forward (import) or both forward (import)
and reverse (export) energy measurement.
• Covers the general requirements and tests for a.c. static direct connected Watthour
smart meter, class 1 & 2.

IS 16444 (Part 2): 2017

• Transformer operated static watt-hour meters & Var-Hour meters consisting of
measuring element(s), time of use register(s), display and built in / plug in type
bidirectional communication module all integral with the meter housing.
• Smart meter for indoor use & capable of forward (import) or import and export energy
measurement.
• Covers the general requirements and tests for a.c. Static Transformer operated
Watthour & Var-Hour Smart Meters, Class 0.2S, 0.5S & 1.0S.
IEC 62056
• Set of Protocols for electricity metering data exchange (IEC  TC13WG14)
• International version of DLMS (Device Language Message Specification)/COSEM 
(Companion Specification for Energy Metering)
• COSEM contains set of specifications that define the Transport and Application 
layer of DLMS protocol
• DLMS users association defines protocol into set of 4 specification documents –
 Green Book – DLMS/COSEM Architecture and Protocols
 Blue Book ‐ COSEM interface classes and OBIS (Object Identification 
System)
 Yellow Book ‐ DLMS/COSEM Conformance Testing Process
 White Book ‐ Glossary of Terms
• Not only applicable to electricity metering, it is equally applicable to water, gas, 
and heating metering systems also
• All the data in electronic meters and associated devices are represented by 
means of mapping them to appropriate classes and attributes
• Specifies an interface model and communication protocols for data exchange 
with metering equipment
DLMS/COSEM
The DLMS/COSEM specification follows a 
three‐step approach:
• Step 1, Modelling: Covers the interface 
model of metering equipment and rules 
for data identification;
• Step 2, Messaging: Covers the services 
for mapping the interface model to 
application layer protocol data units 
(APDU) and the encoding of this APDUs.
• Step 3, Transporting: Covers the 
transportation of the messages through 
the communication channel.
Source: DLMS/COSEM Green Book
DLMS/COSEM Communication Model
Client Server Model
HDLC ‐ High‐level Data Link Control
LLC ‐ Logical Link Control (Sublayer)
SAP ‐ Service Access Point
MAC ‐ Medium Access Control
UDP ‐ User Datagram Protocol
TCP ‐ Transmission Control Protocol

• Uses the concepts of OSI model to 
model information exchange 
between meters and data 
collection systems (DCS)
• Application functions of meters & 
DCS are modelled by application 
processes (APs).
• Communication between APs is 
modelled by communication 
between application entities (AEs)
• AE represents the communication 
functions of an AP. Source:Source:
DLMS/COSEM Green
DLMS/COSEM Book
Green Book
Connection oriented operation
• The DLMS/COSEM AL is connection oriented
• A communication session consists of three phases:
 First, an application level connection, called Application Association (AA), is 
established between a client and a server Application Entities (AE)
 Once the AA is established, message exchange can take place
 At the end of the data exchange, the AA is released.
• Servers cannot initiate the establishment of an AA
• A COSEM logical device may support one or more AAs, each with a different client
• Each AA determines the contexts in which information exchange takes place.

Source: DLMS/COSEM Green Book

ACSE ‐ Association Control Service Element
ASE ‐ Application Service Element
CO ‐ Connection‐oriented
DLMS/COSEM Server Model
DLMS/COSEM Client Model