Testing

What a conformance certificate actually proves (and what it does not)

2026-10-29 · 7 min read

Somewhere in every procurement there is a line requiring a conformance certificate. It is a reasonable requirement that is frequently misunderstood by both sides: the buyer treats it as a guarantee of interoperability, and the vendor treats it as a box to tick. Neither reading survives contact with a real substation.

What it certifies

A certificate records that a defined suite of tests was executed against a specific implementation, in a specific configuration, at a specific time, and that the implementation behaved as the suite required. It is a statement about conformance to the standard's requirements as encoded in that suite.

That is genuinely valuable: it rules out whole classes of implementation error, and it means the vendor has invested in test infrastructure. It is not nothing.

What it does not certify

• Interoperability with a specific third-party master or device. Two conformant implementations can still disagree about optional features, optional fields, or behaviour the standard permits in more than one way.
• Your configuration. The certificate belongs to the tested build and model; a different ICD, a different dataset layout or a later firmware version is outside its scope.
• Performance. A suite checks behaviour, not throughput under a data storm or memory stability over a month.
• The site. Network behaviour, switching, time synchronisation quality and operator workflow are outside any protocol certificate.

How to read one properly

Four things to look for before treating a certificate as evidence:

• The scope: which parts of the standard, which services, and explicitly what was excluded.
• The build identity: firmware and model revision. If it does not match what you were sold, it certifies something else.
• The test suite version. Suites change; a certificate from six years ago speaks to the state of the art then.
• The issuer and the date, and whether the certificate is still listed by the issuing body.

What to ask for instead

The artefact that actually de-risks an integration is smaller and more specific: a test report against your configuration, with the raw exchanges available.

• A run against the customer's own SCL file, not a demo model.
• Captures on both sides of the link, not only the verdict.
• The negative cases: what happens on malformed input, on timeout, on an unexpected service.
• A statement of what the implementation does NOT support, which is the most useful paragraph in any protocol document.

Our position

We build the test tooling ourselves — the IED-side and client-side conformance testers are products, not internal scripts — because the only way to answer "what does your device do when the master misbehaves" is to have a tool that can misbehave deliberately. When we hand over a report, the raw captures come with it.

Questions that come up

Do we need a certificate to sell into Europe?

Procurement requirements vary by utility and by country, and some do name it. What buyers consistently value is evidence specific to their configuration — which a generic certificate does not provide and a targeted report does.

Can a vendor self-certify?

Vendors can run the suites themselves and publish the results, and many do. Whether that is acceptable depends on the buyer; be explicit about who ran the tests when you present the result.

Our device passed the suite but fails at one customer site. Why?

Almost always an optional-feature or configuration difference, or a network behaviour the suite does not model. Get captures from the site and compare against the suite scenario — the divergence is usually visible in a few minutes.

Keep reading