1 Scope
1.1 General
1.1.1 Scope statement
This part of IEC 61850, which is a Technical Report, specifies the mapping framework for building and configuring a system using both IEC 61850 and IEC 61158‑6‑15 (Industrial communication networks – Fieldbus specification, CPF Type 15, Modbus) protocols by utilizing gateways between IEC 61850 and IEC 61158‑6‑15 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‑15 (Modbus TCP).
Within the capability of each protocol, some configuration attributes (IEC 61850‑7‑3:2010 and IEC 61850‑7‑3:2010/AMD1:2020 attributes with functional constraint CF) are also mapped in addition to the operational real-time data.
The frameworks specified in this document are based on the published standards and do not make any proposed changes to IEC 61850 or 61158-6-15. This standard does not specify any framework 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 will be supporting, regardless of whether the implementation uses Modbus or IEC 61850. Instead, this document provides a framework specifying how a gateway maps any given data item from Modbus into an IEC 61850 substation, including the control direction.
Similarly, this document does not mandate which mapping framework a given gateway will be supporting. 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 and IEC 61850‑7‑3:2010/AMD1:2020 data. Subclause 7.5 of this document describes how some of these functions can be specified to a gateway by a mapping tool using XML representations of conversion functions.
The mapping architecture for the exchange of the run-time information consists of four parts:
Conceptual architecture of a gateway and associated use case
Mapping of the information model (Assign semantic to the Modbus data)
Mapping of the data (which is in fact part of the information model)
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 (see Annex A for use of SCL to include Modbus information). By using this specification, Modbus devices can benefit from the full IEC 61850 ecosystem (engineering tools, engineering process, functional naming, …).
This version of the document describes the mapping of data from a Modbus server to be exposed in an IEC 61850 server access point of the gateway. This is intended to enable automated gateway configuration.
1.2 Published versions of this standard and related namespace name
Table 1 provides an overview of the references between the published versions of this standard and the related namespace name.
1.3 Namespace name and version
The namespace associated with this document is an XML schema (XSD) for an extension to the System Configuration Language (SCL) as defined in IEC 61850‑6. The parameters which are identifying the namespace are provided in Table 2.
1.4 Code Component distribution
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 might be released, which supersede(s) the previous release, and will be distributed through the IEC TC57 web site at:
http://www.iec.ch/tc57/supportdocuments.
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.
The code component associated to this document is an XML schema file (XSD). It is available as a full version only. It is freely accessible on the IEC website for download at http://www.iec.ch/tc57/supportdocuments but the usage remains under the licensing conditions.
In case of any differences between the downloadable code component and the IEC pdf published content, the downloadable code component is the valid one; it can be subject to updates. See included history files.