1.1 General

This part of IEC 61850, which is a technical specification, provides a comprehensive overview of the various aspects that need to be considered while using IEC 61850 for information exchange between power system automation equipment and control or maintenance centres or other system level applications. This document:

• defines use cases and communication requirements that require an information exchange between power system automation equipment and control or maintenance centres;

• describes the usage of the configuration language of IEC 61850‑6;

• gives guidelines for the selection of communication services and architectures compatible with IEC 61850;

• describes the engineering workflow;

• introduces the use of a Proxy/Gateway concept;

• describes the links regarding the Specific Communication Service Mapping (SCSM);

• defines the abstract conformance test cases that build the basis for the conformance test procedures elaborated by the UCAIug Testing Sub Committee.

This document does not define constraints or limitations for specific device implementations. There is no specific clause for cyber security, which is tackled when it is necessary. The model for IEC TS 61850‑80‑6 provides security functions based upon the security threats and security functions found in IEC TS 62351‑1 and IEC TS 62351‑2. This document touches on several security aspects with the following basic assumptions:

• Information authentication and integrity (e.g., the ability to provide tamper detection) is needed.

• In case of operational issues, encryption (to achieve confidentiality) is optional. This typically applies for GOOSE and SV messages in the power utility automation system LAN.

End-to-end information authentication and integrity methods, regardless of information hierarchies, need to be provided. The typical method to provide this security function is through some type of information/message authentication code. IEC 62351‑4 and IEC 62351‑9 describe how authentication and integrity is achieved for IEC 61850‑8‑1. IEC 62351‑4 provides means to ensure end-to-end data integrity through Proxy/Gateways.

Beneath information authentication and integrity, information availability is an important aspect for telecontrol. This document provides redundancy architectures to enhance the availability of information in control and maintenance centres.

The scheme shown in Figure 1 gives an overview of the connectivity and the communication paths. It indicates the principle to access directly or indirectly – via the Proxy/Gateway – to an IED. An application of security controls for power system automation equipment to control centre communication can be found in IEC 62351‑10:2012, 6.4.3. Thus, the power system automation equipment is considered to be inside a perimeter of cyber security. The access is totally checked by network security access points (this document does not describe such a network security access point). The boundary of the electronic security perimeter is defined by the point, where the communication line leaves the perimeter of the power utility automation system over public ground. There can be more than one network security access point, where separation of applications (e.g., control centre and maintenance centre) is required. When more than one client needs access to the same network security access point information level access control, e.g. according to IEC TS 62351‑8, can be added. IEC TS 62351‑8 can also be used in other cases, where different access rights are required.

Most applications for which this document is applicable will use the services of MMS (ISO 9506) mapped to ISO/IEC 8802‑3 frame formats, as described in IEC 61850‑8‑1.

The primary application for the use of indirect access, as described in this document, will be for telecontrol applications. Nevertheless, this document does not imply that the use of a Proxy/Gateway is required for telecontrol applications. Direct access can also be used for telecontrol applications where applicable and accepted by the customer.

1.2 Published versions of this standard and related namespace name

Table 2 provides a reference between all published editions, amendments or corrigenda of this document and the full name of the namespace.

1.3 Identification of the Code Components

1.4 Code component distribution

Each Code Component is a ZIP package containing the electronic representation of the Code Component itself, with 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 a Code Component will be found by selecting the file for the Code Component with the highest value for VersionStateInfo, e.g.{VersionStateInfo}.Full.zip.

For conformance testing, implementations should always use the latest downloadable Code Components, as the Code Components might be subject to updates. See technical corrigenda and XSD history files.

When the Code Components associated with this document have a full version and a light version, the light version is freely accessible.

When the Code Components associated with this document have a full version only, the full version is freely accessible.

The freely accessible Code Components are available on the IEC website for download at: http://www.iec.ch/tc57/supportdocuments, but the usage remains under the licensing conditions.