Data Age

Data age is how old a data value is when it is used. The value may be a sensor sample, packet field, state estimate, historian point, alarm input, biomedical waveform sample or digital-twin feature. If the value represents the physical system at time t_sample and is used at time t_use, its age is:

Data age matters because engineering decisions are time dependent. A pressure, speed, temperature, packet counter, position, vibration level or patient measurement can be accurate at acquisition and still be wrong for the current decision if it arrives too late.

Freshness Requirement

A freshness requirement states the maximum age allowed for a specific use:

The age margin is:

A positive margin means the value is fresh enough for that decision. It does not prove the value is accurate, calibrated or correctly timestamped. A negative margin means the system is acting on stale data, even if checksums, units and numeric ranges look valid.

Age Budget

Data age is usually a sum of path terms:

where the terms represent sensing or exposure time, filtering delay, queueing, communication, processing and output hold or display delay. The useful budget depends on the boundary. A control loop may stop the budget at actuator command output. A monitoring display may include historian ingestion, database query and screen refresh.

This budget should be treated as a worst-case or percentile requirement, not only an average. A low average age can still fail if occasional queue bursts, retries, garbage collection, gateway buffering or clock recovery events create stale values during the conditions that matter.

Worked Example

A mobile inspection controller uses a position measurement with:

The communication, compute and hold terms are:

The total data age is:

If the freshness requirement is:

then:

The freshness check passes. Now connect age to physics. If the platform speed is:

the first-order position mismatch from using the old value is:

If the allowed mismatch is only:

the maximum age from the physics limit is:

The original 100 ms requirement is too loose for this operating condition. The engineering conclusion is not just “reduce latency”; it is to define a freshness threshold tied to motion, uncertainty and release risk.

Boundary With Latency

Latency is elapsed time through a system. Data age is elapsed time between the represented event and the use of the value. They often overlap, but they are not identical.

A packet can have low network latency while carrying an old measurement from a buffered sensor. A historian query can return quickly while displaying a value captured minutes earlier. A digital filter can make a signal smooth and calibrated while increasing age enough to damage a control or alarm decision.

For this reason, data-age evidence should state the acquisition event, the timestamp source, the update path, the use boundary and the stale-data rule.

Boundary With Timestamp Uncertainty

Timestamp uncertainty is uncertainty in the assigned time label. Data age is the time difference between the event and use. A value can have low timestamp uncertainty and high data age if it was captured accurately but delivered late. It can also have low age and high timestamp uncertainty if the system delivers quickly but records the wrong event boundary.

The two quantities belong in the same timing review. Timestamp uncertainty affects confidence in t_sample; data age affects whether a value should still be used.

Stale-Data Decisions

Systems should define what happens when data exceed the freshness threshold. Options include rejecting the value, holding the last valid output, degrading the controller, switching to prediction, widening uncertainty, lowering automation authority, raising an alarm or entering a safe state.

The right action depends on the hazard. A stale display may be acceptable if labelled clearly. A stale protection input, infusion-pump measurement, flight-control signal, robotic position update, grid telemetry point or state-estimation measurement can create a dangerous false sense of validity.

Validation Evidence

Useful evidence includes acquisition timestamps, receive timestamps, sequence counters, monotonic clocks, queue-depth logs, filter group-delay estimates, packet captures, gateway timing, scheduler traces, retry counters, dropout tests, load tests, stale-data fault injection and replay tests at representative speed or process dynamics.

Common mistakes include checking only network latency, logging receive time as sample time, trusting a valid checksum as proof of freshness, using average age for a tail-risk decision, ignoring filter delay, hiding stale values behind interpolation and accepting a control or monitoring system without a defined stale-data action. A strong review states the age budget, the maximum allowed age, the physics or risk basis for that limit and the evidence that the stale-data rule works under degraded conditions.