Choose a Status Node When OPC UA Events Are Unavailable
If the device's OPC UA Server does not support Events, expose process state through a status Node and have the application subscribe to that Node. When the device changes the value, the subscription delivers the new value to the application. A String Node can carry messages such as Processing started, although the evidence does not establish whether String is the best data type for every implementation.
This pattern reproduces the required state-change notification without adding a reverse connection. It does not add native Event support; treat it as state reporting and define the value semantics, update conditions, and recovery behavior in the application design.
Compare Unidirectional and Bidirectional Roles
| Architecture | Connection ownership | Failover effect | Primary tradeoff |
|---|---|---|---|
| Device Server; application Client | The application connects to the device. | The active application instance can connect to the device after application failover. | Requires a subscribed status Node when the device lacks Events. |
| Both endpoints are Client and Server | Each endpoint initiates a connection to the other. | The device must know which application endpoint is active and may require reconfiguration when the application moves. | May roughly double the connection relationships and adds endpoint-management complexity. |
OPC UA permits both systems to implement Client and Server roles, but capability alone does not make the topology preferable. The bidirectional design is justified only if its reverse service provides enough value to offset additional connections, configuration, and failover coordination.
Implement and Verify the Status-Node Pattern
- Create a status variable in the device's OPC UA Server address space.
- Write the required process state to that Node when the state changes, such as
Processing started. - Configure the application Client to subscribe to the Node and process each received value change.
- Exercise application failover and confirm that the new active application instance reconnects to the device and resumes receiving status changes.
Before acceptance, define how the application interprets the current value after reconnection. The evidence does not specify Node identifiers, subscription timing, failover discovery, security settings, or event-history requirements, so determine and test those items within the actual system.
FAQ
Can an OPC UA application and device both be Client and Server?
Yes. Both endpoints can implement both roles, but this creates reverse connection dependencies and may roughly double the connection relationships.
How do I emulate OPC UA Events when a device does not support them?
Create a status Node in the device's Server, update it when process state changes, and subscribe to it from the application Client. A String value such as Processing started is one supported approach from the evidence.
Why can bidirectional OPC UA roles complicate application failover?
When the device acts as a Client, it must know the active application Server endpoint. If the application moves to another system, the device may need endpoint reconfiguration, while a Client-only application can reconnect to the unchanged device Server.
