Custom nodesets

Companion specifications published by the OPC Foundation ship with the tooling — declare them in namespaces: and they are there. Anything else is your own file: a vendor's nodeset, a supplier's model, a companion spec you are still writing. Those you upload.

Upload

Open the Dependencies panel from the toolbar and choose Upload NodeSet2.xml.

The file is validated, hashed, and stored under your own account. Nothing is shared with anyone else — see Isolation.

Reference it

namespaces: names specs we ship. imports: names everything else:

namespaces:
  - di

imports:
  - uri: http://acme.example/UA/Base/
    alias: acme
    filename: acme-base.NodeSet2.xml

objectTypes:
  - browseName: PumpControllerType
    subtypeOf: acme:PumpType

Once the alias is bound, a vendor type behaves exactly like a standard one: acme:PumpType is no different from di:DeviceType to the rest of the model, and completions offer its members.

The uri is the identity — it is the ModelUri inside the file. filename is a hint used to locate it.

Limits

Limit	Value
Largest single file	25 MB
Dependencies per model	20
Total uploaded per account	200 MB

These are deliberately not tier-based; they apply to everyone.

Isolation

Uploading a file to a shared service reasonably invites the question.

• Your dependency is stored under your partition, addressed by the SHA-256 of its content.
• The cache is keyed by content hash, never by namespace URI. Two customers can both declare http://acme.example/UA/Base/ with entirely different files and neither can shadow the other. That is the normal case, not a conflict.
• The only nodesets shared between accounts are published OPC Foundation companion specs, which are read-only and identical for everyone. A companion spec you are still writing is an ordinary private upload.
• Your own dependencies take precedence over the shared catalogue. If you override a published spec you get a diagnostic saying so — useful when the Foundation later publishes a version newer than your working copy.

Taking it elsewhere

The YAML is portable; the files it imports are not automatically. The Dependencies panel offers Download bundle, which gives you the model plus a deps/ folder holding the nodesets it imports — ready to compile on a machine that has never seen them.

The desktop CLI does the same with opcua-modeler bundle -i model.yaml.