Interoperability Testing Between Vendors: Making IEC 61850 Work in the Real World
We were on site at a UK digital substation project a few years ago when the commissioning engineer called us over with a look we’ve seen too many times. A protection IED from one major vendor simply would not exchange GOOSE messages with a bay controller from another. Both devices carried certificates declaring full IEC 61850 compliance. Both vendors had signed off their type test documentation. And yet, on that panel, in that substation, nothing moved. That afternoon taught us more about interoperability than any datasheet ever could, and it’s the reason we now treat vendor-to-vendor testing as a project discipline in its own right rather than an afterthought.
Why Interoperability Testing Matters in IEC 61850
IEC 61850 is a framework, not a guarantee. It defines abstract data models, a configuration language, and a set of communication mappings, but it deliberately leaves room for interpretation in how those pieces are implemented. That flexibility is what makes the standard powerful and what makes interoperability testing essential for any serious substation automation or smart grid deployment.
The Gap Between Compliance and Interoperability
A compliance certificate tells you a device behaves correctly against a specific test suite. It does not tell you how that device will behave when it sits opposite a different vendor’s implementation of the same service. Vendors make legitimate engineering choices around optional fields, default values, retransmission behaviour, and dataset ordering. Individually, each choice is defensible. Combined, they can stop a protection scheme from tripping.
We’ve seen this play out across ABB, Siemens, GE, and Schneider Electric equipment on the same project. All four vendors can pass their own conformance tests and still fail to talk to each other without careful configuration and, sometimes, firmware adjustments.
Real-World Consequences for UK Digital Substations
The consequences aren’t abstract. Delayed commissioning, extended outages, expensive site visits from vendor engineers, and in the worst cases, protection schemes that behave differently from the design intent. On a digital substation where Sampled Values replace copper wiring, a misconfigured publisher can blind an entire bay. That’s why we now insist on interoperability testing as a gate before any energisation date is confirmed.
Key Areas Where Vendors Commonly Diverge
After enough projects, patterns emerge. The same handful of areas cause most of the pain, and knowing them in advance saves weeks of debugging.
GOOSE and Sampled Values: Timing and Configuration
GOOSE is publisher-subscriber by design, and small differences matter enormously. Retransmission intervals, VLAN priorities, dataset element ordering, and the handling of the stNum and sqNum counters are all places where implementations drift. Sampled Values add a further layer: sample rate, synchronisation source, and the treatment of missing samples. We’ve watched a Siemens relay accept a GOOSE stream from a GE device but ignore the trip bit because the dataset order differed from the SCL file.
MMS Reporting and Client-Server Behaviour
MMS reporting is where SCADA integration often stumbles. Buffered report control blocks, integrity periods, trigger options, and the handling of optional fields vary between vendors. A gateway that works perfectly with one vendor’s IEDs may drop reports from another because of a subtly different interpretation of the report control block attributes.
SCL Engineering and File Exchange
SCL files are supposed to be the glue that holds multi-vendor systems together, but in practice they’re often the weakest link. Different SCL tools produce different output for the same logical model. Private extensions, namespace handling, and the treatment of IED section boundaries all cause friction. We’ve lost days reconciling an SSD file that one vendor’s tool accepted and another rejected outright.
- GOOSE dataset ordering and retransmission behaviour
- Sampled Values synchronisation and sample rate handling
- MMS buffered and unbuffered report control block semantics
- SCL file export, private extensions, and namespace handling
- Time synchronisation source selection and fallback behaviour
How to Plan and Execute Interoperability Tests
Interoperability testing works best when it’s structured, documented, and done early. We treat it as a project phase with its own deliverables, not a box to tick during commissioning.
Building a Representative Test Environment
Start with a lab that mirrors the real substation as closely as possible. That means the actual IED models, the actual SCL files, the actual network topology including switches and VLANs, and the actual time synchronisation source. If the site will use PTP, test with PTP. If it will use IRIG-B, test with IRIG-B. Anything less and you’re testing a different system.
Defining Test Cases and Acceptance Criteria
Write test cases before any device arrives. Cover normal operation, degraded operation, and failure modes. Define what “pass” means in measurable terms, and get all vendors to agree to those criteria in writing. This is where most projects save themselves weeks of argument later.
Using Simulation and Monitoring Tools
We rely heavily on OMICRON and Doble test equipment for injection and analysis, alongside Wireshark for packet-level inspection of GOOSE, Sampled Values, and MMS traffic. These tools let us see exactly what’s happening on the wire and, more importantly, prove it to vendors who might otherwise insist their device is behaving correctly.
Lessons from UK Digital Substation Projects
The UK has become a genuine testing ground for multi-vendor IEC 61850 deployments, and the lessons from those projects are worth sharing.
National Grid and SSEN Case Examples
National Grid’s digital substation trials demonstrated that process bus architectures can deliver real operational benefits, but only when interoperability is engineered rather than assumed. SSEN’s flexible networks project showed similar results on the distribution side, where the mix of legacy and modern IEDs creates its own interoperability challenges. In both cases, the projects that invested in early multi-vendor testing hit their milestones. The ones that didn’t, didn’t.
What We Learned About Vendor Collaboration
Vendors cooperate far better when they’re in the same room, or at least on the same call, early. We’ve found that a joint test session in a neutral lab resolves in two days what months of email escalation cannot. It also builds relationships that pay off when the next firmware update lands.
Best Practices for Smooth Vendor Interoperability
The good news is that most interoperability problems are preventable with a bit of discipline.
Early Vendor Engagement and Documentation
Bring vendors in during design, not commissioning. Share the SCL strategy, the network design, and the test plan. Ask each vendor to document their known deviations and optional feature choices. That documentation becomes the foundation of your test cases.
Leveraging UCA IUG and Industry Profiles
The UCA IUG (UCA International Users Group) test procedures give you a vendor-neutral baseline for interoperability testing. Combined with UK-specific industry profiles, they provide a defensible framework that all vendors recognise and, in our experience, respect.
Regression Testing After Updates
Every firmware update is a potential interoperability event. We insist on regression testing after any firmware change, however minor the release notes claim it to be. A single changed default has broken more schemes than we care to count.
The Future of Interoperability Testing in Smart Grids
The direction of travel is clear: more automation, more simulation, and more standardisation.
Digital Twins and Automated Test Suites
Digital twins of substations are moving from research into practice. They let us run interoperability test cases against virtual IEDs before hardware arrives, and they make regression testing dramatically cheaper. Automated test suites built around these twins will become standard on UK projects within a few years.
Impact of IEC 61850 Edition 2.1 and Beyond
IEC 61850 Edition 2.1 clarifies several ambiguities that caused vendor divergence in Edition 2, particularly around SCL and reporting. It won’t eliminate interoperability problems, but it narrows the space in which they occur. Future editions are expected to go further, especially around virtualisation and cybersecurity integration.
FAQ
Is IEC 61850 compliance the same as interoperability?
No. Compliance means a device passes a defined conformance test suite. Interoperability means it actually works with other vendors’ devices in a real system. You need both, and they’re tested differently.
How early should interoperability testing start on a UK substation project?
As early as possible, ideally during detailed design. Waiting until commissioning is the single most common cause of project delays we see.
Which tools do you recommend for IEC 61850 interoperability testing?
We regularly use OMICRON and Doble test sets for injection and analysis, and Wireshark for packet-level inspection. The UCA IUG test procedures provide the framework around those tools.
Does IEC 61850 Edition 2.1 fix interoperability problems?
It reduces them by clarifying ambiguities in Edition 2, but it doesn’t remove the need for testing. Vendor implementation choices will always create some level of divergence.
How often should regression testing be repeated?
After every firmware update, every SCL change, and every configuration modification that touches communication. We treat regression testing as a continuous activity, not a one-off event.
Interoperability testing isn’t a phase you complete and move past. It’s a discipline that runs through design, commissioning, and the entire operational life of a digital substation. UK utilities that treat it that way are the ones realising the smart grid vision. Those that don’t will keep finding themselves on site, staring at two compliant devices that simply refuse to talk to each other.
