深入解读车载时间同步
时间同步协议介绍
目前广泛使用的时间同步协议主要是三种 NTP（Network Time Protocol）、PTP（Precision Time Protocol）和 TTEthernet（SAE AS6802）。
NTP（网络时间协议）是较旧的时间系统。通常从 GPS 网络中的卫星接收时间信息。通常 NTP 时间精度是毫秒级别。NTP 时间不足以满足越来越多的应用程序，它无法提供金融交易、国家电网和 5G 通信、智慧城市、大数据人工智能等行业的精确计时，所以通过整合更加精确时间协议（PTP）到原有的时间网络中。与经常在软件中实现的 NTP 相比，PTP 更喜欢对时间戳进行硬件处理以获得更高的准确性。随着网络设备处理时间戳和补偿内在延迟，PTP 提供了时间感知分组网络这种更高水平的同步。丰富的性能监控功能使 PTP 成为关键任务应用程序的更好的计时技术。
PTP 的主要特点是其基于 IEEE 1588 标准的同步机制，这种机制可以精确地测量网络中的时间差异，并使用这种信息来同步网络中的所有设备。在汽车电子域控制器中，PTP 可以用于将时间信息从一个 ECU 传递到另一个 ECU，从而实现时间同步。
车载中常用的 gPTP（Generalized Precision Time Protocol）协议是 PTP 的扩展版本，它是 IEEE 802.1AS-2011 标准的一部分，被设计用于满足汽车工业的特定需求。
PTP 与 gPTP 的差异
PTP 和 gPTP 的协议差别如下：
| 类别 | PTP(IEEE 1588-2008) | gPTP(IEEE 802.1AS-2011) |
|---|---|---|
| 传输延时测量方式 | 支持 P2P 方式和 E2E 方式 | 仅支持 P2P 方式 |
| 时间戳采样方式 | 支持 MAC 层，也支持 Layer3，Layer4 的时间戳 | 仅支持 MAC 层时间戳 |
| 时钟同步类型 | 既支持单步模式，也支持双步模式 | 仅支持双步模式 |
| 时钟类型 | 存在多种类型的时钟：原始时钟，边界时钟，E2E 透传时钟，P2P 透传时钟 | 存在两种时钟：端节点节点时钟，桥接节点时钟 |
| 桥接节点兼容性 | 可以使用 TSN 网络，也适用于非 TSN 网络 | 仅适用于 TSN 网络 |
- P2P 方式：透传节点（桥接设备）需要记录驻留时间，并加入到报文中
- E2E 方式：只需要端到端的时间差，误差比较大，但是对中间的透传设备要求低
- 时间戳采样方式：如果是 MAC 采样，那么确定性比较高，误差比较小，如果在 IP 层或者 UDP 层采样时间戳，由于受到操作系统调度的影响，精度不高
- 时钟同步类型：双步模式对 MAC 的要求相较于单步模式，增加了 Follow_Up 消息，但是对 MAC 层的要求较低，便于网络扩展与应用
AUTOSAR 规范中针对 gPTP 做了进一步的限制和约束：
- 不支持 BMCA 算法，车载网络为静态网络，不需要计算 Master 节点
- 不支持 Announce 与 Signaling 报文的发送与接收
- Pdelay_Req 不作为开启发送 Sync 报文的前置条件
- 允许使用带有 VLAN 信息的报文，前提是网关支持转发预留的多播地址：01:80:C2:00:00:0F
- 报文中 CRC 保护措施不能作为信息安全的内容
gPTP 协议介绍
在当今的汽车电子域控制器中，时间同步成为了一个非常重要的需求。这主要是因为汽车中各个 ECU（电子控制单元）之间需要进行高效且可靠的信息交换，以实现诸如自动驾驶、智能交通控制、车辆远程信息处理等功能。而要实现这些功能，就需要一个统一的时间基准，以确保各个 ECU 能够协同工作。gPTP（Generalized Precision Time Protocol）就是为此目的而设计的。
gPTP 的主要特点是其能够适应汽车环境中的各种网络拓扑结构，包括 CAN、LIN、MOST、Ethernet 等。此外，gPTP 还具有更好的鲁棒性和可靠性，能够处理网络中的故障和延迟，从而确保时间同步的准确性。
总的来说，汽车电子域控制器需要时间同步是因为需要各个 ECU 协同工作以实现复杂的功能。而 gPTP 则是为了满足这一需求而设计的协议。通过使用这些协议，可以确保汽车中的各个 ECU 具有精确且一致的时间基准，从而实现高效且可靠的信息交换。
gPTP 协议原理
在 gPTP 协议中，时间同步是按照“域”（domain）划分的，包含多个 PTP 节点。在这些 PTP 节点中，有且仅有一个全局主节点（GrandMaster PTP Instance），其负责提供时钟信息给所有其他从节点。PTP 节点分为两类：PTP End Instance（PTP 端节点）和 PTP Relay Instance（PTP 交换节点）。其中，PTP End Instance 可以作为 GrandMaster，也可以接收来自 GrandMaster 的时间同步信息。PTP Relay Instance 从某一接口接收时间同步信息，修正时间同步信息后，转发到其他接口。
gPTP 要完成的主要任务包括：主时钟的分配，时钟频率同步，延迟时间测量和时钟偏差测量。下面我们就来深入聊一聊每个功能。
主时钟的分配
gPTP 的主时钟选择机制是“最佳主时钟算法（BMCA）”。选择启动算法是，所有可能成为主时钟的端点都会参与竞争。要启动 BMCA 算法，所有端点都通过发送 Announce 报文来宣告自己的能力。各个端点比较自己与其他端点的相关字段值，胜出者作为主时钟端点。但车辆是一个封闭的网络，不会出现节点总变化的情况，所以车载应用中，主时钟往往都是固定的，比如网关。
时钟频率同步
网络中各个节点的时钟的频率并不总是完全一致。比如，在实际为 100 秒的时间段时间，A 节点的时钟可能计时为 90 秒，B 节点的时钟可能计时为 100 秒（实际中不可能出现如此大的偏差，但偏差总是有的，这里只是举例说明）。所以 gPTP Slave 的时钟频率需要与 master 相匹配。频率同步的实现方式如下图所示：
在实际的 gPTP 通信中，master 会不停地发送 Sync 和 Follow-up，slave 能够测量出自己收到 Sync 报文的时间，即上图中的 T2 和 T4（这个时间是以 slave 的本地时钟为基准的）。在每个 sync 报文之后，master 都会发送一个 follow-up 报文，用来告诉 slave 自己发送上一条 Sync 报文时的时间戳（以 master 的本地时钟为基准）。没有 follow-up 报文的话，slave 无法确定 Sync 报文的实际发送时间，即上图的 T1 和 T3。有了 T1、T3 和 T2、T4，slave 就能够计算出自己的时钟频率与 master 之间的偏差，计算式如下图所示：
延迟时间测量
为了将自己的时钟与 master 同步，slave 必须测量出自己与 master 之间报文传递的延迟时间。时延测量使用到的上文中提到的 PDelay_Req、PDelay_Resp 和PDelay_Resp_Followup 三种 gPTP 报文。具体的测量方式如下图所示：
- 首先 slave 发送 PDelay_Req 报文，请求测量延迟时间
- PDelay_Req 报文离开物理层时，slave 利用本地时钟获得 T1 时间戳
- PDelay_Req 报文到达应答方物理层，master 利用本地时钟获得 T2 时间戳
- master 生成一个 PDelay_Resp 报文并发送，将 T2 时间戳带给 slave
- slave 利用本地时钟可以捕获收到 PDelay_Resp 时的时间戳 T4
- 然后 master 会发送 PDelay_Resp_Followup 报文将 T3 带给 slave
这样 slave 就知道 T1,T2,T3,T4 这四个时间戳了，然后利用如下算式计算延迟时间：
其中 R 是在上节中提到的计算出的 slave 与 master 之间的时钟频率偏差。这种计算方法中，认为信道是对称的，即报文从 slave 到 master 和 master 到 slave 所经历的延时是一样的。
时钟偏差测量
根据上文计算出延迟时间和频率差异之后，slave 就可以利用 master 不断发送的 sync 和 follow_up 报文将自己的时钟与 master 进行同步了。
具体的同步方式如下图所示：
计算公式如下图所示：
在上述计算公式中，Tb 是 slave 在某时刻本地时间戳，Ta 是该时刻 master 上的本地时间戳。同步的目的，就是根据 Tb 可以推算出 Ta 的值。在这个计算式中，slave 通过 sync 和 follow_up 报文获得 T1 和 T2，delay 和 R 在之前的延迟时间和频率差异计算中已经获得。所以，slave 能够根据本地时间戳 Tb 计算出 master 上的时间戳 Ta，时间同步就实现了。
gPTP 报文结构
gPTP 协议位于 OSI 模型的第二层，可以依赖于以太网传输。gPTP 报文利用以太网传输时 Ethertype = 0x88F7。gPTP 协议中的报文被划分成为了报文级别（Message Class）和报文种类（Message Type）两个属性，其中报文级别的具体划分如下：
- 事件型报文（Event Message）：这类报文的特点是在接收或发送事件类报文时，会对硬件计数器进行采样，将震荡周期计数值和时钟震荡频率以及基准时间相结合，生成一个时间戳
- 通用型报文（General Message）：这类报文在设备接收或发送时，不会触发硬件计数器的采样，不会生成时间戳
| Message type | Message class | Value |
|---|---|---|
| Sync | Event | 0x0 |
| Pdelay_Req | Event | 0x2 |
| Pdelay_Resp | Event | 0x3 |
| Announce | General | 0xB |
| Signaling | General | 0xC |
| Follow_Up | General | 0x8 |
| Pdelay_Resp_Follow_Up | General | 0xA |
- Announce 报文是在主时钟分配中启用，包含最佳主时钟的运算时间
- Signaling 报文主要用来传递信息、请求或控制指令
gPTP 报文由 3 部分组成：
- Header（对所有 gPTP 都一样）
- Body（取决于 gPTP 报文类型）
- TLV（type length value）
Header
其中 Header 是所有类型的 gPTP 报文都有的，它有 34 个字节，结构如下图所示：
Header 中各字段的含义如下：
| 字段 | 含义 | 作用 | 取值 |
|---|---|---|---|
| MsgType | 报文类型 | 标识报文类型 | 参考报文类型表格 |
| TranSpec | 传输协议 | 标识所用的传输规范 | 0x1 |
| verPTP | PTP 协议版本 | 标识对应的 IEEE 1588 版本 | 0x2 |
| MsgLength | 报文长度 | 标识整个 PTP 的报头长度 | / |
| DomainNumber | 域编号 | 标识该报文所属的时钟域 | / |
| FlagField | 标识域 | 对特殊报文的特殊取值有不同作用 | 参考 IEEE 802.1 AS Table 10-6 |
| CorrectionField | 修正域 | 各报文都有，主要应用于 Sync 报文，用于补偿传输时延 | 0x0 |
| SourcePortIdentity | 源端口标识符 | 标识发送该报文的时钟 ID 和端口号 | / |
| SequenceID | 序列号 | 标识消息的序列号 | / |
| ControlField | 控制域 | / | 0x5 |
| logMsgInterval | 录入消息周期 | PTP 消息的发送时间 | 不同类型报文的取值不同 |
Body
取决于 gPTP 报文类型，即 Message Type。具体可参考上面的表格。
gPTP 方案介绍
AutoSAR 时间同步
上图是 AUTOSAR 时间同步的软件架构图。AUTOSAR 中的时间同步可以基于多个通信方式，比如 CAN、FR、ETH 等。这里我们着重看一下以太网的时间同步。Ethernet TimeSync 时间同步协议是基于 IEEE 802.1AS 规范中定义的 gPTP 标准协议发展出来的一套协议，该模块的时间同步原理与 gPTP 协议一致，只不过在协议内容方面，AUTOSAR 规范进行了一些扩展，丰富了 gPTP 时间同步内容。gPTP 协议位于 OSI 模型的 2 层之上，可以依赖于以太网传输。gPTP 报文利用以太网传输时， MAC 报头中的 Ethertype = 0x88F7。以太网的时间同步功能涉及到的模块有 Ethernet Driver，Ethernet Interface，Ethernet TimeSync 以及 StbM 模块等。其中 Ethernet Driver，Ethernet Interface 模块提供时间同步报文的收发解析，Ethernet TimeSync 模块负责时间同步协议解析，StbM 负责时间同步统一管理与分发，为应用层提供全局时间戳服务。
LinuxPTP 时间同步
LinuxPTP 整个是运行在用户态的软件，使用 Linux 内核提供的相关应用程序编程接口。LinuxPTP 主要包含两个软件，一个是 ptp4l，一个是 phc2sys。
- ptp4l：遵循 IEEE 1588-2008 标准文档规范，实现了 BC（Boundary Clock）、OC（Ordinary Clock）和 TC（Transparent Clock）等功能，也就是它可以设置时钟作为 master，slave 等。
- phc2sys：phc2sys 是一个同步系统中两个或多个时钟的程序。一般用于将系统时钟与 PTP 硬件时钟（PHC）同步，硬件时钟一般由 ptp4l 进行同步。