TR IEC 61850 90-30 - Guidelines For IEC 61850 Function Modeling in SCL. - PAC World

10/7/23, 10:52 TR IEC 61850 90-30 - Guidelines for IEC 61850 Function Modeling in SCL.
| PAC World
My Account Subscribe Login Store   
Magazine  Events  Areas of Interest  News  Advertising PAC World  Store

Global forum of the Protection, Automation and Control community
IEC 61850
TR IEC 61850 90-30 – Guidelines

for IEC 61850 Function Modeling
in SCL.
The next step towards
improved engineering efficiency
Jorg Reuter, Helinks LLC, Switzerland
TR IEC 61850 90-30 extends the SCL language and the IEC 61850 engineering
process by powerful specification elements and creates the foundation for
the definition of Basic Application Profiles. This will revolutionize the way
we implement automation- and protection schemes in our IEC 61850
systems. This article gives a short introduction.

https://www.pacw.org/tr-iec-61850-90-30-guidelines-for-iec-61850-function-modeling-in-scl 1/27
10/7/23, 10:52 TR IEC 61850 90-30 - Guidelines for IEC 61850 Function Modeling in SCL. | PAC World
The technical report (TR)
Magazine“TR
 IECEvents
61850 90-30.Areas of Interest
Guidelines News
for IEC61850 Function
 Advertising
Modeling in SCL”PAC
has World
the  Store
objective to increase the efficiency of the IEC 61850 engineering process.

It can be considered being an enabler for a more formalized and standardized

IEC 61850 specification process. The TR reaches this objective by:
Extending SCL to formally describe (nearly) all aspects of the IEC 61850
configuration in an IED independent way. This includes the exchange of data
and the specification of protocol parameters independently of specific IEDs
Extending SCL with additional file types, relations, and versioning
information to support the workflow between the specification and
implementation phase
Introducing a more advanced “Templating Concept” into SCL to allow utilities to

formally describe engineering standards and templates
TR 61850 90-30 is not standing isolated. It is extending the engineering process

as defined in Ed 2.1 part 6 and is preparing the ground for the formalized
definition of Basic Application Profiles (BAP). This is ongoing work in WG10 TR
61850 7-6 Basic Application Profiles. (Figure 1).
The TR 90-30 SCL extensions are aiming to improve the IEC 61850 specification
phase by providing a formalized way to specify in the context of the electrical
process, Functions, Protection- and Application schemes, and IED Specifications.
The IEC 61850 Engineering Process as it is described in Part 4 and Part 6 of the
IEC 61850 standard is extended with more details on the specification phase and
the interaction between specification- and system integration phase. (Figure 2).
Why is TR IEC 61850 90-30 important for Utilities?

Edition 2.1 of the standard is focusing on the IED – and system configuration
aspects of the engineering process. Never the less, already in Edition 1 of the
Magazinestandard
 the engineering
Events  Areas process introduced
of Interest  a formalized
News  specification PAC
Advertising phase
World  Store
by defining an SCL file called SSD. SSD stands for System Specification
Description. Up until now this file has scarcely
 been used in power automation
projects because of two major reasons.
The information content of an Edition 2.1 SSD file is limited to a static

description of the electrical system and the required Functions and Logical
Nodes. The information content is just not worth the effort to create an SSD
file. In addition to the SSD file utilities still have to provide the specification
of protection- and automation schemes, parameters, signal and protocol
implementation details etc.
The current IEC 61850 engineering process definition in the standard is not
covering the engineering workflows related to the specification phase and
the transition from specification to implementation.
TR IEC 61850 90-30 enables Utilities to create powerful SSD files that are
formalized specification files, covering nearly all aspects of an IEC 61850 based
PAC system.
The overall efficiency of the IEC 61850 engineering process can be improved by
using templates based on the TR IEC 61850 90.30 SCL extension.
New SCL Elements in the SCL Process Section
This part of the article introduces some new XML elements or extensions of
existing elements defined in TR 61850 90-30. Be aware that not all elements and
relations defined in TR 61850 90-30 are discussed in this chapter.
The content of SCL Files: All SCL Files have potentially four different sections.
(Figure 3).

The Process/Substation Section

The IED Section
Magazine  The Data Type
Events  Section
Areas of Interest  News  Advertising PAC World  Store
The Communication Section

In the context of this article, we are using the notion Process Section to refer to
the Process/Substation section. The new elements, introduced by TR 61850 90-
30 are all located in the Process Section. These elements are covering (Figure 4):
Applications and Functions

Data exchange with Source- and Control Refs
Protocol parameters described by Service Properties
Advanced Logical Node and Data Object mapping information (Specification
Tracking)
Process Resources
Namespace for TR 90-30 SCL Extensions
For now, the extension to SCL defined by TR 61850 90-30 and TR 61850 7-6 (BAP)
are defined in a separate XML namespace. For now, this namespace is called
http://www.iec.ch/61850/2019/SCL/6-100
Once the work is terminated, it will be integrated in the regular SCL namespace.
This is intended to happen with IEC 61850 Edition 3.
Functions
The notion of Function has been omnipresent in IEC 61850. But only since
Edition 2 Functions found their way into SCL as essential elements of the
Process Section. They serve as container for Logical Nodes and can have internal
structures (SubFunctions). Functions are allocated on every level of the Process
Section and when implemented by IEDs, they can spread over multiple IEDs.

TR 61850 90-30 now allows to group Functions into categories and, most
important, Functions can be associated to Applications.
Figure 5 – Functions and Applications, shows some examples of Functions. The

Circuit Breaker Function (CBR Function) is a child of the Conducting Equipment
QA0 in Bay 01. It contains 3 Logical Nodes. Once implemented in a Process Bus
solution this Function could spread over 2 IEDs. The XCBR and SCBR are
implemented by the Process Interface Unit (PIU) and the CSW is implemented
the bay Controller.
Functions and Applications
A Protection – or Automation scheme is defined by a group of Functions and the

data exchange between these Functions. In TR 61850 90-30 we call this an
Application and define it as follows:
An Application is a group of related Functions which are communicating to

implement the functionality of the Application. Applications can be associated to
Process Section elements in the same way as Functions. One Function or
SubFunction can be part of several Applications. Applications can be nested.
The Breaker Failure Application in Figure 5 is allocated to the Circuit Breaker

QA0 in the Bay 01 because it is responsible to react on a failure of this circuit
breaker. In this example 4 different Functions are involved in the Breaker Failure
Scheme. These are:
The Breaker Failure Function with the Logical Node RBRF and
The Circuit Breaker Function of the protected circuit breaker
A Protection Function that issues the trip for the circuit breaker and thus
initiates the Breaker Failure Function 
The Circuit Breaker Function of the surrounding circuit breakers, because

they are opened if the circuit breaker in bay 01 fails definitively
In our example we just have 2 bays. Only the circuit breaker of Bay 02 needs to

be operated by the OpEx signal. In a real project we would have multiple feeders
where we need the external trip. BAP is defining mechanisms and data model
extensions to automatically extend an application to an undefined number of
participants. BAP uses elements as Selectors and Cardinality information for this
purpose. Details on this are beyond the scope of the current article.
For this scenario, TR 61850 90-30 introduces the XML element Application and
allows this element to reference the participating Functions (Function
Reference). A Function can participate in different Applications. It can be
referenced multiple times.
Data Exchange Specification
A Function is included as a participant in an application, if there is any data this

Function exchanges in order to implement the protection- or automation
scheme.
The data exchange between the Functions of an Application is implemented

either by an external protocol (MMS Reporting, GOOSE, SV, wires) or, in case of 2
Functions residing inside the same IED, it can just be an internal connection.
In our example the trip may be sent by GOOSE, as well as the Operate External
for the surrounding circuit breakers. The Internal Operate of the Breaker Failure
Function (Logical Node RBRF) may be configured or even hard wired inside the
IED. Even if this is not a 61850 protocol-based data exchange TR 61850 90-30
allows including this data exchange in the specification of the Application.
Adding data flow information to the Process Section allows describing the data
exchange of Functions independently of the implementing IEDs. The data flow
inside and between Functions is modelled on Logical Node level.
The data exchange between Logical Nodes can represent a status, a measured
value or a configuration value, but it can also represent a command. In the first
case TR 61850 90-30 defines the SourceRef element, in the second case it is the
ControlRef element.
SourceRef

SourceRef stands for Source Reference. (Figure 6).
The SourceRef is a link from a receiving Logical Node back to a source Data
Object or Attribute in a Function of the Process Section.
The Source Reference is conceptually very close to the ExtRef. The difference
between Source References of LNodes and ExtRef is:
The Source Reference points to a Data Object, Data Attribute or LNode

following the LNodetype specification of an LNode in the Process Section.
The pointer is contained in the attribute “source”
There is no reference to IED communication structures (Control Blocks).
Instead, the SourceRef can be related to a Service Specification. The Service
Specification allows to define parameters of the required protocol
The Service indication can include Wiring and IED internal communication,
because the data exchange described by SourceRef is not necessarily
implemented by an IEC 61850 protocol
The Data Flow specification is independent of the device allocation (Allocation of

Functions to IEDs). Once implemented it may be realized by IED internal
communication, GOOSE Messages, MMS Reporting, Control Services, SMV or
even wires. The Service can be specified by the serviceType attribute of the
SourceRef.
The information content of a SourceRef element goes beyond the pure data
exchange specification. It has a life cycle and changes its status during the
specification and engineering process.
A SourceRef element can be “open” or “connected.” Open means that the

SourceRef is defined as input for the Function but is not yet connected to the
source of the data. This corresponds to the ”Later Binding” concept for ExtRefs.
The SourceRef element has additional attributes that support the specification
and the implementation phase of the engineering process:
Specification Phase

An “input” attribute that defines uniquely the SourceRef in the context of its
Logical Node. The value of the ”input” attribute as well as the description
Magazine  attribute
Eventsserve
 as semantical
Areas hint for
of Interest  the engineer
News  to properly link the
Advertising PAC World  Store
SourceRef.
Support for the specification of Applications
 by providing preferred Logical
Node, DO and DA information. These attributes help the engineer to find
the appropriate source data for the SourceRef. This is helpful for the manual
Application design, but it is also intended for the automatic Application
instantiation defined in TR 61850 7-6.
Implementation Phase
Specifying the requested service and protocol parameters for the

implementation
There is, once the LNode is mapped and the communication is configured,
the possibility to link the SourceRef to an ExtRef of an LN. This link
documents in an SCD file how a specified data exchange has been
implemented in the system
Figure 7 is an example of a connected SourceRef. The source attribute has been

set during the specification phase.
The implemented SourceRef of Figure 8 is how a SourceRef may look like in a

properly configured SCD file. The “extRefAddr” attribute points to the source of
the data in the sending IED.
ControlRef for Controls
The Control Reference is a link from a controlling Logical Node to the controlled
Data Object or Attribute.

Control References are referencing I-Group (e.g. ITCI or IHMI) Logical Nodes
without Data Object/Attribute specification or, similar to SourceRef they also can
refer to any other Logical Node that performs control operations. (Figure 9).
Data Object and Attribute Instances for LNodes
Adding instance information to the specification is an important step to allow

much richer SSD files.
Specifying parameter values and attribute values of Logical Nodes is an

important part of a comprehensive Functional Specification. Parameter values
are very often instance specific.
TR 61850 90-30 defines new elements named DOS (Data Object Specification),
SDS (Structured Data Specification) and DAS (Data Attribute Specification). These
elements are children of the Logical Node. They correspond to the LN instance
data of the IED data model. With these new elements values can be added to the
Data Attributes of every LNode instance in the Process Section.
Furthermore, it is possible to add protocol mappings as they are defined e.g. in

TR IEC 61850 80-1 for IEC 61870-5-104 already to the specification. Utilities now
can formally add their 104 addresses to the SSD file.
Specification Tracking
The idea of specification tracking is to support the documentation of

implementation decisions that the system integrator takes during the creation
of an SCD file. TR 61850 90-30 provides several places to document and track
the implementation decisions.
There are new attributes to the Logical Node. These attributes store the
originally specified Logical Node.
If, for some reason, the system integrator is forced to implement a Logical Node
different from its specification the customer can compare the mapped Logical 
Node in the SCD file against the specified one.
MagazineIn caseEvents
a different Areas Node
 Logical of Interest
has been News
 used Advertising
to implement
 PAC World 
a data point, Store
generally also a different DO/DA must be used. This can be tracked by the
customer due to the new DOS/DAS elements. 
Virtual IEDs
Virtual IED Definition in TR 61850 90-30: In this article the virtual IED
definition is not requiring changes in SCL (Edition 2.1) except for some additional
attributes of the IED element and the Header element.
Virtual IEDs can serve 2 different purposes:
As specification for a physical IED

For simulation purposes (Digital Twin)
ISD Files
Virtual IEDs are very much like ICD or IID files. The extension for a virtual IED is “.
ISD”. ISD stands for IED Specification Description
The main difference between ISD files and other IED describing SCL files (ICD,
IID, CID) does not lay in the SCL structure but in the role of the file in the
engineering process and partly in the semantics of the SCL elements.
Identifying and referencing SCL Files and IEDTypes.
A controlled Engineering Process requires careful management of the

participating SCL files. Being able to identify and reference files and their
revisions is the purpose of the following extensions.
The identification of files is done by versioned UUIds. Different versions of a file

are distinguished by a version attribute. The UUID for different file versions
remains unchanged.
Examples of Referencing SCL Files
In the context of a PAC project SCD files can have a reference to the related SSD
file. This reference is contained in the Header element- The attribute is “ssdRef.”

The IED instances in an SSD File can have references to ISD and ICD Files. The
SCD references the SSD File. (Figure 10).
Practical experiences with TR 61850 90-30
Osmose: As part of the European Funded Research Project Osmose TR 61850

90-30 has been successfully applied on the IEC 61850 engineering process in this
project.
OSMOSE has the goal to provide a demonstration of system integration with

smart transmission grid and storage technologies with increasing share of
renewables. (Figure 11).
SCTs and ICTs from different vendors have been used to model, specify and
implement an 61850 based battery storage application.
UW 2030 by Stromnetz Hamburg (SNH)
Stromnetz Hamburg (Germany) is running a digital substation innovation project

implementing new technologies.

The specification data model is delivered as an IEC 61950 SSD file. It is based on
typical feeder arrangements and includes the structure and IEC 61850 naming
Magazinefor
 theEvents
Power Equipment, theInterest
Areas of Electrical Connections
News  andAdvertising
the allocation of theWorld 
PAC Store
IEC 61850 Functions and Logical Nodes.

The Logical Node types are taken from an SNH (Stromnetz Hamburg) specific
private namespace.
According to TR 61850 90-30, Data Exchange and Function Parameters are
added to the Substation/Process section. The Function Templates may contain
unbound SourceRefs(inputs). During the definition of the Application Schemes,
the Source attributes of the inputs are resolved. The Function Parameters are
defined on the Data Object resp. Data Attribute instances (DOS / DAS) in the
Substation/Process section.
Virtual IEDs are derived from the Substation/Process section. The Logical Device
hierarchy is built based on functional testing requirements and is reflected in
the Virtual IEDs. Functional Naming (ldName) and Flexible Naming (LN Prefix and
Inst) is applied. The Virtual IEDs define the required services and contain
specifications for Data Sets and Control Block configurations.
In the Communication Section, Process- and Station bus are defined as well as
the required network settings and IEC 61850 network connections for MMS
Reporting, GOOSE and Sampled Values.
The SSD file describes a highly formalized and comprehensive data model that is
binding for the contractors. The contractors are expected to deliver a
corresponding SCD file, that allows to formally compare the degree of the
specification fulfilment.
Elia “Virtual Substation”
Elia as a Belgium system operator has started an innovation project called

“Virtual Substation.” One of the goals of this project is to highly automate the IEC
61850 engineering process. A proof-of-concept sub project is focusing on this
goal (POC Engineering)
Using SCL extensions from IEC61850-90-30 (former 6-100) (function

modeling) and 7-6 (BAP), including Osmose feedback
Introducing
Function- and application specification (FSD/ASD)
EID specification (ISD)
Specification of logical behaviour using IEC61131(BehD)
Conclusion

TR IEC 61850 90-30 enables Utilities to formally specify their IEC 61850 PAC
System in a device independent way. It provides a solid base for the successful
Magazineimplementation
 Events  of an SCL of
Areas driven top-down
Interest  engineering
News  approach an prepares
Advertising PAC World  Store
the way for working with Basic Application Profiles. This will revolutionize the
way we implement automation- and protection schemes.
Biography:
Jorg Reuter – After earning his master’s degree in electrical engineering from
the University of Kaiserslautern/Germany Jörg entered the world of Industrial
Process Automation to explore his passion for Real Time Operating Systems and
Process Automation.He spent the last 20 years learning about the Utilities
requirements and challenges in engineering IEC 61850 based protection and
control systems as software developer. R&D Manager and CEO in different
companies. Currently, he works as a Director and Owner of Helinks LLC
Switzerland, where he is focused on IEC 61850 Engineering Tools and the IEC
61850 Engineering Process. As a member of TC57 WG10 he is actively involved in
the further development of the IEC 61850 standard.
#Issue 061 September 2022
  
EC 61850 Week 2021 IEEE PES General Meeting
Application of Digitalization Principles in Engineering and Science


You may also like

IEC 61850 • Protection IEC 61850 • Protection
Standardization of PAC  Basic Application Profiles
schemes in Eskom, South
Africa
IEC 61850 • Protection IEC 61850 • Protection

Use of Frame Agreement to Security and Standardization
Standardize PAC Systems
in...
IEC 61850 IEC 61850

From Specification to the Utilizing IEC 61850 Standard
Substation – The OSMOSE... for the circuit based...
Support PAC World – Become a

member
S upport PAC World by becoming a
member. A $25.00 annual fee will give

you full website access (including
access to members-only contents) as
well as the PAC World magazine. Join
now












PAC World Most Popular Join Us
About Us
  
Contact Us
Legal IEC TC 57 WG 17
Update
4 min read
The History of
Protection
Philosophy for
Hydro One...
17 min read

Copyright © 2023 PAC World About Us Contact Us Legal


TR IEC 61850 90-30 - Guidelines For IEC 61850 Function Modeling in SCL. - PAC World

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

TR IEC 61850 90-30 - Guidelines For IEC 61850 Function Modeling in SCL. - PAC World

Uploaded by

Copyright:

Available Formats

10/7/23, 10:52 TR IEC 61850 90-30 - Guidelines for IEC 61850 Function Modeling in SCL.

My Account Subscribe Login Store   

Magazine  Events  Areas of Interest  News  Advertising PAC World  Store

Magazine  Events  Areas of Interest  News  Advertising PAC World  Store