PercentGood

Definition and its mirror

The server computes the Good duration within each processing interval and divides by the interval length, returning a percentage. PercentBad is the mirror aggregate. Because the value is normalised, PercentGood is directly comparable across variables sampled at completely different rates and across intervals of different lengths, which DurationGood is not.

The one number to put on a data-quality dashboard

One processed read per variable per interval gives you a heat map of your whole data estate: which tags, which machines and which time windows are actually trustworthy. It costs one aggregate read rather than a raw history download plus downstream quality reconstruction, and because the server computes it from its own stored quality transitions it sees outages your client never observed.

Percent-of-interval, not percent-of-samples

The denominator is time, not sample count. A variable stored on change with three points in an hour can still be 100 percent Good, and a variable with thousands of points can be 40 percent Good if most of the hour was BadNoCommunication. Any client-side approximation that divides Good samples by total samples answers a different question and usually a flattering one.

Configuration affects the answer

PercentGood depends on AggregateConfiguration, in particular PercentDataGood and PercentDataBad and whether the server's own capability defaults or your supplied configuration is used, plus how the aggregate treats Uncertain time and partial intervals. Two servers can report different percentages for the same raw data under different configurations. Set UseServerCapabilitiesDefaults deliberately and record which configuration a report was produced under.

Example

PercentGood per hour across a shift as a data-quality gate

ReadProcessedDetails
  StartTime          = 2026-09-07T06:00:00Z
  EndTime            = 2026-09-07T14:00:00Z
  ProcessingInterval = 3600000        (one value per hour)
  AggregateType      = [ PercentGood ]

Result for ns=4;s=Line1/Tank3/Temperature
  06:00  100.0 %   ok
  07:00  100.0 %   ok
  08:00   58.3 %   communication outage 08:25-08:45  -> exclude
  09:00   99.8 %   ok
  10:00  100.0 %   ok
  11:00    0.0 %   sensor in BadSensorFailure        -> exclude
  12:00  100.0 %   ok
  13:00  100.0 %   ok

Shift TimeAverage computed over the 6 hours at >= 95 %, and the report
states that 2 hours were excluded and why.

Defined 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.