search

usdot-fhwa-stol / carma-streets

CARMA Streets is a component of CARMA ecosystem, which enables such a coordination among different transportation users. This component provides an interface for CDA participants to interact with the road infrastructure. Doxygen Source Code Documentation: https://usdot-fhwa-stol.github.io/documentation/carma-streets/
10 stars 10 forks source link

UC3 SPaT Get Methods Returns Wrong Timestamp At The Hour Change #278

Open Saeid-Solei opened 1 year ago

Saeid-Solei commented 1 year ago

Types of Issue

Descriptive summary

The movement_events' timings in SPaT are not in epoch format. The timing values in SPaT are shown as decisecond passed from the start of the previous hour! To get these timing in epoch format, the signal_phase_and_timing.h library has "get" methods to get the epoch start and end times for a given movement_event. These methods convert the timing with decisecond format to epoch timestamp. In this conversion, these methods use the current timestamp to find the number of hours passed, and then add the decisecond value to the number of hours multipled by 3600.

The first issue is that for such a conversion, the SPaT timestamp (the time the spat is created or updated) shall be used instead of the current timestamp. The reason is that the get method might be called after the hour is changed and therefore, using the current timestamp might not provide the correct timestamp.

The other issue is that when the hour changes, the start time could be from the previous hour. In this case, adding the decisecond start time to the current hour will return a start time that is an hour away from the actual start time.

Carma streets version where this issue was discovered

4.2.0

Expected behavior

The get method in signal_phase_and_timing.h uses the SPaT timestamp for conversion. If the start time is before the hour change and the end time is after the hour change, the get methods shall provide correct timestamps.

Actual behavior

The get method in signal_phase_and_timing.h uses the current timestamp for conversion. If the start time is before the hour change and the end time is after the hour change, the get methods provide wrong timestamps (get_epoch_start_time returns a start time that is an hour away from the actual start time).

Steps to reproduce the actual behavior

Related work

yingyanlou commented 1 year ago

On 12/21/2022, the team decided to assign lower priority to this anomaly for the following reasons:

  1. The impact of this is that message we read locally in CARMA-Streets services will get timing information that is inaccurate based on CARMA-Streets internal SPaT processing latency (time from when SPaT message is created to time when it is used in a service ). From our logging this value ranges from 0-100 ms which seems largely unimpactful to the overall system performance in terms of behavior. In other words, it does not impact vehicle behavior noticeably.
  2. The issue due to hour change can be avoided in testing (by not starting any test close to the hour change)
  3. After looking deeper at this issue the change for it seems pretty large and possibly error prone.