The components of this parameter are defined in Table 135.

Table 135– DataValue

Name

Type

Description

DataValue

structure

The value and associated information.

value

BaseDataType

The data value. If the StatusCodeindicates an error then the value is to be ignored and the Servershall set it to null.

statusCode

StatusCode

The StatusCodethat defines with the Server’s ability to access/provide the value. The StatusCodetype is defined in 7.39

sourceTimestamp

UtcTime

The source timestamp for the value.

sourcePicoSeconds

UInteger

Specifies the number of 10 picoseconds (1,0 e-11 seconds) intervals which shall be added to the sourceTimestamp.

serverTimestamp

UtcTime

The Servertimestamp for the value.

serverPicoSeconds

UInteger

Specifies the number of 10 picoseconds (1,0 e-11 seconds) intervals which shall be added to the serverTimestamp.

Some applications require high resolution timestamps. The PicoSecondsfields allow applications to specify timestamps with a resolution of 10 picoseconds. The actual size of the PicoSecondsfield depends on the resolution of the UtcTime DataType. For example, if the UtcTime DataTypehas a resolution of 100 nanoseconds then the PicoSecondsfield would need to store values up to 10 000 in order to provide the resolution of 10 picoseconds. The resolution of the UtcTime DataTypedepends on the Mappingsdefined in OPC 10000-6.

The sourceTimestampis used to reflect the timestamp that was applied to a Variablevalue by the data source. Once a value has been assigned a source timestamp, the source timestamp for that value instance never changes. In this context, “value instance” refers to the value received, independent of its actual value.

The sourceTimestampshall be UTC time and should indicate the time of the last change of the valueor statusCode.

The sourceTimestampshould be generated as close as possible to the source of the value but the timestamp needs to be set always by the same physical clock. In the case of redundant sources, the clocks of the sources should be synchronized.

If the OPC UA Serverreceives the Variablevalue from another OPC UA Server, then the OPC UA Servershall always pass the source timestamp without changes. If the source that applies the timestamp is not available, the source timestamp is set to null. For example, if a value could not be read because of some error during processing like invalid arguments passed in the request then the sourceTimestamp shall be null.

In the case of a bad or uncertain status sourceTimestampis used to reflect the time that the source recognized the non-good status or the time the Serverlast tried to recover from the bad or uncertain status.

The sourceTimestampis only returned with a Value Attribute. For all other Attributesthe returned sourceTimestampis set to null.

The serverTimestampis used to reflect the time that the Serverreceived a Variablevalue or knew it to be accurate.

In the case of a bad or uncertain status, serverTimestampis used to reflect the time that the Serverreceived the status or that the Serverlast tried to recover from the bad or uncertain status.

In the case where the OPC UA Serversubscribes to a value from another OPC UA Server, each Serverapplies its own serverTimestamp. This is in contrast to the sourceTimestampin which only the originator of the data is allowed to apply the sourceTimestamp.

If the Serversubscribes to the value from another Serverevery ten seconds and the value changes, then the serverTimestampis updated each time a new value is received. If the value does not change, then new values will not be received on the Subscription. However, in the absence of errors, the receiving Serverapplies a new serverTimestampevery ten seconds because not receiving a value means that the value has not changed. Thus, the serverTimestampreflects the time at which the Serverknew the value to be accurate.

This concept also applies to OPC UA Serversthat receive values from exception-based data sources. For example, suppose that a Serveris receiving values from an exception-based device, and that

  1. the device is checking values every 0,5 seconds,
  2. the connection to the device is good,
  3. the device sent an update 3 minutes ago with a value of 1,234.

In this case, the Servervalue would be 1,234 and the serverTimestampwould be updated every 0,5 seconds after the receipt of the value.

The StatusCodeis used to indicate the conditions under which a Variablevalue was generated, and thereby can be used as an indicator of the usability of the value. The StatusCodeis defined in 7.39.

Overall condition (severity)

  • A StatusCodewith severity Good means that the value is of good quality.
  • A StatusCodewith severity Uncertain means that the quality of the value is uncertain for reasons indicated by the SubCode.
  • A StatusCodewith severity Bad means that the value is not usable for reasons indicated by the SubCode.

Rules

  • The StatusCodeindicates the usability of the value. Therefore, It is required that Clientsminimally check the StatusCode Severityof all results, even if they do not check the other fields, before accessing and using the value.
  • A Server, which does not support status information, shall return a severity code of Good. It is also acceptable for a Serverto simply return a severity and a non-specific (0) SubCode.
  • If the Serverhas no known value - in particular when Severityis BAD, it shall return a NULL value.