转载：一文读懂AUTOSAR CAN时间同步

最新推荐文章于 2025-02-24 16:23:31 发布

小学生Yi

最新推荐文章于 2025-02-24 16:23:31 发布

阅读量4.9k

点赞数 8

分类专栏：时间同步文章标签：其他

原文链接：https://zhuanlan.zhihu.com/p/335715420

版权

时间同步专栏收录该内容

2 篇文章

订阅专栏

首发于 AUTOSAR规范从入门到放弃

无障碍写文章

一文读懂AUTOSAR CAN时间同步

FredXu

自动驾驶从业者

创作声明：内容包含虚构创作

35 人赞同了该文章

汽车上的各个ECU基本都是实时性非常强的控制器，在关联ECU之间或ECU内部各个软件模块之间通常需要在大致同步的时间节拍上运行，特别是在某些高速场景，些微时间的偏差可能引发的后果是灾难性的。以ADAS系统为例，感知模块检测到一个障碍物，控制决策模块需要知道这个障碍物是在什么时间检测到的，以此作出响应。如果感知模块和控制模块都在一个控制器内还好，延时不会很大，若是分布在不同的控制器中，感知模块发送的障碍物信息携带的时间戳与实际检测到的时间偏差太大，那么等控制模块作出响应时，可能汽车已经撞到障碍物上了。所以，时间同步显得尤为重要，各个ECU之间要有一个一致的时钟Global Time (GT)来提供相对准确、精度足够的绝对时间值，并且将此时间同步到各个ECU。

AUTOSAR定义的基于CAN总线时间同步的CanTSyn模块处理CAN总线上的时间信息分发，它以广播的形式将时间信息从master节点(TM) 传输到各slave节点(TS)，还可通过时间网关（TW）将时间同步到其他子网，以解决因各ECU节点的硬件时钟信号偏差、CAN总线传输延时如协议仲裁以及各ECU节点内的软件处理等原因导致的时间延迟。

1. CAN时间同步过程

CAN时间同步机制提出了两步机制：第一步：发送时间同步(SYNC)消息，第二步：发送时间跟随消息（Follow-Up FUP消息）。同步过程如下图所示（AUTOSAR规范）

step1. Master在t1r时刻先发送一个SYNC信号，但这个信号写的是之前要发送SYNC时的时间点(t0r)，然后在t2r时刻Slave接收到了这个SYNC信号。
step2. Master再次发送一个FUP信号，这个信号的内容就是他t1r-t0r的值。
step3. 最后在Slave方，我们就可以计算出本地当下的同步时间值=(t3r-t2r)+t1r。

以上过程，个人感觉还是不太直观，下面再进一步介绍时间同步过程：

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

Time Master在T_0时刻开始同步（如上图），同步过程如下：

（1）TM存储T_0时刻的秒时间s(T_0)和ns时间ns(T0)，并保存T_0时刻的定时器counter TCm为T_0_C；其中，ns时间是通过一个转换函数ns(T)将时间计数器计数值转换为对应的以ns为单位的具体时间，转换关系与具体的计数器硬件时钟频率有关；

（2）TM开始传输SYNC时间同步消息，消息中包含了T_0时刻的秒时间s(T_0)；

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

（4）TM计算传输时间T_TX = ns（T_0）+ ns(Tx_Stamp-T_0_C)，将counter转换为ns时间，然后开始传输FUP同步消息-包含ns时间T_TX；

（5）TS接收到FUP消息时计算此时的实际同步时间T_real = s(T_0) + T_TX + ns(TCs – Rx_Stamp)，TCs为接收到FUP消息时刻的定时器counter值。

2. CAN时间同步报文解析

SYNC消息和FUP消息共用一个CAN ID，分时发送，先发送SYNC消息，再发送FUP消息。

SYNC消息分为两种格式，Type=0x10为不安全的不带CRC校验的报文格式，对应FUP消息类型为0x18；Type=0x20为带CRC校验的安全报文格式，对应FUP消息类型为0x28。

Byte0：时间同步类型：0x20代表当前发送的是带CRC校验的TSync同步消息， 0x28代表当前发送的是对应0x20 SYNC消息的FUP同步消息；0x10代表当前发送的是不带CRC校验的TSync同步消息， 0x18代表当前发送的是对应0x10 SYNC消息的FUP同步消息；

Byte1：byte0为0x20或0x28时,Byte1为该消息的CRC校验值；

Byte2：高4位为时间同步域Time Domain；低4位为Sequence Counter，随发送次数循环累加；

Byte3：byte0为0x10或0x20时，Byte3为UserByte0；同步类型为0x28或0x18时，高5位保留， bit3 SGW为时间同步状态（0：SyncToGTM， 1：SyncToSubDomain），bit1-bit0 OVS为时间同步溢出时间overflow of seconds；

Byte4-Byte7为同步时间，同步类型为SYNC消息时为32bits 秒时间，同步类型为FUP消息时为30bits ns时间。

3. 实车环境下的CAN时间同步报文

如前所述，时间同步SYNC消息和FUP消息共用一个CAN ID，分时发送，先发送SYNC消息，间隔20ms再发送FUP消息，然后间隔480ms再发送SYNC消息进行下一次同步过程。

4. AUTOSAR CAN时间同步验收测试

发布于 2020-12-10 17:33

autosar

时间同步

赞同 35 14 条评论喜欢收藏申请转载

写下你的评论...

14 条评论

默认

最新

hedgehog

请问下autosar can的ACT测试具体测试什么内容呢？

01-22

吴少波

大佬，请问t0的作用是什么？为什么不直接用t1做时间同步？

10-14

fongdier

请问下autosar can的ACT测试具体测试什么内容呢？

然后是否能以一组报文实例讲解下Slave收到的同步时间计算，谢谢~

10-13

老二

ACT得测试内容看不清啊，具体哪些测试项，用什么测试工具或方法呢？

07-13

Test13

t3r时间详细解释一下

2021-12-28

FredXu

作者

t3r是TS节点接收TM发送的FUP报文时的本地时间戳，接收到之后本地的时间被同步未t1r+（t3r-t2r）;其中t1r由SYNC报文和FUP报文中的时间信息合并得到。

01-01

老二

FredXu

这样算来不还是少了一个SYNC报文得发送时间吗

07-13

羽道人

这样同步的精度能达到多少呢？

2021-12-28

羽道人

FredXu

是实测结果吗？这个协议主要是依赖于CAN的报文同步机制，但主节点的完成中断和从节点的接收中断都会引入误差甚至有的mcu采用的是FIFO队列来接收，各种情况考虑进来要实现ns级的同步岂不是要GHz的主频才能在一个指令周期内陷入中断然后处理？而且看资料用的计算单位是ns那从协议上就不支持高于ns的时间同步精度，对于100MHz的MCU理论上能到达的最高同步精度也就±100ns，如果是采用接收FIFO的MCU那时钟同步精度就差的很了...当然汽车上也不需要那么高精度的时钟同步...也可能我们理解不同，我理解的ns级时钟同步是±1ns，你说的ns级是1~1000ns [捂脸]