Sterfive OPC UA Modeler vs UaModeler

If you build OPC UA information models, sooner or later you compare tools. The two names that come up most are Unified Automation's UaModeler and our own OPC UA Modeler — with Siemens SiOME, the OPC Foundation's UA-ModelCompiler, and the FreeOpcUa Python modeler rounding out the field. Since people searching for one increasingly land on the others, let's do the comparison properly: the head-to-head first, then the whole field.

Full disclosure before anything else: we make one of these tools. Sterfive builds the OPC UA Modeler, so read this knowing where we stand. We'll be as fair as we know how to be — UaModeler is a serious, mature product from a company we respect, and for some teams it is genuinely the better choice. We'll tell you which teams, and why.

Two tools, two philosophies

Both tools exist to solve the same problem: designing an OPC UA information model — your types, objects, variables, references — and producing a standards-compliant NodeSet2.xml that any OPC UA server can load. Where they part ways is how you author the model.

UaModeler is GUI-driven. You build the type system visually — trees, dialogs, property panels. It imports and exports NodeSet2 XML, supports companion specifications via NodeSet import, and — its distinctive strength — generates code for Unified Automation's C++, .NET and ANSI C SDKs: typed node classes, encoders and decoders, ready to compile into your server. The tool is licensed commercially; a licence comes bundled when you buy one of their SDKs, or can be bought separately (evaluation mode limits NodeSet2 export).

Sterfive's OPC UA Modeler is model-as-code. Your information model is a YAML DSL inside Visual Studio Code, with live IntelliSense, hover documentation, modelling-rule validation as you type, and NodeSet2.xml generation on demand. Companion specifications (DI, Machinery, PADIM, …) are first-class citizens you reference by alias. The model is text.

namespaces:
  - uri: http://acme.com/UA/Press/
    alias: a

types:
  - browseName: a:HydraulicPressType
    subtypeOf: di:DeviceType
    components:
      - browseName: a:Temperature
        nodeClass: Variable
        dataType: Double
        modelling: Mandatory

The difference that actually matters: your model in git

Here's the argument we'd make even if we didn't sell the tool — because we lived it for years as consultants before building it.

An information model is engineering source code. It evolves, it has versions, several people touch it, and mistakes in it ship to production. The moment that's true, you want the things software teams already solved: meaningful git diffs (a YAML change reads like a change; a regenerated XML blob does not), pull-request review ("why did Temperature become Optional?" is a one-line comment on a one-line diff), merge without a three-way GUI-project headache, and CI — validate the model and regenerate the NodeSet on every commit, fail the build if someone breaks a modelling rule.

GUI tools store their output in XML you can commit, but committing generated XML is not the same as versioning a model: the diffs are noise, review happens by opening the tool, and two engineers editing in parallel is asking for pain. This isn't a flaw in UaModeler specifically — it's the nature of GUI-first modelling, the same trade every industry has faced from schematics to infrastructure-as-code. We think information modelling lands where infrastructure did: as code.

Head to head

The wider field: SiOME, ModelCompiler, and the Python modeler

UaModeler isn't the only alternative, and a fair comparison names the whole field.

Siemens SiOME (SiOME — Siemens OPC UA Modeling Editor) is a free GUI tool, and if you live in the Siemens world it's genuinely compelling: beyond editing information models and mapping companion specifications, it adds TIA Portal mapping information into the NodeSet and can generate the corresponding data blocks for an S7-1500's OPC UA server. That last part is its UaModeler-style killer feature — nothing else automates the Siemens PLC round-trip like it. The flip side: it's GUI-first (same git/review/CI trade-offs as UaModeler) and its centre of gravity is the Siemens ecosystem, not vendor-neutral modelling.

OPC Foundation UA-ModelCompiler is the tool the Foundation itself uses to build the official specification NodeSets — free, open-source, command-line, generating NodeSet2 plus C# and ANSI C source from a ModelDesign XML input. It's technically "model-as-code" like ours, and being CLI it fits CI pipelines. Its problem is ergonomics: ModelDesign XML is an arcane, sparsely documented schema with no IDE assistance — you author your model in raw XML with the spec open in another window. Immensely capable in expert hands; a steep, lonely climb for everyone else.

FreeOpcUa opcua-modeler (the "Python modeler") is a community, open-source Qt GUI on top of the python-opcua stack that edits models and exports XML. It's free and simple, which makes it a fine first ladder rung — but it's a volunteer project whose development activity has slowed considerably, and it lacks the validation depth, companion-spec support, and polish of the commercial tools. Fine for experiments; we'd hesitate to bet a product roadmap on it.

The field at a glance

Notice the pattern: the GUI tools each win through an ecosystem integration (UA SDKs, TIA Portal), and the code-first tools win through workflow (CI, review, versioning). We built ours to be code-first without ModelCompiler's authoring pain — YAML with IntelliSense instead of raw ModelDesign XML.

When UaModeler is the right choice

Being honest, as promised. Choose UaModeler if you're building on Unified Automation's SDKs — the code generation into their C++/.NET/ANSI C stacks is its killer feature and nothing we make replaces that workflow. Choose it too if your modelling team strongly prefers visual editing and models change rarely enough that diff/review/CI aren't pain points, or if it's already bundled with the SDK licence you bought and does what you need. It's a mature tool that has shipped a lot of real-world models.

When ours is

Choose the OPC UA Modeler if your models live in git and evolve continuously, if you want model changes reviewed like code and validated in CI, if you're building on node-opcua or any stack that consumes NodeSet2.xml directly, if your team works across Windows, macOS and Linux, or if companion-spec-heavy modelling (DI, Machinery, PADIM…) is your daily bread and you want those specs handled as dependencies, not manual imports.

The bottom line

It's not "which tool is better" — it's GUI-first vs code-first modelling, and your team's workflow decides. If your world is Unified Automation SDKs and visual editing, UaModeler earns its place. If your world is git, code review, CI, and open stacks, model-as-code is simply how the rest of your engineering already works — and that's the world we built for.

Try it and judge: the OPC UA Modeler installs from the VS Code Marketplace in a minute. And if you're weighing a migration path or a mixed-tool workflow (UaModeler models are NodeSet2 — we can import what you've built), talk to us — we're the team that maintains node-opcua, and information modelling is what we do all day.