分析了40个BUG后对“时间同步”的总结

myhomer

外部授时的应用背景

智能网联汽车需要与车外系统进行信息交互。

车外系统的交互包括诸如车端向TSP的事件上报、信号上报；远控事件，车端与云端、手机端之间的信息交互；安全证书的有效期认证；蓝牙钥匙的使用期间授权；V2V之间交互；V2I之间交互等等。

广义上，车内HMI大屏显示的时间也算是车端与外部乘员系统的信息交互。

在进行信息交互时，车端的时钟系统与需要与车外的时钟系统对齐基准时间，也即遵循相同的时钟体系，以便在时间维度定位事件。

外部授时的场景

在某些初始场景，如整车断KL30电后上电，或整车深休眠->唤醒，车内的基准时钟会紊乱，维护为一个错误的起始时间。比如常见的1970/1/1 0:00:00。

这个时候就需要由外界的时间源给车端的时钟进行授时。

外部时钟源

车端通常使用的外界授时时钟源包括：GNSS原子时、NTP时间、TSP时间、NITZ时间。

GPS原子时是通过GPS卫星播发的原子时，通常视为最高精度时间源，具有最高的授时优先级；车端需要具备GPS接收机，通过GPS接收机接收到GPS信号以解算出该原子时。

NTP时间是由NTP服务端提供的网络时间；精度次于GPS原子时间，且其时钟稳定性依赖于所使用的NTP服务器的稳定性。车端需要能够通过蜂窝网络访问NTP服务器以获取到NTP时间；

NITZ为基站所提供的时间；精度次于NTP时间。车端需要具备蜂窝通信模组与基站进行空口交互以获取该时间；

TSP时间为车企自行维护平台的时间，其时间源多为NTP时间，所以本质是NTP时间。

除外部授时源外，车端自身通常使用RTC芯片在浅休眠->唤醒时用于恢复时间。

举个例子说明外部授时

车端的外部授时，可以类比这样的场景。

一个人喝断片了，然后被关在小黑屋里睡觉。小黑屋里没有钟表。

这个人睡醒后，不知道今夕是何年何月何日 几时几分几秒。

他怎么才能知道现在的真实时间呢？

他可以选择拿起座机电话（是的屋子里有个座机电话，视为接受外部授时的通道）给一个他信得过的人打电话，实时获知当下的时间。

于是就完成了来自外部的授时。

时间维持

这个人得知了真实时间，他可以选择一直不挂断电话，一直问询电话对端当下的真实时间，以便于维持小黑屋里的时钟系统。

他还有另外一种选择，就是自己维持时间的递增。

比如，这个人找到了个有电的秒表（是的屋子里有个秒表，作为维持时相对时间的工具），于是他记下当下的时间后，然后开始启动该秒表。

这个时候他就可以挂断电话了，因为如果想知道当下的时间，只要用 他记录的那个时间 + 秒表显示已经走的秒数，即可计算得到当下的时刻。

车内域间时间同步

车内系统与车外系统需要对齐时间。车内各域控之间也需要对齐时间。

车内各域控制器独立分布，域控之间通过以太网、CANFD等实体总线进行联结和通信。各域控都有自己的一个时钟，且在上电运行时，都有精准维持自己时钟的能力，用于域内交互时对信号事件等标注上相应的时间戳。

可以想象下各个域控系统都有自己的一块手表，每块表都是相对比较精确地逐秒累加时间；但在同一时刻，各个系统的手表报的是不同的时间值。

在对每个信号事件标注时间戳的时候，同一时刻的时间戳是凌乱的，这样跨域间对时间敏感的业务无法正常运行，无法通过多域各自打印的日志分析排查问题。

所以车内每个域控都需要对齐时钟，也即统一时间基准。

由于获取外部时间需要诸如蜂窝通讯、GPS信号接收能力等，所以不是每个域控都会与外界授时源交互获取授时。

车端通常会选取一个主时钟，用于与外界时钟系统进行时间的对齐，也即外部授时。再由被外部可靠时钟源授时后的主时钟对域内各控制器进行车内的时间同步。

举个例子，说明车内域间时间同步

还是被关小黑屋的那个人A。

他发现屋里还有另一部电话。拿起来拨打后对方接了起来。原来是他另一个一起喝断片的朋友B，现在被关在了另一个小黑屋里。

这个B的小黑屋里没有外线电话，只有3部内线电话，一部是通朋友A，另外2部分别通另外两个一起吃饭喝断片的朋友C和D。

C和D分别只有一部内线电话，拿起来只能和B通话。 结构如下这种：



注：一起喝断片的ABCD

“

外面的世界，即外部UTC时间系统

小黑屋们，即失去了正确时间基准的车内时间系统

外线电话，即可获得外部授时的能力通道

内线电话，即车内域间时间同步的能力通道

A房间，有外线+内线电话，即车内的主时钟

B房间，可以与多个房间进行通话，不同房间之间无法直接通话，即B房间为域内的网关域控

C房间和D房间，分别对应 车内的非主时钟、非网关的域控

”

A通过和B的内线电话告诉了B当前的时刻，B知道后，拿起和C、D两人小黑屋连线的内线电话，告知C、D当前的时间。

经过这番操作，ABCD四人完成了粗糙的时间同步。（之所以粗糙是因为未消除传输延时）。

车内域间时间同步故障来源

由上图可知，末端域控节点获取同步时间的链路存在多个环节。某时间同步系统的下游节点出现错误时间（域控时间与UTC时间存在偏差），可能的原因很多，并非完全是主时钟时间源错误所致。

比如可能的原因有：

主时钟时间源错误



系统功能设计失效

硬件异常故障

软件基础库异常故障

授时时间源时间异常

车辆出现过异常工况 （如断kl30） && 无蜂窝网络无法获得ntp时间 && 封闭空间无法获得GNSS授时（此看似极端场景在研发阶段经常出现）

报文播发异常


网关转发异常



主时钟节点-网关节点物理链路/协议链路异常

网关转发报文异常

网关处理时间报文逻辑异常


下游节点接收异常



网关节点-下游节点物理链路/协议链路异常

下游节点接收报文异常

下游节点处理时间报文逻辑异常

下游节点应用层获取时间报文链路异常

下游节点应用层展示时间处理逻辑异常

作为主时钟的功能owner，比较头疼的是但凡下游节点出现时间显示异常的现象，就被按头分析。有些时候是主时钟问题，有些是下游逻辑或链路问题，有些时候是使用场景问题。

断电断网在地库，喊破喉咙也没有人来授时。

这也是我写这篇文章的初衷，希望更多的汽车工程师了解时间同步的大致逻辑，以便更好地识别问题。

车内时间同步的环节

在智能网联汽车上，时间同步这个业务包括如下环节：

  1. 整体

    a. 外部不同时间源授时：授时能力、优先级仲裁

    b. 域间时间同步：同步通道CAN、gPtp等

    c. 不同业务对不同时间源的选取及使用逻辑

  2. 主时钟

    a. 接受多源授时能力

    b. 多源使用逻辑

    c. 多板板间的时间同步

    d. 板上的时间维持

    e. 特殊电源模式下时间恢复机制

    f. CAN、gPtp报文播发

下面选取一些主要环节进行说明。

整车层面，不同业务对不同时间源的选用逻辑

通常的设计方案，整车各域控使用相同的时间源。也即，各域控上的各个业务使用相同的时间基准，共源。

该共源时间源的最高优先级通常指定的是 最高精度的GPS原子时间。只要满足GPS时间获取的条件，就更新时间源为GPS时间。

也有部分OEM根据实际业务需要，选择TSP的时间作为时钟源。

选用TSP的时间是由于车端大部分与外部系统进行交互的时间敏感业务多需车端与TSP的时间对齐，如远控、车辆使用授权等。

TSP使用的时间源为NTP时间，精度不如GPS原子时间，但足以支撑业务。对于NTP服务器极小概率偶发崩溃等情况的应对，践行的是“要错一起错”的准则。

选用不同时间源的根本目的，是为了实现不同业务 向不同对端时间系统的对齐。

有的业务更倾向于对齐TSP时间，有的业务更倾向对齐GPS时间。所以可以考虑多源授时，多源同步的方案。

不同时间源切换所带来的时间跳变

不同时间源进行切换可能会带来毫秒级乃至秒级的跳变。对于从特殊工况中完成首次被授时的时间恢复，可能出现非常大幅度的跳变。

跳变可能向已经发生过的时间跳变，也可能向尚未发生的时间跳变。

回跳是个比较令人头疼的场景。会导致产生数据顺序上报、记录类的业务出现相同时间戳的不同日志；对于一些有严格时序要求的业务，会造成功能失效的情况。

所以在设计功能逻辑时，对于时序有严格要求的业务需要使用单调时钟（系统滴答）以保证时间不会会跳，避免使用墙上时钟以免出现回跳导致的失效。

gPTP机制

下面大致介绍下基于gPTP（IEEE802.1AS）总线的同步机制。

gPTP是一种基于以太网总线的标准的时间同步机制。运行在MAC层，距离物理层近可以减少运行在上层所引起的延时及不确定性，减少传输时延。gptp可以实现各域节点之间ns级别的时间同步。

在gPTP域内，需要指定一个gptp节点作为主时钟（Master），其他gptp节点作为从时钟（Slave）。主时钟通过播发gptp报文的方式实现对其他从时钟节点的时间同步。

提到gPTP就少不了提到PTP。gPTP是基于PTP协议的衍生强化版，两种协议适用不同的硬件环境及用途。

PTP与gptp协议的区别。

面向工程人员的区别主要体现在报文发送内容、报文发送顺序存在区别，gptp比ptp多了delay_resp_follow_up的报文，抓包需要参考不同协议进行分析理解。

原理上的区别是gPTP增加测量了主从端口的时钟频率的偏差，即增加了时钟频率换算系数的计算，而PTP的报文交互未见此环节。

PTP与gPTP的区别详见：https://blog.csdn.net/weixin_43408952/article/details/125082433。

gPTP协议的报文流程交互相比于PTP更为复杂，报文的交互逻辑，具体可查看张大侠专栏：https://zhuanlan.zhihu.com/p/101003490。写的很清楚。

PTP 的钟差以及时延测量逻辑

此处以PTP协议报文的发送内容来理解主从之间clockoffset和pathdelay的测量方法。

PTP时间同步有两个前提。一是主从分别有自己维护的时钟系统，且可准确实现相同时间步长的时钟自增；二是从时钟聪明地知道传输过程有时延，且默认双向时延相同。

报文发送流程图示意如下：



具体的交互逻辑及意图描述如下：

1.起始，主从时钟各自维护自己的时间基准；

2. t1时刻主时钟向从时钟播发sync报文，通知进行同步；从时钟在t2时刻接收到该sync报文指令；

3. 主时钟随后播发follow_up报文，报文payload中携带上一条sync播发对应的主时钟时刻；

4. 基于前述步骤，从时钟可知，在自己接收到sync报文的时刻所对应的主时钟的时刻；仅通过这两个时刻无法获知主从时钟之间的时钟差（clockoffset），因为该时间差包含了主->从的传输延迟（pathdelay）。

因此下一步即从时钟需要探测pathdelay是多少。

5. 在一定时长后（这里举例5 min，实际为ms级），在t3时刻，从时钟向主时钟发送探测pathdelay的delay_req请求；

6. 主时钟在 t4 时刻接收到从时钟发送的delay_req请求，然后发送响应报文delay_resp。该报文的payload携带了t4这个时刻；

7. 通过上述两步骤，t3 和 t4 这两个时间差包含了 主从之间的时钟差及从->主的传输延迟 pathdelay；

8. 此处默认 主->从 和 从->主 的链路传输延迟是相同的。

9. 从时钟基于上述的t1-4数据，可计算得到与主时钟之间的clockoffset 以及 主从之间的传输延迟pathdelay。

clockoffset用于从时钟的系统时钟校准，pathdelay用于以太网switch转发数据包时的时间差补足。

PTP机制的拟人化理解



接下来介绍下作为主时钟域控实现域内板间时间同步。

板间同步的必要性

主时钟需要具备多种对外播发时间同步数据的通道。介质多为CAN 和以太网，报文分别为CAN报文和GPTP报文。

CAN总线时间同步采用 Autosar的TimeSync协议机制。以太网总线时间同步采用GPTP协议机制。

CAN总线和以太网总线两条时间同步通道并行，一是互为灾备冗余，二是面向不同总线节点。

但不论通过哪条总线对外播发时间同步的消息，主时钟播发的CAN报文和gptp报文上的payload时间数据体都应该是相同的。

CAN报文播发和gptp报文播发功能通常分别由MCU和MPU承接。MCU和MPU之间需要实现有效的时间同步，以保证通过不同通道播发的时间数据是一致的。

板间同步的困难点

在异常场景时间恢复时，由于MCU的快速启动及低功耗等特性，多使用MCU上挂接的RTC用于MCU系统的时间恢复。

MPU侧多用于承接外部授时源的授时。但在初始场景，MPU侧通常是需要从MCU侧快速获取时间，并基于当前场景形成判断逻辑确认进入哪一种授时源的授时，以避免多次低优先级的授时源授时而引起多次跳变。

MPU完成外部授时后，需要对MCU侧再进行时间校准以消除MCU RTC恢复MCU系统时间所引起的与MPU系统时间之间的误差。

MCU与MPU之间的时间同步存在系统延迟误差。该误差可能固定可测量出具体数值用于标定补偿，也可能随机不可测不可标定。

实车的使用工况还包含KL30断电冷启MCU RTC时间丢失、地库内无GNSS信号无法获取GPS时间、无蜂窝网络无法获取NTP授时等各种场景，还需要考虑读取RTC失败等偶发电器故障等。

所以主时钟域内的板上及板间 时间恢复、时间同步与反向同步、时间有效性判断、时间维持、外部授时源缺失、休眠期间时间维持、休眠时间写入等，都是需要考虑和设计。

一句话总结即是 MCU和MPU之间的时间同步逻辑非常复杂。是我迄今经手过的烧脑排行前几的系统功能方案。

本想稍微展开写一点，但一展开就写的不只一点了。就变成系统功能规范了。所以就先到这了。

以上即是我对时间同步的理解。存在偏颇之处烦请专家指正。