前言

首先，請問大家幾個小小問題，你清楚：

你知道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所示：

圖1 EthTsync模塊與以太網協議棧關系

如上圖所示，可以得出如下幾個基本結論：

車載以太網時間同步方案會涉及到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域內的從時鐘節點；

圖2 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 主從時鐘頻率同步測量原理

基于圖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的計算方法如下所示：

Pdelay計算公式

值得注意的是上述公式中如果主從時鐘頻率一致，那么此時P=1。

4. 時間同步原理

基于上述計算出來的總線延時時間Pdelay time以及主從時間頻率的比值，也被稱為NeighborRateRatio，那么便可以完成從時鐘節點與主時鐘之間的同步，其同步原理如下圖5所示：

圖5 gPTP時間同步原理

如上圖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展示了兩者協議的相似點與差異：

圖6 gPTP與PTP協議區別

AUTOSAR中gPTP協議介紹

相比IEEE802.1AS規范中定義的gPTP協議，AUTOSAR組織結合車載網絡應用場景針對其部分內容也做了進一步限制與約束，以便能夠更加靈活應用，降低整個系統的集成難度。

AUTOSAR規范中的gPTP主要約束條件如下：

由于車載網絡屬于靜態網絡，不支持BMCA算法；

不支持Anounce與Signaling報文的發送與接收；

Pdelay_Req不作為開啟發送SYNC報文的前置條件；

IEEE802.1AS規定不能發送帶有VLAN信息的時間同步報文，但AUOTSAR允許使用帶有VLAN信息的報文，前提是網關支持轉發預留的多播地址01C200: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則屬于一般性報文，因為不記錄該類收發時刻的時間戳，僅關注其承載信息，如下圖所示。

圖7 gPTP時間同步報文類型定義

上述五類報文按照AUTOSAR定義可以通過參數MessageCompliance來進行統一控制，如果該參數為TRUE,則需要采用IEEE802.1AS規范下的報文格式，如果該參數為FALSE,則使用AUTOSAR規范下的報文格式。

該五類報文格式均由頭信息格式，Paload格式，數據類型(TLV若有)組成，同一規范下的五類報文均具有相同的頭信息格式定義。

以IEEE802.1AS規范下的SYNC報文頭信息格式為例，如下圖所示：

SYNC Message頭信息定義(IEEE802.1AS)

圖8 gPTP時間同步報文類型定義

上述各參數解釋如下表：

圖9 IEEE802.1AS規范下sync報文頭信息定義

SYNC Message Payload定義(IEEE802.1AS)

如下圖所示為SYNC報文的Payload定義以及說明：

圖10 IEEE802.1AS規范下Payload定義說明

根據IEEE802.1AS規范下的SYNC報文頭信息總共占用34個字節，保留了10個字節作為備用，也就意味著SYNC報文除具備gPTP的頭信息以外，不具備其他有效信息。

Follow_Up Message頭信息定義(IEEE802.1AS)

如下圖所示為Follow Up message的頭信息定義說明，可以看出基本與上述SYNC報文基本一致。

圖11 IEEE802.1AS規范下Payload定義說明

圖11中每個參數的定義說明可直接參考圖9，按照相應的報文類型對號入座即可。

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

?

圖12 IEEE802.1AS規范下Follow up報文Payload定義

如下圖13所示為IEEE802.1AS規范下Follow up報文Payload與標準TLV字段解釋說明：

圖13 IEEE802.1AS規范下Follow up報文Payload解釋說明

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所示：

?

?

?

?

?

?

圖14 AUTOSAR規范下Follow up報文新增TLV字段定義

由于AUTOSAR規范下的新增TLV內容較多，主要是針對各種TLV做的CRC計算規則會有些許差異，基本原理一致，不復雜，由于篇幅原因，小T就不過多對這些TLV進行贅述，大家可自行進行研究。

Pdelay_Req報文格式定義

如下圖15所示為IEEE802.1AS定義的報文格式定義：

圖15 Pdelay_Req報文格式定義

上圖中header與SYNC Message頭信息定義(IEEE802.1AS)中一致，該報文共占用54個字節，除了header信息外沒有其他Payload信息。

Pdelay_Resp報文格式定義

圖16 Pdelay_Resp報文格式定義

上圖中header與SYNC Message頭信息定義(IEEE802.1AS)中一致，該報文共占用54個字節， 圖中兩個變量解釋如下：

requestReceiptTimestamp：該值是Pdelay_Req報文發送時刻的s與ns部分；

requestingPortIdentity：該值應與Pdelay_Req報文中的sourcePortIdentity字段一致；

Pdelay_Resp_Follow_Up報文格式定義

圖17 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所示：

圖18 常用函數接口說明 ? ? ?

編輯：黃飛

?