6.2.11 Information flow and status handling

6.2.11.1 Published data items

The configuration model defines different parameters that influence the information flow from Publisher to Subscriber in the case of a Bad Value Status or other error situations. Figure 25 depicts the parameters and the information flow inside a Publisher and inside a Subscriber.

The parameters and behaviour relevant for the encoding of a DataSetMessage on the Publisher side and the decoding of the DataSetMessage on the Subscriber side are defined in 6.2.4.2 together with the DataSetFieldContentMask.

The mapping of source value and status to the DataSet in the Publisher depends on the substitute value. The dependencies are defined in Table 79.

The mapping of the decoded DataSet on the Subscriber side to the value and status of the target Variable depends on the override value. The dependencies are defined in Table 80.

If one of the target Variables in the SubscribedDataSet does not allow writing of the StatusCode and the OverrideValueHandling is set to Disabled, the DataSetReader shall indicate the configuration error by setting the DataSetReader state to Error. In all other configurations of OverrideValueHandling when the target Variable does not allow writing of the StatusCode, only the Value is transferred to the target Variable.

If a target Variable in the SubscribedDataSet does not allow writing of timestamp, any received timestamp shall not be used and only the received value shall be written to the target Variable.

6.2.11.2 Actions

6.2.11.2.1 ActionState

The ActionState is used to indicate the current state of an Action execution. It is an enumeration of the possible states. The enumeration values are described in Table 81.

The ActionState representation in the AddressSpace is defined in Table 82.

6.2.11.2.2 Action execution sequence

The Action execution sequence and the related ActionMetaData for an Action execution through a reliable transport protocol like MQTT is described in Figure 26.

The RequestId is unique within the context of a RequestorId and CorrelationData. Each Action request in a single NetworkMessage has a different RequestId. Multiple NetworkMessages with the same RequestorId and CorrelationData may be sent.

Multiple Responses may be sent in the same NetworkMessage if the corresponding requests have the same RequestorId and CorrelationData. The grouping of requests in NetworkMessages does not affect the grouping of Responses into NetworkMessages.

The Action execution sequence for an Action execution through a non-reliable transport protocol like UDP is described in Figure 27. The related ActionMetaData is described in Figure 26. It shows the use of the ActionState for a non-reliable transport protocol. The request and response messages are send in the PublishingInterval of the Responder as long as the ActionState requires the exchange of messages for a Action execution.

The state changes for Action execution are defined in Table 83 for the Requestor and in Table 84 for the Responder.

Errors during the execution of an Action are reported in the Status of the Action response message.

For some errors such as decoding errors for the request message, addressing errors or failing security checks, the Responder does not produce a response message. Therefore the Requestor should have an internal timeout setting to stop waiting for a response message.

6.2.11.2.3 Action specific use of parameters

The Action specific use of PubSub configuration parameters is defined in Table 85.

Note that the reliability of the protocol depends on the QoS levels supported by the protocol. Any Broker-based middleware that is using a QoS of AtLeastOnce or greater is reliable (see 6.4.2.5.4). Broker-less middle is not reliable if it does not support any DatagramQoS (see 6.4.1.2.6).