A new and important mechanism for validating SCL files is emerging in the IEC 61850 engineering process — OCL (Object Constraint Language), a language for formally describing constraints and rules for the objects of the information model.

In 2025, the technical specification IEC TS 61850-6-3 «Format of machine-processable rules for validation of IEC 61850 XML-based files» was published. It defines the format and method for describing formal OCL rules that can be imported and interpreted by software tools. Among the intended scenarios is the validation of SCL files at various stages of specification and design.

Moreover, this is no longer merely a promising technology. OCL checks are beginning to be applied in practice.

Why XSD is no longer enough

The traditional basis for the formal validation of SCL is the XML Schema Definition — XSD.

With it, you can check the structure of an XML document:

  • whether a given element is allowed;
  • whether it may appear in this location;
  • which attributes are defined for it;
  • whether an attribute is mandatory;
  • whether a value conforms to a given data type.

Such validation is necessary. But its capabilities are limited by the very nature of XML Schema. XSD answers the question well: «Is the XML document well-formed?»

However, many IEC 61850 requirements relate not to the structure of individual XML elements, but to the relationships between different objects and parameters of the model.

The presence of one object may require the presence of another. The value of one attribute may impose constraints on the value of another. The admissibility of a particular configuration may depend on several SCL elements at once.

At the same time, each of these elements individually may fully conform to the XML Schema.

XSD checks the structure of a single element, OCL — the relationships between objects
Fig. 1. XSD is responsible for the structure of individual elements, OCL — for the rules and relationships between the objects of the model. Each element may be correct in isolation, while a violation arises in the relationship between their values.

What OCL provides

OCL makes it possible to formally describe rules roughly of the following form: if condition A holds, then object B must exist or have certain properties.

After that, such a rule can be applied automatically to an SCL file, and any violations found — recorded by a software tool.

A simple example concerns the declaration of an IED's service capabilities.

In the Services section, a device describes the capabilities it supports, including those related to reports. If an IED declares a value of maxReports > 0 — that is, reports the ability to use one or more Report Control Blocks — it must, at the same time, declare support for at least one type of report:

  • bufReport = true — buffered reports are supported;
  • unbufReport = true — unbuffered reports are supported.

Or both types may be supported.

Otherwise, a logical contradiction arises: the device declares the ability to work with reports, yet at the same time declares support for none of their types.

At the same time, from the XML point of view, each attribute in itself may be perfectly correct: the element exists, the value has an allowed type, the document structure conforms to XSD. The problem lies not in the XML, but in the relationship between the values.

An example OCL rule for the declaration of reports in the Services section
Fig. 2. An example OCL rule: if an IED declares maxReports > 0, it must declare at least one type of report. From the XSD point of view both variants are correct — the contradiction is visible only at the level of the relationship between values.

It is precisely such relationships that OCL makes it possible to formalise and check automatically.

XSD checks primarily the correctness of the document structure. OCL makes it possible to check the rules that the model described in the document must satisfy.

From standard text to a machine-readable rule

Today, a significant part of IEC 61850 requirements exists in textual form. A software developer, a device manufacturer, a designer or an expert has to read the relevant clause of the standard, interpret it and implement the necessary check themselves.

OCL makes it possible to express some of these requirements in a formal, machine-readable form. A rule such as «if condition X holds, element Y must have property Z» can exist as a formal rule that a software tool is able to execute automatically.

At the same time, IEC TS 61850-6-3 defines precisely the format and method for describing such rules, while the rules themselves may be used as machine-readable components of the corresponding parts of IEC 61850.

Thanks to this, SCL validation becomes more reproducible and less dependent on the manual interpretation of requirements by a particular specialist.

OCL — one of the focuses of the UCAIug IOP

The direction of development is especially clear from the international IEC 61850 interoperability tests.

OCL validation has already been used in previous UCAIug IOP cycles when checking SCL, alongside other areas of testing configuration tools. SCL errors and inconsistencies have traditionally remained one of the notable classes of problems identified at such events.

The next major milestone will be the UCAIug IEC 61850 IOP 2026.

The in-person part of the international tests will take place in Utrecht, the Netherlands. The main test programme is scheduled for 12–16 October 2026. The event will serve as a venue for the practical verification of interoperability between IEC 61850 devices, gateways and software tools from different manufacturers.

Given the development of IEC 61850-6-3 and the experience already accumulated from previous IOPs, OCL and automated SCL validation are becoming one of the notable areas of the international interoperability tests.

This is an important signal for the industry: OCL is gradually moving from the category of a new standard mechanism into a practical toolset for checking the quality of IEC 61850 engineering data.

From checking XML to checking engineering rules

SCL long ago ceased to be merely an XML file for exchanging configuration between programs.

In the modern IEC 61850 engineering process, SCL effectively becomes the digital description of a substation automation system.

That is why the tooling for checking it develops accordingly:

  • XSD — is the XML document well-formed?
  • NSD — does the information model used conform to the requirements of IEC 61850?
  • OCL — are the more complex rules and relationships between the objects of this model satisfied?

This is precisely where the key value of OCL lies.

It makes it possible to move from checking the formal correctness of XML to the automated checking of engineering requirements that previously had to be interpreted and controlled manually.

That is why OCL should be regarded not merely as yet another language in the IEC 61850 ecosystem, but as a step toward a deeper and more formalised validation of SCL. From a machine-readable description of the digital substation — to a machine-readable checking of engineering rules.