前言

首先，請問大家?guī)讉€小小問題，你清楚：

你知道EthTsync模塊的主要作用是什么嗎？

EthTsync模塊與其他AUTOSAR基礎(chǔ)軟件模塊交互關(guān)系；

Eth Tsync模塊使用的時間同步協(xié)議是什么？

Eth Tsync模塊與gPTP時間同步協(xié)議的關(guān)系是什么？

今天，我們就來一起探索并回答這些問題。為了便于大家理解，以下是本文的主題大綱：

正文

Eth Driver一般都具備硬件時間戳特性，該特性便是車載以太網(wǎng)實現(xiàn)時間同步的一個關(guān)鍵前提，在AUTOSAR標(biāo)準(zhǔn)規(guī)范中，EthTsync模塊就是用來實現(xiàn)基于車載以太網(wǎng)的時間同步協(xié)議的一個獨有的模塊，該模塊與時間同步管理模塊StbM模塊相互配合協(xié)作來共同實現(xiàn)完整的車載以太網(wǎng)時間同步方案。

因此，本文將重點介紹EthTsync模塊在AUTOSAR模塊中的層級關(guān)系，以太網(wǎng)時間同步原理，與EEE802.1AS定義的gPTP時間同步協(xié)議的關(guān)系，以及針對AUTOSAR模塊中定義的PTP時間同步協(xié)議內(nèi)容，以便大家能夠由淺入深，循序漸見地對這個模塊有個清晰的認(rèn)識與理解。

AUTOSAR層級關(guān)系

按照AUTOSAR標(biāo)準(zhǔn)文檔規(guī)范，有關(guān)EthTsync模塊在整個AUTOSAR車載以太網(wǎng)協(xié)議棧的具體位置描述如下圖1所示：

圖1 EthTsync模塊與以太網(wǎng)協(xié)議棧關(guān)系

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

車載以太網(wǎng)時間同步方案會涉及到Eth Driver，EthIf模塊，EthTsync模塊以及StbM模塊等，其中Eth Driver，EthIf模塊提供時間同步報文的收發(fā)解析，EthTsync模塊負(fù)責(zé)時間同步協(xié)議解析，StbM負(fù)責(zé)時間同步統(tǒng)一管理與分發(fā)，為應(yīng)用層提供全局時間戳服務(wù)；

按照AUTOSAR規(guī)范定義當(dāng)前使用的車載以太網(wǎng)時間同步協(xié)議與IEEE802.1AS的gPTP(generalized Precision Time Protocal)協(xié)議一致;

EthTsync時間同步協(xié)議

EthTsync時間同步協(xié)議是基于IEEE 802.1AS規(guī)范中定義的gPTP標(biāo)準(zhǔn)協(xié)議發(fā)展出來的一套協(xié)議，該模塊的時間同步原理與gPTP協(xié)議一致，只不過在協(xié)議內(nèi)容方面，AUTOSAR規(guī)范進(jìn)行了一些擴(kuò)展，豐富了gPTP時間同步內(nèi)容。

因此，本文將重點以IEEE 802.1AS定義的gPTP以太網(wǎng)時間同步原理與協(xié)議來跟大家講解EthTsync模塊的基本功能與作用，同時針對協(xié)議內(nèi)容的差異也會指出區(qū)別與聯(lián)系。

本節(jié)將會從如下幾個方面針對EthTsync模塊時間同步協(xié)議介紹：

gPTP拓?fù)浣Y(jié)構(gòu)：介紹gPTP協(xié)議應(yīng)用在何種以太網(wǎng)節(jié)點網(wǎng)絡(luò)中使用以及各節(jié)點如何進(jìn)行交互；

gPTP時間同步流程：介紹gPTP時間同步協(xié)議實現(xiàn)的基本原理與過程；

gPTP與PTP協(xié)議區(qū)別和聯(lián)系：介紹gPTP協(xié)議與IEEE 1588規(guī)范中定義的PTP協(xié)議區(qū)別與聯(lián)系；

AUTOSAR中g(shù)PTP協(xié)議介紹：介紹在AUTOSAR規(guī)范中的gPTP協(xié)議的具體內(nèi)容，包含報文格式定義等內(nèi)容；

gPTP拓?fù)浣Y(jié)構(gòu)

如下圖2所示展示了單一域時間敏感網(wǎng)絡(luò)的gPTP域拓?fù)浣Y(jié)構(gòu)，根據(jù)gPTP協(xié)議規(guī)范了如下域內(nèi)三種類型的以太網(wǎng)節(jié)點：

GrandMaster Node(簡稱GM)：在一個gPTP域內(nèi)有且僅有一個主時鐘，即GrandMaster節(jié)點，簡稱GM；

Bridge Node：橋接節(jié)點，在一個gPTP域內(nèi)可以存在多個，但是不能作為時鐘節(jié)點，只能作為透明時鐘；

Endpoint Node：邊緣節(jié)點，作為該gPTP域內(nèi)的從時鐘節(jié)點；

圖2 gPTP單一域節(jié)點拓?fù)浣Y(jié)構(gòu)

其中，gPTP協(xié)議是建立在主從時鐘關(guān)系上的一種協(xié)議，也就是說，在一個網(wǎng)絡(luò)內(nèi)所有節(jié)點都要以Master節(jié)點作為主時鐘，其余節(jié)點作為從時鐘，從時鐘將自己的本地時間與主時鐘時間進(jìn)行同步，同時時間同步是可以層次遞進(jìn)的，作為slave節(jié)點的時鐘也可以作為另一個局域網(wǎng)內(nèi)的主時鐘，如網(wǎng)關(guān)節(jié)點。

在上圖中框起來的區(qū)域如果發(fā)生link錯誤，導(dǎo)致current GM無法將時間同步信息傳遞進(jìn)該區(qū)域，那么就會使用到BMCA算法來實現(xiàn)新的Master時鐘選擇， 若發(fā)生此類場景，圖中GNSS邊緣時鐘節(jié)點將會被作為新的GM節(jié)點而存在，此時網(wǎng)絡(luò)中將會存在兩個gPTP域。

值得注意的是，AUTOSAR規(guī)范中的EthTsync模塊明確表示不支持BMCA算法，主要是考慮到整車網(wǎng)絡(luò)屬于一個靜態(tài)網(wǎng)絡(luò)，整個ECU拓?fù)浣Y(jié)構(gòu)上下點電都不會發(fā)生變化，如果發(fā)生上述連接故障問題也就需要進(jìn)行售后處理，軟件無需處理該場景。

因此，在車載以太網(wǎng)拓?fù)浣Y(jié)構(gòu)中，gPTP域內(nèi)的GrandMaster主時鐘均已預(yù)先設(shè)定好，無需通過BMCA算法來進(jìn)行動態(tài)選擇。

gPTP時間同步流程

gPTP時間同步流程可以按照如下先后順序來進(jìn)行，彼此之間存在依賴關(guān)系：

1. 最佳主時鐘選擇原理

在gPTP時間同步協(xié)議中可能在同一域內(nèi)存在多個可用的全局時間源，就需要通過一種方式來選擇全局最佳主時鐘，這種方法被稱為Best Master Clock Algorithm，簡稱BMCA算法。

系統(tǒng)上電之后，所有設(shè)備都可以通過一條報文來參與主時鐘的競選，報文中包含各個設(shè)備的時鐘信息，每個設(shè)備都會主動比較自身與其他節(jié)點時鐘的信息，競選失敗的將退出，如此反復(fù)，直至最后選擇最佳主時鐘。

針對車載以太網(wǎng)，無需通過考慮最佳主時鐘選擇，車載以太網(wǎng)屬于靜態(tài)網(wǎng)絡(luò)，均已提前設(shè)定好。

2. 頻率同步原理

我們知道主從時鐘底層都是通過晶振驅(qū)動來進(jìn)行計時，但是不可避免的是晶振會受到外部溫度，老化等因素影響進(jìn)而產(chǎn)生時鐘偏移。

因此為了更為精確地保證主從時鐘的同步，因此需要將主從時鐘之間的晶振頻率差異考慮在內(nèi)，進(jìn)而解決主從端口晶振精度不準(zhǔn)帶來的時間同步誤差。

計算方法如下圖3所示：

圖3 主從時鐘頻率同步測量原理

基于圖3中的兩個周期性的sync報文與follow-up報文，其中followup報文傳輸?shù)氖莝ync報文在主時鐘節(jié)點發(fā)送時刻的時間戳，考慮主從時鐘節(jié)點對于總線傳輸?shù)难訒r都是固定的，T1，T2，T3，T4都是物理層獲取的時間戳，因此主從時鐘節(jié)點的時鐘偏差可以通過如下公 式來體現(xiàn)：

頻率同步計算公式

3. Path延時時間測量原理

從時鐘節(jié)點為了能夠跟主時鐘同步，除了上述主從時鐘節(jié)點的時鐘頻率偏差帶來的差異外，還存在一個非常重要的延時即以太網(wǎng)總線傳輸延時需要進(jìn)行精確測量，才能夠保證時間同步的精度，測量原理如下圖4所示：

圖4 gPTP延時時間測量原理

注意，Pdelay_Req報文發(fā)起方既可以是Time Master也可以是Time Slave，本文只不過以Time Slave為例。

延時時間Pdelay time的測量具體步驟如下：

S1：Time Slave節(jié)點發(fā)送Pdelay_Req報文，Time Slave節(jié)點記錄該報文發(fā)送時刻的時間戳T1；

S2：Time Master記錄MAC層收到Pdelay_Req報文的時間戳T2；

S3：Time Master將上述T2時間通過Pdelay_Resp報文發(fā)送至Time Slave，同時Time Master記錄發(fā)送該報文的時間戳T3，Time Slave記錄收到該報文的時間戳T4；

S4：Time Master將上述T3時間通過Pdelay_Resp_Follow_Up報文發(fā)送至Time Slave，當(dāng)Time Slave收到該報文時便知道了T1，T2，T3，T4時間戳；

考慮到主從時鐘之間的時鐘頻率偏差以及主從時鐘之間的延時對稱原理，因此Pdelay time的計算方法如下所示：

Pdelay計算公式

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

4. 時間同步原理

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

圖5 gPTP時間同步原理

如上圖5所示，基于gPTP的時間同步協(xié)議通過SYNC報文與FollowUp報文來實現(xiàn)同步，同步流程如下：

S1：Time Master發(fā)送SYNC報文，該報文如果是單步模式，那么就需要攜帶T1時間戳信息，如果是雙步模式，該報文無需發(fā)送任何有效信息；

S2：Time Slave收到SYNC報文之后，MAC層會記錄對應(yīng)時刻的時間戳T2；

S3：若基于雙步模式，Time Master再發(fā)送Follow up報文，該報文中攜帶著SYNC報文外發(fā)時刻的時間戳T1;

基于上述流程，我們便可以得到從時鐘節(jié)點與主時鐘節(jié)點的時間同步關(guān)系，設(shè)某時刻Time Master的全局時間為T6，對應(yīng)此時刻的Time Slave 本地時間為T5，因此時間同步關(guān)系如下：

其中Pdelay time通過上述延時時間測量過程得到，最終得到的Time Master與Time Slave的同步時間關(guān)系。

注意：gPTP時間同步過程可分為單步模式與雙步模式，單步模式(one step)對以太網(wǎng)PHY硬件要求較高，需要能夠精準(zhǔn)獲取發(fā)送時刻的時間，因此普遍采用雙步模式來完成時間同步，以便降低集成難度。

對于AUTOSAR規(guī)范中定義的gPTP時間同步協(xié)議而言，默認(rèn)采用雙步模式(two step)。

gPTP與PTP協(xié)議區(qū)別與聯(lián)系

前面講到gPTP協(xié)議屬于IEEE802.1AS規(guī)范中的內(nèi)容，而對于PTP協(xié)議則是屬于IEEE1588 協(xié)議中的內(nèi)容，gPTP協(xié)議是基于傳統(tǒng)意義上的PTP協(xié)議發(fā)展而來，兩者存在很多的相似點，但也有很多差異，這種差異的來源主要還是兩者針對時間同步的精度不同。

其中g(shù)PTP協(xié)議由TSN工作組進(jìn)行制定，TSN工作組屬于原先的AVB工作組。

對于gPTP協(xié)議而言專用于時間敏感網(wǎng)絡(luò)(TSN)，時間同步精度要求較高，而傳統(tǒng)的PTP時間同步協(xié)議無法滿足該要求，如下圖6展示了兩者協(xié)議的相似點與差異：

圖6 gPTP與PTP協(xié)議區(qū)別

AUTOSAR中g(shù)PTP協(xié)議介紹

相比IEEE802.1AS規(guī)范中定義的gPTP協(xié)議，AUTOSAR組織結(jié)合車載網(wǎng)絡(luò)應(yīng)用場景針對其部分內(nèi)容也做了進(jìn)一步限制與約束，以便能夠更加靈活應(yīng)用，降低整個系統(tǒng)的集成難度。

AUTOSAR規(guī)范中的gPTP主要約束條件如下：

由于車載網(wǎng)絡(luò)屬于靜態(tài)網(wǎng)絡(luò)，不支持BMCA算法；

不支持Anounce與Signaling報文的發(fā)送與接收；

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

IEEE802.1AS規(guī)定不能發(fā)送帶有VLAN信息的時間同步報文，但AUOTSAR允許使用帶有VLAN信息的報文，前提是網(wǎng)關(guān)支持轉(zhuǎn)發(fā)預(yù)留的多播地址01C200:00 .. 0F的報文;

報文中的CRC保護(hù)措施不能作為信息安全的內(nèi)容；

報文類型與格式

在AUTOSAR中的gPTP協(xié)議支持SYNC, Follow-up，Pdelay_Req，Pdelay_Resp, Pdelay_Resp_Follow_up 五類報文。

其中SYNC，Pdelay_Req, Pdelay_Resp報文屬于事件型報文，因為都需要記錄收發(fā)時刻的時間戳，而Follow-up,Pdelay_Resp_Follow_up則屬于一般性報文，因為不記錄該類收發(fā)時刻的時間戳，僅關(guān)注其承載信息，如下圖所示。

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

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

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

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

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

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

上述各參數(shù)解釋如下表：

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

SYNC Message Payload定義(IEEE802.1AS)

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

圖10 IEEE802.1AS規(guī)范下Payload定義說明

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

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

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

圖11 IEEE802.1AS規(guī)范下Payload定義說明

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

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

?

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

如下圖13所示為IEEE802.1AS規(guī)范下Follow up報文Payload與標(biāo)準(zhǔn)TLV字段解釋說明：

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

SYNC Message頭信息定義(AUTOSAR)

與IEEE802.1AS規(guī)范下的SYNC報文頭信息相比，除了domain number有些區(qū)別以外，其余均相同，AUTOSAR規(guī)范下的domain ID為0-15，而IEEE802.1AS規(guī)范下的SYNC報文則固定為0。

SYNC Message Payload定義(AUTOSAR)

AUTOSAR規(guī)范下的SYNC報文與IEEE802.1AS規(guī)范下的SYNC報文Payload內(nèi)容一致,不再過多贅述。

Follow_Up Message頭信息定義(AUTOSAR)

AUTOSAR規(guī)范下的Follow_Up Message 與IEEE802.1AS規(guī)范下Follow_Up Message相比，在Length of Message長度方面多增加了一些字節(jié)，其余沒有區(qū)別，原因是由于AUTOSAR規(guī)范下的Follow_Up Message增加了諸多TLV字段。

Follow Up Message Payload定義(AUTOSAR)

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

?

?

?

?

?

?

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

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

Pdelay_Req報文格式定義

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

圖15 Pdelay_Req報文格式定義

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

Pdelay_Resp報文格式定義

圖16 Pdelay_Resp報文格式定義

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

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

requestingPortIdentity：該值應(yīng)與Pdelay_Req報文中的sourcePortIdentity字段一致；

Pdelay_Resp_Follow_Up報文格式定義

圖17 Pdelay_Resp_Follow_up報文格式定義

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

responseOriginTimestamp：發(fā)送Pdelay_Resp報文時刻的s部分與ns部分；

requestingPortIdentity：該值應(yīng)與Pdelay_Req報文中的sourcePortIdentity字段一致；

除了解上述Path延時測量相關(guān)報文格式以外，AUTOSAR定義的Path延時時間測量機(jī)制還需要注意如下幾個關(guān)鍵點：

EthTsync模塊通過Pdelay_Req，Pdelay_Resp，Pdelay_Resp_Follow_Up報文來進(jìn)行延遲測量；

Pdelay_Res超時發(fā)出接收節(jié)點將會中止本次延時測量，接收節(jié)點默認(rèn)使用上次延時測量的結(jié)果；

主從時鐘節(jié)點均需要周期性發(fā)送Pdelay_Req報文來進(jìn)行彼此的Path延時時間測量，發(fā)送報文周期可通過EthTSynGlobalTimeTxPdelayReqPeriod來控制；

Pdelay_Resp_Follow_Up報文的發(fā)送時間可以通過參數(shù)EthTSynGlobalTimeTxFollowUpOffset配置；

上述五類報文的目標(biāo)MAC地址均統(tǒng)一為01-80-C2-00-00-0E, 源MAC地址為各自報文發(fā)送的端口地址；

上述五類報文的EtherType統(tǒng)一為88-F7;

Time Master行為

在gPTP網(wǎng)絡(luò)中作為Time Master的節(jié)點存在著如下報文處理流程：

Time Master負(fù)責(zé)SYNC報文與Follow-Up報文的發(fā)送，SYNC報文可以通過設(shè)置參數(shù)EthTSynGlobalTimeTxPeriod來進(jìn)行周期性發(fā)送，在發(fā)送SYNC報文的過程中需進(jìn)行如下三個基本步驟：

通過函數(shù) EthIf_ProvideTxBuffer來獲取空閑的buffer來存儲發(fā)送的數(shù)據(jù)；

如果參數(shù)EthTSynHardwareTimestampSupport設(shè)置為TRUE，那么可通過函數(shù)EthIf_EnableEgressTimeStamp來激活硬件時間戳功能；

通過調(diào)用函數(shù)Ethif_Transmit來觸發(fā)報文的發(fā)送；

當(dāng)參數(shù)EthTSynHardwareTimestampSupport設(shè)置為TRUE，通過調(diào)用函數(shù)EthTSyn_TxConfirmation來獲取SYNC報文外發(fā)時刻的時間戳；

通過設(shè)置參數(shù)EthTSynGlobalTimeTxFollowUpOffset來決定SYNC報文發(fā)送之后多久發(fā)送Follow_Up報文，F(xiàn)ollow_Up報文發(fā)送需經(jīng)過如下兩個基本步驟：

通過函數(shù) EthIf_ProvideTxBuffer來獲取空閑的buffer來存儲發(fā)送的數(shù)據(jù)；

通過調(diào)用函數(shù)Ethif_Transmit來觸發(fā)報文的發(fā)送；

通過函數(shù) EthTSyn_TrcvLinkStateChg來獲取當(dāng)前使用的PHY狀態(tài)，當(dāng)PHY狀態(tài)由 ETHTRCV_LINK_STATE_ACTIVE 切換成ETHTRCV_LINK_STATE_DOWN時就會重置所有時間同步報文的發(fā)送與接收狀態(tài)機(jī)。

通過函數(shù) EthTSyn_TrcvLinkStateChg來獲取當(dāng)前使用的PHY狀態(tài)，當(dāng)PHY狀態(tài)由 ETHTRCV_LINK_STATE_DOWN切換成ETHTRCV_LINK_STATE_ACTIVE時就會重啟所有時間同步報文的發(fā)送與接收。

可通過調(diào)用函數(shù)EthTSyn_SetTransmissionMode并設(shè)置成ETHTSYN_TX_OFF，所有發(fā)送的請求將會被禁止發(fā)送，設(shè)置成ETHTSYN_TX_ON則所有的報文發(fā)送請求均會被接受；

Time Slave行為

在gPTP網(wǎng)絡(luò)中作為Time Slave的節(jié)點存在著如下報文處理流程：

如果EthTSynHardwareTimestampSupport設(shè)置成TRUE, Time Slave節(jié)點可以通過函數(shù)EthTSyn_RxIndication來獲取SYNC報文接收到的時間戳；

Time Slave可通過配置參數(shù)EthTSynGlobalTimeFollowUpTimeout來實現(xiàn)SYNC報文接收之后Follow_Up報文的超時監(jiān)控，一旦發(fā)生超時，那么本次時間同步將失效，等待下次新的時間同步序列；

如果EthTSynHardwareTimestampSupport設(shè)置成TRUE, Time Slave節(jié)點收到有效的Follow_Up報文之后，本地時間與Follow_Up發(fā)送的全局時間差距超過 EthTSynTimeHardwareCorrectionThreshold，那么就需要調(diào)用函數(shù)EthIf_SetCorrectionTime來進(jìn)行重置本地時間；

如果EthTSynHardwareTimestampSupport設(shè)置成FALSE, Time Slave就需要計算出全局時間，然后通過函數(shù)StbM_BusSetGlobalTime來實現(xiàn)時間同步；

常用函數(shù)接口

為了便于大家更好地使用EthTsync這個模塊，小T整理了關(guān)于車載以太網(wǎng)時間同步模塊這部分常用的函數(shù)接口與功能說明，如下圖18所示：

圖18 常用函數(shù)接口說明 ? ? ?

編輯：黃飛

?