umati Sample Server

What you actually use it for

• Developing and testing a companion-specification client without waiting for a real machine.
• Learning what a properly modelled machine looks like, so you can tell the difference when a vendor hands you a flat tag list.
• Building an OEE mapping against MachineTool types such as the production state machines and production statistics before commissioning.
• Demonstrating type-driven traversal: browse the ObjectType, then find its instances, which is how the umati dashboard client itself works.
• Regression-testing a client in CI, by running the container as a service container with a known address space.

Walkthrough

1. Start with the public instanceConnect a client to opc.tcp://opcua.umati.app:4840 anonymously. If that works, your client and network are fine and you can concentrate on the model rather than on connectivity.
2. Run the container when you need a stable, private targetdocker run -d -p 4840:4840 ghcr.io/umati/sample-server:main gives you a local server on port 4840. Use this for CI and for anything where a shared public server's availability or content would be a problem.
3. Read the NamespaceArray and record the companion URIsRead the Server object's NamespaceArray and note the machinery and companion namespace URIs. Address every node by URI plus identifier from here on, and your client will survive both a container restart and a move to a real machine.
4. Browse the Machines folderThe Machines folder is the standard place a machinery server enumerates its machines. Browse it and check HasTypeDefinition on each entry to see which companion type it claims.
5. Traverse by type, not by pathBrowse the ObjectType, then locate instances of it, rather than hardcoding a browse path. That is what makes the same client work against the next vendor's machine, and it is the pattern the umati dashboard client uses, skipping instances that lack mandatory nodes.
6. Do not test writes hereThe server is read-only and ignores writes silently rather than returning a Bad status. A client that appears to write successfully against this server has proven nothing about writing against a real machine.
7. Subscribe and check timestampsCreate a subscription on a simulated state machine and its counters, and note which timestamps the server populates. Then compare against the real machine later; PLC-embedded servers often behave very differently.

What it will not do

• Read-only: writes are silently ignored, so it cannot test any write, command or method-side behaviour that depends on state change.
• It simulates the models it implements, not the messiness of real machines: no partial implementations, no missing optional nodes, no vendor quirks.
• Coverage is the companion specifications the project chose; if yours is not among them, this server will not help.
• The public instance is a shared service with no availability commitment; do not build a demo or a test suite that depends on it being up.
• Its Part 9 and Part 11 depth is limited compared with a production server, so alarms and history work needs a different target.

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.