首先,请问大家几个小小问题,你清楚:
今天,我们来一起探索并回答这些问题。为了便于大家理解,以下是本文的主题大纲:
时间同步,顾名思义就是用来保证多方在同一时刻使用的都是全局且一致的时间戳。随着自动驾驶的浪潮日益高涨,中央集中式架构越来越成为主机厂更为青睐的选择。
既然选择了中央集中式架构,就同时意味着整个架构中会存在多种不同传感器数据的融合,而完成数据融合的一个基本前提就是各个传感器传过来的数据需打上对应的时间戳,为了保证各传感器使用的时间戳一致性,就必然需使用时间同步方案来保证各个传感器的全局时间基准是唯一的。
讲清楚了为什么需要时间同步,怎么选择合适的时间同步方案同样是各个主机厂或者Tier1需要仔细考虑的问题,当前对于ADAS领域的时间同步大体可以分为如下几种,见如下图1:
因此,基于上述几大常见的时间同步方案的区别,我们需要从我们实际的应用场景,精度要求,系统设计等方面综合分析来选择合适的时间同步方案。
本文将主要讲解AUTOSAR时间同步方案,并仅CANTsyn时间同步方案为例来介绍AUTOSAR时间同步协议的整个过程,对于AUTOSAR的以太网时间同步等方案基本一致,大家可以举一反三,触类旁通。
首先介绍下整个Can Tsync的整个协议栈框架,主要包含以下两个方面,一个是协议软件架构,这部分主要描述了Can 时间同步的协议栈组成;另一个则是协议初始化,此部分则用来描述使用该协议之前必须要做的初始化工作。
协议软件架构
如下图2所示描述了整个Can 时间同步方案的协议栈软件架构:
在上图中我们看到AUTOSAR时间同步方案又可以根据传输传输介质的不同分为如下四种时间同步方式:
其中CAN 时间同步过程由如下模块Can Driver, Canif,Can Tsync,StbM组成,三个软件模块各司其职,进而完成基于CAN的时间同步,具体分工如下:
Can Driver:提供CAN接收与发送能力;
Canif:负责发送或接收承载着时间同步信息的报文;
Can Tsync:负责时间同步协议的实现;
StbM:负责抽象基于不同传输介质的AUTOSAR时间同步协议,为整个软件系统来提供时间同步之后的全局时间戳;
协议初始化
基于Can的时间同步协议初始化包含如下过程:
SYNC and FUP Message
如下图3所示为SYNC Message 与 FUP Message的报文格式,这两类报文应成对存在,DLC为8,两类报文都共用同样一个CAN ID。
Offset Message
如下图4所示为Offset Message中的OFS 与OFNS Message的报文格式,这两类报文应成对存在,DLC为8,两类报文都共用同样一个CAN ID。
所谓“Time Master”就是主时钟的意思,不过该主时钟也是要在一定时钟域内的主时钟,因为主时钟的定义可以是相对的 。
如下图5所示清楚了描述了在AUTOSAR时间同步策略中几种时钟角色:
从上图中我们可以看到在一个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所示:
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所示:
传输模式
AUTOSAR 时间同步方案可以通过标准API函数CanTSyn_SetTransmissionMode(Controller, Mode) 来完成针对CAN时间同步报文的发送请求控制。
报文装配流程
1.Global Time Calculation
如下图8所示,我们可以通过时序图能够清晰的看到作为Time Master 装配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,那么装配过程如下图所示:
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]来决定。
综上所示,上述几个过程会按照如下的先后顺序来进行:
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报文并最终完成全局时间基准同步地过程:
如果是基于SYNC Time Base,根据上图具体装配过程可拆解成如下几个步骤:
如果是基于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时间同步报文序列:
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对象正常接收处理。
综上所述,时间同步报文的解析过程总体而言可以分为如下几个基本步骤:
意的是Time Master与Time Slave的DataIDList应始终保持一致,否则CRC计算的结果就没法保持一致,报文就不能够被Time Slave对象正常接收处理。**
综上所述,时间同步报文的解析过程总体而言可以分为如下几个基本步骤:
更多精彩内容,敬请关注公众号“ADAS与ECU之吾见”!