Synchronization allows to coordinate different tasks across the network and gives some guarantees about the shared information. Some of these tasks are caused e.g. by the mutual dependency between LLCs and HLCs. LLCs require regularly updated commands from the HLCs to maneuver crash-free and as desired according to e.g. their planned trajectory. HLCs need up-to-date vehicle states from the LLCs to calculate commands that accommodate the current state of the overall system.
The timer class can be used to call tasks periodically, based either on the system clock or the simulated time which is controlled by the LCC. It can wait for a central start signal and can be stopped when a stop signal is sent (both by the LCC). Thus, timers on multiple systems can be started at the same time, and then work simultaneously if their period is set accordingly as well.
The callback function registered in start is called periodically until the timer is stopped, according to period, offset and the usage of simulated time. The following figures illustrate the role of the timer in combination with the LCC as central timing instance.
Real-time refers to the actual current time of the system, given by the system's current timestamp. To make sure that timestamps across different devices are comparable, NTP is used for clock synchronization on these devices. In a real-time scenario, all participants begin their computation (after being started either manually or by the LCC) at unix time
1 + period * n, where n is the smallest n such that the overall term is greater than or equal to the point in time when the timer was started. This assures synchronized periodic behavior for the registered components (using callbacks) across all devices. Real-time is useful whenever the system is used for real driving scenarios, e.g. when the actual physical vehicles are used.
"Real" time (SimpleTimer)
This timer is not intended to be used for actual real-time purposes. It can be used instead for GUI tools etc. to achieve periodic threaded callback of a function in periods which are multiples of 50 milliseconds. Apart from that, it works like the timer above (TimerFD).
The following drawing illustrates which role the LCC plays in a simulated time use case.
As mentioned before, the usage of simulated time and start and stop signals requires a central timing instance. This instance is located in the LCC. Timing can be controlled by the user using the LCC's UI.
The class is also responsible for handling simulated time. Here, further tasks are required. The current simulated time as well as the newest ready signals of the participants need to be stored. From the current time and the participants that rely on it, the system can also infer whether a participant is currently working or waiting for another time step, and if it is out of sync (if only old ready messages are received by it). The class receives and processes all ready signals so that the progression to the next smallest time step works properly. Of course, this also includes waiting for participants that are currently working and have not yet registered a new time step in which they want to be woken up again.