前言
首先,請(qǐng)問大家?guī)讉€(gè)小小問題,你清楚:
你知道EthTsync模塊的主要作用是什么嗎?
EthTsync模塊與其他AUTOSAR基礎(chǔ)軟件模塊交互關(guān)系;
Eth Tsync模塊使用的時(shí)間同步協(xié)議是什么?
Eth Tsync模塊與gPTP時(shí)間同步協(xié)議的關(guān)系是什么?
今天,我們就來(lái)一起探索并回答這些問題。為了便于大家理解,以下是本文的主題大綱:
正文
Eth Driver一般都具備硬件時(shí)間戳特性,該特性便是車載以太網(wǎng)實(shí)現(xiàn)時(shí)間同步的一個(gè)關(guān)鍵前提,在AUTOSAR標(biāo)準(zhǔn)規(guī)范中,EthTsync模塊就是用來(lái)實(shí)現(xiàn)基于車載以太網(wǎng)的時(shí)間同步協(xié)議的一個(gè)獨(dú)有的模塊,該模塊與時(shí)間同步管理模塊StbM模塊相互配合協(xié)作來(lái)共同實(shí)現(xiàn)完整的車載以太網(wǎng)時(shí)間同步方案。
因此,本文將重點(diǎn)介紹EthTsync模塊在AUTOSAR模塊中的層級(jí)關(guān)系,以太網(wǎng)時(shí)間同步原理,與EEE802.1AS定義的gPTP時(shí)間同步協(xié)議的關(guān)系,以及針對(duì)AUTOSAR模塊中定義的PTP時(shí)間同步協(xié)議內(nèi)容,以便大家能夠由淺入深,循序漸見地對(duì)這個(gè)模塊有個(gè)清晰的認(rèn)識(shí)與理解。
AUTOSAR層級(jí)關(guān)系
按照AUTOSAR標(biāo)準(zhǔn)文檔規(guī)范,有關(guān)EthTsync模塊在整個(gè)AUTOSAR車載以太網(wǎng)協(xié)議棧的具體位置描述如下圖1所示:
圖1 EthTsync模塊與以太網(wǎng)協(xié)議棧關(guān)系
如上圖所示,可以得出如下幾個(gè)基本結(jié)論:
車載以太網(wǎng)時(shí)間同步方案會(huì)涉及到Eth Driver,EthIf模塊,EthTsync模塊以及StbM模塊等,其中Eth Driver,EthIf模塊提供時(shí)間同步報(bào)文的收發(fā)解析,EthTsync模塊負(fù)責(zé)時(shí)間同步協(xié)議解析,StbM負(fù)責(zé)時(shí)間同步統(tǒng)一管理與分發(fā),為應(yīng)用層提供全局時(shí)間戳服務(wù);
按照AUTOSAR規(guī)范定義當(dāng)前使用的車載以太網(wǎng)時(shí)間同步協(xié)議與IEEE802.1AS的gPTP(generalized Precision Time Protocal)協(xié)議一致;
EthTsync時(shí)間同步協(xié)議
EthTsync時(shí)間同步協(xié)議是基于IEEE 802.1AS規(guī)范中定義的gPTP標(biāo)準(zhǔn)協(xié)議發(fā)展出來(lái)的一套協(xié)議,該模塊的時(shí)間同步原理與gPTP協(xié)議一致,只不過在協(xié)議內(nèi)容方面,AUTOSAR規(guī)范進(jìn)行了一些擴(kuò)展,豐富了gPTP時(shí)間同步內(nèi)容。
因此,本文將重點(diǎn)以IEEE 802.1AS定義的gPTP以太網(wǎng)時(shí)間同步原理與協(xié)議來(lái)跟大家講解EthTsync模塊的基本功能與作用,同時(shí)針對(duì)協(xié)議內(nèi)容的差異也會(huì)指出區(qū)別與聯(lián)系。
本節(jié)將會(huì)從如下幾個(gè)方面針對(duì)EthTsync模塊時(shí)間同步協(xié)議介紹:
gPTP拓?fù)浣Y(jié)構(gòu):介紹gPTP協(xié)議應(yīng)用在何種以太網(wǎng)節(jié)點(diǎn)網(wǎng)絡(luò)中使用以及各節(jié)點(diǎn)如何進(jìn)行交互;
gPTP時(shí)間同步流程:介紹gPTP時(shí)間同步協(xié)議實(shí)現(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)容,包含報(bào)文格式定義等內(nèi)容;
gPTP拓?fù)浣Y(jié)構(gòu)
如下圖2所示展示了單一域時(shí)間敏感網(wǎng)絡(luò)的gPTP域拓?fù)浣Y(jié)構(gòu),根據(jù)gPTP協(xié)議規(guī)范了如下域內(nèi)三種類型的以太網(wǎng)節(jié)點(diǎn):
GrandMaster Node(簡(jiǎn)稱GM):在一個(gè)gPTP域內(nèi)有且僅有一個(gè)主時(shí)鐘,即GrandMaster節(jié)點(diǎn),簡(jiǎn)稱GM;
Bridge Node:橋接節(jié)點(diǎn),在一個(gè)gPTP域內(nèi)可以存在多個(gè),但是不能作為時(shí)鐘節(jié)點(diǎn),只能作為透明時(shí)鐘;
Endpoint Node:邊緣節(jié)點(diǎn),作為該gPTP域內(nèi)的從時(shí)鐘節(jié)點(diǎn);
圖2 gPTP單一域節(jié)點(diǎn)拓?fù)浣Y(jié)構(gòu)
其中,gPTP協(xié)議是建立在主從時(shí)鐘關(guān)系上的一種協(xié)議,也就是說(shuō),在一個(gè)網(wǎng)絡(luò)內(nèi)所有節(jié)點(diǎn)都要以Master節(jié)點(diǎn)作為主時(shí)鐘,其余節(jié)點(diǎn)作為從時(shí)鐘,從時(shí)鐘將自己的本地時(shí)間與主時(shí)鐘時(shí)間進(jìn)行同步,同時(shí)時(shí)間同步是可以層次遞進(jìn)的,作為slave節(jié)點(diǎn)的時(shí)鐘也可以作為另一個(gè)局域網(wǎng)內(nèi)的主時(shí)鐘,如網(wǎng)關(guān)節(jié)點(diǎn)。
在上圖中框起來(lái)的區(qū)域如果發(fā)生link錯(cuò)誤,導(dǎo)致current GM無(wú)法將時(shí)間同步信息傳遞進(jìn)該區(qū)域,那么就會(huì)使用到BMCA算法來(lái)實(shí)現(xiàn)新的Master時(shí)鐘選擇, 若發(fā)生此類場(chǎng)景,圖中GNSS邊緣時(shí)鐘節(jié)點(diǎn)將會(huì)被作為新的GM節(jié)點(diǎn)而存在,此時(shí)網(wǎng)絡(luò)中將會(huì)存在兩個(gè)gPTP域。
值得注意的是,AUTOSAR規(guī)范中的EthTsync模塊明確表示不支持BMCA算法,主要是考慮到整車網(wǎng)絡(luò)屬于一個(gè)靜態(tài)網(wǎng)絡(luò),整個(gè)ECU拓?fù)浣Y(jié)構(gòu)上下點(diǎn)電都不會(huì)發(fā)生變化,如果發(fā)生上述連接故障問題也就需要進(jìn)行售后處理,軟件無(wú)需處理該場(chǎng)景。
因此,在車載以太網(wǎng)拓?fù)浣Y(jié)構(gòu)中,gPTP域內(nèi)的GrandMaster主時(shí)鐘均已預(yù)先設(shè)定好,無(wú)需通過BMCA算法來(lái)進(jìn)行動(dòng)態(tài)選擇。
gPTP時(shí)間同步流程
gPTP時(shí)間同步流程可以按照如下先后順序來(lái)進(jìn)行,彼此之間存在依賴關(guān)系:
1. 最佳主時(shí)鐘選擇原理
在gPTP時(shí)間同步協(xié)議中可能在同一域內(nèi)存在多個(gè)可用的全局時(shí)間源,就需要通過一種方式來(lái)選擇全局最佳主時(shí)鐘,這種方法被稱為Best Master Clock Algorithm,簡(jiǎn)稱BMCA算法。
系統(tǒng)上電之后,所有設(shè)備都可以通過一條報(bào)文來(lái)參與主時(shí)鐘的競(jìng)選,報(bào)文中包含各個(gè)設(shè)備的時(shí)鐘信息,每個(gè)設(shè)備都會(huì)主動(dòng)比較自身與其他節(jié)點(diǎn)時(shí)鐘的信息,競(jìng)選失敗的將退出,如此反復(fù),直至最后選擇最佳主時(shí)鐘。
針對(duì)車載以太網(wǎng),無(wú)需通過考慮最佳主時(shí)鐘選擇,車載以太網(wǎng)屬于靜態(tài)網(wǎng)絡(luò),均已提前設(shè)定好。
2. 頻率同步原理
我們知道主從時(shí)鐘底層都是通過晶振驅(qū)動(dòng)來(lái)進(jìn)行計(jì)時(shí),但是不可避免的是晶振會(huì)受到外部溫度,老化等因素影響進(jìn)而產(chǎn)生時(shí)鐘偏移。
因此為了更為精確地保證主從時(shí)鐘的同步,因此需要將主從時(shí)鐘之間的晶振頻率差異考慮在內(nèi),進(jìn)而解決主從端口晶振精度不準(zhǔn)帶來(lái)的時(shí)間同步誤差。
計(jì)算方法如下圖3所示:
圖3 主從時(shí)鐘頻率同步測(cè)量原理
基于圖3中的兩個(gè)周期性的sync報(bào)文與follow-up報(bào)文,其中followup報(bào)文傳輸?shù)氖莝ync報(bào)文在主時(shí)鐘節(jié)點(diǎn)發(fā)送時(shí)刻的時(shí)間戳,考慮主從時(shí)鐘節(jié)點(diǎn)對(duì)于總線傳輸?shù)难訒r(shí)都是固定的,T1,T2,T3,T4都是物理層獲取的時(shí)間戳,因此主從時(shí)鐘節(jié)點(diǎn)的時(shí)鐘偏差可以通過如下公 式來(lái)體現(xiàn):
頻率同步計(jì)算公式
3. Path延時(shí)時(shí)間測(cè)量原理
從時(shí)鐘節(jié)點(diǎn)為了能夠跟主時(shí)鐘同步,除了上述主從時(shí)鐘節(jié)點(diǎn)的時(shí)鐘頻率偏差帶來(lái)的差異外,還存在一個(gè)非常重要的延時(shí)即以太網(wǎng)總線傳輸延時(shí)需要進(jìn)行精確測(cè)量,才能夠保證時(shí)間同步的精度,測(cè)量原理如下圖4所示:
圖4 gPTP延時(shí)時(shí)間測(cè)量原理
注意,Pdelay_Req報(bào)文發(fā)起方既可以是Time Master也可以是Time Slave,本文只不過以Time Slave為例。
延時(shí)時(shí)間Pdelay time的測(cè)量具體步驟如下:
S1:Time Slave節(jié)點(diǎn)發(fā)送Pdelay_Req報(bào)文,Time Slave節(jié)點(diǎn)記錄該報(bào)文發(fā)送時(shí)刻的時(shí)間戳T1;
S2:Time Master記錄MAC層收到Pdelay_Req報(bào)文的時(shí)間戳T2;
S3:Time Master將上述T2時(shí)間通過Pdelay_Resp報(bào)文發(fā)送至Time Slave,同時(shí)Time Master記錄發(fā)送該報(bào)文的時(shí)間戳T3,Time Slave記錄收到該報(bào)文的時(shí)間戳T4;
S4:Time Master將上述T3時(shí)間通過Pdelay_Resp_Follow_Up報(bào)文發(fā)送至Time Slave,當(dāng)Time Slave收到該報(bào)文時(shí)便知道了T1,T2,T3,T4時(shí)間戳;
考慮到主從時(shí)鐘之間的時(shí)鐘頻率偏差以及主從時(shí)鐘之間的延時(shí)對(duì)稱原理,因此Pdelay time的計(jì)算方法如下所示:
Pdelay計(jì)算公式
值得注意的是上述公式中如果主從時(shí)鐘頻率一致,那么此時(shí)P=1。
4. 時(shí)間同步原理
基于上述計(jì)算出來(lái)的總線延時(shí)時(shí)間Pdelay time以及主從時(shí)間頻率的比值,也被稱為NeighborRateRatio,那么便可以完成從時(shí)鐘節(jié)點(diǎn)與主時(shí)鐘之間的同步,其同步原理如下圖5所示:
圖5 gPTP時(shí)間同步原理
如上圖5所示,基于gPTP的時(shí)間同步協(xié)議通過SYNC報(bào)文與FollowUp報(bào)文來(lái)實(shí)現(xiàn)同步,同步流程如下:
S1:Time Master發(fā)送SYNC報(bào)文,該報(bào)文如果是單步模式,那么就需要攜帶T1時(shí)間戳信息,如果是雙步模式,該報(bào)文無(wú)需發(fā)送任何有效信息;
S2:Time Slave收到SYNC報(bào)文之后,MAC層會(huì)記錄對(duì)應(yīng)時(shí)刻的時(shí)間戳T2;
S3:若基于雙步模式,Time Master再發(fā)送Follow up報(bào)文,該報(bào)文中攜帶著SYNC報(bào)文外發(fā)時(shí)刻的時(shí)間戳T1;
基于上述流程,我們便可以得到從時(shí)鐘節(jié)點(diǎn)與主時(shí)鐘節(jié)點(diǎn)的時(shí)間同步關(guān)系,設(shè)某時(shí)刻Time Master的全局時(shí)間為T6,對(duì)應(yīng)此時(shí)刻的Time Slave 本地時(shí)間為T5,因此時(shí)間同步關(guān)系如下:
其中Pdelay time通過上述延時(shí)時(shí)間測(cè)量過程得到,最終得到的Time Master與Time Slave的同步時(shí)間關(guān)系。
注意:gPTP時(shí)間同步過程可分為單步模式與雙步模式,單步模式(one step)對(duì)以太網(wǎng)PHY硬件要求較高,需要能夠精準(zhǔn)獲取發(fā)送時(shí)刻的時(shí)間,因此普遍采用雙步模式來(lái)完成時(shí)間同步,以便降低集成難度。
對(duì)于AUTOSAR規(guī)范中定義的gPTP時(shí)間同步協(xié)議而言,默認(rèn)采用雙步模式(two step)。
gPTP與PTP協(xié)議區(qū)別與聯(lián)系
前面講到gPTP協(xié)議屬于IEEE802.1AS規(guī)范中的內(nèi)容,而對(duì)于PTP協(xié)議則是屬于IEEE1588 協(xié)議中的內(nèi)容,gPTP協(xié)議是基于傳統(tǒng)意義上的PTP協(xié)議發(fā)展而來(lái),兩者存在很多的相似點(diǎn),但也有很多差異,這種差異的來(lái)源主要還是兩者針對(duì)時(shí)間同步的精度不同。
其中g(shù)PTP協(xié)議由TSN工作組進(jìn)行制定,TSN工作組屬于原先的AVB工作組。
對(duì)于gPTP協(xié)議而言專用于時(shí)間敏感網(wǎng)絡(luò)(TSN),時(shí)間同步精度要求較高,而傳統(tǒng)的PTP時(shí)間同步協(xié)議無(wú)法滿足該要求,如下圖6展示了兩者協(xié)議的相似點(diǎn)與差異:
圖6 gPTP與PTP協(xié)議區(qū)別
AUTOSAR中g(shù)PTP協(xié)議介紹
相比IEEE802.1AS規(guī)范中定義的gPTP協(xié)議,AUTOSAR組織結(jié)合車載網(wǎng)絡(luò)應(yīng)用場(chǎng)景針對(duì)其部分內(nèi)容也做了進(jìn)一步限制與約束,以便能夠更加靈活應(yīng)用,降低整個(gè)系統(tǒng)的集成難度。
AUTOSAR規(guī)范中的gPTP主要約束條件如下:
由于車載網(wǎng)絡(luò)屬于靜態(tài)網(wǎng)絡(luò),不支持BMCA算法;
不支持Anounce與Signaling報(bào)文的發(fā)送與接收;
Pdelay_Req不作為開啟發(fā)送SYNC報(bào)文的前置條件;
IEEE802.1AS規(guī)定不能發(fā)送帶有VLAN信息的時(shí)間同步報(bào)文,但AUOTSAR允許使用帶有VLAN信息的報(bào)文,前提是網(wǎng)關(guān)支持轉(zhuǎn)發(fā)預(yù)留的多播地址01C200:00 .. 0F的報(bào)文;
報(bào)文中的CRC保護(hù)措施不能作為信息安全的內(nèi)容;
報(bào)文類型與格式
在AUTOSAR中的gPTP協(xié)議支持SYNC, Follow-up,Pdelay_Req,Pdelay_Resp, Pdelay_Resp_Follow_up 五類報(bào)文。
其中SYNC,Pdelay_Req, Pdelay_Resp報(bào)文屬于事件型報(bào)文,因?yàn)槎夹枰涗浭瞻l(fā)時(shí)刻的時(shí)間戳,而Follow-up,Pdelay_Resp_Follow_up則屬于一般性報(bào)文,因?yàn)椴挥涗浽擃愂瞻l(fā)時(shí)刻的時(shí)間戳,僅關(guān)注其承載信息,如下圖所示。
圖7 gPTP時(shí)間同步報(bào)文類型定義
上述五類報(bào)文按照AUTOSAR定義可以通過參數(shù)MessageCompliance來(lái)進(jìn)行統(tǒng)一控制,如果該參數(shù)為TRUE,則需要采用IEEE802.1AS規(guī)范下的報(bào)文格式,如果該參數(shù)為FALSE,則使用AUTOSAR規(guī)范下的報(bào)文格式。
該五類報(bào)文格式均由頭信息格式,Paload格式,數(shù)據(jù)類型(TLV若有)組成,同一規(guī)范下的五類報(bào)文均具有相同的頭信息格式定義。
以IEEE802.1AS規(guī)范下的SYNC報(bào)文頭信息格式為例,如下圖所示:
SYNC Message頭信息定義(IEEE802.1AS)
圖8 gPTP時(shí)間同步報(bào)文類型定義
上述各參數(shù)解釋如下表:
圖9 IEEE802.1AS規(guī)范下sync報(bào)文頭信息定義
SYNC Message Payload定義(IEEE802.1AS)
如下圖所示為SYNC報(bào)文的Payload定義以及說(shuō)明:
圖10 IEEE802.1AS規(guī)范下Payload定義說(shuō)明
根據(jù)IEEE802.1AS規(guī)范下的SYNC報(bào)文頭信息總共占用34個(gè)字節(jié),保留了10個(gè)字節(jié)作為備用,也就意味著SYNC報(bào)文除具備gPTP的頭信息以外,不具備其他有效信息。
Follow_Up Message頭信息定義(IEEE802.1AS)
如下圖所示為Follow Up message的頭信息定義說(shuō)明,可以看出基本與上述SYNC報(bào)文基本一致。
圖11 IEEE802.1AS規(guī)范下Payload定義說(shuō)明
圖11中每個(gè)參數(shù)的定義說(shuō)明可直接參考圖9,按照相應(yīng)的報(bào)文類型對(duì)號(hào)入座即可。
Follow Up Message Payload定義(IEEE802.1AS)
?
圖12 IEEE802.1AS規(guī)范下Follow up報(bào)文Payload定義
如下圖13所示為IEEE802.1AS規(guī)范下Follow up報(bào)文Payload與標(biāo)準(zhǔn)TLV字段解釋說(shuō)明:
圖13 IEEE802.1AS規(guī)范下Follow up報(bào)文Payload解釋說(shuō)明
SYNC Message頭信息定義(AUTOSAR)
與IEEE802.1AS規(guī)范下的SYNC報(bào)文頭信息相比,除了domain number有些區(qū)別以外,其余均相同,AUTOSAR規(guī)范下的domain ID為0-15,而IEEE802.1AS規(guī)范下的SYNC報(bào)文則固定為0。
SYNC Message Payload定義(AUTOSAR)
AUTOSAR規(guī)范下的SYNC報(bào)文與IEEE802.1AS規(guī)范下的SYNC報(bào)文Payload內(nèi)容一致,不再過多贅述。
Follow_Up Message頭信息定義(AUTOSAR)
AUTOSAR規(guī)范下的Follow_Up Message 與IEEE802.1AS規(guī)范下Follow_Up Message相比,在Length of Message長(zhǎng)度方面多增加了一些字節(jié),其余沒有區(qū)別,原因是由于AUTOSAR規(guī)范下的Follow_Up Message增加了諸多TLV字段。
Follow Up Message Payload定義(AUTOSAR)
新增的AUTOSAR TLV字段如下圖14所示:
?
?
?
?
?
?
圖14 AUTOSAR規(guī)范下Follow up報(bào)文新增TLV字段定義
由于AUTOSAR規(guī)范下的新增TLV內(nèi)容較多,主要是針對(duì)各種TLV做的CRC計(jì)算規(guī)則會(huì)有些許差異,基本原理一致,不復(fù)雜,由于篇幅原因,小T就不過多對(duì)這些TLV進(jìn)行贅述,大家可自行進(jìn)行研究。
Pdelay_Req報(bào)文格式定義
如下圖15所示為IEEE802.1AS定義的報(bào)文格式定義:
圖15 Pdelay_Req報(bào)文格式定義
上圖中header與SYNC Message頭信息定義(IEEE802.1AS)中一致,該報(bào)文共占用54個(gè)字節(jié),除了header信息外沒有其他Payload信息。
Pdelay_Resp報(bào)文格式定義
圖16 Pdelay_Resp報(bào)文格式定義
上圖中header與SYNC Message頭信息定義(IEEE802.1AS)中一致,該報(bào)文共占用54個(gè)字節(jié), 圖中兩個(gè)變量解釋如下:
requestReceiptTimestamp:該值是Pdelay_Req報(bào)文發(fā)送時(shí)刻的s與ns部分;
requestingPortIdentity:該值應(yīng)與Pdelay_Req報(bào)文中的sourcePortIdentity字段一致;
Pdelay_Resp_Follow_Up報(bào)文格式定義
圖17 Pdelay_Resp_Follow_up報(bào)文格式定義
上圖中header與SYNC Message頭信息定義(IEEE802.1AS)中一致,該報(bào)文共占用54個(gè)字節(jié), 圖中兩個(gè)變量解釋如下:
responseOriginTimestamp:發(fā)送Pdelay_Resp報(bào)文時(shí)刻的s部分與ns部分;
requestingPortIdentity:該值應(yīng)與Pdelay_Req報(bào)文中的sourcePortIdentity字段一致;
除了解上述Path延時(shí)測(cè)量相關(guān)報(bào)文格式以外,AUTOSAR定義的Path延時(shí)時(shí)間測(cè)量機(jī)制還需要注意如下幾個(gè)關(guān)鍵點(diǎn):
EthTsync模塊通過Pdelay_Req,Pdelay_Resp,Pdelay_Resp_Follow_Up報(bào)文來(lái)進(jìn)行延遲測(cè)量;
Pdelay_Res超時(shí)發(fā)出接收節(jié)點(diǎn)將會(huì)中止本次延時(shí)測(cè)量,接收節(jié)點(diǎn)默認(rèn)使用上次延時(shí)測(cè)量的結(jié)果;
主從時(shí)鐘節(jié)點(diǎn)均需要周期性發(fā)送Pdelay_Req報(bào)文來(lái)進(jìn)行彼此的Path延時(shí)時(shí)間測(cè)量,發(fā)送報(bào)文周期可通過EthTSynGlobalTimeTxPdelayReqPeriod來(lái)控制;
Pdelay_Resp_Follow_Up報(bào)文的發(fā)送時(shí)間可以通過參數(shù)EthTSynGlobalTimeTxFollowUpOffset配置;
上述五類報(bào)文的目標(biāo)MAC地址均統(tǒng)一為01-80-C2-00-00-0E, 源MAC地址為各自報(bào)文發(fā)送的端口地址;
上述五類報(bào)文的EtherType統(tǒng)一為88-F7;
Time Master行為
在gPTP網(wǎng)絡(luò)中作為Time Master的節(jié)點(diǎn)存在著如下報(bào)文處理流程:
Time Master負(fù)責(zé)SYNC報(bào)文與Follow-Up報(bào)文的發(fā)送,SYNC報(bào)文可以通過設(shè)置參數(shù)EthTSynGlobalTimeTxPeriod來(lái)進(jìn)行周期性發(fā)送,在發(fā)送SYNC報(bào)文的過程中需進(jìn)行如下三個(gè)基本步驟:
通過函數(shù) EthIf_ProvideTxBuffer來(lái)獲取空閑的buffer來(lái)存儲(chǔ)發(fā)送的數(shù)據(jù);
如果參數(shù)EthTSynHardwareTimestampSupport設(shè)置為TRUE,那么可通過函數(shù)EthIf_EnableEgressTimeStamp來(lái)激活硬件時(shí)間戳功能;
通過調(diào)用函數(shù)Ethif_Transmit來(lái)觸發(fā)報(bào)文的發(fā)送;
當(dāng)參數(shù)EthTSynHardwareTimestampSupport設(shè)置為TRUE,通過調(diào)用函數(shù)EthTSyn_TxConfirmation來(lái)獲取SYNC報(bào)文外發(fā)時(shí)刻的時(shí)間戳;
通過設(shè)置參數(shù)EthTSynGlobalTimeTxFollowUpOffset來(lái)決定SYNC報(bào)文發(fā)送之后多久發(fā)送Follow_Up報(bào)文,F(xiàn)ollow_Up報(bào)文發(fā)送需經(jīng)過如下兩個(gè)基本步驟:
通過函數(shù) EthIf_ProvideTxBuffer來(lái)獲取空閑的buffer來(lái)存儲(chǔ)發(fā)送的數(shù)據(jù);
通過調(diào)用函數(shù)Ethif_Transmit來(lái)觸發(fā)報(bào)文的發(fā)送;
通過函數(shù) EthTSyn_TrcvLinkStateChg來(lái)獲取當(dāng)前使用的PHY狀態(tài),當(dāng)PHY狀態(tài)由 ETHTRCV_LINK_STATE_ACTIVE 切換成ETHTRCV_LINK_STATE_DOWN時(shí)就會(huì)重置所有時(shí)間同步報(bào)文的發(fā)送與接收狀態(tài)機(jī)。
通過函數(shù) EthTSyn_TrcvLinkStateChg來(lái)獲取當(dāng)前使用的PHY狀態(tài),當(dāng)PHY狀態(tài)由 ETHTRCV_LINK_STATE_DOWN切換成ETHTRCV_LINK_STATE_ACTIVE時(shí)就會(huì)重啟所有時(shí)間同步報(bào)文的發(fā)送與接收。
可通過調(diào)用函數(shù)EthTSyn_SetTransmissionMode并設(shè)置成ETHTSYN_TX_OFF,所有發(fā)送的請(qǐng)求將會(huì)被禁止發(fā)送,設(shè)置成ETHTSYN_TX_ON則所有的報(bào)文發(fā)送請(qǐng)求均會(huì)被接受;
Time Slave行為
在gPTP網(wǎng)絡(luò)中作為Time Slave的節(jié)點(diǎn)存在著如下報(bào)文處理流程:
如果EthTSynHardwareTimestampSupport設(shè)置成TRUE, Time Slave節(jié)點(diǎn)可以通過函數(shù)EthTSyn_RxIndication來(lái)獲取SYNC報(bào)文接收到的時(shí)間戳;
Time Slave可通過配置參數(shù)EthTSynGlobalTimeFollowUpTimeout來(lái)實(shí)現(xiàn)SYNC報(bào)文接收之后Follow_Up報(bào)文的超時(shí)監(jiān)控,一旦發(fā)生超時(shí),那么本次時(shí)間同步將失效,等待下次新的時(shí)間同步序列;
如果EthTSynHardwareTimestampSupport設(shè)置成TRUE, Time Slave節(jié)點(diǎn)收到有效的Follow_Up報(bào)文之后,本地時(shí)間與Follow_Up發(fā)送的全局時(shí)間差距超過 EthTSynTimeHardwareCorrectionThreshold,那么就需要調(diào)用函數(shù)EthIf_SetCorrectionTime來(lái)進(jìn)行重置本地時(shí)間;
如果EthTSynHardwareTimestampSupport設(shè)置成FALSE, Time Slave就需要計(jì)算出全局時(shí)間,然后通過函數(shù)StbM_BusSetGlobalTime來(lái)實(shí)現(xiàn)時(shí)間同步;
常用函數(shù)接口
為了便于大家更好地使用EthTsync這個(gè)模塊,小T整理了關(guān)于車載以太網(wǎng)時(shí)間同步模塊這部分常用的函數(shù)接口與功能說(shuō)明,如下圖18所示:
圖18 常用函數(shù)接口說(shuō)明 ? ? ?
編輯:黃飛
?
評(píng)論
查看更多