umati
| Document | n/a |
|---|---|
| Version | n/a |
| Published | n/a |
| Sector | Adoption vehicle |
umati is not a specification. It is the adoption vehicle for the machinery companion specs, a joint VDW and VDMA initiative that curates a subset of them and runs a public dashboard. Its Sample-Server and dashboard-opcua-client repositories are the best free teaching lab in the OPC UA ecosystem.
Where it sits in the stack
umati sits on top of the released companion specifications rather than beside them: it picks a coherent subset, notably MachineTool, Woodworking, PlasticsRubber, Robotics, GMS and AdditiveManufacturing, and demonstrates them end to end. The Sample-Server is built on open62541 and simulates machine instances; the dashboard client subscribes to ObjectType-typed instances and republishes them as MQTT JSON, which is the exact southbound-to-northbound pattern most OEE and unified-namespace architectures use. Because it is an initiative and not a document, it has no namespace, version or publication date of its own.
The types that matter
| Type | What it carries |
|---|---|
MachineToolType | The MachineTool root type, and the main thing you will find typed on the public umati server. Matching HasTypeDefinition against it is the standard discovery exercise. |
Machines | The Machinery folder the sample server populates. Browsing it is how you learn the discovery pattern that works on real machines too. |
MachineIdentificationType | Machinery identification on the simulated machines, so you can practise reading and storing a nameplate before you meet a real one. |
MachineryItemState_StateMachineType | The Machinery availability state machine as exposed by the simulation, the right place to practise subscribing to CurrentState and to transition events. |
MachineryOperationModeStateMachineType | Operation mode where the simulation exposes it, which is the node most often missing on real machines and therefore worth understanding early. |
ProductionType | The MachineTool production branch, with active program, active job and statistics, on a server you can hammer without asking anyone's permission. |
ProductionStatisticsType | MachineTool counters on the simulation. Good for building and testing counter handling, including reset logic, before a real machine is available. |
ProductionJobStateMachineType | Job state on the simulated machine tools, useful for developing job attribution logic. |
ToolLifeType | Tool life on the simulated machines, the easiest way to see how a wear-limited item is modelled with its limit rather than just a count. |
Using it on a real machine
- Connect to the public serverPoint UaExpert or opcua-commander at opc.tcp://opcua.umati.app:4840. Anonymous with security None is available, so you can be browsing in under a minute with no registration.
- Read NamespaceArray firstThe namespace list shows you the whole curated stack on one server: core, DI, Machinery, MachineTool and the sector models. Record indices at runtime; they are server-specific.
- Discover by type, not by pathBrowse the Machines folder and read HasTypeDefinition on each child. This is exactly what the umati dashboard client does, and it is the discovery pattern that makes an integration portable.
- Run it locally when you want to break thingsdocker run -d -p 4840:4840 ghcr.io/umati/sample-server:main gives you your own instance on localhost:4840. Use it to test reconnect handling, subscription limits and certificate trust without worrying about a shared server.
- Read the dashboard client as a reference implementationThe dashboard-opcua-client repository shows how a production client maps typed instances to MQTT JSON topics. It is the closest thing to a worked example of an OPC UA to unified-namespace bridge that you can read and run.
- Do not test writes hereThe public server is read-only and writes are silently ignored, so a write that appears to succeed proves nothing. Test write paths against a local server or another demo server.
What it gives you for OEE
umati is where you build and prove an OEE pipeline for free before a real machine is available. The public server gives you typed machine instances with identification, state and production statistics, so you can develop discovery by ObjectType, state-duration accumulation from transition events, counter handling with resets, and job attribution end to end. The dashboard client demonstrates the northbound half: OPC UA client southbound, MQTT JSON into a broker or unified namespace, then a time-series store. Two honesty points. The data is simulated, so state durations, counts and stoppage patterns are synthetic and must not be used to calibrate an algorithm or to validate a plant benchmark. And umati coverage of a model does not mean every machine badged with the umati name exposes it: confirm per machine which companion spec and which version you actually get.
Gotchas
- umati is an initiative, not a specification. There is no umati namespace to load and no umati version to pin, so a requirement written as umati compliance has to be restated as a named companion spec and version.
- The public server is a simulation on open62541. It is excellent for client development and useless as a source of realistic production statistics.
- Writes are silently ignored. A client that reports a successful write against the public server has told you nothing about whether your write path works.
- It is a shared public server. Do not load-test it, keep subscription counts sane, and move to the container when you want to explore server limits.
Once the machine speaks a companion spec, the OEE mapping is portable across vendors, which is the point at which analytics stops being a per-machine project.
See Jemba →Last verified 7 September 2026 against OPC UA 1.05.07. Version and publication date read from the released nodeset. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.