ptp/gptp
在车载,vehicle time使用gptp来做vehicle time的同步,gptp算是ptp的简化版,规范定义来源于IEEE 802.1AS,理论上可以达到ns级的误差。针对不通的ptp版本和gptp的对比如下:
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原理的角度来说,可以暂时不用关注报文格式。