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 software tools can import and interpret. The intended use cases include validating SCL files at various stages of specification and engineering.

And this is no longer just a promising technology. OCL checks are starting to be used in practice, including in Russia.

Why XSD is no longer enough

Formal validation of SCL has traditionally been based on XML Schema Definition — XSD.

XSD can check the structure of an XML document:

  • whether a particular element is allowed;
  • whether it may appear in a given place;
  • which attributes are defined for it;
  • whether an attribute is mandatory;
  • whether a value matches a particular data type.

This check is necessary. But its capabilities are limited by the very nature of XML Schema. XSD answers the question "Is the XML document built correctly?" well.

However, many IEC 61850 requirements concern not the structure of individual XML elements but 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 constrain the value of another. Whether a particular configuration is permissible may depend on several SCL elements at once.

And each of these elements, taken on its own, may fully conform to the XML Schema.

What OCL brings

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

Such a rule can then be applied automatically to an SCL file, and any violations are recorded by the 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 the IED declares maxReports > 0, i.e. states that it can use one or more Report Control Blocks, support for at least one report type must also be declared:

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

Or both types may be supported.

Otherwise there is a logical contradiction: the device claims to be able to work with reports while declaring support for none of their types.

From the XML point of view, each attribute on its own may be perfectly correct: the element exists, the value has a valid type and the document structure conforms to the XSD. The problem lies not in the XML but in the relationship between values.

These are exactly the relationships that OCL makes it possible to formalize and check automatically.

XSD checks, above all, that the document structure is correct.

OCL makes it possible to check the rules that the model described in the document must satisfy.

From the text of the standard to a machine-readable rule

Today a large share of IEC 61850 requirements exists only as text. A software developer, device manufacturer, design engineer or expert has to read the relevant clause of the standard, interpret it and implement the necessary check on their own.

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.

IEC TS 61850-6-3 defines the format and method for describing such rules, while the rules themselves can be used as machine-readable components of the relevant parts of IEC 61850.

As a result, SCL validation becomes more reproducible and less dependent on how a particular specialist interprets the requirements.

OCL is one of the focal points of the UCAIug IOP

The direction of travel is particularly visible in the international IEC 61850 interoperability tests.

OCL validation has already been used in previous UCAIug IOP cycles to check SCL, alongside other areas of configuration-tool testing. SCL errors and non-conformities have traditionally remained one of the most noticeable classes of problems found at such events.

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

The on-site 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 be a venue for practical verification of interoperability between IEC 61850 devices, gateways and software tools from different vendors.

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

This is an important signal for the industry: OCL is gradually moving from being a new mechanism in the standard to being a practical toolkit for checking the quality of IEC 61850 engineering data.

OCL has already been used in interoperability testing in Russia

Practical experience with this approach has already been gained in Russia as well.

In 2026, as part of the interoperability testing of IEC 61850 software tools, Tekvel provided methodological and technical support for the automated analysis of SCL files.

Natalya Mararakina, Technical Marketing Manager at Tekvel, presented the methodology and the test results at a meeting of Section No. 3 "Technologies and equipment for automating control systems in electrical networks" of the Scientific and Technical Council of PJSC Rosseti.

The automated review of the files was performed with Tekvel Park Server, software for reviewing digital projects in the SSD and SCD file formats.

The checks covered several levels:

  • conformance of the SCL files to the XML Schema;
  • checking the information model against the NSD;
  • checking the requirements of the corporate profile;
  • OCL checks of IEC 61850 requirements and corporate regulatory documents.

To make the analysis more complete, Tekvel specialists additionally implemented around a hundred automated checks.

Nine device manufacturers took part in the tests, providing a total of 18 ICD files.

The results were telling.

Violations of the SCL structure itself, which are detected by a traditional XML Schema check, occurred only in isolated cases. Most of the issues identified belonged to a deeper level of analysis — the information model, the requirements of the corporate profile and the constraints checked with OCL.

An SCL file can be completely valid from the XSD point of view and still contain violations of IEC 61850 requirements or of the requirements of a specific project.

From checking XML to checking engineering rules

SCL has long since ceased to be just an XML file for exchanging configuration between programs.

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

It is therefore only natural that the tools for checking it are evolving as well.

XSD — is the XML document built correctly?

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 where the key value of OCL lies.

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

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