前言

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

• 你知道EthTsync模块的主要作用是什么吗？

• EthTsync模块与其他AUTOSAR基础软件模块交互关系；

• Eth Tsync模块使用的时间同步协议是什么？

• Eth Tsync模块与gPTP时间同步协议的关系是什么？

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

正文

Eth Driver一般都具备硬件时间戳特性，该特性便是车载以太网实现时间同步的一个关键前提，在AUTOSAR标准规范中，EthTsync模块就是用来实现基于车载以太网的时间同步协议的一个独有的模块，该模块与时间同步管理模块StbM模块相互配合协作来共同实现完整的车载以太网时间同步方案。

因此，本文将重点介绍EthTsync模块在AUTOSAR模块中的层级关系，以太网时间同步原理，与EEE802.1AS定义的gPTP时间同步协议的关系，以及针对AUTOSAR模块中定义的PTP时间同步协议内容，以便大家能够由浅入深，循序渐见地对这个模块有个清晰的认识与理解。

AUTOSAR层级关系

按照AUTOSAR标准文档规范，有关EthTsync模块在整个AUTOSAR车载以太网协议栈的具体位置描述如下图1所示：

如上图所示，可以得出如下几个基本结论：

• 车载以太网时间同步方案会涉及到Eth Driver，EthIf模块，EthTsync模块以及StbM模块等，其中Eth Driver，EthIf模块提供时间同步报文的收发解析，EthTsync模块负责时间同步协议解析，StbM负责时间同步统一管理与分发，为应用层提供全局时间戳服务；

• 按照AUTOSAR规范定义当前使用的车载以太网时间同步协议与IEEE802.1AS的gPTP(generalized Precision Time Protocal)协议一致;

EthTsync时间同步协议

EthTsync时间同步协议是基于IEEE 802.1AS规范中定义的gPTP标准协议发展出来的一套协议，该模块的时间同步原理与gPTP协议一致，只不过在协议内容方面，AUTOSAR规范进行了一些扩展，丰富了gPTP时间同步内容。

因此，本文将重点以IEEE 802.1AS定义的gPTP以太网时间同步原理与协议来跟大家讲解EthTsync模块的基本功能与作用，同时针对协议内容的差异也会指出区别与联系。

本节将会从如下几个方面针对EthTsync模块时间同步协议介绍：

• gPTP拓扑结构：介绍gPTP协议应用在何种以太网节点网络中使用以及各节点如何进行交互；

• gPTP时间同步流程：介绍gPTP时间同步协议实现的基本原理与过程；

• gPTP与PTP协议区别和联系：介绍gPTP协议与IEEE 1588规范中定义的PTP协议区别与联系；

• AUTOSAR中gPTP协议介绍：介绍在AUTOSAR规范中的gPTP协议的具体内容，包含报文格式定义等内容；

gPTP拓扑结构

如下图2所示展示了单一域时间敏感网络的gPTP域拓扑结构，根据gPTP协议规范了如下域内三种类型的以太网节点：

• GrandMaster Node(简称GM)：在一个gPTP域内有且仅有一个主时钟，即GrandMaster节点，简称GM；

• Bridge Node：桥接节点，在一个gPTP域内可以存在多个，但是不能作为时钟节点，只能作为透明时钟；

• Endpoint Node：边缘节点，作为该gPTP域内的从时钟节点；

其中，gPTP协议是建立在主从时钟关系上的一种协议，也就是说，在一个网络内所有节点都要以Master节点作为主时钟，其余节点作为从时钟，从时钟将自己的本地时间与主时钟时间进行同步，同时时间同步是可以层次递进的，作为slave节点的时钟也可以作为另一个局域网内的主时钟，如网关节点。

在上图中框起来的区域如果发生link错误，导致current GM无法将时间同步信息传递进该区域，那么就会使用到BMCA算法来实现新的Master时钟选择， 若发生此类场景，图中GNSS边缘时钟节点将会被作为新的GM节点而存在，此时网络中将会存在两个gPTP域。

值得注意的是，AUTOSAR规范中的EthTsync模块明确表示不支持BMCA算法，主要是考虑到整车网络属于一个静态网络，整个ECU拓扑结构上下点电都不会发生变化，如果发生上述连接故障问题也就需要进行售后处理，软件无需处理该场景。

因此，在车载以太网拓扑结构中，gPTP域内的GrandMaster主时钟均已预先设定好，无需通过BMCA算法来进行动态选择。

gPTP时间同步流程

gPTP时间同步流程可以按照如下先后顺序来进行，彼此之间存在依赖关系：

• 1. 最佳主时钟选择原理

  在gPTP时间同步协议中可能在同一域内存在多个可用的全局时间源，就需要通过一种方式来选择全局最佳主时钟，这种方法被称为Best Master Clock Algorithm，简称BMCA算法。

  系统上电之后，所有设备都可以通过一条报文来参与主时钟的竞选，报文中包含各个设备的时钟信息，每个设备都会主动比较自身与其他节点时钟的信息，竞选失败的将退出，如此反复，直至最后选择最佳主时钟。

  针对车载以太网，无需通过考虑最佳主时钟选择，车载以太网属于静态网络，均已提前设定好。

• 2. 频率同步原理

  我们知道主从时钟底层都是通过晶振驱动来进行计时，但是不可避免的是晶振会受到外部温度，老化等因素影响进而产生时钟偏移。

  因此为了更为精确地保证主从时钟的同步，因此需要将主从时钟之间的晶振频率差异考虑在内，进而解决主从端口晶振精度不准带来的时间同步误差。

  计算方法如下图3所示：

基于图3中的两个周期性的sync报文与follow-up报文，其中followup报文传输的是sync报文在主时钟节点发送时刻的时间戳，考虑主从时钟节点对于总线传输的延时都是固定的，T1，T2，T3，T4都是物理层获取的时间戳，因此主从时钟节点的时钟偏差可以通过如下公 式来体现：

• 3. Path延时时间测量原理

  从时钟节点为了能够跟主时钟同步，除了上述主从时钟节点的时钟频率偏差带来的差异外，还存在一个非常重要的延时即以太网总线传输延时需要进行精确测量，才能够保证时间同步的精度，测量原理如下图4所示：

  图4 gPTP延时时间测量原理
  

  
  

  注意，Pdelay_Req报文发起方既可以是Time Master也可以是Time Slave，本文只不过以Time Slave为例。

  延时时间Pdelay time的测量具体步骤如下：

  S1：Time Slave节点发送Pdelay_Req报文，Time Slave节点记录该报文发送时刻的时间戳T1；

  S2：Time Master记录MAC层收到Pdelay_Req报文的时间戳T2；

  S3：Time Master将上述T2时间通过Pdelay_Resp报文发送至Time Slave，同时Time Master记录发送该报文的时间戳T3，Time Slave记录收到该报文的时间戳T4；

  S4：Time Master将上述T3时间通过Pdelay_Resp_Follow_Up报文发送至Time Slave，当Time Slave收到该报文时便知道了T1，T2，T3，T4时间戳；

  考虑到主从时钟之间的时钟频率偏差以及主从时钟之间的延时对称原理，因此Pdelay time的计算方法如下所示：

  值得注意的是上述公式中如果主从时钟频率一致，那么此时P=1。

• 4. 时间同步原理

  基于上述计算出来的总线延时时间Pdelay time以及主从时间频率的比值，也被称为NeighborRateRatio，那么便可以完成从时钟节点与主时钟之间的同步，其同步原理如下图5所示：

如上图5所示，基于gPTP的时间同步协议通过SYNC报文与FollowUp报文来实现同步，同步流程如下：

S1：Time Master发送SYNC报文，该报文如果是单步模式，那么就需要携带T1时间戳信息，如果是双步模式，该报文无需发送任何有效信息；

S2：Time Slave收到SYNC报文之后，MAC层会记录对应时刻的时间戳T2；

S3：若基于双步模式，Time Master再发送Follow up报文，该报文中携带着SYNC报文外发时刻的时间戳T1;

基于上述流程，我们便可以得到从时钟节点与主时钟节点的时间同步关系，设某时刻Time Master的全局时间为T6，对应此时刻的Time Slave 本地时间为T5，因此时间同步关系如下：

其中Pdelay time通过上述延时时间测量过程得到，最终得到的Time Master与Time Slave的同步时间关系。

注意：gPTP时间同步过程可分为单步模式与双步模式，单步模式(one step)对以太网PHY硬件要求较高，需要能够精准获取发送时刻的时间，因此普遍采用双步模式来完成时间同步，以便降低集成难度。

对于AUTOSAR规范中定义的gPTP时间同步协议而言，默认采用双步模式(two step)。

gPTP与PTP协议区别与联系

前面讲到gPTP协议属于IEEE802.1AS规范中的内容，而对于PTP协议则是属于IEEE1588 协议中的内容，gPTP协议是基于传统意义上的PTP协议发展而来，两者存在很多的相似点，但也有很多差异，这种差异的来源主要还是两者针对时间同步的精度不同。

其中gPTP协议由TSN工作组进行制定，TSN工作组属于原先的AVB工作组。

对于gPTP协议而言专用于时间敏感网络(TSN)，时间同步精度要求较高，而传统的PTP时间同步协议无法满足该要求，如下图6展示了两者协议的相似点与差异：

AUTOSAR中gPTP协议介绍

相比IEEE802.1AS规范中定义的gPTP协议，AUTOSAR组织结合车载网络应用场景针对其部分内容也做了进一步限制与约束，以便能够更加灵活应用，降低整个系统的集成难度。

AUTOSAR规范中的gPTP主要约束条件如下：

• 由于车载网络属于静态网络，不支持BMCA算法；

• 不支持Anounce与Signaling报文的发送与接收；

• Pdelay_Req不作为开启发送SYNC报文的前置条件；

• IEEE802.1AS规定不能发送带有VLAN信息的时间同步报文，但AUOTSAR允许使用带有VLAN信息的报文，前提是网关支持转发预留的多播地址01:80:C2:00:00:00 .. 0F的报文;

• 报文中的CRC保护措施不能作为信息安全的内容；

报文类型与格式

在AUTOSAR中的gPTP协议支持SYNC, Follow-up，Pdelay_Req，Pdelay_Resp, Pdelay_Resp_Follow_up 五类报文。

其中SYNC，Pdelay_Req, Pdelay_Resp报文属于事件型报文，因为都需要记录收发时刻的时间戳，而Follow-up,Pdelay_Resp_Follow_up则属于一般性报文，因为不记录该类收发时刻的时间戳，仅关注其承载信息，如下图所示。

上述五类报文按照AUTOSAR定义可以通过参数MessageCompliance来进行统一控制，如果该参数为TRUE,则需要采用IEEE802.1AS规范下的报文格式，如果该参数为FALSE,则使用AUTOSAR规范下的报文格式。

该五类报文格式均由头信息格式，Paload格式，数据类型(TLV若有)组成，同一规范下的五类报文均具有相同的头信息格式定义。

以IEEE802.1AS规范下的SYNC报文头信息格式为例，如下图所示：

SYNC Message头信息定义(IEEE802.1AS)

上述各参数解释如下表：

SYNC Message Payload定义(IEEE802.1AS)

如下图所示为SYNC报文的Payload定义以及说明：

根据IEEE802.1AS规范下的SYNC报文头信息总共占用34个字节，保留了10个字节作为备用，也就意味着SYNC报文除具备gPTP的头信息以外，不具备其他有效信息。

Follow_Up Message头信息定义(IEEE802.1AS)

如下图所示为Follow Up message的头信息定义说明，可以看出基本与上述SYNC报文基本一致。

图11中每个参数的定义说明可直接参考图9，按照相应的报文类型对号入座即可。

Follow Up Message Payload定义(IEEE802.1AS)

如下图13所示为IEEE802.1AS规范下Follow up报文Payload与标准TLV字段解释说明：

SYNC Message头信息定义(AUTOSAR)

与IEEE802.1AS规范下的SYNC报文头信息相比，除了domain number有些区别以外，其余均相同，AUTOSAR规范下的domain ID为0-15，而IEEE802.1AS规范下的SYNC报文则固定为0。

SYNC Message Payload定义(AUTOSAR)

AUTOSAR规范下的SYNC报文与IEEE802.1AS规范下的SYNC报文Payload内容一致,不再过多赘述。

Follow_Up Message头信息定义(AUTOSAR)

AUTOSAR规范下的Follow_Up Message 与IEEE802.1AS规范下Follow_Up Message相比，在Length of Message长度方面多增加了一些字节，其余没有区别，原因是由于AUTOSAR规范下的Follow_Up Message增加了诸多TLV字段。

Follow Up Message Payload定义(AUTOSAR)

新增的AUTOSAR TLV字段如下图14所示：

由于AUTOSAR规范下的新增TLV内容较多，主要是针对各种TLV做的CRC计算规则会有些许差异，基本原理一致，不复杂，由于篇幅原因，小T就不过多对这些TLV进行赘述，大家可自行进行研究。

Pdelay_Req报文格式定义

如下图15所示为IEEE802.1AS定义的报文格式定义：

上图中header与SYNC Message头信息定义(IEEE802.1AS)中一致，该报文共占用54个字节，除了header信息外没有其他Payload信息。

Pdelay_Resp报文格式定义

上图中header与SYNC Message头信息定义(IEEE802.1AS)中一致，该报文共占用54个字节， 图中两个变量解释如下：

• requestReceiptTimestamp：该值是Pdelay_Req报文发送时刻的s与ns部分；

• requestingPortIdentity：该值应与Pdelay_Req报文中的sourcePortIdentity字段一致；

Pdelay_Resp_Follow_Up报文格式定义

上图中header与SYNC Message头信息定义(IEEE802.1AS)中一致，该报文共占用54个字节， 图中两个变量解释如下：

• responseOriginTimestamp：发送Pdelay_Resp报文时刻的s部分与ns部分；

• requestingPortIdentity：该值应与Pdelay_Req报文中的sourcePortIdentity字段一致；

除了解上述Path延时测量相关报文格式以外，AUTOSAR定义的Path延时时间测量机制还需要注意如下几个关键点：

• EthTsync模块通过Pdelay_Req，Pdelay_Resp，Pdelay_Resp_Follow_Up报文来进行延迟测量；

• Pdelay_Res超时发出接收节点将会中止本次延时测量，接收节点默认使用上次延时测量的结果；

• 主从时钟节点均需要周期性发送Pdelay_Req报文来进行彼此的Path延时时间测量，发送报文周期可通过EthTSynGlobalTimeTxPdelayReqPeriod来控制；

• Pdelay_Resp_Follow_Up报文的发送时间可以通过参数EthTSynGlobalTimeTxFollowUpOffset配置；

• 上述五类报文的目标MAC地址均统一为01-80-C2-00-00-0E, 源MAC地址为各自报文发送的端口地址；

• 上述五类报文的EtherType统一为88-F7;

Time Master行为

在gPTP网络中作为Time Master的节点存在着如下报文处理流程：

• Time Master负责SYNC报文与Follow-Up报文的发送，SYNC报文可以通过设置参数EthTSynGlobalTimeTxPeriod来进行周期性发送，在发送SYNC报文的过程中需进行如下三个基本步骤：

• 通过函数 EthIf_ProvideTxBuffer来获取空闲的buffer来存储发送的数据；

• 如果参数EthTSynHardwareTimestampSupport设置为TRUE，那么可通过函数EthIf_EnableEgressTimeStamp来激活硬件时间戳功能；

• 通过调用函数Ethif_Transmit来触发报文的发送；

• 当参数EthTSynHardwareTimestampSupport设置为TRUE，通过调用函数EthTSyn_TxConfirmation来获取SYNC报文外发时刻的时间戳；

• 通过设置参数EthTSynGlobalTimeTxFollowUpOffset来决定SYNC报文发送之后多久发送Follow_Up报文，Follow_Up报文发送需经过如下两个基本步骤：

• 通过函数 EthIf_ProvideTxBuffer来获取空闲的buffer来存储发送的数据；

• 通过调用函数Ethif_Transmit来触发报文的发送；

• 通过函数 EthTSyn_TrcvLinkStateChg来获取当前使用的PHY状态，当PHY状态由 ETHTRCV_LINK_STATE_ACTIVE 切换成ETHTRCV_LINK_STATE_DOWN时就会重置所有时间同步报文的发送与接收状态机。

• 通过函数 EthTSyn_TrcvLinkStateChg来获取当前使用的PHY状态，当PHY状态由 ETHTRCV_LINK_STATE_DOWN切换成ETHTRCV_LINK_STATE_ACTIVE时就会重启所有时间同步报文的发送与接收。

• 可通过调用函数EthTSyn_SetTransmissionMode并设置成ETHTSYN_TX_OFF，所有发送的请求将会被禁止发送，设置成ETHTSYN_TX_ON则所有的报文发送请求均会被接受；

Time Slave行为

在gPTP网络中作为Time Slave的节点存在着如下报文处理流程：

• 如果EthTSynHardwareTimestampSupport设置成TRUE, Time Slave节点可以通过函数EthTSyn_RxIndication来获取SYNC报文接收到的时间戳；

• Time Slave可通过配置参数EthTSynGlobalTimeFollowUpTimeout来实现SYNC报文接收之后Follow_Up报文的超时监控，一旦发生超时，那么本次时间同步将失效，等待下次新的时间同步序列；

• 如果EthTSynHardwareTimestampSupport设置成TRUE, Time Slave节点收到有效的Follow_Up报文之后，本地时间与Follow_Up发送的全局时间差距超过 EthTSynTimeHardwareCorrectionThreshold，那么就需要调用函数EthIf_SetCorrectionTime来进行重置本地时间；

• 如果EthTSynHardwareTimestampSupport设置成FALSE, Time Slave就需要计算出全局时间，然后通过函数StbM_BusSetGlobalTime来实现时间同步；

常用函数接口

为了便于大家更好地使用EthTsync这个模块，小T整理了关于车载以太网时间同步模块这部分常用的函数接口与功能说明，如下图18所示：

码上报名

2023第六届无人驾驶及智能驾舱中国峰会，5月11-12日，上海

码上报名

AutoSec 7周年年会暨中国汽车网络安全与数据安全合规峰会，5月11-12日，上海

码上报名

AES 2023 第四届中国国际汽车以太网峰会，6月8-9日，上海

更多文章

智能网联汽车信息安全综述

华为蔡建永：智能网联汽车的数字安全和功能安全挑战与思考

汽车数据合规要点

车载以太网技术发展与测试方法

车载以太网防火墙设计

SOA：整车架构下一代的升级方向

软件如何「吞噬」汽车？

汽车信息安全 TARA 分析方法实例简介

汽车FOTA信息安全规范及方法研究

联合国WP.29车辆网络安全法规正式发布

滴滴下架，我却看到数据安全的曙光

从特斯拉被约谈到车辆远程升级（OTA）技术的合规

如何通过CAN破解汽

会员权益: (点击可进入)谈思实验室VIP会员

END

微信入群

谈思实验室专注智能汽车信息安全、预期功能安全、自动驾驶、以太网等汽车创新技术，为汽车行业提供最优质的学习交流服务，并依托强大的产业及专家资源，致力于打造汽车产业一流高效的商务平台。

 

每年谈思实验室举办数十场线上线下品牌活动，拥有数十个智能汽车创新技术的精品专题社群，覆盖BMW、Daimler、PSA、Audi、Volvo、Nissan、广汽、一汽、上汽、蔚来等近百家国内国际领先的汽车厂商专家，已经服务上万名智能汽车行业上下游产业链从业者。专属社群有：信息安全、功能安全、自动驾驶、TARA、渗透测试、SOTIF、WP.29、以太网、物联网安全等，现专题社群仍然开放，入满即止。

扫描二维码添加微信，根据提示，可以进入有意向的专题交流群，享受最新资讯及与业内专家互动机会。

谈思实验室，为汽车科技赋能，推动产业创新发展！