AUTOSAR基础篇之CanTsyn

mizhongquan

前言

首先，请问大家几个小小问题，你清楚：

你知道为什么需要进行时间同步吗？

时间同步的应用场景有哪些呢？

当前主流的时间同步方案有哪些吗？

对于CAN 时间同步的协议又是怎样设计的呢？

今天，我们来一起探索并回答这些问题。为了便于大家理解，以下是本文的主题大纲：



正文

为何需要时间同步

时间同步，顾名思义就是用来保证多方在同一时刻使用的都是全局且一致的时间戳。随着自动驾驶的浪潮日益高涨，中央集中式架构越来越成为主机厂更为青睐的选择。

既然选择了中央集中式架构，就同时意味着整个架构中会存在多种不同传感器数据的融合，而完成数据融合的一个基本前提就是各个传感器传过来的数据需打上对应的时间戳，为了保证各传感器使用的时间戳一致性，就必然需使用时间同步方案来保证各个传感器的全局时间基准是唯一的。

讲清楚了为什么需要时间同步，怎么选择合适的时间同步方案同样是各个主机厂或者Tier1需要仔细考虑的问题，当前对于ADAS领域的时间同步大体可以分为如下几种，见如下图1：



图1 时间同步方案比较
因此，基于上述几大常见的时间同步方案的区别，我们需要从我们实际的应用场景，精度要求，系统设计等方面综合分析来选择合适的时间同步方案。

本文将主要讲解AUTOSAR时间同步方案，并以CANTsyn时间同步方案为例来介绍AUTOSAR时间同步协议的整个过程，对于AUTOSAR的以太网时间同步等方案基本一致，大家可以举一反三，触类旁通。
Can Tsync 协议框架

首先介绍下整个Can Tsync的整个协议栈框架，主要包含以下两个方面，一个是协议软件架构，这部分主要描述了Can 时间同步的协议栈组成；另一个则是协议初始化，此部分则用来描述使用该协议之前必须要做的初始化工作。

协议软件架构

如下图2所示描述了整个Can 时间同步方案的协议栈软件架构：



图2 CAN时间同步协议软件架构
在上图中我们看到AUTOSAR时间同步方案又可以根据传输传输介质的不同分为如下四种时间同步方式：

CAN TimeSync：基于CAN总线完成时间同步；

FR TimeSync：基于Flexray总线完成时间同步；

Eth TimeSync：基于车载以太网完成时间同步；

CDD TimeSync：基于其他外设驱动完成时间同步；

其中CAN 时间同步过程由如下模块Can Driver, Canif，Can Tsync，StbM组成，三个软件模块各司其职，进而完成基于CAN的时间同步，具体分工如下：

Can Driver：提供CAN接收与发送能力；

Canif：负责发送或接收承载着时间同步信息的报文；

Can Tsync：负责时间同步协议的实现；

StbM：负责抽象基于不同传输介质的AUTOSAR时间同步协议，为整个软件系统来提供时间同步之后的全局时间戳；

协议初始化

基于Can的时间同步协议初始化包含如下过程：

执行CanTSyn_Init()函数来完成内部变量的初始化与内部状态的初始化；

当未执行CanTSyn_Init()函数却调用了CanTsync模块其他除去获取版本号的函数就会上报Det错误；

Sequence Counter必须初始化为0；

CAN Timesync 报文格式

SYNC and FUP Message

如下图3所示为SYNC Message 与 FUP Message的报文格式，这两类报文应成对存在，DLC为8，两类报文都共用同样一个CAN ID。



图3 SYNC and FUP 报文格式
Offset Message

如下图4所示为Offset Message中的OFS 与OFNS Message的报文格式，这两类报文应成对存在，DLC为8，两类报文都共用同样一个CAN ID。



图4 OFS and OFNS的报文格式
Time Master

所谓“Time Master”就是主时钟的意思，不过该主时钟也是要在一定时钟域内的主时钟，因为主时钟的定义可以是相对的 。

如下图5所示清楚描述了在AUTOSAR时间同步策略中几种时钟角色：



图5 AUTOSAR 时间同步节点
从上图中我们可以看到在一个Time Domain中存在如下三种时间同步节点：

Time  Master：在同一Time Domain中提供全局时间基准的主时钟；

Time Gateway：在同一Time Domain中既作为上级时钟源的从时钟，又同时作为网关域内的主时钟源；

Time Slave：在同一Time Domain中作为需要同步的从时钟对象；

如果Time Master是全局时间基准的拥有者，那么该Time Master就被称为Global Time Master。Time Gateway一般作为网关域内的多个Time Slave的主时钟。

SYNC and FUP 报文处理流程

时间同步的过程发生在Time Master与Time Slave之间，Time Master通过发送带有全局时间信息的SYNC 报文与Followup 报文对，Time Slave通过接收并处理这两类报文进而完成与Time Master的时间同步，大家就这样把各自的时钟表也对上了。

同时SYNC与FUP 报文在发送过程存在诸多细节需要密切关注，否则很有可能造成时间同步无效。

在同一Time Domain中SYNC 报文与FUP 报文必须成对出现才能够成功完成一次时间同步；

Time Master中SYNC报文发送出去之后，如果在等待CanTsyn_Txconfirmation()超出一定时间，该时间通过参数 CanTSynMasterConfirmationTimeout来设定，那么Time Master应当主动重置内部状态并开启一次新的SYNC 报文发送（超时时间需比SYNC与FUP之间的时间间隔以及FUP与SYNC之间的时间间隔两者中的最小时间还要短）；

Time Master应按照参数CanTSynGlobalTimeTxPeriod的周期限定来完成SYNC报文周期性发送；

SYNC跟FUP序列不能被打乱，即使是同一Time Domain也不例外；

通过参数CanTSynGlobalTimeTxCrcSecured来确保SYNC跟FUP报文是否需要添加CRC保护，是否添加CRC保护将决定同步报文中的第一个字节的值，如下图6所示：

图6 SYNC/FUP报文与CRC关系

通过参数 CanTSynGlobalTimeTxFollowUpOffset来控制SYNC报文发送之后触发FUP 报文的时间间隔；

Offset Message报文处理流程

Offset Message报文处理流程与上述流程基本相似，概括起来可以表述为以下几点：

在同一Time Domain中，每次Offset Message序列均由OFS Message与OFNS Message组成且必须成对出现；

Time Master中OFS报文发送出去之后，如果在等待CanTsyn_Txconfirmation()超出一定时间，该时间通过参数 CanTSynMasterConfirmationTimeout来设定，那么Time Master应当主动重置内部状态并开启一次新的OFS 报文发送（超时时间需比OFS与OFNS之间的时间间隔以及OFS与OFNS之间的时间间隔两者中的最小时间还要短）；

Time Master应按照参数CanTSynGlobalTimeTxPeriod的周期限定来完成OFS报文周期性发送；

OFS跟OFNS序列不能被打乱，即使是同一Time Domain也不例外；

通过参数CanTSynGlobalTimeTxCrcSecured来确保OFS跟OFNS报文是否需要添加CRC保护，是否添加CRC保护将决定同步报文中的第一个字节的值，如下图7所示：

图7 Offset Message与CRC关系

通过参数 CanTSynGlobalTimeTxFollowUpOffset来控制OFS报文发送之后触发OFNS报文的时间间隔；

传输模式

AUTOSAR 时间同步方案可以通过标准API函数CanTSyn_SetTransmissionMode(Controller, Mode) 来完成针对CAN时间同步报文的发送请求控制。

当Mode == CANTSYN_TX_OFF，所有在该对应物理CAN通道上的时间同步报文发送请求均将被舍弃；

当Mode == CANTSYN_TX_ON,    所有在该对应物理CAN通道上的时间同步报文发送请求均能够被正确处理；

报文装配流程

1.Global Time Calculation

如下图8所示，我们可以通过时序图能够清晰看到作为Time Master 装配SYNC/FUP报文的完整流程。



图8 SYNC/FUP报文装配时序图
如果是基于SYNC Time Base，根据上图具体装配过程可拆解成如下几个步骤：

发送SYNC报文中通过函数StbM_GetCurrentTime()来获取T0的秒部分，T0= SyncTimeSec，同时通过函数StbM_GetCurrentTimeRaw()获取T0raw的原始值；

在得到发送SYNC报文的Txconfirmation的过程中通过调用函数StbM_GetCurrentTimeDiff()来获取与T0raw之间的时间间隔，然后将T4 = T0ns + T0diff的ns部分通过FUP报文发送出去；

如果T4 >= 1秒，那么将T4的秒部分写入到OVS位中，T4的ns部分则写入SyncTimeNSec中；

通过上述步骤的SYNC/FUP报文的装配发送过程，我们就可以知道当前Time Master发送出去的全局时间基准为T0+T4。

如果是基于Offset Time Base，那么装配过程如下图所示：

通过函数StbM_GetOffset()获取秒部分，并写入到OfsTimeSecLsbLo，OfsTimeSecLsbHi，OfsTimeSecMsb中；

将Offset Time Base的ns部分写入到OfsTimeNSec中；

2.OVS Calculation

在FUP报文发送的过程中如果存在Time Master的ns的范围（uint32），那么溢出的秒部分应填入到OVS域。

3.SGW Calculation

如果StbM模块中的timeBaseStatus中的STBM_SYNC_TO_GATEWAY bit位没有置位，那么SGW就应该设置为SyncToGTM=0，否则应该设置为SyncToSubDomain=1。

4.Sequence Counter Calculation

在每一个Time Domain中，该Sequence Counter(简称SC)应按照0-15依次循环，SYNC报文与OFS报文的SC每发一次报文就只能依次加1，同时FUP与OFNS报文中的SC应分别与SYNC及OFS报文一致，依次递增。

5.CRC Calculation

如果针对时间同步报文均配置了CRC，那么采用的统一的CRC算法为 Crc_CalculateCRC8H2F()，其中CRC算法中的初始值为0xFF,CRC多项式为0x2F，CRC最终XOR值应为0xFF, 其中CRC的计算范围为SYNC/FUP报文中Byte2-Byte7再加上配置的DataID值，该DataID值与SC Counter一一对应，DataID的值由DataIDList[SC]来决定。

综上所示，上述几个过程会按照如下的先后顺序来进行：

在FUP报文中计算OVS；

在FUP报文中计算SGW；

计算SC；

拷贝所有的数据至相应的报文位置；

计算CRC；

Time Slave

Time Slave作为被同步的对象，仅需通过接收 SYNC/FUP报文便可以跟Time Master同步上时间，获得最新同步的全局时间基准。

SYNC and FUP 报文处理流程

对于接收Time Master发出的SYNC/FUP报文的Time Slave，为了保证时间同步信息的准确性，有必要对输入的时间同步报文信息进行一系列的检查，如下是常见的Checklist：

如果参数CanTSynRxCrcValidated配置成CRC_VALIDATED，那么就只能接收0x20的SYNC报文，其他报文将会忽略；

如果参数CanTSynRxCrcValidated配置成 CRC_NOT_VALIDATED，那么就只能接收0x10的SYNC报文，其他报文将会忽略；

如果参数CanTSynRxCrcValidated配置成 CRC_IGNORED，那么可以接收0x10或者0x20的SYNC报文，其他报文将会忽略；

如果参数CanTSynRxCrcValidated配置成CRC_VALIDATED，CanTsyn模块仅接收一定SC的ID为0x28的FUP报文，其他报文将会忽略；

如果参数CanTSynRxCrcValidated配置成CRC_NOT_VALIDATED，CanTsyn模块仅接收一定SC的ID为0x18的FUP报文，其他报文将会忽略；

如果参数CanTSynRxCrcValidated配置成CRC_IGNORED，CanTsyn模块仅接收一定SC的ID为0x28或者0x18的FUP报文，其他报文将会忽略；

针对每一个Time Slave，CANTsyn模块需配置参数CanTSynGlobalTimeFollowUpTimeout来完成针对SYNC报文之后FUP报文的接收超时时间阈值且内部状态被重置准备接收新的SYNC报文；

当一个完整有效的SYNC/FUP报文接收之后，便会调用函数 StbM_BusSetGlobalTime() 来完成全局时间基准的对齐；

Offset Message报文处理流程

与SYNC/FUP报文类似，Offset Message的OFS/OFNS报文对于Time Slave对象也需要进行如下一系列的检查：

如果参数CanTSynRxCrcValidated配置成CRC_VALIDATED，那么就只能接收0x40的OFS报文，其他报文将会忽略；

如果参数CanTSynRxCrcValidated配置成 CRC_NOT_VALIDATED，那么就只能接收0x30的OFS报文，其他报文将会忽略；

如果参数CanTSynRxCrcValidated配置成 CRC_IGNORED，那么可以接收0x40或者0x30的OFS报文，其他报文将会忽略；

如果参数CanTSynRxCrcValidated配置成CRC_VALIDATED，CanTsyn模块仅接收一定SC的ID为0x48的OFNS报文，其他报文将会忽略；

如果参数CanTSynRxCrcValidated配置成CRC_NOT_VALIDATED，CanTsyn模块仅接收一定SC的ID为0x38的OFNS报文，其他报文将会忽略；

如果参数CanTSynRxCrcValidated配置成CRC_IGNORED，CanTsyn模块仅接收一定SC的ID为0x48或者0x38的OFNS报文，其他报文将会忽略；

针对每一个Time Slave，CANTsyn模块需配置参数CanTSynGlobalTimeFollowUpTimeout来完成针对SYNC报文之后FUP报文的接收超时时间阈值且内部状态被重置准备接收新的OFS报文；

当一个完整有效的OFS/OFNS报文接收之后，便会调用函数 StbM_SetOffset() 来完成全局时间基准的对齐；

报文解析流程

1.Global Time Calculation

如下图所示9所示清晰地描述了作为Time Slave如何接收SYNC/FUP报文并最终完成全局时间基准同步的过程：



图9 SYNC/FUP报文接收时序图
如果是基于SYNC Time Base，根据上图具体装配过程可拆解成如下几个步骤：

当接收到SYNC报文之后，获得到T0时间，此时通过调用函数 StbM_GetCurrentTimeRaw()获得当前的T2raw;

当接收到FUP报文之后，便可以从FUP报文获取T4=（OVS+SyncTimeNSec），同时调用StbM_GetCurrentTimeDiff()基于T2raw来获取两者之间的时间差T3diff = （T3raw-T2raw）；

Time Slave同步之后的全局时间基准为 (T3raw - T2raw) + (T0 + T4)；

如果是基于Offset Time Base，根据上图具体装配过程可拆解成如下几个步骤：

将Offset time base的秒部分同步至OfsTimeSecLsbLo, OfsTimeSecLsbHi，OfsTimeSecMsb这三个区域；

将Offset Time base的ns部分同步至OfsTimeNSec；

2.OVS Consideration

对于Time Slave对象，在FUP报文中必须考虑到OVS的秒部分，并最终参与到全局时间同步基准的计算过程中。

3.SC Validation

针对Time Slave对象，Sequence Counter(SC)必须先完成如下检查，才会正确接收到SYNC/FUP时间同步报文序列：

在同一Time Domain内的同一SYNC/FUP报文序列的SC应始终保持一致，如果不一致，那么之前接收到的SYNC报文将会被丢弃，收到的FUP报文也会被丢弃；

在同一Time Domain内的同一OFS/OFNS报文序列的SC应始终保持一致，如果不一致，那么之前接收到的SYNC报文将会被丢弃，收到的FUP报文也会被丢弃；

在前后两个SYNC/OFS报文的SC的间隔不能超过参数配置CanTSynGlobalTimeSequenceCounterJumpWidth的值，设置为0则不被允许；

由于Time Slave与Time Master两者启动的不同步性，因此对于Time Slave对象，针对首次接收SYNC/OFS报文中的SC值不做任何要求，保证能够正常接收并处理；

4.CRC Validation

如果针对时间同步报文均配置了CRC，那么采用的统一的CRC算法为 Crc_CalculateCRC8H2F()，其中CRC算法中的初始值为0xFF,CRC多项式为0x2F，CRC最终XOR值应为0xFF, 其中CRC的计算范围为SYNC/FUP报文中Byte2-Byte7再加上配置的DataID值，该DataID值与SC Counter一一对应，DataID的值由DataIDList[SC]来决定。

值得注意的是Time Master与Time Slave的DataIDList应始终保持一致，否则CRC计算的结果就没法保持一致，报文就不能够被Time Slave对象正常接收处理。

综上所述，时间同步报文的解析过程总体而言可以分为如下几个基本步骤：

根据CanTSynRxCrcValidated参数来决定是否接收对应的SYNC/FUP报文；

SC应该匹配成对应的期望的值；

接收到的Time Domain应与内部设置的Time Domain匹配上；

FUP/OFNS报文中的ns部分不应超出指定的范围（uint32）;

CRC的计算结果应保持一致；

最终计算出最新的全局同步时间基准；

开垦者

好的，针对您提供的帖子内容，作为汽车工程师的我，回复如下：

AUTOSAR基础篇之CanTsyn前言

关于时间同步的问题，现进行简要解答：

时间同步是为了确保多个系统或组件在同一时刻使用全局一致的时间戳，这是实现协同工作的基础。在汽车行业，尤其是自动驾驶领域，时间同步至关重要。

时间同步的应用场景广泛，包括但不限于自动驾驶系统的传感器数据融合、车辆控制系统间的通信以及ECU间的数据交互等。

当前主流的时间同步方案包括GPS、NTP及PTP等。这些方案均具有较高的准确性和稳定性。

CAN时间同步协议设计旨在确保CAN网络中的消息传输具有一致的时间基准。它通过特定的同步信号和算法，确保所有节点在发送和接收消息时都能达到时间同步。

后续将详细阐述为何需要时间及具体的应用场景、时间同步的实现方式等。

以上内容仅为简要回复，后续将深入探讨相关内容。

落叶纷飞

尊敬的各位同仁，关于AUTOSAR基础中的时间同步技术，我有幸为大家简要介绍。时间同步在分布式系统中尤为关键，它能够确保系统各部分都遵循一个统一的计时基准，以实现信息的精准传递和协调控制。在汽车系统中，其应用场景广泛，如控制单元间的通信、车辆安全系统等。目前主流的时间同步方案包括GPS同步、硬件时钟同步等。而CAN时间同步协议设计主要基于报文传输，确保精确的时间同步。针对中央集中式架构的选择，时间同步更是不可或缺的一环，因为它能够确保各节点间的时间一致性，从而保证整个系统的稳定运行。更多细节与技术实现，我会在接下来的文章中为大家深入解读。希望我们共同探讨、学习，推动汽车技术的进步。

lixinfu

作为一名汽车工程师，对AUTOSAR技术有所了解，时间同步在汽车电子技术中具有关键作用。以下为对帖子的回复：

关于时间同步的问题，其重要性在于确保汽车内部各个系统在同一时刻使用全局一致的时间戳，这是实现精确控制和协同工作的基础。时间同步的应用场景广泛，包括自动驾驶、车辆通信等。当前主流的时间同步方案包括GPS、NTP等。至于CAN时间同步协议，它是基于CAN总线设计的，旨在确保数据传输的实时性和准确性。下文将深入探讨这些问题，并解释为何选择中央集中式架构需要重视时间同步技术。

对于AUTOSAR系统而言，时间同步是实现模块间协同工作的关键，也是保证系统稳定性和可靠性的重要因素。在接下来的文章中，我们将详细解析时间同步的实现原理及其在AUTOSAR系统中的应用。