The result transfer information model provides mechanisms to transfer results that are produced by a Server or its underlying system. The characteristics of such results is to contain meta data together with the individual results. Servers will provide the results for a certain amount of time so that Clients can receive the results using the result transfer.
The base modelling construct for the result transfer is the ResultManagementType (see Figure 1). Servers may provide several instances of that ObjectType to expose different sources of results. Each instance of ResultManagementType already can provide many results.
Figure 1 – Overview Result Transfer Information Model
Instances of ResultManagementType provide optionally all available results as Variables of ResultType under the Results folder. They may generate Events of ResultReadyEventType for new created results. And they provide optional Methods to retrieve individual results or filter for specific results.
The model provides different mechanism how Clients can retrieve information about the currently available results provided by instances of the ResultManagementType. Not all implementations will provide all those possibilities.
The mechanisms are depicted in Figure 2. In order to get notified that a new result has been created, a Client can subscribe to Events of ResultReadyEventType if the Server supports those Events. In order to retrieve information about the available results, the Client can
- Browse the Results folder, each Variable of ResultType represents an individual available result
- Call the GetLatestResult Method to retrieve information about the latest created result
- Call the GetResultIdListFiltered Method to retrieve information about all available results according to the specified filter criteria
Figure 2 – Retrieve Information that Results exist
The model provides different mechanism how Clients can transfer results provided by instances of the ResultManagementType. Not all implementations will provide all those possibilities.
The result consists of meta data describing the result, a relatively small amount of result data called ResultContent and optionally a larger amount of result data called ResultFile, transferred via the OPC UA file transfer. In some cases, the result only consists of parts of the meta data, the ResultEvaluation, which indicates whether the result is in a tolerance.
If a result has been successfully created, the Server shall at least provide the ResultContent, the ResultFile or the ResultEvaluation.
The ResultReadyEvents provide the meta data of the result as well as the ResultContent. Clients can either only subscribe to parts of the meta data and access the ResultContent via a different mechanism or get the ResultContent as well with the Event.
The ResultContent as well as the meta data can be transferred by calling the GetResultById Method. This requires knowledge on the ResultId, that can either be retrieved via the ResultReadyEvents or by calling the GetResultIdListFiltered Method. The latest ResultContent and its meta data can also be transferred by calling the GetLatestResult Method.
The ResultContent as well as the meta data is also provided by Variables under the Results folder and can be transferred by reading or subscribing to those Variables.
In Figure 3, the different options are displayed.
In case the result also contains a ResultFile, the ResultTransfer Object may be used to transfer the ResultFile. In order to use the ResultTransfer Object, the ResultId of the result is needed.
Figure 3 – Transfer ResultContent and Metadata
The lifetime of a result typically is limited as the management of the results is consuming resources of the Server. When using the Methods GetResultById, GetLatestResult or GetResultIdListFiltered, the Client can provide a timer how long it requests the retrieved results to be available, and receives a handle it can use to call the ReleaseResultHandle Method in order to hint to the Server, that the result is not required by the Client anymore. The mechanism is intended to secure the read process of results and not to lock a specific result for a longer time. There is no guarantee that the Server will keep the result until the RelaseResultHandle is called or the timeout is reached. The strategy of the Server is vendor-specific. A Server may, for example, stop producing new results when the old results should still be kept, or remove old results anyhow. A Server may remove results as soon as one Client has received the result data, or keep the results for a specific time since many Clients may need to access the result data.
Note: Since there is no guaranteed storage time even a Server without the capability to store more than one result locally can use this mechanism.
The handle and timeout are of specific importance when the result contains a ResultFile, or when the GetResultIdListFiltered was called and not all returned ResultIds have been received via the GetResultById Method.
Generating results may take time, and during that period Servers may already expose partial results, i.e., results that do contain some information but are not complete. For example, a vision system may inspect a produced part several times from different angles, and each inspection is a partial result. The meta data of the result indicate, when the result is only a partial result.
The ResultContent or the ResultEvaluation and potentially in addition the ResultFile together provide the complete result. Servers may also provide a reduced result summarizing the overall result. For example, a vision system inspecting a produced part may provide in the result the raw image data of the product part in addition to the flag indicating if the quality of the produced part is sufficient. The ReducedResultContent may only contain the quality information without the raw image data. The optional ReducedResultContent is provided with the ResultReadyEvents and the Variables of the Results folder.