What Is IEC 61850 Conformance Testing?

Back to Blog

What the Test Actually Verifies

Conformance testing puts a device against a defined suite of procedures and checks that its behavior matches what the standard requires: that its services respond correctly, its data model is well formed, its reporting and control behave to specification, and its SCL is valid. The testing is scoped by three vendor documents. The PICS (Protocol Implementation Conformance Statement) lists which parts of the standard the device claims to support. The PIXIT (Protocol Implementation eXtra Information for Testing) gives the implementation-specific details a tester needs. The MICS (Model Implementation Conformance Statement) describes the device's data model.

Passing yields a conformance certificate, which tells a specifier the device was tested against the standard by a recognized process. That is genuinely useful - it filters out implementations that simply do not follow the standard - and it is why substation specifications routinely require conformance certification for the devices they accept.

Why Conformance Is Not Interoperability

The important limitation: conformance is per-device, but interoperability is a property of a system. Two individually conformant devices can still fail to work together if their configurations disagree - a GOOSE publisher and subscriber that do not match, a client expecting a dataset the server does not expose, or an edition mismatch. Conformance checks each device against the standard; it does not check that this device and that device are configured to cooperate.

So the practical workflow is: require conformance certificates to establish a baseline, then do integration testing on the actual configuration to prove the devices interoperate as engineered. Reviewing the PIXIT documents during design catches implementation quirks early, and the SCD - built from each device's SCL - is where you verify that the wiring between devices is consistent. Conformance is necessary, not sufficient, for a working IEC 61850 substation.

How a Test Campaign Actually Runs

Conformance testing is performed by test labs recognized under the UCA International Users Group quality program, using procedures derived from the conformance-testing part of the standard, IEC 61850-10. The vendor submits the device together with its PICS, PIXIT, and MICS, and the lab builds a test configuration around exactly what those documents claim - nothing more. The suite includes positive cases, which confirm that claimed services behave as specified, and negative cases, which confirm the device rejects malformed or out-of-scope requests gracefully instead of crashing or answering nonsense.

The output is a test report and, on a clean pass, a certificate. For an integrator, the report is the more useful document: it enumerates which service models were actually exercised - reporting, control, GOOSE publication and subscription, file transfer - and records any observations the lab made along the way. If you can obtain the report rather than just the certificate page, ask for it; you learn substantially more about the implementation you are about to design around.

Reading a Certificate Before You Trust It

A certificate is a snapshot. It names a specific product, a specific firmware version, and a specific edition of the standard, and all three are scope limits. A device certified against one edition may behave differently alongside peers on another, and a firmware release issued after the test date is, strictly speaking, untested territory - ask the vendor in writing how they maintain conformance across firmware updates, because practices differ widely.

Then check what was actually in scope. Certificates cover the services the vendor claimed in the PICS, not everything the standard defines. A server certificate that never exercised buffered and unbuffered reporting tells you nothing about how the device behaves under a client that depends on buffered events, and a device tested without GOOSE subscription may be perfectly conformant while being useless for your protection scheme. Match the certificate's service list against the services your design consumes, dataset by dataset, before the purchase order goes out.

An Acceptance-Test Ladder from Certificate to Site

Certificates are step zero of a longer verification ladder that ends at site acceptance. A workable sequence looks like this:

1. Collect PICS, PIXIT, MICS, and test reports for every device during design, not after purchase.
2. Verify editions and claimed services against what the system design actually consumes.
3. Build the SCD, validate it with tooling, and review every cross-device data flow it declares.
4. At factory acceptance, run the real configuration: reports delivered, controls executed, GOOSE published and subscribed with the engineered datasets.
5. At site acceptance, repeat the critical flows on installed hardware and networks, including failure injection such as pulling a link.
6. Archive the certificates, reports, and the tested SCD revision together as the system baseline.

The ladder is boring on purpose. Each stage catches a class of problem the previous stage cannot see, and the expensive failures live at the top: a mismatch discovered at site acceptance costs an outage window, while the same mismatch found during a PIXIT review costs an email. Treat the ladder as cumulative evidence, too - when a device is later replaced or upgraded, you rerun only the rungs the change invalidates, not the whole climb, and the archived baseline tells you exactly which rungs those are.

Who Writes What: The Document Trail

Document	Author	What it tells you
PICS	Vendor	Which parts of the standard the device claims to support
PIXIT	Vendor	Implementation-specific details and limits a tester or integrator needs
MICS	Vendor	The device's data model as actually implemented
Test report and certificate	Test lab	What was exercised and passed, for one product, firmware, and edition

Keep the whole trail, not just the certificate. When an integration problem surfaces years later, the PIXIT is routinely the document that explains the quirk, and the archived SCD tells you what was actually proven at commissioning. For orientation on where the conformance-testing part sits among the other parts, see how the 61850 series is structured.

Frequently Asked Questions