Marco

Posted on Oct 15 Originally published at siliconlogix.it

OPC UA in action: the SLX GridPilot industrial digital twin

#opcua #rust #automation #digitaltwin

OPC UA becomes easier to understand when a command produces an observable response. A power request, a valve opening, a rotating machine and an alarm connect the protocol to process behavior. With SLX GridPilot, Silicon LogiX presents a desktop application for exploring that path: from the nodes of an OPC UA server to the control of two reversible hydroelectric units and their 3D representation.

The starting point is precise: OPC UA communication and the control runtime are real; the plant is simulated. The computer runs clients, three independent servers and the Eclipse 4diac FORTE runtime. Water, rotating machinery, electrical power and equipment faults belong to the numerical model. This software laboratory serves both people approaching industrial automation and engineers evaluating interfaces, information models and diagnostics without connecting physical equipment.

What is OPC UA, and why does it matter in industrial automation?

OPC Unified Architecture is a platform-independent interoperability architecture. In the client-server model, a server exposes information and services that a client can discover and use: variables, objects, methods and events. For industrial automation, its value includes communicating the meaning of data through types and relationships, beyond a list of numeric values.

A unit's speed, for example, can be presented together with its data type, engineering unit, quality and timestamp. A client can browse the model, read a measurement, call a method and receive notifications. GridPilot applies these operations to a visible scenario: two reversible units, U1 and U2, generating electricity or moving water toward the upper reservoir in pumping mode.

A digital twin demonstrator built around OPC UA

The initial OPC UA Studio workspace displays connected servers, monitored items and notifications received in the current sessions. A live operation map distinguishes the client, servers, FORTE control, simulated equipment and feedback path. These indicators help explain which part of the system is working and where the displayed data comes from.

OPC UA Studio in version 0.4.2. Counters describe actual client connections and notifications; the guided tour verifies server responses.
The three local endpoints represent plant services and the two units: opc.tcp://127.0.0.1:4840, opc.tcp://127.0.0.1:4841 and opc.tcp://127.0.0.1:4842. An external OPC UA client can explore the same model and call its methods. The 3D scene receives state through OPC UA, just like the interface indicators. Selecting U1 or U2 highlights the corresponding unit and lets the operator locate it in the plant view.

From command to feedback: what actually happens

Requesting power does not mean that power has already been delivered. Calling SetPower(1.2) on U1's endpoint requests 1.2 MW of generation. The method's initial response confirms that the request has been queued. LastCommand then reports acceptance or rejection, while power, state and actuator positions show the observed outcome. Hydraulic availability and interlocks can limit the result even when a command is accepted.

The coordinator presents the request to FORTE control logic, which manages sequences and operating limits. The numerical model evolves from the actuator targets; the resulting state is published by the servers and returns to the client through subscriptions. The interface therefore distinguishes request received, command accepted and behavior achieved. The same principle applies to Stop(): confirming a stop requires feedback such as zero speed and closed flow-control devices.

Functional architecture of the demonstrator. OPC UA connects the supervisor to the servers; the coordinator uses local connections to control and model components. Calculated state returns to the servers and client, which also updates the 3D scene.

Exploring OPC UA nodes, types and information models

The integrated browser performs actual Browse and Read operations. Users can search for a node, inspect its type, copy its NodeId and examine quality, timestamps and engineering units. Persistent watchlists follow selected variables, while filters help locate measurements whose quality differs from Good.

A NodeId identifies a node within a namespace. GridPilot's application namespace is urn:siliconlogix:gridpilot:v1. A client must resolve its index on the server instead of assuming that a fixed number always identifies the same namespace. This is a practical detail to understand when moving from an example to integration between different applications.

NodeSet2 XML export, alongside JSON and CSV, documents browsed instances, types and method arguments. It describes the information model: it is neither an executable server backup nor a complete recording of its events.

Subscriptions, quality and timestamps: reading data in context

An OPC UA subscription lets a client receive notifications for configured monitored items. The sampling interval concerns observation of the data; the publishing interval governs notification delivery. A numeric deadband defines a change threshold. The server can revise the requested intervals, and GridPilot exposes those values together with the status of individual monitored items.

Watchlists use a dedicated subscription. Coherent plant state arrives in the Snapshot variable, so indicators and the scene do not have to reconstruct a process snapshot by combining independent reads. SourceTimestamp refers to the sample's UTC publication time; SimTime represents simulated process time. Pausing the simulation therefore does not stop the communication clock.

Quality and freshness have visible consequences: uncertain measurements are identified, and state that no longer receives updates is marked stale. Machine animations do not advance beyond the latest confirmed pose. Motion thus helps users read the available telemetry.

OPC UA faults and alarms: acknowledgement is separate from recovery

The demonstrator supports repeatable actuator, sensor, communication and electrical faults. A simulated speed-sensor error also produces an observable quality change on the OPC UA node. Injecting communication loss for a unit actually shuts down its endpoint, allowing users to examine disconnection, reconnection and the controller's response.

The servers expose standard OPC UA OffNormalAlarmType conditions with severity, message, active state and acknowledgement. An operator can acknowledge a condition and add a comment. Acknowledgement does not remove the fault's cause or automatically release the controller latch: recovery must restore the required conditions. This release uses the experimental Alarms & Conditions support in open62541 1.4.14 and makes no claim of OPC UA conformance certification.

Learning through a guided path and observable checks

The OPC UA Studio tour moves from browsing U1 to requesting power, confirming a stop and injecting a sensor fault, followed by alarm acknowledgement and recovery. Each step advances when the expected feedback is observed. Missing or stale data cannot confirm an outcome.

The plant view complements the experience with overview, cutaway and unit-detail modes. Rotation, flow-control devices, flow indicators and electrical activity make it easier to connect a variable to the relevant machine. Graphics represent received state; the numerical model and control logic determine process evolution.

The Plant view places the 3D model beside operator requests and confirmed values. U1 and U2 labels connect each unit card to its location in the plant.

The technology stack: Rust, Slint, Bevy, open62541 and FORTE

The architecture gives each technology a distinct role. Rust is used for coordination, supervision and the numerical engine. Slint provides the desktop interface; Bevy, together with wgpu, handles the 3D scene and glTF models. Interface and visualization share confirmed process state.

open62541 is the C OPC UA stack used for the servers and client adapter. Eclipse 4diac FORTE is a runtime for function-block applications based on IEC 61499. In GridPilot it executes the application block governing startup, stop, reversal and fault handling. The coordinator maintains a fixed 100 ms step and connects control to the numerical model; supervisor-to-device communication goes through OPC UA.

The hydraulic model is lumped and quasi-steady, with constant efficiencies, actuator limits and water/energy accounting. It is suitable for studying the demonstrator and its interfaces. Designing an actual hydro plant requires further modeling and validation: water hammer, cavitation, electrical-grid transients and qualified electrical protections are examples of phenomena outside this model.

Trends, replay and tests for comparing behavior

The Workbench brings together sequence diagnostics, local numeric history, multivariable charts and CSV export. Commands and alarms can be read alongside measurement trends. Recording, replay, pause and temporal seeking support session review, while test plans define scheduled actions and expected results checked against observed feedback.

For industrial software developers, these functions offer a basis for discussing concrete requirements: how to represent unreliable data, when to declare a command complete, what information to export and what conditions to verify after an interruption. Project checks concern the software and demonstrator model; they do not replace commissioning tests on a real plant.

Download GridPilot and discuss a custom OPC UA project

The SLX GridPilot 0.4.2 release provides a portable Windows x64 package. Download the Windows ZIP, extract the complete folder and launch SLX GridPilot.exe. No compiler, package installation, cloud service or field hardware is required. A Vulkan-capable graphics driver is required. The release also includes SHA-256 checksums for checking the download.

Demonstrator endpoints are limited to the local computer, with anonymous access and SecurityPolicy None. OPC UA provides security mechanisms, but configuring certificates, identities, roles and protected communication for production requires dedicated engineering and verification. The package does not include a preconfigured connection to a physical PLC.

The public repository contains operator documentation, selected screenshots, licensing information and publication checks. The Windows ZIP includes the required runtime data, dependency licenses and corresponding third-party sources. GridPilot's application implementations are proprietary and distributed in compiled form; SDK headers and application sources are excluded from the public distribution. The product license permits study and business evaluation; production integration and redistribution of modifications require written permission. Dependency licenses remain independent.

For an industrial application, a next step may be designing an OPC UA information model, integrating devices and PLCs, developing dedicated supervision, or defining interoperability and recovery tests. These are extensions to agree within a specific project, starting with the actual equipment, security requirements and acceptance criteria. To discuss a project with Silicon LogiX, contact us with the process, the data to expose and the operations the software must support.

DEV Community