OPC UA Server

English · Deutsch · Français · Italiano · Русский · Українська

OPC UA Server

Server Studio lets you design an OPC UA server, run it locally, secure it, and simulate values — without writing code. The designed server runs as a separate process (the headless OpcUaServerRuntime, which embeds open62541), controlled by the GUI through ServerStudio and ServerRuntimeController (see Architecture).

Server projects

A server project (.uaserver) is a JSON file holding everything the runtime needs: the custom namespaces, the address-space nodes, any custom enumeration data types, the endpoint configuration, the security settings, and the behavior rules (ServerProject::ProjectData). Projects are created, opened, saved, and closed from Server Studio.

Designing the address space

In the studio you build a tree of nodes (ServerNodeModel):

• Objects to organize the address space;
• Variables with a data type and an initial value;
• custom enumeration data types, referenced by variables;
• custom namespaces that own your nodes.

An address space can also be brought in rather than drawn by hand:

• Import/export NodeSet2 — exchange the model as standard OPC UA NodeSet2 XML (ServerProject::NodeSet).
• Clone from a browsed server — capture the address space of a server you are connected to in the client into a new server project.

The project is checked by a validator before it is built or started (ServerProject::Validator).

Endpoint and security

The endpoint configuration sets the port and application name. The security configuration selects the security policy and the accepted identities:

• No security for quick local testing;
• Basic256Sha256 with signing and encryption, using a self-signed server certificate created in the server's own PKI store;
• anonymous access and/or username/password users.

These settings let you exercise a client against realistic security without an external server.

Running the server

Starting the server launches the runtime process; the studio waits for it to report its endpoint and then shows it as running. Live diagnostics — session count, secure channels, and uptime — stream back to the studio over a local side-channel (DiagnosticsServer). You can stop, restart, or forcibly kill the runtime; the controller reports crashes and lets you reconnect.

Simulating values

Variables can be given a simulation so their values change over time while the server runs — counter, toggle, random, sine, or ramp (SimulationEngine). The runtime writes the simulated values into the server, so connected clients see real data-change notifications, which is useful for testing trends and subscriptions.

Reacting to writes (behavior rules)

A variable can be given behavior rules: when a client writes the variable, the runtime performs one or more actions on other variables. An action either writes a fixed value or copies the value that was just written, optionally after a delay. This reproduces the request/response handshakes an HMI expects from a PLC — for example, writing PageRequest makes the server set PageResponse — which a static address-space snapshot cannot. Rules are stored in the project and evaluated by the runtime through OPC UA write callbacks (RuleEngine).