UaModeler

What you actually use it for

• Authoring an OPC UA information model graphically instead of hand-editing NodeSet2 XML.
• Importing companion specification nodesets such as DI and Machinery and deriving your own types from them, so your model layers correctly rather than reinventing base types.
• Producing a NodeSet2 file that other tools and stacks can load, including servers that support runtime nodeset import.
• Generating server skeleton code for Unified Automation SDKs from the model, which keeps the address space and the implementation aligned.
• Reviewing an imported nodeset visually when the XML is too large to read.

Walkthrough

1. Create a project and set your namespace URIChoose the namespace URI for your model deliberately and permanently, for example http://example.com/UA/MyMachine/. It is the stable identity of your model; the namespace index a server assigns to it is not.
2. Import the nodesets you depend onImport Opc.Ua.Di.NodeSet2.xml, then Opc.Ua.Machinery.NodeSet2.xml, in dependency order. Model dependencies are directional, so importing in the wrong order or omitting a layer is the usual cause of unresolved references later.
3. Derive your ObjectTypes from the right baseSubtype the companion type rather than BaseObjectType wherever a companion specification already defines the concept. Deriving from MachineIdentificationType or the machinery state machines is what makes a client written against the companion spec work on your machine without special-casing.
4. Set modelling rules on every componentMark each instance declaration Mandatory or Optional. This decides what an instance is required to contain, and it is the field that determines whether a strict client that skips invalid instances will see your machine at all.
5. Define DataTypes with structure definitionsWhere you need a structure, define it so the exported nodeset carries a DataTypeDefinition. That is what lets a modern client decode your ExtensionObjects without a legacy type dictionary.
6. Export NodeSet2 and validate it elsewhereExport the model and then load it in an independent tool, for example a nodeset viewer or a server that imports nodesets at runtime. A model that only opens in the tool that authored it is not yet a deliverable.
7. Generate code only if you are on the matching SDKCode generation targets Unified Automation stacks. If your server is open62541, node-opcua or UA-.NETStandard, take the NodeSet2 file and use that stack's own nodeset compiler or loader instead.

What it will not do

• Commercial and Windows only, which puts it outside the free toolchain some projects require.
• Code generation is oriented to Unified Automation SDKs; other stacks consume the exported nodeset, not the generated code.
• It does not test your model against a live server. Conformance and client compatibility still need a server and a client.
• Very large or heavily interdependent nodesets are slow to work with graphically.
• It cannot tell you whether the companion specification you chose is the right one for your industry; that judgement is yours.

Alternatives

Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.