DataValue
In OPC UA, a DataValue is the container every read, write and subscription notification uses. It holds the Value as a Variant, a StatusCode giving the quality of that value, a SourceTimestamp from the data source, a ServerTimestamp from the server, and optional picosecond fields for both timestamps.
The five fields, and why all of them matter
Value carries the payload as a Variant, so its type is decided by the variable, not by the DataValue. StatusCode is the quality word: it can be Good, Uncertain or Bad, and a Bad StatusCode normally means the Value field is empty and must not be stored as a zero. SourceTimestamp is when the source produced the value, ServerTimestamp is when the server learned about it, and the two picoseconds fields extend each timestamp for high-resolution applications. A historian that stores only Value and one timestamp throws away most of what the protocol told it.
Where DataValues come from
Read returns an array of DataValues, one per RequestedValue in the ReadValueId list, with the requested timestamps controlled by TimestampsToReturn. Subscriptions deliver MonitoredItemNotifications that each carry a DataValue. Write takes DataValues too, but servers commonly reject client-supplied timestamps and only accept the Value field, which is why a write with a SourceTimestamp set can fail on some stacks.
Reading the StatusCode before the value
The correct handling order is StatusCode first, value second. On Good you use the value. On Uncertain, for example UncertainLastUsableValue or UncertainSubstituteValue, the value exists but is not trustworthy for control or for OEE arithmetic. On Bad, such as BadNoCommunication, treat it as a gap, not as a data point. Also check the info bits: the overflow flag lives inside the StatusCode, so a lossy subscription can report data loss while the code bits still look Good.
Encoding on the wire
In UA Binary the DataValue has an encoding mask byte saying which of the five fields are present, so omitted fields cost nothing. In JSON encoding the rule is the same in spirit: a Good StatusCode is the value 0 and is omitted entirely, so an absent StatusCode field means Good, not missing data. Downstream code that treats absence as null quality will mislabel every healthy value.
Example
A DataValue in OPC UA JSON encoding - note that no StatusCode field is present, which means Good
{
"Value": { "Type": 11, "Body": 42.5 },
"SourceTimestamp": "2026-09-07T08:14:22.1230000Z",
"ServerTimestamp": "2026-09-07T08:14:22.1870000Z"
}Defined in: Part 4 - Services, and Part 6 - Mappings for the encoding rules.
Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.