DurationGood
DurationGood is the Part 13 aggregate that returns how much time within each interval a variable held a Good StatusCode, expressed as a Duration in milliseconds. Paired with the interval length it is the cheapest honest data-availability metric a server can give you, computed server-side rather than reconstructed downstream.
What it measures
Not how many values were Good, but for how long the variable was in a Good state. The server walks the stored quality transitions across the interval and sums the Good spans. DurationBad is the mirror aggregate for Bad quality, and the two plus any Uncertain time account for the interval. Because the result is a Duration, you can compare it directly with the processing interval to get a fraction.
Why it is the metric to trust
Counting Good samples tells you about your sampling configuration; measuring Good duration tells you about the process and the connection. A sensor that goes BadNoCommunication for twenty minutes of an hour stores almost nothing during that window, so a count-based metric barely notices while DurationGood reports 40 minutes out of 60. That is the number that determines whether a shift's KPIs are defensible.
Using it for data-quality gating
The practical pattern is one processed read per shift per variable requesting DurationGood alongside the aggregate you actually want, then refusing to publish a KPI whose window was less than an agreed fraction Good. It gives your reporting a defensible provenance rule instead of an unexamined assumption that the data was there. PercentGood expresses the same thing as a percentage if you would rather not divide.
Availability of the data is not availability of the machine
DurationGood is a data-quality measurement, not an OEE availability figure. A machine idle for an hour with a perfectly healthy sensor reports full DurationGood and zero production. Availability comes from a state machine such as MachineryItemState combined with an operation mode, not from data quality. Conflating the two produces OEE numbers that look plausible and are wrong.
Example
DurationGood over one hour with a communication outage
Interval: 08:00:00 - 09:00:00Z, ProcessingInterval = 3600000 ms
Quality timeline for ns=4;s=Line1/Tank3/Temperature
08:00 - 08:25 Good 25 min
08:25 - 08:45 BadNoCommunication 20 min
08:45 - 08:50 UncertainLastUsableValue 5 min
08:50 - 09:00 Good 10 min
DurationGood = (25 + 10) * 60000 = 2100000 ms (35 min)
DurationBad = 20 * 60000 = 1200000 ms (20 min)
PercentGood = 2100000 / 3600000 = 58.33 %
Gate the shift report: publish only if PercentGood >= 95Defined in: Part 13 - Aggregate Functions.
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.