OPC UA Modeler vs the OPC Foundation's UA NodeSet Editor

In September 2026 the OPC Foundation announced the UA NodeSet Editor: a free, web-based tool for creating and editing OPC UA information models, hosted by the Foundation itself at uanodeseteditor.opcfoundation.org. If you searched for "NodeSet2 editor" this month, you probably found it — and if you found us as well, you are now wondering how the two relate.

Full disclosure first, as in our UaModeler comparison: we make one of these tools. Sterfive builds the OPC UA Modeler. We are also a Corporate Member of the OPC Foundation, and we think a free, official editor is good news for everyone who models — more people authoring NodeSets properly means more interoperable machines, and that is the whole point of OPC UA. So this is not a takedown. It is a map: what the Foundation's editor is, what ours is, and which one fits the work you actually do.

Everything we say about the UA NodeSet Editor comes from its announcement, its welcome page and its public repository, as they stood in September 2026. It is a public beta and will move fast; where we could not confirm something, we say so rather than guess.

What the UA NodeSet Editor is

A web application you sign in to — any email address will do, and no OPC Foundation membership is required. You work in Workspaces. A Workspace is a collection of Models and corresponds to one OPC UA server's address space, so it should contain every Model needed to resolve its references. Models come in two kinds: shared Models, which are read-only and can be reused across Workspaces, and private Models, which belong to one Workspace and are the ones you edit.

You bring Models in from the UA Cloud Library or by uploading a NodeSet file, create new types and instances through the web interface, export the result as a NodeSet, and share Models with other users. The Foundation lists a wide range of intended uses: configuring a server's address space, defining Companion Specification models, static digital-twin snapshots, Unified Namespace hierarchies, and CESMII Smart Manufacturing Profiles. That last one is no accident — the code is derived from CESMII's ProfileDesigner.

Three things stand out:

• It is the Foundation's own tool, wired to the Foundation's own library. Browsing the UA Cloud Library and extending what you find there is the designed starting point, and the editor's stated principle is that every NodeSet should derive from another one.
• It checks a Companion Specification document against its NodeSet. Authors can upload the Word document of their specification — written to the Foundation's Companion Specification template — and have it compared with the Model. Anyone who has kept a 200-page specification and a NodeSet in sync by hand knows what that is worth. We know of no other tool that does this, and ours does not.
• It is open source and self-hostable. A .NET back end, a PostgreSQL database, Docker files to run your own instance, and a REST API described in OpenAPI.

It is also, in the Foundation's own words, a starting point. The site is a public beta, users are asked to back up their models with the download feature, the interface is deliberately general-purpose for now, and task-specific interfaces are planned — one for the Digital Product Passport is already in development.

What the OPC UA Modeler is

Ours starts from a different premise: an information model is source code, so it should be text.

You write the model in a small YAML language built for OPC UA. The compiler resolves it against the companion specifications you name, checks it, and produces a standard NodeSet2.xml — plus the Symbols CSV and Markdown documentation — that any OPC UA server can load.

namespaceUri: http://acme.com/UA/Pump/
version: 1.0.0
namespaces:
  - di
objectTypes:
  - browseName: PumpType
    subtypeOf: di:DeviceType
    components:
      - browseName: di:ParameterSet
        components:
          - browseName: FlowRate
            dataType: ua:Double
          - browseName: SetPoint
            dataType: ua:Double
            accessLevel: CurrentRead | CurrentWrite

That is a complete model: a pump type derived from the Device Integration specification, with two process values in its ParameterSet, where DI expects them. Put them directly on the type instead and the compiler tells you so, with the line number. The same language and the same compiler run in four places:

• In the browser — an editor with completion, live diagnostics, diagrams, and a button that starts a real OPC UA server exposing your model so you can browse it with a real client.
• In Visual Studio Code — the extension, for models that live next to the rest of your code.
• On the command line — for CI: build and validate the model on every commit, and reverse an existing NodeSet2.xml back into YAML.
• As an MCP server — so an AI agent can look up companion-specification types, write a model and have it validated rather than hallucinate one.

The difference that matters: where the model lives

In the UA NodeSet Editor your model lives in a database behind a web interface, and the NodeSet file is what you export from it. In the OPC UA Modeler your model lives in a text file, and the NodeSet file is what you build from it.

Neither is wrong. They suit different lives.

A model in a text file gets everything your software already has. A change is a readable git diff. "Why did SetPoint become writable?" is a one-line review comment on a one-line change. Two engineers can work in parallel and merge. A pipeline can refuse a commit that breaks a modelling rule. A release is a tag. None of that needs a feature from us; it comes free with being text.

A model in a hosted workspace gets everything a shared web application has. Nothing to install, nothing to learn beyond OPC UA itself, Models can be shared with other users, and the Cloud Library is one click away. For someone who models a few times a year, a guided interface beats learning any language, ours included.

Head to head

When the UA NodeSet Editor is the right choice

Choose it if you are writing a Companion Specification in a working group. The Word-document check alone justifies it, and you will be working the way the Foundation expects.

Choose it if your starting point is the UA Cloud Library, if you build CESMII Smart Manufacturing Profiles, or if you want the Digital Product Passport interface when it arrives.

Choose it if you model occasionally and want forms rather than a language, if your budget is zero, or if you need to self-host an open-source tool and read its code.

When ours is

Choose the OPC UA Modeler if your model changes every sprint and several people change it; if you want those changes reviewed like code and validated in CI; if the model must ship with the software that serves it, from the same repository and the same tag.

Choose it if you want to see the model running on a real OPC UA server before you write any server code, if you want an AI agent to do the first draft against the real companion specifications, or if you maintain many models and need to build them all from a script.

You can use both

This is the part comparisons usually leave out. NodeSet2.xml is the interchange format, and both tools speak it. They compose:

• Author in YAML, build the NodeSet2.xml, upload it into a UA NodeSet Editor Workspace, and run the Companion Specification document check there. You keep git, review and CI for the model, and get the Foundation's check on the document.
• Going the other way, export a NodeSet from the editor — or download one from the Cloud Library — and turn it into readable YAML:

opcua-modeler reverse --input Acme.Pump.NodeSet2.xml --output pump.model.yaml

From there it is a text file like any other. A working group can draft in the Foundation's editor while the vendor implementing the specification keeps its own extension in git.

The bottom line

The UA NodeSet Editor lowers the floor: anyone with an email address can now produce a correct NodeSet, with the Foundation's library at hand, for free. We are glad it exists.

The OPC UA Modeler is for what comes after the first model — when it has versions, reviewers, a pipeline and a release date. That is an engineering problem more than a modelling one, and text in git is how engineering already solves it.

Try both; it costs an afternoon. The OPC UA Modeler runs in your browser with a free sign-in, and the documentation covers the language, the command line and the MCP server. If you are weighing how the two fit into a Companion Specification project, talk to us — we maintain node-opcua, and information modelling is what we do all day.