The Interface Is Up. Is the Data Still Safe to Use?

The status light is green.

The network reports no errors. The receiving application is updating normally. An operator sees a believable value and acts on it.

There is only one problem: the value is eight seconds old.

Nothing disconnected. No checksum failed. No alarm appeared. The system delivered valid data too late for the decision it was supporting.

A healthy connection does not prove that the information is current.

That distinction belongs in the interface definition, long before integration.

Most interface definitions describe the packet, not its usefulness

Engineering teams are usually diligent about syntax. An interface control document may define the connector, pinout, protocol, units, range, resolution, byte order and message structure.

Those details are necessary. They are not the whole contract.

NASA’s interface-management guidance treats interface requirements as functional, physical and performance requirements. It also says interface analysis should establish origin, destination, stimuli and special characteristics, and that interface requirements feed verification and validation [1].

Time is one of those performance characteristics.

For every data item that can influence a display, estimate, decision or control action, the interface definition should answer:

• How often is a new value expected?
• How long after measurement may it arrive?
• At what age does it become unusable?
• Which clock gives the timestamp meaning?
• Can samples arrive late or out of order?
• What must the receiver do when the data is stale?

Without those answers, two components can comply with the same message format and still disagree about what the data means.

Rate, latency and freshness are different promises

These quantities are easy to collapse into one vague requirement such as “data shall be provided in real time.”

They answer different questions:

• Update period: How often does the source produce or publish a value?
• Transport latency: How long does a sample take to reach the consumer?
• Age at use: How old is the underlying observation when the consumer acts on it?
• Jitter: How much does timing vary from one sample to the next?
• Freshness limit: Beyond what age must a sample be rejected or treated differently?

Consider an illustrative tracking system. A sensor publishes position at 20 Hz, so a new message is expected every 50 ms. That sounds fast.

But the sensor performs 120 ms of internal processing. A gateway occasionally buffers messages for 200 ms. The consumer then receives several samples together and processes them in arrival order.

The message rate is still 20 Hz. The network may be connected. Yet the control function may be acting on information hundreds of milliseconds behind the physical world.

A rate requirement alone cannot expose that problem.

“Reliable” can still be too late

Reliability and timeliness can pull in different directions.

The Object Management Group’s Data Distribution Service specification distinguishes several quality-of-service concepts. Its DEADLINE policy describes how often data is expected to be updated. LATENCY_BUDGET expresses the urgency of communication, although the specification explicitly treats it as a hint. LIFESPAN exists to prevent stale samples from being delivered after an expiration time [2].

The same specification notes that reliable delivery may retransmit missing samples before making later samples available, while best-effort delivery may omit samples but preserve their order from a given writer [2].

Neither choice is universally correct.

For a configuration file, complete delivery may matter more than speed. For a live pointing estimate, an old sample may be worse than a missing one. For an event log, preserving every entry may be essential even if it arrives late.

The interface contract needs to state which property matters for each data flow. “Use TCP” or “use reliable messaging” is an implementation choice, not a complete operational requirement.

A timestamp needs a clock story

A timestamp looks authoritative. It is only useful if its origin and interpretation are clear.

Ask:

1. Does the timestamp represent measurement, publication, transmission or reception time?
2. Is it generated by the sensor, a gateway or the receiving application?
3. What time base and epoch are used?
4. How closely must relevant clocks be synchronized?
5. What happens when synchronization is lost?
6. Can the clock jump after startup or resynchronization?

DDS calculates sample expiration from a source timestamp and notes that this depends on sender and receiver clocks being sufficiently synchronized; where detectable, reception time may be used instead [2].

That caveat matters. A requirement such as “reject data older than 500 ms” is incomplete if different devices can disagree about time by more than the allowance.

Do not hide the clock assumption in a software comment. Make it part of the interface and verification strategy.

Define the stale-data behavior

Detecting old data is not enough. The receiver needs an intentional response.

Depending on the application and hazard analysis, it might:

• Mark the value invalid and stop using it.
• Hold the last value for a limited, defined interval.
• Extrapolate with an explicit uncertainty bound.
• Degrade to another source or operating mode.
• Inhibit an automated action and alert the operator.
• Continue logging the sample while preventing operational use.

The safe response is application-specific. A stale room-temperature reading and a stale obstacle position do not deserve the same treatment.

Also define recovery. After fresh samples return, does the consumer resume immediately? Must it receive several consecutive valid samples? Does a state estimator need to converge again? Does an operator acknowledge the transition?

“Data valid” should describe an engineering condition, not merely the presence of bytes.

Test time as a system property

A component test with two devices on the same bench rarely represents the full timing path.

Verify the end-to-end chain under credible load:

1. Timestamp or otherwise observe the physical input event.
2. Measure when the consuming function actually uses the corresponding data.
3. Exercise nominal, peak-load and degraded-network conditions.
4. Introduce delayed, duplicated, missing and out-of-order samples.
5. Disturb or remove time synchronization where that dependency exists.
6. Confirm both stale-data detection and the required system response.

Keep rate, latency, age and jitter as separate measurements. An average can conceal the single late sample that matters.

NASA notes that interface documentation and parameters are inputs to verification planning, and calls interface-requirement verification a critical part of overall system verification [1]. The timing contract should therefore appear in the test evidence—not only in a network engineer’s diagnostic capture.

Where Ngenaire helps

Ngenaire’s published platform brings requirements, diagrams, verification, schedule and risk into one workspace. It supports requirements with custom attributes and baselines, SysML and UML diagrams, test plans and procedures, RVTM traceability, and project memory for decisions and constraints [3].

Those capabilities can keep a timing constraint connected to the data flow it governs, the clock dependency behind it, the risk created by stale information and the evidence used to verify the behavior.

Ngenaire does not determine the safe freshness limit or replace representative timing analysis. That remains an engineering decision.

Its value is making the decision traceable enough that “connected” is not mistaken for “current” during design, integration or change.

Ask this at the next interface review

Choose one value that drives an operator or automated function.

Then ask:

How old can this information be before the system must stop trusting it—and have we verified what happens next?

If the interface document cannot answer, the packet format may be finished while the interface is not.

Which signal in your system has the most important freshness limit—and is that limit written down?

References

[1] National Aeronautics and Space Administration, “6.3 Interface Management,” NASA Systems Engineering Handbook, updated Jul. 26, 2023. Accessed: Sep. 20, 2026.

[2] Object Management Group, Data Distribution Service, Version 1.4, formal/2015-04-10, Apr. 2015. Accessed: Sep. 20, 2026.

[3] Ngenaire, “We Solve Hard Engineering Problems,” platform features. Accessed: Sep. 20, 2026.