引言和功能概述

时间同步在不同应用程序和电子控制单元（ECU）之间至关重要，特别是在需要跨分布式系统关联不同事件的情况下。无论是为了跟踪这些事件的时间，还是为了在特定时间点触发它们，准确的时间同步都是实现系统协同工作的基础。

为此，AUTOSAR提供了一个时间同步API，使应用程序能够获取与其他实体或ECU同步的时间信息。有关所使用时间同步协议的格式、消息序列和语义的详细信息，请参阅AUTOSAR时间同步协议的协议要求规范（PRS）。

时间同步功能通过不同的“时间基础资源”（Time Base Resource，TBR）提供，这些资源根据其特性被分类为以下几种类型：

同步主时间基础：用于提供标准时间源的主时间基础。

偏移主时间基础：提供基于主时间基础的偏移时间。

同步从属时间基础：从主时间基础中获取时间信息的从属时间基础。

偏移从属时间基础：提供基于从属时间基础的偏移时间。

与Synchronized Time Base Manager（StbM）中的情况类似，时间同步模块（TS）提供的TBR与分布式系统中其他节点上的时间基础进行同步。应用程序通过TBR消费和管理时间信息，因此，TBR充当时间基础的代理，提供对同步时间基础的访问。这种抽象使得TS模块能够从“真实”的时间基础提供者中分离出来。

时间同步作为自适应平台基础设施中的一个功能集群，通过一个库向应用程序提供C++ API，与应用程序链接，以便访问时间同步功能。

#01 什么是时间同步？

在自动驾驶汽车中，多个 ECU 需要协同工作以确保车辆的安全和高效运行。例如，摄像头 ECU 负责捕捉道路图像，雷达 ECU 负责检测障碍物，制动 ECU 负责控制刹车系统。这些 ECU 需要精确的时间同步，以确保它们能够在同一时间点共享和处理数据。

假设摄像头 ECU 和雷达 ECU 的时间不同步，摄像头捕捉到的图像和雷达检测到的障碍物数据之间存在时间差异。这可能导致制动 ECU 接收到不一致的信息，从而无法正确判断何时刹车，最终可能导致交通事故。

通过时间同步，所有 ECU 的时钟都保持一致，摄像头捕捉到的图像和雷达检测到的障碍物数据能够在同一时间点被处理。这样，制动 ECU 可以准确地判断何时刹车，确保车辆的安全运行。

#02 时间同步的目的

时间同步功能集群旨在确保分布式汽车系统中不同的电子控制单元（ECU）维护同步时间。这对于协调操作、准确记录事件和确保系统可靠性至关重要。

时间同步（Time Synchronization）是自适应平台基础中的一个功能集群。作为一个功能集群，时间同步通过库向应用程序提供统一的 C++ API，该库（rb-tsync-lib）通常作为 AP 工具链的一部分提供，并与应用程序链接以访问功能，以便其能够获取与其他实体/ECU 同步的时间信息。

#03 时间同步模块的职责

在自适应平台中，时间同步功能集群支持跨多个目标 ECU 和/或自适应应用程序的功能分配，通过时间上的事件协调。协调可以包括事件的跟踪（在时间上）和在不同目标 ECU 上同时触发事件。

时间同步建立一个或多个时间基准资源（Timebase Resources），这些资源通过标准化网络协议 gPTP 与其他目标 ECU 进行同步，形成主或从时间参考。使用提供的 C++ API，自适应应用程序可以访问时间基准资源，因此可以协调其活动。

#04 时间同步的架构

ARA::TIME专注于解决车辆内部时间同步的核心难题，旨在为各类应用程序和电子控制单元（ECU）提供精准的时间一致性。这一能力对于确保车辆各项功能的协调运作及满足严格的时间要求至关重要。

具体而言，ARA::TIME提供以下关键服务：

1. 分布式ECU时间同步(Time Synchronization across distributed ECUs)：确保车辆内部所有分布式ECU和应用程序的系统时间保持高度一致，从而消除时间差异带来的潜在问题。

2. 时钟管理(Clock Management)：提供对系统时钟的全面访问权限，并允许在系统内部进行灵活的时间管理，以满足不同应用场景的需求。

3. 时间测量(Time Measurement)：实现高精度的时间间隔测量，这对于监控软件组件的执行效率以及调度具有严格时间要求的任务至关重要。

4. 全局时间概念(Global Time)：在涉及车对车（V2V）或车对基础设施（V2I）通信的场景中，ARA::TIME 推广全局时间概念，为这些功能提供一个共同的时间基准，确保通信的准确性和可靠性。

通过克服时间和同步方面的挑战，ARA::TIME 确保车辆的高级功能能够以协调、可靠且高效的方式运行，这是安全关键型汽车应用不可或缺的基础。

#05 关键组成部分

一个时间同步网络由一个时间主节点和一个或多个时间从节点组成。时间主节点使用标准化的时间分配协议将全局时间基准（Global Timebase）分配给从节点。时间从节点使用接收到的时间值来更新和维护自己的本地时间（Local Time），随后可以通过时间同步 API 提供给自适应应用程序。

系统可以由多个时间主节点组成——每个节点服务于独立同步的网络。此外，可以配置时间网关节点在一个时间分配网络上作为从节点，在第二个网络上作为主节点，从而转发同步时间。

全局时间主节点：该组件作为网络中时间同步的参考时钟。它生成同步消息，供其他 ECU（从节点）调整其本地时钟使用。

全局时间从节点：这些组件接收来自主节点的同步消息，并相应地调整他们的本地时钟。

通信连接器：将时间同步组件绑定到底层通信网络（例如，Ethernet）。

#06 通用精确时间协议 Generalized Precision Time Protocol

AUTOSAR 时间同步使用通用精确时间协议（gPTP）来同步时间主节点与从节点之间的时钟。

gPTP通过同步主节点（Time Master）和从节点（Time Slave）的时钟，实现全局一致的时间参考。

以下是gPTP实现主从时间同步的详细过程：

6.1 gPTP时间同步过程

初始状态：主节点（Master）和从节点（Slave）的时钟起初是不同步的，也就是说它们之间没有任何时间关系。

1. 同步请求（Sync Request）

1) 主节点发送同步请求消息给从节点，要求从节点进行同步（Sync）。

2) 从节点记录接收到同步请求的时间（t2），t2是从节点的本地时钟（未同步）。

2. 跟踪消息（Follow-up Message）

1) 主节点紧接着发送一个跟踪消息（Follow-up）给从节点，包含了主节点发送同步请求时的时间戳（t1）。

2) 从节点接收到跟踪消息后，记录下主节点发送同步请求的时间（t1）和自己接收到同步请求的时间（t2），然后计算两者之间的时差图片c，并执行初步同步。

3. 延迟请求（Delay Request）

1) 为了测量消息的传播延迟，从节点向主节点发送延迟请求（Delay Request）消息，并记录下发送时的时间（t6）。

2) 主节点接收到延迟请求后，记录下接收时的时间（t7），然后将这个时间发送给从节点。

4. 延迟响应（Delay Response）

从节点接收到主节点的延迟响应消息后，利用t6和t7的时间差计算消息传播延迟图片p。由于从节点的时钟已经因之前的同步引入了传播时间图片p，因此t6和t7之间的差异实际上是2图片p（因为在发送延迟请求时又引入了一个图片p）。

计算与同步

初始同步

时间差计算：图片c=t2-t1在初始同步过程中，从节点利用t1和t2计算主从节点的时间差

图中从节点接收到主节点发来Follow-up Message的时间是从节点自己本地时钟t3old（未同步）

初步同步：t3new = t3old+图片c（初步同步时间 t3new = 从节点本地时间t3old +主从节点的时间差图片C ）

初步同步时间与实际的同步时间之间差了一个消息传播延迟时间图片P

传播延迟

传播延迟计算：通过图片p=(t7-t6)/2计算传播延迟，这里的 t6和 t7 是从节点接收到消息的时间点。

总时间同步

从节点通过考虑初始时钟差异和消息传播延迟进行准确同步：

t_slave = t_master +图片C +图片P （图片C 主从节点的时间差，图片P传播延迟）

完成同步时间：更新从节点的时间为t8new = t8old +图片P （完成同步时间t8new= 初步同步时间t8old+传播延迟图片P）

周期性重新同步

漂移校正：随着时间的推移，主节点和从节点的时钟会自然漂移。为了避免漂移变得显著，gPTP协议包含定期重新同步过程，确保主节点和从节点时钟保持同步。

gPTP通过上述步骤实现了主从时间的精确同步，使分布式系统中的多个节点能够以统一的时间基准进行协调和操作。

#07 实 施

如前所述，不同自适应应用程序和/或ECUs之间的时间同步对于在分布式系统中关联不同事件至关重要，无论是为了能够跟踪这些事件的时间，还是为了在准确的时间点触发它们。因此，AUTOSAR为自适应应用程序提供了一个时间同步API，使它们可以获取与其他ECUs同步的时间信息。这个API由TSync客户端库（librb-tsync.so）实现，任何想要使用同步时间的应用程序都必须链接这个库。

7.1 rb-aptpd2

RTA-VRTE 包含一个 PTP 守护进程 rb-aptpd2，它是基于 IEEE Std 1588-2008 定义的 PTP 版本 2 的实现。rb-aptpd2 负责同步一组局域网（LAN）连接的目标 ECU 的时间基准。因此，每个需要同步的目标 ECU 都需要运行一个 rb-aptpd2 实例。

每个 rb-aptpd2 实例需要使用一组特定的参数来配置其功能。以下表格列出了基本的 rb-aptpd2 配置选项：

注意：为了兼容 AUTOSAR，还需要–ptpengine:transport=ethernet 选项。

示例

以主模式（masteronly,）、多播模式启动 rb-aptpd2 实例，使用虚拟接口 eth1 并链接到全局域 "42"：

以仅从模式（slaveonly,）、单播模式启动 rb-aptpd2 实例（指定目标地址：192.169.56.13, 192.169.56.14 和 192.169.56.15），使用虚拟接口 eth1 并链接到全局域 "42"：

7.2 rb-tsyncd

时间同步模块提供一个守护进程rb-tsyncd。这个进程管理包含配置的时间基准的共享内存区域。通常 rb-tsyncd 需要通过 ARXML/FlatCFG 文件进行必要的配置。

如果配置不可用或 rb-tsyncd 无法访问配置文件，它将无法启动。这会影响所有提供或使用时间基准资源的进程。

如果 rb-tsyncd 没有创建包含时间基准数据的共享内存文件，这些进程在尝试通过提供的 API 访问这些资源时将会中止。同样，如果这些进程缺乏访问时间同步共享内存文件的必要权限，也会出现相同的问题。

7.2.1 配置

需要在/AR-PACKAGES/AR-PACKAGE/ELEMENTS/MACHINE/MODULE-INSTANTIATIONS 下定义一个 TimeSyncModuleInstantiation。这个模块实例主要由称为时间基准（Time Bases）的元素组成，这些元素可以是两种类型：同步时间基准提供者（Synchronized Time Base Provider）和同步时间基准消费者（Synchronized Time Base Consumer）。

同步时间基准提供者需要引用一个全局时间以太网主设备（Global Time Eth Master）作为网络时间提供者参考（Network Time Provider Ref），该主设备定义在要用于该提供者的全局时间域中。同步时间基准提供者的短名称（Short Name）将用于提供者应用程序的 API。

同样，同步时间基准消费者需要引用一个全局时间以太网从设备（Global Time Eth Slave）作为网络时间消费者参考（Network Time Consumer Ref），该从设备定义在要用于该消费者的全局时间域中。同步时间基准消费者的短名称将用于消费者应用程序的 API。

可以在时间同步校正（Time Sync Correction）下为同步时间基准提供者添加额外的配置。此配置包含以下元素：

允许提供者速率校正（Allow Provider Rate Correction）：定义是否可以使用SetRateCorrection 方法设置时间基准的速率校正值。

偏移校正适应间隔（Offset Correction Adaptation Interval）：定义在此间隔（秒）内，自适应速率校正会消除速率和时间偏差。

偏移校正跳跃阈值（Offset Correction Jump Threshold）：定义校正方法的阈值（秒）。低于此值的偏差将通过线性减少在定义的时间跨度内校正。等于或大于此值的偏差将通过立即设置正确的时间和速率来校正。

每测量持续时间的速率校正次数（Rate Corrections per Measurement Duration）：用于确定当前速率偏差的同时速率测量次数。

速率偏差测量持续时间（Rate Deviation Measurement Duration）：用于计算速率偏差的时间跨度（秒）。

以下是 ARXML 时间基准配置的示例：

下一步是在 /AR-PACKAGES/AR-PACKAGE/ELEMENTS 下定义全局时间域（Global Time Domain）。该元素由域 ID（供 rb-aptpd2 使用）、全局时间主设备和从设备的配置以及以下与循环冗余校验（CRC）相关的一般元素组成：

目标物理地址：定义以太网时间同步消息通信的 MAC 多播地址。

FUP Data Id Lists：用于计算 CRC 的 FUP 消息的 DataIDList。只有在定义了所有十六个值时，DataIDList 才有效。

Message Compliance：定义以太网时间同步消息对特定标准的合规性。

VLAN Priority:：定义在使用 VLAN 标签发送消息时应分配给时间同步消息的 VLAN 优先级。

CRC Correction Field：CRC 标志，定义是否在 CRC 计算和验证中考虑消息的 CRC 校正字段。

CRC Domain Number：CRC 标志，定义是否在 CRC 计算和验证中考虑消息的 CRC 域号。

CRC Message Length：CRC 标志，定义是否在 CRC 计算和验证中考虑消息的 CRC 消息长度。

CRC Precise Origin Timestamp：CRC 标志，定义是否在 CRC 计算和验证中考虑消息的 CRC 精确原始时间戳。

CRC Sequence Id：CRC 标志，定义是否在 CRC 计算和验证中考虑消息的 CRC 序列 ID。

CRC Source Port Identity：CRC 标志，定义是否在 CRC 计算和验证中考虑消息的 CRC 源端口标识。

如果需要 CRC，则必须定义FUP Data Id Lists和Message Compliance元素。

全局时间主设备由全局时间以太网主设备（Global Time Eth Master）元素组成，这些元素通过以下元素进行配置：

Communication Connector Ref：全局时间以太网主设备需要绑定到以太网通信连接器。

Immediate Resume Time：定义“立即”消息和下一条周期消息之间的最短时间。

Is System Wide Global Time Master：如果设置为 true，则全局时间以太网主设备将作为全局时间信息的根。

Sync Period：表示同步周期（秒）。

CRC Secured：定义是否支持 CRC。

OFS Sub TLV：子 TLV 配置标志，定义是否在时间同步消息中包含 OFS 子 TLV 字段。

Status Sub TLV：子 TLV 配置标志，定义是否在时间同步消息中包含状态子 TLV 字段。

Time Sub TLV:：子 TLV 配置标志，定义是否在时间同步消息中包含时间子 TLV 字段。

User Data Sub TLV：子 TLV 配置标志，定义是否在时间同步消息中包含用户数据子 TLV 字段。

从设备由全局时间以太网从设备（Global Time Eth Slave）元素组成，这些元素通过以下元素进行配置：

Communication Connector Ref：全局时间以太网从设备需要绑定到以太网通信连接器。

Follow Up Timeout Value：跟随消息的接收超时。

Time Leap Future Threshold：定义当前本地时间基准值与新接收的全局时间基准值之间允许的最大正差异。

Time Leap Healing Counter：定义在时间基准被认为恢复之前，时间差异必须保持在时间跳跃未来阈值和时间跳跃过去阈值范围内的更新次数。

Time Leap Past Threshold：定义当前本地时间基准值与新接收的全局时间基准值之间允许的最大负差异。

CRC Validated：定义是否支持 CRC 验证。

Status Sub TLV：子 TLV 配置标志，定义是否在时间同步消息中包含状态子 TLV 字段。

Time Sub TLV：子 TLV 配置标志，定义是否在时间同步消息中包含时间子 TLV 字段。

User Data Sub TLV：子 TLV 配置标志，定义是否在时间同步消息中包含用户数据子 TLV 字段。

注意：由于偏移时间基准正在从 AUTOSAR 时间同步协议规范中移除。

Sub-TLV字段 STATUS 与网关用例相关，目前不在 AUTOSAR 时间同步协议规范的范围内。这些可能会在未来某个时候得到支持。

以下是 ARXML 配置的示例：

此外，以太网配置必须包含在/AR-PACKAGES/AR-PACKAGE/ELEMENTS/MACHINE DESIGN 下，如下所示：

#08 时间同步的使用

8.1 创建 SynchronizedTimeBaseProvider

打算消费配置的时间基准资源的时间基准信息的进程必须引入时间同步库，并使用在 ECU 配置中找到的实例说明符（Instance Specifier）实例化 `SynchronizedTimeBaseConsumer` 类型，作为同步时间基准消费者的短名称。因此，在创建消费者之前，必须构建一个实例说明符。

传递给构造函数的实例说明符唯一标识了 `SynchronizedTimeBaseConsumer` 实例应使用的时间基准。

SynchronizedTimeBaseProvider provider(rs.Value());

这些类型的接口允许进程更新时间基准资源的时间基准信息。可以使用 SetTime 或 UpdateTime 方法提供时钟和用户数据的新时间值。使用 SetTime 还会触发总线上的传输，而使用 UpdateTime 则仅在本地更新时钟值，总线上的传输将在下一个周期发生。

8.2 创建 SynchronizedTimeBaseConsumer

打算消费配置的时间基准资源的时间基准信息的进程必须引入时间同步库，并使用在 ECU 配置中找到的实例说明符（Instance Specifier）实例化 SynchronizedTimeBaseConsumer 类型，作为同步时间基准消费者的短名称。因此，在创建消费者之前，必须构建一个实例说明符。

传递给构造函数的实例说明符唯一标识了 SynchronizedTimeBaseConsumer 实例应使用的时间基准。

现在可以使用这个实例说明符构建

SynchronizedTimeBaseConsumer：

SynchronizedTimeBaseConsumer consumer(rs.Value());

这种类型的接口允许进程根据时间基准资源获取当前时间等信息。可以使用 GetCurrentTime 和 GetTimeWithStatus 方法获取时间：

这个类的方法的返回值没有使用 ara::core::Result 类型包装，这意味着无法通过此 API 报告错误状态。

8.3 实例展示：

通过使用rb-tsyncd在同一以太网网络中同步由两台ECU 组成的集群，以访问存储时间基准数据的共享内存区域，并使用rb-aptpd2实现精确时间协议（PTP）来更新网络时间基准。ECU1(蓝色)将运行rb-tsyncd、以主模式运行的rb-aptpd2实例，以及以提供者模式运行的自适应应用tsync-e2e_test。

该应用程序将创建一个ara::tsync::SynchronizedTimeBaseProvider类的对象，通过该对象向网络提供公共时间戳和用户数据，使用UpdateTime方法进行更新。

第二台ECU2将运行rb-tsyncd、以从模式运行的rb-aptpd2实例，以及以消费者模式运行的自适应应用tsync-e2e_test。在这种情况下，tsync-e2e_test将创建一个ara::tsync::SynchronizedTimeBaseConsumer类的对象，利用GetCurrentTime和GetTimeWithStatus方法分别获取网络时间戳和用户数据。

具体来说，在ECU1上将运行一个rb-tsyncd实例和一个作为已配置时间基准sysclock_provider主设备的rb-aptpd2实例，以及每5秒提供时间基准时间戳和用户数据的e2e_qnx_provider。而ECU2将运行一个rb-tsyncd实例和一个作为已配置时间基准sysclock_consumer从设备的rb-aptpd2实例，以及每1秒对齐时间基准时间戳和用户数据的e2e_linux_consumer。

下图展示了ECU2的日志（左侧）和ECU1的日志（右侧）。需要注意的是，此示例可以在不同机器上运行多个时间域从设备的实例。此外，该示例中的配置可以通过更改SoftwareCluster_0（主设备）和SoftwareCluster_1（从设备）中的进程，来在不同架构上运行时间域主设备和从设备。

#09 时间同步过程梳理

1. 主节点初始化：

Global Timebase主节点配置通信连接器和同步参数。

它开始按定义的间隔广播同步消息。

2. 从节点初始化：

Global Time从节点配置为监听来自主节点的同步消息。

他们设置跟随超时值和时间跃迁修正的阈值。

3. 消息交换：

同步消息：主节点发送包含其当前时间的同步消息。

跟随消息：主节点发送跟随消息以提供额外的时间信息。

延迟请求：从节点向主节点发送延迟请求以测量往返延迟。

延迟响应：主节点响应延迟请求的时间。

步骤 5：时间调整

每个从节点使用同步消息和延迟请求中的信息计算其本地时钟和主节点时钟之间的时间差。

从节点根据计算的偏移量调整它们的本地时钟，确保它们与主节点保持同步。

步骤 6：处理时间偏差

时间跃迁未来/过去阈值：这些阈值定义了可接受的时间差限制。如果从节点接收到的时间超出这些阈值，它将启动修复过程以重新同步。

修复计数器：该计数器计算在阈值范围内成功更新的次数，直到认为该时间基准被视为已修复。

步骤 7：持续同步

定期的同步确保主节点和从节点之间的任何偏差随着时间的推移而得到纠正。

系统持续监控同步状态，并根据需要调整参数。

步骤 8：自适应应用中的实现

1. 创建 SynchronizedTimeBaseProvider：

需要提供时间的应用程序必须使用唯一实例说明符实例化`SynchronizedTimeBaseProvider`。

使用 `SetTime` 和 `UpdateTime` 等方法来管理时间基准。

2. 创建 SynchronizedTimeBaseConsumer：

消费配置信息的时间基准资源的应用程序必须实例化`SynchronizedTimeBaseConsumer`。

他们可以使用 `GetCurrentTime` 等方法检索当前时间和状态。

步骤 9：错误处理和通知

系统未使用结果类型包装返回值，这意味着错误处理必须由应用程序显式管理。

可以注册通知，以在新时间数据可用时通知应用程序。

#10 小 结

AUTOSAR 中的时间同步功能集群提供了一种结构化的方法来维护多个 ECU 之间的同步时间。该过程包括设置全球时间主节点和从节点、交换同步消息、调整本地时钟以及通过定期更新确保持续同步。通过使用通用精确时间协议（gPTP）和自适应平台的时间同步 API，系统能够实现高精度的时间同步，从而提高车辆的安全性和可靠性。