Design and Implementation

of an IEC 61850 gateway for

PLC Systems
Jonas Lidn
Master Thesis
Stockholm, Sweden 2006
XR-EE-ICS 2006:021
Abstract

This master thesis presents the result of an investigation and testing of IEC 61850
introduction into Vattenfall Vattenkraft ABs technical systems for turbine controllers. The
work started with an investigation of todays automation products with focus on station bus
communication. Today Vattenfall Vattenkraft AB are modernising their automation products
in many of their hydro power plants, and the turbine controllers are developed by SwedPower
AB on standard PLCs from Siemens Automation and Drives. Therefore the product focus has
been PLC systems from Siemens for compatibility with the modern turbine controller used
today. The initial investigation provided a few alternatives for how to implement and test an
IEC 61850 interface for turbine controllers, one of these alternatives were selected for
implementation and tested regarding communication on the station bus and for a few data
values. The report describes the implementation and the results of the testing.

Today there are no PLCs capable of communicating in accordance to IEC 61850, the
interface implemented and tested during this master thesis work provides an interface based
on an industrial PC gateway for PLCs to communicate using the IEC 61850 standard.

Keywords
IEC 61850, PLC, Simatic S7, AX-S4 MMS, Gateway.

Preface
This technical report is the result of my master thesis work that has been conducted on
Vattenfall Utveckling AB. The supervisors for this work are Mr. Anders Johnsson from
Vattenfall Utveckling AB and Mr. Lars Nordstrm from the department of Industrial
Information and Control Systems at the Royal Institute of Technology. Mr Per-Anders
Nordlander from Vattenfall Vattenkraft AB and Mr Henrik Wiechel from SwedPower AB
have given many valuable opinions and implementation help regarding the functions and
testing of the IEC 61850 interface.
This report is in first hand written for people with knowledge of the electric power industry
already familiar with the many terms used in substations and hydro power plants. Readers not
introduced to the standard of IEC 61850 are recommended to read Appendix 1 - IEC 61850
after the initial chapter of IEC 61850 found in chapter 3.1.

I hope that all readers find it valuable and interesting.

Stockholm, 06-03-28

Jonas Lidn
jonlinde@kth.se

4
Abstract ..................................................................................................................................... 2
Preface ....................................................................................................................................... 3
1 Introduction...................................................................................................................... 7
1.1 Purpose....................................................................................................................... 7
1.2 Background ................................................................................................................ 7
1.3 Outline of the report ................................................................................................... 8
2 Research Method............................................................................................................ 10
2.1 Goals......................................................................................................................... 10
2.2 Scope of the study .................................................................................................... 10
2.3 Problem description.................................................................................................. 10
2.4 Research Problem..................................................................................................... 11
2.5 Implementation guidelines ....................................................................................... 11
2.6 Investigation path ..................................................................................................... 12
2.7 Literature .................................................................................................................. 12
3 Communication solutions .............................................................................................. 14
3.1 IEC 61850 Overview................................................................................................ 14
3.2 OPC.......................................................................................................................... 17
3.3 MMS......................................................................................................................... 18
4 Product information....................................................................................................... 20
4.1 Siemens S7 PLC....................................................................................................... 20
4.2 ABB AC 800M PLC................................................................................................ 23
4.3 Siemens Simatic Microbox 420 ............................................................................... 24
4.4 Tamarack software stack for embedded systems ..................................................... 25
4.5 MMS-EASE Lite...................................................................................................... 25
4.6 AX-S4 MMS ............................................................................................................ 26
4.7 SOFTNET for PROFIBUS....................................................................................... 27
5 Design alternatives ......................................................................................................... 28
5.1 Implementation on ABB PLC system:..................................................................... 29
5.2 Implementation on Siemens PLC system: ............................................................... 30
5.3 PC Gateway design .................................................................................................. 30
5.4 Rejected alternatives ................................................................................................ 31
6 Design proposal .............................................................................................................. 33
6.1 Overview.................................................................................................................. 33
6.2 Hardware: ................................................................................................................. 33
6.3 Software ................................................................................................................... 34
6.4 Design specifications................................................................................................ 34
7 Testing the interface....................................................................................................... 37
8 Results ............................................................................................................................. 40
9 Future work .................................................................................................................... 41
9.1 Implemented interface.............................................................................................. 41
9.2 Future products......................................................................................................... 42
10 References to external experts .................................................................................. 44
11 References for articles and manuals......................................................................... 45
Appendix 1 - IEC 61850........................................................................................................... 1
The ACSI-model .................................................................................................................... 4
Data modelling ....................................................................................................................... 7
Communication services ...................................................................................................... 17
Client/Server communication............................................................................................... 21
Reporting.............................................................................................................................. 25
Logging ................................................................................................................................ 28


5
Control class model .............................................................................................................. 30
Comparison of the data access methods............................................................................... 30
Communication mappings.................................................................................................... 31
Appendix 2 - Definitions. ......................................................................................................... 1
Logical Nodes ........................................................................................................................ 1
Data Objects ........................................................................................................................... 2


6
Glossary

ACSI: Abstract Communication Service Interface
GOOSE: Generic Object Oriented Substation Event
GSE: Generic Substation Event
GSSE: Generic Substation State Event
PICOM: Piece of Information for COMmunication
SCSM: Specific Communication Service Mapping
SV: Sampled Values
OSI: Open Systems Interconnection
LN: Logical Node
LD: Logical Device
CDC: Common Data Class
SCL: Substation Configuration Language
XML: Extensible Mark-up Language
SCADA: Supervisory Control and Data Acquisition
HMI: Human Machine Interface
IED: Intelligent Electronic Device
PAS: Power Station System
TPAA: Two Party Application Association
MCAA: Multicast Application Association
RCB: Report Control Block
URCB: Un-buffered Report Control Block
BRCB: Buffered Report Control Block
SGCB: Setting Group Control Block
PLC: Programmable Logic Controller
MMS: Manufacturer Message Specification
OPC: OLE for Process Control
Analogue I/O: Analogue signal for Input or Output, usually 4-20mA. 4mA
means minimum and 20mA means maximum signal strength.
Digital I/O: Digital signal for Input or Output, 0 or 1 for on or off.

7
1 Introduction
1.1 Purpose
Vattenfall AB Vattenkrafts purpose with the initiation of this master thesis is to investigate
the prerequisites and consequences of an IEC 61850 introduction in their automation systems.
In line with Vattenfall ABs renewal strategies the communication interface of IEC 61850
needs to be implemented, tested and evaluated in todays generation of PLC-systems before
any further decisions can be made. Important feedback that this master thesis should provide
is both technological and economical aspects of the IEC 61850 introduction.
1.2 Background
Communication standards in the electric power industry provide a basis for an efficient
exchange of essential commands, status information and measurement data. As the number of
signals increased, existing solutions have reached their limits [10]. In 1994 EPRI/IEEE started
a work UCA2 (utility communication architecture), with focus on the station bus. In 1996 IEC
TC57 (technical committee 57) began work on IEC 61850 to define a station bus. This led to
a combined effort in 1997 to define an international standard that would merge the work of
both groups. The result is the current IEC 61850 specifications.
In 2004 a new group within IEC TC57/WG 18 started the work to define the use of 61850 in
hydro power plants. The WG (working group) 18 extension makes it possible to use IEC
61850 for hydro power plants. Vattenfall AB is an active member of this workgroup and
holds the chairman role. Today Vattenfall are using different solutions for every hydro power
station, each solution is almost unique. This is because no concept has been used when the
stations were built and because of different technology where available when the stations
where modernised. There is a need for standardising the communication in hydro power
plants and IEC 61850 could prove to be the way out of a vendor-specific environment just in
line with Vattenfall ABs renewal plans.

The following description of how the modern stations communication system is built is
generic but provides a god foundation for understanding it. On the top of the control system is
the station computer, which deals with functions concerning the whole station and all the
units, like water flow in and out of the station. This computer also handles the communication
with the plants control room and communications with central control stations. Below, there is
the unit computer that controls more local events for each unit, this computer also collects
measurements from the more local controllers and passes them on upwards in the
communication system. To the unit computer more PLC systems are connected that each
handles different tasks in the process, like magnetisation, turbine control and voltage control.
Each of these PLCs is connected to the process either via hardwired I/O signals or via a field
bus. The interface between the local controllers and the unit computer is the station bus. The
communication on the station bus level is today not standardised and Vattenfall uses different
solutions. In the older power plants there is no station bus, all signals are hardwired between
the PLCs and unit computer [9].
Introduction

8

Figure 1: Vattenfall system environment

Vattenfall uses controllers from different vendors in the power stations. Today there is one
station with a whole concept using Siemens as station/unit computer and turbine controller
and voltage controller. The same is true for ABB, one station uses a whole concept solution
from ABB. Furthermore about ten PLCs from Siemens are installed as turbine controllers.
Also one turbine controller is implemented on a PLC from GE Fanuc. Today Vattenfall are
installing turbine controllers implemented on standard industrial PLC systems delivered by
SwedPower AB. The controller hardware is based on the Siemens Simatic S7-300, and the
controller application is developed by SwedPower AB. This is the turbine controller that is
intended to be used in the nearest future in all upgrades for hydro power plants. Vattenfall
needs an interface for IEC 61850 in turbine controllers since the modern generation of power
distribution equipment will be using this interface. Since the programming methods for PLC
systems follow the standard IEC 61131-3 and not IEC 61850, it is of interest to study how to
implement IEC 61850 in an environment of a PLC.
1.3 Outline of the report
Chapter 1 - Introduction is intended to focus the reader on the right problem and provides a
background for the rationale behind the initiation of the master thesis. Chapter 2 - Research
Method provides information regarding the goals, methods used and literature studied in this
work. Chapter 3 - Communication solutions provides a basis for understanding IEC 61580
that is the standard investigated and tested in this work and other communication solutions of
interest in this work. More information regarding IEC 16850 can be found in Appendix 1 -
IEC 61850. Chapter 4 - Product information describes the hardware and software products
that have been of interest during the investigation of suitable solutions to the research
problem. Chapter 5 - Design alternatives presents the options that were presented at a meeting
at Vattenfall during December in order to select a suitable design for the IEC 61850 interface.
The selected alternative is presented in chapter 6 - Design proposal. The Test and
implementation plan and the results for verifying the design is presented in chapter 7 - Testing
the interface. Chapter 8 - Results describes the result of the project. Chapter 9 - Future work
Introduction

9
presents the conclusions and any future work that might be of interest for the design proposal,
and also a discussion of future products that might be of interest.
10
2 Research Method
This chapter presents the objectives for the study and the research method for achieving the
goals for this project. This technical report is in first hand to be considered as a feasibility
study that addresses the problem defined in chapter 2.4.
2.1 Goals
The overall goal of this project is to provide a basis for future decisions as part of the renewal
strategies of Vattenfall Vattenkraft AB. The main task of this master thesis work is to
investigate software and hardware that enables messaging on station bus level using IEC
61850 as protocol, focusing on turbine controllers. The secondary task if the investigation has
a positive result is to implement and test the messaging on station bus level specified in the
communication interface of IEC 61850.
The objective is to deliver a technical report that summarises the result and conclusions of the
investigation, implementation and testing of IEC 61850 in PLC-systems.
Including a software and hardware investigation of PLC and communication products
from different vendors that are suitable for using in an implementation of an IEC 61850
interface.
Including one or more design proposals with a test plan.
Including implementation and testing results from one of the design proposals.
2.2 Scope of the study
Due to the fact that the focus of this study will be set on communication for turbine
controllers and HMI systems a natural restriction will be that only communication on station
bus level will be investigated. A restriction during the implementation is that only one or few
of the logical nodes specified in IEC 61850 will be implemented and tested, and only the
read/write service will be implemented and tested.
2.3 Problem description
The main goal with this master thesis in the project specification was set to investigate
solutions for enabling an IEC 61850 interface for PLC systems. One of the main problems is
that IEC 61850 is a standard for sub station automation. Servers are located in distributed
devices like switchgear and protection devices. These devices hold their own controlling
equipment and are not connected to PLC systems for controlling purposes. In short the IEC
61850 standard is not directly applicable to industrial automation PLCs. Figure 2 below
shows typical equipment in a sub station communicating over a station bus.
Research Method

11

Figure 2: Station bus

Since a PLC is a multipurpose device and holds no own functionality until the user programs
it, the development of a server for PLC systems must be user configurable and relate to some
sort of predictable mapping of the data objects in the standard to I/O signals or parameters in
the user program. A hydro power plant contains a sub stations but it also contains much more
distributed functionality that are located in PLC systems. The standard is therefore not
applicable right on. New logical nodes and data objects that can present the information
produced in the hydro power plant must be defined. In TC 57 WG 18 of the IEC, work is
being done to define these new logical nodes and data objects that would cover all the
information presentation needed in hydro power plants. However, this work is not finished
until 2007/2008. The logical nodes and the data objects from this new standard are accessible
in committee drafts.
2.4 Research Problem
In hydro power plants industrial automation PLCs are used to implement turbine controllers.
At the same time the IEC 61850 standard has been developed to support substation
automation and communication in the power industry. The IEC 61850 standard does however
not cover controllers, and manufacturers of industrial automation PLC do not support he IEC
61850 standard.
2.5 Implementation guidelines
There are some basic guidelines that have come up during the investigation and they are
essential for understanding what products that were investigated, and the design of the
alternatives for an interface.
A design based on a PC gateway is acceptable.
Vattenfall does not wish to develop new products, like communication cards that will
be included in an interface. If it is possible to implement an interface, a vendor will be
contracted for any kind of development job.
Off the shelf products that can be configured and programmed are preferable.
The interface must be possible to use with todays turbine controller (treg 1.0)
delivered by SwedPower.
Research Method

12
2.6 Investigation path
The work to design an IEC 61850 interface has consisted of studies of IEC 61850 and
technical manuals of suitable PLC systems. The work started with a project specification
where the milestones and goal where specified. After KTH and Vattenfall accepted the project
specification, the investigation started with studies of the IEC 61850 standard. After initial
studies of the IEC standard, PLC system manuals and product information regarding IEC
61850 were studied. Contact with vendors of PLC products and software were initiated early
for future references regarding their systems and possibilities to use them in the
implementation. During the process of creating a design proposal a few alternatives were
identified. The design alternatives have been discussed with the technical advisors and tutors
and the vendors of the components selected. The final and more detailed proposal is presented
in chapter 6. After the decision had been made by Vattenfall to go forth and test the selected
components an order was placed for the selected components and some tests were made.
Chapter 8 provides the result of the whole project as specified in the project specification.


Figure 3: Workflow for design proposal, starting on project specification.

2.7 Literature
The information concerning the Simatic products has been collected from the Simatic
webpage [7] and from the introduction book [1], and from discussions with Siemens technical
support for Simatic products. Manuals from Siemens can be located on Siemens website using
the ordering number specified for each manual in chapter 11. The most important documents
from the webpage are: [2], [3] and [11]. Information concerning the standard of IEC 61850
has been collected directly from the documents in the standard, parts of the IEC 61850
Research Method

13
appendix has been written by Mr. Berkan Kapkac during his master thesis work at ALSTOM
Power AB. Information regarding ABB control systems has been collected from discussions
with representatives from ABBs organisation and from their webpage [8]. Information
regarding products from SISCO and Tamarack has been collected from e-mails and telephone
calls with the contact persons for respective company or their respective European value
added resellers. Unless any other reference is presented in the text, the information presented
in chapter 1, 3, 4, 5 and Appendix 1 - IEC 61850 has been collected as described above. All
technical experts that have been contacted during this project are listed in chapter 10.
14
3 Communication solutions
This chapter describes the basics of the communication solutions of interest in this work. The
chapters considering OPC and MMS are meant to orientate the uninitiated reader about the
subject, since both MMS and OPC will be mentioned later on in this report. MMS is used as a
part of IEC 61850 and should not be of interest to the solution, it is only important that the
reader is aware that services in IEC 61850 are performed by the use of MMS services. OPC is
of interest since this will be used as a method for communication in one of the solutions
presented in this report later on.
However both of them can be considered as underlying messaging systems as both of these
communication solutions are standards and there are functional solutions to communicate in
accordance to both of them with PLC:s. The focus should be laying on IEC 61850, as this is
the new communication protocol that does not have a solution for PLC systems.
3.1 IEC 61850 Overview
A short description of the standard IEC 61850 is given below, a more thoroughly explanation
can be found in Appendix 1 - IEC 61850.
3.1.1 Information model
The goal of the IEC 61850 series is to provide interoperability between IED's from different
vendors or, more precisely, between functions to be performed in a substation but residing in
equipment (physical devices) from different vendors. The information exchange mechanisms
rely on well-defined information (data) models. These information models and the modelling
methods are at the core of IEC 61850 series.

The standard uses the concept of virtualisation. Virtualisation provides a view of those aspects
of a real device that are of interest for the information exchange with other devices. Only
those details that are required to provide interoperability of devices are defined in the IEC
61850 series. Several different physical devices are often used together in a power station
system to perform a specific functionality. This kind of functionality is called distributed
functionality and the devices involved are called distributed devices. If a distributed
functionality is going to work correctly it is required that the involved devices communicate
with each other in a standardised manner.

In IEC 61850 series functionalities that the real devices comprise are decomposed into the
smallest entities, which are used to exchange information between different devices. These
entities are called logical nodes. The logical nodes are the virtual representation of the real
functionalities. The intent is that all data that could originate in the substation can be assigned
to one of these logical nodes. Several logical nodes from different (real-) devices build up a
logical device (which is a virtual device). A logical device is always implemented in one IED,
therefore logical devices are not distributed.

Logical devices, logical nodes and data objects are all virtual terms. They represent real data,
which is used for communication. One device (for example a control unit) only communicates
with the logical nodes or its data objects of another device (for example an IED). The real
data, which the logical nodes represent, are hidden and they are not accessed directly. This
approach has the advantage that communication and information modelling is not dependent
on operating systems, storage systems and programming languages [10]. The concept of
virtualisation is shown in figure 4 below, where the real device on the right hand side is
modelled as a virtual model in the middle of the figure. The logical nodes (for example
Communication solutions

15
XCBR, circuit breaker) defined in the logical device (Bay) correspond to well known
functions in the real devices. In this example the logical node XCBR represents a specific
circuit breaker of the bay to the right.


Figure 4: Virtual and real world.

Based on their functionality, a logical node contains a list of data (for example, position) with
dedicated data attributes. The data have a structure and a pre-defined semantic. The
information represented by the data and their attributes are exchanged by the communication
services according to the well-defined rules and the requested performances.

To illustrate more clearly how the logical devices, logical nodes, classes and data concepts
map to the real world, imagine an IED as a container.


Figure 5: Physical and logical device.
Communication solutions

16

The container is the physical device, which is containing one or more logical devices. Each
logical device contains one or more logical nodes, each of which contains a pre-defined set of
data classes. Every data class contains many data attributes (status value, quality etc.).
3.1.2 Information exchange model
The IEC 61850 series defines the information models and information exchange services in a
way that it is independent of a concrete implementation (i.e. it uses abstract models). This is
done by an object-oriented concept called Abstract Communication Service Interface (ACSI),
which is the subject of IEC 61850-7-1, IEC 61850-7-2, IEC 61850-7-3 and IEC 61850-7-4.
Abstract means that the definition is focused on the description of what the services provide
1
.
The concrete implementation is achieved through the Specific Communication Service
Mappings (SCSM), which are defined in IEC 61850-8-1, 61850-9-1 and 61850-9-2. In this
work only the 8-1 part of the standard is of interest since both of part 9 only considers the
process bus, while 8-1 considers the station bus. In IEC 618508-1 the services described in
ACSI is mapped to the MMS service. However there is only one such specific mapping to
day, the standard are constructed in a way that allows it to be mapped over other protocols as
well.

1
Abstraction in ACSI has two meanings. First only those aspects of a real device (for example, a breaker) or a
real function that are visible and accessible over communications network are modelled. This abstraction leads to
the hierarchical class models and their behaviour defined in IEC 61850-7-2, IEC 61850-7-3 and IEC 61850-7-4.
Second, the ACSI abstracts from the aspect of concrete definitions on how the devices exchange information;
only a conceptual cooperation is defined.
Communication solutions

17

Figure 6: Conceptual service model of the ACSI.

3.2 OPC
OPC is the acronym for OLE for Process Control, but it should rather be called COM for
Process Control since OPC is based on the Component Object Model (COM). COM is the
central component of Windows operating systems and controls the interplay between multiple
software components. By using COM, the OPC server becomes similar to part of the
Windows operating system and is therefore independent of file names, storage locations, and
versions. As a further development of COM, DCOM supports distributed applications and
allow cooperation between software components on different computers within a network.
Before OPC, a lot of effort was necessary to control the hardware of different vendors using
software applications. There were numerous different systems and protocols; for each vendor
and each protocol, a user had to order special software to access the specific interfaces and
drivers. User programs were therefore dependent on the vendor, protocol, or system. OPC on
the basis of COM or DCOM has a uniform and non-proprietary software interface that has
revolutionised data exchange in automation engineering. Today OPC is the most common
way to exchange data between applications connected to real-time systems from different
vendors [11]. Figure 7 show the typical use of OPC, were OPC is used to connect a SCADA
system with hardware from different vendors.
Communication solutions

18

Figure 7: OPC interface

3.3 MMS
MMS (Manufacturing Message Specification) is an internationally standardised messaging
system for exchanging real-time data and supervisory control information between networked
devices and/or computer applications in a manner that is independent of the application
function being performed or the developer of the device or application. MMS is an
international standard (ISO 9506) that is developed and maintained by Technical Committee
Number 184 (TC184), Industrial Automation, of the International Organization for
Standardization (ISO). The messaging services provided by MMS are generic enough to be
appropriate for a wide variety of devices, applications, and industries. For instance, the MMS
Read service allows an application or device to read a variable from another application or
device. Whether the device is a Programmable Logic Controller or a robot, the MMS services
and messages are identical. Similarly, applications as diverse as material handling, fault
annunciation, energy management, electrical power distribution control, inventory control,
and deep space antenna positioning in industries as varied as automotive, aerospace, petro-
chemical, electric utility, office machinery and space exploration have put MMS to useful
work.
MMS provides a comprehensive and flexible framework for exchanging variable information
over a network. The MMS variable access model includes capabilities for named, unnamed
(addressed), and named lists of variables. MMS also allows the type description of the
variables to be manipulated as a separate MMS object (named type object). MMS variables
can be simple (e.g. integer, boolean, floating point, string, etc.) or complex (e.g. arrays and
structures). The services available to access and manage MMS variable and type objects are
very powerful and include services for:

Read and Write services allow MMS client applications to access the contents of
Named Variables, Unnamed Variables, and Named Variable List objects.

Communication solutions

19
The Information Report service allows a server to report the contents of a variable to a
remote client in an unsolicited manner.

Define, delete, and get attribute services are available for both variables and types to
allow clients to manage the variable access environment.

Service options allow groups of variables to be accessed in a single MMS request, allow large
arrays and complex structures to be partially accessed (alternate access), and allow clients to
recast variable types and complex structures to suit their needs (access by description) [5].

20
4 Product information
This chapter will present a description of the products considered in the solution to the
research problem. The description will consist of hardware, software, development
environments and communication capabilities. Also software implementations of IEC 61850
and communication software needed to present a solution are described here.
4.1 Siemens S7 PLC
This chapter provides a description of the communication interface, software environment and
the hardware available in the Simatic PLC systems. The Simatic PLC systems are presented
more thoroughly than the ABB PLC system since this is the hardware that the original turbine
controller is based upon.

Figure 8: S7-300 PLC system


Figure 9: S7-400 PLC system

4.1.1 Hardware
The Simatic automation system is a range of coordinated components. The main unit includes
a central processing unit and a memory to store the user program. The main unit handles
communication with other modules that are connected via the multi-point bus (MPI) bus. The
MPI bus is used to establish a subnet in which CPUs user interfaces and programming
devices can exchange data. There are many different modules that can be attached. The most
important for this work is the communication processor (CP) that connects the PLC to a
variety of networks.
Product information

21
There are CP:s for PROFIBUS, FMS, Industrial Ethernet, and more. The Industrial Ethernet
CP can be used to establish ISO-Transport and ISO-on-TCP connections [1].
The main units of Simatic come equipped with different hardware for different demands on
processing capabilities. The Simatic S7 family consists of several modules that are mounted
on a rail. For a complete unit a power supply and a CPU unit is needed. The CPU units have
different amount of memory and performance capabilities to suit different users needs. I/O
modules can be used to expand the systems capabilities to control tasks, although the more
I/O the more performance and memory it takes to process them. The turbine controller uses
both hardwired I/O and distributed I/O over Profibus.
4.1.2 Software environment
The complete program of a CPU consists of the operating system and the user program.
4.1.2.1 Operating system
The operating system contains instructions and declarations of internal device operating
functions and is proprietary to Siemens. There are several system data blocks (SFB) and
functions ready (SFC) for use in the operating system. The SFC are functions without a
memory and its parameters (return values) has to be processed by the user program
immediately, while the SFB has a memory and its output can be accessed anywhere and
anytime in the user program.
4.1.2.2 User program
The user program contains all programmed instructions and declarations for the control task.
The user program is usually divided into a self-contained technological or functional unit.
These units are called blocks. The FC and FB works the same way as SFC and SFB, but they
are not a part of the operating system they are programmed by the user [2]. The organisation
blocks are the interface between the operating system and the user program. The organisation
block is a part of the user program and are called and processed by the operating system when
certain events occur. Priority tagging of the organisation blocks governs the actions taken by
the CPU on events. Events from a higher priority can interrupt events from a lower priority, if
the interrupting event has lower priority than the running event, the event that is running is
finished before the CPU handles the interrupting event. The priorities span between 1 (lowest)
to 29 (highest).
4.1.2.3 Memory
The information on signal states is stored in the memory area. The address areas are the part
of the memory area, which can be manipulated by the user program. There are address areas
for inputs and outputs of the process and a bit memory for internal data storage. The part of
the system memory that holds the signal states is the process-image input table (PII) and the
process-image output table (PIQ). It begins at I/O address 0 and ends at an upper limit
specified by the particular CPU. The bit memory are the part of the memory where variables
from SFB:s are stored and can be accessed from other parts of the user program. The data are
stored bitwise in the memory and each address contains 8 bits of data (1 byte is 8 bit). The
memory can handle addresses up to 4 byte of length, which is equal to 32 bits of length. The
addressing of these bytes and bits are Mx for memory area, Ix for input area and Qx for output
area of the memory, where the x notation is either blank for a bit, B for a byte (8 bit), W for a
word (16 bit) or D for double word (32 bit).
The parameter are addressed from their storage location, a 16 bit length integer would have
the bit memory address MW100, where M is the bit memory, W is 16 bit length and 100 is the
position in the memory. This parameter will be stored in positions 100 and 101 since each
address contains 8 bits. So the next unassigned address will be 102. A bit is addressed
Q102.0, this addresses bit number 0 in position 102 in the output memory area.
Product information

22
4.1.2.4 Operation
When the CPU starts a start-up program is executed, thereafter the signal states of PIQ are
transferred to the output modules and the signal states of the input modules are transferred to
the PII by the operating system. Then the main program runs. This is located in organisation
block 1 (OB1). The operating system calls OB1 that has priority 1 (lowest) and can be
interrupted by all events. The user program in OB1 then calls other blocks (i.e. user
programs), which are processed in an order. When OB1 is completed, the operating system
sets the signal states from PIQ to the output modules and reads new signal states from the
input modules to PII. Finally when the program is completed, OB1 is executed again by the
operating system.
4.1.3 Communication interface
Communication processors are used to relieve the CPU of communication tasks. The
communication utility specifies how the communication stations are to exchange data and
how these data are to be treated. The utility is based on a protocol, which describes the
coordination procedure between communication partners. Recognised utilities are S7
functions, Profibus, ISO-transport, ISO-on-TCP and some serial link protocols. The
communication functions are the user programs interface to the communication utility. The
communication functions are integrated in the CPUs operating system and are called by
system blocks for internal Simatic S7 communication. Loadable blocks are available for
communication with external devices thorough communication processors. Every CPU is
equipped with the MPI bus on which Siemens own protocol is used. Transmission speed is up
to 187.5 kbit/s and uses shielded two-wire copper cable or fiber optic cable, the physical
connector is the same as for Profibus. The Profibus interface can transfer data up to 12 Mbit/s
over either a shielded two-wire copper cable or a fiber optic conductor. Up to 127 stations can
be connected and the communication is established using token ring technology where a
master communicates with the slaves when it has the token. Data can be transferred using
Profibus FMS and Profibus FDL and Profibus DP, also S7 functions can be used.
Industrial Ethernet is the subnet for connection to computers. The connection uses a double-
shielded coaxial cable or an industrial twisted pair. Also fiber optic cable is available. The
communication interfaces are S7 functions, ISO-transport and ISO-on-TCP. Transmission
speed is up to 100 Mbit/s.
4.1.4 Programming
Step 7 is the software used for configuring and programming Simatic PLC, this means:
Setting up managing projects
Configuring and assigning parameters to hardware and communications
Managing symbols
Creating programs for S7 programmable controller
Downloading programs to programmable controllers
Testing the automation system
Diagnosing plant failures

Step 7 conforms to the programming languages defined in IEC 61131-3, which is a standard
for logic programming of controllers and the programming methods will not be explained
here. The most common languages defined in IEC 61131-3 are:
Ladder logic (LAD) is a graphical representation of the programming language. The
syntax for the instructions is similar to a relay ladder logic diagram
Product information

23
Statement list (ST) is a textual representation of the programming language, similar to
machine code.
Structured control language (SCL) is a Pascal-like programming language, which is
more suitable for creating complex functions.

The turbine controller is implemented in FCs and FBs in the IEC 61131-3 languages and the
process data is exchanged over Profibus using integers.
4.2 ABB AC 800M PLC
ABBs concept of Industrial IT is a system family consistent with controllers, HMI, SCADA
and more products that can all be connected and commissioned from the same engineering
station.

Figure 10 - AC 800M controller

4.2.1 Hardware
The AC 800M controller is a modular based system that can be comprised of CPU units of
different performance ranging from 48MHz to 96 MHz and memory sizes of 8Mb to 32Mb
and I/O cards with a different amount of analogue and digital inputs/outputs and different
communication cards depending on communication protocol to be used. The basic line-up is a
CPU unit, a power unit and an I/O module. The modules are mounted on a rail that houses
two internal communication buses. One bus for additional I/O modules and the other bus is
the CEX bus for communication modules for various network types and protocols.
4.2.2 Software environment
The system software runs on a real-time operating system called VxWorks. All parameters
from the user program in the PLC can be mapped to MMS variables and are accessible from
both overlaying systems (HMI systems on the station bus) via OPC connections and to the
user interface.
4.2.3 Communication interface
All CPU units have two onboard Ethernet-interfaces for access to Industrial Ethernet. For
access to other protocols separate communication cards are plugged in to the main unit. The
Product information

24
800M system uses MMS for communication between the connected devices over an Ethernet
interface.
4.2.4 Programming
ABBs Industrial IT suite conforms to the programming languages of IEC 61131-3. Also
ABBs own control module language is available. This programming method allows the user
to mix all elements of IEC 61131-3 into pre-defined algorithms, to hide the control logic. By
storing these control modules in a system library the solutions can be reused throughout the
entire automation system. The control builder is tool used to specify a project containing all
hardware components in a automation system, this is also where the user programs are written
and compiled before they are transferred to the PLC.
4.3 Siemens Simatic Microbox 420
The Microbox is an industrial PC system that can be used for communication tasks and
controlling tasks. For controlling tasks WinAC RTX can be used which is a software PLC that
communicate with devices over industrial Ethernet or Profibus.

Figure 11: Microbox

4.3.1 Hardware
The Microbox is a DIN rail mounted industrial PC without any moving parts (fan less
cooling) except for the optional hard drive. The Microbox runs on an Intel Celeron 400MHz
or 650 MHz, or an Intel Pentium III 933 MHz with a memory of 128, 265 or 512 MB.
4.3.2 Software
The Microbox runs Windows XP Pro, Windows XP embedded or Linux. The operating
system can be booted from an internal hard drive, compact flash memory card or an USB
memory stick. On the hard drive version Windows XP Pro is used. For the flash drive
Windows XP embedded is used. WinAC RTX (RTX means Real-Time eXtension) provides
the controlling functions of a PLC in a PC environment. The WinAC RTX software provides
a shared memory area for real-time parameters. This means that real-time controlling
applications (PLC programs) will have the ability to share the memory with Windows
environment application, i.e. both the controller application and programs in the multi-task
environment of Windows have read and write access to these parameters. This can be used for
Product information

25
third-party Windows applications that need to send/receive real-time information to control
systems, such as set-point values or calculated values from the control application.
4.3.3 Communication interface
For user communication the Microbox has 1 serial port (9-pin COM port), 4 USB 2.0
connectors and DVI-I monitor interface. For network communication the Microbox are
equipped with 2 Ethernet ports and one Profibus/MPI connector. An important difference
between a Microbox and a PLC regarding the controlling purposes is that a Microbox does
not provides analogue or digital inputs or outputs the same way as a PLC. The only way to
communicate with field devices is by the use of field busses, either by Ethernet or
Profibus/MPI.
4.4 Tamarack software stack for embedded systems
Tamarack Consulting has developed a Software stack for embedded devices for use in
integration of IEC 61850 in different products. The software is an application programming
interface (API) delivered in ANSI C code. All IEC 61850 services accesses the user data
strictly through data handler functions, which translates from the local data representation to
the IEC 61850 data encoding. Data handlers that are included in the software are restricted to
variables defined in RAM in C, but customised handlers for any access method can be
developed. The protocol stack does not include a TCP/IP stack so the software needs access to
a system sockets interface. A server application is generated in C source code using the
included proprietary object builder. The data objects can either be defined static (i.e. at
compile time) or dynamically using SCL-files as defined in IEC 61850-6.
4.5 MMS-EASE Lite
MMS-EASE Lite: IEC 61850 for embedded systems is a C language application program
interface containing modules of C code with an implementation of layer 5-7 of the OSI model
that is conformal to the A-Profile in IEC 61850. MMS-EASE consists of a library of C
language function calls and data structures that provide application programs access to all the
services needed for communications utilising the IEC 61850 protocol in a manner that is
independent of any particular interface board or operating system. A tool for developing
ANSI C code for the application is provided in the package and is a Windows-based software
named MMS Object Foundry. The software package includes a high-level interface layer
referred to as MMS-Virtual-Lite (MVL). MVL is coupled with the lower layers and provides
an application framework. A number of configurable sample applications for both client and
server use is provided. MVL also supply means for conversation of local data formats into
IEC 61850 encoding, which is done using a dual-port RAM in the device. The lower levels of
the stack are accessed using sockets interface in the operating system.
Product information

26

Figure 12: Software package provided by Sisco

4.6 AX-S4 MMS
AX-S4-MMS is an IEC 61850 interface for windows applications supporting OPC data access
(DA) interface and Dynamic Data Exchange (DDE). It features implementations of
server/client functionality. The principle is to use a PC platform running Windows 2000/XP
for the IEC 61850 server and access process parameters as OPC items from arbitrary OPC
server. The server functionality is implemented from the MMS-Ease Lite, and support
write/read and reporting. The logical nodes and data objects in the server are configured via a
SCL file that is imported to the server. There are options to set mapped items with read only
or read/write permission. The scan rate i.e. how often the IEC 61850 server should update the
values from the OPC server, is grouped and every individual value are associated with a
group. The user creates groups to which permissions and scan rates are associated. This way
the most important values can be updated as often as one would like, whilst the less frequently
used values can be updated less often. During read requests the server responds with the
initially set value or the latest value acquired by the OPC client. During write request the
server writes the value to the OPC server before it sends acknowledgment to the IEC 61850
client. Figure 13 shows the architecture diagram of AX-S4 MMS. The software also includes
an OPC server and an IEC 61850 client that can be configured for accessing IEC 61850
devices from Windows applications.
Product information

27

Figure 13: AX-S4 MMS architecture

4.7 SOFTNET for PROFIBUS
Softnet for Profibus is Siemens proprietary solution for communication between PLC systems
and PC stations. The communication uses Siemens proprietary S7 function protocol, which is
a method to access individual bits or bytes in the memory area of the PLC. The Softnet for
Profibus includes an OPC server and a configuration tools OPC Scout. The OPC server is
included in the Simatic project and can access S7 devices using the proprietary S7
communication protocol. From the OPC Scout one can connect to the OPC server and access
the variables in the memory and process area of the PLC. Groups can be created in the OPC
server in which transmission intervals and member items can be organised. Every position in
the memory area of the PLC can be linked to an OPC Item. The OPC linking of data does not
however provide any type of data conversation, so a OPC item of floating-point type must be
linked to a floating-point type in the PLC. These Items are accessible to any OPC client as
COM objects in Windows environment. Most OLE data types can be read via the OPC
interface from the PLC. The ones that are of interest in this work are: Integers, floating-point
numbers and bits. The notation of OPC data type that is of interest are X for boolean, INT and
DINT for integers of 16 and 32 bits length, and REAL for floting-point number (32 bits).
28
5 Design alternatives
These are the design alternatives that were considered during the implementation phase. The
requirements must be to implement the communication server without interfering with the
user application that handles the controller routines. To do this the server must either be
implemented on a separate communications card, or as an application in a multi-tasking
environment. In order to import one of the source code implementations of IEC 61850
described in chapter 4.4 and 4.5 there is a need for a C compiler supporting the hardware on
which the source code shall be compiled. Figure 14 below describes in a convenient how such
an interface must be implemented. The process data that are produced by the controller
application needs to be shared with applications located in different devices, at the same time
this data must also be available to be exchanged using other protocols than IEC 61850. The
ACSI is the link between the controller application that produces the process data that needs
to be accessed by other devices, these devices uses different communication protocols, where
IEC 61850 is one of them. The services provided by the ACSI must be implemented by means
of the OSI model, where each protocol provides services to the overlying protocol and uses
the services provided by the protocol below. The SCSM implementation is the protocol stack
used by specific protocols like IEC 61850 or Profibus for instance.

Figure 14: Implementation of software stack.

In order to do this without interfering with the controller application itself, the protocol stack
must be implemented on a separate communications card or in a multi-task environment
where the environment allows different threads to be processed prioritised. PLC:s does not
offer a multitasking environment, so the option is to implement the communication stack on a
separate communication card. The ACSI must be implemented as the interface between the
communication card and the controller where each implemented data attribute on the
communication card can be linked to a specific memory position or I/O address in the
memory of the PLC. Since the PLC knows nothing of the name semantics of the protocols but
rather just the memory address for each parameter in the controller application, the
conversation from the name of an IEC 61850 data into the memory position of the PLC must
be translated in the communication card. The server implementation does not need to be user
Design alternatives

29
configurable since a turbine controller only will have a certain function and that function will
not change over time. This means that the translation between IEC 61850 data attributes and
PLC parameters into the memory position where the value of each PLC parameter is stored
can be configured before compilation of the server. So if a server is possible to implement on
a PLC system, all of the logical nodes and data objects can be defined from the start. The
design alternatives that support an implementation like this are presented below.
5.1 Implementation on ABB PLC system:
ABB are currently running a project to implement IEC 61850 into their automation system.
How this will be implemented is not decided by ABB yet, but it will be implemented on a
separate communication card using one of the two source code implementation of IEC 61850
described in chapter 4.4 and 4.5. The interface between the controller and IEC 61850 is the
mapping of data objects in IEC 61850 to the process values stored in the memory of the
controller.
5.1.1 Design alternative for AC 800M
The communication card ABB are developing does not fit the requirements for Vattenfall,
since ABB not will implement the complete functionality of IEC 61850. The development
environment for ABBs communications card is the Tornado by Windriver Inc (which
supports C), this opens a opportunity for Vattenfall to implement and test the functionality of
a IEC 61850 server that are required by the turbine controller without dependence from
ABBs development project. For further development of this communication card into a
complete product, Vattenfall could either contract ABB using their customer funded research
program or by in-house development.

The requirements for this would be:
Hardware:
ABB AC800M PLC system
SM810 Communication module
Software:
Software package with communication stack and server application.
o SISCO
o Tamarack
TCP/IP stack for the communication card
ABB development environment / Tornado development environment from Windriver
Inc.
ABB control builder

The software package would be implemented on a separate communication card containing
the TCP/IP stack. The software package containing the realisation of the ACSI with its
logical nodes and data attributes and would be linked to the parameters in the user program of
the controller. The encoding to IEC 61850 data format is provided by the server application
that is provided by the software package.

Uncertainties:
No support from ABB regarding the development environment is avaliable.
How to define the mapping of the data objects in the logical node to the user parameters in the
PLC, since the parameters needs to be accessible for both read and write for both the user
application and the server.
Design alternatives

30

Expected results:
A successful result would prove the AC 800M as a possible turbine controller including an
IEC 61850 interface for future installations of turbine controllers. For the modern turbine
controller this type of implementation could be used as a gateway by connecting the AC800M
to the S7-300 PLC using Profibus or Ethernet and configure the controller application in the
AC800M to cyclically read all process values from the S7-300 system. This way the turbine
controller application in the S7-300 is unaltered and the AC800M will be the IEC 61850
communication interface for the turbine controller.
5.2 Implementation on Siemens PLC system:
Siemens has no plans for developing a communication processor for the Simatic series of
PLC with support for the IEC 61850 protocol. There seems to be no possibilities to use or
license Siemens development environment for in-house development of a communication
card for Vattenfall. Because of this there are no alternatives of importing any of the softwares
described in chapter 4 to the PLC.
5.2.1 Design alternative for Simatic PLC
According to Siemens Automation and Drives it should be possible to implement the
communication stack defined in IEC 61850 in Step 7 using the IEC 61131-3 language.
However this not supported by Siemens Automation and Drives. The Simatic S7-300 that is
currently used, as turbine controller does not have enough performance to support a new
communication protocol and the control application. Siemens automation and drives
recommended that for such an implementation the S7-400 system should be used or to
implement the server application on a separate S7-300 controller and link them both using
MPI bus. In order to implement the communication stack on a S7-400 the CP 431-1 would be
a suitable communication card to use, since it provides an implementation of layer 1-4 that is
defined as TCP/IP T-profile in IEC 61850-8-1. Siemens Industrial Solutions (independent
from Automation and Drives) has developed a client for communication with protection
devices. Since the protocol stack for a server and a client are the same and only the
application it self (client application or server application) are different this might be a
feasible option to develop an IEC 61850 server for the Simatic PLC. Siemens Industrial
Solutions implemented this client using the IEC 61131-3 language and the client function
block runs on a S7-400 and it uses the communication utilities of the CP 431-1
communication card. Layer 5-7 which is described as the A-Profile in IEC 61850 must be
implemented as a function block in a S7-400 system.
5.3 PC Gateway design
Since implementation of IEC 61850 on a separate communications card requires that
Vattenfall have access to the development environment of the specific vendor, a PC gateway
design is more suitable if Vattenfall would like to develop an interface for IEC 61850. The
interface would consist of standard off the shelf products and would be user configurable
without having to be dependent of vendor supplied development environments.
5.3.1 Microbox gateway and WinAC RTX
The multi-task environment of Windows and the shared memory area of WinAC RTX can be
used to implement one of the source code implementations of IEC 61850 in a convenient way.
Since the Microbox are not equipped with digital and analogue input and outputs either the
turbine controller would need to be implemented in the soft PLC environment or that a
Design alternatives

31
program that cyclically reads all process values from the S7-300 must be implemented in the
WinAC. What really needs to be implemented and tested with this type of design is an
application handling the delivery of data from the RTX environment to the IEC 61850
environment and vice versa using the API provided by the WinAC RTX soft PLC. Figure 15
shows a schematic over the implementation using the SMX as described in chapter 4.3.2.


Figure 15: WinAC RTX implementation

Components needed:
o Simatic S7-300 with Profibus interface.
o Ethernet switch
o PC platform (client)
o Simatic Microbox 420 from Siemens Automation and Drives.
o Step 7.
o Compiler supporting ANSI C and Windows environment.
o Tamarack software stack.
5.4 Rejected alternatives
A number of alternatives where considered and discussed, but rejected for some reason.
Below are a presentation of these alternatives and the reason for rejection.
Use the client that was developed by Siemens I&S and use it for reverse
communication, the client could be implemented on a S7-400 system and the service
of SetDataValues could write values to a server located in a PC. This would not be
possible since the client is sold as know how protected function blocks that are loaded
into the Simatic environment.
Design alternatives

32
Implementation on ABB PLC system. If Vattenfall were to implement the interface
on ABB PLC systems, the development environment from Windriver would need to
be licensed and the source code implementation of IEC 61850 needs to be licensed.
This would mean a very big development project, and is not suitable for testing during
a master thesis work.
Order development from ABB. Vattenfall would be too dependent on a vendor in
order to make changes to the interface.
Implementation on Simatic PLC system using IEC 61131-3. This would take too
much resource and would be a very costly alternative, and it is not certain to be fully
functional.
Implementation on Microbox using WinAC RTX and Tamarack software
implementation. This would be a fully flexible and user configurable solution.
However this alternative is very costly since it includes rewriting the functions of the
turbine controller and includes very expensive software implementations of IEC
61850. This also would mean that Vattenfall would need to start a large development
project.
33
6 Design proposal
This is the design alternative that has been selected for a test, the design has been discussed
with the vendors of the products included in the design, and they offer support for the
implementation. This is the best alternative for a design that shall be possible to test during
this project and it does fulfil the requirements for an interface.
6.1 Overview
With this gateway design there will be no problems with mapping IEC 61850 objects to the
memory of the PLC since the interface between the IEC 61850 data attributes and the PLC
addresses will use standard OPC interface. In order to communicate with the S7-300 PLC
system the Simatic Softnet OPC Profibus is needed. This software module is installed on the
Microbox system. From the Softnet module, parameters in the PLC can be mapped to the
OPC server as items. The communication between the PLC and the Microbox will use S7
protocol over Profibus. The items in the OPC server are accessible from any OPC client. The
software package AX-S4 MMS includes an IEC 61850 server and an OPC client for easy
mapping to these items on OPC servers. See figure 16 for an overview of the communication
solution for the gateway.

Figure 16: Gateway design
6.2 Hardware:
The following hardware is needed for the design.
o Simatic S7-300 with Profibus interface.
o Ethernet switch
o PC platform (client)
Design proposal

34
o Simatic Microbox 420 from Siemens Automation and Drives.
o Monitor
o Keyboard
o Mouse
6.3 Software
The following software is needed for the design.
o Step 7.
o SOFTNET for PROFIBUS.
o AX-S4 MMS from Sisco Inc.
o Tamarack MMSd test client.
6.4 Design specifications
This chapter will present the specification on what that will be implemented in the server, for
a architecture diagram of AX-S4 MMS, see figure 13.
6.4.1 Configuration
The server is configured using SCL-files accordingly to IEC 61850-6, a small example in the
textbox below:
Within the <LNodeType> tags the name and class of the logical node is defined. Within the
<DO Type> tag each name of included compatible data class and their common data class is
defined using the <DA name>. The attributes of basic type are defined using bType. Composite
components are defined as bType="Struct" and an additional tag, type describes the structure
type. Also the functional constraint is set for each attribute in this tag. Structure types are
defined using the <DAType> tag, and the attributes of basic types are defined for each
structure using the <BDA name> tag. The basic types of data are already defined in AX-S4
MMS.

























- <LNodeType id="TPOSa" lnClass="TPOS">
<DO name="Mod" type="INC" />
<DO name="Beh" type="INS" />
<DO name="Health" type="INS" />
<DO name="NamPlt" type="LPL" />
<DO name="Psn" type="SAV" />
</LNodeType>

- <DOType id="SAV" cdc="SAV">
<DA name="instMag" fc="MX" bType="Struct" type="AnalogueValue" />
<DA name="q" fc="MX" bType="Quality" qchg="true" />
<DA name="t" fc="MX" bType="Timestamp" />
<DA name="units" fc="CF" bType="Struct" type="Unit" />
<DA name="sVC" fc="CF" bType="Struct" type="ScaledValueConfig" />
<DA name="min" fc="CF" bType="Struct" type="AnalogueValue" />
<DA name="max" fc="CF" bType="Struct" type="AnalogueValue" />
<DA name="d" fc="DC" bType="VisString255" />
<DA name="cdcNs" fc="EX" bType="VisString255" />
<DA name="cdcName" fc="EX" bType="VisString255" />
<DA name="dataNs" fc="EX" bType="VisString255" />
</DOType>

- <DAType id="AnalogueValue">
<BDA name="i" bType="INT32" />
<BDA name="f" bType="FLOAT32" />
</DAType>
Design proposal

35
The configuration-file above would provide a logical node with the hierarchical view as in
figure 17.

Figure 17: Logical Node

6.4.2 Mapping
The mapping of these data attribute components into OPC items is done in a separate
configuration file that is read by the server. Below is an example of the mapping file.

61850 Logical Device 61850 Leaf OPC server OPC Item IOClass Type
Treg TPOS$MX$Psn$instMag$i Server1 Item1 Class0 Long
Treg TPOS$MX$Psn$instMag$f Server2 Item1 Class1 Float
Table 1: Example file of OPC mapping

The IOClass column in the table defines what class the value shall belong to. The class
defines read/write properties and how often the IEC 61850 server shall update the value from
the OPC server. The Type column defines the type of data the server shall expect from the
OPC Item.
Two Logical nodes and their Data Objects shall be implemented and tested. The definition of
these can be found in Appendix 2 - Definitions. The attribute ASPT.CP.SetPt.setMag.i is
mapped to the item MDINT100 writable. This shall represent the set point value of a
controller.
The attribute TPOS.MX.Psn.instMag.i is mapped non writable to the output value of
MDINT104. This represents the actual output of the controller. Figure 18 shows the
hierarchical view of the data attributes that will be mapped to OPC Items.

Design proposal

36

Figure 18: hierarchical view of the data attributes

The Services to control set-point values and to read data attributes are supported by AX-S4
MMS and is defined by the functional constraint attached for each data attribute. The
TPOS.Psn.instMag.i has the MX attribute for measured values, the ASPT.SetPt.instMag.i also
have the MX attribute. The ASPT.SetPt.setMag.i is a controllable set-point, which is has the
functional constraint SP. From here on MMS notation will be used in the report as the IEC
61850 clients uses that notation. The functional constraint attribute are a part of the attribute
path and dollar signs instead of dots are used, i.e. ASPT$CP$SetPt and TPOS$MX$Psn
To read the attribute with functional constraints MX the get data value service is needed. To
control (i.e. to write to the value) the attributes with functional constraint SP the operate
service is needed.
37
7 Testing the interface
In order to test the design the direct control with normal security service is necessary to
implement in order to write information to the ASPT$SP$SetPt$setMag$i attribute.
According to IEC 61850-8-1 the control model is accessed via the MMS read and write
named variable services. The common data classes (from IEC 61850-7-3) that allow control
operations contain elements with the functional constraint CO (for control) or SP (for set-
point). The control model defined in IEC 61850-7-2 contains additional service parameters
that are conveyed when executing the control. The mapping of control models and services is
accomplished by combining the service parameters and the control elements into MMS
structure type definitions and inserting them as components of the MMS named variable
representing the common data class instance in a logical node. The services are then mapped
to MMS read and write service requests of these inserted components.
The operate service is performed by an MMS write request to the Oper structure. For a
successful request a response+ is sent back to the client, and for a failure a response- is sent
back to the client. The additional parameters that need to be implemented are show in figure
19.

Figure 19: Parameters for operate service

The complete hierarchical view, with only the necessary data attributes of the two logical
nodes is shown below in figure 20.
Test

38

Figure 20: Logical nodes to be implemented

The PLC will run a program with two variables. There are eight switches on the PLC that
represents the values of 0 to 255 binary located on input address 0 (IB0). For each cycle the
PLC reads the input value from IB0. The next step in the program adds the value of a double
integer. The double integer is located in memory position 100 (MD100) and then the result is
stored in the double integer in memory position 104 (MD104). The MD100 and MD104 must
be linked to the OPC server as items, the name for these two items in the OPC server is:
MDINT100 and MDINT104.

MDINT100 are mapped writable to ASPT$SP$SetPt$Oper$setMag$i
MDINT100 are mapped non writable to ASPT$MX$ActualSet$instMag$i
MDINT104 are mapped non writable to TPOS$MX$Psn$instMag$i
The ASPT$CF$SetPt$ctlModel is pre-set to 1 in accordance with IEC 61850-7-2 for direct
operate mode.

The first steps for testing the interface and to make sure that the communication between the
PC station with the IEC 61850 client and the PLC really works is to use the test program.
When no value has been written to ASPT$SP$SetPt$setMag$i the initial value set by the PLC
to MDINT100 is zero. This means that the MDINT104 in the PLC shall be equal to the binary
number represented by the positions of the switches on the PLC. This can be monitored from
the TPOS$MX$Psn$instMag$i in the IEC 61850 client. When the IEC 61850 client uses the
control service to write a value to the ASPT$SP$SetPt$Oper$setMag$i attribute, the PLC
must change the value of MDINT104 to the sum of the binary number represented by the
switches and the value of MDINT100. If this works, the control service must have been
successful since the PLC program can calculate the correct sum from two values, of which
Test

39
one was written to the PLC over an Ethernet bus using IEC 61850 as communication
protocol.
In order to test the functionality from the IEC 61850 server two types of clients is used.
The first client is MMS Object Explorer, this client is bundled with the AX-S4 MMS suite
and the license agreement does not allow installation on more that one computer, this means
that it can be used on the Microbox where the server are located, i.e. the object explorer is
used for testing locally without any network traffic. The second client is the MMSd Test
Client, which is an MMS test client from Tamarack Consulting. This client is used from the
client computer and connects to the Microbox over an Ethernet bus (see figure 16). Below
there are a screenshot from the MMSd test clients showing the data structures and their values
when connected to the server. In the name column in figure 21 the second row named
Treg_testC1/ASPT1$SP$SetPt$Oper shows the values for each parameter that are defined
in the Oper structure.

Figure 21: Screenshot from MMSd Test Client

The results are positive from the testing. Both of the clients can use the GetDataValues
service on the two instMag attributes and the Operate service on the setMag attribute in
accordance with the standard. This means that it possible to map data of 32 bit length integer
(double integer) in the turbine controller into data objects in IEC 61850 of basic type int32.
40
8 Results
The purpose of this master thesis work was to provide technological and economical feedback
on implementation of an IEC 61850 interface for turbine controllers. The technological aspect
of the goals where set to implement and test an interface for IEC 61850 and that has been
completed. An operational server interface for turbine controller has been presented and
tested. The testing of this interface has however only covered the GetDataValue and the
Operate service. The goal from the project specification has been fulfilled as this report
provides a summary of the products that are suitable to select in order to implement 61850 for
turbine controller. The report does also contain design alternatives and results from the testing
of one of the design alternatives.
Economical factors for developing the design proposal into a complete and fully functional
product are not easy to estimate. What the writer can point out is the costs for hardware and
software that will come up if Vattenfall would decide to continue the development of this
gateway design. The prices are presented separately to Vattenfall and not in this report.

41
9 Future work
This chapter will present future work that needs to be done on the tested interface. It will also
provide a discussion regarding future products that might be of interest to test.
9.1 Implemented interface
One of the limitations of the server is that it cannot handle data conversation from local
formats into IEC 61850 encoding. Presentation of the data from the turbine controller must
therefore be in a format expected by the IEC 61850 server. Since the turbine controller does
not use real floating-point numbers but rather integers that are re-calculated into floating point
numbers. This is due to limitations over the Profibus and currently installed equipment, some
routine for converting formats from the local format in the controller into the type that IEC
61850 use as basic types for each data attribute must be implemented in the controller. Or the
problem with the equipment must be solved in order to use real floating-point numbers in the
turbine controller. However it is important to point out that this design actually is an
operational IEC 61850 interface for turbine controllers. This interface does not only cover the
turbine controller but also any kind of controller that holds data that would be of interest to
present for an IEC 61850 client. The limitations are of course the possibilities to find correct
communications network for the OPC server. Siemens equipment uses the proprietary S7
communication over Profibus. It is also possible to use OPC over Ethernet to communicate
with controllers. Since the Microbox has two Ethernet ports, one of them can act as a
dedicated OPC bus, while the other communicates on the station bus. This would make it
possible to communicate with ABB controller equipment as well as the GE Fanuc PLC
systems using one of the Ethernet ports for OPC communication and the other Ethernet port
for communication on the station bus.

Further testing regarding services are required since this project only tested a few services.
Other control services than Operate should be tested, today there are some limitations to the
control services. Only direct control with normal security and Select Before Operate
(SBO) control with normal security is implemented in AX-S4 MMS. The Operate service is
supported for both direct and SBO control, but the time activated operate service is not
supported. The optional report is not generated in either case.
Performance of the server has not been tested in this work. This would be an interesting are
for future work with the server. Also a test with a device that gets control values using an IEC
61850 client from the gateway is of interest.
An important aspect regarding supported services and the functionality of the AX-S4 MMS
IEC 61850 Server is that the version used and tested is only a beta version. The first official
version might add functionality that is not there yet.
Some bugs were found during the implementation that are worth mentioning for
documentation. The server does not work if the system time in Windows is set east of GMT,
this is a known bug from SISCO. Also the ASPT$SP$SetPt$t attribute, which is the time
stamp attribute for ASPT$SP$SetPt$Oper$SetMag is not found and mapped by the server.
This has to do with the algorithm that locates the time stamp attribute for controlled values.
42
9.2 Future products
The ambition from the beginning of this work was to implement the interface directly in the
PLC or in a separate communication processor. Due to restrictions from Siemens to access
their development environment this was not possible. Therefore the PC based gateway design
is the best choice. The work done by Siemens I&S to implement an IEC 61850 client based
on Step 7, does however prove that it should be feasible to implement the communication
stack used by IEC 61850 in a Simatic PLC. If this is economically or technologically
beneficial instead of basing a future implementation in the PLC on the source code
implementations of IEC 61850 is not answered by this report. During discussions of
requirements with external experts, the general opinion was that it is not cost effective to
implement this in a Simatic PLC using Step 7. It is even not for certain that it is
technologically feasible to implement the server application in the Simatic environment using
a high-level programming language like ST. This is something that needs to be further
investigated. In order to get the interface directly into the controller the option is to migrate
the turbine controller to the Microbox running a WinAC RTX environment and a
communication application on the Windows environment (see chapter 5.3.1). This solution
would utilise the Simatic S7-300 for communication with hard-wired I/Os and the Microbox
is running the controller application and the communication over the Ethernet bus.
Today Siemens Automation and Drives have no interest in the development of an IEC 61850
server for PLC systems, since there is no market for this type of application. Siemens
promotes the SICAM PAS system as their solution of IEC 61850 communications, but this
computer only feature an IEC 61850 client for communication with distributed servers located
in field devices.
Options that include in-house development of the turbine controller with an integrated
interface include changing vendor of automation equipment. Automation Direct offers a PLC
line DL-205 with an optional CPU unit based on a 100Mhz processor and 8Mb of RAM, and
communication with I/Os using the backplane bus. The operating system of the WinCPU unit
is Windows CE, which would be a suitable environment for Sisco or Tamarack software.
Probably most of the controlling routines for the turbine controller would need to be
reprogrammed to suit the new PLC. This however would be a controller with enough
resources for controlling tasks and IEC 61850 communication tasks. The possibilities to use
this controller with installations of treg 1.0 would be limited, as this PLC is not compatible
with the I/O cards that are installed today. Also there would be a need for two developments
lines, one gateway design for existing turbine controllers and one controller design for
upcoming installations.
Within the next years when the information model for hydro power plants are released the
vendors will for sure be more interested in developing solutions for PLC systems by
themselves.
ALSTOM Power is currently running a master thesis work for investigating and testing an
implementation of IEC 61850 using the Tamarack software into their soft logic PCX
controllers. The result of this work is presented sometimes during April or May. When the
results of that work are concluded ALSTOM Power will start the implementation of an IEC
61850 interface on the soft logic PCX controller. This controller could prove to be a very
interesting for future turbine controllers and station/unit computers.
As of today most vendors of PLC equipment that where contacted during the investigation
phase didnt seem to have a very big interest of developing products for IEC 61850 for PLC
equipment. This is because there is no market today for substation automation using standard
PLC automation equipment. ABB and VA-TECH have shown interest in developing their
own IEC 61850 servers for their PLC automation equipment in the future. Both companies
Future products


43
seem to have interest in doing so. VA-TECH are a large supplier of hydro power plant
automation and are members of the IEC group specifying the information model for hydro
power plants have controllers that according to their own statement are suitable for an IEC
61850 implementation and they will implement this in their turbine controller that are
delivered with their solution for hydro power plant automation.
ABB are currently running a project for developing a communications module for AC 800M
controller equipped with an IEC 61850 server for GOOSE messaging between substation
protection devices and PLC automation products using the MMS EASE-Lite source code.
This step was initiated by ABB after demands by their customers to integrate the PLC
equipment with the controlling and protection devices for substations. It would be reasonable
to assume that ABB would develop this product into a complete server for messaging on
station bus if there are demands/interests from their customers. ABB also offers customer
financed development of products. This would make it possible for Vattenfall to order a
communication card for use with PLC systems.

In the future there will be alternatives of controllers capable of communicating with IEC
61850 both for station bus and for process bus. If these are freely programmable like a PLC
system and the user can link any parameter in the PLC:s memory register into any data object
of IEC 61850 or if they will have a pre-defined set of functions that will produce the
information defined in IEC 61850 is unknown and the vendors seems to yet not have taken
the decision of how to implement these controllers.
44
10 References to external experts
Fred Steinhauser, Product Manager, Omicron (Austria), European reseller of Tamarack
Consulting products, fred.steinhauser@omicron.at
Mr. Steinhauser has provided information regarding the software products from
Tamarack Consulting.
Ralph Mackiewicz, Vice President SISCO (USA), ralph@sisconet.com
Mr. Mackiewicz has provided information regarding software products from
SISCO INC.
Samuel Wenz, Siemens I&S (Germany), samuel.wenz@siemens.com
Mr. Wenz has developed the client for communication between S7-400 PLC
systems and Siprotec relays.
Kenneth Quinteros, Promotor, Siemens Automation and Drives (Sweden),
kenneth.quinteros@siemens.com
Mr. Quinteros has provided information regarding Simatic products and OPC
communication.
Urban Nygren, ABB (Sweden), urban.nygren@se.abb.com
Kenneth Fridholm, ABB (Sweden), kenneth.fridholm@se.abb.com
Rolf Setthammar, ABB (Sweden), rolf.setthammar@se.abb.com
M.r Setthammar has provided information regarding ABBs project with the
development of a communication card for the AC 800M PLC system.
Anders Ramberg, Sales Engineer, Siemens (Sweden), anders.ramberg@siemens.com
Tony Knutsson, VA-TECH SAT (Denmark), TPK@sat-automation.com
Jenz Putz, Marketing Manager SAT VA-TECH (Austria), jens.paeutz@sat-automation.com
Alfred Maschka, AMA-Systems (Germany), European reseller of SISCO and Direct
Automation products.
Mr. Maschka has provided information regarding PLC products from
Automation Direct, and information regarding the software products from
SISCO.
Irmhild Maschka, President of AMA-systems (Germany), maschka@ama-systems.de
John Bruder, Development Engineer, SISCO (USA), johnb@sisconet.com
Mr. Bruder has provided support for the implementation of AX-S4 MMS.
Denise Patrishkoff, Technical Service Coordinator, SISCO (USA), denise@sisconet.com

45
11 References for articles and manuals
[1] Hans Berger, Automating with Simatic, 2003, ISBN 3-89578-223-8
[2] Siemens, Communication with Simatic, 1997, ordering # 6ES7 398-8EA00-8BA0
[3] Siemens, NCM for Industrial Ethernet Manual, 2003, ordering # C79000-G8976-
C129-07
[4] Cisco, Introduction to Internet,
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/introint.htm. 26/10-05
[5] Ralph Mackiewicz, An Overview to the Manufacturing Message Specification, 1994
http://www.baetzler.de/nwapps/mms.html 16/3-06
[6] ABB, Introduction and configuration, ABB Manual. Document # 3BSE035980R4101
[7] Simatic Webpage, www.siemens.com/simatic
[8] ABB Webpage, www.abb.com/substationautomation
[9] Jan Gugala, Nsta generations informations- och styrsystem fr Vattenfall Vattenkraft,
2004.
[10] PRAXIS Profiline, 2005: IEC 61850 Volume D/E
[11] Siemens, Industrial communication with PG/PC, 2003, ordering #: C79000-G8976-
C172
[12] Network protocol suite directory index, http://www.javvin.com/protocolsuite.html 27/3-
06
1
Appendix 1 - IEC 61850
The IEC 61850 series of standards was initially focused on protection and substation
automation. It has now also become the most important standard for the future supply of
electric power outside the substation i.e. hydropower stations, wind power plants, etc.

The IEC 61850 series of standards is a powerful solution, compared to old standards, because
it takes all the various aspects that are common in a substation in consideration. It covers
general requirements relating to substations, engineering, data models, communication
solutions and conformity testing. It provides a uniform framework for all of the three typical
system levels, in other words between the process level, device level and the station level.

The standard is composed of 14 parts (documents) that together cover all the requirements
that has to be fulfilled by a substation automation system. During 2005 all parts of the
standard have been issued as official IEC standards. The complete set of the standard can be
seen as a toolkit, which can be used to design open substation automation systems.

Through the supplement of new parts to the existing document series, the standard can be
expanded to cover other areas within a power station system. This characteristic is very
interesting for this study where the standard is going to be expanded by the document, IEC
62344, to also cover data modeling in hydroelectric power plants.


Below a short summary of all 14 parts of the standard is given:

IEC 61850-1, Introduction and Overview: This part gives an introduction to IEC
61850 and a general outline over all parts of it.

IEC 61850-2, Glossary: This part contains the glossary of specific terminology and
definitions used in the context of Substation Automation Systems within the various
parts of the standard.

IEC 61850-3, General Requirements: This part defines quality requirements
(reliability, maintainability, system availability, probability, IT security), operating
conditions, auxiliary services and other engineering standards.

IEC 61850-4, System and Project management: This part defines engineering
services requirements (parameter classification, engineering tools, documentation),
system usage cycle (product versions, factory setup, support after factory setup),
quality assurance (responsibilities, test systems, type sets, system sets, factory
acceptance tests (FAT), site acceptance tests (SAT))

IEC 61850-5, Communication Requirements for Functions and Device Models:
This part describes the logical node principle, logical communication links, items of
information for communication (PICOM), logical nodes and associated PICOMs,
functions, performance requirements (response times, etc.), dynamic scenarios
(information flow requirements under various operating conditions).

IEC 61850-6, Configuration Description language for Communication in
Electrical Substation: This part of the IEC 61850 series specifies a file format for
Appendix 1 - IEC 61850

2
describing communication related IED configurations and IED parameters,
communication system configurations, switchyard (function) structures, and the
relations between them. The main purpose of this format is to exchange IED
capability descriptions, and SA system descriptions between IED engineering tools
and the system engineering tool(s) of different manufacturers in a compatible way.
The defined language is called Substation Configuration description Language (SCL).
It is based on the Extensible Markup Language (XML) version 1.0. The IED and
communication system model in SCL is according to IEC 61850-5 and IEC 61850-7-
x.

IEC 61850-7-1, Basic Communication Structure for Substation and Feeder
Equipment: This part of the IEC 61850 series introduces the modeling methods,
communication principles, and information models that are used in the parts of IEC
61850-7-x. It provides explanations and provides detailed requirements relating to the
relation between IEC 61850-7-4, IEC 61850-7-3, IEC 61850-7-2 and IEC 61850-5.
This part also gives an overview of how the abstract services and models of IEC
61850-7-x are mapped to concrete communication protocols as defined in IEC 61850-
8-1.

IEC 61850-7-2, Basic Communication Structure for Substation and Feeder
Equipment - Abstract Communication Service Interface (ACSI): This part of IEC
61850 describes and specifies the Abstract Communication Service Interface (ACSI)
for use in the utility substation domain that require real-time cooperation of intelligent
electronic devices. The ACSI has been defined so as to be independent of the
underlying communication systems. Specific communication service mappings
(SCSM) are specified in part 8-1, 9-1 and 9-2 of this standard. The ACSI description
technique abstracts away from all the different approaches to implement the
cooperation of the various devices. Example of ACSI services that is described are
reporting, logging, setting, getting, publishing/subscribing etc.

IEC 61850-7-3, Basic Communication Structure for Substation and Feeder
Equipment - Common Data Classes (CDC): This part defines common attribute
types and common data classes related to substation applications. These common data
classes are used in IEC 61850-7-4. To define compatible data classes, the attributes of
the instances of data shall be accessed using services defined in IEC 61850-7-2.

IEC 61850-7-4, Basic Communication Structure for Substation and Feeder
Equipment - Compatible logical node classes and data classes: In this part general
and typical station classes for logical nodes and data are defined. All data are defined
with regard to syntax and semantics. This is required to reach interoperability
between the IEDs.

IEC 61850-8-1, Specific Communication Service Mapping (SCSM) - Mapping to
MMS (ISO/IEC 9506-1 and ISO/IEC 9506-2) and ISO/IEC 8802-3: In this part
the communication mapping in the entire station is described (client/server
communication for SCADA functions and GOOSE and GSSE data exchange for real
time requirements, for example tripping signals).

IEC 61850-9-1, Specific Communication Service Mapping (SCSM) - Sampled
Values over serial unidirectional multidrop point to point link: In this part the
Appendix 1 - IEC 61850

3
SCSM for point-to-point, unidirectional communication of sampled values from
transformers (with and without Merging Unit) is described.

IEC 61850-9-2, Specific Communication Service Mapping (SCSM) - Sampled
values over ISO/IEC 8802-3: In this part the SCSM for bus-type, flexible
communication of sampled values from instrument transformers (with and without
Merging Unit) is described.

IEC 61850-10, Conformance Testing: This part of IEC 61850 specifies standard
techniques for testing of conformance of implementations, as well as specific
measurement techniques to be applied when declaring performance parameters. The
use of these techniques will enhance the ability of the system integrator to integrate
IEDs easily, operate IEDs correctly, and support the applications as intended.

These 14 documents define together the following four key aspects which are independent of
each other and which build on one other [10]:

1. Standardized information: for intelligent devices: units, measured values,
control, metadata, etc. including self description. Standardized information is
based on a general set of about 20 common data types. Some standardized
information is specific to substations, and other information is more general.
Standardized information gives advantage because engineering and validation
can be highly automated, and interoperability is dramatically improved,
because among other things the consistency of the data model can be checked
at both ends of a connection (in the IED and in the higher-level system).

2. Standardized services: for simple data access, reporting, logging, querying,
device control etc. The standardized services can be used with standardized
information or with any new or extended information models.

3. Standardized networks: Suitable networks are selected for exchanging
messages in the strict sense of the term. Standardized communication systems
are used for the standardized services, standardized information and any other
type of information.

4. Standardized configuration: A complete, formal description is generated for
the devices and the entire substation. IEC 61850-6 defines an XML-based
system description language, which is used to generate configuration files.
These files can be interpreted by the devices themselves or by the
configuration tool, which belongs to a device, and by a system configuration.

Appendix 1 - IEC 61850

4

Figure 22: The four key aspects of IEC 61850.
As seen from figure 22 above standardized information models, a set of suitable information
exchange mechanisms for use in a real-time environment and state-of-the-art communication
applications provide the framework for interaction at the user level, in other words
interoperability, to an extent that has never been possible before.
The ACSI-model
The IEC 61850 series defines the information models and information exchange services in a
way that it is independent of a concrete implementation (i.e. it uses abstract models). This is
done by an object-oriented concept called Abstract Communication Service Interface (ACSI),
which is the subject of IEC 61850-7-1, IEC 61850-7-2, IEC 61850-7-3 and IEC 61850-7-4.
Abstract means that the definition is focused on the description of what the services provide
2
.
The concrete implementation is achieved through the Specific Communication Service
Mappings (SCSM), which is defined in IEC 61850-8-1, 61850-9-1 and 61850-9-2.
The ACSI comprises thus the first and second of the four key aspects of IEC 61850, described
in figure 22 above, which corresponds to standardized data and standardized services. The
textbox below summarizes the content of ACSI.

2
Abstraction in ACSI has two meanings. First only those aspects of a real device (for example, a breaker) or a
real function that are visible and accessible over a communication network are modelled. This abstraction leads
to the hierarchical class models and their behaviour defined in IEC 61850-7-2, IEC 61850-7-3 and IEC 61850-7-
4. Second, the ACSI abstracts from the aspect of concrete definitions on how the devices exchange information;
only a conceptual cooperation is defined.
Appendix 1 - IEC 61850

5



The ACSI is a very useful architecture, because the services are independent of the
information content and the communication protocol. Using this approach, IEC 61850
remains open for additional useful and advanced protocols, which may be used on a
widespread basis in the automation world in the future [10].
The information models and information exchange services are interwoven. The services are
strongly dependent of the information models, because it is the information model that
specifies what services that can be done on a specific device.
The class diagram, together with class definitions, below gives an entirety picture of the ACSI
model.


The ACSI is defined in terms of:

A hierarchical class model of all information that can be accessed via a
communication network.
Services that operate on these classes.
Parameters associated with each service.

Appendix 1 - IEC 61850

6

Figure 23: Conceptual service model of the ACSI.

Definition of the conceptual models to build the domain-specific information models:

Each of these information models (server, logical node, logical device and data) comprises
attributes and services (reporting, logging etc.).

SERVER represents the external visible behavior of a device. All other ACSI models are
part of the server.

LOGICAL-DEVICE (LD) contains the information produced and consumed by a group of
domain-specific application functions; functions are defined as LOGICAL-NODEs.

LOGICAL-NODE (LN) contains the information produced and consumed by a domain
specific application function, for example, over voltage protection or circuit breaker.

DATA provide means to specify typed information, for example, position of a switch with
quality information and timestamp, contained in LOGICAL-NODEs.

Appendix 1 - IEC 61850

7
DATA-SET permits the grouping of data and data attributes. Used for direct access and for
reporting and logging.

Definition of the conceptual models of the service models:

Substitution supports replacement of a process value by another value.

SETTING-GROUP-CONTROL-BLOCK defines how to switch from one set of setting
values to another one and how to edit setting groups.

REPORT-CONTROL-BLOCK and LOG-CONTROL-BLOCK describe the conditions
for generating reports and logs based on parameters set by the client. Reports may be
triggered by changes of process data values (for example, state change or dead band) or by
quality changes. Logs can be queried for later retrieval. Reports may be sent immediately or
deferred. Reports provide change-of-state and sequence-of-events information exchange.

control blocks for generic substation event (GSE) supports a fast and reliable
system-wide distribution of input and output data values; peer-to-peer exchange of IED binary
status information, for example, a trip signal.

control blocks for transmission of sampled values fast and cyclic transfer of
samples, for example, of instrument transformers.

control describes the services to control, for example, devices.

time and time synchronization provides the time base for the device and system.

file transfer defines the exchange of large data blocks such as programs.
Data modelling
The goal of the IEC 61850 series is to provide interoperability between IED's from different
vendors or, more precisely, between functions to be performed in a substation but residing in
equipment (physical devices) from different vendors. The information exchange mechanisms
rely on well-defined information (data) models. These information models and the modelling
methods are at the core of IEC 61850 series.

The IEC 61850 series defines the information and information exchange in a way that it is
independent of a concrete implementation (i.e., it uses abstract models - ACSI). The standard
also uses the concept of virtualisation. Virtualisation provides a view of those aspects of a real
device that are of interest for the information exchange with other devices. Only those details
that are required to provide interoperability of devices are defined in the IEC 61850 series.

Several different physical devices are often used together in a power station system to
perform a specific functionality. This kind of functionality is called distributed functionality
and the devices involved are called distributed devices. If a distributed functionality is going
to work correctly it is required that the involved devices communicate with each other in a
standardized manner.

In IEC 61850 series functionalities that the real devices comprise are decomposed into the
smallest entities, which are used to exchange information between different devices. These
Appendix 1 - IEC 61850

8
entities are called logical nodes. The logical nodes are the virtual representation of the real
functionalities. The intent is that all data that could originate in the substation can be assigned
to one of these logical nodes. Several logical nodes from different (real-) devices build up a
logical device (which is a virtual device). A logical device is always implemented in one IED,
therefore logical devices are not distributed.

Logical devices, logical nodes and data objects are all virtual terms. They represent real data,
which is used for communication. One device (for example a control unit) only communicates
with the logical nodes or its data objects of another device (for example an IED). The real
data, which the logical nodes represent, are hidden and they are not accessed directly. This
approach has the advantage that communication and information modelling is not dependent
on operating systems, storage systems and programming languages [10]. The concept of
virtualisation is shown in figure 24 below, where the real device on the right hand side is
modelled as a virtual model in the middle of the figure
3
. The logical nodes (for example
XCBR) defined in the logical device (Bay) correspond to well known functions in the real
devices. In this example the logical node XCBR represents a specific circuit breaker of the
bay to the right.


Figure 24: Virtual and real world.


Based on their functionality, a logical node contains a list of data (for example, position) with
dedicated data attributes. The data have a structure and a pre-defined semantic. The
information represented by the data and their attributes are exchanged by the communication
services according to the well-defined rules and the requested performances.

To illustrate more clearly how the logical devices, logical nodes, classes and data concepts
map to the real world, imagine an IED as a container.


3
Figure 24 is an excerpt from IEC 61850-7-1. It also shows what parts of the standard that is of interest for this
thesis work.
Appendix 1 - IEC 61850

9

Figure 25: Physical and logical device.


The container is the physical device, which is containing one or more logical devices. Each
logical device contains one or more logical nodes, each of which contains a pre-defined set of
data classes. Every data class contains many data attributes (status value, quality etc.).
Before explaining the data-modelling concept deeper, it is one more time worth to notify that
the logical devices, logical nodes and data objects are virtual, which means that they merely
seem to exist. The logical nodes and the data contained in the logical devices are crucial for
the description and information exchange for power station automation systems to reach
interoperability.

Logical devices
One physical device can be divided into one or more logical devices. A multifunction device
used to control and protect a bay can be a complex logical device as well. The logical nodes
are sub-functions in the logical devices.

A logical device consist of a minimum of three logical nodes, i.e. the LN with the core
functionality itself, the process interface LN and the HMI LN meaning human access to the
function.

Figure 26: Logical Device (LD) class definition, from IEC 61850-7-2.
The logical device contains at least three Logical Nodes. Two of the LLN0 and LPHD are
specific to the logical device and describes information about the physical device and are used
Appendix 1 - IEC 61850

10
to model common issues for the logical device, for more information see IEC 61850-7-4. A
logical device also always contains at least one domain specific logical node these are defined
in IEC 61850-4. The common logical node is defined in figure 28. The LDName defines the
Logical device, this could for instance be LDName.

Logical Nodes
Logical nodes are grouped according to the logical node groups listed in Table 2. About 90
logical nodes covering the most common applications of power stations and feeder equipment
are defined. All of the logical nodes have been defined in a joint effort of domain experts of
the various substation application domains and modeling experts. The names of logical nodes
begin with the character representing the group to which the logical node belongs.

IEC 61850 lays down clear rules relating to extensions of the information models, including
extensions to logical nodes, new logical nodes, expanded and new data and new data
attributes [10].

The intent is that all data that could originate in the substation can be assigned to one of these
groups

Group Indicator Logical node groups Number
A Automatic Control 8
C Supervisory Control 5
G Generic Function References 3
I Interfacing and Archiving 4
L System Logical Nodes 3
M Metering and Measurement 8
P Protection Functions 28
R Protection Related Functions 10
S Sensors and Monitoring 4
T Instrument Transformer 2
X Switchgear 2
Y Power Transformer 4
Z Further (power system) Equipment 15
TOTAL 92
Table 2: Groups of Logical nodes

Logical nodes have a hierarchical structure. The data within the logical node classes are
grouped into various categories for the convenience of the reader (see figure 27 below). This
grouping may result in some overlapping.

Appendix 1 - IEC 61850

11

Figure 27: Logical node model.


The standardization of functions in substations is not within the scope of the IEC 61850
series. But if any of these functions is used, its communication shall be based on the LN
structure
4
.

4
The Logical Nodes are described in IEC 61850-5 clause 11.
Appendix 1 - IEC 61850

12

Figure 28: Logical Node (LN) class definition, from IEC 61850-7-2.
The LN class definition shows the structure of a common logical node. The Data and Datasets
that is held by it is defined by its use, this is documented in IEC 61850-7-4. The LNName is
inherited from the logical device, for a common node this could be LDName\LNName.

Data classes
In IEC 61850 there are basic types of data like Boolean and integers (BasicTypes) that
contains values, they form the PrimitiveComponents and the CompositeComponents. The
PrimitiveComponents shall have a name, presence, and a BasicType. The composite
components, are built by one ore more primitive components (see figure 29) of basic type.
Together the primitive and composite component form the data attribute type (DAType)
Appendix 1 - IEC 61850

13

Figure 29: Class diagram of DATA and Data Attribute.

The DATA is a class that has a Data name, a presence and DataAttributes. The DataAttributes
are used to form a simple common data class (SimpleCDC) and the composite common data
class (CompositeCDC). The CompositeCDC is constructed by on or more SimpleCDC and or
DataAttributes. Figure 30 shows an example of Data classes, data components and data
attributes.
Appendix 1 - IEC 61850

14

Figure 30: Example of DATA, from IEC 61850-7-2.

Data Class Definition

Figure 31: DATA class definition, from IEC 61850-7-2.
Data class definition shows the recursive structure of DATA. The DataName is inherited from
the LN that DATA is held by. The ObjectReference could be
LDName\LNName\DataName[.DataName], this could be more than one name if its
recursive.

Appendix 1 - IEC 61850

15
Data attributes

Figure 32: DAType definition, from IEC 61850-7-2.
The DAType definition shows the structure of the Data attribute type. The DATRef is
inherited from classes from which the DAType is derived. The presence is mandatory or
optional. The data attribute type contains composite components data types or primitive
components.

Functional Constraint
From an application point of view, the data attributes are classified from their specific use.
The functional constraint (FC) shall be a property of DA characterising the specific use.
Specific use is properties like, controlling purposes, reporting, and logging. The FC governs
the services allowed to act on the DA.

Trigger option
The trigger option (TrgOp) specifies the conditions for an event to occur. This can be for
instance, a report to be sent or a log to be stored. The TrgOp is data change, quality change or
data value update. When the TrgOp for a monitored DA or data set is fulfilled the control
block with the TrgOpEna that equals the TrgOp in the LD is triggered.
Appendix 1 - IEC 61850

16

Figure 33: Trigger option and reporting

Common Data Classes (CDC)

Figure 34: Common data class definition, from IEC 61850-7-2.
The Common data class is a subclass used to define the compatible data classes.
Compatible Data Classes
The data defines a class that is specialised in IEC 61850-7-3 to define the common data. IEC
61850-7-4 specialises the common data to define the compatible data, the relation is shown in
Figure 35.
Appendix 1 - IEC 61850

17

Figure 35: relation of data class.

Data set
A Data set is a ordered group of object references of data or data attributes (known as data set
members), organised as a single collection for convenience for the client. The object
references shall be known to both the server and the clients so that only the name of the data
set and the values needs to be transmitted. There are two types of data sets, a persistent and a
non-persistent instance of data set. The persistent instance of data set shall be visible to clients
of any two party application association. Non-persistent instances shall only be visible to the
client that created the data set. Pre-configured data sets shall be visible to clients of any two
party application association and shall be non-deletable.

Figure 36: Data set definition
Communication services
The ACSI model basically provides the methods of exchanging information between devices
as shown in figure 37.

Appendix 1 - IEC 61850

18

Figure 37: Information flow and modelling.

There are two different groups of communication services within ACSI, which are depicted in
figure 38 below. One group uses a client/server model with services like control or get data
values. A second group comprises a peer-to-peer model with GSE services (used for time-
critical purposes, for example, fast and reliable transmission of data between protection IEDs,
from one IED to many remote IEDs) and with the sampled value transmissions based on a
periodic basis.



Figure 38: ACSI communication methods.
Appendix 1 - IEC 61850

19


These two groups of communication services are defined from the application association
model.
Application Association model
The application association model presents the provisions on how communication between
several IEDs is achieved. The model describes two different methods for application
association (communication), which are the two-party application association (client/server)
and multicast application association (GOOSE, SV). The application association model also
comprises the access control concept that specifies how to restrict access to instances in a
server.

The two party application association defines the services provided for managing association
between client and server. The multicast application association defines the services provided
for managing associations for multicast messaging, for example GOOSE and transmission of
sampled values. Before a deeper description of these association models is given the access
control concept will be described.

Access control (Virtual Access View)
Several functionalities in a plant automation system (PAS) are performed through the
interaction of distributed devices. This conveys that a certain device should have access
permission to certain data or services in other devices and vice versa. There should also be
different access schemes defined that restricts the "visibility" of a device particular data of a
device. An operator may for example not be allowed to change protection settings. All these
features are provided in ACSI through a virtual concept called access control model. The
device information is described as being a part of a server and the other devices that accesses
data inside it are interpreted as clients.

The access control model provides the capability to restrict the access of a specific client to
class instances, class instance attributes, and ACSI services acting upon class instances of a
specific server. The set of instances visible (and therefore accessible) for a client is restricted
on the basis of the identification of the client and the access control specification of the server.
This restricted set is called a virtual access view. A virtual access view may not only restrict
the visibility of instances or attributes but also the supported service. The virtual access view
can be used to describe and represent the complete behaviour of a device. Any other devices,
another controller or even a SCADA system, a maintenance system, or an engineering system
may use the ACSI services to interoperate with that device. A received service request is
independent of the device that has requested the service. The concept of virtual access view is
illustrated in figure 39 below.

Appendix 1 - IEC 61850

20

Figure 39: Access view of a server.
In figure 39 above two users have different virtual access views of the server. View 1 allows
just one data (XCBR.OperCnt) to be accessed remotely. View 2 allows all data to be
accessed. The intention of IEC 61850 is to implement the virtual access view in the server of
a device, thus providing access restriction to any user who tries to access the instances.
Independent of the implementation in the device, additional access restriction may be
implemented at the user side, for example, local password or simply a key on the keyboard.

A client shall be identified by authentication parameters passed to the server when
establishing the association with the server or when sending the information over multicast
application association. The details of access control including structure and content of
authentication parameters are supposed to be specified by the specific communication system
that is used.

Two-Party-Application-Association (TPAA)
A bi-directional connection-oriented information exchange between two applications is
referred to as two-party application association (TPAA). The TPAA shall be reliable and the
information flow shall be controlled end to end. Reliable means that the connection on which
the application association relies provides measures to notify reasons for non-deliverance of
information in due time. End-to-end flow control means that sources of information do not
send more information than the destination can buffer.

The class definition of the TPAA is given in figure 40.


Figure 40: TPAA.
Appendix 1 - IEC 61850

21
Description of the services of TPAA:
Associate: Establish an association.
Abort: Abort an association.
Release: Release an association.

TPAA is most common in the station buses of a PAS through the client/server
communication, which will be described below.
Client/Server communication
This chapter describes the client/server communication.
Server
The server contains everything that is defined to be visible and accessible from the
communication network, which are the content of a logical device (logical nodes, data, data
sets, reports etc.), the association model, time synchronisation and file transfer.

Figure 41: Sever building blocks.

The association model provides mechanisms for establishing and maintaining connections
between devices and to implement access control mechanisms. Time synchronization
provides the accurate time for time tagging (ms range) in applications such as reporting and
logging or for applications such as synchronized sampling (s range). A physical device may
host one or more server.

Client/Server
Figure 42 below illustrates the client/server role. Clients issues service requests and receive
confirmations of the service that has been processed in the server. A client may also receive
report indications from a server. All service requests and responses are communicated by the
protocol stack that is being used by a SCSM.

Appendix 1 - IEC 61850

22

Figure 42: Service exchange.

Figure 43 below shows an example of a get service that enables a client to retrieve the values
of the data inside the server.


Figure 43: Information exchange.

The standard defines just the server role; the logical nodes, data, control, etc. located in the
server (see figure 41), and the service request exchanged. Clients are not described in the
standard they play a complementary roll. In practice a client is a device that issues a service.
Most of the ACSI services belong to the client/server category. The TPAA links the clients
and the servers. It ensures that data can be reliably transferred via any underlying network
[10]. A device can be a client to one device while it is a server to another device, which is
illustrated below in figure 44.

Appendix 1 - IEC 61850

23

Figure 44: Client and server roll of the device.

When two devices exchange information with each other from an application point of view
(according to the standard), it is actually the logical nodes of the devices that exchange data.
The logical nodes in that sense comprise the data and control as well as the client and server
role. From an application point of view the server and the client are not needed. Therefore, the
logical nodes can be understood as being in communication with one another. This view is
just a matter of abstraction. The logical node view and the communication view are two
different views of the very same real subject. The logical node view is illustrated in figure 45
below.


Figure 45: Logical nodes in devices.

Services provided
The services are requested after an association between the client and the server is established.
The client requests the service and sends request specific parameters to the server, which in
turn responds to the request ether positively or negatively. Table 3 below shows what type of
parameters that are sent for each service.

Appendix 1 - IEC 61850

24
Parameter
Name

Applies for
Service and description
Request Positive response
(Response+)


Negative
Response
(Response-)
Logical Device
GetLogicalNodeDirectory Retrieve list of object references of all logical nodes contained in the
logical device
LDReference LNReference[3..n] ServiceError
Logical Node
GetLogicalNodeDirectory Retrieve object reference of a specific ACSI class contained in the logic
node
LNReference
ACSIClass
InstanceName[0..n] ServiceError
GetAllDataValues Retrieve all data attribute values of all data contained in the logical
node
LNReference
FunctionalConstraint[0..1]
LNReference
DataAttributeReference[1..n]
DataAttributeValue[1..n]
ServiceError
Data class
GetDataValues Retreive values of data contained in the logical node
Reference DataAttributeValue[1..n] ServiceError
SetDataValues Write values of data contained in the logical node
Reference
DataAttributeValue[1..n]
[blank] ServiceError
GetDataDirectory Retrieve object references of all data attributes contained in data
DataReference DataAttributename[1..n] ServiceError
GetDataDefinition Retrieve definitions of all data attributes contained in data
DataReference DataAttributeDefinition ServiceError
Data set
GetDataSetValues Retrieve all values of data referenced by the members of the data set
DataSetReference DataSetReference
DataAttributeValue[1..n]
ServiceError
SetDataSetValues Write all values of data referenced by the members of the data set
DataSetReference
DataAttributeValue[1..n]
Result ServiceError
CreateDataSet Create a data set by providing the functionally constrained data
references or that form the data set.
DataSetReference
DSMemberRef[1..n]
[blank] ServiceError
DeleteDataSet Delete a data set
DataSetReference [blank] ServiceError
GetDataSetDirectory Retrieve functionally constrained data references of all members
referenced in the data set
DataSetReference DSMemberRef[1..n] ServiceError
Table 3: Parameters for services.

Figure 46 shows an example of the services for data classes.
Appendix 1 - IEC 61850

25

Figure 46: Overview of data class services

Reporting
The server sends, spontaneously or in connection to different events, reports of information to
the client upon several trig conditions. These kinds of reports are based on change in the data
objects and on the Report Control Block (RCB), which controls reporting depending on the
attribute settings. Internal events that can trigger (initiate) reports are:

data change (dchg, property of the data attribute)
data update (dupt, property of the data attribute)
quality change (qchg, property of the data attribute)
integrity period (Report Control Block attribute)
general interrogation (Report Control Block attribute)

This information is grouped using a data set. The data set is the content basis for reporting and
logging. The data set contains references to the real data (and data attribute values) and it
specifies which data are to be monitored and reported. The real data values are conceptually
monitored by the event monitors. An event monitor determines, on the basis of the state of the
real data and the attributes of the control class, when to inform the handler of the occurrence
of an internal event. The report handler decides when and how to send a report to the
subscribed client. This is illustrated in figure 47.

Appendix 1 - IEC 61850

26

Figure 47: Basic building blocks for reporting and logging.































The next task is to define when and how to report the information. The reporting model
provides two kinds of RCBs:

1. Buffered Report Control Blocks (BRCB), and
Example that shows how the data sets references data and data attribute:

The data attribute stVal (status value) of the data MyLD/XCBR1.Pos (position) in
the figure below is referenced in two different data sets. The figure displays two
different instances of data sets that reference the data attributes of the position. In
the case on the left, the data set references 9 individual data set members (all of
functional constraint ST): Pos.stVal is one of the nine members. In case of the
change triggered by the member stVal, the value for exactly that member shall be
included in the report. The data set in the example on the right hand side has just
two members. The data Pos (which has six data attributes: stVal, q, t, etc.) is one
of the two members. A change triggered in the member Pos (for example, by the
change in the DataAttribute stVal) shall cause the inclusion of the values of all
data attributes of the data set member Pos (i.e., the complete member comprising
all six data attributes stVal, q, t, etc.).


Appendix 1 - IEC 61850

27
2. Unbuffered Report Control Blocks (URCB).

Both buffered and unbuffered reporting starts with the configuration of the report control
blocks. The reporting starts with setting the enable buffer attribute to TRUE; setting to
FALSE stops the reporting.


Figure 48: Buffered report control block (conceptual).
The specific characteristic of the BRCB is that it continues buffering the event data as they
occur according to the enabled trigger options in case of, for example, a communication loss
such that values of data are not lost. The reporting process continues as soon as the
communication is available again. The BRCB guarantees sequence-of-events (SoE) up to
some practical limits (for example, buffer size and maximum interruption time).

The URBC does not support SoE. Internal events (trigger conditions) issue immediate sending
of reports on a "best effort" basis. If no association exists, or if the transport data flow is not
fast enough to support it, events may be lost.

The server can be pre-configured or configured remotely by activating RCB instances to
report only the changed data values since the last report or to send all data values of an
application specific set of data when certain conditions are met (for example, data change or
cyclic). The report control continuously reports data values without further client actions. A
client may remotely disable the issuance of further reports to this client. Several clients can
receive the same data, in which case an instance of the RCB must be defined for each client
5
.
A client may also initiate a general interrogation at any time to receive all data values of an
application specific set of data.

An example of the reporting model is given by figure 49.


5
How to define an instance of the RCB for each client is defined in 76 of IEC 61850-7-2
Appendix 1 - IEC 61850

28

Figure 49: Reporting.
Logging
Event logging directly in the automation device is described in the logging model. Logging is
very similar to buffered reporting. The major difference is that with buffered reporting, the
reports are always sent immediately (if no communication errors occurs). If the buffer time is
not equal to zero, the report can be delayed to include other events from the data set, but the
principle remains the same. With the logging model, the client actively retrieves the reports
from a circular buffer in the server. Two time stamps can be assigned; the start time (or a start
number for the entry) and the end time. All log entries between these two time stamps (or
between the start number and the end of the log) are sent to the client [10].

Another major difference compared to BRCB is that when BRCB is used, only one client
receives data. With logging, any number of clients can query entries. Queries do not change
the entries.

The standard describes the difference between reporting and logging according to the text
below:






The principal building blocks for logging are depicted in figure 50. The logging model has
four building blocks. The data set represents the real data values. It is referenced in the log
control block (LCB). The LCB controls which data values and when these data values are to
Reporting provides mechanisms to report packed values of instances of data
immediately or after some buffer time. The logging model provides mechanisms
to store events in the log in sequence. A client may query a range of log entries at
any time [10].

Appendix 1 - IEC 61850

29
be stored into he log. The real data values are conceptually monitored by the event monitors.
An event monitor determines, on the basis of the state of the real data and the attributes of the
LCB class, when to inform the handler of the occurrence of an internal event. The log handler
stores a log entry to the log, which is a circular buffer that overwrites the oldest values in the
log. The number of entries depends on the size of log entries and the buffer size.

More then one LCB can be implemented per log, and they can reference different or the same
data sets. The events are the same as for the reports; dchg, qchang, dupt, integrity period and
general interrogation.




Figure 50: Reporting and logging.

Even if the Log is a circular buffer this is hidden from the client. The client view of the Log is
a linear buffer, where the Log entries are identified by:

EntryID: a unique identifier of a Log entry;
TimeofEntry: the time, when the Log entry has been added to the Log.

The EntryID provides together with TimeofEntry a unique identification of the entry.

Figure 51 shows an example of a log and three log control blocks. The first step is to
configure and enable log control blocks. After enabling the association with that server may
be closed. The log entries are stored into the log as they arrive for inclusion into the log. The
logs are stored in time sequence order. This allows retrieval of a sequence-of-events.


Appendix 1 - IEC 61850

30

Figure 51: Logging.

The log (not the log control block) is enabled at any time. The different log control blocks
allow storage of information from different data sets into the log. Each log control block is
independent of the other control blocks.

Control class model
The Control model provides services to operate on DATA with data attributes having the
functional constraint CO or SP.

Depending on the application, different behaviours of a control object shall be used. IEC
61850-7-2 defines these services as direct control and select before operate (SBO). There are
two cases of each service, with normal security and with enhanced security.
The direct control offers the ability to operate on the attribute with CP or SP functional
constraint. The SBO service validates the attribute to ensure that no other client currently are
operating or has selected the same attribute, before the operate request is sent.
The normal security mode there is no acknowledgement sent to the client after the operate
service, this means that if the operate request is negative, the client does not get any
information about the failure from the control object. The enhanced security mode provides
such information to the client.

Comparison of the data access methods
The principal characteristics of the data access methods provided by IEC 61850 are shown in
figure 52
Appendix 1 - IEC 61850

31

Figure 52: Comparison of data access methods.

Each of the four retrieval methods has a specific characteristic. There is no single method that
meets all application requirements. During system design, the designer has to analyse the
requirements ant to check them against the (implemented) methods provided by a device
compliant with the IEC 61850 series.

Communication mappings
The abstract communication service interface (ACSI) must be implemented by means of
protocols in order to use the services defined in IEC 61850. The standard describes four such
mappings, specific communication service mapping (ACSI). Two that maps the client/server
communication on the station bus level to existing standards. Common for the two is that both
uses manufacturing message specification (MMS). MMS is a standard that have served the
industry for many years, the mapping to this standard provides a robust and well tested
communication service interface for IEC 61850. MMS maps to the upper layers of the stack
while the lower part is mapped to Ethernet, with and without TCP/IP. The two remaining
SCSM maps GOOSE and SV communication over Ethernet. And SCSM mapping for SV
communication over point-to-point links. Since station bus is the focus in this work, the
GOOSE and SV mapping will not be considered. IEC 61850-8-1 defines three communication
profiles, two of them for layer 1-4 and one for the layers 5-7. They are referred to as A-Profile
for the layers 5-7 and TCP/IP T-Profile and OSI T-Profile.
The A-Profile defines the services for layer 5-7 and has the following attributes.

Figure 53: A-Profile
Layer 7:
MMS provides a rich set of services for peer-to-peer real-time communications over a
network. [5]. MMS is used for mapping of all client/server communication in IEC 61850.
Association control service element is used to establish and release an application-association
between two applications and to determine the application context of that association [12].
Appendix 1 - IEC 61850

32

The association control service element (ACSE) supports two modes of communication:
connection-oriented and connectionless. For the connection-oriented mode, the application-
association is established and released by the reference of ACSE connection oriented services.
For the connectionless mode, the application-association exists during the invocation of the
single ACSE connectionless mode service, A-UNIT-DATA [12].
Layer 6:
Connection oriented Presentation this has two functions. One is to negotiate the transfer
syntax and the second is transformation to and from that syntax [12]. In the A-Profile abstract
syntax notation one (ASN.1) is used, which encodes the PDUs to a standard format that all
layers can exchange.
Layer 5:
Connection oriented session provides the session management, opening and closing of
sessions. It also handles synchronisation points in the stream of packets [12].


The TCP/IP T-Profile defines the services for layer 1-4

Figure 54: TCP/IP T-Profile
Layer 4:
ISO transport on to of TCP is a mechanism that allows ISO applications to be ported to
TCP/IP network [12].
Appendix 1 - IEC 61850

33
Internet control message protocol is a integrated part of the IP suite , icmp messages
delivered in packages are used for out-of-band messages related to network operations or
mis-operations [12].
Transmission control protocol provides a reliable stream delivery and virtual connection
service to applications by sequenced acknowledgment [12].
Layer 3:
Internet protocol contains addressing information and control information to route packages
thru the network [12].
Address resolution protocol provides mapping of the IP-address to the physical network
address [12].
Layer 2:
Standard for the transmission of IP datagrams over Eternet networks is a method for
transmission of packages.
Carrier sense multiple access with collision detection is a method to control access to the
network bus [12].
Layer 1:
Interface connector and contact assignment for ISDN basic access interface (ISO/IEC
8877:1992), this is the specification for 10BaseT connector.
Basic optical fiber connector (IEC60874-10 1, -2 and 3), this is the specification for the ST
connector.
1
Appendix 2 - Definitions.

This appendix shows the definitions of the logical nodes and the data object that where
implemented during the test phase.
Logical Nodes
The two definitions of the logical nodes below,
LN: Generic set-point control Name: ASPT
This LN shall be used to provide the common characteristics found in all controller or
regulator type Logical Nodes. The LN can be standalone or cascaded with other logical nodes
to forma a complete controller.
ASPT class
Attribute Name Attr. Type Explanation T M/
O
LNName Shall be inherited from Logical-Node Class (see IEC 61850-7-2)
Data
Common Logical Node Information
LN shall inherit all Mandatory Data from Common Logical Node Class M
Controls
SptR SPC Setpoint raise O
SptL SPC Setpoint lower O
Measured Values
ActualSet MV Actual setpoint M
ErrTerm MV Error term O
Output MV Output
Status Information
Auto SPS Automatic operation O
SptDevAlm SPS Deviation alarm O
SptUp SPS Setpoint going up (raising) O
SptDwn SPS Setpoint going up (Lowering) O
SptDir SPS Setpoint direction O
SptMsg INS End Message:
0 Ended normally
1 Ended with overshoot
2 Cancelled: measurement was deviating
3 Cancelled: loss of communication with dispatch centre
4 Cancelled: loss of communication with local area network
5 Cancelled: loss of communication with the local interface
6 Cancelled: timeout
7 Cancelled: voluntarily
8 Cancelled: noisy environments
9 Cancelled: material failure
A Cancelled: new set-point request
B Cancelled: improper environment (blockage)
C Cancelled: stability time was reached
D Cancelled: immobilisation time was reached
E Cancelled: equipment was in the wrong mode
F Unknown causes

O
AdjMsg INS Adjustment Message
0 Completed
1 Cancelled
2 New adjustments
3 Under way

O
Settings
MaxRst RST Maximum restriction O
MinRst RST Minimum restriction O
DevAlm ASG Deviation Alarm O
SetPt APC Setpoint O
DeadB ASG Deadband O
Controls
Blk SPS Block operation O
Table 4: ASPT logical node class
Appendix 2 - Definitions.

2



LN: Position indicator Name: TPOS
This LN represents the position of a movable device, actuator or similar. The position is given
as a percentage of the full movement of the device being monitored. Compare with TDST that
returns the distance in m.
TPOS class
Attribute Name Attr. Type Explanation T M/O
LNName Shall be inherited from Logical-Node Class (see IEC 61850-7-2)
Data
Common Logical Node Information
LN shall inherit all Mandatory Data from Common Logical Node Class M
SmpRteRng ING Available sampling rate range O
Measured values
Psn SAV Position given as percentage of full movement (%) M
Settings
SmpRteSet ING Sampling rate setting O
Table 5: TPOS logical node class
Only the mandatory objects where implemendet, i.e the ASPT.SetPt and the TPOS.Psn and
the ASPT.ActualSet

Data Objects
The data classes implemented where: APC (from ASPT.SetPt), MV (from ASPT.ActualSet)
and SAV from (TPOS.Psn).
The MV and SAV are data classes for measured information and shall have the following
properties:

Figure 55: Services defined for measurand information

Appendix 2 - Definitions.

3
The APC class is a set point and is controllable analogue data and have the following
properties:

Figure 56: Services defined for controllable analogues

Appendix 2 - Definitions.

4

Figure 57: APC data class



Appendix 2 - Definitions.

5

Figure 58: MV data class



Appendix 2 - Definitions.

6

Figure 59: SAV data class


Figure 60: Analogue value data type