You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The backend should support mechanisms to handle trigger events by OPC UA events and methods.
handling OPC UA events can be done by mapping them to readable ChimeraTK process variables of type Void. However, it is expected that an implementation would also map the properties provided in OPC UA events to additional associated variables.
triggering OPC UA method calls can be done by mapping them to writable ChimeraTK Void variables. The simplest case corresponds to a method with signature void(void). However, it is expected that an implementation would also support more complex methods, with lists of typed input and output arguments.
Background info
(from discussion with Martin K. about Void type in ChimeraTK DeviceAccess and in OPC UA)
In ChimeraTK, we recently added Void user types. Those can be used for DeviceAccess/ApplicationCore process variables.
intended usage for Void:
you are interested in the time when an update for the variable is received, but not in the data
=> use the Usertype Void in DeviceAccess, for reading from device or backend
you want to send a trigger, but don't care about the content and type of the process variable you need to write to
=> write to variable of Usertype Void
This raised the question, how to handle these cases with the OPC UA backend, and whether we need a "Void" data type in OPC UA.
The OPC UA backend realizes an OPC UA Client. The device it connects to, is an OPC UA server.
The use cases described above, for Void, are about sending/receiving triggers.
The OPC UA way to handle triggers is by events and methods.
In order to provide a trigger event of the device, typically an OPC UA server would send an appropriate OPC UA event (of standard or customized event type)
In order to allow triggering of a device, typically an OPC UA server would provide an OPC UA method
A simple mapping of ChimeraTk variables of type Void to OPC UA variables with dataType=Null (an OPC UA Variant type can be empty, by setting data type to Null), is not recommended since it would not help cover meaningful use cases.
Rather, to cover meaningful use cases, we need the OPC UA features for events and methods in the backend.
The text was updated successfully, but these errors were encountered:
The backend should support mechanisms to handle trigger events by OPC UA events and methods.
Background info
(from discussion with Martin K. about Void type in ChimeraTK DeviceAccess and in OPC UA)
In ChimeraTK, we recently added Void user types. Those can be used for DeviceAccess/ApplicationCore process variables.
intended usage for Void:
=> use the Usertype Void in DeviceAccess, for reading from device or backend
=> write to variable of Usertype Void
This raised the question, how to handle these cases with the OPC UA backend, and whether we need a "Void" data type in OPC UA.
The OPC UA backend realizes an OPC UA Client. The device it connects to, is an OPC UA server.
The use cases described above, for Void, are about sending/receiving triggers.
The OPC UA way to handle triggers is by events and methods.
A simple mapping of ChimeraTk variables of type Void to OPC UA variables with dataType=Null (an OPC UA Variant type can be empty, by setting data type to Null), is not recommended since it would not help cover meaningful use cases.
Rather, to cover meaningful use cases, we need the OPC UA features for events and methods in the backend.
The text was updated successfully, but these errors were encountered: