Quickstart — online

Five minutes, nothing to install, and no account needed to start.

1. Open the editor

The editor opens straight away. Signing in is only needed for the three things listed at the end of this page.

2. Write a model

Replace the contents with this:

A temperature sensor
objectTypes:
  - browseName: TemperatureSensorType
    subtypeOf: di:ComponentType
    description: A temperature sensor, modelled as a DI component.
    components:
      # DI puts process values in the ParameterSet, which the base type declares
      # as optional — redeclaring it here makes it mandatory on every instance.
      - browseName: di:ParameterSet
        components:
          - browseName: Temperature
            typeDefinition: ua:AnalogUnitType
            dataType: ua:Double
            engineeringUnits: "°C"
            description: The measured temperature.

instances:
  - browseName: Sensor1
    typeDefinition: TemperatureSensorType
    organizedBy: /ua:Objects
    initializers:
      # di:ComponentType inherits these as mandatory from the DI nameplate
      # interface, so every instance carries them — give them real values.
      - variable: di:Manufacturer
        value: "Acme Instruments"
      - variable: di:Model
        value: "TS-100"

You need a header above it — the namespace this model defines, and its version:

namespaceUri: http://example.com/UA/Quickstart/
version: 1.0.0
publicationDate: "2026-01-01T00:00:00Z"

namespaces:
  - di

That is a complete model. TemperatureSensorType is a device component from the DI companion specification with one measured value, and Sensor1 is an instance of it hanging off the standard Objects folder.

The temperature sits inside di:ParameterSet rather than directly on the type: DI keeps process values there, and the modeller will warn you if you put them elsewhere. Following the companion spec from the start costs nothing here and saves rework later.

3. Watch it validate as you type

Two things happen without you asking:

Diagnostics appear under anything wrong — a misspelled key, a type that does not exist, a missing required field — with the line and a code.
Completions offer real values. Put the cursor after subtypeOf: and you are offered types that actually exist, not a guess.

Try breaking it deliberately: change ua:Double to ua:Doubl and watch the error appear, then fix it.

4. Look at what you built

The right-hand panel switches between four views:

View	Shows
Diagram	Your types drawn as an OPC UA class diagram
Documentation	The generated Markdown spec for the model
Problems	Every diagnostic in one list
Dependencies	The companion specs and vendor nodesets in play

The diagram and documentation update as you type. Nothing is generated on a button press — they are the model.

5. What needs an account

Signing in (Google, GitHub, or email) adds three things:

Save to the cloud — models persist to your account, with autosave.
Run it in a real OPC UA server — one click starts an actual server exposing your model, so you can point a client such as UaExpert at it.
Generate from a description — write what you want in plain language and have a validated model produced for you.

Access is currently Early Bird, for adopters working with us directly — talk to us.

Getting the NodeSet2.xml out

The browser is where you author. To turn a model into NodeSet2.xml, Symbols.CSV and documentation, use the REST API with an API key, or the desktop CLI, which does it offline.

The YAML DSL reference — every key, with examples
Temperature sensor, in full — the long-form tutorial
Which flavor is for you? — if the CLI or an AI agent suits you better

1. Open the editor​

2. Write a model​

3. Watch it validate as you type​

4. Look at what you built​

5. What needs an account​

Getting the NodeSet2.xml out​

Next​