Aller au contenu principal

Why OPC UA Desperately Needs a Standard Modeling Language

· 5 minutes de lecture
Etienne Rossignon
Etienne Rossignon
CEO sterfive

OPC UA information models are the backbone of modern industrial interoperability. They describe how machines, sensors, and production lines expose their data to the world. Yet in 2026, the way we author these models is stuck in the early 2000s — hand-editing verbose XML, locked inside proprietary GUI tools, with no path to version control, code review, or CI/CD. The OPC UA community deserves better.

The NodeSet2 XML Reality​

Every OPC UA information model ultimately ships as a NodeSet2 XML file — the interchange format defined by OPC 10000-6. It's faithful to the OPC UA address-space model, and every server, SDK, and tool can consume it. That's the good news.

The bad news? Nobody writes it by hand. Here's what a single ObjectType with one variable looks like in NodeSet2 XML:

<UAObjectType NodeId="ns=1;i=1001" BrowseName="1:TemperatureSensorType">
  <DisplayName>TemperatureSensorType</DisplayName>
  <References>
    <Reference ReferenceType="HasSubtype" IsForward="false">
      i=58
    </Reference>
    <Reference ReferenceType="HasComponent">ns=1;i=6001</Reference>
  </References>
</UAObjectType>
<UAVariable NodeId="ns=1;i=6001" BrowseName="1:Temperature"
            DataType="Double" ParentNodeId="ns=1;i=1001">
  <DisplayName>Temperature</DisplayName>
  <References>
    <Reference ReferenceType="HasTypeDefinition">i=63</Reference>
    <Reference ReferenceType="HasModellingRule">i=78</Reference>
    <Reference ReferenceType="HasComponent" IsForward="false">
      ns=1;i=1001
    </Reference>
  </References>
</UAVariable>

Twenty lines of XML for one type with one variable. Now imagine a companion specification with 50 ObjectTypes, dozens of DataTypes, enumerations, state machines, methods, and hundreds of instances. The files grow to thousands of lines of tightly coupled, numeric-NodeId-riddled XML that is essentially unreadable to a human reviewer.

[!NOTE] NodeSet2 XML was designed as a machine interchange format, not as an authoring format. It's the equivalent of writing assembly language when you should be writing Python.

Proprietary Tools: The Vendor Lock-In Problem​

Because hand-editing XML is impractical, the industry turned to GUI-based modeling tools. These tools offer drag-and-drop interfaces, visual type hierarchies, and export-to-NodeSet2 buttons. Sounds great — until you try to:

  • Switch tools. Your model lives in a proprietary project format. Moving to a different vendor's tool means starting over, or writing fragile migration scripts.
  • Collaborate across organizations. If your partner uses Tool A and you use Tool B, exchanging models means round-tripping through NodeSet2 XML and losing all the high-level intent along the way.
  • Onboard new engineers. Each tool has its own learning curve, its own quirks, its own license cost. Knowledge doesn't transfer.

The result? Models become trapped. The intellectual property you invested months creating is siloed inside a single vendor's ecosystem.

The Missing Developer Workflow​

In every other branch of software engineering, we've embraced practices that make collaboration reliable and scalable:

  • Version control — git diff shows exactly what changed, who changed it, and why.
  • Code review — pull requests let peers catch mistakes before they ship.
  • CI/CD pipelines — automated validation, testing, and deployment on every commit.
  • IDE support — autocomplete, inline diagnostics, hover documentation.

None of this works well with binary project files or 5,000-line XML blobs. Try running git diff on a NodeSet2 XML file where someone changed a single Description field — you'll get a screenful of noise from re-ordered references and renumbered namespace indices.

OPC UA information models are too important to be exempt from modern engineering practices. They define the contract between machines and software. A typo in a browse name or a missing modelling rule can cause interoperability failures that take days to diagnose in the field.

What the Industry Needs​

The path forward is clear. OPC UA needs a vendor-neutral, human-readable modeling language that:

  1. Is text-based — so models live in Git, get reviewed in pull requests, and flow through CI/CD pipelines.
  2. Is compact — so engineers can read and reason about models without drowning in boilerplate.
  3. Has a formal specification — so any vendor, any open-source project, any research lab can build a conformant implementation.
  4. Covers the full OPC UA type system — ObjectTypes, VariableTypes, DataTypes (structures, enumerations, unions, option sets), ReferenceTypes, InterfaceTypes, EventTypes, state machines, methods, instances, and initializers.
  5. Shields authors from NodeId management — auto-assigning numeric identifiers and persisting them in a stable symbol table.

This isn't a wish list. It's an engineering requirement for an ecosystem that aspires to be the universal language of industrial interoperability.

A Specification Is Coming​

We've been working on exactly this: a formal, open specification for a YAML-based DSL that compiles to conformant NodeSet2 XML. It covers the full OPC UA address-space vocabulary, defines clear conformance classes, and is designed from day one to be implementable by anyone.

Stay tuned — the next post in this series will introduce the specification in detail, walk through the design principles, and show a compelling before-and-after comparison of the same model in XML versus YAML.

The era of proprietary silos and unreadable XML is ending. The era of collaborative, human-readable OPC UA modeling is about to begin.