Page History

TODO: get_time, LCC timing description (e.g. saving next time stamp / listening to different timers)

Synchronization across all participants in the RTI DDS network is very important for all tasks that

...

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

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 for real driving scenarios, to evaluate the system in a real-time use case.

The following drawing shows which role the LCC plays in the real-time timing case.

Simulated time

Simulated time refers to a fictional measure of time, that is not related to the unix time of the physical devices on which the different tasks operate. Instead, the current time is determined by a central timing instance, in this case by the LCC. Simulated time can be used to speed up or slow down the simulation of a scenario, which might help to detect errors, to improve the timing of the individual components or to test faster how the system operates on the long run.

In a simulated time case, it is required that all participants are uniquely identifiable (here by setting node_id differently for all participating tasks). The participants register the next time when their callback function should be called according to the fictional time measure, which is based on the offset and period settings. The LCC collects all these ready signals until timing is started manually by the user (or until ready signals from all pre-registered timers have been received). It then performs the following tasks in a loop:

• Select the smallest next fictional time stamp of all received timestamps (that is greater than the current simulated time) and send a system trigger to all participants containing this time stamp
• Wait for all participants that registered this timestamp to register a new, greater timestamp

The simulated time progresses this way until the timing is stopped in the LCC. The time can of course only progress if all participants send new ready signals after they have been invoked (and after the work of their callback function has been done).

The following drawing illustrates which role the LCC plays in a simulated time use case.