为什么需要时间同步，时间同步解决什么问题

• 时间同步技术就是为了解决精确获取传感器采样时间的，在以太网、CAN、Flexray总线上都有相应的实现。

• 时间同步信息以广播的形式从Master(TM)节点发送至各Slave节点(TS)，或者通过时间网关将时间同步信息同步至其他子网络，用于解决各ECU因硬件时钟信号偏差、总线仲裁、总线传输、软件处理等原因带来的时间延迟。

• 对于自动驾驶而言，通常需要摄像头、毫米波雷达、超声波雷达、激光雷达等传感器，而这些传感器的精确的数据采集时间是及其重要的，因为这些数据是感知和决策规划的输入。如果输入数据的时间不同步，可能会引起决策规划出错误的动作，导致车辆做出危险的动作。

• 汽车上的各个ECU基本都是实时性非常强的控制器，在关联ECU之间或ECU内部各个软件模块之间通常需要在大致同步的时间节拍上运行，特别是在某些高速场景，些微时间的偏差可能引发的后果是灾难性的。

• 以ADAS系统为例，感知模块检测到一个障碍物，控制决策模块需要知道这个障碍物是在什么时间检测到的，以此作出响应。如果感知模块和控制模块都在一个控制器内还好，延时不会很大，若是分布在不同的控制器中，感知模块发送的障碍物信息携带的时间戳与实际检测到的时间偏差太大，那么等控制模块作出响应时，可能汽车已经撞到障碍物上了。所以，时间同步显得尤为重要，各个ECU之间要有一个一致的时钟Global Time (GT)来提供相对准确、精度足够的绝对时间值，并且将此时间同步到各个ECU。

2.1 请求应答机制同步原理

主要过程分为四步：

（1）Sync，主时钟发出 sync 报文，并记录下 sync 报文离开主时钟的精确发送时间 T1;

（2）Follow_up，主时钟将精确发送时间 T1 封装到 Follow_up 报文中，发送给从时钟；

（3）Delay_Req，从时钟向主时钟，发送Delay_Req报文，用于方向传输延时计算，并记录发送时刻T3，主时钟收到该报文后，记录接收时刻T4；

（4）Delay_Resp，主时钟收到Delay_Req后，回复一个Delay_Resp的报文，将T4告诉从时钟。

以上的计算是基于主时钟和从时钟同步的场景，真实情况是主时钟和从时钟存在偏差，我们假设这个偏差为offset，即 T主-T从 = offset

在网络中，一般主-->从，从-->主 网络延时是一样；

T4 - T3 = delay - offset;

T2 - T 1 = delay+ offset;

因此传递的延时 :

delay = [(T2-T1) + (T4-T3)] / 2

由于offset存在，映射到从时钟 时间轴上计算offset:

offset = [(T2-T1) - (T4-T3)] / 2

2.2. 端延时机制同步原理

所谓的端延时机制，是在请求响应延时的基础上，增加pdelay_resp和Pdelay_resp_follow_up的计算，主要是为了进一步考虑上游链路的延时；

进而得到delay：

delay = [(T4-T3) + (T6-T5)] / 2

进而得到offset:

offset = (T2-T1) - {[(T4-T3) + (T6-T5)] / 2}

功能只有两个：

• 同步各个软件模块实体

• 提供绝对时间值

从右下角就是硬件时钟，也是整个同步系统的基石。但是因为隔一段时间超过最大值后就会溢出，所以需要一个Software Counter来记录这种溢出，然后一起产生了一个虚拟本地时间 (Virtual Local Time). 这个时间就没有溢出和跳跃了，也就是说很平稳的表达时间的流逝。

接下来是进行时间的矫正。接下来就可以产生一个同步的本地时间信号，之后就可以传递给其他的软件模块了。

• 时间主站通过时间同步消息将Global Time Bases分发到每个时域的连接时从站。

• Master 先基于本地时钟生成一个Global Time Base，根据这个Global Time Base会更新Master 的所有时间控制单元，之后打出时间戳，通过Message发出去

• Slave 端接收到 Message后，解析出时间戳，放到 Local Time Base 里，之后 Slave 的 Local Time Base模块会基于Slave的时钟跟新一个新的时间到 Local Time Base 里，最后更新 Slave 的所有时间控制单元。

• Slave 更新Local Time Base后传给SWC应用进行处理

• 第一步是TM发送SYNC信息，第二步是发送FUP(Timeadjustment message (Follow-Up)，时间调整信息)，第三步. 最后在Slave方，我们就可以计算出本地当下的同步时间值=(t3r-t2r)+t1r

• TM节点在t0r时刻调用接口发送SYNC信号，SYNC信号中包含的时间信息为t0r，在t1r时刻SYNC信号发送完成，此时的时间为t1r。TS节点在t2r时刻接收到了SYNC信号。

• TM节点再次发送FUP信号，信号中包含的时间信息为t4r=t1r-(st0r)，其中st0r=t1r-t0r，TS节点在t3r时刻接收到了FUP信号。

• 同步时间Time其实是时基【Time Base，秒s时间】和一个实时运行的32bit的定时器counter(TC)之和（会转换为纳秒ns时间）；Time Master将Time Base传输至Time Slaves。

• 在SYNC消息传输完成时，TM和TS同时捕捉存储各自的定时器counter计数值，分别记为Tx_Stamp和Rx_Stamp；

• TM计算传输时间M_TX = ns(T0r)+ ns(Tx_Stamp-T0rCounter)，将counter转换为ns时间，然后开始传输FUP同步消息-包含ns时间TX；

• TS接收到FUP消息时计算此时的实际同步时间 S_real = s(T0r) + M_TX + ns(TCs – Rx_Stamp)，TCs为接收到FUP消息时刻的定时器counter值。

SYNC 和 FUP 用一个 CAN-ID。

• 第一步，在SYNC报文中，塞入基于秒的时间，即所谓的t0r;

• 第二步，在FUP报文中，塞入基于纳秒的时间，即所谓的t4r = t1r - t0r，此时从节点知道，发送方真实的发送时刻为 t1r ，即t0r秒t4r纳秒，这样 从节点就可以得到当前真实的时间，current_time = t0r + t4r + t3r-t2r【这里t3r，表示计算时刻，从节点本地的时间】

• 在Slave收到SYNC的消息后，从 StbM_GetCurrentVirtualLocalTime 获取T2vlt时间，在收到FUP的消息后，从 StbM_GetCurrentVirtualLocalTime 获取T5vlt时间。

• 获取当前时间：

• 时间的矫正过程，并不改变各个在本地的运行时钟，而是动态改变本地时钟的实体变量。

• 时间纠正机制：Tv-Tvsync 保存从上次接收到的 Global Time 所经过的时间量。但它会受到本地硬件时钟漂移的影响。当从总线接收到新的 Global Time 时，Global Time 的 local instance 和接收到的 Global Time之间可能存在偏移。

• Rate Devision：指时间在本地时基和全局时基实例中以不同的速率前进。例如，如果本地硬件参考时钟由由于制造公差和/或热效应而导致频率关闭的晶体驱动，则可能会发生这种偏差。

• Time Offset：指时基的本地实例和全局时基没有精确同步。当本地硬件参考时钟的速率不准确并且与全局时基的同步受到抖动效应、软件延迟和计数器粒度的影响时，就会出现这种偏差。

• 因此，需要执行一种时间校正，如下图所示：

• offset Correction ：偏移校正校正绝对时间偏差（偏移）。根据偏移量的大小和 StbM 的配置，该校正可以通过跳跃校正或速率自适应来执行。偏移校正独立于速率校正。每次将时基的本地实例同步到其全球时基时都会执行此操作。

• Rate Correction：Rate Correction 的工作原理不是为了让它以正确的速率前进而调整本地硬件参考时钟。相反，速率校正仅在读取时实时校正时基的本地实例的值。

• rate Adaption ：速率校正校正本地硬件参考时钟的速率偏差。这种校正是通过一个乘法校正因子来完成的，该因子在时钟的预配置速率之外使用。速率校正确定测量范围内的校正因子。然而，该校正因子不是固定的，而是在每次成功测量后更新。

• Jump Correction 通过将偏移量添加到 Time Base 的本地实例（相当于接管 Global Time Base 的值），一步校正绝对时间偏移量。

版权声明：本文为CSDN博主「梅尔文.古」的原创文章

原文链接：

https://blog.csdn.net/xiandang8023/article/details/127719288