Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
IEC TR 61850-1:2013 — Communication Networks and Systems for Power Utility Automation: Framework and Concepts
Understanding the architectural framework, communication services, and engineering methodology behind the world’s leading substation automation standard
Standard at a Glance
IEC TR 61850-1 is the foundational introductory document of the IEC 61850 series, providing an overall framework and conceptual overview of communication networks and systems for power utility automation. As a Technical Report (TR), it is informative rather than normative, serving as the essential roadmap for understanding the architecture, communication services, configuration language (SCL), and engineering processes defined across the multi-part IEC 61850 standard suite. It is the indispensable starting point for anyone involved in digital substation design, smart grid communications, or utility automation architecture.
IEC TR 61850-1 is the foundational introductory document of the IEC 61850 series, providing an overall framework and conceptual overview of communication networks and systems for power utility automation. As a Technical Report (TR), it is informative rather than normative, serving as the essential roadmap for understanding the architecture, communication services, configuration language (SCL), and engineering processes defined across the multi-part IEC 61850 standard suite. It is the indispensable starting point for anyone involved in digital substation design, smart grid communications, or utility automation architecture.
1. The Evolution of Substation Communications and the IEC 61850 Paradigm
1.1 From Proprietary Protocols to Standardized Interoperability
Before IEC 61850, substation automation relied on a fragmented landscape of proprietary protocols (Modbus, DNP3, IEC 60870-5-101/103, Profibus, and numerous vendor-specific implementations). Each protocol had its own data model, communication stack, and configuration approach, creating significant interoperability challenges. A protection relay from Manufacturer A could not directly communicate with a bay controller from Manufacturer B without custom gateway devices or protocol converters, increasing system complexity, cost, and maintenance burden.
IEC 61850 fundamentally changed this paradigm by introducing a comprehensive, object-oriented data model combined with abstract communication service interfaces (ACSI). The standard separates the application data model completely from the communication protocol stack, meaning that the same data objects and services can be mapped onto different transport protocols (MMS over TCP/IP, GOOSE directly over Ethernet, Sampled Values directly over Ethernet) without modifying the application layer. This abstraction is the architectural cornerstone that enables true vendor interoperability.
Engineering Insight
The separation of data model from communication protocol is conceptually analogous to the OSI model’s layer separation but goes much further. In IEC 61850, a circuit breaker’s position is modeled as a standardized logical node
The separation of data model from communication protocol is conceptually analogous to the OSI model’s layer separation but goes much further. In IEC 61850, a circuit breaker’s position is modeled as a standardized logical node
XCBR with a specific data object Pos (position), regardless of whether that information travels via MMS to a SCADA system, via GOOSE to a neighbouring protection relay, or via Sampled Values to a merging unit. This means engineers design once for the data model and then select the appropriate communication service for each use case — a dramatic improvement over traditional approaches where the communication protocol dictated the data model.
1.2 The IEC 61850 Series Structure
The IEC 61850 series consists of numerous parts organized into logical groups. IEC TR 61850-1 provides the essential map of this landscape:
| Part Range | Focus Area | Key Content |
|---|---|---|
| 61850-1 | Introduction and overview | TR providing concepts, models, and guidance for navigating the series |
| 61850-2 through -4 | Glossary, general requirements, system and project management | Definitions, quality requirements, engineering lifecycle |
| 61850-5 through -6 | Communication requirements and configuration | Functional requirements, SCL (Substation Configuration Language) |
| 61850-7-x | Basic communication structure | ACSI (7-2), Object models (7-3), Logical node classes (7-4) |
| 61850-8-x | Communication service mappings | MMS mapping (8-1), GOOSE mapping (8-1) |
| 61850-9-x | Sampled Values | Sampled Values over Ethernet (9-2) |
| 61850-10 | Conformance testing | Test procedures for interoperability validation |
| 61850-90-x | Technical reports (applications) | Use cases: hydro, wind, DER, condition monitoring, etc. |
2. Core Concepts: The Three Pillars of IEC 61850
2.1 Information Modeling: Logical Nodes, Data Objects, and Data Attributes
The heart of IEC 61850 is its object-oriented information model. Every physical device or function in a substation is represented as a logical device containing one or more logical nodes (LNs). Each logical node represents a specific function (e.g., XCBR for circuit breaker, PTOC for time overcurrent protection, MMXU for measurement unit). Each logical node contains standardized data objects (DOs), and each data object contains data attributes (DAs) with precise semantics.
The naming convention follows a rigid hierarchy: LD/LN.DO.DA. For example, PROT/PTOC1.Op.general represents the general operation signal of the first time overcurrent protection logical node within the protection logical device. This naming is globally unique and self-documenting — any engineer familiar with IEC 61850 can interpret the meaning without consulting proprietary documentation.
| Logical Node Prefix | Group | Examples | Function |
|---|---|---|---|
| XCBR | Switchgear | XCBR1, XCBR2 | Circuit breaker (position, blocking, operation counting) |
| XSWI | Switchgear | XSWI1 | Disconnector / switch |
| PTOC | Protection | PTOC1, PTOC2 | Time overcurrent protection |
| PDIS | Protection | PDIS1 | Distance protection |
| MMXU | Measurement | MMXU1 | Three-phase measurement (V, I, P, Q, PF, Hz) |
| GGIO | Generic | GGIO1, GGIO2 | Generic process I/O for non-standard signals |
| CSWI | Control | CSWI1 | Switch control (interlocking, select-before-operate) |
| TCTR | Instrument transformer | TCTR1 | Current transformer (Sampled Values) |
| TVTR | Instrument transformer | TVTR1 | Voltage transformer (Sampled Values) |
2.2 Communication Services: MMS, GOOSE, and Sampled Values
IEC 61850 defines three primary communication service types, each optimized for a different category of information exchange:
MMS (Manufacturing Message Specification) — Client/Server Communication: MMS (mapped to TCP/IP) provides reliable, connection-oriented communication for SCADA supervision, configuration, and control commands. It is used for slower-speed data exchange where reliability and completeness are paramount — such as alarm lists, event logs, disturbance records, and parameter settings. MMS uses a client-server model where SCADA systems (clients) request data from IEDs (servers).
GOOSE (Generic Object-Oriented Substation Event) — Peer-to-Peer Fast Messaging: GOOSE is the revolutionary aspect of IEC 61850. It provides high-speed, peer-to-peer communication directly over Ethernet (Layer 2) without TCP/IP overhead. GOOSE messages are published by an IED on a multicast basis and can be subscribed to by multiple receiving IEDs simultaneously. Typical GOOSE applications include interlocking signals, breaker trip commands, and status change notifications — with end-to-end delivery times under 3 ms. GOOSE uses a publish-subscribe model with automatic retransmission at increasing intervals to ensure reliability.
Sampled Values (SV) — Process Bus Communication: SV enables the digitization of analog measurements at the source (merging units in the switchyard) and their transmission over Ethernet to protection relays and bay controllers in the control room. This eliminates the need for traditional copper wiring from CTs and VTs, dramatically reducing installation cost and complexity. SV packets contain time-stamped samples of current and voltage waveforms, typically at 80 samples/cycle for protection and 256–480 samples/cycle for power quality applications.
Design Warning
While GOOSE and SV offer compelling performance advantages, they introduce network design challenges that do not exist in traditional substations. GOOSE and SV traffic share the same Ethernet network, and careful engineering of VLANs (IEEE 802.1Q), priority tagging (802.1p), and network redundancy (IEC 62439 PRP/HSR) is essential. One of the most common design errors is inadequate bandwidth provisioning for SV streams — a single merging unit producing 80 samples/cycle for 4 currents and 4 voltages generates approximately 8–10 Mbps of continuous traffic. With 20 merging units in a large substation, the process bus network must handle 200+ Mbps of deterministic streaming data, requiring careful switch capacity planning and traffic segmentation.
While GOOSE and SV offer compelling performance advantages, they introduce network design challenges that do not exist in traditional substations. GOOSE and SV traffic share the same Ethernet network, and careful engineering of VLANs (IEEE 802.1Q), priority tagging (802.1p), and network redundancy (IEC 62439 PRP/HSR) is essential. One of the most common design errors is inadequate bandwidth provisioning for SV streams — a single merging unit producing 80 samples/cycle for 4 currents and 4 voltages generates approximately 8–10 Mbps of continuous traffic. With 20 merging units in a large substation, the process bus network must handle 200+ Mbps of deterministic streaming data, requiring careful switch capacity planning and traffic segmentation.
2.3 Substation Configuration Language (SCL)
SCL (based on XML) is the standardized configuration language that enables interoperability across the entire engineering lifecycle. IEC 61850-6 defines four types of SCL files that flow through the engineering process:
- ICD (IED Capability Description): Provided by the IED vendor, describes the full capabilities of an IED model — all logical nodes, data objects, services, and communication parameters it supports.
- SSD (System Specification Description): Describes the substation topology (single-line diagram), primary equipment, and the required logical nodes for each function.
- SCD (Substation Configuration Description): The complete, configured system description — the “as-built” engineering output that binds IEDs to their roles, configures GOOSE subscriptions, and sets communication parameters.
- CID (Configured IED Description): An extract from the SCD containing only the configuration relevant to a specific IED, ready to be downloaded to the device.
Engineering Best Practice
Implement a robust SCL management process as the backbone of your IEC 61850 project. Use a system-wide SCL tool (e.g., Siemens SICAM PAS, ABB PCM600, or an independent tool like Helinks SCL Manager) that enforces consistency checking across all ICD, SSD, and SCD files. The most common source of integration issues in multi-vendor IEC 61850 projects is SCL file inconsistency — for example, GOOSE subscription definitions in the SCD that reference data attributes not actually published by the source IED per its ICD. Automated SCL validation against the IEC 61850-6 schema and cross-referencing of GOOSE control blocks are non-negotiable quality assurance steps before commissioning.
Implement a robust SCL management process as the backbone of your IEC 61850 project. Use a system-wide SCL tool (e.g., Siemens SICAM PAS, ABB PCM600, or an independent tool like Helinks SCL Manager) that enforces consistency checking across all ICD, SSD, and SCD files. The most common source of integration issues in multi-vendor IEC 61850 projects is SCL file inconsistency — for example, GOOSE subscription definitions in the SCD that reference data attributes not actually published by the source IED per its ICD. Automated SCL validation against the IEC 61850-6 schema and cross-referencing of GOOSE control blocks are non-negotiable quality assurance steps before commissioning.
3. Engineering the Digital Substation: Practical Implementation
3.1 Architecture Design: Station Bus, Process Bus, and Time Synchronization
A modern IEC 61850-based substation automation system typically implements a two-bus architecture. The station bus connects all IEDs within the substation for MMS communication (SCADA, HMI, gateway to control center) and GOOSE messaging (protection scheme coordination, interlocking). The process bus connects merging units (in the switchyard) to protection relays and bay controllers (in the control room) via Sampled Values and GOOSE for trip commands.
Time synchronization is critical for both SV (sample alignment requires sub-microsecond accuracy) and GOOSE (event time-stamping requires millisecond accuracy). IEC 61850 relies on IEEE 1588 (Precision Time Protocol) — specifically the Power Profile (IEEE C37.238 / IEC 61850-9-3) — to achieve the required synchronization accuracy over the same Ethernet network. A transparent clock architecture using boundary clocks or transparent clocks in the network switches maintains sub-microsecond accuracy across the entire substation.
| Architecture Component | Protocol | Media | Timing Requirement | Typical Data Rate |
|---|---|---|---|---|
| Station Bus (SCADA) | MMS over TCP/IP | 100/1000BASE-FX | ±1 ms | 1–10 Mbps |
| Station Bus (Protection) | GOOSE Layer 2 | 100/1000BASE-FX | ±1 ms | Burst to 50 Mbps |
| Process Bus (SV) | Sampled Values 9-2 | 1000BASE-FX | ±1 µs | 8–10 Mbps per MU |
| Time Sync | IEEE 1588 PTP (C37.238) | Same Ethernet | ±1 µs | Minimal |
| Control Center Link | MMS / IEC 60870-5-104 | WAN / Fiber | ±10 ms | 0.5–5 Mbps |
3.2 Cybersecurity Considerations
With the adoption of Ethernet-based communication throughout the substation, cybersecurity becomes a critical engineering concern. IEC 62351 (Security for power system management and associated information exchange) provides the security framework specifically designed for IEC 61850-based systems. Key measures include:
- Authentication for GOOSE and SV: Digital signatures prevent spoofing of critical trip commands. Without authentication, a forged GOOSE message containing a trip command could cause unintended breaker operation.
- Role-based access control (RBAC): Different operator roles (viewer, operator, engineer, administrator) have different privileges for reading and writing IED data via MMS.
- Network segmentation: The process bus and station bus should be physically or virtually separated, with firewalls or ACLs controlling cross-boundary traffic.
- Intrusion detection: Monitoring for anomalous GOOSE/SV traffic patterns can identify network attacks or device failures before they cause operational impact.
Critical Security Consideration
One frequently overlooked vulnerability in IEC 61850 installations is the GOOSE storm — a condition where a malfunctioning IED or network error causes a cascade of GOOSE messages that saturates the network. Because GOOSE operates at Layer 2 without TCP flow control, a GOOSE storm can degrade or completely block all network communication, including protection-critical SV streams and trip commands. IEC 61850-8-1 specifies a minimum GOOSE retransmission interval that limits the theoretical maximum rate, but engineers must also implement network-level rate limiting (storm control) on managed switches to contain such events. Additionally, GOOSE should never be routed across WAN links without dedicated GOOSE-aware firewalls that can inspect and filter GOOSE messages at the application layer.
One frequently overlooked vulnerability in IEC 61850 installations is the GOOSE storm — a condition where a malfunctioning IED or network error causes a cascade of GOOSE messages that saturates the network. Because GOOSE operates at Layer 2 without TCP flow control, a GOOSE storm can degrade or completely block all network communication, including protection-critical SV streams and trip commands. IEC 61850-8-1 specifies a minimum GOOSE retransmission interval that limits the theoretical maximum rate, but engineers must also implement network-level rate limiting (storm control) on managed switches to contain such events. Additionally, GOOSE should never be routed across WAN links without dedicated GOOSE-aware firewalls that can inspect and filter GOOSE messages at the application layer.
Frequently Asked Questions
Q1: What is the difference between IEC 61850 and IEC 60870-5-101/104?
A: IEC 60870-5-101/104 are telecontrol protocols designed for SCADA communication between control centers and remote substations. They use a simple, non-object-oriented data model with predefined information object addresses (standardized in IEC 60870-5-101 or user-defined). IEC 61850 is far more comprehensive: it provides an object-oriented data model (logical nodes, data objects, attributes), standardized configuration language (SCL), high-speed peer-to-peer communication (GOOSE), process bus digitization (Sampled Values), and formal conformance testing. IEC 61850 is designed for intra-substation communication at all levels, while IEC 60870-5-104 remains widely used for control center communication due to its simplicity and established deployment base. Many installations use both: IEC 61850 within the substation and convert to IEC 60870-5-104 for the control center link.
Q2: Is it necessary to implement the full IEC 61850 series for substation automation?
A: No. IEC 61850 is modular by design, and you can implement only the parts relevant to your application. A simple remote terminal unit (RTU) may only need MMS client/server for SCADA communication (parts 7-2, 7-3, 7-4, 8-1), while a protection scheme requires GOOSE (same parts plus GOOSE-specific configuration). A full digital substation with process bus adds Sampled Values (part 9-2) and precision time synchronization (part 9-3). IEC TR 61850-1 provides guidance on selecting the appropriate subset for each use case. However, adopting the SCL configuration language (part 6) from the start is strongly recommended even for simple systems, as it provides the engineering documentation discipline that pays dividends during expansion and maintenance.
Q3: Can IEC 61850 be used for renewable energy and distributed energy resources (DER)?
A: Absolutely. IEC 61850-7-420 defines logical nodes specifically for DER systems including photovoltaic, wind turbine, fuel cell, battery storage, and combined heat and power. IEC TR 61850-90-7 extends the model for DER inverter-based power plants, including communication for active power control, reactive power/voltage regulation, and ride-through requirements. For wind power plants specifically, IEC 61400-25 uses IEC 61850 as its communication basis. The standard’s flexibility makes it suitable for the full spectrum of power system automation — from generation (conventional and renewable) through transmission, distribution, and customer premises.
Q4: What are the main challenges when migrating an existing substation to IEC 61850?
A: The primary challenges are threefold. (1) Legacy device integration: Existing protection relays and RTUs using proprietary protocols must be integrated via protocol converters or gateway devices, which adds cost and complexity. A common approach is to deploy IEC 61850 bay controllers that interface with legacy IEDs via serial links and present a unified IEC 61850 interface upstream. (2) Engineering process change: The shift from individual IED configuration to system-level SCL-based engineering requires new tools, training, and workflow discipline. (3) Network infrastructure: Existing copper-based wiring must be replaced with fiber-optic Ethernet, and network switches with support for VLANs, priority queuing, PRP/HSR redundancy, and IEEE 1588 PTP must be deployed. The total cost of ownership analysis should include not just the IED replacement cost but the network infrastructure, engineering tools, training, and commissioning testing — which can amount to 40–60% of the total project cost.
