Using IEC 61850 for remote disturbance analysis

Roland Hamrén
[email protected]

Master Thesis in Computer Science, 20p D-level

Mälardalen University

Powel Energy Management AB

Östersund, Sweden
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

Abstract
Power networks are monitored and controlled by different types of intelligent electronic
devices in substations in order to control the power flow, handle line failures, protect
expensive equipment, and register power disturbances. A power disturbance is any event
which can pose a threat to the smooth operation of equipment connected to the power net.
Transient overvoltages, interruptions, and spikes are examples of disturbances that can
appear.

IEC 61850 is a new international standard covering all aspects regarding communication in
substations. Earlier, different manufacturers developed their own proprietary communication
solutions, which made it problematic to combine devices from different manufacturers in the
same substation.

Powel Energy Management AB has developed a disturbance analysis system named STINA,
a Swedish acronym for STörning, INsamling, Analys. The STINA system collects and
normalizes information from different types and brands of protection and disturbance
recording devices. The manufactures of such devices have now started to introduce new
products supporting the IEC 61850 standard, and consequently Powel now wants to integrate
support for communication to IEC 61850 compliant devices into their disturbance analysis
system.

For this thesis a prototype for communication between STINA and IEC 61850 compliant
devices was developed. The work composed of first identifying what information STINA
wants and to find out how that information could be retrieved from IEC 61850 compliant
devices, and thereafter was the prototype implemented. The prototype provides STINA with
COMTRADE files. COMTRADE is a standardized format for transient data exchange.
Transient data is usually used for disturbance analysis.

I
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

Sammanfattning
Elnät övervakas och kontrolleras av olika typer av intelligenta elektroniska enheter
lokaliserade i kraftstationer, detta för att kunna kontrollera flöden, hantera fel på ledningar,
skydda dyr utrustning, samt registrera eventuella störningar på nätet. En störning är en
händelse som orsaker ett hot mot driften av elektriska utrustningar kopplade till nätet.
Tillfälliga överspänningar, avbrott, och spikar är några exempel på störningar som kan uppstå.

IEC 61850 är en ny internationell standard som täcker alla aspekter angående kommunikation
i kraftstationer. Tidigare så har tillverkare utvecklat egna kommunikationslösningar, vilket
gjorde det problematiskt att kombinera ihop utrustningar från olika tillverkare i samma
transformatorstation.

Powel Energy Management AB har utvecklat ett system vid namn STINA för insamling och
analys av störningsinformation från olika typer och märken av skydds och
störningsregistrerande utrustningar. Tillverkarna av sådana utrustningar har nu börjat
introducera nyutvecklade enheter med stöd för IEC 61850, vilket också är orsaken till Powel’s
intresse för att bygga in stöd för kommunikation med IEC 61850 kompatibla enheter i deras
system STINA. Namnet STINA är en akronym för Störning, Insamling, Analys.

För detta examensarbete så har en prototyp för kommunikation mellan STINA och IEC 61850
kompatibla utrustningar tagits fram. Arbete bestod utav att först identifiera vilken information
som STINA har användning för, samt att ta reda på hur denna information kan hämtas från
enheter med stöd för IEC 61850, och därefter implementerades prototypen. Prototypen förser
STINA med COMTRADE filer. COMTRADE är ett standardiserat format för utbyte av
transient data. Transient data används vanligtvis vid störningsanalys.

II
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

Table of contents
1 INTRODUCTION ....................................................................................................................................... 1
1.1 PURPOSE ............................................................................................................................................... 1
1.2 GOAL .................................................................................................................................................... 1
1.3 CONSTRAINTS ....................................................................................................................................... 2
2 RELATED WORK AND THEORY.......................................................................................................... 3
2.1 THE OPEN SYSTEMS INTERCONNECTION REFERENCE MODEL .............................................................. 3
2.2 CONVENTIONAL SUBSTATION COMMUNICATION PROTOCOLS ............................................................... 5
2.2.1 Modbus communication .................................................................................................................. 5
2.2.2 IEC 60870-5-103 substation communication.................................................................................. 7
2.2.3 Why a international standard was needed ...................................................................................... 8
2.3 IEC 61850, COMMUNICATION NETWORKS AND SYSTEMS IN SUBSTATIONS........................................... 9
2.3.1 Different parts of IEC 61850 standard series ................................................................................. 9
2.3.2 IEC 61850-7-2 Abstract Communication Service Interface.......................................................... 10
2.3.3 Information exchange.................................................................................................................... 11
2.3.4 Substation Configuration Language ............................................................................................. 12
2.3.5 Manufacturing Message Specification .......................................................................................... 13
2.4 TCP CLIENT ....................................................................................................................................... 13
3 STINA™ - DISTURBANCE AND FAULT INFORMATION COLLECTION AND ANALYSIS ... 14
3.1 HARDWARE ARCHITECTURE ............................................................................................................... 14
3.2 SOFTWARE DESIGN ............................................................................................................................. 16
3.2.1 Communication server software.................................................................................................... 16
3.2.2 Adaptor principle .......................................................................................................................... 17
3.3 NAVIGATOR ........................................................................................................................................ 18
3.4 ADMINISTRATOR ................................................................................................................................ 18
3.5 COMTRADE VIEWER ....................................................................................................................... 19
4 LAB EQUIPMENT ................................................................................................................................... 20
5 COMTRADE - COMMON FORMAT FOR TRANSIENT DATA EXCHANGE .............................. 21
6 ABSTRACT SYNTAX NOTATION ONE.............................................................................................. 23
7 PROBLEM FORMULATION ................................................................................................................. 24
8 PROBLEM ANALYSIS............................................................................................................................ 25
9 METHODOLOGY .................................................................................................................................... 26
9.1 IDENTIFICATION OF SUITABLE INFORMATION MODELS ........................................................................ 26
9.1.1 Connection Establishment............................................................................................................. 26
9.1.2 Downloading of COMTRADE files ............................................................................................... 27
9.2 MAPPING OF ABSTRACT SERVICES ...................................................................................................... 28
9.3 COMMUNICATION STACK ................................................................................................................... 28
9.3.1 Communication stack design considerations ................................................................................ 28
9.3.2 Useable Tools................................................................................................................................ 29
9.4 CREATING A STINA IEC 61850 COMMUNICATION PROTOTYPE .......................................................... 29
10 SOLUTION ................................................................................................................................................ 30
10.1 ABSTRACT SERVICES .......................................................................................................................... 30
10.1.1 The Associate Service ............................................................................................................... 30
10.1.2 The Abort Service ..................................................................................................................... 30
10.1.3 The Release Service.................................................................................................................. 31
10.1.4 The GetServerDirectory Service............................................................................................... 31
10.1.5 The GetFile Service .................................................................................................................. 32
10.1.6 The GetFileAttributeValues Service ......................................................................................... 32
10.2 MAPPING OF ABSTRACT SERVICES ...................................................................................................... 33
10.2.1 Mapping of Associate Service................................................................................................... 33
10.2.2 Mapping of Abort Service......................................................................................................... 33
10.2.3 Mapping of Release Service ..................................................................................................... 33

III
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07
10.2.4 Mapping of GetServerDirectory Service .................................................................................. 33
10.2.5 Mapping of GetFile .................................................................................................................. 34
10.2.6 Mapping of GetFileAttributeValues ......................................................................................... 34
10.3 MANUFACTURING MESSAGE SPECIFICATION ...................................................................................... 35
10.3.1 Protocol Data Units ................................................................................................................. 35
10.3.2 Initiate Service.......................................................................................................................... 35
10.3.3 Conclude-Service...................................................................................................................... 37
10.3.4 Abort......................................................................................................................................... 37
10.3.5 File services.............................................................................................................................. 37
10.3.6 FileOpen................................................................................................................................... 38
10.3.7 FileRead ................................................................................................................................... 39
10.3.8 FileClose .................................................................................................................................. 39
10.3.9 FileDirectory ............................................................................................................................ 39
10.4 BER ENCODING/DECODING................................................................................................................ 40
10.5 MAPPINGS BETWEEN C++ AND ASN.1 ............................................................................................... 43
10.6 COMMUNICATION STACK ................................................................................................................... 44
10.6.1 Communication stack specified by IEC 61850-8-1................................................................... 45
10.6.2 Reduced communication stack.................................................................................................. 46
10.7 STINA IEC 61850 COMMUNICATION PROTOTYPE .............................................................................. 55
10.7.1 STINA IEC 61850 - Communication adapter........................................................................... 55
10.7.2 STINA IEC 61850 - Process adapter........................................................................................ 59
11 TESTING OF THE PROTOTYPE’S FUNCTIONALITY ................................................................... 62
12 CONCLUSION .......................................................................................................................................... 64
13 GLOSSARY ............................................................................................................................................... 65
14 REFERENCES .......................................................................................................................................... 67
15 APPENDIX A - ASN.1 AND BER............................................................................................................ 70
15.1 TYPES ................................................................................................................................................. 70
15.1.1 Simple type ............................................................................................................................... 70
15.1.2 Structured type ......................................................................................................................... 70
15.1.3 Tagged type .............................................................................................................................. 71
15.1.4 Other types ............................................................................................................................... 72
15.2 TAG CLASSES ...................................................................................................................................... 73
15.2.1 Universal .................................................................................................................................. 73
15.2.2 Application ............................................................................................................................... 73
15.2.3 Private ...................................................................................................................................... 74
15.2.4 Context-specific ........................................................................................................................ 74
15.3 ASN.1 TYPE EXAMPLE ....................................................................................................................... 74
15.4 BASIC ENCODING RULES .................................................................................................................... 75
15.5 PRIMITIVE, DEFINITE-LENGTH METHOD .............................................................................................. 76
15.5.1 Identifier octets......................................................................................................................... 76
15.5.2 Length octets............................................................................................................................. 76
15.5.3 Contents octets ......................................................................................................................... 77
15.6 CONSTRUCTED, DEFINITE-LENGTH METHOD ....................................................................................... 77
15.7 CONSTRUCTED, INDEFINITE-LENGTH METHOD .................................................................................... 77

IV
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

List of figures
FIGURE 2-1 – OSI MODEL [RAD07].......................................................................................................................... 3
FIGURE 2-2 – MODBUS ON TCP/IP [PLA06]............................................................................................................. 6
FIGURE 2-3 – IEC 60870-5-103 DATA MODEL [1] .................................................................................................... 7
FIGURE 2-4 – CONCEPTUAL VIEW OF ACSI BASIC INFORMATION MODELS............................................................. 10
FIGURE 2-5 – COMPATIBLE LOGICAL NODE ............................................................................................................ 11
FIGURE 3-1 – STINA HARDWARE ARCHITECTURE [POW06].................................................................................. 14
FIGURE 3-2 – STINA SOFTWARE DESIGN .............................................................................................................. 16
FIGURE 3-3 – STINA ADAPTOR PRINCIPLE ............................................................................................................ 17
FIGURE 3-4 – STINA NAVIGATOR ......................................................................................................................... 18
FIGURE 3-5 – STINA ADMINISTRATOR ................................................................................................................. 18
FIGURE 3-6 – STINA COMTRADE-VIEWER ........................................................................................................ 19
FIGURE 4-1 – ABB 670 IED [ABB06B].................................................................................................................. 20
FIGURE 5-1 – COMTRADE INVESTIGATED IN A GRAPHICAL COMTRADE VIEWER ............................................ 22
FIGURE 10-1 – ACSI ASSOCIATE SERVICE ............................................................................................................. 30
FIGURE 10-2 – ACSI ABORT SERVICE.................................................................................................................... 30
FIGURE 10-3 – ACSI RELEASE SERVICE................................................................................................................. 31
FIGURE 10-4 – ACSI GETSERVERDIRECTORY SERVICE ......................................................................................... 31
FIGURE 10-5 – ACSI GETFILE SERVICE ................................................................................................................. 32
FIGURE 10-6 – ACSI GETFILEATTRIBUTEVALUES SERVICE .................................................................................. 32
FIGURE 10-7 – MAPPING OF GETSERVERDIRECTORY SERVICE TO MMS ............................................................... 33
FIGURE 10-8 – MAPPING OF GETFILE SERVICE TO MMS ....................................................................................... 34
FIGURE 10-9 – MAPPING OF GETFILEATTRIBUTEVALUES SERVICE TO MMS ........................................................ 34
FIGURE 10-10 – REDUCED COMMUNICATION STACK DESIGN ................................................................................. 46
FIGURE 10-11– TRANSPORT LAYER - SETIP .......................................................................................................... 47
FIGURE 10-12 – TRANSPORT LAYER - CONNECTIONREQUEST ............................................................................... 48
FIGURE 10-13 – TRANSPORT LAYER - SENDDATA ................................................................................................. 48
FIGURE 10-14 – TRANSPORT LAYER - RECEIVEDATA ............................................................................................ 48
FIGURE 10-15 – TRANSPORT LAYER -DISCONNECT ............................................................................................... 49
FIGURE 10-16 – SESSION LAYER - SETIP ............................................................................................................... 49
FIGURE 10-17 – SESSION LAYER - CONNECT ......................................................................................................... 49
FIGURE 10-18 – SESSION LAYER - DATATRANSFER ............................................................................................... 50
FIGURE 10-19 – SESSION LAYER - FINISH .............................................................................................................. 50
FIGURE 10-20 – PRESENTATION LAYER - SETIP .................................................................................................... 51
FIGURE 10-21 – PRESENTATION LAYER - CONNECT .............................................................................................. 51
FIGURE 10-22 – PRESENTATION LAYER - DATAREQUESTRESPONSE ..................................................................... 51
FIGURE 10-23 – PRESENTATION LAYER - RELEASE................................................................................................ 52
FIGURE 10-24 – APPLICATION LAYER - SETIP ....................................................................................................... 52
FIGURE 10-25 – APPLICATION LAYER - INITIATE ................................................................................................... 52
FIGURE 10-26 – APPLICATION LAYER - GETFILE ................................................................................................... 53
FIGURE 10-27 – APPLICATION LAYER - GETDIRECTORY ....................................................................................... 53
FIGURE 10-28 – APPLICATION LAYER - CONCLUDE ............................................................................................... 53
FIGURE 10-29 – STINA IEC 61850 COMMUNICATION ADAPTER DESIGN ............................................................... 55
FIGURE 10-30 – COMMUNICATION ADAPTER- INIT ................................................................................................ 56
FIGURE 10-31 – COMMUNICATION ADAPTER - GETDATA ...................................................................................... 57
FIGURE 10-32 – COMMUNICATION ADAPTER - CLEANUP....................................................................................... 58
FIGURE 10-33 – STINA IEC 61850 PROCESS ADAPTER DESIGN ............................................................................. 59
FIGURE 10-34 – PROCESS ADAPTER - INIT .............................................................................................................. 59
FIGURE 10-35 – PROCESS ADAPTER - PROCESSDATA ............................................................................................. 60

V
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07
FIGURE 10-36 – PROCESS ADAPTER - CLEANUP..................................................................................................... 61
FIGURE 11-1 – STINA NAVIGATOR SHOWING DOWNLOADED DISTURBANCE INFORMATION ................................. 62
FIGURE 11-2 – SELECTION OF COMTRADE IN STINA NAVIGATOR .................................................................... 62
FIGURE 11-3 – INVESTIGATION OF A COMTRADE IN STINA COMTRADE-VIEWER ......................................... 63

VI
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

List of tables
TABLE 2-1 – PARTS OF IEC 61850 STANDARD SERIES ............................................................................................. 9
TABLE 2-2 – LOGICAL NODE GROUPS [2] ............................................................................................................... 11
TABLE 2-3 – SELECTION OF ACSI INFORMATION MODELS ..................................................................................... 12
TABLE 9-1 – FILE CLASS ....................................................................................................................................... 27
TABLE 9-2 – GETSERVERDIRECTORY SERVICE ...................................................................................................... 27
TABLE 10-1 – MMS BASED ON TCP/IP T-PROFILE ................................................................................................ 45
TABLE 10-2 – TRANSPORT PACKET FORMAT .......................................................................................................... 47
TABLE 15-1 – UNIVERSAL TYPES [OBJ07] ............................................................................................................. 73
TABLE 15-2 – BER ENCODING OF TAG CLASSES [DER07] ...................................................................................... 76

VII
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

Preface
First I want to thank Powel Energy Management for giving me the opportunity to do an
interesting and instructive master thesis covering the latest technology for substation
communication.

I would also like to thank Leif Nordin at E.ON in Sundsvall for lending me the equipment
needed in this thesis, without the equipment it would have been almost impossible to produce
a good result.

Finally I want to thank my supervisor Jan Gustafsson at Mälardalen University for good
advice regarding the making and the finalization of this thesis report.

VIII
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

1 Introduction
Power networks are monitored and controlled by different types of substation automation
devices in order to handle line failures, protect expensive equipment, control power flow, and
to register power disturbances. Different vendors of substation automation devices have
traditionally developed their own proprietary communication solutions, which have led to the
existence of several different communication protocols for the same type of communication.
This multitude of protocols has resulted in difficulties in integrating equipment from different
manufactures in the same substation since various types of protocol converters are needed. A
new global standard named IEC 61850 has however emerged during the last few years with
the goal to solve the different problems regarding substation communication and integration.

Powel Energy Management AB, which is a Swedish subsidiary of the fast growing
Norwegian Powel ASA group, provides IT-solutions to municipalities, utilities and other
companies in the energy market. Powel Energy Management AB has developed a system for
disturbance analysis, called STINA [Pow06] (a Swedish acronym for STörning, INsamling,
Analys). STINA is currently the dominating tool for disturbance analysis on the Nordic
energy market and it is used by Svenska Kraftnät, Vattenfall, Fortum, and E.ON among
others. The STINA system collects and normalizes information from different types and
brands of protection and disturbance recording devices, and thus makes it easier for users to
do disturbance analysis and fault locating since only one tool is needed regardless of the
manufacturer of the device. Previously, disturbance engineers had to use different proprietary
tools for different devices. In order to communicate with different manufacturers’ protection
devices the system currently needs several different communication adapters or gateways.
The latest trend however is that several manufacturers, for example ABB, Siemens, Areva,
Vamp etc., are supporting the new global substation communication standard IEC 61850 in
their new devices. Powel is now interested in integrating support for communication with
devices supporting the new standard into their system, and the purpose of this thesis is to
show how the standard can be used in practice, even outside the substation communication
bus.

1.1 Purpose
The purpose of this master’s thesis in computer science is to show that it is possible to
integrate communication with IEC 61850 compliant devices in an already existing system for
disturbance analysis. In other words, the purpose shows how the new global substation
communication standard IEC 61850 can be applied in the area of remote disturbance analysis.
The thesis will not only focus on the integration of IEC 61850 communications with the
disturbance analysis system STINA, a theoretical study will also be conducted with the
purpose to answer the question: “What is the difference between IEC 61850 and earlier
substation communication protocols?”

1.2 Goal
The goal with this thesis is to develop a prototype for IEC 61850 communication between the
disturbance analysis system called STINA [Pow06] and IEC 61860 compliant devices. The
prototype should theoretically be able to communicate with equipment developed by ABB,
Areva, Siemens, Vamp, or by any other company, as long as the equipment complies with the
new standard. In this way, the number of necessary STINA adapters will in time decrease as
the energy companies replaces their old equipment with newer IEC 61850 compliant ones.

1
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07
1.3 Constraints
The thesis should be completed after approximately 20 weeks, and therefore it was delimited
to only a small part of IEC 61850. The minimum requirements of the prototype were stated in
the beginning of the project.

• The prototype should be able to communicate with devices supporting IEC 61850, and
provide STINA information useable for remote disturbance analysis.

2
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

2 Related work and theory

2.1 The Open Systems Interconnection Reference Model

The Open Systems Interconnection Reference model, shortly called the OSI model, is a
generic model that describes how different applications may communicate with each other.
The model defines a communication stack with seven different layers (Layer 1 to 7). Layer
diagrams are usually drawn with layer one at the bottom and layer seven at the top of the
communication stack according to Figure 2-1. Each layer uses services provided by the layer
below and in turn provides services to the layer above. [Pcs07]

Figure 2-1 – OSI model [Rad07]

Layer 1 – Physical Layer

The physical layer in the OSI-model defines all the physical and electrical specifications of a
network device.

Layer 2 – Data Link Layer

The second layer, the data link layer, defines the access strategy for sharing the physical
medium including data link and media access issues. The data link layer is responsible for
node to node packet delivery.

Layer 3 – Network Layer

The network layer provides functionality for transferring data from a source to a destination
via one or more networks. This layer is thereby responsible for addressing the messages and
end to end packet delivery. The IP protocol is one of the most well known network layer
protocols.

3
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

Layer 4 – Transport Layer

The transport layer provides functionality for reliable data transfer between hosts and is
usually responsible for communication error recovery and flow control. TCP is currently one
of the most used transport Layers, and can be considered as common knowledge.

Layer 5 – Session Layer

The session layer provides the functionality for establishing, managing and terminating
communication sessions between end-user processes.

Layer 6 – Presentation Layer

The presentation layer is responsible for the delivery and formatting of data, so that the data
later can be processed by the application layer, or sent via the Session Layer.

Layer 7 – Application Layer

The application layer is closest to the end-user and provides services that make it possible for
one application (end-user) to communicate with an application on another computer.

4
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

2.2 Conventional Substation communication protocols

IEC 60870-5-103 and the Modbus protocol are two of the many protocols that are supported
by STINA today. These two is also two of the most used conventional substation
communication protocols, which make them appropriate for a comparison with IEC 61850. A
short introduction to these two protocols will be presented in the next two sections (2.2.1,
2.2.2), this in order to easier explain why a new global standard was needed.

2.2.1 Modbus communication

In 1979 the PLC manufacturer Modicon introduced a simple field-bus communication
protocol called Modbus. Modbus can be considered as the industry’s first “open field bus”
communication protocol and it is now a de facto standard. [Wik07][Pla06]

Modbus is an application layer protocol that provides client/server communication between

devices. It is mostly used on slow serial communication interfaces (RS232, RS485) but it can
be used on any other physical interface, e.g. Ethernet. The conversation between a client and a
server is based on Modbus protocol data units. [Jam06]

Modbus Protocol Data Unit

The Modbus protocol specifies three different types of protocol data units (PDUs): the request
PDU, the response PDU and the exception response PDU. All PDUs are constructed
according to the same format; all data units consist of a function code and a data field. A
conversation is initiated by the client when it sends a request PDU to the server, the server
answers to the request by sending a function specific response PDU if everything worked as it
should or an exception response if an error occurred. [Jam06]

Request PDU
1) Function code – Function
2) Data - Function specific data

Response PDU
1) Function code - Code corresponding to the request
2) Data - Response specific data

Exception response PDU

1) Function code - Code corresponding to the request + 128
2) Data – Exception code

Modbus functions
Modbus specifies a number of standardized functions and exceptions, each function or
exception is assigned to a specific function code. Function codes in the range from 1 to 127
specify functions, codes between 129 and 255 represents exceptions. The latest Modbus
version divides the function codes into three categories: public, user defined and reserved.
[Jam06]

Public function codes are guaranteed to be unique, and they specify functions that are well
defined and publicly documented. The function documentation consists of a function

5
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07
description, the assigned function code, the Request PDU, the Response PDU and the
Exception Response PDU, among other useful information.

User defined function codes are available for companies who want to implement their own
functions not covered by the Modbus protocol. There is no guarantee that a user defined
function code is unique.

Reserved function codes are currently used by some companies for legacy products and these
codes are not available for public use.

Transmission of data
Modbus protocol data units are mapped into Modbus application data units, shortly called
ADUs. An application data unit consists of an address, a Modbus protocol data unit and a 16-
bit checksum used for communication error detection. The address is represented by a number
between 0 and 247 where 0 is used as a broadcast address. [Jam06]

There are two different modes for serial transmission between Modbus clients and Modbus
servers: the ASCII-mode and the RTU-mode. In ASCII mode the messages are sent in a
readable format by encoding every byte as two ASCII characters. In RTU-mode the bytes are
instead transferred as two four-bit hexadecimal digits. The main advantage of the RTU-mode
is the higher throughput. [Jam06]

The Modbus protocol can also be used on Ethernet networks. This is done by encapsulating
the Modbus packets into TCP/IP packets according to Figure 2-2. The 16-bits Modbus
checksum is replaced by the 32-bits TCP/IP checksum. [Pla06]

Transaction Protocol Length Modbus TCP FRAME

Identifier Identifier Field Frame

ADDRESS FUNCTION DATA CHECKSUM

MODBUS FRAME CODE

Figure 2-2 – Modbus on TCP/IP [Pla06]

Advantages and disadvantages

The Modbus/ModbusTCP protocol is relatively easy to understand and to implement which
has made it successful. One other advantage with Modbus is that the standard is open for
everybody, specifications and implementation examples are available for free at Schneider
Automation website. [Pla06] The Modbus protocol is as earlier stated simple, but its
simplicity is also its biggest disadvantage. The data model used by Modbus/Modbus TCP is
too simple and cannot provide support for complex object structures, self-describing devices,
automatic configuration etc. Nor does the standard cover all functions used by different types
of substation devices. [Wik07] The manufacturers have instead been forced to define their
own private functions, and that has resulted in decreased operability and compatibility
between different manufacturers.

6
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

2.2.2 IEC 60870-5-103 substation communication

IEC 60870-5 is another substation communication standard that has been, and is still, widely
used. This standard was introduced in the early nineties and it is said to be forerunner to IEC
61850. IEC 60870-5 is constructed according to the Enhanced Performance Architecture
(EPA) reference model. The EPA model uses three of the seven layers defined by the OSI-
model: the physical layer, the link layer and the application layer. [Ipc06]

The companion standard IEC 60870-5-103 defines an application layer, based on IEC 60870-
5, designed for communication with protection devices. It defines two different methods for
information exchange. One of the methods is based on explicitly specified Application
Service Data Units (ASDUs) and application procedures used for transmission of
standardized messages. The other method is based on generic services for transferring all
types of information. IEC 60870-5-103 is currently mostly used on slow serial physical layers
but fiber optics is also supported. [Ipc06]

Data model
The standardized functionality is based on Application Service Data Units (ASDUs)
constructed according to Figure 2-3. The data unit is divided into several fields, which are
always transferred in the same sequence (TOP-DOWN)
The first octet of the Data Unit
Identifier is the Type identification
field. Only type numbers between
1 and 31 are specified by the
standard and only those can be
used for compatible data exchange.
All other types (32 – 255) belong
to the private range which can be
used differently by different
manufacturers. The data model
will not be explained any further,
more information about it and the
different fields can be found in
IEC 60870-5-103 specification [1].
Figure 2-3 – IEC 60870-5-103 data model [1]

Disadvantages
IEC 60870-5-103 is a relative well used protocol and several manufacturers are supporting
this standard in their protection devices, but it has several limitations.

IEC 60870-5-103 is limited to 255 types and only 31 of those are standardized. When
manufacturers define their own types, the interoperability and compatibility between devices
from different manufacturers decrease. [Ipc06]

The data representation (ASDU) is a part of the communication stack, functionality

represented by the data model is thereby mixed together with functionality provided by the
communication services, and that makes the standard hard to adapt to future communication
technologies. [Hog04] Further, it does not provide support for self describing objects and
automatic device configuration. The scope of IEC 60870-5-103 is communication with
protection devices and not communication with all kinds of substation devices. [Sch02]

7
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

2.2.3 Why a international standard was needed

Traditionally, different manufacturers of substation devices have developed their own
proprietary communication solutions for substations and it has therefore been difficult to
integrate devices from different vendors in one substation. Gateways and different types of
protocol converters have been used to make it possible for devices from different
manufacturers to communicate with each other. This solution to interoperability is however
not a good one since the extra equipment may introduce communication errors and delays. A
better way to solve the interoperability problem in substations is to have one global standard
that cover all aspects of communication in substations. [Sch03]

One of the most common and largest drawbacks of the different standards available today,
e.g. Modbus and IEC 60870-5-103, is that they do not separate the data representation from
the communication services and the protocol stacks. It is not unusual that the standards define
specific bit-sequences for the messages. A bit-sequence is dependent on the communication
protocol and the protocol is dependent on the communication technology, and when
technology changes then the bit-sequences must be updated to fit the new technology. A
communication standard based on protocol dependent bit sequences is therefore not a future-
proof solution. [Hog04]

One other drawback with the legacy protocols is that the data models provided by these
protocols are too simple and cannot provide support for all possible functions in substation
devices. In addition they do not specify how the information should be organized in the
physical devices which have resulted in that system engineers have been forced to manually
configure objects and functions by mapping them to system variables, low-level registers, I/O
modules etc. [Mac06]

The biggest disadvantage with the traditional substation communication standards was
however that none of them covered all aspects of substation communication. The new global
standard IEC 61850 was designed to solve the problems with substation communication, and
its purpose is to provide a future-proof standardized way to communicate. IEC 61850
separates the data representation, communication services and protocol stacks from each
other, and it is therefore a future-proof solution and can easily be updated to fit new
communication technologies without changing the standardized data models. The data model
of IEC 61850 is object-oriented and provides support for all possible functions in substations,
function names and their data are also specified. A new configuration language format (SCL)
is also provided by IEC 61850 which makes the configuration of devices a lot easier than
before. This new standard is very extensive and it is much more than just a substation
communication protocol. [Hog04]

8
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

2.3 IEC 61850, Communication networks and systems in

substations
IEC 61850, Communication networks and systems in substations, is a new international
standard for substation automation systems. It is the first and only global standard that covers
all the communication needs within substations and it is also made to be a future proof
solution to substation automation problems. The main goal with this new standard is to
provide interoperability between substation devices. [Hog04] A more detailed overview of
IEC 61850 describing the standard and its features can be found in [Mac06]

2.3.1 Different parts of IEC 61850 standard series

The standard is divided into several parts which cover different aspects regarding substation
automation. IEC 61850 is, as one can see from Table 2-1, very extensive; it does not only
cover the communication but also for example conformance testing, requirements and the
specification of a new configuration language. [Mac06] This thesis has its focus on
integrating support for communication with IEC 61850 compliant devices in an existing
system for remote disturbance analysis and not on substation automation in general, the thesis
will therefore not be affected by all parts of this new standard.

Parts of IEC 61850 standard series

IEC 61850-1
Introduction and overview
IEC/TS 61850-2
Glossary
IEC 61850-3
General requirements
IEC 61850-4
System and project management
IEC 61850-5
Communication requirements for functions and device models
IEC 61850-6
Configuration description language for communication in electrical substations related to IEDs.
IEC 61850-7-1
Basic communication structure for substation and feeder equipment - Principles and models
IEC 61850-7-2
Basic communication structure for substation and feeder equipment - Abstract communication service interface
(ACSI)
IEC 61850-7-3
Basic communication structure for substation and feeder equipment - Common data classes
IEC 61850-7-4
Basic communication structure for substation and feeder equipment - Compatible logical node classes and data
classes
IEC 61850-8-1
Specific Communication Service Mapping (SCSM) - Mappings to MMS (ISO 9506-1 and ISO 9506-2) and to
ISO/IEC 8802-3
IEC 61850-9-1
Specific Communication Service Mapping (SCSM) - Sampled values over serial unidirectional multidrop point
to point link
IEC 61850-9-2
Specific Communication Service Mapping (SCSM) - Sampled values over ISO/IEC 8802-3
IEC 61850-10
Conformance testing
Table 2-1 – Parts of IEC 61850 standard series

9
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07
2.3.2 IEC 61850-7-2 Abstract Communication Service Interface
IEC 61850 uses an object-oriented approach to define the standardized functionality in
substation devices. The Abstract Communication Service Interface (ACSI) specified by IEC
61850-7-2 provides information models that describe how the information should be
organized and how it should be exchanged between different devices. Some of models are
basic information models, which are used to build up domain specific information models.
The ACSI also provides other information models, e.g. models for file transfer and
application associations. All ACSI models are defined as classes which both contain attributes
and services for information exchange. [3]

Basic information models

The basic information models are a fundamental part of IEC 61850 since they are used to
build up other domain specific models, for example substation automation models. Figure 2-4
shows how the different models are related. Note that every model in the diagram except the
SERVER has a Name. The name consists of an ObjectName and an ObjectReference. The
ObjectReference is a concatenation of Object Names from the different containers in which
the object is found. [3]

SERVER
The SERVER-model represents a physical device. All
other models provided by the ACSI are part of the
SERVER. The main purpose of the SERVER is to
communicate with clients and peer-devices.

LOGICAL-DEVICE
A LOGICAL-DEVICE (LD) works like a container for
logical nodes. A LOGICAL-DEVICE should usually
contain nodes with the same type of functionality, e.g.
several nodes with protection related functionality can
be grouped into one logical device and nodes with
control functionality can be grouped into another. A
physical device can in this way consist of one or several
logical devices.

LOGICAL-NODE
The LOGICAL-NODE model represents a specific
function and contains the consumed or produced
information (DATA)

Figure 2-4 – Conceptual view of ACSI DATA

basic information models
The DATA-model is used to specify typed information,
for example a sample value. Data contains a few or
several data attributes.

10
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

Logical nodes
The basic information models are, as earlier stated,
used to build up domain specific information
models. IEC 61850-7-4 defines about 90 different
logical node classes, called compatible logical
nodes, with standardized names and data. These
nodes are divided into 13 groups, shown by Table
2-2, and cover the most of the functionality used
by different types of substation devices. There are
also standardized rules which should be used to
create new logical node classes when extra
functionality not covered by the standard is needed.
Figure 2-5 – Compatible logical node
Figure 2-5 shows how the compatible logical node
classes are built up by using the basic information
models. [2]

Logical node groups Number of logical nodes

System logical nodes 3
Protection functions 28
Protection related function 10
Supervisory control 5
Generic references 3
Interfacing and archiving 4
Automatic control 4
Metering and measurement 8
Sensors and monitoring 4
Switchgear 2
Instrument transformer 2
Power transformer 4
Further power system equipment 15
Total number of logical nodes 92
Table 2-2 – Logical node groups [2]

2.3.3 Information exchange

The Abstract communication service interface is, as it sounds, only abstract. The services
defined by the ACSI models are called abstract services and they only describe the required
actions on the receiving side of a service (The server side). In order to make data
communication possible the services must be mapped to a real communication protocol. The
mapping to a real communication protocol is specified by a Specific Communication Service
Mapping (SCSM). In this way the standardized functionality in IEC 61850-7-2 is not directly
dependent on a specific communication protocol and that makes IEC 61850 to a future-proof
solution. The communication technology can be changed to a newer technology but the
standardized information models will always be the same. Today, the most of the ACSI
services are mapped to the Manufacturing Message Specification (MMS) as specified by
61850-8-1. [Mac06] Table 2-3 shows an overview of some of the models and abstract
services provided by IEC 61850-7-2.

11
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

ACSI models
Server model Logical-Device model
GetServerDirectory GetLogicalDeviceDirectory
Association model Logical-node model
Associate GetLogicalNodeDirectory
Abort GetAllDataValues
Release
Data-set model Control model
GetDataSetValues Select
SetDataSetValues SelectWithValue
CreateDataSet Cancel
DeleteDataSet Operate
GetDataSetDirectory CommandTermination
TimeActivatedOperate
Data-model File transfer model
GetDataValues GetFile
SetDataValues SetFile
GetDataDirectory DeleteFile
GetDataDefinition GetFileAttributeValues

Table 2-3 – Selection of ACSI information models

2.3.4 Substation Configuration Language

IEC 61850-6-1 specifies a new Substation Configuration Language (SCL) based on the
eXtensible Markup Language (XML) to describe the configuration of substation automation
systems based on the IEC 61850 standard. A hierarchy of XML-based configuration files is
specified by SCL, all files in the hierarchy have the same format but different scopes. Four
different types of configuration files are specified:

• System Specification Description (SSD) files

• IED Capability Description files (ICD) files
• Substation Configuration Description (SCD) files
• Configured IED Description (CID) files

The SCL files needed for IED configuration can be generated by off-line system development
tools, which eliminates most, if not all, manual configuration. Another advantage with SCL is
that it enables the sharing of IED configuration among users and suppliers, which reduces the
inconsistencies and misunderstandings in system configuration and requirements. Users can
provide their own SCL files to ensure that the devices will be delivered properly configured.
[Mac06]

SCL does not only make it possible to build up and configure substation automation systems,
it can also be used for specification of new ones. [Hog04]

12
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

2.3.5 Manufacturing Message Specification

The Manufacturing Message Specification (MMS) is an international standard that defines
how networked devices and/or computer applications may communicate with each other.
MMS (ISO 9506) was developed by Technical Committee Number 184 (TC184), Industrial
Automation, of the International Organization for Standardization (ISO), during the late
eighties, and it is today jointly managed by TC184 in collaboration with the International
Electro technical Commission (IEC).

The MMS standard is based on the Open Systems Interconnection (OSI) networking model
and provides messaging services appropriate for a variety of different application, devices,
and industries. The standard is divided into several parts, where the two first acts like the
“core” of MMS. The first part (ISO 9506-1) is the service specification, and the second part
(ISO 9506-2) is the protocol specification. The protocol specification defines the rules of
communication, e.g. sequencing of messages, message format, interaction with other layers of
the OSI model etc.

A presentation layer standard called Abstract Syntax Notation One (ASN.1 – ISO 8824) is
utilized by the MMS protocol specification to specify the format of he messages used by the
MMS services. The services provide for example functionality for initializing and managing
of application associations (connections), file transfer, reading/writing of named variables,
and remote program control. [Sis95]

MMS provides much of the functionality needed for implementation of the abstract services
defined by IEC 61850-7-2, and that’s the reason for why the mapping of abstract services to
MMS exists.

2.4 TCP Client

The Borland C++ Builder 6.0 environment provides a class called TIdTCPClient which
encapsulates a complete TCP client. The class can for example be used for initialization of a
TCP/IP connection with a specific server, and for bi-directional data transfer between a client
and a server. It should in other word be stupid to implement the TCP/IP protocol, since it is
already available for use.

TCP/IP is today a widely used protocol for data communication, and I feel that it would be
unnecessary to explain TCP/IP in detail, since there are several solutions available for TCP/IP
communication, e.g. the TIdTCPClient provided by Borland C++ Builder 6.0. But those who
want to have some more information about TCP/IP can always visit the free online dictionary
Wikipedia: http://en.wikipedia.org/wiki/Internet_protocol_suite

13
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

3 STINA™ - Disturbance and Fault Information Collection

and Analysis

The disturbance analysis and surveillance system STINA was originally developed for The
National Grid as an extra support system for gathering and analysis of disturbances and fault
on electricity networks. The STINA system collects and normalizes information from
different types and brands of protection and disturbance recording devices, and thus makes
easier for users to do disturbance analysis and fault locating since only one tool is needed
regardless of the manufacturer of the device. Information is not only gathered from physical
devices, it can also be retrieved via for example emails and reports from operations
technician. The information about STINA and the figures describing the system are from the
STINA product brochure [Pow06].

3.1 Hardware architecture

The STINA system has client/server hardware architecture, and it comprises client units, a
communications server, and a data server as modeled by Figure 3-1. STINA gathers and
normalizes data related to disturbances on power networks and makes the information
accessible for disturbance analysis. Information is retrieved from different sources, e.g.
disturbance recorders, fault locators, and event recorders.

DR – Disturbance recorders
PR – Protection relays
ER – Event recorders
FL – Fault locators
PQ – Power quality meters

Figure 3-1 – STINA Hardware architecture [Pow06]

Communications server
This part of STINA is responsible for gathering and
processing of data. It comprises software that acts like
the engine of the system, in order to ensure low
response times for data access.

14
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07
Database server
The database server is used for long-term data storage.
Data is stored in its file system and in the Oracle
database.

Database and File System

Disturbance information is primarily stored in the
Oracle database. Not only disturbance data is stored in
the database, information regarding substations,
equipments, schedules, logs, and connections are also
located here. COMTRADE files, documents, and other
files are stored in the file system.

Clients
The client tools provided by STINA can be used for
administration and configuration of the system, data
access, disturbance analysis, and fault locating.

The NAVIGATOR client tool is used for locating and structuring of data. It can also be used
for manual downloading of information from equipment in substations.

The ADMINISTRATOR client tool is used for administration and configuration of the
system.

The ARCHIVER client tool can be used to make a backup of the present information, and if
needed to restore the system.

The COMTRADE-VIEWER is used for investigation of COMTRADE files.

Communications equipment
Disturbance Information can be gathered from different
sources via for example multiple modem connections,
TCP/IP, and other types of communication solutions.

Remote equipment
Different types of remote equipment is supported, e.g.
Disturbance recorders (DR) and Protection Relays
(PR).

Local networks
Local Area Network is used for communication within
STINA (between Clients and Server), as well as for
communication with some of the remote equipment.

15
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07
3.2 Software design
The software of STINA is divided into several sub-systems, which together form a
homogenous system. Each sub-system has its own area of responsibility and clearly defined
interfaces. This approach was chosen to minimize the dependencies between different parts of
STINA, and to make the architecture flexible for future additions and modifications. Figure
3-2 shows an overview of the software parts included in a STINA system.

Figure 3-2 – STINA Software design

The purpose of this thesis was to show how IEC 61850 could be used for disturbance
analysis, and the goal was to develop an integration of IEC 61850 communication to STINA.
To be able to understand the presented solution, the reader must to have some basic
knowledge about some software parts in the STINA communication server.

3.2.1 Communication server software

The communication server software is separated into layers. The upper layer provides an
overall general framework, while the lower layers consist of the parts of the software adapted
to manage customer specific requirements and equipments, and partly of support functions in
the form of adaptation to the database and outside units.

KernelSrv
KernelSrv corresponds to the highest layer in the communication server software and
provides the overall general framework, its main functionality is to control and administrate
all jobs in the system. It handles the DCOM-based communication between the clients and the
communication server and reacts on requests from the Clients, e.g. to start manually
downloading of disturbance data from a specific station/device. KernelSrv uses services
provided by CommSrv and ProcSrv in order to gather and process disturbance data.

CommSrv
CommSrv’s responsibility is to handle communication and to collect disturbance data from
different kinds of physical devices. The adaptor principle is used to be able to communicate
with a variety of different types of devices.

16
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07
ProcSrv
ProcSrv’s responsibility is to convert and normalize the data downloaded by the CommSrv.
The adaptor principle is used to be able to support a variety of different devices.

DispatchSrv
DispatchSrv’s responsibility is to administrate all scheduled activities in STINA, e.g.
schedules for automatic collecting of disturbance data from physical devices located in
substations. DispatchSrv can start jobs, e.g. collecting of data, by using services provided by
KernelSrv.

3.2.2 Adaptor principle

The adaptor principle is used by STINA to be able to communicate with several different
types of devices. For each type of device separate adaptors are developed. The number of
adaptors used by STINA depends on the number of different types of equipment integrated in
the system. An adaptor is in real term a COM object encapsulated in a DLL. Two adaptors are
needed for each type of device, a communication (COMM) adaptor used by CommSrv to
download the data and store it as temporary files, and a process (PROC) adaptor used by
ProcSrv in order to process and normalize the downloaded data. The integration of IEC 61850
communication in STINA will result in a COMM adapter for communication to IEC 61850
compliant devices, and a PROC adapter that should process and normalize the downloaded
information. Figure 3-3 gives an overview of the adaptor principle.

Device X
Database
General
Server software

Communication
media ProcSrv Adaptor
X_PROC

Adaptor CommSrv
X_COMM

Figure 3-3 – STINA Adaptor principle

17
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

3.3 Navigator
The Navigator is STINA’s ordinary user’s client tool for searching, organizing, and viewing
data. It is also possible to initialize manual downloading of disturbance data by using this
tool. The Graphical user interface is similar to the GUI used by Windows Explorer, it is
divided into two parts where the left shows a tree structure of catalogs and the right one
shows the contents of the current catalog. (See Figure 3-4)

Figure 3-4 – STINA Navigator

3.4 Administrator
The Administrator tool is used for administration and configuration of STINA. This tool
provides for example functionality for adding, changing, removing, installations of stations,
devices in substations, and communication settings. Figure 3-5 shows the STINA
administrator tool.

Figure 3-5 – STINA Administrator

18
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07
3.5 COMTRADE Viewer
The STINA COMTRADE Viewer, shown by Figure 3-6, is used for investigating disturbance
data saved as COMTRADE files. Disturbance recordings downloaded from different types of
devices are converted by STINA, if applicable, into the standard COMTRADE format, which
makes it possible to compare disturbance recordings downloaded from different devices in a
simple way.

Figure 3-6 – STINA COMTRADE-Viewer

19
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

4 Lab equipment

ABB has developed a new series of products, the IED670 product series, for substation
automation. These new products implement all aspects of IEC 61850, and can interoperate
with other IEC 61850 compliant devices, tools, and systems. They do not only support IEC
61850, IEC 60870-5-103 and older ABB specific communication protocols are also
supported, which makes it possible to use these new products in parallel with older ones from
ABB.

The IED670 products are delivered pre-configured, type tested and with default parameters, to
make them easy to use. They are designed for TCP/IP and high-speed Ethernet based on
reliable and disturbance free optical communication. They are available in three different
sizes as shown by Figure 4-1. [Abb05][Abb06a] A REL670, which is designed for protection,
monitoring and control of overhead lines and cables, was used in this thesis during the
development and for verifying of functionality of the final prototype.

Figure 4-1 – ABB 670 IED [Abb06b]

20
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

5 COMTRADE - Common Format for Transient Data

Exchange
COMTRADE (IEEE STD C37.111) specifies a common format for transient data exchange.
Transient data is used for analysis and identification of undesirable sources of harmonics and
unbalances, fault locating and analysis of events causing power network instability. The
COMTRADE format consists of four different files, a configuration file, a data file, a header
file, and an information file. [CMT07a][CMT07b]

COMTRADE files
The configuration file (*.CFG) contains information about:
• Station name, used for identification.
• Number of digital channels
• Number of analog channels
• Channel names, units and conversion factors
• Line frequency
• Sample rate
• Number of samples
• Start time (Date and time of first data value)
• Trig time (Date and time of trigger point)
• Data file type (BINARY or ASCII)

The data file (*.DAT), which either can be in ASCII or BINARY format, contains the actual
transient data. The header file (*.HDR), which is optional, can be used to provide information
about the source, the location, the data format etc. The information file (*.INF) is optional and
can be used to provide setup information.

Figure 5-1 gives an example of a COMTRADE being investigated in a graphical

COMTRADE-viewer. The COMTRADE graph shows recorded sample values from both
analogical and digital channels around the time of a disturbance. The information displayed
by the viewer is useful when doing different kinds of disturbance analysis. Disturbance
analysis is however a subject not covered by this report, but COMTRADE files will be used
in the prototype implementation.

21
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

Figure 5-1 – COMTRADE investigated in a graphical COMTRADE viewer

22
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

6 Abstract Syntax Notation One

The protocol specification of the Manufacturing Message Specification (ISO 9506-2) defines
the MMS services in ASN.1 notation (ISO 8824-1, ITU-T X.680). The purpose of this section
is to give the reader basic knowledge about what ASN.1 (Abstract Syntax Notation One) is,
and how it can be used.

What is ASN.1?
ASN.1 is a formal language used for specifying data structures on a high level of abstraction,
independent from programming languages and computer platforms. Several different
standardized encoding rules, e.g. BER, DER or XER, can be used to encode the abstract
syntax described by ASN.1 notation into a concrete data representation (transfer syntax)
[Oss07a]

• The Basic Encoding Rules (BER) (ISO 8825-1, ITU-T X.690) was invented in the
early 1980s. BER encodes each data item as a type field, a length description and
the actual data. Encodings of this kind is commonly called type-length-value
(TLV) encodings.

• The Distinguished Encoding Rules (DER), which is a subset of BER, is used in

security-conscious applications.

• The XML Encoding Rules (XER) can be used to encode ASN.1 specifications into
XML format.

How is it used?
One way to work with protocols written in ASN.1 notation is to use an ASN.1 Tool, e.g. one
of the tools provided by Oss Nokalva [Oss07b]. Tools are available for almost every
operating system and they provide functionality for translating ASN.1 specifications into a
specific programming language, e.g. C or C++. Run time libraries, which are also provided by
several ASN.1 tools, can later be used for serializing/de-serializing of messages. This method
is recommended when doing larger implementations of protocols written in ASN.1, since it
will make the work a lot easier, and decrease the debugging and testing time. Another way to
work with ASN.1 specifications is to do the mapping of the abstract notation to a specific
programming language (e.g. C/C++) and the encoding/decoding methods manually without
any tool. This method is however only recommended for smaller implementations, when we
do not want to spend money on an ASN.1 tool license. More information about ASN.1 and
BER encoding can be found in appendix 1.

23
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

7 Problem formulation
Powel has developed a disturbance collecting/analysis system called STINA. STINA
currently supports a variety of legacy substation communication protocols. Different vendors
of protection devices and other substation devices, however have started to build in support
for the new global substation automation standard IEC 61850 into their devices and Powel is
now interested in integrating support for IEC 61850 communication into their system.

The IEC61850 substation communication standard is very extensive and covers all aspects
regarding communication in substations. The purpose of this thesis is to show how the new
substation automation standard can be used outside the substations. The major goal is to
develop an IEC 61850 communication prototype to STINA, not a complete product. The
work was intended to follow these steps:

• Study of the disturbance analysis system STINA.

• Study of IEC 61850 standard series and other conventional substation communication
protocols
• Installation of lab equipment, e.g. ABB REL670.
• Design of a STINA IEC 61850 communication prototype
• Implementation
• Testing
• Report writing
• Presentation of the STINA IEC 61850 communication prototype

24
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

8 Problem Analysis
The major problem, which is to develop an STINA IEC 61850 communication prototype, can
be divided into several sub-problems. This section describes the different sub-problems to
solve.

Identification of suitable information models

STINA needs information suitable for disturbance analysis. Which of the information models
provided by IEC 61850 can be used to retrieve this information?

Mapping of abstract services

The identified information models provide abstract services for information exchange. Which
of these abstract services is useable by the STINA IEC 61850 communication prototype, and
how does the mapping to the real communication protocol look like?

Communication Stack

The protocol mappings are by themselves not enough to make communication possible. What
communication stack should be used, and how should it be implemented?
The implemented communication stack should be used for integrating support for IEC 61850
communication in STINA.

Creating a STINA IEC 61850 communication prototype

The goal of this thesis is to make and show that it is possible to integrate support for IEC
61850 compliant devices in STINA. The final prototype must be able to provide STINA with
some useful information. To be able to do that, knowledge in both STINA and IEC 61850 is
needed. How should the downloaded information be accessible by STINA?

25
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

9 Methodology
The sub-problems, which all had to be solved in order to make a functional and usable STINA
IEC 61850 communication prototype, were solved by using the following methods.

9.1 Identification of suitable information models

STINA and earlier STINA communication was investigated to find out which kind of
information STINA needs. It was found out that a lot of the earlier STINA communication
solutions provide the system with COMTRADE files in one way or another. Some of the
solutions generated COMTRADE files from raw transient data, and other solutions
downloaded instead COMTRADE files directly from the physical devices. The COMTRADE
files can later be investigated by using the graphical COMTRADE-viewer provided by the
STINA system. A communication prototype that can provide STINA with COMTRADE files
containing disturbance information from IEC 61850 compliant devices, either by
downloading COMTRADE files directly from the devices or generating COMTRADE files
from raw transient data, seemed to be good and useable for remote disturbance analysis.

IEC 61850 was studied to see how the information needed to make a COMTRADE could be
accessed. It was however found out that COMTRADE files are generated by the disturbance
recorder (Logical node RDRE specified in IEC 61850-7-4) in IEC 61850 compliant devices
and stored within the server file store. It should thereby be possible to download generated
COMTRADE files directly from IEC 61850 compliant devices as long as they have a
disturbance recorder. The Logical Nodes and Device models of the ACSI will not be used by
the STINA IEC 61850 communication prototype, since file transfer is described by a separate
ACSI information model called the File-Transfer model.

9.1.1 Connection Establishment

A connection must be established before we can use services provided by the File-Transfer
model to download the wanted COMTRADE files. IEC 61850-7-2 specifies a model called
the TWO-PARTY-APPLICATION-ASSOCIATION (TPAA) model which describes the
actions on the Server side for establishing, managing, and terminating, of connections
between IEC 61850 clients and servers. [3] The following abstract services are provided by
the TPAA model:

The Associate Service

The Associate Service should be used to establish an association between a
client and a server. [3]

The Abort Service

The Abort Service should be used to abort the association. [3]

The Release Service

The Release Service should be used to terminate an association. [3]

26
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07
9.1.2 Downloading of COMTRADE files
The File-Transfer model specified by IEC 61850-7-2 defines how files are constructed,
services for managing and transferring of files are also described in an abstract way. A File
stored in the server should according to IEC 61850-7-2, FileTransfer model, have a format
according to Table 9-1.

FILE
Attribute Name Attribute Type
FileName VISIBLE STRING 255
FileSize INT32U
LastModified TimeStamp
Services
GetFile
SetFile
DeleteFile
GetFileAttributeValues
Table 9-1 – FILE class

Two of the services provided by the FILE class describe functionality needed by the STINA
IEC 61850 communication prototype, the GetFileAttributeValues service and the GetFile
service. The GetFileAttributeValues service can be used by a client to get the size and last
modified time of a specific file. [3] This information is needed to sort out files that have
already been downloaded by the prototype, so that a specific COMTRADE file is only
downloaded one time. The GetFile service will be used for downloading of COMTRADE
files.

File Selection
The FILE class provides only functionality for managing files and file transfer. To be able to
use the GetFile or the GetFileAttributeValues service provided by the FILE class, we must
know what files we can download. All files are stored in the server file store, and a list with
file names can be received by using the GetServerDirectory service provided by the
SERVER model. The prototype will use this functionality to retrieve a list of accessible files,
and then sort out which files to download by using file attributes like filename, and last
modified time. The GetServerDirectory service is described by Table 9-2.

GetServerDirectory Request:
Request The ObjectClass parameter specifies if we use the
ObjectClass service for getting a list with filenames or a list with
Response+
Reference[0..n]
object references to logical devices. [3] The
Response- prototype should only be able to get the filenames.
ServiceError

Table 9-2 – GetServerDirectory service

Response+:
Reference shall contain file names or object references to logical devices [3]. Only filenames
will be received by the STINA IEC 61850 prototype.

Response-
A Response- indicates that the request failed [3]. An appropriate ServiceError is sent from
the Server.

27
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

9.2 Mapping of abstract services

The prototype will only use Client/Server communication services identified in Clause 9.1.
Those services should according to IEC 61850-8-1 be implemented by using services
provided by Manufacturing Message Specification.

9.3 Communication Stack

Lab equipment was needed for testing during developing and for verifying the functionality of
the communication stack. An ABB REL670 relay [Abb05] was borrowed from E.ON in
Sundsvall and installed at Powel Energy Management in Östersund. The relay was connected
to Powel’s Local Area Network with an Ethernet-fiber optical network converter.

9.3.1 Communication stack design considerations

To be able to implement the MMS services which should be used to perform the functionality
described by the abstract services (Clause 9.1) so is a MMS communication stack with all
necessary layers included needed.

There are several ways to implement a MMS communication stack. One way is to buy an
implementation of it from another company, but this is expensive and not suitable for the
STINA IEC 61850 communication prototype since only a small subset of the communication
stack will be needed.

The MMS application layer is specified in ASN.1 format. One way to implement layers
written in ASN.1 is to use an ASN.1 tool [Oss07b]. An ASN.1 tool takes the ASN.1
specification and generates data structures (e.g. C/C++ structures) and code for serializing/de-
serializing the data structures. This could have been a very good way to solve the problem if
larger parts of the MMS application layer should have been used, but since only small parts of
it was needed it felt more instructive not to use a ASN.1 compiler, and instead learn the basics
of ASN.1. It also felt unnecessary to buy a license to an ASN.1 tool since the tool wouldn’t be
used too much. Mappings to C++ structures and serializing/de-serializing methods were
instead written from scratch.

Two different types of T-Profiles (OSI Layer 1-4) can be used by the MMS communication
stack, the OSI or TCP/IP T-profile. [4] The TCP/IP T-profile will be used by the prototype,
since the ABB REL670 relay uses TCP/IP communication. IEC 61850-8-1 does also state that
at least the TCP/IP profile should be supported.

The selected method for creating the communication stack became to implement the different
communication layers used by MMS on top of a TCP client. Only the absolutely necessary
parts of the communication stack were implemented, in order to make it small, simple, and
compact. This was done by first identifying the needed services top-down in the
communication stack, before implementing the communication stack bottom - up. A small
test application was created to be able to test the functionality of the communication stack
separately from the STINA system.

28
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

9.3.2 Useable Tools

A packet capture file with IP traffic between an ABB 670 IED and a MMS client was
received from ABB Power Technologies. This file became very useful during implementation
of the communication stack, since it gave an example of how the “real bits on the wire” may
look like.

A program called Ethereal was used during implementation of the communication stack to
capture the IP traffic between the small test application and the ABB relay, this program made
it a lot easier to do debugging and to find coding flaws. Ethereal is a very useful tool and must
be recommended for analyzing of protocol implementations.

9.4 Creating a STINA IEC 61850 communication prototype

STINA and the earlier STINA adapters were investigated to find out how they were designed
and how the internal communication in the system worked. The new STINA IEC 61850
communication prototype is designed as the earlier adapters and reuses functionality provided
by already implemented base classes.

The prototype was developed in Borland C++ Builder 6.0 since most of STINA is developed
with this tool. The Borland Development Environment is still used at Powel in Östersund.

29
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

10 Solution
A STINA IEC 61850 communication prototype has been developed during this thesis. The
prototype is based on information models provided by IEC 61850-7-2 and protocol mappings
provided by IEC 61850-8-1.

10.1 Abstract Services

The information models provided by the Abstract Communication Service Interface (ACSI)
define abstract services that should be used for information exchange. The following abstract
services describe functionality used by the Prototype.

10.1.1 The Associate Service

The Associate Service provided by the TWO-PARTY-APPLICATION-ASSOCIATION
model [3] is used by the STINA IEC 61850 communication prototype to establish a two-party
application association with a specific IEC 61850 hardware device. Figure 10-1 describes the
Associate Service in a simple way, the real service definition can be found in IEC 61850-7-2,
Clause 7.4.2. This abstract service will be used by the prototype to establish a connection.
Request succeeded Request failed
Associate request Associate request
SERVER

SERVER
CLIENT

CLIENT

Associate response+ Associate response-

Figure 10-1 – ACSI Associate service

10.1.2 The Abort Service

The Abort Service provided by the TWO-PARTY-APPLICATION-ASSOCIATION model is
used to abort a two-party-application association. All service request issued by the client shall
be discarded, and no further service shall be processed. [3] The definition of this service can
be found in IEC 61850-7-2, Clause 7.4.2. Figure 10-2 shows the main functionality of the
Abort Service. The association can be aborted by the Server or the Client.

Abort
SERVER
CLIENT

Abort Abort

Figure 10-2 – ACSI Abort service

30
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

10.1.3 The Release Service

The Release Service provide by the TWO-PARTY-APPLICATION-ASSOCIATION model
[3] is used by the STINA IEC 61850 prototype to terminate an association between itself and
an IEC 61850 server. All service request issued shall be completed before the termination of
the association. The definition of this service can be found in IEC 61850-7-2, Clause 7.4.2.
Figure 10-3 describes the Release service in a simplified way.

Request succeeded Request failed

Release request Release request
SERVER

SERVER
CLIENT

CLIENT
Release response+ Release response-

Figure 10-3 – ACSI Release service

10.1.4 The GetServerDirectory Service

The GetServerDirectory service provided by the SERVER-model can be used to retrieve a list
of all accessible LOGICAL-DEVICES or Files. [3] It is used by the STINA IEC 61850
prototype to get the names of accessible files in a specific IEC 61850 device. The definition
of this service can be found in IEC 61850-7-2, Clause 6.2.2. Figure 10-4 describes the
GetServerDirectory service in a simplified way.

Request succeeded Request failed

GetServerDirectory req GetServerDirectory req
SERVER
SERVER

CLIENT
CLIENT

GetServerDirectory resp+ GetServerDirectory resp-

Figure 10-4 – ACSI GetServerDirectory service

31
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

10.1.5 The GetFile Service

The GetFile service should be used by a client to get the contents of a specific file within the
server file store. [3] This service is used by the STINA IEC 61850 prototype to download
COMTRADE files. The definition of this service can be found in IEC 61850-7-2, Clause
20.2.1. Figure 10-5 describes the GetFile service in a simplified way.
Request succeeded Request failed
GetFile req GetFile req

SERVER
SERVER

CLIENT
CLIENT

GetFile resp+ GetFile resp-

Figure 10-5 – ACSI GetFile service

10.1.6 The GetFileAttributeValues Service

The GetFileAttributeValues service is used to get the attributes, including the last modified
time and size, of a specific file. [3] The attributes is used by the prototype to select if a file
should be downloaded or not, to avoid downloading the same COMTRADE file several
times. It is not enough to check the Filenames, since a new COMTRADE can be generated
with the same name as an old one. The definition of this service can be found in IEC 61850-
7-2, Clause 20.2.4. Figure 10-6 describes the GetFileAttributeValues service in a simplified
way.

Request succeeded Request failed

GetFileAttributeValues req GetFileAttributeValues req
SERVER
SERVER

CLIENT
CLIENT

GetFileAttributeValues resp+ GetFileAttributeValues resp-

Figure 10-6 – ACSI GetFileAttributeValues service

32
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

10.2 Mapping of abstract services

The abstract services described in Clause 10.1 only describe the functionality in an abstract
way, and they must be implemented by using a specific communication protocol. Those
services should according to IEC 61850-8-1 be implemented by using the MMS application
layer.

The information below describes the mappings specified by IEC 61850-8-1 in a simplified
way to make them as easy as possible to understand. More information about the mappings
can be found in IEC 61850-8-1. The MMS services identified by doing this mapping will later
be used by the prototype to communicate with IEC 61850 compliant devices.

10.2.1 Mapping of Associate Service

The ACSI Associate Service (10.1.1) should be mapped directly to the MMS initiate service
[4]. The prototype uses the MMS initiate service to establish a connection with an IEC 61850-
compliant device.

10.2.2 Mapping of Abort Service

The ACSI Abort Service (10.1.2) should be mapped directly to the MMS Abort service. [4]

10.2.3 Mapping of Release Service

The ACSI Release Service (10.1.3) should be mapped directly to the MMS conclude service.
[4] The prototype uses the MMS conclude service to release the connection.

10.2.4 Mapping of GetServerDirectory Service

The GetServerDirectory (10.1.4) should be implemented by using the MMS FileDirectory as
described by Figure 10-7. COMTRADE files should be stored within a directory called
“COMTRADE”, and zip files located in that directory shall contain compressed
COMTRADEs. [4] The prototype uses the MMS FileDirectory Service for downloading of
names of the files contained in the Server. This mapping is only valid when names of files
should be received, another mapping should be used when object reference to logical devices
are wanted. The prototype will however only handle files.

ACSI Client MMS Provider

Note1
GetServerDirectory.req FileDirectory.req Several FileDirectory request
should be sent until
MoreFollows == false in the
FileDirectory confirm.
GetServerDirectory.resp+
Note2
A MMS service conf- response
FileDirectory.conf+ should generate a
GetServerDirectory resp-.

Figure 10-7 – Mapping of GetServerDirectory service to MMS

33
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07
10.2.5 Mapping of GetFile
The GetFile service (10.1.5) should be mapped to a sequence of MMS FileOpen, FileRead
and FileClose services according to Figure 10-8. [4] The prototype uses this functionality to
download COMTRADE files.

ACSI Client MMS Provider

GetFile.req FileOpen.req

FileOpen.conf+

Note1
FileRead.req Several FileRead requests
should be sent until
MoreFollows == false in the
FileRead.conf+ FileRead confirm.

FileClose.req
Note2
A MMS service conf- response
GetFile.resp should generate a GetFile resp-.

FileClose.conf+

Figure 10-8 – Mapping of GetFile service to MMS

10.2.6 Mapping of GetFileAttributeValues

The GetServerDirectory (10.1.6) should be implemented by using the MMS FileDirectory as
described by Figure 10-9. [4] Note that this mapping uses the same MMS service as the
mapping for the GetServerDirectory service (10.2.4), it should thereby be possible to
download the filenames of files contained in a server and other attributes at the same time,
which the final prototype also does.

ACSI Client MMS Provider

Note1
GetFileAttributeValues.req FileDirectory.req Several FileDirectory request
should be sent until
MoreFollows == false in the
FileDirectory confirm.
GetFileAttributeValues.resp+
Note2
A MMS service conf- response
FileDirectory.conf+ should generate a
GetFileAttributeValues resp-.

Figure 10-9 – Mapping of GetFileAttributeValues service to MMS

34
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

10.3 Manufacturing Message Specification

The protocol specification of Manufacturing Message Specification is defined in ASN.1
notation. Appendix A provides more basic information about ASN.1 and BER encoding. This
section of the report is instead supposed to give the reader extra information about the MMS
services used by the developed prototype. The ASN.1 notation that appears in this report is
sometimes simplified to make them more understandable and easier to read. The original
ASN.1 notation can be found in ISO 9506-2.

10.3.1 Protocol Data Units

MMS defines fourteen types of protocol data units (PDUs) [5], only 9 of these is used for
communication between the STINA IEC 61850 prototype and IEC 61850 compliant devices.
The different types used by the prototype can be described by the ASN.1 syntax below, which
is a subset of the syntax specified by IEC 9506-2.

MMSpdu ::= CHOICE {

--SIMPLIFIED NOTATION
confirmed-RequestPDU [0] IMPLICIT Confirmed-RequestPDU,
confirmed-ResponsePDU [1] IMPLICIT Confirmed-ResponsePDU,
confimed-ErrorPDU [2] IMPLICIT Confimed-ErrorPDU,
initiate-RequestPDU [8] IMPLICIT Initiate-RequestPDU,
initiate-ResponsePDU [9] IMPLICIT Initiate-ResponsePDU,
initiate-ErrorPDU [10] IMPLICIT Initiate-ErrorPDU,
conclude-RequestPDU [11] IMPLICIT Conclude-RequestPDU,
conclude-ResponsePDU [12] IMPLICIT Conclude-ResponsePDU,
conclude-ErrorPDU [13] IMPLICIT Conclude-ErrorPDU
}

The initiate PDUs are used by the initiate Service. The confirmed-request, the confirmed-
response, and the confirmed-error PDUs are used by different client/server services, e.g. file
services. The conclude PDUs are used by the MMS conclude service. Error PDUs are not
fully handled by the prototype. If an error is received, then the communication stack detects
an invalid reply and as a consequence of that an exception is thrown.

10.3.2 Initiate Service

An Initiate-RequestPDU is sent by the client to establish a connection, and a response should
be received. An incoming Error-PDU indicates that the initialization failed. [5] The ASN.1
notation below describes the structure of the request. Some parts are optional and not used by
the prototype implementation.
Abstract syntax: Initiate-RequestPDU

Initiate-RequestPDU ::= SEQUENCE {

localDetailCalling [0] IMPLICIT Integer32 OPTIONAL,
proposedMaxServOutStandingCalling [1] IMPLICIT Integer16,
proposedMaxServOutStandingCalled [2] IMPLICIT Integer16,
proposedDataStructureNestingLevel [3] IMPLICIT Integer8 OPTIONAL,
initRequestDetail [4] IMPLICIT SEQUENCE {
proposedVersionNumber [0] IMPLICIT Integer16,
proposedParameterCBB [1] IMPLICIT ParameterSupportOptions,
servicesSupportedCalling [2] IMPLICIT ServiceSupportOptions,
…
IF (csr cspi) -- NOT USED BY THE PROTOTYPE IMPLEMENTATION
, additionalSupportedCalling [3] IMPLICIT AdditionalSupportOptions

35
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07
ENDIF
IF (cspi) – NOT USED BY THE PROTOTYPE IMPLEMENTATION
, additionalCbbSupportedCalling [4] IMPLICITAdditionalCBBOptions,
privilegeClassIdentityCalling [5] IMPLICIT VisibleString
ENDIF
}
}

The following values are used by the prototype:

localDetailCalling = 8000 (Max MMS PDU size)
proposedMaxServOutStandingCalling = 1
proposedMaxServOutStandingCalled = 1
proposedDataStructureNestingLevel =5
proposedVersionNumber = 1 (Defined by MMS standard)
proposedParameterCBB = str1 (ArraySupport) and str2 (StructureSupport)
servicesSupportedCalling = 0 -- The client does not provide any services, it only uses service provided by
the IEC 61850 compliant device

An Initiate-ResponsePDU should be received after the request has been sent. The response
should have a format according to the abstract syntax below. The initiate response PDU is not
parsed by the implemented Client. A check is performed to see that we received a correct
response, but the different parameters are not controlled.
Abstract syntax: Initiate-ResponsePDU

Initiate-ResponsePDU ::= SEQUENCE {

localDetailCalled [0] IMPLICIT Integer32 OPTIONAL,
negotiatedMaxServOutStandingCalling [1] IMPLICIT Integer16,
negotiatedMaxServOutStandingCalled [2] IMPLICIT Integer16,
negotiatedDataStructureNestingLevel [3] IMPLICIT Integer8 OPTIONAL,
initResponseDetail [4] IMPLICIT SEQUENCE {
negotiatedVersionNumber [0] IMPLICIT Integer16,
negotiatedParameterCBB [1] IMPLICIT ParameterSupportOptions,
servicesSupportedCalled [2] IMPLICIT ServiceSupportOptions,
…
IF (csr cspi)
, additionalSupportedCalling [3] IMPLICIT AdditionalSupportOptions
ENDIF
IF (cspi)
, additionalCbbSupportedCalled [4] IMPLICITAdditionalCBBOptions
privilegeClassIdentityCalled [5] IMPLICIT VisibleString
ENDIF
}
}

An incoming Initiate-ErrorPDU instead of an incoming Initiate-ResponsePDU indicates that

the initialization failed.

Abstract syntax: Initiate-ErrorPDU

Initiate-ErrorPDU ::= ServiceError

36
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

10.3.3 Conclude-Service
The Conclude service shall be used to gracefully terminate a connection. Gracefully means
that the connection is released without any loss of information, all other issued requests must
be completed before the connection can be terminated.

The conclude service PDUs are simple, the Conclude-RequestPDU and the Conclude-
Response corresponds to NULL, and the Conclude-ErrorPDU corresponds to a ServiceError.
Abstract syntax: Conclude

Conclude-RequestPDU ::= NULL

Conclude-ResponsePDU ::= NULL
Conclude-ErrorPDU ::= ServiceError

10.3.4 Abort
Abort service should be directly mapped to the M-U-ABORT service provided by ACSE
(ISO 8649/8650) [5]. The Abort service is not actually used by the prototype, and will
therefore not be explained. Abortion of the association was instead implemented by closing
the TCP/IP connection directly, which works like a hard but yet effective abort.

10.3.5 File services

File services uses the Confirmed-RequestPDU, the Confirmed-ResponsePDU, and the
Confirmed-ErrorPDU. A Confirmed-RequestPDU is sent by the client to request a service,
and a Confirmed-ResponsePDU should be received.

Abstract syntax: Confirmed-RequestPDU

Confirmed-RequestPDU ::= SEQUENCE

{
invokeID Unsigned32
service ConfirmedServiceRequest,
}
The service parameter of type ConfirmedServiceRequest shall correspond to specific service
request, e.g. a FileDirectory-Request. [5]

Abstract syntax: Confirmed-ResponsePDU

Confirmed-ResponsePDU ::= SEQUENCE {

invokeID Unsigned32
service ConfirmedServiceResponse,
}

The service parameter of type ConfirmedServiceResponse shall correspond to a specific

service response, a FileDirectory-Response if a FileDirectory-Request was sent. An incoming
Confirmed-ErrorPDU indicates that the request failed. [5]

Abstract syntax: Confirmed-ErrorPDU

Confirmed-ErrorPDU ::= SEQUENCE {

invokeID [0] IMPLICIT Unsigned32
serviceError [2] IMPLICIT ServiceError,
}
The serviceError parameter contains a specific ServiceError.

37
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

All confirmed service PDUs contains an invokeID. The invoke id is used to relate a response
with a specific request. The invoke id of the RequestPDU should be the same as the invoke id
of the ResponsePDU or ErrorPDU. [5] Confirmed-Error PDUs are not fully handled by the
prototype; an incoming ErrorPDU will result in the generation of an exception. The exception
is handled by the prototype by closing down the communication.

There are a lot of different MMS confirmed services that can be used, but only four are used
by the STINA IEC 61850 communication prototype. These are: FileOpen, FileRead,
FileClose, and FileDirectory.

Abstract syntax: ConfirmedServiceRequest

ConfirmedServiceRequest ::= CHOICE {

--Selection of services
fileOpen [72] IMPLICIT FileOpen-Request
fileRead [73] IMPLICIT FileRead-Request
fileClose [74] IMPLICIT FileClose-Request
fileDirectory [77] IMPLICIT FileDirectory-Request
}

Abstract syntax: ConfirmedServiceResponse

ConfirmedServiceResponse ::= CHOICE {

--Selection of services
fileOpen [72] IMPLICIT FileOpen-Response
fileRead [73] IMPLICIT FileRead-Response
fileClose [74] IMPLICIT FileClose-Response
fileDirectory [77] IMPLICIT FileDirectory-Response
}

10.3.6 FileOpen
A FileOpen-Request is sent by the client to open a file in the server file store and make it
available for file transfer. The request takes two parameters, the filename and the initial
position. The initial position should be set to zero to download the complete file. [5]

A FileOpen-Response should be received. The response contains two parameters, the frsmId
and file attributes. The attributes consist of the file size and last modified time of the file. The
frsmId (file resource manager id) shall be used by the FileRead service. [5]

Abstract syntax: FileOpen

FileAttributes ::= SEQUENCE {

sizeOfFile [0] IMPLICIT Unsigned 32,
lastModified [1] IMPLICIT GeneralizedTime OPTIONAL }

FileName ::= SEQUENCE OF GraphicString

FileOpen-Request ::= SEQUENCE {

fileName [0] IMPLICIT FileName,
initialPosition [1] IMPLICIT Unsigned32 }

FileOpen-Response ::= SEQUENCE {

frsmID [0] IMPLICIT Integer32,
fileAttributes [1] IMPLICIT FileAttributes }

38
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07
10.3.7 FileRead
When the file has been opened then it is available for transfer. The Client should send a
FileRead-Request equals to the frsmId from the FileOpen-Response to retrieve the contents
of the file. The Server should response with a FileRead-Response containing fileData and
the moreFollows parameter. If moreFollows = true, then one more FileRead-Request should
be sent by the client until the moreFollows = false in the new Response. [5]

Abstract syntax: FileRead

FileRead-Request ::= Integer32 -- FRSM ID

FileRead-Response ::= SEQUENCE {

fileData [0] IMPLICIT OCTET STRING,
moreFollows [1] IMPLICIT BOOLEAN DEFAULT TRUE}

10.3.8 FileClose
After the contents of the file have been received, then the client should close the file in the
server file store by using the FileClose service. A FileClose-Request should be sent by the
Client, and a FileClose-Response should be received. [5]

Abstract syntax: FileClose

FileClose-Request ::= Integer32 – FRSM ID

FileClose-Response ::= NULL

10.3.9 FileDirectory
The FileDirectory service should be used to retrieve a list of names and other attributes of
available files within a MMS server file store. A FileDirectory-Request should be sent, and a
FileDirectory-Response should be received. [5]

Abstract syntax: FileDirectory-Request

FileDirectory-Request ::= SEQUENCE {

fileSpecification [0] IMPLICIT FileName OPTIONAL,
continueAfter [1] IMPLICIT FileNAme OPTIONAL }

The parameter fileSpecifiaction is optional. When it is present then it shall identify a file or a
group of file in the server file store whose attributes are desired. If it isn’t present, then
attributes of a default group of files are requested.

The continueAfter parameter is optional. When it is present, then it shall identify a starting
point within an ordered list of the complete group of files selected by the fileSpecification
parameter. Only attributes of the proceeding files are included in the result. [5]

Abstract syntax: FileDirectory-Response

FileDirectory-Response ::= SEQUENCE {

listOfDirectoryEntry [0] SEQUENCE OF DirectoryEntry
moreFollows [1] IMPLICIT BOOLEN DEFAULT FALSE }

The listOfDirectoryEntry parameter shall contain a list with directory entries.

39
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07
If moreFollows = true, then one more FileDirectory-Request should be sent until
moreFollows = false in the response. [5]

A directory entry consists of the filename and other file attributes, like size and last modified
time, according to the syntax below.

Abstract syntax: Directory-Entry

DirectoryEntry ::= SEQUENCE {

fileName [0] IMPLICIT FileName,
fileAttributes [1] IMPLICIT FileAttributes
}

FileAttributes ::= SEQUENCE {

sizeOfFile [0] IMPLICIT Unsigned 32,
lastModified [1] IMPLICIT GeneralizedTime OPTIONAL }

10.4 BER Encoding/Decoding

Manufacturing message specification is defined in ASN.1 syntax. The prototype uses simple
methods for BER encoding and decoding. The example below describes how messages are
encoded and decoded when using Basic Encoding Rules. (ISO 8825-1, X.690)

Example:
The abstract service GetFile shall be mapped to a sequence of MMS FileOpen, FileRead and
FileClose. This example will show how the FileOpen-Request is encoded, and how an
incoming FileOpen-Response is decoded. More information about ASN.1 and BER encoding
can be found in appendix A, which shall be used as a extra help to understand how ASN.1
types is built up, and how they are encoded/decoded.

The client sends a FileOpen-Request message to start downloading a specific file. We assume
that the filename of the wanted file is “/flash/drec/drec_31.zip” (corresponds to one of the
files available in the test equipment) and that the complete file should be downloaded.
(initialPosition == 0) Lets also assume that the invoke id = 0.

The FileOpen request can be described as below. This is a simplification of the ASN.1 syntax
defined in 10.3.5 and 10.3.6.

confirmedRequest [0] IMPLICIT SEQUENCE

{
invokeID Unsigned32
fileOpen-Request [72] IMPLICIT SEQUENCE
{
fileName [0] IMPLICIT Sequence of graphic string,
initialPosition [1] IMPLICIT Unsigned32
}
}

40
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07
The FileOpen-Request would be encoded like below:

(T = TAG, L = LENGTH, V= VALUE)

[0] IMPLICIT SEQUENCE (confirmedRequest)

T L V
0xA0 0x24 Unsinged32 (invokeID = 0)
T L V
0x02 0x01 0x00
[72] IMPLICIT SEQUENCE (fileOpen-Request)
T L V
0xBF, 0x48 0x1E (filename = ”/flash/drec/drec_31.zip”)

(72 > 30) =>2 byte tag [0] IMPLICIT SEQUENCE OF

T L V
0xA0, 0x19,
Graphic String
T L V
0x19, 0x17, filename

[1] IMPLICIT Unsigned32

T L V
0x81 0x01 0x00

Encoded data:
0xA0, 0x24, 0x02, 0x01, 0x00, 0xBF, 0x48, 0x1E, 0xA0, 0x19, 0x19, 0x17, ’/’, ’f’, ’l’, ’a’,
’s’, ’h’, ’/’, ’d’, ’r’, ’e’, ’c’, ’/’, ’d’, ’r’, ’e’, ’c’, ’_’, ’3’, ’1’, ’.’, ’z’, ’i’, ’p’, 0x81, 0x01, 0x00

The client sends the encoded data, and the server answers with the byte stream below.

0xA1, 0x23, 0x02, 0x01, 0x00, 0xBF, 0x48, 0x1D, 0x80, 0x04, 0x07, 0x81, 0xEB, 0x10,
0xA1, 0x15, 0x80, 0x02, 0x14, 0x7B, 0x81, 0x0F, 0x32, 0x30, 0x30, 0x36, 0x31, 0x31, 0x31
0x30, 0x31, 0x33, 0x32, 0x39, 0x32, 0x30, 0x5A

41
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07
Decoding of the FileOpen-Response:

[1] IMPLICIT SEQUENCE (Confirmed-ResponsePDU)

T L V
0xA1 0x23 Unsigned32 (InvokeID)
T L V
0x02 0x01 0x00
[72] IMPLICIT SEQUENCE (FileOpen-Response)
T L V
0xBF, 0x48 0x1D [0] IMPLICIT Integer32 (frsmId = 125954832)
(0xBF => tag > 30) T L V
0x80 0x04 0x07, 0x81, 0xEB, 0x10
[1] IMPLICIT SEQUENCE (FileAttributes)
T L V
0x81 0x15 [0] IMPLICIT Unsigned 32 (size = 5243)
T L V
0x80 0x02 0x14, 0x7b
[1] IMPLICIT GeneralizedTime
T L V
0x81 0x0F 0x32, 0x30, 0x30, 0x36,

0x31, 0x31, 0x31 0x30,

0x31, 0x33, 0x32, 0x39,
0x32, 0x30, 0x5A
(lastModified = 20061110 132920Z)

There are three types of encodings for GeneralizedTime, the ’Z’ means that the time
corresponds to GMT (Greenwich Mean Time).

The decoding can be described by the following ASN.1 notation:

FileOpenResponse [1] IMPLICIT SEQUENCE

{
invokeID Unsigned32 -- (invokeID = 0),
fileOpen-Response [72] IMPLICIT SEQUENCE
{
frsmId [0] IMPLICIT Integer32 -- (frsmId = 125954832),
fileAttributes [1] IMPLICIT FileAttributes
}

}
FileAttributes ::= SEQUENCE {
sizeOfFile [0] IMPLICIT Unsigned 32 -- (size = 5243)
lastModified [1] IMPLICIT GeneralizedTime
--(lastModified = 20061110 132920Z)
}
Result: InvokeId = 0, frsmID = 125954832, sizeOfFile = 5243,
lastModified = 2006-11-10 13:29:20 (GMT)

Note: The frsmId shall later be used to retrieve the contents of the opened file.

42
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07
10.5 Mappings between C++ and ASN.1
The implemented communication stack uses a simple method for mapping of ASN.1 syntax to
c++. Here is an example of how the ASN.1 syntax for FileOpen-Request can be described in
C++.

A FileOpen-Request is transferred in a CConfirmedRequestPDU (See 10.3.5). The

ConfirmedRequestPDU can be implemented in C++ as:

class CConfirmedRequestPDU
{
public:
//methods for setting of attributes
void SetService(CConfirmedServiceRequest * ccsrService);
void SetInvokeID(unsigned int invokeid);

//methods for encoding/decoding

virtual void GetFrame(byte ** buf, int &len);
virtual void SetFrame(byte * buf, int len);
private:
unsigned int invokeID;
CConfirmedServiceRequest * service;
};
The FileOpen-Request is only one of several existing service requests. All service requests
have the same syntax, which can be implemented by a pure virtual base class.
class CConfirmedServiceRequest
{
public:
//Encoding
virtual void GetFrame(byte ** buf, int &len)=0;

//Decoding
void SetFrame(byte * buf, int len)
{
//No need for decoding of request, they will only be sent from the client.
}
};

The ASN.1 notation for FileOpen-Request (10.3.6) can be implemented by a realization of the
pure virtual base class CConfirmedServiceRequest.

class CFileOpenRequest : public CConfirmedServiceRequest

{
public:
void SetFileName(char * filename, unsigned int length);
void SetInitialPosition(unsigned int initPos);
void GetFrame(byte ** buf, int &len);
private:
char * fileName;
unsigned int initialPosition;
};

The serialization of the classes is implemented in the GetFrame method, and the de-
serialization is implemented in the SetFrame method. There is however no need for de-
serialization of requests, since they will only be sent by the client. In the same way is there no
need for serialization of response messages, since they will only be received by the prototype.
The SetFrame and GetFrame methods use the rules defined by BER.

43
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

My own reflections regarding ASN.1 and BER

The ASN.1 notation can be mapped to C++ in several different ways. The serialized byte-
stream must however always correspond to the serialization of the ASN.1 notation, since it is
always in the end the “bytes on the wire” that matters. But it is also good to have a mapping
that looks like the object oriented ASN.1 syntax, since it makes it easier to do a correct
encoding/decoding.

10.6 Communication Stack

To be able to implement the MMS services identified by doing the abstract service mapping
(section 8.2), a small subset of the communication stack specified by the IEC 61850-8-1
standard is needed. The goal became to develop a simple and compact but yet functional
communication stack, which makes it possible for the STINA IEC 61850 prototype to
download disturbance information (COMTRADE files) from IEC 61850 compliant devices.

The following MMS services were identified by doing the service mapping:

• Initiate
• (Abort)
• Conclude
• FileDirectory
• FileOpen
• FileRead
• FileClose

A communication stack that supported those services had to be implemented in order to

provide the prototype the desired functionality. The Abort service became however later
unnecessary for the prototype, and is because of that not supported by the final
communication stack. The communication between the Client and the Server can instead be
aborted by closing the transport connection directly. If the server sends an Abort message to
the client, the client will recognize an unsupported message and as a consequence of that the
transport layer will be disconnected.

44
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

10.6.1 Communication stack specified by IEC 61850-8-1

The IEC 61850-8-1 standard specifies that a communication stack according to Table 10-1
should be used for Client/Server services based on MMS on top of TCP/IP. A small subset of
this communication stack was implemented and used for downloading disturbance
information to STINA.

OSI model Specification m/o

layer
Name Service Protocol
Specification Specification
Application Manufacturing ISO 9506-1:2003 ISO 9506-2:2003 m
Message
Specification
Association Control ISO/IEC 8649:1996 ISO/IEC 8650:1996 m
Service Element
Presentation Connection ISO/IEC 8822:1994 ISO/IEC 8823- m
Oriented 1:1994
Presentation
Abstract Syntax ISO/IEC 8824- ISO/IEC 8825-1 m
1:1999
Session Connection ISO/IEC 8326:1996 ISO/IEC 8327- M
Oriented Session (X.225) 1:1997 (X.225)

Transport ISO transport on RFC 1006 (RFC 905) m

top of TCP
Internet Control RFC 792 m
Message Protocol
Transport Control RFC 793 m
Protocol
Network Internet Protocol RFC 791 m
An Ethernet RFC 826 m
Address Resolution
protocol (ARP)
DataLink Standard for the RFC 894 m
transmission of IP
datagrams over
Ethernet networks
Carrier Sense ISO/IEC 8802-3:2001 m
Multiple Access
with collision
detection
(CSMA/CD)
Physical 10Base-T/100Base- ISO/IEC 8802-3:2001 m (Option 1 or 2)
(option 1) T
Interface connector ISO/IEC 8877:1992
and contact
assignments for
ISDN Basic Access
Interface
Physical Fiber Optical ISO/IEC 8802-3:2001 m (Option 1 or 2)
(option 2) transmission system
100Base-FX
Basic Optical Fiber IEC 60874-10-1, IEC 60874-10-2 and IEC
Connector 60874-10-3
Table 10-1 – MMS based on TCP/IP T-profile

45
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

10.6.2 Reduced communication stack

A reduced version of the MMS communication stack specified by Table 10-1 was needed to
provide the STINA IEC 61850 communication prototype the desired functionality. The
implemented communication stack use the same framing as the communication stack
specified by IEC 61850-8-1, but the internal architecture is a bit different.

Overall Design
Figure 10-10 shows the structure of
the implemented communication
stack, where the
IEC61850ClientFileServices class
acts like the application layer, and
the TIDTCPClient class provided by
Borland implements the most of the
functionality in the transport layer.

The implemented communication

stack provides the following
methods to its user:
• SetIP
• GetFile
• GetDirectory (Only filenames)
• Initiate
• Conclude

The architecture of the

communication stack is layered, but
the different layers should not be
seen as independent layers, as they
only implement the functionality
needed by the layer above. The
implemented communication stack
can thereby be seen as an STINA
IEC 61850 specific communication
stack.

Figure 10-10 – Reduced communication

stack design

46
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

Transport Layer
Most of the Transport Layer was implemented by using the TCP/IP client (TIdTCPClient)
provided by the Borland C++ Builder Environment, only the part “ISO transport on top of
TCP/IP” had to be implemented. The implementation does not follow RFC1006 (see Table
10-1) strictly, it is instead only implemented to look like the protocol described by RFC1006.

Packet Format
The protocol described by RFC1006 [7] defines a simple packet format. Each packet, termed
TPKT, has a format according to Table 10-2.

TPKT
Packet Header TPDU
Byte 0 Byte 1 Byte 2 & Byte 3 Byte 4 –
Vrsn reserved packet length data
Table 10-2 – Transport packet format
vrsn – This field is always 0x03 for the version of the protocol described by RFC 1006.[7]
reserved – This field is reserved; value 0x00 could be used
packet length – This field contains the length (in bytes) of the entire TPKT. [7]

RFC905 describes the services provided by the transport layer (ISO 8073) and the used
transport protocol data units (TPDUs). Five different transport protocols are described by
RFC905, RFC1006 specifies that transport protocol class 0 (TP0) should be used. TP0
performs segmentation and reassembling of data.

The implemented class called CTPKT provides methods for initializing a TCP/IP connection,
for sending TPDUs (Transport Protocol Data Units), for receiving TPDUs, and for closing the
initialized connection. The cTCPClient class is an extension of the TCP client provided by
Borland, it implements a new read method with timeout control. The transport layer is
implemented by the CCOTP class and provides the following methods.

SetIp
The SetIP method, described by Figure 10-11,
sets the IP number used by the TCP client. This
method is used instead of transferring the IP
address as a parameter in the ConnectionRequest
method.

void SetIp(AnsiString asIP)

The asIP parameter shall contain the IP number.

Figure 10-11– Transport Layer - SetIP

47
 Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07
ConnectionRequest
The ConnectionRequest method described by
Figure 10-12 should be used to initiate a transport
connection. The method sends a CR TPDU and
expects a CC TPDU. More information about
connection establishment can be found in RFC905.

int ConnectionRequest(unsigned short

source_ref);

The source_ref parameter is used to identify the

source of the request. The function returns 1 on
success, and generates exception on error.

Figure 10-12 – Transport Layer -

ConnectionRequest

SendData
The SendData method described by Figure 10-13
should be used by the session layer to send user
data. The data is packed into a DT TPDU as
defined by RFC905. Segmentation (fragmenting)
of data is not implemented since only small data
blocks will be sent by the STINA IEC 61850
prototype.

void SendData(byte * buffer, int len);

Figure 10-13 – Transport Layer - SendData
The buffer parameter shall contain the data to be
sent.
The len parameter shall specify the length of the
data.

ReceiveData
The ReceiveData method described by Figure
10-14 shall be used by the session layer to receive
user data. Data is unpacked from DT TPDUs as
defined by RFC 905. Reassembling of data is
implemented to make it possible to reassemble
segmented data sent from the server.

void ReceiveData(byte ** buffer, int &len);

Figure 10-14 – Transport Layer - ReceiveData
The buffer parameter contains the received data.
The len parameter specifies the length of the
received data.

48
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07
Disconnect
The Disconnect method should be used by the
session layer to disconnect the transport
connection. The implicit disconnect method
defined by RFC905 is used. The transport layer is
disconnected by closing the TCP/IP connection
directly.

void Disconnect();

Figure 10-15 – Transport Layer -Disconnect

Session Layer
The Session Layer is implemented by using the methods provided by the implementation of
the transport layer (the CCOTP class). The implementation of the session layer (ISO 8327) is
based on ITU-T recommendation X.225 and provides four methods to the layer above. The
methods are implemented sequentially, they sends a request and waits for a response. The
implementation provides functionality for session management and data transfer. More
information about the session layer (ISO 8327) can be found at [Jav07b].

SetIP
The SetIP method should be used to set the IP-
number used by the transport layer. This
method is used instead of transferring the IP-
number as a parameter in the Connect method.

Figure 10-16 – Session Layer - SetIP

Connect
The Connect method should be used to
establish a Session connection, it works as the
S-CONNECT service defined by ITU-T
recommendation X.225.

The ConnectionRequest method provided by

the implementation of the transport layer is
first used to establish a transport connection.

The second step is to use the SendData method

provided by the transport layer to send a CN
Session Protocol Data Unit (SPDU)

An AC SPDU should later be received if the

request succeeded. [ITU88]
Figure 10-17 – Session Layer - Connect

49
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

DataTransfer
The DataTransfer method should be used to
transfer session user data between a client and
a server, and it used the same framing as
normal data transfer (the S-DATA service)
defined by X.225. The outgoing data is packed
into DT SPDUs, and incoming data is
unpacked from DT SPDUs. The
implementation uses methods provided by the
transport layer according to Figure 10-18.

Figure 10-18 – Session Layer - DataTransfer

Finish
The Finish method should be used to terminate
the connection. This method uses the same
framing as the S-RELEASE service defined by
X.255. A FINISH SPDU is sent, and a
DISCONNECT SPDU should be received
[ITU88]. The implementation uses methods
provided by the transport layer according to
Figure 10-19.

Figure 10-19 – Session Layer - Finish

50
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

Presentation Layer
The presentation layer ISO 8823 has two responsibilities, negotiation of transfer syntaxes and
transformation to and from transfer syntax. [Jav07c] IEC 61850-8-1 specifies that the BER
transfer syntax should be used, and only BER is supported by the implementation. The
implementation of the presentation layer encodes/decodes messages and adds the
corresponding framing for MMS and ACSE (Association Control Service Element)
application layers.

SetIP
The SetIP method is used to specify the IP
number of a specific server. This method is
used instead of transferring the IP-number
as a parameter in the Connect method.

Figure 10-20 – Presentation Layer - SetIP

Connect
The Connect method should be used to
establish an association. It uses the same
framing as the P-CONNECT service
defined by ISO 8822/8823-1. The
implementation uses methods provided by
the session layer according to Figure
10-21.

Figure 10-21 – Presentation Layer - Connect

DataRequestResponse
The DataRequestResponse method should
be used to transfer user data. It uses the
same framing as the P-DATA service
defined by ISO 8822/8823-1. A request is
sent and a response should be received by
using the DataTransfer method provided by
the session layer according to Figure 10-22.
The BER transfer syntax is used.
Figure 10-22 – Presentation Layer -
DataRequestResponse

51
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

Release
The Release method should be used by the
application layer to release an association.
It uses the same framing as the P-
RELEASE service defined by ISO
8822/8823-1. The implementation uses the
Finish method provided by the session
layer as shown by Figure 10-23. The P-
RELEASE service is used by the ACSE A-
RELEASE service.
Figure 10-23 – Presentation Layer - Release

Application Layer
The application layer, implemented by the IEC61850ClientFileServices class, is a mixture of
several protocols, it implements MMS (ISO 9506) services, ACSE functionality, and provides
its user with only a few methods which are simple to use. This class does also implement the
mappings between abstract services defined by IEC 61850-7-2 and MMS as defined by IEC
61850-8-1. The ACSE protocol is defined by ISO 8650 and provides functionality for
establishing and releasing application associations [Jav07d]. MMS uses TCP/IP port 102
[Kir07], which has been “hard coded” in the transport layer.

SetIP
The SetIP method should be use to
specify the IP-number of the server
(physical equipment) with which the
application should communicate. This
method is used instead of transferring
the IP-number as a parameter in the
Initiate method. The implementation
uses the SetIP method provided by the
presentation layer as shown by Figure
10-24.
Figure 10-24 – Application Layer - SetIP

Initiate
The Initiate method should be used to
initiate an association with a MMS
server. It implements the MMS Initiate
service (10.3.2), and adds also the
framing used by the ACSE A-
ASSOCIATE service. The Initiate
method uses functionality provided by
the presentation layer as shown by
Figure 10-25.

Figure 10-25 – Application Layer - Initiate

52
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

GetFile
The GetFile method should be used to
get the contents of a specific file. The
method takes the FileName as a
parameter, and returns the contents of
the file.

The MMS FileOpen service (10.3.6) is

used to open the file in the server file
store, the MMS FileRead service
(10.3.7) is used to get the contents of the
file, and the FileClose service (10.3.8) is
used to close the file. At last the contents
of the specific file are retuned. The
implementation uses methods provided
by the presentation layer as shown by
Figure 10-26.

Figure 10-26 – Application Layer - GetFile

GetDirectory
The GetDirectory method should be
used to get a list with names of available
files. Attributes like file-size and last
modified time are also returned.

The MMS FileDirectory service (10.3.9)

is implemented by this method and the
implementation uses functionality
provided by the presentation layer as
shown by Figure 10-27.
Figure 10-27 – Application Layer - GetDirectory

Conclude
The Conclude method should be use to
terminate an association with a server.
This method implements the MMS
Conclude service (10.3.3). A MMS
Conclude request is sent, and a response
should be received. After the response
has been received, then the ACSE A-
RELEASE service is used for final
termination of the connection. The
implementation uses services provided
by the presentation layer as shown by
Figure 10-28.

Figure 10-28 – Application Layer - Conclude

53
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

Abort
The MMS abort service has, as earlier stated, not been implemented. The communication
between STINA IEC 61850 prototype and IEC 61850 compliant devices can instead be
aborted by disconnecting the transport connection directly.

The reason why it wasn’t implemented

• The Abort service is not needed to be able to download files or filenames.

• When something goes wrong in the communication, an exception is thrown from the
layer were the error appeared. The exception is handled by disconnecting the transport
connection. (The Implicit release variant specified by RFC 905 is used)

• The implicit release variant specifies that the lifetime of a transport connection relates
to the lifetime of the network connection. When the socket connection is being closed,
then the transport layer on the other side will be notified. [6]

• Closing the transport connection works like a hard, but very simple Abort service.
This method is possible since the implemented transport layer will only be used by
one application, the STINA IEC61850 prototype.

54
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

10.7 STINA IEC 61850 communication prototype

The developed STINA IEC 61850 communication prototype will be presented in this part of
the thesis report. The prototype should however not be considered as a general solution, but
instead as an example of how IEC 61850 can be used for remote disturbance analysis. The
ABB REL670 line protection relay provided only compressed COMTRADE files (zip-files).
The prototype was designed to be as simple as possible and provides consequently only
support for downloading of compressed COMTRADE files. The communication stack can
however be used to download any kind of file, and only a small modification will be needed
to make the prototype to work with uncompressed COMTRADE files.

The new STINA IEC 61850 communication prototype is like all earlier STINA
communication solutions divided into two parts: a communication (COMM) adapter and a
data process (PROC) adapter.

10.7.1 STINA IEC 61850 - Communication adapter

All STINA communication adapters

should implement a COM interface called
UnitInterface. Figure 10.29 shows the
design of the communication adapter.

The base class called CCommBase is

used by almost all STINA
communication adapters and provides a
lot of useful functionality, e.g. methods
for internal communication in STINA,
reading of database parameters etc.

The STINA IEC 61850 communication

adapter uses the implemented
communication stack to download
compressed COMTRADE files.

IUnitInterface specification
IUnitInterface contains the following
methods:
• Init
• GetData
• CleanUp
• SetUnitLocalTime
• GetUnitLocalTime
Figure 10-29 – STINA IEC 61850
communication adapter design

55
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

Init
The purpose of the Init method is to initiate the
communication adapter with useful information. Figure
10-30 shows the basic functionality of this method.

The following database parameters are read from

STINA’s database by using the GetParam function
provided by the CCommBase base class:

IPNR: The adapter is initiated with an IP-number to an

IEC 61850 compliant physical device.

FILEFILTER: The adapter is initiated with a file

filter, which makes it possible to select the format of
the wanted COMTRADE files. IEC 61850-8-1
specifies that the COMTRADE files should be located
in a specific directory called “COMTRADE”, this part
of IEC 61850-8-1 was apparently not followed by
ABB, since the COMTRADE files were located in the
default directory which was “/flash/drec/”. The
FileFilter database parameter makes it possible to
specify the format of the compressed COMTRADE
files, so that only compressed COMTRADE files will
Figure 10-30 – Communication adapter- be downloaded and no other zip-files. This method was
Init used since ABB didn’t follow the standard exactly.

NROFDAYS: This parameter makes it possible to filter out too old disturbance information.

56
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

GetData
The GetData method described by Figure 10-31 is used by CommSrv to download
compressed COMTRADE files from IEC 61850 compliant relays according to IEC 61850-8-
1. The IP-number is set to the number retrieved from the IPNR database parameter.

Figure 10-31 – Communication adapter - GetData

Get Disturbances
The CIEC61850DEVICE class (see Figure 10-31) uses the Initiate service provided by the
communication stack to initiate an association with a specific Server. When an association has
been established, then the GetDirectory service (see Figure 10-31) is used to retrieve a list of
available files, file attributes like size and last modified time is also retrieved.

Only files according to the parameter FileFilter will later be downloaded. If the FileFilter
parameter is empty, then this filter is inactivated, and all available zip-files are valid.

The NROFDAYS database parameter is used filter out too old files. This formula is used to
calculate if a file can be downloaded or not:

LastModifiedDate > Current Time – NROFDAYS

If the two first criteria are fulfilled, then the file is downloaded by the STINA IEC 61850
communication adapter if the current file has not been downloaded by STINA before. To be
able to know if a file has been downloaded before so is a string named “chunk” generated by
the adapter. The chunk is a concatenation of the filename and the last modified time of the
file. The adapter looks up the chunk in the database to see if the current file has been
downloaded (the chunk is inserted by the process adapter). If the chunk is not found, then the
file can be downloaded by the adapter. This check is made to avoid downloading unnecessary
information, and is used by almost all STINA communication adapters. When all files that
fulfilled the different requirements have been downloaded, then the connection to the Server
is disconnected.

57
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

Save Disturbances
For every downloaded disturbance file, the STINA IEC 61850 communication adapter
generates two temporary files in a folder specified by STINA (as parameter in the GetData
method)

The files have the same names, only the type differs.

• “NewFilename.dat” contains the original filename, the fetch time, and the last
modified date of the downloaded file. This information is needed when we should
generate the chunk.

• “NewFilename.zip” contains the downloaded information (a set of compressed

COMTRADE files, at least a *.dat and a *.cfg file)

The filename is generated by using the current date and time, to make sure that the new
filename will be unique in the folder used by STINA. All names of the *.dat files are added to
a list, which is later returned to the user (CommSrv) of the adapter via a pointer in the
GetData method interface.

CleanUp
The CleanUp method shown by Figure 10-32 is
used by CommSrv to clean up resources allocated
by the COMM adapter.

Figure 10-32 – Communication adapter -

CleanUp

SetUnitLocalTime and GetUnitLocalTime

These two methods are not supported by the STINA IEC 61850 communication prototype,
and the implementation of them does not perform anything useful.

58
 Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

10.7.2 STINA IEC 61850 - Process adapter

The process (PROC) adapter processes and normalizes the data downloaded by the
communication adapter. All STINA Proc adapters implement the COM interface called
ProcInterface. The base class CProcBase which is used by most STINA process adapters
makes implementation a lot easier. This base class provides for example functionality for
Database access, inserting chunks, inserting disturbance information (e.g. COMTRADEs) etc.
Figure 10-33 shows the design of the STINA IEC61850 process adapter.

IProcnterface Specification
• Init
• ProcessData
• CleanUp

Figure 10-33 – STINA IEC 61850 process adapter design

Init
The Init method, described by Figure 10-34, should be used by the ProvSrv to initiate the
adapter. A parameter called EXTRACT is read from the database.

Figure 10-34 – Process adapter - Init

59
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

ProcessData
The STINA IEC 61850 communication adapter generates a file list with the names of the
generated *.dat files. This file list is sent to the Proc adapter via a parameter in the
ProcessData function. The process adapter knows that for every *.dat file there is also a *.zip
file with the same name. Every *.dat file is processed by using the same method. Figure 10-35
shows the functionality of the ProcessData method.

Process data file

The PROC adapter generates a string, normally called chunk, by using the information
provided by the *.dat file. The chunk is generated by concatenating the last modified time
with the original filename. (In the same way as in the COMM adapter)

The processDataFile method decompresses the zip file to a unique folder. (Folder name is
generated by the name of the .dat file) During the decompressing the zip-file, the Unzip file
method searches after a CFG file. A COMTRADE consists of at least a CFG file, and a DAT
file, and some times could also a HDR and an INF file be included. All files should have the
same names, only the file types should differ.

The unpacked COMTRADE file is processed by

the processComtradeFile method. The
processComtradeFile method takes two
parameters, the name of the CFG file, and the
generated chunk. It first checks first that the
current file hasn’t been added to the database
before. If the current file has been processed, then
it continues with the next *.dat file. This check is
performed by using the generated chunk. If it
hasn’t been processed, then the COMTRADE file
is processed and added to STINA by using the
AddSS (SS = StörningsSkrivare) method provided
by CProcBase. Only the name of the
COMTRADE CFG file is added to the database,
the real files are copied to a folder specified by
STINA. If the EXTRACT parameter of type
Boolean read from the database was true, then
events are extracted from the COMTRADE file.
An event occurs when a digital channel is
changing its state, going from zero to one, or from
one to zero. Events are inserted by using the
AddHS method (HS = Händelse Skrivare)
provided by CProcBase. After the current
COMTRADE has been processed and added to the
database correctly, then the chunk is added to the
database. All these steps is done for every *.dat
file until every file has been processed.
Figure 10-35 – Process adapter - ProcessData

60
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07
CleanUp
The CleanUp method described by Figure 10-36 should be used to release allocated resources.

Figure 10-36 – Process adapter - CleanUp

61
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

11 Testing of the prototype’s functionality

This thesis has resulted in a prototype for communication between the disturbance analysis
and disturbance collecting system named STINA and IEC 61850 compliant devices. The
prototype implements functionality needed for downloading of COMTRADE files to STINA
directly from IEC 61850 compliant devices and makes them accessible to the rest of the
system. The prototype, which has only been tested with an ABB REL670 line protection
relay, shall be used to download zipped COMTRADE files. Only a small modification should
be needed to make it work with regular COMTRADE files.

The functionality of the prototype was verified in the end of the project by installing the
developed software into a STINA system at Powel’s office in Östersund. The STINA
administrator tool was used to configure STINA for communication with the borrowed ABB
REL670 relay. Downloading of information from the device was initialized by using the
functionality for manual downloading of data provided by the STINA Navigator. Several
COMTRADE files were in this way downloaded from the ABB REL670 relay. Figure 11-1
shows the STINA Navigator and the selected row corresponds to one of the downloaded
COMTRADE files.

Figure 11-1 – STINA Navigator showing downloaded disturbance information

The COMTRADE can be opened in the STINA COMTRADE Viewer by double clicking it in
the STINA Navigator.

Figure 11-2 – Selection of COMTRADE in STINA Navigator

The HS fields, e.g. TRIP ON (see Figure 11-2), show events which have been extracted from
the COMTRADE (see 10.7.2). The time shown in the selected row (Figure 11-2) corresponds
to the time when the disturbance was recorded. Figure 11-3 shows how the selected
disturbance recording looks like in the STINA COMTRADE-Viewer. The COMTRADE file
shows a recording of sample values, from both analog and digital channels, around the time of
a disturbance.

62
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

The information provided by COMTRADE files are useful in analyzing of disturbances on

power networks and the prototype thereby fulfills the minimum requirement which was to
provide STINA with information from IEC 61850 compliant devices useable for disturbance
analysis

Figure 11-3 – Investigation of a COMTRADE in STINA COMTRADE-Viewer

63
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

12 Conclusion
The new global standard IEC 61850 standard for substation automation is probably here to
stay, since it covers all aspects of substation automation and is future-proof. But one of the
problems with all standards is that they also must be supported by the manufacturers, in this
thesis was it found out that one part of IEC 61850-8-1 regarding COMTRADE files wasn’t
followed by ABB, the COMTRADE files were not located in a standardized directory. This
became no problem, however, since the COMTRADE files were located in the default
directory (”/flash/drec/”). But it can be a problem if several vendors start to put their
COMTRADE files in un-standardized directories, since it will make it more difficult to find
the correct files.

The developed STINA IEC 61850 communication prototype downloads compressed

COMTRADE files from IEC 61850 compliant devices. A lot of protocol specification had to
be read in order to develop the prototype, and several standards had to be bought. This
became however much cheaper than to buy an implementation of an IEC 61850
communication stack. But it is also understandable that the available IEC 61850 solutions is
expensive, since a lot of work is needed to implement the IEC 61850 standard. Only a small
part of it was implemented in this thesis, but it was still hard enough. It became also a bit hard
to describe the work in an understandable way, since it spanned over several subjects, e.g.
disturbance analysis, substation automation, MMS, and integration to STINA.

The developed solution is only a prototype, and a more extensive STINA IEC 61850
communication solution can probably be developed. Only COMTRADE files are handled by
the current solution, additional functionality for reading information contained in logical
nodes could also be useful.

The solution must however be seen as successful since it is able to provide STINA with
information suitable for disturbance analysis. STINA can now be used for both downloading
of disturbance information from devices based on older communication protocols (e.g.
Modbus and IEC 60870-5-103), and for downloading of disturbance information from newer
devices supporting IEC 61850, which makes the tool even better than before. The prototype is
however not a complete product, and small modifications will be needed to make it work with
uncompressed COMTRADE files. The modification will mainly consist of removing the
decompressing of files in the PROC adapter.

64
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

13 Glossary
ACSE: Association Control Service Element
ACSI: Abstract Communication Service Interface
Adapter: Microsoft COM object encapsulated in a DLL.
APDU: Application Protocol Data Unit
ASDU: Application Service Data Unit
ASN.1: Abstract Syntax Notation One (ISO 8824-1, X.680)
BER: Basic Encoding Rules (ISO 8825-1, X.690)
COM: Component Object Model
COMM adapter: Adapter used by STINA CommSrv in order to communicate with
specific remote equipment.
CommSrv: Part of STINA communication server used for downloading of
data.
COMTRADE: Common Format for Transient Data Exchange
DCOM: Distributed Component Object Model
DLL: Dynamic link library
IEC: The International Electro technical Commission
IED: Intelligent electronic device
IP: Internet Protocol
ISO: International Organization for Standardization
ITU: International Telecommunication Union
ITU-T: International Telecommunication Union – Telecom
standardization
KernelSrv: Part of STINA communication server that acts like the engine of
STINA.
LAN: Local Are Network
LD: Logical Device
LN: Logical Node
MMS: Manufacturing Message Specification
OSI Model: The Open Systems Interconnection Reference Model
PPDU: Presentation Protocol Data Unit
PROC adapter: Adapter used by STINA ProcSrv in order to process downloaded
data from specific remote equipment.
ProcSrv: Part of STINA communication server used for processing of
downloaded data.
RFC: Request for comments
RTU: Remote Terminal Unit
SCL: Substation configuration Language
SCSM: Specific communication service mapping
SPDU: Session Protocol Data Unit
STINA: Disturbance analysis system developed by Powel Energy
Management AB
TCP: Transport Control Protocol
TPDU: Transport Protocol Data Unit
TPKT: Transport PacKeT
X.225: ITU-T Recommendation X.225, OSI session layer protocol (ISO
8327)

65
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07
X.680: ITU-T Recommendation X.680, International Standard 8824-1
(ASN.1)
X.690: ITU-T Recommendation X.690, International Standard 8825-1
(BER)
XML: Extensible Mark-up Language

66
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

14 References
Modbus
[Jam06] Jamod, Understanding the Modbus protocol,
http://jamod.sourceforge.net/kbase/protocol.html, 2006-10-02

[Wik07] Wikipedia, Modbus, http://en.wikipedia.org/wiki/Modbus, 2007-02-28

[Pla06] Plant Automation, Modbus/TCP

http://www.plantautomation.com/content/news/article.asp?DocID=%7B2D631F2E-0C1D-
11D5-A770-00D0B7694F32%7D&VNETCOOKIE=NO, 2006-10-12

IEC 60870-5-103
[Ipc06] IPComm, Protocols, IEC 60870-5-103,
http://www.ipcomm.de/protocol/IEC103/en/sheet.html, 2006-11-01

MMS
[Sis95] SISCO, Overview and Introduction to the Manufacturing Message Specification
(MMS), Sisco Inc 1995. http://www.sisconet.com/downloads/mmsovrlg.pdf

[Kir07] Prof. Dr. H. Kirrmann, http://lamspeople.epfl.ch/kirrmann/Slides/AI_420_MMS.ppt,

2007-02-23

COMTRADE
[CMT07a] Standards for wide area measurement systems,
http://www3.imperial.ac.uk/portal/pls/portallive/docs/1/4859918.PDF, 2007-02-15

[CMT07b] COMTRADE: a new standard for common data format for transient data
exchange,
www.ece.msstate.edu/~schulz/classes/ece8613/jian.ppt, 2007-02-15

ASN.1
[Obj07] Objective systems, Listing of universal tags.
http://www.obj-sys.com/asn1tutorial/node124.html, 2007-01-05

[Der07] Luca Deri, A Layman's Guide to a Subset of ASN.1, BER, and DER.
http://luca.ntop.org/Teaching/Appunti/asn1.html, 2007-02-01

[Oss07a] OSS Nokalva, ASN.1 codig rules. http://www.oss.com/asn1/rules.html, 2007-02-01

[Oss07b] OSS Nokalva, http://www.oss.com/news/sitenews.html

Session Layer
[Jav07b] Javvin network management and security, session layer,
http://www.javvin.com/protocolISOsession.html, 2007-02-20

67
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07
Presentation Layer
[Jav07c] Javvin network management and security, presentation layer,
http://www.javvin.com/protocolISOpresentation.html, 2007-02-20

Application Layer - ACSE

[Jav07d] Javvin network management and security, ACSE,
http://www.javvin.com/protocolISOACSE.html, 2007-02-20

OSI-model
[Pcs07] PC Support Advisor, OSI 7 Layer Model Tutorial,
http://www.pcsupportadvisor.com/OSI_7_layer_model_page1.htm
2007-02-20

[Rad07] RAD University, The Seven Layer model,

http://www.raduniversity.com/networks/1994/osi/layers.htm
2007-02-20

STINA
[Pow06] Powel, STINA Product brochure, 2006

IEC 61850
[Mac06] Ralph Mackiewicz , Member IEEE. Overview of IEC 61850 and Benefits, 2006

[Sch03 ] H. Schuhert G. Wong. IEC 61850 -THE FUTURE GLOBAL STANDARD FOR
SEAMLESS AND VENDOR-INDEPENDENT
COMMUNICATION WITHIN SUBSTATIONS, 2003

[Hog04] C. Hoga and G.Wong. IEC 61850: Open Communication in Practice in Substations,
2004

[Sch02] Karlheinz Schwarz, Comparison of IEC 60870-5-101/-103/-104, DNP3, and IEC

60870-6-TASE.2 with IEC 61850, SCC 2002

Standards
[1] International standard IEC 60870-5-103 – Transmission protocols – Companion standard
for the informative interface of protection equipment, 1997

[2] International Standard IEC 61850-7-1, Communication networks and systems in

substations – Basic communication structure for substation and feeder equipment – Principles
and models, 2003-07

[3] International Standard IEC 61850-7-2, Communication networks and systems in

substations – Basic communication structure for substation and feeder equipment – Abstract
Communication Service Interface (ACSI), 2003-05

[4] International Standard IEC 61850-8-1, Communication networks and systems in

substations – Specific Communication Service Mapping (SCSM) – Mappings to MMS (ISO
9506-1 and ISO 9506-2) and to ISO/IEC 8802-3, 2004-05

68
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07
[5] International Standard ISO 9506-2, Industrial automation systems – Manufacturing
Message Specification – Protocol specification, second edition 2003-07-01

[6] Reguest for Comments, RFC905, ISO Transport Protocol Specification ISO DP 8073,
1984-04

[7] Request for Comments, RFC1006, ISO Transport Service on top of the TCP version: 3,
1987-05

International Telecommunication Union recommendations

[ITU88] ITU-T Recommendation X.225, OSI session layer protocol (ISO 8327), 1988

ABB REL670
[Abb05] ABB, Innovation from ABB, Line distance protection IED REL, 2005

[Abb06a] ABB, Innovation from ABB, Protection and Control for Transmission Networks
IED 670 Selection Guide, 2006

[Abb06b] ABB, Line distance protection IED, REL 670, buyer’s guide, April 2006

69
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

15 Appendix A - ASN.1 and BER

Abstract Syntax Notation One (ASN.1) is a formal language used for specifying objects and
data types on an abstract level, independent from programming languages and computer
platforms. The notation is flexible and a variety of data types can be described by using it.

Several different standardized encoding rules, e.g. BER, DER or XER, can be used to encode
the data types defined by ASN.1 notation into a concrete data representation (transfer syntax)
BER, which was used in this thesis, describes how the ASN.1 types should be encoded as a
sequence of octets. All ASN.1 types, except the CHOICE and ANY type, have tags used for
identification. A tag consists of a tag class and a non-negative number as described by section
15.2.

15.1 Types
ASN.1 defines a type as a set of values. Some types have a finite number of values, and others
have an infinite number. The ASN.1 assignment operator (::=) can be used to name types. The
names can later be used to build up other types. There are four different kinds of ASN.1
types: [Der07]

15.1.1 Simple type

A simple type has no components, and works like a building block for other types. An Integer
is a good example of a simple type. Simple types can be divided into string types and non-
string types. [Der07]

15.1.2 Structured type

Structured types are types which consist of components. The components can be optional, and
they can also have default values. There are four different kinds of structured types in ASN.1:
[Der07]

SEQUENCE
A SEQUENCE is an ordered collection of variables of different types.

SEQUENCE OF
A SEQUENCE OF is an ordered collection of variables of a specific type.

SET
A SET is an unordered collection of variables of different types.

SET OF
A SET OF is an unordered collection of zero or more objects of a specific type.

70
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

15.1.3 Tagged type

A tagged typed is derived from other types. Tagging can be used to distinguish types within
an application, or components type within a structured type. ASN.1 uses two types of tagging,
EXPLICIT and IMPLICIT tagging. [Der07]

Example:
This example will explain why tagging is used by ASN.1.

The ASN.1 syntax below is ambiguous.

Invalid ::= SEQUENCE{

number1 Integer32 OPTIONAL,
number2 Integer32 OPTIONAL}

The type named Invalid has two optional components of type Integer32 with
no extra tagging. We can get the following types by removing the OPTIONAL
parts from it in different ways.

SEQUENCE{
number1 Integer32}

SEQUENCE{
number2 Integer32}

Those types will be abstractly the same types, both is a SEQUENCE that
consists of one component of type Integer32, it will thereby be impossible to
know if the OPTIONAL part number1 is missing, or if number2 is missing. If
we encode this type with one of the OPTIONAL parts removed, the receiver
will not be able to decode it correctly since he cannot know if he gets number1
or number2. It is always the tag that matters, not the names of the variables. This
problem can be solved by redefining the type:

Valid ::= SEQUENCE{

number1 [0] Integer32 OPTIONAL,
number2 [1] Integer32 OPTIONAL}

If only the OPTIONAL part number2 is removed we get the following type:

SEQUENCE{
number1 [0] Integer32 }

If number1 is removed we get this type:

SEQUENCE{
Number2 [1] Integer32 }

It will now possible to see that number2 is missing from the first type, and
number1 from the second, since the numbers have an extra tag which differs.

71
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07
Implicit tagging
The keyword IMPLICIT is used to specify that a type is implicitly tagged. Implicitly tagged
types are derived by changing the tag of the underlying type, and they are considered to be the
same as the underlying type. [Der07]

Syntax: [class number] IMPLICIT

Explicit tagging
The keyword EXPLICIT is used to specify that a type shall be explicitly tagged. Explicitly
tagged types are derived by adding an extra tag to the underlying type. If none of the
keywords IMPLICIT or EXPLICIT is present, then the default tagging type is used. The
default type is usually EXPLICIT tagging. An explicitly tagged type can be seen as a
structured type with the underlying type as a component. [Der07]

Syntax: [class number] EXPLICIT or [Number]

15.1.4 Other types

Other types correspond to types that do not fit in any of the other categories. The CHOICE-
and the ANY-type are included in this category. The CHOICE type corresponds to a union of
one or several alternatives. [Der07]

72
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

15.2 Tag classes

All ASN.1 types, except the ANY and the CHOICE type, have tags. A tag consists of two
parts, a class and a tag number. There are four different classes. [Der07]

15.2.1 Universal
Universal tags are used by types whose meaning is always the same. Table 15-1 shows an
overview of universal types.

Universal Tag Number Description

0 reserved for BER
1 BOOLEAN
2 INTEGER
3 BIT STRING
4 OCTET STRING
5 NULL
6 OBJECT IDENTIFIER
7 ObjectDescriptor
8 INSTANCE OF, EXTERNAL
9 REAL
10 ENUMERATED
11 EMBEDDED PDV
12 UTF8String
13 RELATIVE-OID
16 SEQUENCE, SEQUENCE OF
17 SET, SET OF
18 NumericString
19 PrintableString
20 TeletexString, T61String
21 VideotexString
22 IA5String
23 UTCTime
24 GeneralizedTime
25 GraphicString
26 VisibleString, ISO646String
27 GeneralString
28 UniversalString
29 CHARACTER STRING
30 BMPString
Table 15-1 – Universal types [Obj07]

15.2.2 Application
Tags of type Application is used by application specific types. [Der07] Implicit or explicit
tagging can be used.

Syntax: [APPLICATION 2] denotes a tag of class APPLICATION with the tag

number equals to two.

73
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07
15.2.3 Private
Tags of type Private is used by types whose meaning is specific to a given enterprise. [Der07]
Implicit or explicit tagging can be used.

Syntax: [PRIVATE 2] denotes a tag of class PRIVATE with the tag number equal to
two.

15.2.4 Context-specific
Tags of type Context-specific are used by types whose meaning is specific to a given
structured type. [Der07] Either implicit or explicit tagging can be used.

Syntax: [2] denotes a Context-specific tag with the tag number equals to two.

15.3 ASN.1 Type Example

ASN.1 notation can as earlier be said to describe complex types, the ASN.1 notation below
defines the type “Example” which is a SEQUENCE of other objects of different types.

Example

Example ::= SEQUENCE{

object1 [0] IMPLICIT Type1 OPTIONAL,
object2 [1] IMPLICIT Type1 OPTIONAL,
object3 Type2}

Type1 ::= SEQUENCE{

boolean1 [0] IMPLICIT BOOLEAN DEFAULT TRUE,
boolean2 [1] IMPLICIT BOOLEAN DEFAULT FALSE,
integer INTEGER}

Type2 ::= CHOICE{

number1 INTEGER,
number2 BOOLEAN}

The syntax above defines the type “Example” as a sequence of two optional objects of type
Type1 and one object of Type2. The Type1 type is defined as a sequence of two Booleans and
one Integer, boolean1 has the default value true, and boolean2 has the default value false
Type2 is defined as a choice between an INTEGER and a BOOLEAN. The Example type
does not represent anything useful; its purpose is only to give an example of how types can be
defined.

74
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

15.4 Basic Encoding Rules

The Basic encoding rules define three methods for encoding of an ASN.1 values [Der07]:

Primitive, definite-length encoding

This method is used by simple non-string types.

Constructed, definite- length encoding
This method is used by structured types when the length of the value is known.

Constructed, indefinite-length encoding
This method is used by constructed types when the length is unknown.

Implicitly tagged types use the method for the underlying type, and explicitly tagged types
uses one of the methods used for encoding constructed types. A BER encoded ASN.1 type
consists of three or four parts. The fourth part is only present if the indefinite-length encoding
method is used [Der07].

Identifier octets
The Identifier octets correspond to the encoding of the tag used by the ASN.1 type.

Length octets
The length octets give defines the length of the contents octets, or indicates that the length is
indefinite.

Contents octets
If the type is primitive, then the contents octets give a concrete representation of a specific
value. If the encoded type is constructed, then the contents octets contain the BER encodings
of the components.

End-of-contents octets
The End-of-contents octets are only used by the constructed, indefinite-length encoding
method, and they shall consist of two octets with the value 0x0000. [Der07]

75
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

15.5 Primitive, definite-length method

The primitive, definite-length encoding method is used by simple types and implicitly tagged
types derived from simple types. [Der07]

15.5.1 Identifier octets

The identifier octets are used for identification of types. BER uses two forms for the identifier
octets. One method is used for tag numbers between 0 and 30, and another method is used for
larger tag numbers (>=31). [Der07]

CLASS BIT 8 BIT 7

UNIVERSAL 0 0
APPLICATION 0 1
CONTEXT-SPECIFIC 1 0
PRIVATE 1 1
Table 15-2 – BER encoding of tag classes [Der07]

Tag numbers (0 <= NR <= 30)

Tag numbers between 0 and 30 are encoded by one identifier octet. Bit 8 and 7 should be used
to specify the class of the tag according to Table 15-2. Bit 6 should be set to zero to indicate
that the type is primitive. Bit 5 -1 shall give the tag number.

Tag numbers (NR >= 31)

Tag numbers in this range should be encoded by two or more identifier octets. The first
identifier octet is encoded in the same way as tags between 0 and 30, except that Bits 5 – 1
should be set to 0b11111 to indicate that a tag number above 30 is encoded. The remaining
octets give the tag number. Bit 7-1 of each remaining octet represents a part of the value (base
128 and most significant bit first), and bit 8 indicates if the current identifier octet is the last
one or not. Bit 8 = 1 indicates that the current octet is the last one of the identifier field. The
tag number should be encoded by as few bits as possible. [Der07]

15.5.2 Length octets

BER uses two different forms for describing definite lengths. One method is used for lengths
between 0 and 127, and another method is used for lengths between 0 and 2^1008 -1. [Der07]

Lengths between 0 and 127

This method encodes the length to one octet:

Bit 8 = 0

Bits 7–1 give the length of the contents octets.

Lengths between 0 and 2^1008 -1

This method encodes the length as two to 127 octets.

First length octet

Bit 8 = 1

Bits 7-1 specify the number of additional length octets.
Remaining octets

The remaining octets give the number of octets in the contents field, most
significant digit first.

76
Using IEC 61850 for remote disturbance analysis Roland Hamrén
Powel Energy Management AB March 07

15.5.3 Contents octets

The contents octets give a concrete representation of the value of the primitive type. [Der07]

15.6 Constructed, definite-length method

This method is used by:

Simple string types

Types derived from simple string types

Structured types

Implicitly tagged structured types

Explicitly tagged types

Identifier octets
The tag is encoded as described by the primitive, definite-length encoding method, except that
Bit 6 of the first identifier octet is set to one to indicate that the encoding is constructed.
[Der07]

Length octets
The same method as used by the primitive types.

Contents octets
The contents octets shall contain BER encodings of the components of the structured type.
[Der07]

15.7 Constructed, indefinite-length method

This method is used for encode constructed ASN.1 types when we do not know the length of
the type in advance. The method is almost the same as the method used for definite-length
encoding of constructed types, only two parts is different. [Der07]

Length octets
The length octets shall consist of one octet containing the following value: 0x80
This indicates that indefinite-length encoding is used. [Der07]

End-of-contents octets
End-of-contents octets (0x00 00) shall mark were the encoding stops. [Der07]

77