车载gptp同步原理介绍

ptp/gptp

在车载，vehicle time使用gptp来做vehicle time的同步，gptp算是ptp的简化版，规范定义来源于IEEE 802.1AS，理论上可以达到ns级的误差。针对不通的ptp版本和gptp的对比如下：

1. gptp同步原理

针对gptp，所有slave节点，都与master（grandmaster）的时钟保持同步；在车载领域，master节点都是静态指定的，并且从功能安全的角度来看，会选择具备功能安全的mcu来做为master节点。所以会一般选用gw（gateway）或者tbox来做master，而选择gw或者tbox对后续整车整个时间管理是策略会有影响。

master节点的sync报文（sync+follow up，以下用sync报文代替）会使用二层报文传遍整个时钟树，gptp中，sync报文使用二层报文，mac地址是指定的广播mac地址，但是实际上sync报文都是以单播的形式发送到下一跳节点，如果下一条节点是Bridage，则将重新修正correctionField（路由处理所消耗的时间），然后再将原来信息添加到sync报文从而路由到下一跳节点，直至到终端节点--End-Station。sync报文会包含master preciseOriginTimestamp、correctionField等。如下图：

slave节点会根据sync报文带上的preciseOriginTimestamp、correctionField来调整自己的时钟频率以及偏移；为了消除总线上的传输时延，slave节点会发送延迟测量报文，由于在车载每一跳都会有gptp协议栈，所以理论上测出的时钟同步是单向、精确的，如下图：

Pdelay=（（t（4）-t（1）） - （t（3）-t（2）））/2

Pdelay测量的仅仅相邻两跳之间的传输时延，所以Pdelay是不会穿透Bridge的，从上面可以看到，gptp相对于can tsync不仅仅消除了传输延迟和路由报文时的处理延迟，同时时间戳是由硬件加上的，所以其时钟同步精度远远大于can tsync。

有了上述基础后，我们将所有gptp报文放一起，如下所示，并推导出slave节点用于调幅和调相的公式。

C Pdelay = （（t6-t3）-（t5-t4））/2 Gm = t1 + Pdelay + CorrectionField //主时钟时刻+线缆传输时间+路由报文花销掉的时间 TimeOffset = t2 - Gm //用于调相或者调幅 Ratio = （Gm-Gm_last） /（t2-t2_last） //Gm_last和t2_last可以更久之前的。 FreqOffset = （1-Ratio）*1e9//用于调频

根据规范，sync报文一般是125ms发送一次；而Pdelay报文是1s发送一次，也可以是每次sync报文触发一次Pdelay报文，并且一般来说说同步精度是可配置的，当超过threshold时才去调整本地时钟。gptp调整的时钟（gptp时钟），是与网卡时钟源同一层级的时钟树端点，在linux上一般会抽象成设备，也就是/dev/ptpx；在使用硬件时钟戳时，当网络报文发送或者接收时的采样点到达时，会从gptp时钟上获取时间戳。采样点如下图所示：

额外：上图不仅仅展示了采样点，还展示了latency，如果是为了追求超高精度的时钟同步，需要将ingress_latency和egress_latency在实际计算时进行补偿。

gptp报文格式略微复杂，在这里不再具体展开，对于了解gptp原理的角度来说，可以暂时不用关注报文格式。