Introduction

Scope: This article explains what Object Constraint Language (OCL) is, why it matters for SCL file validation in IEC 61850 projects, what IEC TS 61850-6-3 defines, and where the open-source RiseClipse tool fits in. It does not cover OCL implementation details for tool developers, nor does it address all aspects of IEC 61850 conformance testing.

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. 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 being used in the open-source RiseClipse tool, and what the ongoing standardisation work defines.

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.

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 is 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. 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 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 or 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 was published on 8 July 2025. It is the first formal IEC document describing how OCL should be used in the IEC 61850 ecosystem.

Note: IEC TS 61850-6-3 is a Technical Specification, not a full International Standard. It defines a framework and format; the specific OCL rule sets for SCL are being developed separately by WG10 TF OCL and are not yet fully published as of early 2026.

How OCL Rules Work in Practice

The validation workflow:

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.

OCL works at the semantic level: it can navigate the object graph — following references, checking conditions across the file — in ways that XSD or XSLT checks cannot.

RiseClipse: The Open-Source 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 has been used at IEC 61850 interoperability testing events since at least 2015 (see: Marcadet et al., PSCC 2016). Broader adoption across the industry remains limited; the tool and the associated rule sets are still maturing.

The WG10 TF OCL Work: What Is Happening Now

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.

The work of the task force is described in IEC TS 61850-6-3:2025, which establishes the framework and format for OCL rule sets. As described in the Technical Specification, the rule development process requires testing candidate rules against real-world engineering files to verify correctness and completeness before normative publication.

This is typical of early-stage standardisation work: rules must be validated against the range of real configurations before they can be published normatively. The balance between completeness and timely release is a common challenge at this stage of specification development.

No full timeline for the first rule set publication has been announced publicly as of this writing.

Practical Implications for Engineers and Integrators

For engineers who work with SCL files, OCL-based validation addresses a known gap: semantic checks that XSD validation cannot perform. The practical significance depends on how quickly tool vendors adopt the published rule sets.

Specific capabilities that OCL rules enable:

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

Consistent checks across tools. When the rule set is standardised by IEC and published as machine-processable code, different tools can run the same checks against the same normative basis. Today, tools apply different subsets of the standard's rules, which produces inconsistent results.

Traceable rule-to-clause mapping. Each OCL rule can be linked back to a specific clause in the IEC 61850 standard. If a file fails a check, the engineer can identify which normative requirement is violated.

Private rule extensions. IEC TS 61850-6-3 explicitly allows private OCL rules — project-specific or vendor-specific constraints beyond the standard. Utilities can encode their own engineering rules in the same formal language.

Engineers should expect SCL validation in tools to become stricter as OCL rule sets are published and adopted. Files that pass today's basic XSD checks may need corrections when validated against a full OCL rule set.

Limitations

Several practical boundaries apply to OCL-based SCL validation as it stands today:

Rule coverage is incomplete. The WG10 TF OCL first publication is being finalized in early 2026. It will not cover all constraints in IEC 61850-6. Rule sets will expand in subsequent releases.

Tool adoption is limited. As of early 2026, RiseClipse and CoMPAS are the primary tools using OCL-based SCL validation. Most commercial IEC 61850 engineering tools do not yet implement IEC TS 61850-6-3 rule sets.

RiseClipse maturity. RiseClipse is a research-origin tool. It has been used at interoperability testing events and in research contexts. It is not yet a certified conformance testing tool, and the OCL rule sets it uses are not yet the finalized IEC-published sets.

Scope of IEC TS 61850-6-3. The Technical Specification defines a format for rules — not the rules themselves. Validation quality depends on the completeness and correctness of the OCL rule files applied, which varies by implementation.

Integration effort. Integrating OCL-based validation into existing engineering workflows requires tooling support. Not all SCL editors or system configurators support OCL rule import and execution.

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 not 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 encounter OCL-based validation in engineering tools as adoption grows. Understanding what it checks — and why — helps engineers interpret validation results and write correct 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 are possible. This is an ongoing process, not a one-time publication.

Conclusion

OCL-based validation addresses a long-standing gap in IEC 61850 engineering: the absence of formal, machine-checkable rules beyond XML Schema. IEC TS 61850-6-3 provides the format definition. The WG10 TF OCL is developing the rule sets.

For engineers and system integrators, the practical impact will depend on tool adoption and the pace at which the rule sets are published and finalized. Files containing semantic errors — cross-references pointing nowhere, missing mandatory objects, inconsistent subscriptions — can in principle be detected by OCL-based tools today; in practice, the coverage and tooling are still maturing.

The first batch of rules is being finalized as of early 2026. As rule sets and tooling develop, OCL has the potential to become a standard part of SCL engineering and commissioning workflows.

Sources and References

  • IEC TS 61850-6-3:2025, Format of machine-processable rules for validation of IEC 61850 XML-based files, IEC Webstore, published 8 July 2025
  • RiseClipse project: riseclipse.github.io
  • RiseClipse OCL constraints for SCL: github.com/riseclipse/riseclipse-ocl-constraints-scl2003
  • D. Marcadet et al., RiseClipse: why Working at the Model Level is Better for Validating IEC 61850 SCL Files, PSCC 2016
  • CIGRE B5 Study Committee, 2024: Introduction to IEC 61850-6-3 OCL: Machine-processable rules for validation of IEC 61850 XML-based files — CIGRE 2024, Study Committee B5 (full paper number and author list not confirmed in publicly available sources)
  • Triangle MicroWorks SCL Navigator with RiseClipse OCL Engine: trianglemicroworks.com
  • CoMPAS SCL Validator (LFEnergy): github.com/com-pas/compas-scl-validator

Last updated: March 2026