IEC61850 Ed2 Devices - EN - Rev1.6

Baseline Software Platform
IEC61850 Ed2 Device (Client & Server)
09/2019
www.schneider-electric.com
Rev. 1.6 (16-09-2019)
Change Control
Rev Date Description
1.0 25-10-2016 Initial revision for Easergy Builder.
1.1 11-11-2016 Add recommended RCB parameter settings in Section 3.1.10
Revised GOOSE section.
Revised Section 3.2.1
1.2 15-11-2017 GOOSE IF is now Interface name not IP address
1.3 14-2-2018 Rewrite introduction, move IEC 61850 overview to annex, restructure chapters 3, 5 to add
descriptions for T300.
1.4 01-03-2018 Minor changes.
1.5 12-04-2018 Client limits revised.
1.6 16-09-2019 Review all sections and revise client and server limits.
Relevant information for the user

As a result of the multiple uses of the product, the personnel in charge of the application and use of this control device
must ensure these usages comply with all safety and performance requirements applicable in each application. The
requirements include the applicable industry-related laws, norms, regulations and standards.
Throughout this manual some notes are included in order to alert the user about specific circumstances:
NOTICE
NOTICE identifies information about practices and circumstances which could result in a malfunction of the equipment.
Restricted Liability
Electrical equipment should be serviced and maintained only by qualified personnel.
No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this manual. This
document is not intended as an instruction manual for untrained persons.
The illustrations, dialog boxes, programming models and examples shown in this manual are intended for exemplary
purposes. As there are installation-specific variables and requirements, Schneider Electric will not be held responsible for
the misuse of the equipment based on the examples herein published.
NOTICE
An inadequate use of the equipment, or misuse by ignoring these specifications, may comprise the system’s security.
It is highly recommendable to backup the application programs frequently using the appropriate storage media to avoid
potential data loss.
The Baseline platform and all its components have been developed in accordance to the requirements for
a quality management system, complying with the ISO 9001 Standard
Document: FTE-IEC61-2-S854
Revision / Date: Rev 1.6 / 16-09-2019
File: IEC61850 Ed2 Devices_EN_Rev1.6.pdf
Retention period: Permanent throughout its validation period + 3 years after its
cancellation.
Configuring IEC61850 1
Rev. 1.6 (16-09-2019)
Table of Contents
Table of Contents .................................................................................................................................................................. 2
Index of Figures..................................................................................................................................................................... 6
Index of Tables ...................................................................................................................................................................... 7
Contents ................................................................................................................................................................................ 8
Chapter 1. Overview .................................................................................................................................................... 1-1
1.1 RTU Software Architecture ................................................................................................................................. 1-1
1.2 IEC 61850 Controller architecture ...................................................................................................................... 1-2
1.3 IEC 61850 Hierarchal Data Model ...................................................................................................................... 1-3
1.4 IEC 61850 Communication Profiles .................................................................................................................... 1-3
1.4.1 Client / Server (MMS) ................................................................................................................................. 1-3
1.4.2 Multicast GOOSE ....................................................................................................................................... 1-4
1.5 Use cases........................................................................................................................................................... 1-4
1.5.1 RTU as IEC61850 server ........................................................................................................................... 1-4
1.5.2 RTU as IEC61850 client ............................................................................................................................. 1-5
1.5.3 RTU as IEC61850 client/server gateway .................................................................................................... 1-6
1.6 IEC61850 Engineering Flow using Easergy Builder ........................................................................................... 1-6
1.7 Schema version .................................................................................................................................................. 1-8
Chapter 2. Easergy Builder .......................................................................................................................................... 2-1
2.1 SCL Files ............................................................................................................................................................ 2-1
2.2 Starting Easergy Builder ..................................................................................................................................... 2-1
2.3 Create a Saitel DP IEC61850 Client ................................................................................................................... 2-2
2.4 Create a T300 IEC61850 Server ........................................................................................................................ 2-7
2.4.1 Add an IEC 61850 controller ...................................................................................................................... 2-7
2.4.2 Add logical devices for each module .......................................................................................................... 2-9
2.4.3 Modifing dataset definitions ...................................................................................................................... 2-11
2.4.4 Add data base mapping ............................................................................................................................ 2-12
2.4.5 Save the configuration .............................................................................................................................. 2-13
2.4.6 Export an ICD/CID/IID file ......................................................................................................................... 2-13
2.5 ICD Editor ......................................................................................................................................................... 2-14
Chapter 3. IEC61850 Ed1/Ed2 Client ......................................................................................................................... 3-15
3.1 IEC61850 Ed1/Ed2 Client Configuration .......................................................................................................... 3-15
3.2 Local server data model ................................................................................................................................... 3-16
3.3 Signal Identification and mapping ..................................................................................................................... 3-16
3.3.1 The MMS Leaf Concept ............................................................................................................................ 3-16
3.3.2 IEC61850 Client Coordinate Syntax ......................................................................................................... 3-17
3.3.3 Client side Diagnostic Points .................................................................................................................... 3-18
3.3.4 IEC61850 Client side double command points without IsaGraf ................................................................ 3-18
3.4 Data sets and report control blocks .................................................................................................................. 3-19
3.4.1 Client side limits........................................................................................................................................ 3-19
3.4.2 Client side Information Report Datasets ................................................................................................... 3-19
Rev. 1.6 (16-09-2019)
3.4.3 Report Control Blocks............................................................................................................................... 3-21

3.5 Quality flag mapping ......................................................................................................................................... 3-24
3.6 Inverting Dbpos values ..................................................................................................................................... 3-25
Chapter 4. IEC61850 Ed1/Ed2 Client PICS ................................................................................................................. 4-1
4.1 General............................................................................................................................................................... 4-1
4.2 ASCI basic conformance statement ................................................................................................................... 4-1
4.3 ACSI models conformance statement ................................................................................................................ 4-2
4.4 ACSI service conformance statement ................................................................................................................ 4-3
Chapter 5. IEC61850 Ed2 Server................................................................................................................................. 5-6
5.1 Server Configuration........................................................................................................................................... 5-6
5.1.1 Signal identification and mapping ............................................................................................................... 5-6
5.1.2 Diagnostic coordinates ............................................................................................................................... 5-8
5.1.3 Health enumerations .................................................................................................................................. 5-8
5.2 Local / Remote ................................................................................................................................................... 5-9
5.2.1 CoreDB configuration for local/remote status ............................................................................................. 5-9
5.2.2 IEC 61850 Definition................................................................................................................................... 5-9
5.2.3 Saitel CPU Local/Remote Mode ................................................................................................................. 5-9
5.2.4 Saitel Logical Node Local/Remote Mode .................................................................................................... 5-9
5.2.5 T300 definition .......................................................................................................................................... 5-10
5.2.6 IEC 61850 local/remote modelling for T300 ............................................................................................. 5-10
5.2.7 Mapping LocKey ....................................................................................................................................... 5-11
5.3 Mode & Behaviour ............................................................................................................................................ 5-11
5.3.1 Restrictions ............................................................................................................................................... 5-12
5.4 Control Model ................................................................................................................................................... 5-12
5.4.1 CoreDB mapping ...................................................................................................................................... 5-12
5.4.2 Controls with enhanced security ............................................................................................................... 5-12
5.4.3 Controls with normal security ................................................................................................................... 5-12
5.4.4 Switch blocking and interlocking ............................................................................................................... 5-13
5.4.5 Control Service Status / Additional Cause ................................................................................................ 5-13
5.5 Data sets and report control blocks .................................................................................................................. 5-15
5.5.1 Server side limits ...................................................................................................................................... 5-15
5.5.2 Buffered reports ........................................................................................................................................ 5-15
5.5.3 Trigger conditions ..................................................................................................................................... 5-16
5.6 Quality flag mapping ......................................................................................................................................... 5-16
5.6.1 General quality flag mapping .................................................................................................................... 5-16
5.6.2 T300 quality flag mapping ........................................................................................................................ 5-16
5.7 GOOSE ............................................................................................................................................................ 5-17
5.7.1 GOOSE Publish........................................................................................................................................ 5-17
5.7.2 GOOSE Subscribe ................................................................................................................................... 5-19
Chapter 6. IEC61850 Ed2 Server PICS ....................................................................................................................... 6-1
6.1 General............................................................................................................................................................... 6-1
6.2 ASCI basic conformance statement ................................................................................................................... 6-1
6.3 ACSI models conformance statement ................................................................................................................ 6-1
Rev. 1.6 (16-09-2019)
6.4 ACSI service conformance statement ................................................................................................................ 6-3

Chapter 7. IEC61850 Ed2 PIXIT .................................................................................................................................. 7-1
7.1 Introduction......................................................................................................................................................... 7-1
7.2 Association Model .............................................................................................................................................. 7-1
7.2.1 Association parameters .............................................................................................................................. 7-1
7.2.2 TCP Keep Alive .......................................................................................................................................... 7-1
7.2.3 TCP Timeout .............................................................................................................................................. 7-1
7.2.4 Maximum Client associations ..................................................................................................................... 7-1
7.2.5 Aborting associations ................................................................................................................................. 7-1
7.2.6 Authentication Authentication ..................................................................................................................... 7-2
7.2.7 MMS PDU Size........................................................................................................................................... 7-2
7.3 Startup time ........................................................................................................................................................ 7-2
7.4 Server Model ...................................................................................................................................................... 7-2
7.4.1 Data quality ................................................................................................................................................ 7-2
7.4.2 Get / Set data values services .................................................................................................................... 7-2
7.5 Data Set Model ................................................................................................................................................... 7-3
7.5.1 Data set structure and content ................................................................................................................... 7-3
7.5.2 Dynamic data set creation .......................................................................................................................... 7-3
7.6 Substitution Model .............................................................................................................................................. 7-3
7.7 Setting Group Control Model .............................................................................................................................. 7-3
7.8 Reporting Model ................................................................................................................................................. 7-3
7.8.1 Supported Report Control Block ................................................................................................................. 7-3
7.8.2 Report Control Blocks................................................................................................................................. 7-3
7.9 Logging Model .................................................................................................................................................... 7-5
7.10 Generic Substation Events Model ...................................................................................................................... 7-5
7.10.1 GSSE model ............................................................................................................................................... 7-5
7.10.2 GOOSE model............................................................................................................................................ 7-5
7.10.3 GOOSE Publication .................................................................................................................................... 7-5
7.10.4 GOOSE Subscription.................................................................................................................................. 7-7
7.11 Sampled Values Model....................................................................................................................................... 7-9
7.12 Control Model ..................................................................................................................................................... 7-9
7.12.1 Modes of operation ..................................................................................................................................... 7-9
7.12.2 Error code ................................................................................................................................................... 7-9
7.12.3 Control service status - AddCause ............................................................................................................. 7-9
7.13 Time and Time Synchronisation ....................................................................................................................... 7-10
7.14 File Transfer Model .......................................................................................................................................... 7-10
Chapter 8. Trouble Shooting ........................................................................................................................................ 8-1
8.1 IEC61850 configuration checklist ....................................................................................................................... 8-1
8.2 Log files .............................................................................................................................................................. 8-1
8.2.1 Saitel: syslog.txt and i61.log files ................................................................................................................ 8-1
8.2.2 T300: Syslog and i61log ............................................................................................................................. 8-1
8.3 Saitel: IEC61850 Diagnostics ............................................................................................................................. 8-1
8.3.1 MMS STATS .............................................................................................................................................. 8-3
Rev. 1.6 (16-09-2019)
8.3.2 IEC-61850 CLIENT CONNECTIONS ......................................................................................................... 8-3

8.4 Saitel: Console trace / Logging to nvRam .......................................................................................................... 8-3
8.4.1 Console trace User Interface ...................................................................................................................... 8-4
8.4.2 FUNCTION: i61srvSetDebugLevel ............................................................................................................. 8-4
8.4.3 FUNCTION: i61srvSetDebugFG................................................................................................................. 8-4
8.4.4 FUNCTION: i61srvDebugStop.................................................................................................................... 8-4
8.4.5 FUNCTION: i61cliSetDebugLevel .............................................................................................................. 8-4
8.4.6 FUNCTION: i61cliSetDebugFG .................................................................................................................. 8-4
8.4.7 FUNCTION: i61cliDebugStop ..................................................................................................................... 8-5
8.5 IEC61850 FAQ ................................................................................................................................................... 8-6
Chapter 9. IEC 61850 Overview................................................................................................................................... 9-8
9.1 Station Level, Bay Level and Process Level....................................................................................................... 9-8
9.2 Data modelling and services .............................................................................................................................. 9-9
9.2.1 Data modelling – the Leaf concept ............................................................................................................. 9-9
9.3 Substation Configuration Language (SCL) ....................................................................................................... 9-10
9.4 IEC61850 Engineering ..................................................................................................................................... 9-10
Chapter 10. Annexes ........................................................................................................................................................ A
10.1 Glossary ................................................................................................................................................................ A
10.2 IEC 61850 Document References ......................................................................................................................... C
10.3 Functional Constraints ........................................................................................................................................... C
10.4 Changes from IEC 61850 Ed1 to Ed2 ................................................................................................................... A
10.4.1 Data model changes...................................................................................................................................... A
10.4.2 Communication changes ............................................................................................................................... A
10.4.3 SCL changes ................................................................................................................................................. A
10.5 Configuration Files ................................................................................................................................................ A
10.5.1 i61_conf.xml file ............................................................................................................................................. A
10.5.2 SCD file ......................................................................................................................................................... B
Rev. 1.6 (16-09-2019)
Index of Figures
Figure 1-1. Baseline software architecture. ........................................................................................................................ 1-1
Figure 1-2. Relation between coreDb and other applications. ............................................................................................ 1-2
Figure 1-3. Controller architecture ...................................................................................................................................... 1-3
Figure 1-4. RTU as IEC 61850 Server ............................................................................................................................... 1-4
Figure 1-5. RTU as IEC 61850 Client ................................................................................................................................. 1-5
Figure 1-6. RTU as IEC 61850 Gateway ............................................................................................................................ 1-6
Figure 1-7. IEC 61850 Engineering flow with Easergy Builder ........................................................................................... 1-7
Figure 2-1. Easergy Builder interface. ................................................................................................................................ 2-1
Figure 2-2. Empty Workspace. ........................................................................................................................................... 2-2
Figure 2-3. Add new RTU ................................................................................................................................................... 2-2
Figure 2-4. Add a project. ................................................................................................................................................... 2-3
Figure 2-5. Example project SS1........................................................................................................................................ 2-3
Figure 2-6. Add IEC61850 Device. ..................................................................................................................................... 2-4
Figure 2-7. Open the IEC61850 Configuration page. ......................................................................................................... 2-4
Figure 2-8. Name of local IEC61850 server, SS1BAUXD01. ............................................................................................. 2-4
Figure 2-9. Select all remote nodes.................................................................................................................................... 2-5
Figure 2-10. SS1BAUXD01 with access point AP1. ........................................................................................................... 2-5
Figure 2-11. Save the project. ........................................................................................................................................... 2-6
Figure 2-12. T300 configuration before adding IEC 61850 controller. ................................................................................ 2-7
Figure 2-13. T300 configuration after adding IEC 61850 controller. ................................................................................... 2-8
Figure 2-14. Modify datasets ............................................................................................................................................ 2-12
Figure 2-15. Create/Edit a new ICD file ............................................................................................................................ 2-14
Figure 3-1. Typical SCD contents..................................................................................................................................... 3-15
Figure 3-2. Typical local server data model for Saitel....................................................................................................... 3-16
Figure 3-3. The MMS leaf concept ................................................................................................................................... 3-17
Figure 3-4. IEC61850 Report Control Block. .................................................................................................................... 3-22
Figure 3-5. Configuring RCBs in Easergy Builder. ........................................................................................................... 3-23
Figure 3-6. Buffered Report parameters ........................................................................................................................... 3-23
Figure 3-7. Unbuffered Report parameters ...................................................................................................................... 3-24
Figure 3-8. Invert double point status ............................................................................................................................... 3-26
Figure 7-1. GOOSE Publishers .......................................................................................................................................... 7-5
Figure 7-2. GOOSE Subscribers ........................................................................................................................................ 7-7
Figure 8-1. Remote reboot of CPU from Easergy Builder .................................................................................................. 8-7
Figure 8-2. Reboot CPUA, CPUB or both .......................................................................................................................... 8-7
Figure 9-1. IEC61850 Station level, Bay level and Process level. ...................................................................................... 9-9
Figure 9-2. Logical Node XSWI and Data. ......................................................................................................................... 9-9
Figure 9-3. IEC61850 Substation Engineering. ................................................................................................................ 9-12
Figure 10-1. SCD file structure. .............................................................................................................................................. I
Rev. 1.6 (16-09-2019)
Index of Tables
Table 0-1-1. Reference manuals ........................................................................................................................................... 9
Table 0-1-2. Software versions.............................................................................................................................................. 9
Table 0-1-3. Hardware/Software compatibility. ...................................................................................................................... 9
Table 2-1. T300 Module ICD files ....................................................................................................................................... 2-9
Table 3-1. Client side limits .............................................................................................................................................. 3-19
Table 3-2. Supported CDCs ............................................................................................................................................. 3-20
Table 3-3. Supported Client side RCB types .................................................................................................................... 3-23
Table 3-4. Mapping IEC61850 Validity to CoreDB ........................................................................................................... 3-25
Table 3-5. Mapping IEC61850 Quality detail to CoreDB .................................................................................................. 3-25
Table A.4-1 – Basic conformance statement ...................................................................................................................... 4-1
Table A.4-2 – ACSI models conformance statement.......................................................................................................... 4-2
Table A.4-3 – ACSI service Conformance statement ......................................................................................................... 4-3
Table 5-1. Server Coordinate syntax .................................................................................................................................. 5-7
Table 5-2. T300 Mapping examples ................................................................................................................................... 5-7
Table 5-3. Pre-defined data attribute values ...................................................................................................................... 5-8
Table 5-4. Mod/Beh Data Objects .................................................................................................................................... 5-11
Table 5-5. Mod/Beh Enumeration..................................................................................................................................... 5-12
Table 5-6. Control Status / Additional Cause ................................................................................................................... 5-14
Table 5-7. Server side limits ............................................................................................................................................. 5-15
Table 5-8. General quality flag mapping........................................................................................................................... 5-16
Table 5-9. T300 quality flag mapping ............................................................................................................................... 5-17
Table A.6-1 – Basic conformance statement ...................................................................................................................... 6-1
Table A.6-2 – ACSI models conformance statement.......................................................................................................... 6-2
Table A.6-3 – ACSI service Conformance statement ......................................................................................................... 6-3
Table 8-1. Checklist............................................................................................................................................................ 8-1
Table 10-1. Glossary ............................................................................................................................................................. B
Table 10-2. Supported Services ........................................................................................................................................... G
Rev. 1.6 (16-09-2019)
Contents
I. Objective
This manual provides information about the configuration of the IEC61850 Ed2 communications device in Easergy Builder.
Both profiles, client and server are described.
II. Arrangement
This manual is divided in the following chapters.
Chapter 1 – Overview
Introduction to the IEC 61850 controller architecture, data modelling, use cases, and overview of the Engineering flow
using Easergy Builder
Chapter 2 – Easergy Builder

A general description of the tool Easergy Builder and the IEC61850 Ed2 plugin.
Chapter 3 – IEC61850 Ed1/Ed2 Client

Description of the user interface implemented in Easergy Builder to manage the information associated to the IEC61850
Ed1/Ed2 client.
Chapter 4 – IEC61850 Ed1/Ed2 Client PICS

IEC61850 Ed1/Ed2 Client Protocol Implementation Statement.
Chapter 5 – IEC61850 Ed2 Server

Description of the user interface implemented in Easergy Builder to manage the information associated to the IEC61850
Ed2 server.
Chapter 6 – IEC61850 Ed2 Server PICS

IEC61850 Ed2 Server Protocol Implementation Statement.
Chapter 7 – IEC61850 PIXIT

The Protocol Implementation eXtra Information for Testing (PIXIT) of the Baseline IEC61850 Ed2 solution.
Chapter 8 – Trouble Shooting

Things to check when it seems impossible to configure the Baseline IEC61850 Ed2 controller. Includes a FAQ.
Chapter 9 – IEC 61850

Introduces some of the main concepts of IEC 61850
Chapter 10 – Annexes
Rev. 1.6 (16-09-2019)
III. Reference Manuals

The following documents, which could be used for further reference, are provided to supplement the information included
in this manual:
Manual’s name Document
Easergy Builder User Manual TE-HG-0000-MSS-S856
Saitel Webtool User Manual TE-HG-0000-MCW-S856
Table 0-1-1. Reference manuals
IV. Software Versions

The information in this manual applies to software versions listed in the following table and subsequent:
Module Software version (CPU) Pluging version (Easergy Builder)
IEC61850 Ed2 client/server i61scBinC - 10.02.27 IEC61850 - 1.1.22.0
Table 0-1-2. Software versions
V. Hardware/Software Compatibility
Controllers supported by the CPU modules of different hardware platforms are the following:
Software SM_CPU866 SM_CPU866e HU_B/HU_BI HU_A/HU_AF HU 250 HUe
√ √
IEC61850 Ed2
√client/server
× √ × ×
Table 0-1-3. Hardware/Software compatibility.
NOTICE
Saitel DR basic head units (modules HU_B and HU_BF) don’t use VxWorks nor Linux. They use a tailor-made software
which includes the OS, database and applications. The Saitel IEC61850 Ed2 solution does not run on these platforms.
Rev. 1.6 (16-09-2019)
Chapter 1. Overview
NOTICE
It is highly recommended that the user be familiar with the IEC61850 international standard prior to configuring the
RTU, only a brief overview is provided here.
1.1 RTU Software Architecture

The Baseline Software Platform of Schneider Electric is composed by:
• VxWorks & Linux operating systems.
• Real-time applications and its configuration files.
• Configuration, management, supervision and monitorization tools.
The following figure shows the different applications included in the software platform, as well as additional applications
that implement protocols to upgrade Easergy Builder:
IEC61850
coreDb
(client & server)
Configuration Files
IEC104
(master & slave)
IEC101
(master & slave)
DNP
(master & slave)
Devices Modbus Real Time Database Web Server

Configuration Files (master & slave) (coreDb) (Saitel Webtool)
ISaGRAF
(v3.5 & v5)
Synchronization
Supervision
Communications
Local Acquisition
(Saitel DP & DR)
Cilo
(Easergy T300)
Others
Devices
Real Time Operating System

(VxWorks & Linux)
Figure 1-1. Baseline software architecture.
The operating system abstracts the hardware from the software applications and manages the applications in real time. It
integrates the basic protocols to access the remote unit (SFTP, SSH, etc.) and manage multiple users.
The real-time database, named coreDb, is probably the most important element. All the other elements are developed
around coreDb:
Configuring IEC61850 1-1

Rev. 1.6 (16-09-2019)
Figure 1-2. Relation between coreDb and other applications.
coreDb performs the real-time management of RTU signals. This real-time database is associated with data producing
and consuming Devices. Devices are the different data acquisition and processing applications software which access
coreDb.
For more information about the Baseline Software Platform, please consult the manuals “Easergy Builder User Manual”
and “Saitel Webtool User Manual”.
1.2 IEC 61850 Controller architecture

The Baseline IEC61850 Ed2 solution is both a IEC61850 Ed2 server and Ed1/Ed2 compatible client. It acts as a client to
communicate with downstream physical IEDs. It provides a server side for communication upstream to HMI or other
clients. The local server is always available even in gateway projects where the upstream communication is via a non-
61850 protocol, IEC104, DNP, etc.
The internal architecture is based on a shared real-time database, “CoreDB”, and several data sources or data
destinations known as “bin controllers”. Each type of communication protocol has a different type of bin controller.
The IEC61850 bin controller includes both server and client functions. However, there is no direct data transfer between
the server and client functions within the bin controller. Data values are transferred to-from CoreDB variables for the
server in the same way as other slave (SCADA) bin controllers, and for the client in in the same way as other master bin
controllers.

Rev. 1.6 (16-09-2019)
SCADA Slave 104 SC150

(master) e.g. 104 Master(s)
LV150
CoreDB
IED
IEC 61850 IEC 61850 IEC 61850
client Server Client(s)
IED
Figure 1-3. Controller architecture
1.3 IEC 61850 Hierarchal Data Model

The IEC61850 data model uses a hierarchal approach that can be summarised as follows
• An Intelligent Electronic Device (IED) is a physical device which is a communication server.
• Each physical device contains 1 or more instances of Logical Devices (LD).
• Each Logical Device contains many instances of Logical Nodes (LN).
• Each Logical Node is a standardised set of related Data Objects (DO).
• Data Objects have standard types called Common Data Classes (CDC).
• Common Data Classes define a set of Data Attributes.
• Data attributes have functional constraints that indicate how they are used.
Logical Nodes represent relatively-self contained functions, for example a protection function, or temperature
measurement monitoring. Logical Nodes for substation automation are described in Part 7-4. Other application domains
may define new Logical Nodes and Data Objects, but shared the same Common Data Classes.
Data attributes may be Status information (digital values), Measurands (analogue values), Operation or control requests (if
applicable), Settings (sometimes changed), Configuration (rarely changed).
1.4 IEC 61850 Communication Profiles

IEC61850 defines a generic abstract communication service interface (ASCI) and several communication mappings or
profiles. The Saitel / Easergy T300 support client/server and multicast communication mappings.
1.4.1 Client / Server (MMS)

MMS is an international standardized messaging system (ISO 9506) for exchanging real-time data and supervisory control
information between networked elements in a manner that is independent of the application function that is being
performed and the developer of the device or application.
MMS provides a rich set of services for peer-to-peer real-time network communications. Messaging services are generic
enough to be appropriate for a wide variety of devices, applications, and industries. The IEC 61850 standard uses MMS
TCP to map all services, objects, and algorithms that are specified in parts 7-2, 7-3, and 7-4 and conform to ACSI. ACSI
provides an abstract interface to describe communications between clients and servers (data access and retrieval, device
control, reporting, and so on). It also describes the system-wide event distribution between an application in one device
and many remote applications in other devices (publisher/subscriber). It also describes the transmission of sampled
measured values (publisher/subscriber). In short, IEC 61850 requirements are defined in ACSI as an abstract interface
and are implemented through the MMS protocol.

Rev. 1.6 (16-09-2019)
1.4.2 Multicast GOOSE

Generic Object Oriented Substation Event (GOOSE) is a mechanism for the fast transmission of data. A GOOSE
message is published by one IED and received by one or more other IEDs. GOOSE can be used for several purposes
such as tripping switchgear, starting a disturbance recorder, providing position indication for interlocking.
When a device (publisher) sends information, only its subscribers use it (although all devices on the network receive the
data unless communications are filtered by an Ethernet switch). The action of each subscriber depends on its own
configuration and functionality.
1.5 Use cases

This section uses the T300 and its modules as an example but similar principles apply to Saitel RTUs.
1.5.1 RTU as IEC61850 server

The T300 collects data from its local I/O modules and acts a server for communication with a remote client.
Master SC150
104
LV150
CoreDB
IEC 61850 IEC 61850

client Server
Figure 1-4. RTU as IEC 61850 Server
1.5.1.1 Configuration
The CoreDB data base is defined with the variables for the relevant number of SC150 and LV150 modules using a
configuration produced by the T300 Generator.
The IEC61850 bin controller is configured with a SCD that defines the server with a logical device corresponding to the
Head Unit, plus other logical devices corresponding to each SC150 and LV150 module. The SCD is built within Easergy
Builder by reading the IED Capability Description (ICD) file for each module.
The IEC61850 server can be defined as a destination device for selected status and analog variables, or a source for
command variables, in the same way as for other SCADA protocols.
The SCL file for the T300 can be saved as a Configured IED Description (CID) file that can be used by the client.
1.5.1.2 Supported Services

As a server, the T300 can report status and analog values via reporting blocks or via polled reads.
The T300 will accept commands from the IEC61850 client.
Configuration settings for the modules can only be changed by the Head Unit web pages.

Rev. 1.6 (16-09-2019)
1.5.2 RTU as IEC61850 client

The T300 communicates as a client with the IEC61850 server(s) on one or remote IEDs. The T300 IEC61850 server side
is still active, the logical device ‘SYSTEM’ can contain the RTU alarm signals.
SCADA Slave 104 SC150

(master) e.g. 104 Master(s)
LV150
CoreDB
IED
IEC 61850 IEC 61850
Server Client(s)
IED
Figure 1-5. RTU as IEC 61850 Client
The IEC61850 bin controller is configured with an SCD that defines the server with a default logical device corresponding
to the Head Unit, plus the definitions of the remote IEDs and their logical devices. The SCD can be built within Easergy
Builder by reading the IED Capability Description (ICD) files for each IED.
Based on the data set reports defined in each ICD file, Easergy Builder can automatically create status and analog
variables in CoreDB, together with the correct source coordinates. If event logging is required for these variables, the IED
status and analog variables must be manually mapped to the SOE device.
CoreDB command and set-point variables for the IED must be defined manually.
The SCADA slave bin controller can be defined as a destination device for selected IED status and analog variables, or as
a source of command variables, in the same way as for variables updated by other protocols.

As a client, the T300 retrieves status and analog values from the IEDs via reporting blocks only.
The SCD file may define values for configuration settings and description data attributes. However, these configuration
settings are neither read from, nor written to the remote IEDs. IED settings can only be changed by configuring the IED
directly.

Rev. 1.6 (16-09-2019)
1.5.3 RTU as IEC61850 client/server gateway

The T300 acts a server for communication with a remote client, and it acts as a client with the IEC 61850 server(s) on one
or remote IEDs.
CoreDB
IED
IEC 61850 IEC 61850 IEC 61850
client Server Client(s)
IED
Figure 1-6. RTU as IEC 61850 Gateway
The IEC61850 bin controller is configured with an SCD that defines the server with a logical device corresponding to the
Head Unit, plus a set of proxy logical devices, plus the definitions of the remote IEDs and their logical devices. The SCD
can be built within Easergy Builder by reading the ICD or CID file for each IED.
Based on the data set reports defined in each ICD file, Easergy Builder can automatically create status and analog
variables in CoreDB, together with the correct source AND destination coordinates. If event logging is required for these
variables, the IED status and analog variables must be manually mapped to the SOE device.
CoreDB command and set-point variables for the IED must be defined manually.
The IEC61850 server can be defined as a source for command variables, in the same way as for other SCADA protocols.

As a client, the T300 retrieves status and analog values from the IEDs via reporting blocks only. As a server, the T300 can
report status and analog values via reporting blocks or via polled reads.
The SCD file may define values for configuration settings and description data attributes which can be read by the external
client. If the settings are not declared to be read-only in the SCD, the external client can write new values. However, these
configuration settings are neither read from, nor written to the remote IEDs. IED settings can only be changed by
configuring the IED directly.
1.6 IEC61850 Engineering Flow using Easergy Builder

Easergy Builder functions both as a simple system configurator tool (SCT) and as an IED configuration tool (ICT)
It uses two special configuration files, a SCD file which describes the IEC61850 communication, and a proprietary format
configuration file i61_conf.xml.
The SCD file must be created at the IEC61850 system configuration level by someone who has a view of the whole
substation and the necessary dataflow between IEC61850 devices. The ICD or CID files for the protection devices are
imported into the System Configuration Tool (SCT), which then creates the SCD file for the substation.
For simple configurations, the SCD file can be built using Easergy Builder. For complex configurations, it is recommended
to use dedicated System Configuration Tool (SCT) such as =S= SET or Helinks. The SCD is then imported into Easergy
Builder which acts as the IED Configuration Tool (ICT).
For mixed edition / mixed vendor solutions you must create the SCD using =S= SET or Helinks.

Rev. 1.6 (16-09-2019)
Once the SCD is built or loaded into Easergy Builder, the tool is used for IED level IEC61850 engineering, for example to
define the configuration for activating report control blocks in the remote devices. This extra configuration is stored in the
i61_conf.xml file.
Figure 1-7 shows a summary of the overall IEC61850 engineering flow.

STEP 1: ICD (or CID or IID) files are supplied by the manufacturers for the protection devices involved.
STEP 2: The System tool (SCT) is used to imports the ICD (or CID or IID) files for protection devices + the ICD (or IID) file
for the Saitel / T300 RTU and creates instances necessary for the project.
STEP 3: Use SCT to do system level 61850 engineering.
STEP 4: Export the SCD file.
STEP 5: Use Easergy Builder as the ICT to import the SCD file to start IED level 61850 engineering.
STEP 6: Configure the coreDb RTDB variables and any other changes necessary.
STEP 7: If the local server data model was edited, the new IID must be exported and re-imported into the SCT. Return to
STEP 2 so that the SCD file for the substation stays up to date.
STEP 8: Download configuration to the Saitel or T300 RTU.
Figure 1-7. IEC 61850 Engineering flow with Easergy Builder
NOTICE
It is vital that the CID files imported correspond exactly to the actual configuration of the protection devices, if this is
not the case then there is little chance that the Saitel RTU will be configured correctly. In particular the IP addresses
in the CID files must match the actual IP address of the configured protection devices.

Rev. 1.6 (16-09-2019)
1.7 Schema version

The Baseline IEC61850 Ed2 solution uses the SCL schemas 2007B. After Easergy Builder is installed the applicable Ed2
schema can be found in the Program Files directory;
C:/Program Files/Schneider Electric/Easergy Builder/PlugsBin/i61sc/schemas/3.1/SCL.xsd
NOTICE
The Baseline IEC61850 Ed2 solution uses SCL schema version;
SCL.2007B.2014-01-22.
The SCL schemas used by the protection devices must be compatible with this version of the SCL schema or
interoperability cannot be guaranteed.

Rev. 1.6 (16-09-2019)
Chapter 2. Easergy Builder

2.1 SCL Files
The IEC61850 Server uses configuration files whose formats are defined in IEC61850 part 6. Two types are used for the
configuration.
• ICD: IED Capability Description – a template description of a single type of IED
• SCD: Substation Configuration Description – the description of all the IEDs in a specific system
The IEC61850 client/server is initialized from a single System Configuration Description (SCD) file. The SCD file includes
the definition of the IEC61850 data models for both the server and the client.
For simple configurations, Easergy Builder has a “SCD build” mode where the SCD can be initialized from a default ICD
files for the Head Unit, and then be extended by importing definitions from ICD files for each type of T300 module or
external IED.
A set of ICD files have been defined for each type of T300 module: SC150, LV150 and PS50. There are different ICD files
if the modules are configured with Power Measurement and Power Quality options.
2.2 Starting Easergy Builder

Easergy Builder is started using the Windows® Home Menu, or via the desktop shortcut. The initial interface is as follows:
Figure 2-1. Easergy Builder interface.
The Easergy Builder image depends on if there is a configuration active or not. For example, the previous figure shows
Easergy Builder when you are editing a configuration:
• 1: Information about the active configuration.
• 2: Toolbar and main menu.
• 3: Edition zone.
• 4: Log console
• 5: Device catalog
The toolbar, main menu and edition zone will be detailed for each device.

Rev. 1.6 (16-09-2019)
2.3 Create a Saitel DP IEC61850 Client

Here we describe how to create a new IEC61850 project from scratch using the DP (SM_CPU866e) as an example.
The SCD file to be used in this example can be found in the demo workspace; EB-demo-Ed2-ws\DP_T1\SS1\SS1-
v29_s.scd
The process of creating the demo workspace is now elaborated below, alternatively you can just open the workspace and
study it.
First click the button to add a new RTU type;
Figure 2-2. Empty Workspace.
Figure 2-3. Add new RTU
Now create a configuration (or project) for the RTU type by clicking on the spanner symbol ;

Rev. 1.6 (16-09-2019)
Figure 2-4. Add a project.
For this example the project is called SS1.
Figure 2-5. Example project SS1
Double click on the project to open the Devices page and add the IEC61850 controller called ‘SS1BAUXD01’;

Rev. 1.6 (16-09-2019)
Figure 2-6. Add IEC61850 Device.
Figure 2-7. Open the IEC61850 Configuration page.
Double click on the SS1BAUXD01 device just added to open the IEC61850 configuration page and select the name of the
device, SS1BAUXD01 just created;
Figure 2-8. Name of local IEC61850 server, SS1BAUXD01.
And then Select SCL to import the project SCD file ‘SS1-v29_s.scd’ and select all remote nodes EXCEPT the local
IEC61850 SS1BAUXD01 server;

Rev. 1.6 (16-09-2019)
.
Figure 2-9. Select all remote nodes.
Then select the other parameters associated with the local IEC61850 server;
Figure 2-10. SS1BAUXD01 with access point AP1.
Click the symbol at the bottom of the IEC61850 configuration page and then save the project.

Rev. 1.6 (16-09-2019)
Figure 2-11. Save the project.
Now you have your first IEC61850 Ed2 project workspace for the Saitel DP SM_CPU866e-linux, ready to configure local
adquisition, synchronisation, report control blocks for the reports to be enabled by the RTU and add the RTU database.
Please see the attached workspace, it is a fully configured project for a transmission substation, mapping upstream to
DNP3 and also to local IEC61850 HMI.

Rev. 1.6 (16-09-2019)
2.4 Create a T300 IEC61850 Server

• Create a basic configuration, e.g. using the T300 Generator or by cloning an existing configuration.
Figure 2-12. T300 configuration before adding IEC 61850 controller.
2.4.1 Add an IEC 61850 controller

• Open the configuration and add an IEC 61850 device by clicking on the button.
ATTENTION: The device name will be used as the IED name in the SCD file
Note: The device name is restricted to 32 characters.
• Choose the option to Build a SCD file

Rev. 1.6 (16-09-2019)
A new device will be added:
Figure 2-13. T300 configuration after adding IEC 61850 controller.
• Double-click on the new device to open its configuration window

On the left, the window shows the structure of the IEC 61850 data model.
On the right, the window shows a list of ICD/CID templates appropriate for the RTU type (in this case the T300).

Rev. 1.6 (16-09-2019)
2.4.2 Add logical devices for each module

There are different templates for different module types and options
Module Options used in T300 Generato ICD Template
LV150 Base (with or without Broken Conductor) T300_LV150_TEMPLATE_01_Base.icd
LV150 Power Quality T300_LV150_TEMPLATE_01_PQ.icd
SC150 Base (with or without Broken Conductor) T300_SC150_TEMPLATE_01_Base.icd
SC150 Power Metering T300_SC150_TEMPLATE_01_PM.icd
SC150 Power Quality (with or without Power Metering) T300_SC150_TEMPLATE_01_PMPQ.icd
PS50 - T300_PS0_TEMPLATE_01_Base.icd
Table 2-1. T300 Module ICD files
• To add logical devices corresponding to the SC150 and LV150 modules, right click on the required template

Rev. 1.6 (16-09-2019)
• To add a single logical device, choose option “Add logical devices to IED server”.
Enter the prefix of the identification corresponding to the modules device name e.g. SC01, SC02, LV01 etc
• To add several logical devices of the same type, choose option “Add multiple logical devices to IED server …”
Enter a list of prefixes corresponding to the modules device name e.g. SC01, SC02
• Click the ok (tick) button on this screen and click yes or ok on the confirmation dialog box.

Rev. 1.6 (16-09-2019)
The SCL view will be updated with the new logical devices and their logical nodes
By default, the models for the SC150, LV150 and PS50 modules include most of the status and analog variables. They do
not include power quality harmonics measurements.
Click the ok (tick) button to exit the IEC 61850 plug-in and return to the main configuration window.
2.4.3 Modifing dataset definitions

If required, the SCL definition can be modified e.g. to delete unwanted variables from the DataSets and remove unused
logical nodes.
Use the SCL view in Easergy Builder to add, delete or reconfigure data set elements.

Rev. 1.6 (16-09-2019)
Figure 2-14. Modify datasets
2.4.4 Add data base mapping

The function described above add logical devices only adds information to the SCL model that is used to create the SCD
file – they do not change the CoreDB definition.
Use the Point Wizard to add the data base mappings. The Point Wizard obeys all the relevant mapping rules.
It is also possible to export the CoreDb definition as an Excel file, add the mapping in Excel, and then reimporting the
CoreDb definition. In this case, it is essential to use the CoreDB checking button to check for errors.
See section 5.1.1 Signal identification and mapping

Rev. 1.6 (16-09-2019)
2.4.5 Save the configuration

• Save the configuration as normal.
If the SCL definition has changed, then you will be prompted to add some information to the Header, History section in the
SCL file.
2.4.6 Export an ICD/CID/IID file

• Double-click on the IEC 61850 device to open its configuration window
On the right pane, select the tab “Device Controller”.
To export the SCL definition, click on the relevant button.

Export ICD Exports the SCL replacing the IED name with the word TEMPLATE.
When and ICD file is used by a system configuration tool, the tool should prompt the user to enter the desired IED name
and IP address.
Export CID Exports the SCL as a Configured IED Description file
Export IID Exports the SCL as a Instantiated IED Description file.

Rev. 1.6 (16-09-2019)
ATTENTION: The CID or IID files contain the correct IED name, but they do not set the IP address. When the CID or IID
file is imported into a system configuration tool, the correct IP address must be entered manually.
(This restricton is because Saitel DP and Easergy T300 RTUs have different ways of defining the network interfaces).
2.5 ICD Editor

New ICD files can be created by Easergy Builder installation. Logical devices and logical nodes can be added using a
database of logical node types and data object types according to IEC 61850-7-4.
After you have created an RTU type and project, enter the window ICD, select ‘Create ICD’, specify the I/O required;
Figure 2-15. Create/Edit a new ICD file
This ICD file can then be edited;

Right click on Server to add a new Logical Device then left click on the new logical device to configure it.
Right click on a Logical Device to add a new Logical Node,
a) select lnClass and DO/DA attributes required,
b) LNodeType ID (if it does not already exist in the DataTypeTemplates),
c) select Logical Node prefix,
d) select Logical Node instance,
e) Add
Similarly, you can add Datasets, Report Control Blocks, GOOSE control blocks, data initial values to Logical Nodes.
Don’t forget to export the ICD file after editing.

Rev. 1.6 (16-09-2019)
Chapter 3. IEC61850 Ed1/Ed2 Client
3.1 IEC61850 Ed1/Ed2 Client Configuration

The client side of the Saitel RTU uses the information supplied in the SCD file and the i61_conf.xml file. Because the
Saitel RTU processes the SCD file it has ‘knowledge’ of all the data models of all the protection devices and the user (via
Easergy Builder) can select exactly which reports are to be enabled and which GOOSE messages are to be subscribed to.
For example, the SCD file from the SCT might contain far more IEDs than required for a specific stage of a project, for
example integration testing of just one bay, the ICT allows the user to specify that only a subset of the total number of
IEDs are to be connected to and only a subset of the total number of datasets are to be enabled.
Figure 3-1. Typical SCD contents
In Figure 3 a typical view of the SCD file is presented;
IED: GTW is the local server data model

IED:SLS is a pure client data model, for a local substation MMS client. (pure clients are highlighted in red to distinguish
them from the downstream IED data models.)
IED: IEDn is a protection device data model. Of course this is just an example in which all the downstream IEDs have
similar names, this is not normally the case.

Rev. 1.6 (16-09-2019)
3.2 Local server data model

The local server data model will always contain at least the ‘SYSTEM’ logical device so that system related information
can be viewed by a local MMS client. In addition, the data model can be modified (e.g. add more logical nodes, datasets,
report control blocks) with the use of Easergy Builder. This can be convenient for monitoring and debugging
communication problems with downstream 61850 protection devices.
Figure 3-2. Typical local server data model for Saitel
3.3 Signal Identification and mapping

3.3.1 The MMS Leaf Concept
IEC61850 uses a hierarchical data model. Logical Devices and Logical Nodes represent branches in the model. Data
Attributes are the “leaves”.
Figure 3-3 introduces the concept of MMS leaves. The figure shows some Logical Nodes for a Logical Device (not shown)

Rev. 1.6 (16-09-2019)
and the LEAFROOT=’TRP_2MMXU1$MX$TotW’ has been expanded to show the two values, VALUE=’instMag’ and
VALUE=’mag’ with the associated QUALITY=’q’ and TIMESTAMP=’t’. In the right-hand side of the figure you can see the
actual values associated with the MMS leaves.
Figure 3-3. The MMS leaf concept
3.3.2 IEC61850 Client Coordinate Syntax

The SCD built or imported into Easergy Builder defines the data model for the IEC61850 server. IEC61850 classifies each
data attribute with a “Functional Constraint” which indicate which IEC61850 services are applicable to each data attribute.
In the Saitel IEC61850 Server, the Functional Constraint also determines how the values are transferred to or from
CoreDB. Data points with functional constraint ST, MX, CO or SP can be mapped to CoreDB variables.
Point mapping limitations limitations
1. STATUS points (fc=ST) can only be mapped in the Status point table.
2. ANALOG points (fc=MX) can only be mapped in the Analog point table.
3. COMMAND points (fc=CO) can be mapped in either the Command or Setpoint table.
4. SETPOINT points (fc=SP) can only be mapped in the Setpoint table.
The IEC61850 Client syntax is as follows
STATUS/ANALOG SOURCE: [LDEVICE/LEAFROOT]VALUE:QUALITY:TIMESTAMP

COMMAND/SETPOINT DESTINATION: [LDEVICE/LEAFROOT]
LDEVICE: Name of the Logical Device in the Local Server that contains the data reference.
LEAFROOT: Common root of the collection of IEC61850 leaves associated with the point in coreDb,
including functional constraint, ST, MX, CO, SP.
VALUE: Name of the leaf associated with the value of the data point mapped in coreDb.
QUALITY: Name of the leaf associated with the quality of the data point mapped in coreDb.
TIMESTAMP: Name of the leaf associated with timestamp of the data point mapped in coreDb.
Examples of the coordinate syntax

STATUS point
<STATUS NAME="GAT22004L_ES510A" DESC="52-2 ACT DISCOR DE POLOS (PROT INTER)">
<SOURCE_COORD BIN_NAME="p143" EXT="[GAT220PI0D04System/RlyGGIO1$ST$Ind11$]stVal:q:t" VMASK="" />
</STATUS>
ANALOG point
<ANALOG NAME="CYNPRS1MMCFR" DESC="Corriente Fase R">

<SOURCE_COORD BIN_NAME="ied99" EXT="[IED99ADQ/MMXU1$MX$A$phsA$]cVal$mag$f:q:t" UM="" />
</ANALOG>
COMMAND point
<COMMAND NAME="QA51_1GGIO1" DESC="SPC control model 1">

<DEST_COORD BIN_NAME="ied9" EXT="[wCR220FE01SPCTRL/QA51_1GGIO1$CO$SPCSO$]" />
</COMMAND>
SETPOINT point
Sometimes it might be appropriate the map a command into the Setpoint table because Isagraf treats Commands and
Setpoints in different ways. This is the case when the command type inside the downstream device is a double point
command.
<SETPOINT NAME="QA52_1GGIO1" DESC="DPC mapped in Setpoint table">
<DEST_COORD BIN_NAME="ied9" EXT="[IED9CTRL/QA52_1GGIO1$CO$Pos$]" />
</SETPOINT>

Rev. 1.6 (16-09-2019)
If the point is really a command, it must contain the functional constraint $CO tag. If the point is a setpoint it must contain
the $SP tag.
<SETPOINT NAME="ATCC1_SP" DESC="Automatic tap changer controller – band center voltage - setMag">
<DEST_COORD BIN_NAME="ied69" EXT="[IED69LD0/ATCC1$SP$BndCtr$setMag$]" />
</SETPOINT>
The EasergyBuilder IEC61850 plugin handles these coordinate strings so there is no need to elaborate more here.
3.3.3 Client side Diagnostic Points

STATUS Point, DIAG:ONLINE indicates whether the IED is connected or not.
ANALOG Point, DIAG:HEALTH indicates the ‘health’ of the IED;
Bit encoding: 0000 0000 0000 0000 0000 000b8 b7b6b5b4 b3b2b1b0
b0 - b0=1 if any NamPlt$configRev mismatch
b1 - b1=1 if any RCB$confRev mismatch
b2 - b2=1 if any RCB has Number of DataSet elements in SCD != Number of DataSet elements in real
device
b3 - b3=1 if any Dataset element order in SCD != Dataset element order in real device
b4 - b4=1 if any Ic_ACSI_GetDataSetDirectory() FAILED
b5 - b5=1 if any Ic_ACSI_SetURCBValues: TrgOps failed
b6 - b6=1 if any Ic_ACSI_SetBRCBValues: TrgOps failed
b7 - b7=1 if any Ic_ACSI_SetURCBValues: RptEna failed
b8 - b8=1 if any Ic_ACSI_SetBRCBValues: RptEna failed
All OK then DIAG:HEALTH = 0
3.3.4 IEC61850 Client side double command points without IsaGraf

The IEC61850 Ed2 client supports double commands without IsaGraf. The command point external coordinate can
now contain an additional symbol;
‘D’ – coreDb value 1 means send BOOL FALSE (Open) downstream, value 2 means send BOOL TRUE (Close)
downstream, other coreDb values won't have effect.
‘DON’ -- coreDb non-zero value means send a BOOL TRUE (Close)
‘DOFF’ -- coreDb non-zero value means send a BOOL FALSE (Open)
For example;
EXT="[UCD01POSICION/INTXCBR1$CO$Pos$]D"
EXT="[UCD01POSICION/INTXCBR1$CO$Pos$]DON"
EXT="[UCD01POSICION/INTXCBR1$CO$Pos$]DOFF"
This conversion of double command points points is necessary because in the case of Switch (LN: XSWI) or
Interruptor (LN: XCBR) or Switch Controller (LN: CSWI) the Pos.ctlVal is BOOLEAN.
Examples;

<COMMAND NAME="XCBRPOS011" DESC="XCBR Pos DPS 1">
<DEST_COORD BIN_NAME="UCD01" EXT="[UCD01POSICION/INTXCBR1$CO$Pos$]D" />
</COMMAND>

<COMMAND NAME="XCBRPOS012C" DESC="">
<DEST_COORD BIN_NAME="UCD01" EXT="[UCD01POSICION/INT_2XCBR2$CO$Pos$]DON" />
</COMMAND>
<COMMAND NAME="XCBRPOS012O" DESC="">
<DEST_COORD BIN_NAME="UCD01" EXT="[UCD01POSICION/INT_2XCBR2$CO$Pos$]DOFF" />
</COMMAND>


<COMMAND NAME="ATCCTAPCHG01" DESC="">
<DEST_COORD BIN_NAME="UCD01" EXT="[UCD01MANDOS/ATCC1$CO$TapChg$]" />
</COMMAND>

Rev. 1.6 (16-09-2019)
3.4 Data sets and report control blocks

3.4.1 Client side limits
Some of the client side limits are defined in the Services section of the SCD file.
Feature Value
Buffered Reports DP CPU866e: supported
DR HUe: supported
T300 HU250: supported
Unbuffered Reports DP CPU866e: supported
DR HUe: supported
GOOSE subscriptions DP CPU866e: supported
DR HUe: supported
Maximum number of IEDs DP CPU866e: Absolute max. 200 (Recommended 120)
DR HUe: 60
T300 HU250: 30
Maximum number of Report Control Blocks (RCB) per IED DP CPU866e: 13
DR HUe: 10
T300 HU250: 10
Maximum total number of Report Control Blocks (RCB) DP CPU866e: 400
across all IEDs DR HUe: 300
T300 HU250: 300
Maximum number of GOOSE Subscriptions DP CPU866e: 128
DR HUe: 32
T300 HU250: 8
Maximum number of GOOSE Publications DP CPU866e: 8
DR HUe: 4
T300 HU250: 4
Maximum number of members in a Report Dataset DP CPU866e: 320
DR HUe: 320
T300 HU250: 320
Maximum number of members in a GOOSE Dataset DP CPU866e: 128
DR HUe: 128
T300 HU250: 128
Table 3-1. Client side limits
3.4.2 Client side Information Report Datasets

3.4.2.1 Supported Common Data Classes
Table 3-2 below shows the CDCs supported by the IEC 61850 controller
Common Data Class Supported Commment
SPS Yes
DPS Yes
INS Yes
ENS Yes
ACT Yes
ACD Yes
BCR Yes
MV Yes
CMV Yes
WYE Yes
DEL Yes
SPC Yes
DPC Yes
INC Yes
ENC Yes
BSC Yes

Rev. 1.6 (16-09-2019)
ISC Yes
SEC No Only used in GSAL - Security violations
HST No Used for histograms
VSS No Text string
SAV No Used with sampled values
SEQ Yes
HMV No Harmonics
HMYE No Harmonics
HDEL No Harmonics
APC No Not normally used in datasets
BAC No Not normally used in datasets
SPG No no fc=ST or MX
ING No no fc=ST or MX
ENG No no fc=ST or MX
ORG No no fc=ST or MX
TSG No no fc=ST or MX
CUG No no fc=ST or MX
VSG No no fc=ST or MX
ASG No no fc=ST or MX
CURVE No no fc=ST or MX
CSG No no fc=ST or MX
DPL No no fc=ST or MX
LPL No no fc=ST or MX
CSD No no fc=ST or MX
CST No only used for service tracking, no fc=ST or MX
BTS No only used for service tracking, no fc=ST or MX
UTS No only used for service tracking, no fc=ST or MX
LTS No only used for service tracking, no fc=ST or MX
GTS No only used for service tracking, no fc=ST or MX
MTS No only used for service tracking, no fc=ST or MX
NTS No only used for service tracking, no fc=ST or MX
STS No only used for service tracking, no fc=ST or MX
CTS No only used for service tracking, no fc=ST or MX
OTS No only used for service tracking, no fc=ST or MX
Table 3-2. Supported CDCs
3.4.2.2 Supported Status (fc=ST) Information Report DataSet Types

The client can process Status (fc=ST) information report datasets mapped to daName, however it is usual to map them
only to doName.
Examples of supported information report Status (fc=ST) datasets;
<DataSet name="DSST1" desc="">
<FCDA ldInst="LD0" prefix="" lnClass="GGIO" lnInst="1" doName="Ind1" fc="ST"/>
<FCDA ldInst="LD0" prefix="" lnClass="XSWI" lnInst="1" doName="Beh" fc="ST"/>
<FCDA ldInst="LD0" prefix="" lnClass="XSWI" lnInst="1" doName="Health" fc="ST"/>
<FCDA ldInst="LD0" prefix="" lnClass="XSWI" lnInst="1" doName="OpCnt" fc="ST"/>
<FCDA ldInst="LD0" prefix="" lnClass="PDIS" lnInst="1" doName="Op" fc="ST"/>
<FCDA ldInst="LD0" prefix="" lnClass="PDIS" lnInst="1" doName="Str" fc="ST"/>
<FCDA ldInst="LD0" prefix="" lnClass="LCCH" lnInst="1" doName="RxCnt" fc="ST"/>
<FCDA ldInst="LD0" prefix="" lnClass="GGIO" lnInst="1" doName="SPCSO1" fc="ST"/>
<FCDA ldInst="LD0" prefix="" lnClass="GGIO" lnInst="1" doName="DPCSO1" fc="ST"/>
<FCDA ldInst="LD0" prefix="" lnClass="GGIO" lnInst="1" doName="ISCSO1" fc="ST"/>
<FCDA ldInst="LD0" prefix="" lnClass="ATCC" lnInst="1" doName="TapChg" fc="ST"/>
<FCDA ldInst="LD0" prefix="" lnClass="ATCC" lnInst="1" doName="TapPos" fc="ST"/>
</DataSet>
<DataSet name="DSST2" desc="">

<FCDA ldInst="LD0" prefix="" lnClass="GGIO" lnInst="1" doName="Ind1" daName="stVal" fc="ST"/>
<FCDA ldInst="LD0" prefix="" lnClass="GGIO" lnInst="1" doName="Ind1" daName="q" fc="ST"/>
<FCDA ldInst="LD0" prefix="" lnClass="GGIO" lnInst="1" doName="Ind1" daName="t" fc="ST"/>
. . . etc
</DataSet>

Rev. 1.6 (16-09-2019)
3.4.2.3 Supported Measures (fc=MX) Information Report DataSet Types

The client can process Analog (fc=MX) information report datasets mapped to daName or doName.
Examples of supported information report Analog (fc=MX) datasets;
<DataSet name="DSMX1">
<FCDA ldInst="LD0" prefix="" lnClass="MMXU" lnInst="1" doName="A" fc="MX"/>
<FCDA ldInst="LD0" prefix="" lnClass="MMXU" lnInst="1" doName="PPV" fc="MX"/>
</DataSet>
<FCDA ldInst="LD0" prefix="" lnClass="MMXU" lnInst="1" doName="A.phsA" fc="MX"/>
<FCDA ldInst="LD0" prefix="" lnClass="MMXU" lnInst="1" doName="A.phsB" fc="MX"/>
<FCDA ldInst="LD0" prefix="" lnClass="MMXU" lnInst="1" doName="A.phsC" fc="MX"/>
<FCDA ldInst="LD0" prefix="" lnClass="MMXU" lnInst="1" doName="PPV.phsAB" fc="MX"/>
<FCDA ldInst="LD0" prefix="" lnClass="MMXU" lnInst="1" doName="PPV.phsBC" fc="MX"/>
<FCDA ldInst="LD0" prefix="" lnClass="MMXU" lnInst="1" doName="PPV.phsCA" fc="MX"/>
</DataSet>
<FCDA ldInst="LD0" prefix="" lnClass="MMXU" lnInst="1" doName="A.phsA" daName="cVal" fc="MX"/>
<FCDA ldInst="LD0" prefix="" lnClass="MMXU" lnInst="1" doName="A.phsA" daName="q" fc="MX"/>
<FCDA ldInst="LD0" prefix="" lnClass="MMXU" lnInst="1" doName="A.phsA" daName="t" fc="MX"/>
<FCDA ldInst="LD0" prefix="" lnClass="MMXU" lnInst="1" doName="A.phsB" daName="cVal" fc="MX"/>
<FCDA ldInst="LD0" prefix="" lnClass="MMXU" lnInst="1" doName="A.phsB" daName="q" fc="MX"/>
<FCDA ldInst="LD0" prefix="" lnClass="MMXU" lnInst="1" doName="A.phsB" daName="t" fc="MX"/>
<FCDA ldInst="LD0" prefix="" lnClass="MMXU" lnInst="1" doName="A.phsC" daName="cVal" fc="MX"/>
<FCDA ldInst="LD0" prefix="" lnClass="MMXU" lnInst="1" doName="A.phsC" daName="q" fc="MX"/>
<FCDA ldInst="LD0" prefix="" lnClass="MMXU" lnInst="1" doName="A.phsC" daName="t" fc="MX"/>
. . . etc
</DataSet>
<FCDA ldInst="LD0" prefix="" lnClass="MMXU" lnInst="1" doName="TotW" fc="MX"/>
<FCDA ldInst="LD0" prefix="" lnClass="MMXU" lnInst="1" doName="TotVAr" fc="MX"/>
</DataSet>
<FCDA ldInst="LD0" prefix="" lnClass="MMXU" lnInst="1" doName="TotW" daName="mag" fc="MX"/>
<FCDA ldInst="LD0" prefix="" lnClass="MMXU" lnInst="1" doName="TotW" daName="q" fc="MX"/>
<FCDA ldInst="LD0" prefix="" lnClass="MMXU" lnInst="1" doName="TotW" daName="t" fc="MX"/>
. . . etc
</DataSet>
3.4.3 Report Control Blocks

3.4.3.1 Overview
The following diagram provides an overview of the relation between a IEC61850 client, a IEC61850 server and the report
control block (RCB) within the server. The server maintains a report control block that allows IEC61850 clients to connect
and enable the associated Information Reports.

Rev. 1.6 (16-09-2019)
Figure 3-4. IEC61850 Report Control Block.
EasergyBuilder must be used to select the RCBs to be enabled from the available RCBs listed in the SCD and modify the
corresponding TrgOps, OptFlds, IntgPd. See image below;

Rev. 1.6 (16-09-2019)
Figure 3-5. Configuring RCBs in Easergy Builder.
3.4.3.2 Supported RCB Types

The IEC61850 Ed2 client can process the following Report Control Block (RCB) types,
RCB Type Dataset Functional Supported by Client

Constraint
Unbuffered ST Yes
Unbuffered MX Yes
Unbuffered Mixed ST, MX Yes
Buffered ST Yes
Buffered MX Yes
Buffered Mixed ST, MX Yes
Table 3-3. Supported Client side RCB types
3.4.3.3 Setting report parameters in Easergy Builder

For the vast majority of projects the Report parameters listed below will work without problem. However sometimes the
parameters may need to be changed to suit particular IEDs, for example some IEDs don’t allow the TrgOps.gi to be set,
and other IEDs insist it is set before allowing the client to force a General Interrogation, these sorts of issues can only be
resolved by reading the PICS and PIXIT documents for the IED or more likely trial and error during FAT or SAT.
Of course if it is required for a particular project, TrgOps.dchg,qchg can be set for Unbuffered Measures Reports, however
it should be done with care because if the thresholds are not set correctly in the IED, reporting floating point values by
dchg can generate a lot of unnecessary MMS traffic.
Usually OptFlds.dataRef is never set because it just makes the Information Report messages larger, however
sometimes it can be useful for debugging if capturing MMS traffic via wireshark.
Usually TrgOps.dupd is never set because it also generates a lot of extra reports for no real gain, if it is set some
IEDs send a report every time the data is refreshed in the IED even if the data value and quality flags are the same.
3.4.3.4 Recommended settings

Buffered Reports
TrgOps: dchg,qchg,gi
OptFlds: seqNum,timeStamp,reasonCode,dataSet,bufOvfl,entryID,configRev
IntgPd: 0
Figure 3-6. Buffered Report parameters

Rev. 1.6 (16-09-2019)
Unbuffered Reports
TrgOps: period,gi
OptFlds: seqNum,timeStamp,reasonCode,dataSet,configRev
IntgPd: 30000 (ms)
Figure 3-7. Unbuffered Report parameters
3.4.3.5 Client side permanent storage for Buffered Reports EntryID

The IEC61850 Ed2 controllers that have nvRAM support permanent storage for the Buffered Report EntryIDs processed
by the client side of the controller. This means that if the CPU resets the EntryIDs will be recovered from nvRAM.
In a redundant CPU system, this means the CPU that comes online will “know” the last received EntryID for each Buffered
Report Control Block so it can receive reports that were buffered in the downstream devices during the CPU change-over.
One analog point is required to store the required EntryID information. The Easergy Builder point wizard can be used to
create the analog point for each EntryID to be stored and store them in nvRam.
3.5 Quality flag mapping

The RTDB (coreDb) has its own quality flags, hence a mapping of the IEC61850 quality bits to coreDb quality flags is
required. There are two types of coreDb q-flags, local and remote. Local flag states are generated as a copy of the
remote flags or locally because of some anomaly detected by the protocol controller. Remote flags states are a translation
of the quality flags received from the remote device.
Table 3-4 shows how the principal IEC 61850 flags are mapped to coreDB-q-flags when data reports are received from
remote IEDs.

Rev. 1.6 (16-09-2019)
Bit(s) IEC61850-7-3 BitString2 or Bit coreDb coreDb

Flags set Flags cleared
Attribute Name Attribute Value Value
0-1 Validity Good 00 IV_RQF,

OV_RQF,
BL_RQF,
NT_RQF,
SB_RQF
Invalid 01 IV_RQF
Reserved 10 IV_RQF
Questionable 11 IV_RQF
10 Source TRUE SB_RQF
(Substituted)
FALSE SB_RQF
(Process)
11 Test TRUE
FALSE
12 OperatorBlocked TRUE BL_RQF
FALSE BL_RQF
Table 3-4. Mapping IEC61850 Validity to CoreDB

If the Validity is Invalid or Questionable, then additional quality detail flags may be sent by the IED. Table 3-5 shows how
these are mapped to coreDB.
Bit(s) IEC61850-7-3 BitString2 or Bit coreDb coreDb

Flag set Flags cleared
Attribute Name Value
2 Overflow TRUE OV_RQF

3 OutofRange TRUE OV_RQF
4 BadReference TRUE IV_RQF
5 Oscillatory TRUE
6 Failure TRUE IV_RQF
7 OldData TRUE NT_RQF
8 Inconsistent TRUE IV_RQF
9 Inaccurate TRUE IV_RQF
Table 3-5. Mapping IEC61850 Quality detail to CoreDB
Example; If IEC61850 data is received with q-bits Validity != Good and OverFlow=True then coreDb q-flags IV_RQF
(Invalid) and OV_RQF (Overflow) will be Set and flags BL_RQF (Blocked), NT_RQF (Not Topical) and SB_RQF
(Substituted) will be Cleared.
In addition to the remote q-flags listed in the table above the IEC61850 controller will set the following q-flag if the client
side detects that the IED is off-line;
IV_LQF (Invalid Local)
Also if the user forces a point via the web browser interface the following q-flags could be set;
BL_LQF (Blocked Local)
SB_LQF (Substituted Local)
3.6 Inverting Dbpos values

The IEC61850 client can be configured to invert the bits when it decodes bType ‘Dbpos’ for double point status
information.

Rev. 1.6 (16-09-2019)
Figure 3-8. Invert double point status

Rev. 1.6 (16-09-2019)
Chapter 4. IEC61850 Ed1/Ed2 Client

PICS
4.1 General
The following ACSI conformance statements are used to provide an overview and details about the Baseline IEC61850
Ed2 Client solution.
— ASCI basic conformance statement,
— ACSI models conformance statement,
— ACSI service conformance statement
The statements specify the communication features mapped to IEC 61850-8-1.
4.2 ASCI basic conformance statement

The basic conformance statement is defined in Table A.4-1.
Table A.4-1 – Basic conformance statement
Client/ Server/ Value/ Comments

Subscriber Publisher
Client-Server roles
B11 Server side (of TWO-PARTY-APPLICATION- 

ASSOCIATION)
B12 Client side of (TWO-PARTY-APPLICATION- Y 
ASSOCIATION)
SCSMs supported
B21 SCSM: IEC 61850-8-1 used Y

B22 SCSM: IEC 61850-9-1 used N
B24 SCSM: other N
Generic substation event model (GSE)
B31 Publisher side 

B32 Subscriber side Y 
Transmission of sampled value model (SVC)
B41 Publisher side 

B42 Subcriber side N 
Y = supported
N or empty = not supported

Rev. 1.6 (16-09-2019)
4.3 ACSI models conformance statement

The ACSI models conformance statement is defined in Table A.4-2.
Table A.4-2 – ACSI models conformance statement

If Server or Client side (B11/12) supported
M1 Logical device Y
M2 Logical node Y
M3 Data Y
M4 Data set Y
M5 Substitution N
M6 Setting group control N
Reporting
M7 Buffered report control Y
M7-1 sequence-number Y
M7-2 report-time-stamp Y
M7-3 reason-for-inclusion Y
M7-4 data-set-name Y
M7-5 data-reference Y
M7-6 buffer-overflow Y
M7-7 entryID Y
M7-8 BufTim Y
M7-9 IntgPd Y
M7-10 GI Y
M7-11 conf-revision Y
M8 Unbuffered report control Y
M8-6 BufTim Y
M8-7 IntgPd Y
M8-8 GI Y
Logging N
M9 Log control N
M9-1 IntgPd N
M10 Log N
M11 Control Y
If GSE (B31/32) is supported
M12 GOOSE Y
M13 GSSE N
If SVC (41/42) is supported
M14 Multicast SVC N

Rev. 1.6 (16-09-2019)

M15 Unicast SVC N
M16 Time Y
M17 File Transfer N
Y = service is supported
N or empty = service is not supported
4.4 ACSI service conformance statement

The ACSI service conformance statement is defined in Table A.4-3 (depending on the statements in Table A.4-1).
Table A.4-3 – ACSI service Conformance statement
Services AA: Client Server Comments

TP/MC (C) (S)
Server
S1 ServerDirectory TP Y
Application association
S2 Associate Y
S3 Abort Y
S4 Release Y
Logical device
S5 LogicalDeviceDirectory TP Y
Logical node
S6 LogicalNodeDirectory TP Y
S7 GetAllDataValues TP Y
Data
S8 GetDataValues TP Y
S9 SetDataValues TP Y
S10 GetDataDirectory TP Y
S11 GetDataDefinition TP Y
Data set
S12 GetDataSetValues TP Y
S13 SetDataSetValues TP N
S14 CreateDataSet TP N
S15 DeleteDataSet TP N
S16 GetDataSetDirectory TP Y

Rev. 1.6 (16-09-2019)

TP/MC (C) (S)
Substitution
S17 SetDataValues TP N
Setting group control

S18 SelectActiveSG TP N
S19 SelectEditSG TP N
S20 SetSGValues TP N
S21 ConfirmEditSGValues TP N
S22 GetSGValues TP N
S23 GetSGCBValues TP N
Reporting
Buffered report control block (BRCB)
S24 Report TP Y
S24-1 data-change (dchg) Y
S24-2 qchg-change (qchg) Y
S24-3 data-update (dupd) Y
S25 GetBRCBValues TP Y
S26 SetBRCBValues TP Y
Unbuffered report control block (URCB)
S27 Report TP Y
S27-3 data-update (dup Y
S28 GetURCBValues TP Y
S29 SetURCBValues TP Y
Logging
Log control block
S30 GetLCBValues TP N
S31 SetLCBValues TP N
Log
S32 QueryLogByTime TP N
S33 QueryLogByEntry TP N
S34 GetLogStatusValues TP N

GOOSE-CONTROL-BLOCK
S35 SendGOOSEMessage MC Y
S36 GetReference TP N
S37 GetGOOSEElementNumber TP N
S38 GetGoCBValues TP Y
S39 SetGoCBValues TP Y

Rev. 1.6 (16-09-2019)

TP/MC (C) (S)
GSSE-CONTROL-BLOCK
S40 SendGSSEMessage MC N
S42 GetGSSEElementNumber TP N
S43 GetGsCBValues TP N
S44 SetGsCBValues TP N

Multicast SVC
S45 SendMSVMessage MC N
S46 GetMSVCBValues TP N
S47 SetMSVCBValues TP N
Unicast SVC
S48 SendUSVMessage TP N
S49 GetUSVCBValues TP N
S50 SetUSVCBValues TP N
Control
S51 Select Y
S52 SelectWithValue TP Y
S53 Cancel TP N
S54 Operate TP Y
S55 Command- TP Y
Termination
S56 TimeActivated-Operate TP N
File transfer
S57 GetFile TP Y
S58 SetFile TP N
S59 DeleteFile TP N
S60 GetFileAttributeValues TP Y
Time
T1 Time resolution of internal clock 1ms
T2 Time accuracy of internal clock ±60 T0 (sec. per year, 0 to 40 ºC)
±240 T0 (sec. per year, -40 to 85 ºC)
T1
T2
T3
T4
T5
T3 Supported TimeStamp - 1ms
resolution

Rev. 1.6 (16-09-2019)
Chapter 5. IEC61850 Ed2 Server

5.1 Server Configuration
5.1.1 Signal identification and mapping
5.1.1.1 The MMS leaf concept
IEC 61850 uses a hierarchical data model. Logical Devices and Logical Nodes represent branches in the model. Data
Attributes are the “leaves”. In general, CoreDB variables correspond to the principal “leaf” attributes such as stVal for
status variables and mag.f for analog variables. See 3.3.1 The MMS Leaf Concept
The MMS mapping uses a text string to indentify data. This string is formed by concatenating the names of the various
components. The general format is of the form
<IEDName><LogicalDeviceName>/
<LogicalNodeName>$<FunctionalConstraint>$<DataObjectName>$<DataAttributeName>
This MMS format is used for defining the mapping to coredb variables.
5.1.1.2 IEC61850 server coordinate syntax

The SCD built or imported into Easergy Builder defines the data model for the IEC 61850 server. IEC 61850 classifies
each data attribute with a “Functional Constraint” which indicate which IEC 61850 services are applicable to each data
attribute.
In the Baseline IEC 61850 Server, the Functional Constraint also determines how the values are transferred to or from
CoreDB. Data points with functional constraint ST, MX, CO or SP can be mapped to CoreDB variables.
Point mapping limitations limitations
1. STATUS points (fc=ST) can only be mapped in the Status point table or the Command point table in the case of
so called GOOSE “Commands”.
2. ANALOG points (fc=MX) can only be mapped in the Analog point table.
3. COMMAND points (fc=CO) can be mapped in either the Command or Setpoint table.
4. SETPOINT points (fc=SP) can only be mapped in the Setpoint table.
The IEC61850 Server coordinate syntax corresponds to the signal identification used by the IEC 61850 protocol mapping
to MMS. This is a complex string that reflects the hierarchy of the IEC 61850 data classes. The formats are not always the
same, because some data classes have sub-data objects and some data attributes have sub-data attributes.
Within Easergy Builder, the coordinates can be defined using text entry or using the Point Wizard (recommended). For
bulk edits to the CoreDB definition, it is convenient to export it to an Excel spreadsheet, make the changes and then re-
import it. In this case, it is essential to use the CoreDB checking button to check for errors.
NOTE: Apart from commands, the coordinate must be defined at the lowest (“leaf-node”) level e.g. cVal$mag$f
Variable type Direction IEC 61850 Functional Coordinate Format

Constraint
Status Destination ST Status [IedNameLDEVICE/LNODE$ST$DO$]DA:q:t
Analog Destination MX Measurand [IedNameLDEVICE/LNODE$MX$DO$]DA:q:t

(IEC 61850
data class
MV)

Rev. 1.6 (16-09-2019)
Variable type Direction IEC 61850 Functional Coordinate Format

Constraint
Analog Destination MX Measurand [IedNameLDEVICE/LNODE$MX$DO$SDO$]cVal$DA:q:t

(IEC 61850
data class
WYE or DEL)
Command Source CO Control [IedNameLDEVICE/LNODE$CO$DO$]
Setpoint Source SP Setting (outside [IedNameLDEVICE/LNODE$SP$DO$DA$]

setting group)
Table 5-1. Server Coordinate syntax

Where:
IedName Name of the IED
LDEVICE Name of the logical device within the IED
LNODE Name of the logical node within the logical device (Prefix + Class + Instance number)
DO Name of the data object within the logical node
SDO Name of the sub-data object within the data object
ST, MX, CO, SP Functional constraint
DA Name of the data attribute associated with the value of the coreDb data point.
Typically, this is stVal for status points; mag$f for analog points (cdc=MV) or cVal$mag$f for analog
points (cdc=DEL, WYE)
q Name of the data attribute for the quality of the coreDb data point.
t Name of the data attribute for the timestamp of the coreDb data point.
5.1.1.3 Mapping examples for T300

Examples of the coordinate syntax applied to T300 variables are shown below.
Type Variable name IEC 61850 Coordinate
Status SC01_MainCSWI1_Pos_stVal [IED1SC01_LD0/MainCSWI1$ST$Pos$]stVal:q:t
Analog SC01_PMr_MMXU1_A_phsA [IED1SC01_LD0/PMr_MMXU1$MX$A$phsA$]cVal$mag$f:q:t
Command SC01_MainCSWI1_PosCtlVal_stVal [IED1SC01_LD0/MainCSWI1$CO$Pos$]
Setpoint PS01_AcPTOV1_LnEna_setVal [IED1PS01_LD0/AcPTOV1$SP$LnEna$setVal$]
Table 5-2. T300 Mapping examples
5.1.1.4 Mapping examples for Saitel

Examples of the coordinate syntax are given in the following sub sections.
STATUS variable
<STATUS NAME=”SPITBAUXD01_OB01_3” DESC=”spare”>
<SOURCE_COORD BIN_NAME=”laq” EXT=”2017020003” VMASK=”” />
<DEST_COORD BIN_NAME=”SPITBAUXD01” EXT=”[SPITBAUXD01SYSTEM/LAQDIGGIO1$ST$Ind4$]stVal:q:t” />
</STATUS>
ANALOG variable
<ANALOG NAME=”SPITBAUXD01_OB30_0” DESC=”Standby Diesel Generator Amps”>

<SOURCE_COORD BIN_NAME=”laq” EXT=”2014010000” VMASK=”” />
Rev. 1.6 (16-09-2019)
<DEST_COORD BIN_NAME=”SPITBAUXD01” EXT=”[SPITBAUXD01SYSTEM/LAQAIGGIO1$MX$AnIn1$]mag$f:q:t” UM=”” />
</ANALOG>
COMMAND variable
<COMMAND NAME=”THUSBAUXD01_OB12_0” DESC=”spare”>

<SOURCE_COORD BIN_NAME=”dnps” EXT=”0:OB12:1” />
<SOURCE_COORD BIN_NAME=”THUSBAUXD01” EXT=”[THUSBAUXD01SYSTEM/LAQDOGGIO1$CO$SPCSO1$]” />
<DEST_COORD BIN_NAME=”laq” EXT=”2015050000” />
</COMMAND>
SETPOINT variable
<SETPOINT NAME=”D002_00008” DESC=”Fault. Voltage Presence Threshold (% Reference Voltage)”>
<PROP NVV=”Y” />
<SOURCE_COORD BIN_NAME=”IED_FLISR_3CB_1” EXT=”[IED_FLISR_3CB_1AB_AC1/PTOV1$SP$StrVal$setMag$]” />
<DEST_COORD BIN_NAME=”Acq” EXT=”2002000032” />
</SETPOINT>
5.1.1.5 Predefined data attribute values

Some data objects/attributes have values defined in the firmware or in the ICD or CID files that are used to build the SCD.
Most of these are read-only but some, such as control timeouts, can be changed using IEC 61850 services.
The most important ones are listed in the following table
Module Data object/attribute Value Update
Any LLN0 Mode on Control service
Any Behaviour on Read only
T300 Modules
All controls except switch position direct, normal security Read only
SC150 CSWI switch position control model select-before-operate, Read / write

enhanced security
(can be modified in SCD)
SC150 CSWI switch position select timeout 5000 ms Read / write

SC150 CSWI switch position operate timeout 15000 ms Read / write

Table 5-3. Pre-defined data attribute values
5.1.1.6 Unmapped data attributes

Data objects/attributes that are define in the IEC 61850 Server SCD but are not mapped to CoreDB will have a value of
zero, quality good and timestamp 1/1/1970 except for ‘Mod’, ‘Beh’ and ‘Health’
5.1.2 Diagnostic coordinates

There are no special diagnostic points associated with the IEC61850 server.
5.1.3 Health enumerations

The T300 modules have single point status variables to indicate error or warning conditions. For IEC 61850, these need to
be defined in CoreDB with formulas to translate single point status variables into enumerated values.
For example, for a T300 HU250
<STATUS NAME="HU01_LLN0_Health_stVal" DESC="Module health enumeration">

Rev. 1.6 (16-09-2019)
<SOURCE_COORD BIN_NAME="Formula" EXT="IF(HU01_LLN0_Health_stVal_Fail,3,

IF(HU01_LLN0_Health_stVal_Warn,2,1))" VMASK="" />
<DEST_COORD BIN_NAME="IED128" EXT="[IED128SYSTEM/LLN0$ST$Health$]stVal:q:t" />
</STATUS>
For example, for a T300 SC150 module
<STATUS NAME="SC01_LLN0_Health_stVal" DESC="Module health enumeration">
<SOURCE_COORD BIN_NAME="Formula" EXT="IF(NOT(SC01_LCCH1_ChLiv_stVal),3,
IF(SC01_LLN0_Health_stVal_Fail,3, IF(SC01_LLN0_CfgHealth_stVal_Warn,2,1)))" VMASK="" />
<DEST_COORD BIN_NAME="IED128" EXT="[IED128SC01_LD0/LLN0$ST$Health$]stVal:q:t" />
</STATUS>
5.2 Local / Remote

5.2.1 CoreDB configuration for local/remote status
For both Saitel and T300, the IEC61850 bin controller will automatically copy the head unit internal local/remote status to
the LLN0 logical node within the SYSTEM logical device. It is not necessary to configure a mapping in CoreDB.
5.2.2 IEC 61850 Definition

IEC61850-7-4 Annex B defines the concept of a hierarchal control authority. The sources of controls are classified into
three levels: remote (from a control centre), station (from a station HMI), or bay (from a local controller). The standard
assumes that there could be several digital inputs from key-switches that are used to set the “Loc” status for the IED or for
specific equipment. In addition, a station HMI could be used to send the LocSta control to one or more IEDs or specific
logical nodes.
IEC61850 -7-500 adds further clarification: “If LocKey is "true", the Loc has to be also set to “true”. If LocKey is in the LLN0
then this is valid for all control functions”
The rules can be summarised in pseudo-code as
IF (XSWI.Loc is true) THEN
{ block bay commands, block station commands, block remote commands }
ELSE IF (CSWI.Loc is true) THEN
{ enable bay commands, block station commands, block remote commands }
ELSE IF (CSWI.LocSta is true) THEN
{ enable station commands, block remote commands }
ELSE
{ enable remote commands }
5.2.3 Saitel CPU Local/Remote Mode

The whole CPU can be put in Local Mode by using the console function i61consoleSetCpuLocRem.
To put the CPU in Local mode, in the console, login as root and type;
SM_CPU866e>//echo “i61consoleSetCpuLocRem 1” > /tmp/BLCMD
To put the CPU in Remote mode, in the console type;
SM_CPU866e>//echo “i61consoleSetCpuLocRem 0” > /tmp/BLCMD
The CPU in Local mode means two things;

(i) No Commands coming from coreDB will be accepted by the client, ie. No downstream IEC61850 Commands or
Setpoints will be issued by the client.
(ii) No IEC61850 Commands coming from an MMS client will be accepted by the server.
5.2.4 Saitel Logical Node Local/Remote Mode

A Logical Node instance can be put in Local Mode by using the console function i61consoleSetLnLocRem.
To put the LN in Local mode, in the console, login as root and type;
SM_CPU866e>//echo “i61consoleSetLnLocRem <ObjectReference> 1” > /tmp/BLCMD

Rev. 1.6 (16-09-2019)
To put the LN in Remote mode, in the console type;

SM_CPU866e>//echo “i61consoleSetLnLocRem <ObjectReference> 0” > /tmp/BLCMD
Where <ObjectReference> is of the following format;
<IED><LDName>/<prefix><LNType><inst>.Loc
For example;
GTWSYSTEM/QA1CSWI1.Loc
Note 1.: You can only change local/remote for Logical Nodes in the local server data model.
Note 2: The ObjectReference is not the same as a CoreDB mapping – it does not contain the functional constraint ‘ST’ nor
the attribute ‘stVal’.
5.2.5 T300 definition

The T300 does not support “station local” commands. Commands are either local (= bay control) or remote. In IEC61850
terms, this means each SC150 switch control module is a separate logical device at the bay controller level.
The Head Unit has push buttons to set its own the local/remote status.
SYSTEM/LLN0.Loc = SYSTEM/LLN0.LocKey (internal)
Configurations created by the T300 Generator are defined so that the HU250 automatically broadcasts the HU250
local/remote status to all the SC150 modules.
SCxx/LLN0.Loc = SYSTEM/LLN0.Loc
For each SC150 module
IF (LLN0.Loc is true) THEN
{ enable local commands , block remote commands }
ELSE
{ block local commands, enable remote commands }
There are no physical inputs to define Loc at the XSWI level. The values are fixed in the ICD templates.
MainXSWI1.Loc = false (bay or remote commands always allowed)
EarthXSWI1.Loc = true (commands via protocol never allowed)
5.2.6 IEC 61850 local/remote modelling for T300
Module Logical Data Description T300 Implementation IEC 61850 Configuration

Node Object
HU250 LLN0 MltLev Configuration that determines Implicitly false Not modelled
whether commands can be
accepted from more than one
level at a time.
All LLN0 LocSta A command, typically from the Not supported. Not modelled
CSWI Station HMI, which sets the
switching authority status for
XSWI the station level.
HU250 LLN0 Loc Status of the local control The T300 Head Unit has push- Automatically sets
behaviour for the logical buttons to change the SYSTEM/LLN0.Loc
device local/remote status OR it can
be configured to use an
external key switch.
HU250 LLN0 LocKey Status of a physical key switch Same as LLN0.Loc Not modelled.
which allows taking over the It is possible to edit SCD
control authority at a specific and mapping if required.
level.
SC150 CSWI LocKey Bay or device key switch Not supported. Not modelled
XSWI

Rev. 1.6 (16-09-2019)
Module Logical Data Description T300 Implementation IEC 61850 Configuration

Node Object
SC150 LLN0 Loc Status of the local control Set by the push buttons or key Defined as destination for
behaviour for the logical switch for the Head Unit, and variable
device copied to all the switch control HU01_LLN0_Loc_stVal
modules
SC150 CSWI Loc Status of the local control Copy of LLN0.Loc Not modelled
behaviour for the bay
controller
SC150 XSWI Loc Status of the local control For main switch, always false Defined in the ICD with fixed
behaviour for the switch (bay or remote commands values
always allowed) (Mandatory according to
For earth switch, always true IEC61850-7-4)
(commands never allowed)
5.2.7 Mapping LocKey

If LocKey is required for a project, it is necessary to add the data object in the SCD. Once defined in the SCD, LocKey
should be mapped as a destination for the existing local/remote variable. For example:
Status Variable HU01_LLN0_Loc_stVal System local / remote status
Source Lioc LLN0_LOCAL
Destination IED1 [IED1SYSTEM/LLN0$ST$LocKey$]stVal:q:t
5.3 Mode & Behaviour

IEC61850 defines some special data objects that are used only by the IEC61850 protocol. These are defined in the SCL
model but are not mapped to CoreDB. They can only be changed using MMS services.
Regardless of the current Mod or Beh state, Mod commands with Test=false will always be accepted.
When other controls are received, the IEC61850 bin controller will check the status of LLN0.Mod; and if it exists, check the
Mod data object for the logical node that contains the control.
Name Type Description
Mod ENC (Controllable) Operating mode of the domain logical node that may be changed by an
operator using IEC 61850 services.
Mandatory for LLN0. Optional for other nodes.
Beh ENS Read-only value, describing the behaviour of a domain logical node. It depends on the
current operating mode of the logical node if it exists and the current operating mode of the
logical device that contains it ('LLN0.Mod').
Mandatory for all nodes.
Table 5-4. Mod/Beh Data Objects

Both Mod and Beh are enumerations. The meaning of each value is given in the following table.
BehaviourModeKind
enumeration item value description
on 1 Normal enabled state.
Data objects will be transmitted with a relevant quality.

Control commands will be accepted and executed.
blocked 2 Process is passively supervised.
Data objects will be transmitted with a relevant quality.

Control commands with Test=false will be accepted but not executed.
Control commands with Test=true will be rejected.

Rev. 1.6 (16-09-2019)
BehaviourModeKind
test 3 Function is operated but results are indicated as test results.
Data objects will be transmitted with q.test=true.

Control commands with Test=true will be accepted.
Control commands with Test=false will be rejected
test/blocked 4 Function is operated in test mode, but with no impact to the process.
Data objects will be transmitted with q.test=true

Control commands with Test=true will be accepted but not executed.
Control commands with Test=false will be rejected.
off 5 Function is inactive but shows its configuration capability.
All communication services work (output with quality.validity=invalid, except Mod, Beh
and Health, which will have q.validity=good).
Control commands to the process will be rejected
Table 5-5. Mod/Beh Enumeration

For full details see IEC61850-7-4 Annex A
5.3.1 Restrictions
Test mode is supported for controls, but not for data reporting. Data objects are always transmitted with q.test = false.
The value of Beh within logical nodes is not updated when LLN0.Beh changes.
5.4 Control Model

5.4.1 CoreDB mapping
Control data objects in the SCL are always defined with both a status data attribute (Functional Constraint=ST) and a
control data attribute (Functional Constraint=CO)
5.4.2 Controls with enhanced security

Commands using enhanced security must have both the status and the control data attributes mapped to CoreDB.
Command SC01_MainCSWI1_PosCtlVal_stVal Switch position requested via Head Unit
Source IED1 [IED1SC01_LD0/MainCSWI1$CO$Pos$]
Status SC01_MainCSWI1_Pos_stVal Main switch filtered position status

Destination IED1 [IED1SC01_LD0/MainCSWI1$ST$Pos$]stVal:q:t
Note: for testing, it is possible to define Formulas in the CoreDB configuration to trigger the update of the status value
when the control value is changed.
5.4.3 Controls with normal security

For commands using normal security it is optional whether to map the status variable. Typically, it is useful to map the
status values for counter preset (INC) commands or commands that toggle a status e.g. “Automation enable/disable”
Command HU01_SysGAPC1_AutoOn_stVal
System automation operation control enable/disable
Source IED1 [IED1SYSTEM/SysGAPC1$CO$Auto$]
Status HU01_SysGAPC1_Auto_stVal

Rev. 1.6 (16-09-2019)
System automation operation status (ON/OFF)

Destination IED1 [IED1SYSTEM/SysGAPC1$ST$Auto$]stVal:q:t
For commands that are simple reset commands, e.g. System automation reset command, the ST data attributes are not
mapped.
5.4.4 Switch blocking and interlocking

The T300 IEC61850 server does not perform any checks of switch control blocking and interlocking at the IEC61850
protocol level.
Each SC150 switch controller module implements blocking depending on the initial switch position and other digital inputs.
The HU250 implements 1-of-n-control for all the SC150 modules and can block commands depending on the state of the
battery and power supply.
IEC61850 defines mandatory data objects BlkOpn and BlkCls for XSWI logical nodes. These have been defined in the
ICD files as status-only data objects with fixed values of false, i.e. not blocked.
5.4.5 Control Service Status / Additional Cause

“Control service status, including normal and failed conditions. The application usually determines the value to use as a
function of the value in some data object (for example, the value in data object 'XSWI.Pos' may result in 'Invalid-position'
or 'Position-reached').” [IEC 61850-7-2]
ControlServiceStatusKind Supported by Saitel / T300

Unknown 0 Command not successful due to unknown Yes
causes.
Not-supported 1 Control action is not supported (for example, a Yes
usually controllable object is not controllable,
such as when 'XCBR.Pos.ctlModel'='status-
only').
Blocked-by-switching- 2 Failure since one of the downstream Loc Yes but only checks
hierarchy switches like in CSWI has the value true. SYSTEM/LLN0.Loc
LN.Loc (if in data model)
Select-failed 3 Cancelled due to an unsuccessful selection Yes
('select' service).
Invalid-position 4 Control action is aborted due to, for example, Enhanced security only
invalid switch position ('XCBR.Pos' or Yes - requires feedback ST to be
'XSWI.Pos'). mapped with control data object
Position-reached 5 Equipment is already in the intended position Enhanced security only
(e.g., 'XCBR.Pos' or 'XSWI.Pos'). Yes - requires feedback ST to be
mapped with control data object
Parameter-change-in- 6 Control action is blocked due to running No
execution parameter change. E.g. applying settings.
Step-limit 7 Control action is blocked because an end No
position of raise/lower command has been
reached (e.g., EndPosR or EndPosL in YLTC,
ATCC or YEFN).
Blocked-by-Mode 8 Control action is blocked because the LN (e.g., Yes
CSWI or XCBR/XSWI) is in a mode (Mod) that
doesn't allow any switching.
Blocked-by-process 9 Control action is blocked due to some external No
event at process level that prevents a successful There is no mechanism to define
operation, for example, blocking indication the link between the control object
(EEHealth in XCBR or XSWI). and the blocking objects/attributes
Blocked-by-interlocking 10 Control action is blocked due to interlocking of No
switching devices ('CILO.EnaOpn.stVal'=false or There is no mechanism to define
'CILO.EnaCls.stVal'=false). the link between the control object
and the interlocking
object/attribute

Rev. 1.6 (16-09-2019)
ControlServiceStatusKind Supported by Saitel / T300

Blocked-by- 11 Control action with synchrocheck is aborted due No
synchrocheck to exceed of time limit and missing synchronism There is no mechanism to define
condition. the link between the control object
and the synchro-check
object/attribute
Command-already-in- 12 'control', 'select' or 'cancel' service is rejected, Yes
execution because control action is already running.
Blocked-by-health 13 Control action is blocked due to some internal No
event that prevents a successful operation There is no mechanism to define
(Health). the link between the control object
and the health object/attribute
1-of-n-control 14 Control action is blocked because another Yes (where domain = the IED)
control action in a domain (for example Returned if another command is
substation) is already running (in any XCBR or received before operTimeout of
XSWI of that domain, 'DPC.stSeld'=true). previous command.
Abortion-by-cancel 15 Control action is aborted due to 'cancel' service. Yes
Time-limit-over 16 Control action is terminated due to exceed of Yes
some time limit.
Abortion-by-trip 17 Control action is aborted due to a trip No
('PTRC.Op.general'=true or
'PTRC.Tr.general'=true).
Object-not-selected 18 Control action is rejected, because control object Yes
was not selected.
Object-already-selected 19 Select action is not executed, because the Yes
addressed object is already selected.
No-access-authority 20 Control action is blocked due to lack of access No
authority.
Ended-with-overshoot 21 Control action executed but the end position has No
overshoot.
Abortion-due-to- 22 Control action is aborted due to deviation No
deviation between the command value and the measured
value.
Abortion-by- 23 Control action is aborted due to the loss of No
communication-loss connection with the client that issued the control. For control models with select
before operate, a select command
should timeout.
For control models with enhanced
security, an operate command will
either succeed or timeout
Blocked-by-command 24 Control action is blocked due to explicit block No
command ('CmdBlk.stVal'=true). The firmware does not check the
CmdBlk object within the owning
logical node.
None 25 Control action successfully executed. Yes
Inconsistent- 26 The parameters between successive control Yes
parameters services are not consistent, for example the
'ctlNum' of 'selectWithValue' and 'operate'
service are different, or the service parameters
use values out-of-range of the supported range.
Locked-by-other-client 27 Another client has already reserved the object. No
The response will be select-failed
Table 5-6. Control Status / Additional Cause

Rev. 1.6 (16-09-2019)
5.5 Data sets and report control blocks

5.5.1 Server side limits
The ICD files define default data sets and report control blocks for each module which are copied into the SCD file.
Feature Value
DP CPU866e: supported
Buffered Reports DR HUe: supported
Unbuffered Reports DP CPU866e: supported
DR HUe: supported
GOOSE Publication DP CPU866e: supported
DR HUe: supported
Maximum number of Logical Devices in server data model DP CPU866e: 2048
DR HUe: 1024
T300 HU250: 128
Maximum number of Logical Nodes in a Logical Device DP CPU866e: 128
DR HUe: 128
T300 HU250: 64
Maximum number of Data Objects in a Logical Node DP CPU866e: 128
DR HUe: 128
T300 HU250: 128
Maximum number of Datasets DP CPU866e: 1536
DR HUe: 256
T300 HU250: 64
Maximum number of attributes in dataset DP CPU866e: 384
DR HUe: 384
T300 HU250: 384
Default number of reporting datasets DP CPU866e: (depends on ICD, configurable)
DR HUe: (depends on ICD, configurable)
T300 HU250: 2 per module
Maximum number of report control block instances DP CPU866e: 3072
DR HUe: 512
T300 HU250: 64
Default number of control blocks per dataset (RptEnabled DP CPU866e: 2 per dataset
max="N") DR HUe: 2 per dataset
T300 HU250: 2 per dataset
Buffered reports – buffer size for each RCB instance DP CPU866e: 300-500 SPS data value changes
DR HUe: 300-500 SPS data value changes
T300 HU250: 300-500 SPS data value changes
Table 5-7. Server side limits
5.5.2 Buffered reports

The server generates buffered or unbuffered reports as defined in the SCL file.
For buffered information reports, the IEC61850 server enables buffering immediately out of the reset using the OptFlds
and TrgOps specified in the SCL file. If a 61850 client connects and enables a BRCB instance and does not change the
OptFlds nor the TrgOps then the server will send all buffered reports to that client.
5.5.2.1 BRCB_BUFFER_SIZE
Each Buffered RCB instance has two circular buffers of size 20kB, one for GI reports and one for event triggered reports.
How many events can be buffered in 20kB? It depends on the Information Report Option Fields and the Common Data
Class in question.
The =S= 61850 Brick is quite efficient in only storing the absolutely necessary data in the buffer.
To calculate how many events this equates to, we need to consider specific DO types.
For Example;
One SPS DO event in a typical Status dataset of 64 SPS DOs.
Each entry in the RCB buffer stores;

Rev. 1.6 (16-09-2019)
The EntryID = 8 bytes

The TimeOfEntry = 10 bytes
The Inclusion Bitstring = 8 bytes
The Data Value, stVal + q + t, 1 + 2 + 12 = 15 bytes
The Reason-for-inclusion = 1 byte
Total 42 bytes
Therefore a server side BRCB buffer could store approximately 20kB / 42 = 487 such SPS events.
5.5.3 Trigger conditions

Due to the internal architecture, not all trigger options are supported.
Abbreviation Description Comment
dchg data-change all changes are reported with both dchg and qchg
dupd data-update (e.g. periodic not supported

update)
qchg quality-change all changes are reported with both dchg and qchg
gi general interrogation
intg integity
5.6 Quality flag mapping

5.6.1 General quality flag mapping
The IEC 61850 Server supports all the IEC61850 quality flags, but internally CoreDB does not.
Head Unit (local) quality flags IEC 61850 Server flags

Good Good
Invalid Invalid
Overflow Overflow
OutOfRange
Invalid Invalid
Failure
Not Topical Questionable
(The point has not been written to the database yet) OldData
Locked operatorBlocked
Locked Manual operatorBlocked

source=substituted
Table 5-8. General quality flag mapping
5.6.2 T300 quality flag mapping

For the T300, the internal communication between the SC150 or Lv150 modules and the HU250 uses IEC 60870-5-104
which has a limited number of quality flags.
SC150 internal quality and reason SC150 (remote) HU250 (local) IEC 61850 Server
quality quality
Rev. 1.6 (16-09-2019)
SC150 internal quality and reason SC150 (remote) HU250 (local) IEC 61850 Server
quality quality
Good. Good Good Good
Value has been correctly acquired.
Questionable + Out-of-range. Not Topical, Invalid, Invalid
Analog inputs only. The input values are Overflow Overflow Overflow
excessive. This is normally due to errors in the OutOfRange
configuration settings.
Invalid + Oscillatory Invalid Invalid Invalid,

Digital inputs only. Input is chattering Failure
Invalid + Failure. Invalid Invalid Invalid,
Analog inputs only. The acquisition hardware Failure
has reported an error.
Invalid Invalid Invalid Invalid

Value has not been calculated e.g. no sensor Failure
configured or calculation period not expired.
[SC150] Not configured Not Topical Questionable

[HU250] The point has not been written to the OldData
database yet
Communications error Invalid Invalid
Failure
Data update locked from web pages Locked operatorBlocked
Manual override of value or quality flags from Locked Manual operatorBlocked

web pages source=substituted
Table 5-9. T300 quality flag mapping
5.7 GOOSE
Easergy Builder is used to configure GOOSE however the details are presented here, the Easergy Builder user should
never have to manually edit the files discussed below, their details are provided here for information only.
5.7.1 GOOSE Publish

The first GOOSE messages published by the IEC61850 Ed2 controller are delayed 2 seconds from startup (going hot) to
give the other SOURCE controllers time to write data to coreDb real time database, this means that when the IEC61850
controller does its first read from coreDb in preparation for sending the GOOSE messages, the data is more likely to be
correct.
An example of GOOSE publish follows, two geese will be published. A device which publishes a GOOSE message,
SERVER in the following example, must have the corresponding GOOSE Control Block declared in the Communication
section of its SCL file imported into Easergy Builder.
<Communication>
<SubNetwork name=”W01”>
<ConnectedAP iedName=”SERVER” apName=”AP1”>
<Address>
172.19.47.21
255.255.255.0
1.1.1.1
1,3,9999,106
106
0001
00000001
0001
</Address>
<GSE ldInst=”LD_GOOSE” cbName=”GCB_GOOSE1”>
<Address>
01-0C-CD-01-00-41
0001
Rev. 1.6 (16-09-2019)
4
002
</Address>
<MinTime unit=”s” multiplier=”m”>300</MinTime>
<MaxTime unit=”s” multiplier=”m”>5000</MaxTime>
</GSE>
<GSE ldInst=”LD_GOOSE” cbName=”GCB_GOOSE2”>
<Address>
</Address>
</GSE>
</ConnectedAP>
</SubNetwork>
</Communication>
In the example above both GCBs are using the same Destination MAC 01-0C-CD-01-00-41 but each has its own unique
APPID, 0001 and 0002 respectively.
In the same SCL file, the device data model must contain the GOOSE control block and associated dataset, for example;
<IED name=”SERVER” desc=”” type=”Saitel” manufacturer=”SE”>
…
<AccessPoint name=”AP1” desc=””>
…
<Server desc=”” timeout=”60”>
…
<Ldevice desc=”” inst=”LD_GOOSE”>
<LN0 lnClass=”LLN0” lnType=”LLN0_0” inst=”” desc=””>
<!–SP16GGIO1 GOOSE Dataset 

<DataSet name=”GOOSE_DS1” desc=””>
<FCDA ldInst=”LD_GOOSE” prefix=”SP16” lnClass=”GGIO” lnInst=”1” doName=”Ind1”
daName=”stVal” fc=”ST”/>
daName=”q” fc=”ST”/>
</DataSet>
<!–SP16GGIO2 GOOSE Dataset 

<DataSet name=”GOOSE_DS2” desc=””>
</DataSet>
<GSEControl name=”GCB_GOOSE1” desc=”GOOSE Publish SP16GGIO1” datSet=”GOOSE_DS1”

confRev=”1” appID=”GOOSE_01” type=”GOOSE”/>
<GSEControl name=”GCB_GOOSE2” desc=”GOOSE Publish SP16GGIO2” datSet=”GOOSE_DS2”
confRev=”1” appID=”GOOSE_02” type=”GOOSE”/>
</LN0>
<LN desc=”Physical device info” lnType=”LPHD_0” lnClass=”LPHD” inst=”1”/>
<LN desc=”16 Single Points” lnType=”GGIO_SP16” lnClass=”GGIO” inst=”1”
prefix=”SP16”/>
<LN desc=”16 Single Points” lnType=”GGIO_SP16” lnClass=”GGIO” inst=”2”
prefix=”SP16”/>
</Ldevice>

Rev. 1.6 (16-09-2019)
</Server>
</AccessPoint>
</IED>
Each GCB must have a unique appID, GOOSE_01 and GOOSE_02 respectively in the example above.
NOTE: APPID used in the GOOSE addressing section of the SCL file and appID used in the GCB section are two different
things.
Please double check configurations and make sure both APPID and appID are unique if publishing to the same
Destination MAC, in fact even if using different Destination MAC addresses it’s good practice to use unique APPID and
appID because it makes diagnosing GOOSE problems easier, ie when observing GOOSE traffic on the network.
The corresponding i61_conf.xml file produced by Easergy Builder will contain the necessary PUBLISHER section to
indicate that this GOOSE message is to be published;
<GOOSE IF=”eth0” ENABLE=”1”>
<RETRANS_CURVE T1=”10” T2=”500” T3=”5000” T0=”30000” K=”3” />
<DECODE OPT=”” />
<PUBLISHER LD=”SERVERLD_GOOSE” GSECB=”GCB_GOOSE1” TIME=”UTC” />
<PUBLISHER LD=”SERVERLD_GOOSE” GSECB=”GCB_GOOSE2” TIME=”UTC” />
</GOOSE>
5.7.2 GOOSE Subscribe

For each GOOSE message to be subscribed to, use Easergy Builder to add an instance of LnodeType LGOS with the
parameters required. For example, if a Saitel device is to subscribe to the two GOOSE messages published by SERVER
as detailed in the previous section, add the following LGOS Logical Nodes,
<LN inst=”1” lnClass=”LGOS” prefix=”” lnType=”LGOS_TYPE”>

<DOI name=”ConfRevNum”>
<DAI name=”stVal”>
<Val>1</Val>
</DAI>
</DOI>
<DOI name=”GoCBRef”>
<DAI name=”setSrcCB”>
<Val>SERVERLD_GOOSE/LLN0$GO$GCB_GOOSE1</Val>
</DAI>
</DOI>
</LN>
<LN inst=”2” lnClass=”LGOS” prefix=”” lnType=”LGOS_TYPE”>
<DOI name=”ConfRevNum”>
<DAI name=”stVal”>
<Val>1</Val>
</DAI>
</DOI>
<DOI name=”GoCBRef”>
<DAI name=”setSrcCB”>
<Val>SERVERLD_GOOSE/LLN0$GO$GCB_GOOSE2</Val>
</DAI>
</DOI>
</LN>
The corresponding i61_conf.xml file produced by Easergy Builder will contain the necessary SUBSCRIBER section to
indicate that this GOOSE message is to be subscribed to;
<GOOSE IF=”eth0” ENABLE=”1”>
<RETRANS_CURVE T1=”10” T2=”500” T3=”5000” T0=”30000” K=”3” />
<DECODE OPT=”” />
<SUBSCRIBER LD=”SERVERLD_GOOSE” GSECB=”GCB_GOOSE1” TIME=”UTC” />
<SUBSCRIBER LD=”SERVERLD_GOOSE” GSECB=”GCB_GOOSE2” TIME=”UTC” />
</GOOSE>
When subscribing to more than one GOOSE message from the same Destination MAC address the APPIDs in the
GOOSE addressing section and the appIDs in the GCBs must be unique.

Rev. 1.6 (16-09-2019)
Chapter 6. IEC61850 Ed2 Server PICS

6.1 General
The following ACSI conformance statements are used to provide an overview and details about the Baseline
IEC 61850 Ed2 Server solution.
— ASCI basic conformance statement,
— ACSI models conformance statement,
— ACSI service conformance statement
The statements specify the communication features mapped to IEC 61850-8-1.
6.2 ASCI basic conformance statement

The basic conformance statement is defined in Table A.4-1.
Table A.6-1 – Basic conformance statement
Client/ Server/ Value/

Subscriber Publisher Comments
Client-Server roles
B11 Server side (of TWO-PARTY-  Y

APPLICATION-ASSOCIATION)
B12 Client side of (TWO-PARTY- 
APPLICATION-ASSOCIATION)
SCSMs supported
B21 SCSM: IEC 61850-8-1 used Y

B24 SCSM: other N
B31 Publisher side  Y

B32 Subscriber side 
B41 Publisher side  N

B42 Subcriber side 
–
Y = supported
N or empty = not supported
6.3 ACSI models conformance statement

The ACSI models conformance statement is defined in Table A.4-2.

Rev. 1.6 (16-09-2019)
Table A.6-2 – ACSI models conformance statement

M1 Logical device Y
M2 Logical node Y
M3 Data Y
M4 Data set Y
M5 Substitution N
M6 Setting group control N
Reporting
M7 Buffered report control Y
M7-6 buffer-overflow Y
M7-7 entryID Y
M7-8 BufTim Y
M7-9 IntgPd Y
M7-10 GI Y
M8 Unbuffered report control Y
M8-6 BufTim Y
M8-7 IntgPd Y
M8-8 GI Y
Logging N
M9 Log control N
M9-1 IntgPd N
M10 Log N
M11 Control Y
If GSE (B31/32) is supported
M12 GOOSE Y
M13 GSSE N
If SVC (41/42) is supported
M14 Multicast SVC N

M15 Unicast SVC N

Rev. 1.6 (16-09-2019)

M16 Time Y
M17 File Transfer N
Y = service is supported
N or empty = service is not supported
6.4 ACSI service conformance statement

The ACSI service conformance statement is defined in Table A.4-3 (depending on the statements in Table A.4-1).
Table A.6-3 – ACSI service Conformance statement

TP/MC I (S)
Server
S1 ServerDirectory TP Y
Application association
S2 Associate Y
S3 Abort Y
S4 Release Y
Logical device
S5 LogicalDeviceDirectory TP Y
Logical node
S6 LogicalNodeDirectory TP Y
S7 GetAllDataValues TP Y
Data
S8 GetDataValues TP Y
S9 SetDataValues TP Y
S10 GetDataDirectory TP Y
S11 GetDataDefinition TP Y
Data set
S12 GetDataSetValues TP Y
S13 SetDataSetValues TP N
S14 CreateDataSet TP N
S15 DeleteDataSet TP N
S16 GetDataSetDirectory TP Y
Substitution
S17 SetDataValues TP N

Rev. 1.6 (16-09-2019)

TP/MC I (S)
Setting group control

S18 SelectActiveSG TP N
S19 SelectEditSG TP N
S20 SetSGValues TP N
S21 ConfirmEditSGValues TP N
S22 GetSGValues TP N
S23 GetSGCBValues TP N
Reporting
Buffered report control block (BRCB)
S24 Report TP Y
S24-3 data-update (dupd) N
S25 GetBRCBValues TP Y
S26 SetBRCBValues TP Y
Unbuffered report control block (URCB)
S27 Report TP Y
S27-3 data-update (dupd) N
S28 GetURCBValues TP Y
S29 SetURCBValues TP Y
Logging
Log control block
S30 GetLCBValues TP N
S31 SetLCBValues TP N
Log
S32 QueryLogByTime TP N
S33 QueryLogByEntry TP N
S34 GetLogStatusValues TP N

GOOSE-CONTROL-BLOCK
S35 SendGOOSEMessage MC Y
S37 GetGOOSEElementNumber TP N
S38 GetGoCBValues TP Y
S39 SetGoCBValues TP Y

Rev. 1.6 (16-09-2019)

TP/MC I (S)
GSSE-CONTROL-BLOCK
S40 SendGSSEMessage MC N
S42 GetGSSEElementNumber TP N
S43 GetGsCBValues TP N
S44 SetGsCBValues TP N

Multicast SVC
S45 SendMSVMessage MC N
S46 GetMSVCBValues TP N
S47 SetMSVCBValues TP N
Unicast SVC
S48 SendUSVMessage TP N
S49 GetUSVCBValues TP N
S50 SetUSVCBValues TP N
Control
S51 Select Y
S52 SelectWithValue TP Y
S53 Cancel TP Y
S54 Operate TP Y
S55 Command- TP Y
Termination
S56 TimeActivated-Operate TP N
File transfer
S57 GetFile TP N
S58 SetFile TP N
S59 DeleteFile TP N
S60 GetFileAttributeValues TP N
Time
T1 Time resolution of internal 1ms
clock
T2 Time accuracy of internal ±60 T0 (sec. per year, 0 to 40 ºC)
clock ±240 T0 (sec. per year, -40 to 85 ºC)
T1
T2
T3
T4
T5
T3 Supported TimeStamp - 1ms
resolution

Rev. 1.6 (16-09-2019)
Chapter 7. IEC61850 Ed2 PIXIT
7.1 Introduction
This chapter specifies the Protocol Implementation eXtra Information for Testing (PIXIT) of the Baseline IEC61850 Ed2
solution. Together with the PICS and the MICS, the PIXIT forms the basis for a conformance test according to IEC61850-
10.
Each section within this chapter specifies the PIXIT for each supported ACSI service model as structured in parts 7-2 and
10 of the IEC61850 standard specifications.
7.2 Association Model

7.2.1 Association parameters
Parameters required or not to be specified when attempting to initiate an association with the RTU
Parameter Description Required Value Comments

IP IP address Yes Default 127.0.0.1
TSEL Transport selector Yes Default 00 01
SSEL Session selector Yes Default 00 01
PSEL Presentation selector Yes Default 00 00 00 01
Ap Title Application Process Title No Default 1,3,9999,33
AeQual Application Entity Qualifier No Default 1
7.2.2 TCP Keep Alive

The TCP_KEEPALIVE function has been implemented on the server side and client side according to part 8 of the IEC
61850 standards and the RFCs which the specification references. Acknowledgements received by the the RTU to keep-
alive messages are not processed.
The IDLE for the keep-alive messages is 5 seconds (1~20, default 5 seconds).
The INTERVAL for the keep-alive messages is 5 seconds (1~IDLE, default 5 seconds).
The Count for the keep-alive messages is 5 times (1~20, default 5 times).
7.2.3 TCP Timeout

[Saitel] The TCP_TIMEOUT is set to approximately one minute. This means the after a cable disconnect the client side
will detect this event after about one minute.
[T300] The TCP_USER_TIMEOUT is set to 30 seconds for all calling sockets. This timout specifies the maximum amount
of time in milliseconds that transmitted data may remain unacknowledged before TCP will forcibly close the corresponding
connection.
7.2.4 Maximum Client associations

The maximum number of simultaneously connected clients supported is configurable in the RTU, with a default value of 3.
The maximum number of simultaneously connected servers supported is configurable in the RTU (Client), with an
absolute maximum of 200.
7.2.5 Aborting associations

When a client aborts its association, the TCP/IP socket is immediately closed by the RTU.
A total of 1024 file descriptors per process are available but it should be noted that these resources are shared with other
network tasks (for example SNTP time synchronisation, FTP, Web server). If no sockets (file descriptors) are available,
the RTU will refuse new association requests from a client.

Rev. 1.6 (16-09-2019)
7.2.6 Authentication Authentication

Authentication is not supported.
7.2.7 MMS PDU Size

The maximum supported MMS PDU size is configurable, and the default value is 65535 bytes.
7.3 Startup time

The typical start-up time of linux boot, basic Ethernet services, following an interruption to the power supply, is
approximately 20 seconds.
Full IEC 61850 services are available after an approximate start-up time of 30 seconds.
7.4 Server Model

7.4.1 Data quality
The RTU supports a subset of the IEC 61850 quality information for measurements (MX) and status (ST).
See section 5.6 Quality flag mapping
Quality Description MX ST Comments

validity – good Y Y
validity – reserved
validity – invalid Y Y
validity – questionable
detailQual – overFlow Y Y
detailQual – outOfRange Y Y
detailQual – badReference
detailQual – oscillatory
detailQual – Failure Y Y
detailQual – oldData Y Y
detailQual – inconsistent
detailQual – inaccurate
Source – process Y Y
Source – substituted Y Y
test
operatorBlocked Y Y
Test mode is not supported for data reporting. Data objects are always transmitted with q.test = false.
7.4.2 Get / Set data values services

The maximum number of data values supported in one GetDataValues and SetDataValues service request is dependent
upon the following elements:
The maximum negotiated size of the MMS PDU.
The total length of all ObjectReferences to be included within the service request.
The GetDataValues and SetDataValues service request parameters should contain an ObjectReference that has a deeper
level than FC.
7.4.2.1 Exceptions
The value of Beh within logical nodes is not updated when LLN0.Beh changes.

Rev. 1.6 (16-09-2019)
7.5 Data Set Model

7.5.1 Data set structure and content
Datasets can exist in any Logical Node of the data model and may contain data in the device data model belonging to the
following Functional Constraints:
• ST – Status Information
• MX – Measurands (analogue values)
7.5.1.1 Datasets Server Side

See 5.5.1 Server side limits
7.5.1.2 Datasets Client Side

See 3.4.1 Client side limits
7.5.2 Dynamic data set creation

Dynamic data set creation is not supported
7.6 Substitution Model

Substitution is not supported
7.7 Setting Group Control Model

Setting Groups are not supported
7.8 Reporting Model

7.8.1 Supported Report Control Block
The RTU supports both buffered (BRCB) and unbuffered (URCB) Report Control Block services.
BRCB and URCB can be defined in any Logical Node of the data model.
Dynamic creation of BRCB or URCB is not supported.
7.8.2 Report Control Blocks

Both BRCB and URCB can be indexed, for the Server Side, <RptEnabled max=”3”/>.
Each instance of the indexed Report Control Block can only be assigned to a single client. Clients may be configured to
directly use a specific indexed instance, or may browse the indexed instances for one that is currently available.
If there is only 1 instance, Both BRCB and URCB can be non-indexed, and the non-indexed BRCB and URCB is visible to
all clients.
7.8.2.1 RCBs Server Side

See 5.5.1 Server side limits
7.8.2.2 RCBs Client Side

See 3.4.1 Client side limits
7.8.2.3 Trigger conditions

The following report trigger conditions are supported:
• integrity
• data-change
• quality-change
• general-interrogation

Rev. 1.6 (16-09-2019)
All changes to internal variables, whether a data change or a quality change or both, are reported as both dchg and qchg.
The following report trigger conditions are not supported:
• data-update
7.8.2.4 Optional fields

The following optional fields are supported:
• sequence-number
• report-time-stamp
• reason-for-inclusion
• data-set-name
• data-reference
• conf-revision
• buffer-overflow
• entryID
• segmentation
7.8.2.5 Format of EntryID

For server side buffered reports, the eight EntryID octets are represented by two unsigned int32 words;
4 Octets 4 Octets
INT32U_1 INT32U_2
The initial value for INT32U_1 and INT32U_2 is 0u.

The INT32U_1 will be an incremented from 0x00000000 to 0xffffffff 1 by 1, then return to next round but the INT32U_2 will
be increased by 1.
7.8.2.6 BufTm of BRCB

The buffer time can be configured in the SCD. Default 100ms. Range 0~3600 ms.
7.8.2.7 Measurement values second change within BufTm

For analogue (FC=MX) information the server behaves as if BufTm has expired and immediately transmit the report for
transmission, then restarts the timer with value BufTm and process the second notification;
Report is sent for URCB immediately.
Report is stored in entry for BRCB immediately, to send immediately or to wait until the communication condition is
allowed depends on the BRCB status.
7.8.2.8 Buffer size of BRCB

The buffer size for each BRCB can be buffered is 20k bytes. Configurable buffer size is not supported.
7.8.2.9 Reservation of RCB

Reservation of RCB is not supported
7.8.2.10 Data set assignment

Before a Report Control Block can be used by a client, a data set must be created and assigned to it. This must be done
during configuration time in the SCD.
7.8.2.11 rptID
The report ID is initialized as the report reference if the configuration is missing; if the report ID is configured, the real
report ID is the same as configuration, the report ID can also be assigned by a client on-line.
7.8.2.12 Segmentation
Segmentation of reports for both BRCB and URCB is supported. The segmentation in option field is not resettable.
Rev. 1.6 (16-09-2019)
7.9 Logging Model

Log Model is not supported.
7.10 Generic Substation Events Model

7.10.1 GSSE model
GSSE is deprecated in Ed2 of IEC61850 and is not supported.
7.10.2 GOOSE model

The following GOOSE services are supported:
SendGOOSEMessage
GetGoCBValues
The SetGoCBValues service is only supported to change the GoEna attribute online.
GOOSE appID in the GooseControlBlocks must be unique in the SCD file, eg;
<GSEControl name=”gooseAIED2” type=”GOOSE” appID=”MGOOSEAIED2” confRev=”1” datSet=”gooseST1”/>
7.10.3 GOOSE Publication

7.10.3.1 Publication IED data model
To publish a goose message from the Saitel RTU, the ICT Easergy Builder loads and parses the SCD file and allows the
user to select which GOIDs are to be published, see figure below.
Figure 7-1. GOOSE Publishers
7.10.3.2 Pre-configured attributes

The following attributes of GoCB are configurable from SCL:
Attribute Description Comments

Name GoCB Name Needed for GoCB reference
Rev. 1.6 (16-09-2019)
DatSet Data set reference

confRev Configuration revision
GoID GoID
fixedOffs Fixed length encoding
MAC-Address Destination Mac Address Default 01-0c-cd-01-01-01
APPID Iecgoose APPID Default 0x3000
VLAN-ID VLAN Identifier Only when VLAN is supported
VLAN-PRIORITY VLAN priority Only when VLAN is supported
7.10.3.3 Commissioning
The data set assigned to the GOOSE Control Block is user-configurable and must be created/assigned to the GoCB at
system configuration time.
When a GoCB is assigned a data set, the NdsCom attribute should be fixed to FALSE. But the RTU should set NdsCom to
TRUE when Dataset is NULL or the length of encoded dataset value exceed Goose maximum size and set GoEna to
False.
7.10.3.4 Simulation/Test
The goose message can be tagged as “simulation” / “test”.
7.10.3.5 Repetition curve

The repetition curve can be set with minTime, MaxTime (these two parameters are from SCL file), and an increasing factor
c (the default c=1.4);
The increment will be
1, (1+c), (1+c)^2, (1+c)^3, (1+c)^4, (1+c)^5, (1+c)^6, …. Until reach the MaxTime;
And a default curve is min = 10, max = 2000, c = 1.4;
7.10.3.6 Ethernet interface for GOOSE

The Ethernet interface for goose is configurable for the RTU, the interface is listed in /mnt/flash/netConfig.xml as for
example;
<DEVICE NAME=”eth0” IP=”192.168.1.100” MASK=”ffffff00” />
And then in the /mnt/flash/cfgFiles/i61_conf.xml file;
<GOOSE IF=”eth0” ENABLED=”1”>
Which means eth0 is used for goose publish and subscribe. These files are updated by the Easergy Builder ICT.
7.10.3.7 Fixed – length encoded GOOSE message

Fixed – length encoded and decode GOOSE is not supported.
7.10.3.8 GOOSE Datasets

The published GOOSE data set can contain:
· Structured data objects.
· Data attributes.
The subscribed GOOSE data set must contain:
· Mapping to Data attribute (daName) level, examples follow;
STATUS DATASET
<FCDA ldInst=”CONTROL” lnClass=”GGIO” lnInst=”1” doName=”Ind1” daName=”stVal” fc=”ST”/>
<FCDA ldInst=”CONTROL” lnClass=”GGIO” lnInst=”1” doName=”Ind1” daName=”q” fc=”ST”/>
<FCDA ldInst=”CONTROL” lnClass=”GGIO” lnInst=”1” doName=”Ind1” daName=”t” fc=”ST”/>
<FCDA ldInst=”CONTROL” lnClass=”CSWI” lnInst=”1” doName=”Pos” daName=”stVal” fc=”ST”/>

<FCDA ldInst=”CONTROL” lnClass=”CSWI” lnInst=”1” doName=”Pos “ daName=”q” fc=”ST”/>
<FCDA ldInst=”CONTROL” lnClass=”CSWI” lnInst=”1” doName=”Pos “ daName=”t” fc=”ST”/>

Rev. 1.6 (16-09-2019)
ANALOG MEASURES DATASET

<FCDA ldInst=”CONTROL” lnClass=”MMXU” lnInst=”1” doName=”TotW” daName=”mag.f” fc=”MX”/>
<FCDA ldInst=”CONTROL” lnClass=”MMXU” lnInst=”1” doName=”TotW” daName=”q” fc=”MX”/>
<FCDA ldInst=”CONTROL” lnClass=”MMXU” lnInst=”1” doName=”TotW” daName=”t” fc=”MX”/>
<FCDA ldInst=”CONTROL” lnClass=”MMXU” lnInst=”1” doName=”PPV.phsAB” daName=”cVal.mag.f” fc=”MX”/>

<FCDA ldInst=”CONTROL” lnClass=”MMXU” lnInst=”1” doName=”PPV.phsAB” daName=”q” fc=”MX”/>
<FCDA ldInst=”CONTROL” lnClass=”MMXU” lnInst=”1” doName=”PPV.phsAB” daName=”t” fc=”MX”/>
Mixed datasets, fc=”ST” and fc=”MX” are supported for GOOSE subscription.
7.10.4 GOOSE Subscription

7.10.4.1 Subscription IED data model
To subscribe to a goose message from an IED, the ICT Easergy Builder loads and parses the SCD file and allows the
user to select which GOIDs are to be consumed, see figure below, in this case the RTU will be configured to subscribe to
appID=GOOSEAIED1 from IED1.
Figure 7-2. GOOSE Subscribers
7.10.4.2 Message validation

The following elements of a GOOSE message header are checked in order to determine the messages validity prior to
processing its data:

APPID goose APPID in the header No Check (this is not the appID in the GCB in the SCL file.)
GoCBRef GoCB Reference Check with configuration

DatSet Data set reference Check with configuration
ConfRev Configuration revision Check with configuration
GoID Goose ID Check with configuration if appeared in goose message.
numDatSetEntries Check with configuration
stNum Status number
sqNum Sequence number stNum and sqNum filter repetition

Rev. 1.6 (16-09-2019)
The following elements of a GOOSE message header are not checked in order to determine the messages validity prior to
processing its data:

Source Mac
Destination MAC
VLAN-ID VLAN Identifier
VLAN-PRIORITY VLAN priority
NdsCom Needs commission
t timestamp
simulation/test
7.10.4.3 Data processing

The data will be automatically decoded and updated if the goose is valid and new status (StNum change) is included in the
message.
Goose messages with or without VLAN tag can be decoded.
The GOOSE subscriber can decode GOOSE data sets containing:
· Data attributes.
7.10.4.4 Repetition process

If the goose is a simple repetition, same StNum, only SqNum increments, it will only update the GoCB attribute, the data
will not be decoded and updated for efficiency reasons.
7.10.4.5 Error detection

The following errors can be detected:
GOOSE_OOO – Out Of Order; stNum is not correct, some new status missing;
GOOSE_TAL – TAL timeout; the second goose was not received in the time allowed to live;
GOOSE_CFG – Configuration mismatch; eg. confRev mismatch, data set name mismatch, data set members mismatch;
GOOSE_OOS – Out Of Sequence; some goose retransmission is missing;
7.10.4.6 Absence of publishing IED

Absence of goose will be detected if no goose is received in the time allow to live with 10ms as safe margin; At start up,
there is no goose received time out is 2*MaxTime. MinTime and MaxTime are specified in the Communication section of
the SCD file for each GCB, eg;
<GSE ldInst=”CONTROL” cbName=”gooseAIED1”>
<Address>
</Address>
</GSE>
7.10.4.7 Simulation/test
When receiving a goose message tagged as “simulation” or “test”, the Saitel RTU will not decode the data and will not
write to its RTDB.
7.10.4.8 NdsCom
When receiving a goose messge tagged as “NdsCom”, the RTU will not decode the data and will not write to its RTDB. If
the RTU data model contains the LGOS instance for this GOOSE message then the NdsCom, St attributes will be
updated.

Rev. 1.6 (16-09-2019)
7.10.4.9 Ethernet interface for GOOSE

The Ethernet interface for goose can be chosen as detailed in the Publish section above.
7.11 Sampled Values Model

Sample values are not supported.
7.12 Control Model

7.12.1 Modes of operation
The following control modes are supported:
Control Models Comments

Status only
Direct with normal security
SBO with normal security
Direct control with enhanced security
SBO with enhanced security
The initial control mode for each data object is defined in the SCD. The SCD may allow the control mode to be modified
using a MMS write request.
Time activated operate (operTm) is not supported.
“Operate-many” is not supported.
Check conditions:
Check Interlocking is not supported (SBOes, DOes).
Check Synchrocheck is not supported.
Originator check is partially supported for SBOes and SBOns

Originator.orCat check is supported.
Originator.orIdent check is not supported.
Local/Remote check is supported.

Mod/Beh check is supported.
‘test’ bit check is supported.
7.12.2 Error code

The following negative response codes are supported:
OBJ_ACCESS_DENIED
OBJ_VALUE_INVALID
OBJ_INVALIDATED
TEMP_UNAVAIL
OBJ_ACC_UNSUPPORTED
TYPE_INCONSISTENT
HW_FAULT
7.12.3 Control service status - AddCause

The supported Additonal causes are described in 5.4.5 Control Service Status / Additional Cause
7.12.3.1 Exceptions
A SelectWithValue request to a control object with control model SBO with normal security returns AddCause “Select-
failed” instead of “not-supported”

Rev. 1.6 (16-09-2019)
A SelectWithValue request to a control object with control model SBO with enhanced security whilst Operate is in progress
returns "1-of-n control" instead of "Command-already-in-execution"
7.13 Time and Time Synchronisation

The Saitel RTU provides various synchronisation options; SNTP, PTP, protocol. The accurancy for SNTP and protocol is
1ms. The accuracy when using a PTP timing source can be quoted as better than 1ms.
7.14 File Transfer Model

File Transfer is not supported.

Rev. 1.6 (16-09-2019)
Chapter 8. Trouble Shooting

8.1 IEC61850 configuration checklist
A configuration checklist is provided below to be used for trouble shooting.
No. Item Details Action
1 The i61_conf.xml file has The Max_Calling_Connections parameter must equal the Check i61_conf.xml
the correct max. calling number of downstream IED connections and in
parameter. Max_Called_Connections must equal the number of MMS /mnt/flash/cfgFiles
clients that will connect to the 61850 server.
<STACK_CFG>
<MMS>
...
<Max_Calling_Connections>10</Max_Calling_Connections>
<Max_Called_Connections>1</Max_Called_Connections>
...
</MMS>
</STACK_CFG>
2 The CID files match the Sometimes the protection devices are updated but the new CID Check CID files.
actual configuration of file is not exported and imported into the SCT to create a new
the protection devices. SCD file.
3 CID files have correct IP Sometimes the IP addresses are changed but the new CID file Check CID files.
addresses. is not exported and imported into the SCT to create a new SCD
file.
4 The RCBs to be enabled Sometimes the ClientLN XML section is not added to the Check SCD file.
by the client contain ReportControl section and so the EasergyBuilder must be used
ClientLN or have been to select the RCBs to be enabled otherwise the 61850 client will
configured using not know it has to enable the report.
EasergyBuilder.
5 RCB confRev in the Sometimes the datasets within the protection device are Check CID files.
SCD file matches the modified which implies an increment in the RCB confRev but
confRev in the protection the new CID file is not exported and imported into the SCT to
devices. create a new SCD file.
Table 8-1. Checklist
8.2 Log files

If an error is encountered in the field two log files are needed to enable analysis.
8.2.1 Saitel: syslog.txt and i61.log files

Two log files exist in /mnt/nvRam, syslog.txt and i61.log. In general information related to coreDb goes in syslog.txt (eg.
Installation of points, initialization of points, parsing of external coordinate strings, etc) and information specific to the
61850 world goes into i61.log (eg. Registering the application callbacks with the brick library, setting various parameters in
the brick data engine, 61850 data model errors, etc).
8.2.2 T300: Syslog and i61log

On the T300, these logs can be viewed and saved as files using the web pagse
8.3 Saitel: IEC61850 Diagnostics

Authorised users can connect to the RTU using a command shell. A number of diagnostic commands are avaialble
The i61StateShow command can be used from the RTU command Shell (serial terminal) to diagnose the state of the
IEC61850 server and client.

Rev. 1.6 (16-09-2019)
Log in to the console shell as root and type echo i61StateShow > /tmp/BLCMD, output like the following should appear;
SM_CPU866e//>echo i61StateShow > /tmp/BLCMD
IEC61850 Server/Client (v10.01.24-3.4.0.0-Ic5977-Plf1984-012) up time 0 days, 3 hours, 12 mins
**MMS STATS**
Calling Connections 361

Calling Connections, OK 4
Calling Connections, Failed 0
Called Connections 0
Called Connections, OK 0
Called Connections, Failed 0
Client Concludes 0
Server Concludes 0
Local Aborts 0
Remote Aborts 356
Rejects Sent 0
Rejects Received 0
Client Requests 44
Client Requests, OK 64
Client Requests, Error 0
Client Variables Read, OK 0
Client Variables Read, Error 0
Client Variables Write, OK 0
Client Variables Write, Error 0
Client InfoRpts Received 6
Client Unsolicited Status 0
Server Indications 40
Server Response, OK 40
Server Response, Error 0
Server Variables Read, OK 0
Server Variables Read, Error 0
Server Variables Write, OK 4
Server Variables Write, Error 0
Server InfoRpts Sent 0
Server Unsolicited Status 0
**IEC-61850 CLIENT CONNECTIONS**
-Server OFFLINE: ‘SPITBB03D01’

. . . etc
+Server ONLINE: ‘SPITBB01D01’
ReportSettings (1,2,2,1,1,1,1)
Ref=’SPITBB01D01/System/LLN0$BR$brcbB01’
---
Config: OK
RCB values:
Device RCB.RptID=IEDP143System/LLN0$BR$brcbB01
Device RCB.DataSet=SPITBB01D01System/LLN0$RTU
Device RCB.confRev=1
SCL RCB.confRev=1
Device DS.numElements=7
SCL DS.numElements=7
Reports Received: 2

---
Config: OK
RCB values:
SCL RCB.confRev=1
Reports Received: 1
Rev. 1.6 (16-09-2019)

---
Config: OK
RCB values:
SCL RCB.confRev=1
Reports Received: 2

---
Config: OK
RCB values:
SCL RCB.confRev=4
Reports Received: 1

. . . etc
**GOOSE**
GOOSE Enabled= 0
The diagnostic information is divided into the following sections;
• MMS STATS
• IEC-61850 CLIENT CONNECTIONS
8.3.1 MMS STATS

Provides client and server side service statistics.
8.3.2 IEC-61850 CLIENT CONNECTIONS

Provides details of client side connections to the IEDs. Can be used to detect problems enabling the information reports in
the IEDs such as confRev mismatch between SCD file and actual IED configuration, number of dataset elements
mismatch.
If the i61StateShow command is not enough to diagnose what is happening then the i61.log file in /mnt/nvRam should be
retrieved and analyzed.
8.4 Saitel: Console trace / Logging to nvRam

The controller allows the user to start realtime tracing to the stdout console. This feature was added to enable
troubleshooting, in particular, it is needed after migrating to a new version of the IEC61850 brick library code.
Be careful when enabling stdout trace, for example if server read tracing is on during an auto-discovery of the server data
model for a large data model an enormous amount of text is printed to stdout and hence the auto-discovery takes a long
time.
Note: Some stdout tracing comes from the IEC61850 brick library itself, this tracing will be taken out eventually, at the
moment we leave it in the build since it is helpful and no worse than all the stuff linux prints to stdout during boot time.

Rev. 1.6 (16-09-2019)
8.4.1 Console trace User Interface

The console interfaces are called as follows;
SM_CPU866e//>echo “<command> <args>” > /tmp/BLCMD
eg; to start level 2 server side tracing of commands;
SM_CPU866e//>echo “i61srvSetDebugFG 1” > /tmp/BLCMD
SM_CPU866e//>echo “i61srvSetDebugLevel 2” > /tmp/BLCMD
eg; to start level 2 client side tracing of connections;
SM_CPU866e//>echo “i61cliSetDebugFG 16” > /tmp/BLCMD
SM_CPU866e//>echo “i61cliSetDebugLevel 2” > /tmp/BLCMD
NOTE: Arguments are decimal values.
8.4.2 FUNCTION: i61srvSetDebugLevel

Use this function from the stdout console to set the server side trace level, four levels are possible, 0 – no trace, 1 – some
trace info, 2 – more info, 4 – even more info.
8.4.3 FUNCTION: i61srvSetDebugFG

Use this function from the stdout console to set the Functional Group.
#define DBG_SRV_NONE 0x0000
#define DBG_SRV_COM 0x0001 /* Commands */
#define DBG_SRV_RD 0x0002 /* Server Read */
#define DBG_SRV_WR 0x0004 /* Server write */
#define DBG_SRV_GOO 0x0008 /* GOOSE related */
#define DBG_SRV_CON 0x0010 /* Connections */
#define DBG_SRV_EVT 0x0020 /* Event from coreDb */
8.4.4 FUNCTION: i61srvDebugStop

Use this function from the stdout console to stop all server side tracing.
8.4.5 FUNCTION: i61cliSetDebugLevel

Use this function from the stdout console to set the client side trace level, four levels are possible, 0 – no trace, 1 – some
trace info, 2 – more info, 4 – even more info.
8.4.6 FUNCTION: i61cliSetDebugFG

Use this function from the stdout console to set the Functional Group.
#define DBG_CLI_NONE 0x0000
#define DBG_CLI_COM 0x0001 /* Commands */
#define DBG_CLI_URCB 0x0002 /* URCB reception */
#define DBG_CLI_BRCB 0x0004 /* BRCB reception */
#define DBG_CLI_GOO 0x0008 /* GOOSE reception */
#define DBG_CLI_CON 0x0010 /* Connections */
#define DBG_CLI_ENARPTS 0x0020 /* Enable Reports */
#define DBG_CLI_LGOSUPD 0x0040 /* LGOS update */

Rev. 1.6 (16-09-2019)
8.4.7 FUNCTION: i61cliDebugStop

Use this function from the stdout console to stop all client side tracing.

Rev. 1.6 (16-09-2019)
8.5 IEC61850 FAQ
Q >What is the real impact of using common switches (not specifically branded as 61850 compliant) in a
configuration where all the devices are in the same LAN?
Ethernet switches that claim to be IEC61850 compliant supposedly guarantee that the grade of service for trip type
messages can be met by using IEEE 802.1Q Priority Tagging/VLAN
Priority tagging/VLAN: Priority tagging according to IEEE 802.1Q is used to separate time critical and high priority bus
traffic for protection of relevant applications from low priority busload.
According to IEEE 802.1Q, conforming Ethernet Switches shall remove IEEE 802.1Q tags that have a VID = 0. This
means that the VLAN ID=0 tagged traffic becomes untagged and any associated priority is also lost. Therefore, VLAN 0
should not be used for operational systems in which priority is needed. Additionally, VLAN ID = 1 is reserved for the
purposes of Ethernet Switch management and therefore should not be used for GOOSE, SV, or GSE traffic.
So it comes down to the types of GOOSE messages (performance class, see below) you wish to exchange in your project,
ie. How urgent they are and the performance of the GOOSE publishers and subscribers involved.
Part 5 Ed2 Section 11 defines Transfer times classes for control and protection.
Transfer time is the time delay between a) the time when a subscribing ‘application function’ in an IED begins to act on the
event information and b) the time when the publishing ‘application function’ started encoding the event information. So it
includes encoding time, time for the signals to propagate on the bus and through switches and the time to decode the
message.
TT1 Transfer time 1000 ms
Trying to meet TT6 and even TT5 is difficult, (Saitel Ed2 standard solution will not meet these transfer time classes, please
remember the Saitel is not a protection device) and means the Ethernet switch must prioritize the urgent GOOSE
message and forward it without delay.
Part 5 Ed2 Section 11 also defines Messages types and performances classes.
Type 1A “Trip” – TT6 or TT5
Type 1B “Others” – TT4
Type 2 – Medium speed messages (“Automatics”) – TT3
Type 3 – Low speed messages (“Operator”) – TT2 or TT1
Q >If one IED is going to publish and to subscribe, is it necessary to define two GCBs each of them with different
parameters (virtual MAC Address and APPID)?
Yes you must use different MAC Addresses (and preferably APPID) if the RTU is both publishing and subscribing, if the
MAC Address is the same then the subscriber task will be overloaded ‘catching’ all the frames that the publisher task is
producing.
It’s a good idea to use different APPIDs to help filtering of GOOSE message by the subscribers, the Saitel (and probably
any other device does something similar) filters on many fields before accepting the frame and decoding all the data it
contains, 1) MAC Address must be correct, then 2) APPID, then 3) appID, then 4) confRev, so if the frame can be dropped
at APPID level it means less processing by the subscriber, even better if the frame can be dropped at MAC Address level.
The appID really must be different for the each ‘application’ so things can be documented accurately and shared between
all 61850 designers involved in the project, eg; a publisher device sends trip data and uses appID = G_HV_TRIP1 and this
is documented (along with the data it contains + the other parameters, MAC, APPID, etc) so anyone who needs this data
knows to subscribe to the frame with appID = G_HV_TRIP1.
<GSEControl name=”GCB_GOOSE1” desc=”HV Trip data” datSet=”DR_DS_GOOSE” confRev=”1”
appID=”G_HV_TRIP1” type=”GOOSE” />
> I need to remotely reboot the CPU866e and I wasn’t able to do it because root user is not able to connect by
SSH, how do I do it?

Rev. 1.6 (16-09-2019)
If the CPU is straight from fabrication the default user is ‘admin’ and the password is ‘12345678’, if you have defined your
own users for the project in question. Ie you have downloaded a configuration to the CPU before, then you can just use
one of the users you defined.
The only method available for remote reboot is via Easergy Builder, it is assumed you have connectivity through the public
network to the substation LAN.
Click on the button indicated below to reboot the CPU.
Figure 8-1. Remote reboot of CPU from Easergy Builder
Then you will be asked for a user name and password, you can use one of your existing user names, and choose which
CPU to reboot in the case of a dual system.
Figure 8-2. Reboot CPUA, CPUB or both
Enter the user credentials and click the tick button.

Rev. 1.6 (16-09-2019)
Chapter 9. IEC 61850 Overview

This chapter introduces some of the main concepts of IEC 61850.
9.1 Station Level, Bay Level and Process Level

The IEC61850 standard was developed using the strengths of the following three methods: functional decomposition, data
flow, and information modelling.
Functional decomposition is used to understand the logical relationship between components of a distributed function and
is presented in terms of logical nodes that describe thefunctions, subfunctions and functional interfaces.
Data flow is used to understand the communication interfaces that must support the exchange of information between
distributed functional components and the functional performance requirements.
Information modelling is used to define the abstract syntax and semantics of the information exchanged and is presented
in terms of data object classes and types, attributes, abstract object methods (services) and their relationships.
The objective of the standard was to specify requirements and to provide a framework to achieve interoperability between
the IEDs supplied from different suppliers.
The allocation of functions to devices (IEDs) and control levels is not fixed. The allocation normally depends on availability
requirements, performance requirements, cost constraints, the state of the art of technology, utilities’ philosophies etc.
Therefore, the standard should support any allocation of functions.
In order to allow a free allocation of functions to IEDs, interoperability should be provided between functions to be
performed in a substation but residing in equipment (physical devices) from different suppliers. The functions may be split
in parts performed in different IEDs but communicating with each other (distributed function). Therefore, the
communication behaviour of such parts called logical nodes (LN) has to support the requested interoperability of the IEDs.
The functions (application functions) of an SAS are control and supervision, as well as protection and monitoring of the
primary equipment and of the grid. Other functions (system functions) are related to the system itself, for example
supervision of the communication.
Functions can be assigned to three levels: the station level, the bay level and the process level.

Rev. 1.6 (16-09-2019)
Figure 9-1. IEC61850 Station level, Bay level and Process level.
Process level devices are typically remote I/Os, intelligent sensors and actuators. Bay level devices consist of control,
protection or monitoring units per bay. Station level devices consist of the station computer with a database, the operator’s
workplace, interfaces for remote communication, etc.
9.2 Data modelling and services

Logical nodes can only interoperate with each other if they are able to interpret and to process the data received (syntax
and semantics) and the communication services used. Thus it is necessary to standardise data objects assigned to
logical nodes and their identification within the logical nodes. Data and services of an application can be modelled in three
levels. Level 1 describes abstract models and communication services used to exchange information between the logical
nodes. Levels 2 and 3 define the application domain specific object model. This includes a specification of data classes
with attributes and their relation to logical nodes.
Level 1: Abstract Communication Service Interface (ACSI)

The ACSI specifies the models and services used for access to the elements of the domain (substation automation)
specific object model. Communication services provide mechanisms not only for reading and writing of object values, but
also for other operations, for example for controlling primary equipment.
Level 2: Common Data Classes

The second level defines “Common Data Classes” (CDC). A common data class defines structured information consisting
of one or more attributes. The data type of an attribute may be a foundation type (for example, BOOLEAN, INTEGER, …)
as defined in IEC 61850-7-1. More data types are defined as common data attribute types in level 2. Data classes as
defined in level 3 are specialisations of CDCs according to their specific use in the application context.
Level 3: Compatible logical node classes and data classes

This level defines a compatible object model specifying logical node classes and data classes. No additional specification
is required as the identification and meaning (semantics) of the logical node and data classes are defined. An example for
a data class is ’switch position with quality and time stamp’.
Figure 9-2. Logical Node XSWI and Data.
9.2.1 Data modelling – the Leaf concept

Rev. 1.6 (16-09-2019)
9.3 Substation Configuration Language (SCL)

The Substation Configuration Langage (SCL) describes a model of the following;
• The primary (power) system structure: which primary apparatus functions are used, and how the apparatus are
connected. This results in a designation of all covered switchgear as substation automation functions, structured according
to IEC 61346-1. This section of the SCL file is not used by the IEC61850 Ed2 controller.
• The communication system: how IEDs are connected to subnetworks and networks, and at which of their communication
access points (communication ports).
• The application level communication: how data is grouped into data sets for sending, how IEDs trigger the sending and
which service they choose, which input data from other IEDs is needed.
• Each IED: the logical devices configured on the IED, the logical nodes with class and type belonging to each logical
device, the reports and their data contents, the (pre-configured) associations available; and which data shall be logged.
• Instantiable logical node (LN) type definitions. The logical nodes as defined in IEC 61850-7-x have mandatory, optional
and user defined DATA (here abbreviated DO) as well as optional services, and are therefore not instantiable. In this
document, instantiable LNTypes and DOTypes are defined as templates, which contain the really implemented DOs and
services.
• The relations between instantiated logical nodes and their hosting IEDs on one side and the switch yard (function) parts
on the other side.
SCL allows the specification of user defined DOs as an extension of standard LN classes as well as completely user
defined LNs according to the rules of IEC 61850-7-4. This means that the appropriate name space attributes shall be
defined in the logical node types, and their value shall appear in the SCL file.
Part 6 of the IEC61850 standard introduces the concept of a Substation Control Language which is in fact a collection of
XML schemas, the basic flavors are as follows;
• ICD: IED Capability Description
• CID: Configured IED Description
• IID: Instantiated IED Description (CID file for an Ed2 device)
• SCD: Substation Configuration Description
• SSD: Substation Specification Description; here a pure version without IEDs, and a version with some already
known IEDs is introduced.
9.4 IEC61850 Engineering
Engineering of a substation automation system may start either with the allocation of functionally pre-configured devices to
switchyard parts, products or functions, or with the design of the process functionality, where functions are allocated to
physical devices later based on functional capabilities of devices and their configuration capabilities. Often a mixed
approach is necessary: a typical process part such as a line bay is pre-engineered, and then the result is used within the
process functionality as often as needed. For SCL, this means that it must be capable of describing:
a) A system specification in terms of the single line diagram, and allocation of logical nodes (LN) to parts and equipment of
the single line to indicate the needed functionality.
b) Pre-configured IEDs with a fixed number of logical nodes (LNs), but with no binding to a specific process, may only be
related to a very general process function part.
c) Pre-configured IEDs with a pre-configured semantic for a process part of a certain structure, for example a double
busbar GIS line feeder.
d) Complete process configuration with all IEDs bound to individual process functions and primary equipment, enhanced
by the access point connections and possible access paths in subnetworks for all possible clients.
e) As item d) above, but additionally with all predefined associations and client server connections between logical nodes
on data level. This is needed if an IED is not capable of dynamically building associations or reporting connections (either
on the client or on the server side).

Rev. 1.6 (16-09-2019)
Case e) is the complete case. Both cases d) and e) are the result after SAS engineering, while case a) is a functional
specification input to SAS engineering, and b) and c) are possible results after IED pre-engineering.
The scope of SCL is restricted to these purposes:
1) SAS functional specification (point a) above),
2) IED capability description (points b)and c) above), and
3) SA system description (points d) and e) above)
for the purpose of system design, communication engineering and the description of the engineered system
communication for the device engineering tools in a standardised way. This is reached by defining an object model
describing the IEDs, their communication connections, and their allocation to the switchyard, and a standardized way to
describe how this model shall be represented in a file to be exchanged between engineering tools. The resulting object
model could also be the base for other engineering tasks, possibly with some additions. Therefore, and because of the
additional needs of SCSMs, the standard considers the language as the core model, and defines how extensions of this
core model for SCSMs as well as other (engineering) purposes can be done in a standardised way.
Figure 1-3 explains the usage of SCL data exchange in the above-mentioned engineering process. The shaded text boxes
above the dashed line indicate where SCL files are used. The text box IED capabilities corresponds to a result of steps b)
and c) above, the text box System specification corresponds to step a) above, the text box Associations. at the right to
steps d) or e) above.
The IED Configurator is a manufacturer-specific tool that shall be able to import or export the files defined by this part of
IEC 61850. It provides IED-specific settings and generates IEDspecific configuration files, or it loads the IED configuration
into the IED.
An IED can only be considered compatible in the sense of the IEC 61850 series, if:
• It is accompanied either by an SCL file describing its capabilities, or by a tool, which can generate this file from the IED.
• It can directly use a system SCL file to set its communication configuration, as far as setting is possible in this IED (i.e. as
a minimum, its needed addresses), or it is accompanied by a tool which can import a system SCL file to set these
parameters to the IED.
The System Configurator Tool is an IED independent system level tool that shall be able to import or export configuration
files defined by this part of IEC 61850. It shall be able to import configuration files from several IEDs, as needed for
system level engineering, and used by the configuration engineer to add system information shared by different IEDs.
Then the system configurator shall generate a substation related configuration file as defined by this part of IEC 61850,
which may be fed back to the IED Configurator for system related IED configuration. The System Configurator should also
be able to read a System specification file for example as a base for starting system engineering, or to compare it with an
engineered system for the same substation.
The Figure below identifies the core components of the 61850 engineering flow;
a) The System Configuration Tool (SCT) such as SET or Helinks.
b) The IED Configuration Tool (ICT) such as Easergy Builder.
c) The IEDs to be configured and
d) The Engineering Workplace that send the SCL configuration files to the appropriate IEDs.

Rev. 1.6 (16-09-2019)
Figure 9-3. IEC61850 Substation Engineering.

Rev. 1.6 (16-09-2019)
Chapter 10.Annexes
10.1 Glossary
Term Description
ACSI Abstract Communication Service Interface
CID Configured IED Description. A type of SCL configuration file describing the
configuration for a specific, single IED. IEC 61850 Edition 1 term for the configuration
file loaded onto an IED. The simplest form of an CID is a copy of the ICD with a
specific IED name and IP address.
coreDb Real time database of the Baseline Software Platform.
CPU Central Processing Unit
DB Database
DO Data Object – part of a logical node object representing specific information for
example status or measurement
DOes Direct Operate with enhanced security. A control mode that monitors the initial and final
state of the controlled value. (Rarely used)
DOns Direct Operate with normal security. A control mode without monitoring the controlled
value. Used for controls that do not change external equipment, e.g. counter reset.
FC Functional Constraint – property of a data-attribute that indicates the services for

example read value, write value, substitute value, etc. that may be applied to that data
attribute
GOOSE Generic Object Oriented Substation Event (GOOSE). A mechanism for the fast
transmission of data. A GOOSE message is published by one IED and received by one
or more other IEDs. The action of each subscriber depends on its own configuration
and functionality.
HU_A Saitel DR advanced HU.
HU_AF Saitel DR advanced HU with acquisition.
HU_B Saitel DR basic HU.
HU250 Head Unit module for the T300 Feeder RTU
I/O Input / Output.
ICD IED Capability Description. A type of SCL configuration file that is a template
description of a single type of IED.
IEC International Electrotechnical Commission
IED Intelligent Electronic Device
IID Instantiated IED Description. A type of SCL configuration file describing the
configuration for a specific, single IED. IEC 61850 Edition 2 term for the configuration
file loaded onto or read from an IED.
LAN Local Area Network o también Red de Área Local
Configuring IEC61850 A
Rev. 1.6 (16-09-2019)
Term Description
LD Logical Device – a group of Logical Nodes
LN Logical Node – a group of data objects
LV150 LV Measurement module for the T300 Feeder RTU
MICS Model Implementation Conformance Statement
MMS Manufacturing Message Specification (ISO 9506).

A client/server protocol with a specific communication service mapping defined in IEC
61850-8-1
PICS Protocol Implementation Conformance Statement
PIXIT Protocol Implementation eXtra Information for Testing
PS50 Power supply with communications module for the T300 Feeder RTU
RAM Random Access Memory
RCB Report control block
URCB Unbuffered report control block
BRCB Buffered report control block
RTU Remote Terminal Unit
SBO Select Before Operate
SBOes Select Before Operate with enhanced security. A control mode that monitors the initial
and final states of the controlled value e.g. switch position. Recommended for switch
gear.
SBOns Select Before Operate with normal security. A control mode that does not monitor the
controlled value. (Rarely used)
SC150 MV Switch Controller module for the T300 Feeder RTU
SCADA Supervisory Control and Data Acquisition
SCD Substation Configuration Description. A type of SCL configuration file that describes
the configuration for all the IEDs in a specific system.
SCL System Configuration Language. Defined in IEC 61850-6
SCSM Specific Communication Service Mapping
SM_CPU866 Saitel DP CPU (standard).
SM_CPU866e Saitel DP CPU (advanced).
SV Sampled values
T300 A modular Feeder Rermote Terminal Unit
TCP Transport Control Protocol.
Table 10-1. Glossary
Configuring IEC61850 B
Rev. 1.6 (16-09-2019)
10.2 IEC 61850 Document References

IEC 61850-2: Communication networks and systems in substations – Part 2: Glossary
IEC 61850-5: Communication networks and systems in substations – Part 5: Communication requirements for functions
and devices models
IEC 61850-6, Communication networks and systems for power utility automation – Part 6 Configuration description
language for communication in electrical substations related to IEDs
IEC 61850-7-1: Communication networks and systems for power utility automation – Part 7-1: Basic communication
structure – Principles and models
IEC 61850-7-2: Communication networks and systems for power utility automation – Part 7-2: Basic information and
communication structure – Abstract communication service interface (ACSI)
IEC 61850-7-3, Communication networks and systems for power utility automation – Part 7-3: Basic communication
structure – Common data classes
IEC 61850-7-4, Communication networks and systems for power utility automation – Part 7-4: Basic communication
structure – Compatible logical node classes and data object classes
IEC 61850-8-1, Communication networks and systems for power utility automation – Part 8-1: Specific communication
service mapping (SCSM) – Mappings to MMS (ISO 9506-1 and ISO 9506-2) and to ISO/IEC 8802-33)
IEC 61850-9-2, Communication networks and systems for power utility automation – Part 9-2: Specific communication
service mapping (SCSM) – Sampled values over ISO/IEC 8802-33)
10.3 Functional Constraints

IEC 61850 classifies data attributes with a “Functional Constraint”. This is a key concept for understanding the data
mapping.
[From IEC61850-7-2] Functional constraint indicates services applicable to a specific data attribute.
From an application point of view, the data attributes are classified according to their specific use. Some attributes are
used for controlling, other for reporting and logging, or measurements or setting groups, or the description of a specific
data attribute.
The functional constraint (FC) serves as a data filter in the sense of defining the services applicable to specific data
attributes of common data classes (defined in part IEC 61850-7-3).
Code Description
ST Status information (discrete values)
MX Measurands (analogue values)
CO Control
SP Setting (outside setting group)
SV Substitution
CF Configuration
DC Description
SG Setting group
SE Setting group editable
SR Service response
OR Operate received
BL Blocking
Configuring IEC61850 C
Rev. 1.6 (16-09-2019)
Code Description
EX Extended definition (application name space)
Configuring IEC61850 D
10.4 Changes from IEC 61850 Ed1 to Ed2
10.4.1 Data model changes
• Scope changed from substation to “power utility”
• Many Logical Nodes from applications outside the substation and power quality have been added
• Hierarchy of logical devices using the GrRef data object. This enables to turn on/off certain protection functions using
LLN0.Mod
• Private extensions are now limited to private Logical Nodes and Data Objects
• Added protection settings to all Pxxx logical nodes
10.4.2 Communication changes

• Extended name length to 64/64 (mandatory)
• Switch the subscription of Simulated GOOSE <> Real GOOSE using the LPHD.SimSt
• GOOSE fixed length encoding to improve performance
• Service tracking; one client can monitor what other client(s) are doing
• Supervision Logical Nodes:
• GOOSE subscription supervision = LGOS
• Sampled Values subscription supervision = LSVS
• Time management and supervision = LTMS, LTIM
• Well defined situations for each error code
• More precise control and reporting specifications
• Clarified the use of Mod = test and Operate with Test=True
• Improved Local / Remote on local, station and remote level
10.4.3 SCL changes

• Many new SCL attributes to improve the exchange between SCL tools
• Indexing of report control blocks is specified in SCL
• SCL schema = 2007B
• New SCL file extension
• “.IID” = Instantiated IED description
• “.SED” = System Exchange Description to support system tools from different projects
• Setting group editing: FC=SE (was FC=SG)
10.5 Configuration Files

These files are managed by Easergy Builder. Examples are provided for information only,
10.5.1 i61_conf.xml file

The i61_conf.xml file contains the configuration parameters that are entered in Easergy Builder to complement the
information in the SCD file. For example, it contains the configuration for activating report control blocks in the remote
devices.
<?xml version="1.0" standalone="yes"?>
<IEC61850_CFG>
<ENV_CFG>
<SCL_PATH VALUE="/mnt/flash/cfgFiles/" />
<SCL_FILE VALUE="test003_ed2_30ied_product_naming.scd.exi" />
<IC_LOG_PATH VALUE="/mnt/nvRam/" />
<IC_LOG_FILE VALUE="i61.log" />
Rev. 1.6 (16-09-2019)
<IC_LOG_LEVEL VALUE="3" />
<IC_LOG_TYPE VALUE="2" />
</ENV_CFG>
<APP_CFG>
<SERVER ID_BIN="GTW" MAX_N_POINTS="5000">
<STARTUP_CFG IED_NAME="GTW" ACCESS_POINT_NAME="GTW_AP" />
<BRCB BUF_MAX_SIZE="100000" />
</SERVER>
<CLIENT MAX_RNODES="30" TIMEOUT="3" INVERT_DBPOS="FALSE" ORIDENT="Saitel" ORCAT="3">
<REMOTE_NODE IED="IED1" AP="IED1_AP">
<REPORT RCB="CONTROL/LLN0$BR$brcbA01" TRG="011001B" OPTS="011110111B" INTGPD="0" />
<REPORT RCB="STATUS/GGIO1$BR$brcbA01" TRG="011001B" OPTS="011110111B" INTGPD="0" />
<REPORT RCB="STATUS/GGIO2$BR$brcbB01" TRG="011001B" OPTS="011110111B" INTGPD="0" />
</REMOTE_NODE>
</REMOTE_NODE>
</REMOTE_NODE>
… etc
</CLIENT>
<GOOSE IF="eth0" ENABLED="1">
<RETRANS_CURVE T1="10" T2="500" T3="5000" T0="30000" K="3" />
<PUBLISH GOID="GTWIED1_CONTROL/LLN0$GO$gooseAIED1" />
<PUBLISH GOID="GTWIED1_CONTROL/LLN0$GO$gooseBIED1" />
<SUBSCRIBE GOID="GOOSEAIED1" DST_MAC="01-0C-CD-01-01-01" />
<SUBSCRIBE GOID="GOOSEBIED1" DST_MAC="01-0C-CD-01-01-01" />
</GOOSE>
<TCP_KEEPALIVE>
<TCP_KEEPIDLE VALUE="5" />
<TCP_KEEPCNT VALUE="5" />
<TCP_KEEPINTVL VALUE="5" />
</TCP_KEEPALIVE>
</APP_CFG>
<STACK_CFG>
<MAX_MMS_PDU VALUE="65535" />
<MAX_CALLING VALUE="30" />
<MAX_CALLED VALUE="3" />
</STACK_CFG>
<TOOL_SETTINGS>
<SERVER_ONLY VALUE="N" />
</TOOL_SETTINGS>
</IEC61850_CFG>
10.5.2 SCD file

The SCD file needs to be created separately, it should be created at the IEC61850 system configuration level, ie above
the IED configuration level by someone who has a view of the whole substation and the necessary dataflow between
IEC61850 devices, normally this is provided by the SCT (System Configuration Tool) such as =S= SET or Helinks, in fact
for mixed edition / mixed vendor solutions you must use =S= SET or Helinks.
The SCD file will contain the IEC61850 data model for the server side of the controller and in addition it will contain the
data models of each of the downstream servers that the client side of the controller will connect to.
10.5.2.1 SCL Communication Section

The first section of importance for the Saitel RTU is the <Communication> section which lists all the IEC61850 devices
connected to the IEC61850 network for the substation in question. The client side of the IEC61850 controller uses the IP
addresses listed here in order to establish the connections with the downstream IEC61850 protection devices. If the
IEC61850 controller is not establishing connections with the downstream servers this is the first section to be checked, the
IP addresses might be incorrect.
Configuring IEC61850 B
NOTICE
The IEC61850 Ed2 controller does not use the Saitel Baseline 'chan' module.
10.5.2.2 SCL IED Section

Each IEC61850 device connected to the IEC61850 network will have an associated IEC61850 data model and this data
model is listed in the corresponding IED section. Each data model is a collection of logical devices each of which being
constructed from the building blocks listed in the DataTypeTemplate section at the end of the SCL file. The building
blocks are the types of logical nodes (LNodeType) available and the definition of a specific data model creates instances
of the logical node types. Once the instances of logical node types have been created the report data sets can be defined
and associated with a report control block.
From the DataTypeTemplate section we can see that each logical node is made up of a collection of data object types
(DOType) and each data object type is made up of a collection of data attribute types (DAType) or other data object types
if it's a composite type. Finally each data attribute type is a collection of basic types (BOOLEAN, INT8U, Octet64, etc) or
enum types.
Each IED section in the SCD file will contain the following subsections;
• <Services> - This section defines the services offered by the server so that a client has some idea of what the
server has to offer.
• <AccessPoint> - This section defines the name of the Access point for this IED, this is used by the client when
connecting to the server.
• <Server> - This tag marks the beginning of the definition of the server’s IEC61850 data model.
• <LDevice> - This IEC61850 data model consists of a number of Logical Devices and each Logical Device
consists of a number of Logical Nodes.
• <LN0> - Each Logical Device must have a Logical Node 0, lnClass=”LLN0”. This is a special Logical Node.
• <LN> - The logical nodes that make up the data model.
• <DataSet> - Definition of a list a data references to be sent by an IED in an Information Report.
• <ReportControl> - Definition of the Report Control Block associated with a DataSet, ie when to send the report,
what to include in the report and whether a report control block instance has been reserved by a client.
• <DOI> - Data initialization values, IED server inital values are of no interest to the Saitel RTU IEC61850 client.
10.5.2.3 SCL Services Section

For an IEC61850 Ed2 device the Services section of the SCL file is far more important than it was for Ed1 solutions. For
Ed2 devices the Services section provides information about both the server side and client side. In this section we define
the services supported.
IEC61850-6 Ed2 Table 11 defines the Service capabilities, there are some setting and configuration capabilities which
may be performed online, per SCL configuration, or just have fixed values. These are indicated by the appropriate attribute
values of Dyn (dynamically settable by IEC61850 communication services), Conf (configurable via an SCL file), and Fix
(only one fix value, typically documented in the SCL file). The Dyn option in this case always includes the Conf option, i.e.
if online setting is possible, also setting via SCL shall be possible.
Service / Capability Description Supported Default value

Indicates which general service classes this IED can
ClientServices use as a client: goose, gsse, sampled values (sv), Yes <ClientServices
unbuffered reporting (unbufReport), buffered bufReport="true"
reporting (bufReport), reading logs (readLog).
Default (missing element): supported client services
unbufReport="true"
not known (except possibly from GOOSE/GSSE goose="true"
elements) – look into PICS. maxGOOSE="10"
Required for 2007 version. A pure client shall set at maxReports="300" />
least one of the options to true.
Default for a missing attribute: false

Rev. 1.6 (16-09-2019)

All services for dynamic building of associations.
DynAssociation These are capabilities without attributes. Yes <DynAssociation max="120"/>
The max attribute indicates the maximum guarantied
number of dynamic associations which are possible.
Setting group services belong to the setting group

SettingGroups: control block. If this control block is available, then No
the setting group service SelectActiveSG for
SGEdit
activating a setting group is also available. The
ConfSG capability of online editing (IEC 61850-7-2 services
SelectEditSG, ConfirmEditSGValues, SetSGValues)
is decided with the SGEdit element. The capability to
configure the (number of) setting groups by SCL can
be also available (ConfSG). These are options
without attributes
Services for reading the contents of a server, i.e. the
GetDirectory LD and LN directories (all LDs, LNs and DATA of the Yes <GetDirectory/>
LNs). This is an option without attributes.
Includes the IEC 61850-7-2 services
GetServerDirectory, GetLogicalDeviceDirectory,
GetLogicalNodeDirectory
Service to retrieve the complete list of all DA
GetDataObjectDefinition definitions of the referenced data that are visible and Yes <GetDataObjectDefinition/>
thus accessible to the requesting client by the
referenced LN. It is a service without attributes.
Refers to IEC 61850-7-2 service GetDataDefinition
Service to get the DATA defined in a LN. It is a
DataObjectDirectory service without attributes. Refers to IEC 61850-7-2 Yes <DataObjectDirectory/>
service GetDataDirectory
Service to retrieve all values of data referenced by
GetDataSetValue the members of the data set. It is a service without Yes <GetDataSetValue/>
attributes. Refers to IEC 61850-7-2 service
GetDataSetValues
Service to write all values of data referenced by the
SetDataSetValue members of the data set. It is a service without No
SetDataSetValues
Service to retrieve FCD/FCDA of all members
DataSetDirectory referenced in the data set. It is a service without Yes <DataSetDirectory/>
GetDataSetDirectory
If ConfDataSet is not specified, then the default
ConfDataSet value of its max attribute is equal to the number of Yes <ConfDataSet max="64"
preconfigured data sets, and they may only be maxAttributes="128"
modified. If it is specified, it is possible to configure
new data sets up to the defined max, or modify
modify="true"/>
existing ones at configuration time via SCL.
The attribute meaning is:
max – the maximum number of data sets

maxAttributes – the maximum number of attributes
allowed in a data set (an FCDA can
contain several attributes)
modify – TRUE means that preconfigured data sets

may be modified; default: true
Services to dynamically create and delete data sets.

DynDataSet Refers to IEC 61850-7-2 services CreateDataSet No
and DeleteDataSet.
max – the maximum number of dynamically

creatable data sets (including eventually
predefined data sets)
maxAttributes – the maximum number of attributes
allowed in a data set (an FCDA can contain several
attributes)
Basic data read and write facility; includes the IEC
ReadWrite 61850-7-2 services GetData, SetData, and the Yes <ReadWrite/>
Operate service, if appropriate data exist. It is a
capability without attributes.
This element specifies that timer activated control
TimerActivatedControl services are supported. All other control-related No
services are specified directly at a DO with the
ctlModel attribute. It is a service without attributes.
Configuring IEC61850 D
Capability of static (by configuration via SCL)
ConfReportControl creation of report control blocks. Yes <ConfReportControl max="64"
The attribute’s meaning is: bufConf="true"
max – the maximum number of instantiable report
bufMode="both"/>
control blocks. If this is equal to the number of
preconfigured instances, then no new instances can
be created. If it is higher than the number of
preconfigured instances, the project engineer is
allowed to create more instances, even for new
types, up to this limit.
bufMode – unbuffered, buffered, both; the buffer
mode allowed to configure for new control block
types.
bufConf – boolean. TRUE means, the buffered
attribute of preconfigured report control blocks can
be changed via SCL
GetCBValues Read values of control blocks. It is a service without Yes <GetCBValues/>

attributes
Capability of static (by configuration via SCL)

ConfLogControl creation of log control blocks. No
The attribute’s meaning is:
max – maximum number of instantiable log control

blocks
The report control block attributes for which online

ReportSettings setting is possible with services SetURCBValues Yes <ReportSettings
respective SetBRCBValues: bufTime="Dyn"
cbName="Conf"
cbName – control block name datSet="Conf" intgPd="Dyn"
datSet – data set reference optFields="Dyn" rptID="Dyn"
rptID – report identifier trgOps="Dyn" />
optFields – optional fields to include in report
bufTime – buffer time
trgOps – trigger options enable
intgPd – integrity period
resvTms – if true, the ResvTms attribute exists at all
buffered control blocks.
In this case, if the BRCB instance is allocated to a
client, it should be configured as -1 (reserved), else
as 0 (free).
The log control block attributes for which online
LogSettings setting is possible with service No
SetLCBValues:
cbName – control block name

datSet – data set reference
logEna – log enable
trgOps – trigger options
intgPd – integrity period
The GSE control block attributes for which online
GSESettings setting is possible with service SetGsCBValues Yes <GSESettings appID="Conf"
respective SetGoCBValues: cbName="Conf"
datSet="Conf"/>
appID – application identifier
dataLabel – value for the object reference if the
corresponding element ist being sent (applies only to
GSSE control blocks)
Rev. 1.6 (16-09-2019)

The SMV control block attributes for which online
SMVSettings setting is possible with service No
SetMSVCBValues respective SetUSVCBValues:
svID – sample value identifier
optFields – optional fields to include in sample value
message
smpRate – sample rate per period is supported
samplesPerSec - samples per second resp. seconds
per samples are supported
SMVSettings allows the following (sub-)elements:
SmpRate – defines the implemented sample rate(s)
per period
SamplesPerSec – defines the implemented sample
rate(s) per second
SecPerSamples – defines the implemented seconds
between samples
If no appropriate elements are defined, the sample
rate per period or per second as
defined by above attributes is assumed to be freely
settable
Describes what can be configured for LNs defined in

ConfLNs an ICD file Yes <ConfLNs fixPrefix="true"
The attribute meanings are: fixLnInst="true"/>
fixPrefix – if false, prefixes can be set/changed
fixLnInst – if false. LN instance numbers can be

changed
If this element is present, the IED allows as a server

ConfLdName to define functional LD names (bymeans of the No
LDevice ldName attribute), and a client can receive
and interpret correctly SCL and online messages
using this capability
GSEDir GSE directory services according to IEC 61850-7-2. Yes <GSEDir/>

This capability has no attributes.
This element shows that the IED can be a GOOSE

GOOSE server or client according to IEC 61850-7-2. <GOOSE max="10"/>
The attributes meaning is:
max = maximum number of GOOSE control blocks,

which are configurable for publishing (max=0 means
the device is only a GOOSE client)
This element shows that the IED can be a binary
GSSE data GSSE server or client according No
to IEC 61850-7-2.
max – maximum number of GSSE control blocks,

which are configurable. Max=0 means only GSSE
client.
This element shows that the IED can be a Sampled
SMVsc Value server or client according to IEC 61850-7-2. No
max = maximum number of SMV control blocks,

which are configurable for publishing
(max=0 means the device is only a SMV client; can
be missing, if this is defined at the ClientServices
element).
FileHandling All file handling services; without attributes No
This element shows the capability to supervise

SupSubscription GOOSE or SMV subscriptions. Yes <SupSubscription
The attribute meaning is: maxGo="10" maxSv="0"/>
max – maximum number of subscription supervision
LNs to be instantiated on the IED.
If the actually instantiated number is less, the system
configurator is allowed to add more as needed up to
max. If this element is missing, only eventually
preconfigured supervision LNs are allowed to be
used.
Configuring IEC61850 F
This element shows the capability to include input
ConfSigRef references into logical nodes. No
max – maximum number of input references (e.g.

data objects InRef and BlkRef,having CDC ORG) to
be instantiated on the IED. If the actually instantiated
number is less, the system configurator is allowed to
add more as needed up to max. If this element is
missing, only eventually preconfigured input
reference elements are allowed to be used.
Table 10-2. Supported Services
10.5.2.4 Local Server Data Model

The local server is the IEC61850 interface offered by the controller to upstream clients such as the substation local HMI, a
trivial example of a server configuration is given below. This configuration defines a server IED with name ‘GTW’, access
point ‘P1’ which contains only one Logical Device, ‘SYSTEM’ which in turn contains five Logical Nodes, LLN0 and LPHD1,
ALGGIO1, ALGGIO2 and ITCI1;
<IED desc="Gateway" manufacturer="SE" type="Saitel" originalSclRevision="B" originalSclVersion="2007"

name="GTW">
<Services>
</Services>
<AccessPoint name="P1">
<Server>
<LDevice inst="SYSTEM" desc="example">
<LN0 inst="" desc="" lnClass="LLN0" lnType="/SAITEL/LLN0">
<DataSet name="ST_AL1" desc="Alarms">
<FCDA ldInst="SYSTEM" prefix="AL" lnInst="1" lnClass="GGIO" doName="Ind1" fc="ST"/>
<FCDA ldInst="SYSTEM" prefix="AL" lnInst="1" lnClass="GGIO" doName="Ind2" fc="ST"/>
... more data set elements
</DataSet>
<ReportControl name="brcbA" desc="" buffered="true" rptID="GTWSYSTEM/LLN0$BR$brcbA"
datSet="ST_AL1">
<RptEnabled max="2" />
</ReportControl>
<DOI name="Beh" desc=""/>
<DOI name="Health" desc=""/>
<DOI name="NamPlt" desc="">
<DAI name="configRev">
<Val>19-04-2010 09:17:22</Val>
</DAI>
</DOI>
</LN0>
<LN inst="1" desc="" lnClass="LPHD" lnType="/SAITEL/LPHD1" />
<LN prefix="AL" inst="1" desc="alarms" lnClass="GGIO" lnType="/SAITEL/GGIO32" />
<LN prefix="AL" inst="2" desc="alarms" lnClass="GGIO" lnType="/SAITEL/GGIO32" />
<LN inst="1" desc="for ClientLN refs" lnClass="ITCI" lnType="/SAITEL/ITCI1" />
</LDevice>
</Server>
</AccessPoint>
</IED>
10.5.2.5 SCL DataTypeTemplates Section

The DataTypeTemplate section of the SCD file will contain all the LNodeType, DOType, DAType and EnumType
definitions required by all IEDs defined in the file.
If we have a project which uses IEC61850 protection devices from only one manufacturer, then this section is simply a
copy of the manufacturer’s DataTypeTemplates. If however we are using IEC61850 protection devices from various
manufactures this section must be managed by a tool such as =S= SET or Helinks so that the types defined by each
manufacturer are renamed if there are type name clashes which is usually the case.
The IEC61850 Ed2 solution loads an Efficient XML Interchange (EXI) version of the SCD file, Easergy Builder does the
EXI encoding. The Easergy Builder ICT and controller firmware use SCL schema version, SCL.2007B.2014-01-22.
Rev. 1.6 (16-09-2019)
The SCD file has the following structure, the same as Ed1, ie. a Communications section, a section for each IED and a
section for the DataType templates;
<SCL ... >

<Communication>
<SubNetwork name="W01" type="8-MMS">
<!—Saitel RTU -->
<ConnectedAP iedName="UCDFECN" apName="PA1"/>

<ConnectedAP iedName="UPD1CYNTF1" apName="P1"/>
<ConnectedAP iedName="UPD2CYNTF1" apName="S1"/>

... more
</SubNetwork>
</Communication>
<IED name="UCDFECN" type="Saitel" manufacturer="SE" configVersion="1.0">
... similar sections as listed for IED UPD1CYNTF1 below
</IED>
<IED name="UPD1CYNTF1" type="Siprotec" manufacturer="SIEMENS" configVersion="1.0">
<Services/>
<AccessPoint name="S1">
<Server>
<Authentication none="true"/>
<LDevice inst="F650">
<LN0 desc="description" lnType="geLLN0" lnClass="LLN0" inst="">
<DataSet name="GGIO_F_Contacts" desc="GGIO_F Contact Inputs">
<FCDA ldInst="F650" prefix="" lnInst="1" lnClass="GGIO" doName="Ind1"
fc="ST"/>
<FCDA ldInst="F650" prefix="" lnInst="1" lnClass="GGIO" doName="Ind2"
fc="ST"/>
... more data set elelments
</DataSet>
<ReportControl name="brcbSTA" desc="" rptID="UPD1CYNTF1F650/LLN0$BR$brcbSTA"
datSet="GGIO_F_Contacts">
<RptEnabled max="1">

<ClientLN iedName="UCDFECN" ldInst="SYSTEM" lnInst="1" lnClass="ITCI"/>
</RptEnabled>
</ReportControl>
<DOI name="NamPlt">
<DAI name="configRev" valKind="Set">
<Val>2010-10-28 11:46:37.086</Val>
</DAI>
</DOI>
</LN0>
<LN inst="1" lnClass="LPHD" lnType="geLPHD"/>
<LN inst="1" lnClass="XCBR" lnType="geXCBR"/>
<LN inst="1" lnClass="CSWI" lnType="geCSWI"/>
<LN inst="2" lnClass="CSWI" lnType="geCSWI"/>
<LN inst="1" lnClass="XSWI" lnType="geXSWI"/>
<LN inst="2" lnClass="XSWI" lnType="geXSWI"/>
<LN inst="1" lnClass="GGIO" lnType="geBoardGGIO"/>
... more instances of Logical Nodes
</Ldevice>
... more instance of Logical Devices
</Server>
</AccessPoint>
</IED>
<IED name="UPD2CYNTF1" type="Siprotec" manufacturer="SIEMENS" configVersion="1.0">
... similar sections as listed for UPD1CYNTF1 above
</IED>
... more IEDs
<DataTypeTemplates>
<LNodeType id="LLN0_0" lnClass="LLN0"/>
<LNodeType id="GGIO_0" lnClass="GGIO"/>
<LNodeType id="XCBR_0" lnClass="XCBR"/>
... more Logical Node Types
<DOType id="INC_0" cdc="INC"/>
<DOType id="INS_0" cdc="INS"/>
<DOType id="SPC_0" cdc="SPC"/>
... more Data Object Types
<DAType id="Originator_0"/>
<DAType id="Oper_0"/>
<DAType id="Cancel_0"/>
... more Data Attribute Types
<EnumType id="Mod"/>
<EnumType id="ctlModel"/>
Configuring IEC61850 H
... more Enumerated Types
</DataTypeTemplates>
</SCL>
Figure 10-1. SCD file structure.
This SCD file means the Saitel RTU UCDFECN is to enable the report brcbSTA01 in IED UPD1CYNTF1.
Seville, Spain
Rev. 1.6 (16-09-2019)
Configuring IEC61850
C/ Charles Darwin s/n
Schneider Electric
www.schneider-electric.com
Saitel Team
Parque Científico y Tecnológico de la Cartuja
J
© 2019 All rights reserved. The information contained in this document is confidential and is owned by Schneider Electric. It cannot
be copied or distributed in any way, unless there is express written authorization by Schneider Electric. Although this information
was verified at the time of publication, may be subject to change without notice.

IEC61850 Ed2 Devices - EN - Rev1.6

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IEC61850 Ed2 Devices - EN - Rev1.6

Uploaded by

Copyright:

Available Formats

Baseline Software Platform

IEC61850 Ed2 Device (Client & Server)

1.0 25-10-2016 Initial revision for Easergy Builder.

1.1 11-11-2016 Add recommended RCB parameter settings in Section 3.1.10

Revised GOOSE section.

Revised Section 3.2.1

1.2 15-11-2017 GOOSE IF is now Interface name not IP address

1.4 01-03-2018 Minor changes.

1.5 12-04-2018 Client limits revised.

Relevant information for the user

Revision / Date: Rev 1.6 / 16-09-2019

File: IEC61850 Ed2 Devices_EN_Rev1.6.pdf

3.4.3 Report Control Blocks............................................................................................................................... 3-21

6.4 ACSI service conformance statement ................................................................................................................ 6-3

8.3.2 IEC-61850 CLIENT CONNECTIONS ......................................................................................................... 8-3

Chapter 2 – Easergy Builder

Chapter 3 – IEC61850 Ed1/Ed2 Client

Chapter 4 – IEC61850 Ed1/Ed2 Client PICS

Chapter 5 – IEC61850 Ed2 Server

Chapter 6 – IEC61850 Ed2 Server PICS

Chapter 7 – IEC61850 PIXIT

Chapter 8 – Trouble Shooting

Chapter 9 – IEC 61850

III. Reference Manuals

Manual’s name Document

Easergy Builder User Manual TE-HG-0000-MSS-S856

Saitel Webtool User Manual TE-HG-0000-MCW-S856

Table 0-1-1. Reference manuals

IV. Software Versions

Module Software version (CPU) Pluging version (Easergy Builder)

IEC61850 Ed2 client/server i61scBinC - 10.02.27 IEC61850 - 1.1.22.0

Table 0-1-2. Software versions

Software SM_CPU866 SM_CPU866e HU_B/HU_BI HU_A/HU_AF HU 250 HUe

Table 0-1-3. Hardware/Software compatibility.

1.1 RTU Software Architecture

Devices Modbus Real Time Database Web Server

Real Time Operating System

Figure 1-1. Baseline software architecture.

Configuring IEC61850 1-1

Figure 1-2. Relation between coreDb and other applications.

1.2 IEC 61850 Controller architecture

Configuring IEC61850 1-2

SCADA Slave 104 SC150

Figure 1-3. Controller architecture

1.3 IEC 61850 Hierarchal Data Model

1.4 IEC 61850 Communication Profiles

1.4.1 Client / Server (MMS)

Configuring IEC61850 1-3

1.4.2 Multicast GOOSE

1.5 Use cases

1.5.1 RTU as IEC61850 server

IEC 61850 IEC 61850

Figure 1-4. RTU as IEC 61850 Server

1.5.1.2 Supported Services

Configuring IEC61850 1-4

1.5.2 RTU as IEC61850 client

SCADA Slave 104 SC150

Figure 1-5. RTU as IEC 61850 Client

1.5.2.2 Supported Services

Configuring IEC61850 1-5

1.5.3 RTU as IEC61850 client/server gateway

Figure 1-6. RTU as IEC 61850 Gateway

1.5.3.2 Supported Services