Communication networks and systems for power utility automation - Part 80-5: Guideline for mapping information between IEC 61850 and IEC 61158-15

IEC TR 61850-80-5:2024, which is a Technical Report, specifies the mapping rules for building and configuring a system using both IEC 61850 and IEC 61158-6 (Industrial communication networks - Fieldbus specification, CPF Type 15, Modbus) protocols by utilizing gateways between IEC 61850 and IEC 61158-6 IEDs / subsystems. The objective is to enable operational run-time data exchange among these IEDs / subsystems, and to automate the configuration of a gateway as much as possible.
Please note that for the purposes of this document, "Modbus" is used to represent both serial Modbus (Modbus RTU) and IEC 61158-6 (Modbus TCP).
Within the capability of each protocol, some configuration attributes (IEC 61850-7-3:2010+AMD1:2020 attributes with functional constraint CF) are also mapped in addition to the operational real-time data.
The rules specified in this document are based on the published standards and do not make any proposed changes to IEC 61850 or 61158-6. This standard does not specify any rules for an IEC 61850 IED to directly communicate with a Modbus IED and vice versa, except through a gateway.
This document does not mandate which data items that a particular IED shall support, regardless of whether the implementation uses Modbus or IEC 61850. Instead this document provides rules specifying how a gateway maps any given data item from one protocol to the other, given that the data item is already available and is transmitted using one of the protocols.
Similarly, this document does not mandate which mapping rules a given gateway shall support. When this document is republished as a Technical Specification, conformance requirements will be identified.
This document recognizes that there will be situations in which a user will require that a gateway perform non-standard protocol mappings. Non-standard mappings are outside the scope of this document.
This document also recognizes that gateways typically manipulate the data passing through them in a variety of ways. Some of these functions include alarm trigger grouping, data suppression, interlocking and command blocking. Conformance to this document does not preclude a gateway from performing such functions, even though this document primarily specifies "straight through" mapping of Modbus data to IEC 61850-7-3:2010+AMD1:2020 data. Subclause 7.4 of this document describes how some of these functions may be specified to a gateway by a mapping tool using equation notation in XML. However, some of these functions may be too complex for a mapping tool to specify in an automated manner.
The mapping architecture for the exchange of the run-time information consists of four parts:
1) Conceptual architecture of a gateway and associated use case
2) Mapping of the information model (Assign semantic to the Modbus data)
3) Mapping of the data (which is in fact part of the information model)
4) Mapping of the services (out of scope for this document)

General Information

Status
Published
Publication Date
08-Feb-2024
Current Stage
PPUB - Publication issued
Start Date
09-Feb-2024
Completion Date
08-Mar-2024
Ref Project
Technical report
iectr61850-80-5{ed1.0}en - IEC TR 61850-80-5:2024 - Communication networks and systems for power utility automation - Part 80-5: Guideline for mapping information between IEC 61850 and IEC 61158-15 Released:2/9/2024 Isbn:9782832282366
English language
47 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)


IEC TR 61850-80-5 ®
Edition 1.0 2024-02
TECHNICAL
REPORT
colour
inside
Communication networks and systems for power utility automation –
Part 80-5: Guideline for mapping information between IEC 61850 and
IEC 61158-15
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC
copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or
your local IEC member National Committee for further information.

IEC Secretariat Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigendum or an amendment might have been published.

IEC publications search - webstore.iec.ch/advsearchform IEC Products & Services Portal - products.iec.ch
The advanced search enables to find IEC publications by a Discover our powerful search engine and read freely all the
variety of criteria (reference number, text, technical publications previews. With a subscription you will always have
committee, …). It also gives information on projects, replaced access to up to date content tailored to your needs.
and withdrawn publications.
Electropedia - www.electropedia.org
IEC Just Published - webstore.iec.ch/justpublished
The world's leading online dictionary on electrotechnology,
Stay up to date on all new IEC publications. Just Published
containing more than 22 500 terminological entries in English
details all new publications released. Available online and once
and French, with equivalent terms in 25 additional languages.
a month by email.
Also known as the International Electrotechnical Vocabulary

(IEV) online.
IEC Customer Service Centre - webstore.iec.ch/csc

If you wish to give us your feedback on this publication or need
further assistance, please contact the Customer Service
Centre: sales@iec.ch.
IEC TR 61850-80-5 ®
Edition 1.0 2024-02
TECHNICAL
REPORT
colour
inside
Communication networks and systems for power utility automation –

Part 80-5: Guideline for mapping information between IEC 61850 and

IEC 61158-15
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 33.200 ISBN 978-2-8322-8236-6

– 2 – IEC TR 61850-80-5:2024  IEC 2024
CONTENTS
FOREWORD . 4
INTRODUCTION . 6
1 Scope . 7
1.1 General . 7
1.1.1 Scope statement . 7
1.1.2 Areas of application . 8
1.1.3 Benefits . 8
1.1.4 Published versions of this standard and related namespace name . 8
1.2 Namespace name and version . 8
1.3 Code Component distribution . 9
1.3.1 General . 9
1.3.2 XML schema namespace code component . 9
2 Normative references . 10
3 Terms, definitions and abbreviated terms . 10
3.1 Terms and definitions . 10
3.2 Abbreviated terms . 11
4 Architecture of gateways between IEC 61850 and Modbus . 11
4.1 Overview. 11
4.2 Gateway between a Modbus server IED and an IEC 61850 client/subscriber
IED . 11
4.2.1 General . 11
4.2.2 Gateway device . 12
4.2.3 Handling of communication interruptions between the Gateway Modbus
Client and the Modbus Server . 13
4.2.4 Handling of Mod and Beh. 14
4.2.5 Handling of Health status . 14
4.2.6 Handling of configuration parameters . 14
4.2.7 Handling of substitution . 15
4.2.8 Service tracking . 15
4.3 Considerations on configuring the gateway . 15
5 Modbus to IEC 61850 gateway engineering workflow . 15
5.1 Overview. 15
5.2 Extensions to the SCL engineering process . 16
5.3 Extensions of the SCL schema from IEC 61850-6:2019 . 17
6 Mapping . 18
6.1 IEC 61850 & Modbus addressing schemes . 18
6.2 Logical device mapping . 18
6.3 Object mapping . 21
7 Mapping of data structure . 22
7.1 General . 22
7.2 Mapping principles . 22
7.2.1 General . 22
7.3 Handling of the quality . 23
7.4 Basic conversion functions . 24
7.4.1 Overview . 24
7.4.2 General conversion behaviour . 32
7.4.3 Literals . 32

7.4.4 Unit conversions . 32
7.4.5 Modbus Coil . 32
7.4.6 Modbus Holding Register . 33
8 Time and time synchronization model . 34
9 File transfer . 34
10 Mapping of services . 34
Annex A (informative) Use of SCL (substation configuration language) to include
Modbus information . 35
A.1 SCL schema . 35
A.1.1 Code components . 35
A.1.2 General . 36
Annex B (informative) Example SCL File Showing Modbus Mapping . 37
Bibliography . 47

Figure 1 – Communication between a Modbus server IED and an IEC 61850 client IED . 12
Figure 2 – Architecture of a gateway between a Modbus server IED and an IEC 61850
client IED . 13
Figure 3 – Logical device mapping . 19
Figure 4 – Local vs Proxied functionality . 20
Figure 5 – Object mapping . 22
Figure 6 – Handling of Quality . 23
Figure 7 – Handling of Timestamp . 24

Table 1 – Reference between published versions of the standard and related
namespace name . 8
Table 2 – Attributes of xsd namespace . 9
Table 3 – Modbus exception codes . 23
Table 4 – Conversion functions . 25

– 4 – IEC TR 61850-80-5:2024  IEC 2024
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
COMMUNICATION NETWORKS AND
SYSTEMS FOR POWER UTILITY AUTOMATION –

Part 80-5: Guideline for mapping information
between IEC 61850 and IEC 61158-15

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote international
co-operation on all questions concerning standardization in the electrical and electronic fields. To this end and
in addition to other activities, IEC publishes International Standards, Technical Specifications, Technical Reports,
Publicly Available Specifications (PAS) and Guides (hereafter referred to as "IEC Publication(s)"). Their
preparation is entrusted to technical committees; any IEC National Committee interested in the subject dealt with
may participate in this preparatory work. International, governmental and non-governmental organizations liaising
with the IEC also participate in this preparation. IEC collaborates closely with the International Organization for
Standardization (ISO) in accordance with conditions determined by agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence between
any IEC Publication and the corresponding national or regional publication shall be clearly indicated in the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) IEC draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). IEC takes no position concerning the evidence, validity or applicability of any claimed patent rights in
respect thereof. As of the date of publication of this document, IEC had not received notice of (a) patent(s), which
may be required to implement this document. However, implementers are cautioned that this may not represent
the latest information, which may be obtained from the patent database available at https://patents.iec.ch. IEC
shall not be held responsible for identifying any or all such patent rights.
IEC TR 61850-80-5 has been prepared by IEC technical committee 57: Power systems
management and associated information exchange. It is a Technical Report.
The text of this Technical Report is based on the following documents:
Draft Report on voting
57/2622/DTR 57/2647/RVDTR
Full information on the voting for its approval can be found in the report on voting indicated in
the above table.
The language used for the development of this Technical Report is English.
This document was drafted in accordance with ISO/IEC Directives, Part 2, and developed in
accordance with ISO/IEC Directives, Part 1 and ISO/IEC Directives, IEC Supplement, available
at www.iec.ch/members_experts/refdocs. The main document types developed by IEC are
described in greater detail at www.iec.ch/standardsdev/publications.
A list of all parts in the IEC 61850 series, published under the general title Communication
networks and systems for power utility automation, can be found on the IEC website.
This IEC standard includes Code Components i.e. components that are intended to be directly
processed by a computer. Such content is any text found between the markers BEGINS> and , or otherwise is clearly labeled in this standard as a Code
Component.
The purchase of this IEC standard carries a copyright license for the purchaser to sell software
containing Code Components from this standard directly to end users and to end users via
distributors, subject to IEC software licensing conditions, which can be found at:
http://www.iec.ch/CCv1.
The committee has decided that the contents of this document will remain unchanged until the
stability date indicated on the IEC website under webstore.iec.ch in the data related to the
specific document. At this date, the document will be
• reconfirmed,
• withdrawn, or
• revised.
IMPORTANT – The "colour inside" logo on the cover page of this document indicates
that it contains colours which are considered to be useful for the correct understanding
of its contents. Users should therefore print this document using a colour printer.

– 6 – IEC TR 61850-80-5:2024  IEC 2024
INTRODUCTION
This part of IEC 61850, which is a Technical Report, provides a guideline to exchanging
information between IEC 61850 and IEC 61158-6-15 (Modbus TCP). Today, industrial fields,
such as distributed energy resource (wind and solar energy, etc.) and condition monitoring,
have been successfully exchanging information from Modbus to IEC 61850. Although many
manufacturers have already implemented the Modbus to IEC 61850 conversion device or
system, these devices do not guarantee interoperability. Therefore, a consistent and unified
information exchange scheme between IEC 61850 and IEC 61158-6-15 is required.
Modbus over serial line (Modbus RTU) is not part of IEC 61158-6-15, but is also considered in
this technical report.
It was first foreseen to prepare this document as a Technical Specification. However, as there
is a lack of feedback from practical experience, it was decided to first publish a Technical Report
with a limited scope (see 57/2506/Q and 57/2553/RQ).
This is now the first edition of a Technical Report with the scope limited to the mapping of a
Modbus device's register into an IEC 61850 model. It is intended to encourage first prototype
implementations to get technical feedback.

COMMUNICATION NETWORKS AND
SYSTEMS FOR POWER UTILITY AUTOMATION –

Part 80-5: Guideline for mapping information
between IEC 61850 and IEC 61158-15

1 Scope
1.1 General
1.1.1 Scope statement
This part of IEC 61850, which is a Technical Report, specifies the mapping rules for building
and configuring a system using both IEC 61850 and IEC 61158-6 (Industrial communication
networks – Fieldbus specification, CPF Type 15, Modbus) protocols by utilizing gateways
between IEC 61850 and IEC 61158-6 IEDs / subsystems. The objective is to enable operational
run-time data exchange among these IEDs / subsystems, and to automate the configuration of
a gateway as much as possible.
Please note that for the purposes of this document, "Modbus" is used to represent both serial
Modbus (Modbus RTU) and IEC 61158-6 (Modbus TCP).
Within the capability of each protocol, some configuration attributes
(IEC 61850-7-3:2010+AMD1:2020 attributes with functional constraint CF) are also mapped in
addition to the operational real-time data.
The rules specified in this document are based on the published standards and do not make
any proposed changes to IEC 61850 or 61158-6. This standard does not specify any rules for
an IEC 61850 IED to directly communicate with a Modbus IED and vice versa, except through
a gateway.
This document does not mandate which data items that a particular IED shall support,
regardless of whether the implementation uses Modbus or IEC 61850. Instead this document
provides rules specifying how a gateway maps any given data item from one protocol to the
other, given that the data item is already available and is transmitted using one of the protocols.
Similarly, this document does not mandate which mapping rules a given gateway shall support.
When this document is republished as a Technical Specification, conformance requirements
will be identified.
This document recognizes that there will be situations in which a user will require that a gateway
perform non-standard protocol mappings. Non-standard mappings are outside the scope of this
document.
This document also recognizes that gateways typically manipulate the data passing through
them in a variety of ways. Some of these functions include alarm trigger grouping, data
suppression, interlocking and command blocking. Conformance to this document does not
preclude a gateway from performing such functions, even though this document primarily
specifies "straight through" mapping of Modbus data to IEC 61850-7-3:2010+AMD1:2020 data.
Subclause 7.4 of this document describes how some of these functions may be specified to a
gateway by a mapping tool using equation notation in XML. However, some of these functions
may be too complex for a mapping tool to specify in an automated manner.

– 8 – IEC TR 61850-80-5:2024  IEC 2024
The mapping architecture for the exchange of the run-time information consists of four parts:
1) Conceptual architecture of a gateway and associated use case
2) Mapping of the information model (Assign semantic to the Modbus data)
3) Mapping of the data (which is in fact part of the information model)
4) Mapping of the services (out of scope for this document)
1.1.2 Areas of application
While a primary focus of this document is for electric utility industry, other industries that deliver
energy and water could also use this document if they also plan to use both Modbus and
IEC 61850 in their systems.
Vendors can use this document to implement and test their gateway products and be assured
of their interoperability to this mapping standard. Users can use this document to specify their
respective systems. System integrators can use this standard to assist in system integration
and testing of user systems utilizing both protocols and gateways.
Modbus device vendors can use this document to express in a non-ambiguous manner the
semantics of each of the data points exposed over the Modbus interface.
1.1.3 Benefits
This document specifies an SCL extension using a Modbus specific XML namespace to add
syntax for describing the mapping of Modbus data into the IEC 61850 data model. By using this
specification, Modbus devices may benefit from the full IEC 61850 ecosystem (engineering
tools, engineering process, functional naming …).
This version of the document focuses on the mapping of Modbus data into the IEC 61850
semantic model and therefore expects the gateway configuration to be mapping data from a
Modbus server to be exposed in an IEC 61850 server access point of the gateway.
1.1.4 Published versions of this standard and related namespace name
This document defines one namespace:
– An SCL schema namespace (SCL)
Table 1 provides an overview of the references between the published versions of this standard
and the related namespace name.
Table 1 – Reference between published versions of the standard
and related namespace name
Edition Publication Webstore Namespace
date
Edition 1.0 2023-xx IEC TR 61850-80-5:20xx IEC 61850-80-5:2020A2

1.2 Namespace name and version
Table 2 shows all the attributes of the XML schema namespace.

Table 2 – Attributes of xsd namespace
Attribute Content
Namespace nameplate
Namespace Identifier (xmlns) http://www.iec.ch/61850/2020/SCL/80-5
XSD version header attribute 2020A2
Recommended reference name eIEC61850-80-5
Version 2020
Revision A
Release 2
CodeComponentName SCL
1.3 Code Component distribution
1.3.1 General
Each Code Component is a ZIP package containing at least the electronic representation of the
Code Component itself and a file describing the content of the package (IECManifest.xml).
The life cycle of a code component is not restricted to the life cycle of the related publication.
The publication life cycle goes through two stages, Version (corresponding to an edition) and
Revision (corresponding to an amendment). A third publication stage (Release) allows
publication of Code Component in case of urgent fixes of InterOp Tissues, thus without need to
publish an amendment.
Consequently, new release(s) of the Code Component may be released, which supersede(s)
the previous release, and will be distributed through the IEC TC57 web site at:
http://www.iec.ch/tc57/supportingdocuments.
The latest version/release of the document will be found by selecting the file for the code
component with the highest value for VersionStateInfo, e.g.
IEC_TR_61850-80-5.SCL.{VersionStateInfo}.full.zip.
1.3.2 XML schema namespace code component
The SCL code component namespace is an XML schema file. It will be available in a full version.
The code component includes sn XML file which is an example file.
The full version is freely accessible on the IEC website for download at
http://www.iec.ch/tc57/supportingdocuments but the usage remains under the licensing
conditions.
In case of any differences between the downloadable code and the IEC pdf published content,
the downloadable code(s) is(are) the valid one; it may be subject to updates. See history files.

– 10 – IEC TR 61850-80-5:2024  IEC 2024
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies.
For undated references, the latest edition of the referenced document (including any
amendments) applies.
IEC TS 61850-2:2019, Communication networks and systems for power utility automation –
Part 2: Glossary
IEC 61850-7-2:2010, Communication networks and systems for power utility automation –
Part 7-2: Basic information and communication structure – Abstract communication service
interface (ACSI)
IEC 61850-7-2:2010/AMD1:2020
IEC 61850-7-3:2010, Communication networks and systems for power utility automation –
Part 7-3: Basic communication structure – Common data classes
IEC 61850-7-3:2010/AMD1:2020
IEC 61850-7-4:2010, Communication networks and systems for power utility automation –
Part 7-4: Basic communication structure – Compatible logical node classes and data object
classes
IEC 61850-7-4:2010/AMD1:2020
IEC 61784-2:2019, Industrial communication networks – Profiles – Part 2: Additional fieldbus
profiles for real-time networks based on ISO/IEC/IEEE 8802-3
IEC 61158-5-15:2010, Industrial communication networks – Fieldbus specifications – Part 5-15:
Application layer service definition – Type 15 elements
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
ISO and IEC maintain terminological databases for use in standardization at the following
addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at http://www.iso.org/obp
For the purposes of this document, the following terms and definitions apply.
3.1.1
Modbus Client
interface which allows the user application to explicitly control information exchange with a
remote device
Note 1 to entry: The Modbus Client builds a Modbus request from parameter contained in a demand sent by the
user application to the Modbus Client Interface. The Modbus Client uses a Modbus transaction whose management
includes waiting for and processing of a Modbus confirmation.
3.1.2
Modbus Server
module which, on reception of a Modbus request, activates a local action to read, to write or to
achieve some other actions
Note 1 to entry: The processing of these actions is done totally transparently for the application programmer. The
main Modbus server functions are to wait for a Modbus request on 502 TCP port, to treat this request and then to
build a Modbus response depending on device context.

3.2 Abbreviated terms
For the purposes of this document, the abbreviated terms given in IEC TS 61850-2,
IEC 61850-7-2:2010+AMD1:2020 as well as the following apply.
GCT Gateway Configuration Tool
ICT IED Configuration Tool
SCT System Configuration Tool
MCD Modbus Configuration Description
4 Architecture of gateways between IEC 61850 and Modbus
4.1 Overview
This clause describes the conceptual architecture of gateways between IEC 61850 and
Modbus. There are two basic types of gateways to be considered:
• Gateway between an IEC 61850 server IED and a Modbus client IED. This may be the case
where the substation with IEC 61850 is connected to the network control center via Modbus
communication.
• Gateway between a Modbus server IED and an IEC 61850 client IED. This is the case where
a Modbus IED must be connected to a substation using IEC 61850.
This document will focus on the second case, because it is more common. The first case may
be treated in a later edition of this document. Nevertheless, the basic principle of both gateway
types is described in Subclauses 4.2 to 4.3.
4.2 Gateway between a Modbus server IED and an IEC 61850 client/subscriber IED
4.2.1 General
The generalized configuration is shown in Figure 1. It consists of several Modbus server
devices, a gateway device and an IEC 61850 client device. One side of the gateway has a
Modbus client interface to communicate with the Modbus server devices and the other side of
the gateway has an IEC 61850 server interface for communication with the IEC 61850
client/subscriber device. The IEC 61850 communications provided by the gateway are out of
scope of this document.
– 12 – IEC TR 61850-80-5:2024  IEC 2024

Figure 1 – Communication between a Modbus server IED and an IEC 61850 client IED
4.2.2 Gateway device
The conceptual architecture of the gateway device is shown in Figure 2. The gateway device is
decoupling the IEC 61850 communication and the Modbus communication via a "Gateway
function". The Gateway function may implement an IEC 61850 process data image. The
advantage of this approach is that a real-time pass-through is not necessarily required for all
messages. The following principles are used for the information exchanges between IEC 61850
and Modbus:
• Run-time operational information (status information, measurements) that is usually
transmitted event driven is exchanged through the process data image. Data retrieval on
the two networks is independent and may take place at different rates.

• Services for the control model interaction are directly forwarded by the gateway. Therefore,
these services are supported by the gateway function.
• Run-time access to other information of the data model (parameters, configuration and
description information, substitution) is directly forwarded to the Modbus IED by the
gateway. Therefore, these services are supported by the gateway function.
This document defines the way data structures are mapped. The way to map the services is not
defined because many ways to implement a service in Modbus exist in the field. Note that the
implementation of the process data image is a local issue. It could be a database, or it could
be something else. Internal operations performed by the gateway on the data in the process
data image are permitted but are out of the scope of this document.

Figure 2 – Architecture of a gateway between a Modbus server IED
and an IEC 61850 client IED
NOTE The term process data image has already been used in IEC 61850-90-2 for the same purpose and is used
here for consistency with other parts of IEC 61850.
4.2.3 Handling of communication interruptions between the Gateway Modbus Client
and the Modbus Server
4.2.3.1 General
The communication between a Modbus Server IED and the Gateway Modbus Client can be
disturbed for various reasons. This will also influence the communication between the Gateway
IEC 61850 server and the IEC 61850 Client. Subclauses 4.2.3.2 to 4.2.3.7 define the behaviour
of the Gateway IEC 61850 Server.
4.2.3.2 Status and Measurands
If the Gateway maintains a local process data image, the quality of status information and
measurands will follow the rules given in IEC 61850-7-2:2010+AMD1:2020, Annex D. A
GetDataValues request will return the last value received from the Modbus Server IED with the
updated status information. A SetDataValues request will result in a ServiceError.Control.

– 14 – IEC TR 61850-80-5:2024  IEC 2024
4.2.3.3 Control
When a Modbus Server IED is disconnected from the Gateway Modbus Client, the Gateway
IEC 61850 server will respond with a temporarily-unavailable ServiceError to all attempts to
control one of the values.
4.2.3.4 Setting Group Control
Setting Group Control is not supported with this edition of the document.
4.2.3.5 Report Control
Reporting, buffered and unbuffered, requires a local process data image. When the
communication between the Modbus Server IED and the Gateway Modbus Client is disturbed,
the quality of the related data in the local process data image will be changed (see 4.2.3.2). If
the trigger option TrgOpt = qchg (quality-change) is set, reports with the updated values will be
send to the IEC 61850 client.
The reporting function itself is not influenced by the communication interruption between the
Modbus Server IED and the Gateway Modbus Client, because the reports for the IEC 61850
client are created in the Gateway IEC 61850 server.
4.2.3.6 Substitution
Substitution is not supported with this edition of the document.
4.2.3.7 File Transfer
File Transfer is not supported with this edition of the document.
4.2.4 Handling of Mod and Beh
IEC 61850 supports the possibility of changing the mode of logical devices or logical nodes by
using the data object Mod that is found in every logical node including in LLN0. Changing any
Mod in the Gateway IEC 61850 server follows the basic rules for operations in the control
direction. All changes of the logical node mode effects only the behaviour of the IEC 61850
server of the Gateway.
This edition of the document does not define any rules how a change of the mode affects the
communication between the Gateway Modbus Client and the Modbus Server of the Modbus
IED.
4.2.5 Handling of Health status
The data object Health of the logical nodes reflecting the Modbus IED data is available in the
Gateway IEC 61850 object model.
The data object Health of LLN0 of the logical devices whose modelling follows the rules defined
in 6.2, represents, as IEC 61850-7-4:2010+AMD1:2020 defines it, the worst "health" of the
logical nodes that are part of the logical device associated with LLN0.
4.2.6 Handling of configuration parameters
The Gateway may support changes of measurement value configurations according to
IEC 61850-7-2:2010+AMD1:2020, such as e.g. scaling or dead band parameters.

Whether the configuration parameters are applied locally or are forwarded to the Modbus Server
IED depends on the implementation of the Gateway and the capabilities of the Modbus Server
IED. The PIXIT of the Gateway contains the information how configuration parameters are
handled.
4.2.7 Handling of substitution
If supported by the Gateway IEC 61850 server implementation substitution from the IEC 61850
client will take place in the Gateway IEC 61850 server.
Substitution of values in the Modbus Server is not supported by this edition of the document.
4.2.8 Service tracking
Tracking of services is local to the Gateway IEC 61850 server for all services that are handled
by the Gateway IEC 61850 server.
4.3 Considerations on configuring the gateway
The following items are to be considered when configuring the gateway.
• Scan cycles
• Bandwidth usage / optimization
• Performance related techniques
• Dealing with units
• Scaling
• Multi-byte handling
• Signed / Unsigned integer handling
• Overflow handling
• "Modbus authentication", verify the IED is the IED it is supposed to be
• Handling/Detection of Communication interruptions on Modbus side
• Error handling of gateway functions and access
5 Modbus to IEC 61850 gateway engineering workflow
5.1 Overview
The configuration of the Modbus to IEC 61850 Gateway involves two main tasks. Each of these
tasks can be split up into several steps.
The first major step is to create a semantically defined IEC 61850 data object model for each
Modbus device (based on IEC 61850-7-3, 7-4, etc.) which includes:
• Find the semantically matching IEC 61850 data object for the Modbus information
• Identify the required data attributes of the CDC for the selected IEC 61850 information
• Define the links between the data attributes and the respective Modbus information
• Define the required conversion functions between the Modbus information and the
IEC 61850 data attributes
When the IEC 61850 data models for all Modbus devices have been created, the Modbus to
IEC 61850 Gateway can be configured:
• Create the object model of the IEC 61850 server out of the data models for the Modbus
devices
– 16 – IEC TR 61850-80-5:2024  IEC 2024
• Define the supported IEC 61850 communication services and the communication
parameters of the server
Subclause 5.2 describe the engineering steps in more detail.

5.2 Extensions to the SCL engineering process
The SCL engineering process will remain same for Modbus devices providing the description
of their data model using SCL files based on mapping extension is defined by this document.
The objective is to give the capability to have an integrated engineering process for Modbus
devices, by means of the same process and the same semantic.
SCL files will be enhanced to contain Modbus mapping associated to IEC 61850 data. Then the
communication part will be extended to integrate engineering of the Modbus device
communication.
The MCD is consumed by the ICT of the gateway in order to configure the gateway and to
produce the ICD/IID file of the IEC 61850 server representing the modbus data.
Finally, thanks to the Gateway concept of IEC 61850, a Modbus system could be integrated into
an IEC 61850 system with a seamless process by sharing the same semantic and the same file
format.
5.3 Extensions of the SCL schema from IEC 61850-6:2019
A schema is attached to IEC 61850-80-5 to define how the Modbus specific data will be added
to an existing SCL.
A dedicated namespace has been created to identify this new schema:
"http://www.iec.ch/61850/2020/SCL/80-5" and will be referred into the SCL file with an
additional versioning attribute of the extension:
5SCL="http://www.iec.ch/61850/2020/SCL/80-5" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.iec.ch/61850/2003/SCL SCL.xsd http://www.iec.ch/61850/2020/SCL/80-5
IEC61850-80-5.xsd" version="2007" revision="B" release="4" eIEC61850-80-5:version="2020" eIEC61850-80-
5:revision="A" eIEC61850-80-5:release="1">
The IEC 61850-80-5 Modbus extension will have to be added under dedicated Private elements
with type "eIEC61850-80-5". These privates will be added at DA level to give Modbus mapping
information attached to the attribute.



The private element could be then added at instance level (DAI) and/or template level (BDA).
NOTE The definition at template level will allow the definition of common mapping information to avoid redefining
it at each instance and indicate only addressing information in specific cases.
The Modbus mapping information has two kinds of elements:
– RegisterRef to indicate mapping address
– ConvFunctRef to indicate transformation rules between IEC 61850 data and Modbus data
The RegisterRef does not include the Modbus server address. Each Modbus address is
modeled as separate IED. See full schema for details.
Then the schema will give extension to a communication section. Configuration of the Modbus
communication will be done with an SCL communication section with the specific SubNetwork
type "MODBUS-IP" or "MODBUS-Serial". Then dedicated P elements will allow the
configuration of communication attributes.



192.168.0.1


1


502





The schema information can be found in the code components.

– 18 – IEC TR 61850-80-5:2024  IEC 2024
6 Mapping
6.1 IEC 61850 & Modbus addressing schemes
IEC 61850 provides a hierarchical information model with the following hierarchical levels:
• Logical device
• Logical node
• Data object
• Data attribute
• Sub data attribute
A physical device may consist of one or more logical devices. The hierarchy of the information
model is used to identify the information. The identification of the information is independent of
the physical device. A data attribute is identified by its path name created from the hierarchy:
 LogicalDeviceName/LogicalNodeName.DataObjectName.DataAttributeName
6.2 Logical device mapping
One Modbus device is to be mapped onto one root LD, and its data can be mapped on nested
LDs. The result of this rule is that the IEC 61850 server will provide multiple root LDs that reflect
the multiple Modbus IEDs.
Figure 4 shows how a physical device is mapped to a device acting as a protocol gateway. In
this figure, LN refers to an application specific LN as defined in the IEC 61850-7-x series.

Figure 3 – Logical device mapping
The logical devices that do not mirror logical devices of Modbus physical devices provide an
LPHD that represent the physical device on which they reside. In Figure 3, this logical device
is PXY_GTW_LD1, which is implemented to represent the information about the gateway itself.
The logical nodes LLN0 and LPHD of this logical device represent information about the
gateway device. The logical device may also contain domain specific logical nodes.
Figure 3 also shows how Modbus physical devices are mapped to the gateway device. LD_MB-1
is used to represent the information related t
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.

Loading comments...