Skip to main content

From Proprietary Silos to Open Collaboration — The Future of OPC UA Modeling

· 6 min read
Etienne Rossignon
Etienne Rossignon
CEO sterfive

The OPC UA YAML DSL specification isn't just a nicer syntax for writing information models. It's the foundation for a fundamental shift in how the OPC UA community builds, reviews, shares, and evolves models. When your information model is a human-readable text file with a formal specification behind it, every modern software engineering practice suddenly becomes available. Let's explore what that future looks like.

Git Workflows for Information Models​

Today, most OPC UA models live in proprietary project files or sprawling XML blobs. Try branching, merging, or reviewing changes — it's painful at best, impossible at worst.

With YAML-based models, the full power of Git becomes available:

  • Branching. An engineer works on a new RobotArmType in a feature branch while the main model stays stable.
  • Meaningful diffs. Adding an optional property produces a clean, two-line diff — not a cascade of renumbered NodeIds.
  • Pull requests. A colleague reviews the model change, comments on a browse-name choice, suggests a different modelling rule — all in the same workflow they use for application code.
  • Merge conflict resolution. Because YAML is line-oriented and each construct maps to a small, self-contained block, merge conflicts are rare and easy to resolve when they do occur.
 objectTypes:
   - browseName: ConveyorType
     subtypeOf: machinery:MachineryItemType
     components:
       - browseName: Speed
         dataType: ua:Double
+      - browseName: LoadWeight
+        dataType: ua:Float
+        modellingRule: Optional

That diff tells the whole story. No guesswork, no noise.

CI/CD Pipelines That Validate Models​

Once your models are text files in Git, you can plug them into CI/CD pipelines just like any other source code:

  1. Schema validation — the companion JSON Schema catches syntax errors before a human ever looks at the file.
  2. Conformant Processor build — compile the YAML to NodeSet2 XML and verify the output is well-formed.
  3. Cross-reference checks — ensure every browse path resolves, every namespace is declared, every modelling rule is consistent.
  4. Regression testing — diff the generated NodeSet2 XML against a known-good baseline to catch unintended changes.
  5. Automated publishing — deploy validated NodeSet2 files to an artifact registry or companion-spec repository.

Imagine catching a missing subtypeOf or a duplicate browse name in CI, minutes after the commit — instead of discovering it during a factory integration test three months later.

IDE Support: Autocomplete, Diagnostics, LSP​

A formal specification with a companion JSON Schema enables first-class IDE integration:

  • Autocomplete. Type subtypeOf: and your editor suggests every ObjectType visible in the current namespace context — standard types, companion-spec types, and your own.
  • Inline diagnostics. Reference a browse name that doesn't exist? The editor underlines it in red before you save the file.
  • Hover documentation. Mouse over di:DeviceType and see its description, its base type hierarchy, and its mandatory components — pulled straight from the specification.
  • Go to definition. Click through from a typeDefinition reference to the type's declaration, even across imported namespaces.

This isn't hypothetical. The OPC UA Modeler IDE extension already implements a full Language Server Protocol (LSP) backend for YAML DSL files. But because the specification is open, any editor — VS Code, JetBrains, Vim, Emacs — can build equivalent support.

AI-Assisted Modeling​

Here's a reality that deserves more attention: Large Language Models are remarkably good at reading and writing YAML, and remarkably bad at reading and writing XML.

When your information model is expressed in the YAML DSL, AI assistants can:

  • Generate boilerplate. Describe a sensor type in natural language and get a valid YAML model back — complete with components, properties, data types, and engineering units.
  • Review models. Ask an LLM to check whether your type hierarchy follows OPC UA best practices, whether optional members are correctly declared, or whether your interface application is lean.
  • Refactor. Rename a type, extract an interface, split a model into multiple files — tasks that are tedious by hand but natural for an AI working with structured, readable text.
  • Translate. Convert between companion-spec patterns, adapt a model from one industry vertical to another, or generate documentation from model definitions.

The compact, declarative nature of the YAML DSL means models fit easily within an LLM's context window. A 500-node information model that would be 3,000 lines of XML might be 400 lines of YAML — well within the range where AI assistance is most effective.

[!TIP] Because the YAML DSL has a formal JSON Schema, AI-generated models can be validated instantly — catching hallucinated property names or invalid type references before they reach a human reviewer.

Multi-Vendor Interoperability​

The specification defines conformance classes — not a single implementation. This means:

  • Tool A can author models in the YAML DSL.
  • Tool B can consume the same YAML files and produce identical NodeSet2 output.
  • Tool C can validate models without generating XML at all.
  • An open-source CLI can compile YAML to NodeSet2 in a CI pipeline.

Models become truly portable. An integrator can author a model, hand it to a machine builder using a different toolchain, and know that both sides are working from the same source of truth. The NodeSet2 XML output is the interchange format; the YAML DSL is the authoring format. Both are open. Neither is proprietary.

Community-Driven Evolution​

The specification is published as a Working Draft — deliberately. We want feedback from the people who live and breathe OPC UA every day:

  • Companion-spec authors — does the DSL express your domain's patterns naturally? Are there constructs you need that are missing?
  • SDK developers — is the processing model clear enough to implement? Are the conformance requirements testable?
  • System integrators — does the namespace import system work for your multi-vendor projects? Are the browse-path conventions intuitive?
  • End users — is the YAML readable? Can you onboard a new engineer in a day instead of a week?

The format will evolve based on real-world usage and community input. That's how good standards are born — not in isolation, but through iteration with practitioners.

A Call to Action​

The OPC UA YAML DSL specification is available now at /specification/. Read it. Try it. Break it. Tell us what works and what doesn't.

If you're building OPC UA information models today — whether for a companion specification, a machine builder's product line, or a factory integration project — this specification is written for you. It's open, it's formal, and it's designed to make your work faster, more reliable, and more collaborative.

The future of OPC UA modeling isn't locked inside a proprietary tool. It's a YAML file in a Git repository, validated by CI, reviewed by your team, and ready to compile into standard NodeSet2 XML at the push of a button.

Let's build that future together.