TimeDaemon: TimeJumpsValidator does not match the time leap requirements #264

The time leap detection of the TimeDaemon TimeJumpsValidator does not match feat_req__time__veh_status_leap_fut / veh_status_leap_past (a time leap is the correction of the Vehicle Time after an update against the Vehicle Time predicted for the Sync ingress instant before the update, compared with a configured threshold), feat_req__time__veh_leap_debounce, feat_req__time__veh_leap_heal / veh_leap_past_heal and feat_req__time__veh_leap_after_timeout.

Findings

1. TimeJumpsValidator::IsTimeJumpDetected predicts the master time as last precise_origin_timestamp + (current − last sync_ingress_timestamp). It does not apply the measured rate deviation (PtpTimeInfo::rate_deviation is available), the correction_field or the peer delay.
   With a free-running PHC (PhcConfig::enabled = false by default), a local rate deviation of 100 ppm gives 12.5 µs prediction error per 125 ms sync interval, i.e. a false time leap for thresholds in the µs range. A varying correctionField (bridge residence time) adds further error.
2. In the states kIdle and kInitialSyncDebouncing the validator does not call UpdateStatus, so the time leap flags received from upstream pass through unchanged to the users during the initial debounce, although no time leap shall be indicated in that period.
3. TimeJumpState allows only one direction: a time leap to the past clears the time leap to the future indication, and one valid_frames_cnt_ heals both. The two indications must be independent: both can be active at the same time, and each clears after the configured number of consecutive updates without a leap in its own direction (same configured count for both).
4. The validator ignores status.is_timeout. The first update after a timeout is predicted across the gap from the last frame before the timeout. The evaluation of the first update after a timeout shall be skipped unless configured otherwise (new configuration parameter, default: skip).
5. The PTP machine (50 ms polling) and the ControlFlowDivider (republish on timeout) deliver the same Sync several times. The validator counts a repeated frame (same Sync ingress timestamp) as a valid update and logs an error. Only new updates (new sequence_id) shall be evaluated and counted for healing; a repeat shall not be logged as an error.

Proposal

• Compare the corrected master time (precise_origin_timestamp + correction_field + peer delay) with a prediction that applies the measured rate deviation to the local ingress difference.
• The validator determines the time leap flags in all states (no time leap indicated during the debounce).
• Two independent time leap indications with independent healing progress and one common configured healing count.
• Skip the evaluation of the first update after a timeout unless configured otherwise.
• Evaluate and count only new updates (new sequence_id).

Acceptance criteria (unit tests)

• ±100 ppm rate deviation, 125 ms sync interval, 5 µs threshold, no real correction: no time leap.
• Correction of 6 µs (future and past) with 5 µs threshold: time leap in the matching direction.
• Varying correctionField compensated: no time leap.
• Upstream time leap flags set during the debounce: no time leap indicated.
• Future leap followed by a past leap: both flags set, then cleared independently.
• First update after a timeout with a correction above the threshold: no time leap (default); time leap when configured to evaluate.
• Leap followed by repeats of one good Sync: not healed until the configured count of new good updates is reached.

Out of scope: the time leap flags set by the TimeSlave (SyncStateMachine::BuildResult), to be decided with the TimeSlave component requirements; repeated deliveries of the same update to the IPC publisher and the client notifications (polling cycles of the PTP machine and the ControlFlowDivider), handled separately.