Introduction

If you have ever opened an SCL file from another vendor and wondered whether it is actually correct — not just well-formed XML, but semantically valid against the IEC 61850 standard — you already understand the problem that OCL is trying to solve.

XML Schema validation tells you whether the file is structured correctly. It cannot tell you whether a GOOSE subscription references a valid dataset, whether a logical node contains the required data objects, or whether two LDs are wired together in a way that makes sense. That level of checking requires something more expressive.

Object Constraint Language (OCL) is that something. And as of 2025, IEC has published IEC TS 61850-6-3, a Technical Specification that formally describes how OCL rules should be written and applied to IEC 61850 XML-based files — including SCL.

This article explains what OCL is, why it matters for engineers working with SCD and ICD files, how it is already being used in practice, and what the ongoing standardisation work means for the industry.

What Is OCL?

OCL — Object Constraint Language — is a formal language originally developed as part of the Unified Modeling Language (UML) specification. It allows you to express constraints and queries on object models in a precise, unambiguous way.

In plain terms: where UML diagrams describe what a model looks like, OCL lets you write rules about what must always be true in a valid model.

An OCL constraint looks like a logical statement attached to a model element. For example, in the context of IEC 61850, you could express a rule such as:

Every LDevice must have at least one LN0, and at most one.

Or:

A GOOSE subscription ExtRef must reference a dataset that exists in the file.

XML Schema cannot enforce rules like these. OCL can. And because OCL operates at the model level — not the XML syntax level — it can navigate relationships between elements across the entire configuration file.

Why SCL Validation Needs More Than XML Schema

IEC 61850 uses Substation Configuration Language (SCL) to describe the configuration of intelligent electronic devices (IEDs), the substation topology, and the communication between them. SCL files — SSD, SCD, ICD, CID, IID — are XML documents.

XML Schema (XSD) validates the structure of these files: element names, attributes, cardinality. That is necessary but not sufficient.

The IEC 61850 standard contains hundreds of additional rules that XML Schema cannot express:

  • Cross-references between elements (a subscribed signal must match a published one in name and type)
  • Constraints that depend on attribute values ("if type = GOOSE, then...")
  • Rules about mandatory and optional data objects depending on logical node class
  • Engineering consistency checks between different sections of an SCD file

Without machine-checkable rules for these constraints, validation has been left to tools doing it their own way — inconsistently, incompletely, or not at all. The result is interoperability problems discovered late: during factory acceptance tests, site commissioning, or interoperability events.

IEC TS 61850-6-3: The New Standard

In 2025, IEC TC57 Working Group 10 published IEC TS 61850-6-3:2025 — "Format of machine-processable rules for validation of IEC 61850 XML-based files".

This Technical Specification does three things:

  1. Defines the format for writing OCL validation rules for IEC 61850 — a structured, standardised way to express constraints that tools can import and execute.
  2. Supports three main use cases: - Validating SCL files at every stage of the engineering process - Verifying conformity after upgrading/downgrading between standard editions - Extending standard rules with private (vendor- or project-specific) OCL rules
  3. Separates the format from the rules themselves — the Technical Specification covers how to write rules, while the actual rule sets are published as code components attached to the corresponding IEC 61850 parts (such as IEC 61850-6).

The standard is 33 pages and was published on 8 July 2025. It is the first formal IEC document describing how OCL should be used in the IEC 61850 ecosystem.

How OCL Rules Work in Practice

The workflow is straightforward in principle:

flowchart LR
    A[IEC 61850 Standard\nUML Model] -->|defines| B[OCL Rules\n.ocl files]
    C[SCL File\nSCD / ICD / CID] -->|loaded into| D[Model Instance]
    B -->|applied to| D
    D -->|produces| E[Validation Report\nerrors / warnings]
    E -->|feedback to| F[Engineer /\nSystem Integrator]
  1. The IEC 61850 UML model is the reference. OCL rules are written against this model — they describe what constraints are always valid.
  2. An SCL file is loaded into a tool that instantiates it as an object model (rather than just parsing XML).
  3. The OCL rules are applied to that model instance.
  4. Violations are reported with precise locations and descriptions.

The key insight is that OCL works at the semantic level. It can navigate the object graph — following references, checking conditions across the file — in ways that simple XSD or XSLT checks cannot.

RiseClipse: The Open Implementation

The primary open-source implementation of OCL-based SCL validation is RiseClipse, developed by CentraleSupélec and EDF R&D in France under the RISEGrid research programme.

RiseClipse:

  • Loads SCL files and instantiates them as EMF (Eclipse Modeling Framework) objects conformant with the SCL UML model

  • Applies OCL constraint sets expressed in .ocl files

  • Reports violations at the semantic level — not just "element missing" but "this ExtRef references a non-existent dataset"

The OCL constraint files for SCL are published as an open-source repository on GitHub: riseclipse/riseclipse-ocl-constraints-scl2003.

RiseClipse can be used in several ways:

  • Command-line tool (fat JAR) for integration into CI/CD pipelines and engineering workflows

  • Docker image for containerised deployment

  • Triangle MicroWorks SCL Navigator — a commercial tool with the RiseClipse OCL engine embedded, with a free reader mode available

  • CoMPAS (LFEnergy project) — uses RiseClipse as its SCL validation backend

RiseClipse was first used at IEC 61850 interoperability testing events as early as 2015, where it identified errors that other validation tools missed.

The WG10 TF OCL Work: What Is Happening Now

The publication of IEC TS 61850-6-3 was not the end of the work — it was the beginning of the next phase.

IEC TC57 Working Group 10 has a dedicated Task Force on OCL (TF OCL) responsible for developing the actual rule sets to be published alongside the standard parts. These rule sets define what it means, formally and machine-checkably, for an SCL file to conform to IEC 61850-6. As of March 2026, the task force is preparing the first publication of OCL rules for SCL files.

What This Means for Engineers and Integrators

For engineers who work with SCL files daily, OCL-based validation represents a meaningful shift:

More complete checking. OCL rules can catch errors that XSD validation misses — dangling references, missing mandatory objects, inconsistent configuration across IEDs.

Consistency across tools. When the rule set is standardised by IEC and published as machine-processable code, every tool can run the same checks. Today, different tools apply different subsets of the standard's rules, which leads to inconsistent results.

Formal traceability. Each OCL rule can be linked back to a specific clause in the IEC 61850 standard. If your file fails a check, you know exactly which normative requirement it violates.

Extensibility. IEC TS 61850-6-3 explicitly allows private OCL rules — project-specific or vendor-specific constraints that go beyond the standard. This means utilities can encode their own engineering rules in the same formal language.

Practical implication: Engineers should expect SCL validation in modern tools to become stricter and more consistent as OCL rule sets are published and adopted. Files that pass today's basic checks may need corrections when validated against the full OCL rule set.

Common Misunderstandings

"OCL is a new IEC 61850 standard."
OCL is not a new communication protocol or data model. It is a language for expressing validation rules. The new element is IEC TS 61850-6-3, which defines how OCL should be used in the IEC 61850 context.

"XSD validation is enough."
XML Schema validation is necessary but far from sufficient for SCL correctness. XSD checks structure; OCL checks semantics. An SCL file can be XSD-valid and still be logically incorrect.

"Only tool developers need to care about this."
Utilities and system integrators will increasingly encounter OCL-based validation in engineering tools. Understanding what it checks — and why — helps engineers interpret validation results and write better configuration files.

"The rules are complete and final."
The TF OCL is still publishing the initial rule set. The rules will evolve. Private rule extensions will be possible. This is an ongoing process, not a one-time publication.

Conclusion

OCL-based validation is filling a long-standing gap in IEC 61850 engineering: the absence of formal, machine-checkable rules that go beyond XML Schema. IEC TS 61850-6-3 provides the foundation — a standardised format for writing and distributing these rules. The WG10 TF OCL is building the actual rule sets on top of that foundation.

For engineers and system integrators, the practical impact will be felt through stricter, more consistent SCL validation in the tools they use. Files that have quietly contained semantic errors — cross-references pointing nowhere, missing mandatory objects, inconsistent subscriptions — will no longer pass unnoticed.

The work is ongoing. The first batch of rules is being finalized as of early 2026. As the rule sets mature and tool adoption grows, OCL will become a standard part of the SCL engineering and commissioning workflow.