为了协调在不同平台上运行的软件模块之间的事件，exOS 在整个系统中分配了一个全局时间戳。该时间戳的基础是 Automation Runtime 的所谓 NETTIME。NETTIME 是一个分辨率为 1us 的单调时钟（即保证向上计数而无跳变）。
该 NETTIME 提供给 exOS 目标，可用于协调 Linux 应用程序与机器 I/O 或伺服驱动器之间的操作和事件。例如，在实时自动化运行时系统上的轴上触发信号，可与从 Linux 上的 USB 设备读取数值同步。即使在 Linux 程序对来自 Automation Runtime 的数值进行异步计算（例如使用人工智能算法）的情况下，存储的数值的 NETTIME 也可用于在未来精确触发事件，或者仅基于当前的 NETTIME，或者基于轴位置等其他重要数值。
为了补偿从 PLC 到 exOS 目标系统之间的传播延迟，使用了一种类似于 NTP 或 PTP 的算法，即每个站点发送其当前时钟以测量传输延迟。根据延迟时间，从 AR 发送一个推断的 NETTIME 值，并 在 Linux 中估计 CLOCK_MONOTONIC_RAW 。如果时间估计值在给定精度范围内，NETTIME 值将以值对形式（NETTIME@current_time） 分配给应用程序。 通过函数 exos_datamodel_get_nettime()， 每个 Linux 应用程序都能获取 "当前 "NETTIME - 即从最后一个有效值对推算出的当前时间。
同步状态可通过 ExData 日志查看，该日志应在系统启动时输出以下信息（使用默认日志过滤器）：
一般同步状态可通过 ExDataConnectionInfo 功能块 获得 ， 详细情况可通过 ExSyncInfo 功能块 查看 。
在 Linux 中，所有应用程序的时间基准都是 CLOCK_MONOTONIC_RAW，该时钟在所有应用程序中都是相同的，并保证随时间推移而增加（即不会向后跳变）。之所以需要这样做，是因为 Linux 应用程序中数值变化的时间戳之间需要有正确的关系，这意味着触发后续事件的数值变化必须始终有较早的时间戳。
在 Linux 中 ，使用 CLOCK_MONOTONIC_RAW的应用程序之间的这种同步时间戳行为 有一个缺点，那就是由于它不能向后跳转，因此随着时间的推移，它将比 CLOCK_REALTIME 或在本例中比 AR NETTIME 增加得更多 。这意味着，为了使 Linux 应用程序之间的时间戳行为保持一致，时钟会发生漂移。这种漂移可以通过 ExTargetClockDeviation 功能块进行测量 ，测量单位为每小时微秒（漂移）。
In order to achieve a given microsecond synchronization Precision, this "drift" may not supersede the configured Precision. The time in which the "drift" lies within the Precision is called the Guard Time and is calculated by the exOS TP for the Hypervisor system. In Simulation, the Guard Time has a predefined value of 30 seconds, as "real" synchronization is very hard to achieve here.In order to coordinate events between software modules running on different platforms, exOS distributes a global timestamp across the whole system. The base of this timestamp is the so-called NETTIME from Automation Runtime. The NETTIME is a monotonic clock (i.e. guaranteed to be counting upwards without jumps) with a resolution of 1us.
This NETTIME is provided to the exOS targets and allows to coordinate actions and events between e.g. a Linux application and machine I/Os or servo drives. For example, hitting a trigger signal on an axis on the real-time Automation Runtime system can be synchronized with reading a value from a USB device on Linux. Even in cases where the Linux program runs asynchronous calculations (for example using AI algorithms) on values from Automation Runtime, the stored NETTIME of the values can be used to precisely trigger events in the future, either based on the current NETTIME alone, or based on another significant value like an axis position.
In order to compensate for the propagation delay from the PLC to the exOS target system, an algorithm similar to NTP or PTP is used, where each station sends its current clock to measure the transport latency. With the latency, an extrapolated NETTIME value is sent from AR with an estimated CLOCK_MONOTONIC_RAW in Linux. If the time estimate is within the given precision, the NETTIME value is distributed to applications in value pairs (NETTIME@current_time). The function exos_datamodel_get_nettime() lets each Linux application retrieve the "current" NETTIME - extrapolated to the current time from the last valid value pair.
The synchronization status becomes visible via the ExData log which should output the following message at system startup (using default log filters):
The general synchronization status can be obtained via the ExDataConnectionInfo function block, and the detailed view is visible via the ExSyncInfo function block.
Clock Deviation and Guard Time
In Linux, the time base for all applications is the CLOCK_MONOTONIC_RAW, which is a clock that is equal across all applications and is guaranteed to increase over time (i.e. not jump backwards). This is needed as the timestamps of value changes across the Linux applications need to have the correct relation between each other, meaning a change of a value that triggered a following event must always have an earlier timestamp.
This synchronous timestamping behaviour between applications with the CLOCK_MONOTONIC_RAW in Linux comes with the drawback that - because it cannot jump backwards - it will increase more over time than the CLOCK_REALTIME, or - in this case - than the AR NETTIME. This means in order to have a consistent timestamp behaviour between Linux applications, the clocks will drift. This drift can be measured by the ExTargetClockDeviation function block, where it is measured in microseconds (drift) per hour.
In order to achieve a given microsecond synchronization Precision, this "drift" may not supersede the configured Precision. The time in which the "drift" lies within the Precision is called the Guard Time and is calculated by the exOS TP for the Hypervisor system. In Simulation, the Guard Time has a predefined value of 30 seconds, as "real" synchronization is very hard to achieve here.