The UCA International Users Group has announced the opening of registration for 61850 IOP 2026 — the annual interoperability testing event for equipment and software tools conforming to the IEC 61850 standard. The event will take place in Europe in autumn 2026. 11 network equipment vendors have already confirmed their participation.

Why MPLS Has Entered the Testing Programme

The IEC 61850 standard was originally designed for use within the local area networks of substations: GOOSE messages and Sampled Values (SV) streams are exchanged within a single site, at Layer 2. However, modern power systems demand more — links between multiple substations, remote access from control centres, integration with corporate networks. This is where MPLS (Multiprotocol Label Switching) comes in: the technology that telecom operators use to build wide-area networks.

At the boundary between the substation LAN and the telecom network, several non-trivial challenges arise:

  • Routable GOOSE and SV. Standard GOOSE and SV operate as Layer 2 multicast frames and physically cannot pass through a router. The IEC 61850-90-5 standard defined the R-GOOSE and R-SV formats — encapsulation in UDP/IP for WAN transmission. Making these protocols work together in a multi-vendor MPLS environment remains a complex task for several concrete reasons.

    • IP multicast over WAN. R-GOOSE is sent to a group IP address. For packets to reach all subscribers in other network segments, the MPLS infrastructure must support multicast routing protocols (PIM-SM or equivalents). Typical WAN configurations offered by telecom operators do not provide multicast for third-party clients — each case requires individual negotiations with the provider and manual configuration.

    • Latency and QoS requirements. Protection functions require GOOSE delivery within no more than 10 ms. In a WAN channel, latency accumulates from several components: queuing jitter, signal propagation time, processing at border routers. Traffic prioritisation in IEC 61850 is specified via the PCP (Priority Code Point) field in the Ethernet VLAN tag; upon entering the MPLS network, these bits must be mapped to the TC (Traffic Class) field of MPLS labels — but the exact mapping method and its correctness depend on each vendor's implementation.

    • Standard fragmentation. IEC 61850-90-5, on which R-GOOSE was based, has been officially withdrawn; current requirements have been moved to Amendment 1 of IEC 61850-8-2 under Ed.2. Some vendors implemented support based on the old document — as a result, different devices may use incompatible encapsulation variants, which is only revealed during joint interoperability testing.

  • Time synchronisation. Telecom operators use the PTP Telecom Profile (ITU-T G.8275 standard), while substation applications require the IEC 61850 Power Profile (IEC 61850-9-3). At the boundary between the two environments, profile conversion is required — this is included in the IOP 2026 programme as a dedicated test scenario.

  • Cybersecurity. When IEC 61850 traffic leaves the substation perimeter, the security boundary dissolves. IEC 62351-14 defines security management requirements for automation systems: IOP 2026 plans to verify corporate public key infrastructure (PKI) supporting SCAP, EST and LDAP protocols, as well as structured Syslog logging.

  • Network configuration from the SCD file. One of the most promising directions: MPLS network equipment (switches, routers) receives its configuration directly from the substation's digital project file — the SCD. This approach was first demonstrated at IOP 2024 in Birmingham; more mature implementations and cross-vendor verification are expected in 2026.

The IOP 2026 test infrastructure will include at least five isolated LANs interconnected via MPLS — recreating a realistic multi-node topology with real communication barriers between segments.

What Are Basic Application Profiles and Why They Change the Rules

The key methodological innovation of IOP 2026 is the conduct of functional tests based on Basic Application Profiles (BAP) — standardised application profiles defined in two IEC technical reports:

TR IEC 61850-7-6 (Ed. 2, 2024) — "Guidelines for defining Basic Application Profiles". The document describes how to formalise a typical protection or automation function as a machine-readable profile: which logical nodes are involved, which signals a device must produce or consume, and what the interfaces to other systems are. Unlike the first edition (2019), where profiles existed only as textual descriptions in Word and Excel, the second edition brings BAP into SCL format — the same format used for substation engineering files — enabling automated verification.

TR IEC 61850-90-30:2025 — "Guidelines for modelling IEC 61850 functions in SCL". This technical report describes the complete top-down engineering process: from the system functional specification (SSD) through to the configuration of individual devices (ICD → SCD). It introduces new SCL elements for hardware-independent requirements description and a new SCC (System Configuration Collaboration) file format for multi-engineer collaboration on a single project.

The Problem Without BAP

Before BAP profiles existed, each IED manufacturer implemented the same function — for example, distance line protection — in its own way, using proprietary logical nodes or private model extensions. The consequence: even when formally conforming to IEC 61850, devices from different vendors required individual configuration for every combination of "protection + bay controller + process interface". The same function in different bays of a substation could be implemented differently — depending on which vendor's equipment was installed there.

What BAP Changes

BAP establishes an unambiguous "contract": for a specific application — for example, short-circuit protection with auto-reclosing — it is precisely defined which signals must be present, what they must be named, and how they must interact. If two devices from different vendors both correctly implement the same BAP, they should work together without additional manual adjustment.

At IOP 2024 in Birmingham, the BAP approach was applied in testing for the first time: typical bays (line bay, bay with sync-check, bay with breaker failure protection) were equipped with devices from different vendors, which chose their roles according to their capabilities. Functions tested included line protection, auto-reclosing, sync-check switching, breaker failure protection, and planned maintenance without taking the bay out of service (virtual isolation).

The Purpose of These Tests

IEC 61850 IOP is not a certification or a competition. It is collaborative debugging in a safe environment: manufacturers connect real equipment and software solutions to a shared test infrastructure, identify interoperability problems, and work on resolving them on the spot. Results are not published in a "pass/fail" format — instead, participants receive detailed technical reports on identified incompatibilities.

The shift to BAP testing means moving from the question "can devices exchange data?" to the question "can devices jointly perform a specific protection or control function?" — which is much closer to the real requirements of the power system.

How to Participate

IOP 2026 is an in-person multi-day event. Exact dates and location will be announced separately; Europe, autumn 2026 is planned. Registration is open.