Overview

This is a Docker-Compose suite of OPC UA test servers built for one job: integration testing of OPC UA client libraries. Whatever language you're writing the client in — Rust, Python, PHP, Go, Java, C#, anything that speaks OPC UA — you point it at this suite and exercise every protocol corner without having to set up a PLC.

What runs

All 10 classic instances run the same code with different environment variables — same address space, ~300 nodes, identical behaviour. Only the security / authentication wrapping differs.

Why it exists

The original php-opcua/opcua-test-suite ran on Node.js + node-opcua. This suite reimplements it on the OPC Foundation UA-.NETStandard library — the reference implementation, maintained by the same organisation that publishes the OPC UA specification.

For an integration-test counterpart this matters: protocol behaviour, encoding, and security are as close to the spec as possible. A test passing against this suite is a strong signal your client will interop with real-world servers built on the same stack (Siemens, Beckhoff, KEPServer, …).

Address space — what's in it

Each of the 10 classic servers exposes the same ~200-node custom address space (plus the standard ns=0 framework nodes that every UA-.NETStandard server ships):

• 21 scalar data types × {RW, RO} variants
• 20 RW arrays + 14 empty arrays + 6 RO arrays
• 3 multi-dimensional matrices (2D and 3D)
• 12 callable methods (arithmetic, strings, arrays, async, failures)
• 13 dynamic variables (counters, waves, random)
• 3 periodic standard BaseEventState event timers (no custom event types)
• 3 alarms (exclusive limit, non-exclusive limit, off-normal)
• 4 historical variables (1-second recording, 10 000-sample buffer)
• Structured objects (nested up to 10 levels)
• 2 extension objects (binary-encoded ExtensionObject)
• 50 access-control variables across every type/access combination
• 4 OPC UA Views for filtered browsing

Detailed breakdowns in Address space · Overview and the Data features / Runtime features sections.

How tests typically use it

A typical CI-integration pattern:

1. Start the suite (docker compose up -d or the GitHub Action).
2. Run your client's integration suite against localhost:4840-4849.
3. Tear down.

For GitHub Actions this is one step:

# Pin to a tag (e.g. @v1.2.0) once you've verified one exists for
# your fork; @master tracks the bleeding edge. There is no
# guarantee a v1.2.0 tag exists in upstream — check
# https://github.com/php-opcua/uanetstandard-test-suite/tags
- uses: php-opcua/uanetstandard-test-suite@master

- run: cargo test  # or pytest, npm test, dotnet test, …

See CI integration · GitHub Action.

Tools that test against this suite

The same suite powers integration tests across several client libraries:

…and any other client that exercises a CI matrix can plug in the same way.

Forkable

The codebase is organised as a set of focused builders — one C# class per feature group (data types, methods, events, etc.). Adding your own variables, methods, or even whole new server flavours is a small change.

See Customization · Forking and adding nodes.

Where to read next

• Installation — get it running.
• Quick start — first commands.
• Server instances · Overview — pick the right server for your test.