連載二:基於AURIX™ TC3xx時間敏感性網絡系統助力車載網絡TSN協議實現

作者:英飛凌汽車電子生態圈 同濟大學


本文長約9000字,乾貨滿滿,建議收藏。

上一篇我們提到針對常用TSN協議實現的難點,同濟大學開發了基於英飛凌AURIX™ TC3xx的時間敏感性網絡演示系統。今天,我們將結合IEEE 802.1AS,IEEE 802.1Qbv,IEEE 802.1CB協議標準,深入解析基於英飛凌AURIX™ TC3xx的時間敏感性網絡演示系統如何解決這些難點。

一、系統特性介紹

圖1 系統架構

系統的整體結構如圖所示,由一個主控節點N1,兩個視頻轉發節點N2和N3,一個音頻節點N4以及兩個帶攝像頭的樹莓派節點組成。其中N2節點同時還是車模的控制節點。N1-N4每個節點都包含以太網交換機和主控MCU TC3x7。四節點組成的主幹網絡通過1000BASE-T1連接形成環形網絡。

視頻流由兩個樹莓派節點生成並傳輸至N2和N3,並最終根據設計的路徑到達PC,並在上位機上顯示。音頻文件存儲在上位機中,由上位機發往N4音頻節點,通過音頻模塊和音響實現播放。控制報文以以太網的格式從上位機發出,到達N2節點後轉換成CAN報文,並發送給車模節點,實現車門和車燈的控制。

IEEE 802.1AS是網絡的基礎,用於所有節點的時間同步。其中N2的TC377為全局的主時鐘節點,其他節點交換機和控制器均以該節點時間為參考進行時間同步。同時通過上位機可以動態的對上述既定的音視頻流量和控制流量進行TSN協議的配置,例如IEEE 802.1Qbv、IEEE 802.1CB、IEEE 802.1Qci和基於TC3xx系列實現的端節點分時調度機制。除此之外上位機還能控制網絡中干擾流量的生成,通過視頻卡頓的直觀感受和視頻流實時端到端延時散點圖,端和橋中應用TSN協議後的實際效果和性能可以被清晰直觀的反應。

整個系統實物如圖所示:

圖2 系統實物
二、 IEEE802.1AS時間同步協議的實現原理和演示

1.  IEEE802.1AS實現原理介紹

IEEE 802.1AS精準時間同步協議(Precise Time Protocol,簡稱PTP)基於IEEE Std 1588:2008協議,定義了整個網絡的時間同步機制。PTP協議的同步機制的實現包括了三個方面,分別是主時鐘自主協商與選擇,路徑延遲計算與校正以及時鐘同步和校準。

PTP定義了主時鐘自主協商與選擇算法,也就是最優主時鐘算法(Best Master Clock Algorithm,簡稱BMCA)。BMCA定義了底層的協商和信令機制,用於選擇出網絡中的主時鐘(Grandmaster),而主時鐘一旦選定,網絡中的其他節點都將被同步到主時鐘的時間上,以主時鐘的時間作為參考值。而當網絡因為線路失敗等原因出現故障時,網絡會在短時間內重啟BMCA算法,並挑選出一個新的主時鐘作為其新的參考值,以此確保網絡能一直保持同步。而在汽車領域,控制器有啟動時間的要求,所以BMCA一般不推薦在車載網絡中使用,而使用靜態主時鐘預設的方法。

支持PTP協議的設備通過交換標準的以太網消息,將整個網絡中的節點的時間同步到一個共同的時鐘,網絡中所有的事件都基於這個時鐘來考慮,從而達到網絡時間同步的過程。PTP協議的同步機制通過在網絡設備中周期性地發送包含同步信息的事件報文,各設備通過交換包含同步信息的事件報文,使得網絡中的設備實現精確的時鐘調整和頻率匹配,使得整個PTP網絡同步到相同的時鐘上,保證了網絡中的同步以及誤差。

IEEE 802.1AS的核心在於它的時間戳機制。在AVB網絡中,所有的報文被分為事件報文和普通報文。事件報文通過支持PTP功能的埠時,就會觸發協議對本地時鐘(RTC)的採樣,將自身的時鐘採樣值與來自該埠的主時鐘(Grandmaster)的時間信息進行對比,利用路徑延遲與校正功能,將本地的時鐘採樣值匹配到PTP域的主時鐘的時間值,於是對該事件報文打上的時間戳就是整個網絡已經同步後的時間值。普通報文經過埠則不會被打上時間戳。

  • 路徑延遲計算與校正
PTP協議的時間同步的實現過程簡單來說和IEEE Std 1588:2008是一樣的:由最優主時鐘發出包含當前同步時間的信息,其他的時間感知系統在接收到這個信息後,通過將傳播時間添加到同步時間上來校正自己的時間,當收到該信息的時間感知系統為時間感知橋時,還要把自己的轉發時間添加進去。因此,為了保證整個網絡更精確地運轉,有兩個時間必須要被精確測量:轉發時間(也叫生存時間)和報文在兩個時間感知系統之間傳播的路徑延時。對於轉發時間,由於轉發過程是在交換機之中進行的,因此可以通過查看該報文進出交換機的時間便可以輕鬆得到這個時間。然而通信路徑延時卻有很多印象因素,其中包括介質依賴特性和路徑長度。

IEEE 802.1AS協議里說明了三種傳輸方式(包括全雙工以太網鏈路、IEEE 802.11無線傳輸以及EPON),每一種不同的傳輸方式都有不同的方法來測量傳播時間,但它們都是基於相同的原則:測量一個設備A發出一幀特定報文的時間,緊接著在接收設備B測量該設備接收到該特定報文的時間,然後反過來,由設備B發出另一幀特定的報文,再測量這幀報文的發送時間和接收時間。該機制的實現過程可以通過下圖來說明:


圖3 對等延時測量計算圖

傳輸路徑延時的測量計算是由通信路徑一端的時間感知系統發起的,該時間感知系統被稱為對等延時機制發起者,傳輸路徑的另一端則被稱為對等延時機制響應者。傳輸路徑延時的測量從發起者發出報文開始,這一幀報文成為Pdelay_Req,對等延時機制發起者同時記錄下這幀報文的發出時間t1,然後對等延時機制響應者在t2接收到這一幀報文;對等延時機制響應者在收到該報文後,發出一幀Pdelay_Resp,並記錄下這幀報文的發出時間t3,同時,該報文包含了對等延時機制響應者收到Pdelay_Req的時間t2;在發出Pdelay_Resp後,對等延時機制響應者隨即發出一幀Pdelay_RespFollowUp報文,報文里包含了Pdelay_Resp報文的發出時間t3;對等延時機制發起者收到Pdelay_Req報文時會記錄下接收時間t4,在接收到Pdelay_RespFollowUp報文後,對等延時機制發起者就得到了計算傳輸路徑延時的所需全部時間t1、t2 、t3和t4。通過這四個時間,對等延時機制發起者便可以計算出它和對等延時機制響應者傳輸路徑的延時:

其中,tir和tri分別代表傳輸路徑上不同方向的傳播時間,tp表示傳輸路徑上的平均傳輸路徑延時。由公式(3)可以看出,傳輸路徑延時的精度取決於t1、t2 、t3和t4的測量精度。而三個公式的計算都是基於對等延時機制發起者和對等延時機制響應者都是基於相同的時鐘頻率和相位的。但實際上,t1和t4是在對等延時機制發起者本地時鐘下獲取的,而t2和t3是在對等延時機制響應者本地時鐘下獲取的。如果要把對等延時機制響應者的時間戳信息歸一化到對等延時機制發起者的時鐘上,那麼t2和t3的差就必須乘以一個頻率比;同理,如果要把對等延時機制發起者的時間戳信息歸一化到對等延時機制發響應者的時鐘上,也要將t1和t4的差乘以一個相應的頻率比,否則這樣測量出來的傳輸路徑延時會存在誤差。當需要把這個傳輸路徑延時歸一化到全網絡的最優主時鐘上時,就要將相應的時間差乘以各自以最優主時鐘為參考的頻率比,這樣就得到以最優主時鐘為參考的所有設備之間的傳輸路徑延時。

  • 時鐘同步和校準
時鐘校準機制的實現原理如所示,在數學上等效於IEEE 1588-2008中描述的用於兩步對等透明同步時鐘機制。

圖4 時鐘同步和校準機制

如圖表示三個相鄰的時間感知系統i-1,i以及i+1。同步報文從時間感知系統i-1傳輸到i再傳輸到i+1。時間感知系統i-1向時間感知系統i發送Sync報文的時間戳為ts,i-1(以時間感知系統i-1的本地時鐘實體為時間基準)。之後,時間感知系統i-1又向時間感知系統i發送相關聯的Follow_Up報文,其包含preciseOriginTimestamp(精確的原始時間)、correctionFieldi-1(修正域)和rateRatioi-1(頻率比)。精確的原始時間指由最優主時鐘發起Sync報文的時間,該值在時鐘生成樹的一次傳播上通常不會被改變,修正域包含當前發送Sync報文的時間感知系統發送Sync報文的時間(即對應於本地時間ts,i-1)與精確的原始時間之間的偏差,precisionOriginTimestamp和correctionFieldi-1。頻率比是最優主時鐘的頻率與當前發送Sync報文的時間感知系統的本地時鐘實體的頻率比值。

時間感知系統i接收到Sync報文並產生相應的時間戳tr,i(相對本地時鐘實體),並在之後接收到與Sync報文對應的Follow_Up報文。

時間感知系統i最終在ts,i時刻(相對本地時鐘實體)時向時間感知系統i+1發送Sync報文,時間ts,i發生在從時間感知系統i-1接收到Follow_Up消息之後。此時時間感知系統i需要計算correctionFieldi欄位,即對應於ts,i的同步時間和preciseOriginTimestamp之間的差值。此間隔包括兩部分內容:時間感知系統i-1和i之間的鏈路上的傳播延遲以及ts,i和tr,i之間的差(即停留時間),均以最優主時鐘的本地時鐘實體作為時間基準。

2. IEEE802.1AS演示

在演示系統中,N2節點的TC377為全局的主時鐘節點,系統內其他節點的MCU和交換機為從節點,接收來自N2節點的時間同步信息。

端節點和橋節點在上電後自行運行時間同步協議棧,位於四塊板卡上的這兩個PPS的紅色LED燈光指示大致同步情況,同時每個控制器節點的時間同步狀態會上傳至上位機,在上位機端顯示大致的同步情況。

圖5 時間同步實驗結果(PPS波形)

時間同步的真實精度,可以通過示波器觀察PPS引腳的上升沿重合情況確定。使用示波器餘暉模式持續觀察PPS信號並記錄,如圖,示波器橫坐標一格為100ns,七跳的時間精度可以維持在正負400ns以內,高於協議要求的七跳1us精度要求。

三、IEEE802.1Qbv時間整形協議的實現原理和演示

1. IEEE802.1Qbv實現原理介紹

IEEE 802.1Qbv協議針對報文轉發過程進行了一些增強,主要是定義了支持流量調度的報文的轉發過程,提供了基於時間調度機制的隊列消息流量整形控制,由此達到了降低高實時性要求的關鍵性報文流量被實時性要求較低的非關鍵性報文流量干擾的機率,從而保證交換網絡中數據流量傳輸的時間確定性,協議同時還支持VLAN網絡和非VLAN網絡的流量調度通信。IEEE 802.1Qbv協議將報文按照VLAN優先級劃分到不同的隊列中,每一個隊列內部可以有其它的選擇邏輯(如嚴格優先級傳輸選擇策略和基於信用值的傳輸選擇策略等),每一個隊列的選擇發送則嚴格按照分時調度的方式進行。

IEEE 802.1Qbv協議在實現調度的過程中引入了傳輸窗口的概念,每一個傳輸窗口都對應著一個隊列,傳輸窗口具有開和閉兩個狀態,分別對應著相應的隊列是否被發送。當一個隊列的傳輸窗口打開時,意味著該隊列的報文可以被其相應的傳輸選擇算法發送出去;而當傳輸窗口閉合時,則不允許發送該隊列的報文。

圖6 帶傳輸窗口的傳輸選擇算法

傳輸窗口的狀態是由窗口控制列表決定的,每一個埠都有一個與之相關聯的窗口控制列表,其包含了窗口控制的順序,每一次調度都會通過窗口控制列表來改變埠中隊列的傳輸窗口狀態。對於不支持時間調度通信的系統而言,相當於所有的傳輸窗口始終處於打開狀態。

傳輸窗口由兩個參數,窗口狀態參數表示埠中每個隊列的窗口的狀態值,開啟或關閉狀態。傳輸窗口則會立即設置為窗口狀態參數中指示的狀態,因此,當列表中下一時刻的窗口狀態與上一時刻的狀態不一致時,在任何隊列中都會產生關閉窗口事件或開啟窗口事件。另一個參數為時間間隔,表示的是上一次傳輸窗口控制和下一次傳輸窗口控制的間隔。

正是有了通過控制傳輸窗口的手段,才使得對實時性要求高的關鍵報文得以被通過分時調度的方式及時發送出去。尤其是在多類報文對實時性要求高,而又可能會相互響應的情況下,這時候就需要保證在特定的時間內,只有同一類關鍵性報文會被發送,從而協調這些關鍵性報文的發送而又不影響其實時性,其具體實現如下圖所示:


圖7 使用傳輸窗口控制的調度


當實時性要求高的等級為3的隊列中有報文等待發送時,由於此時正在有一些對實時性要求不高的數據在發送,這個時候,首先是需要對隊列3需要發送時間T1之前的一段時間(guard band,T0到T1)對網絡進行保護,以免非關鍵性報文占用了網絡資源,然後在T1設置傳輸窗口的狀態為ccccoccc,即關閉其他傳輸而只打開隊列3的傳輸窗口,以保證關鍵性報文的及時傳輸。當隊列3的傳輸窗口的打開時間T2之後,則設置傳輸窗口的狀態為oooocooo,即關閉隊列3的傳輸窗口而打開其他隊列的傳輸窗口,以保證其他數據的正常發送。

2. TC3xx GETH的Time Slot功能介紹

TC3xx GETH支持Time Slot機制,該機制能實現對報文傳輸時刻進行精確控制。Time Slot機制在功能層面類似於 802.1Qbv 協議中規定的分時調度機制,因此可以通過Time Slot機制實現類分時調度機制。

TC3xx Time Slot機制的實現原理如下圖所示,MAC時間被周期性地劃分為多個大小相等的時間槽(Slot),並且每一幀待發送以太網報文都能夠綁定一個指定時間槽去發送。時間槽功能在底層是通過TC3xx的DMA模塊實現的。為了減少CPU干預,TC3xx利用DMA將報文從系統內存中搬運到以太網接口的發送隊列中進行傳輸,報文的控制欄位被存儲在一種名為描述符(Descriptor)的結構體中。用戶可以在描述符中設置一個名為時間槽編號值(Slot Number Value)的參數,DMA 只能在該參數指定的時間槽內將報文轉移到發送隊列進而發送,從而實現了在特定時間槽發送報文的功能。


圖8 timeslot機制原理示意圖

Time Slot功能相關的參數配置主要包括時間槽功能初始化以及以太網報文與發送時間槽綁定兩個過程。

在時間槽功能初始化階段,其配置圍繞SLOT_FUNCTION_CONTROL_STATUS寄存器展開,針對發送通道的單個時間槽長度參數和是否使能時間槽比較功能進行配置。

對於以太網報文與發送時間槽綁定的過程,主要是針對描述符 TDES3部分的 SLOTNUM_THL欄位進行配置,設定當前報文的具體傳輸時間槽,待時間槽序列進行到設定時間槽後再開始數據發送。

完成上述報文描述符配置後,將報文通過配置好的發送通道進行發送,那麼報文就能夠在對應的時間槽內被發送。

時間槽機制與標準的Qbv機制相比,存在著一些局限性。在分時調度表配置層面,標準 802.1Qbv 分時調度機制需要分時調度表內的每個條目均有自己的觸發時長,其單個時間片長度和時間片內門控開啟情況也要是可獨立控制的。TC3xx 的時間槽機制規定一個循環周期內存在 16 個時間槽,且單個時間槽的長度範圍為 1~4096 微秒,且各時間槽長度均相等,通過劃定報文的指定發送時間槽即可控制報文的發送窗口,這種特性限制了時間片的長度獨立可控,其控制粒度限制了 TC3xx 可實現的調度複雜性上限。

3. 為什麼需要端節點支持time slot?
端節點支持time slot具有重要意義,基於time slot功能可以在端節點實現類Qbv的分時調度功能,只有這樣才能真正保證網絡中流量的確定性傳輸。如果在TSN網絡中,只是交換機具有分時調度能力,那麼來自端節點的以太網數據幀可能以不確定的順序和時刻到達交換機的接收埠。若此時交換機的門控列表處在關閉狀態,那該幀數據就會被緩存堵塞,造成端到端延時增加和不確定。若緩存超過交換機隊列上限,甚至會出現丟包情況。相反,如果端節點和交換機均具有分時調度能力,那麼端節點可以計劃發送各數據流的時間,以便在已知的順序和時刻到達交換機,兩者的門控相互配合,使該幀數據在交換機的駐留時間達到最低。
4. 如何解決端節點和switch時間窗不對齊的問題?
不失一般性,我們假設數據流的周期T=800us,優先級為7。在MCU端,由於時間槽數量固定為16,所以可以將單個時間槽長度(SIV)設為50us,並在每個slot1到來前準備一幀報文,將報文描述符的 SLOTNUM_THL 欄位的值設置為1,那麼在每個slot1到來時,MCU將發出一幀報文,實現了以800us為周期的數據流發送。

在交換機端,門控列表的循環周期設置為800us,並配置兩條表項。如圖所示,在循環周期的前100us中,隊列7的門控打開,讓時間敏感流的報文順利通過,而其餘隊列的門控關閉,以免來自非關鍵流量報文的干擾。而循環周期剩下的700us中,隊列7的門控關閉,因為這段時間內沒有來自時間敏感流的報文抵達交換機,而其餘隊列的門控開啟,讓非關鍵流量的報文得以傳輸。

TC3xx MCU的時間槽基準時鐘來源於MAC時鐘,在上電後,二者是對齊的。因此上述配置情況適用於MCU作為AS主時鐘的情況,在這種情況下,MAC時鐘上電不會被修改,因此時間槽的基準時鐘和同步域中各節點的MAC時鐘是對齊的。

而當MCU作為AS從時鐘時,MAC時鐘在上電後會被修改,導致時間槽基準時鐘和同步域各節點MAC時鐘不一致。在同步達到穩定狀態後,兩個時鐘之間存在一個穩定但未知的偏差值delta。由於交換機門控列表的時鐘源是MAC時鐘,所以如圖所示,此時MCU如果仍然在slot1發送報文,顯然無法做到在敏感流所屬隊列門控打開的時間段發出報文,不符合預期的效果。
這種情況下需要將報文發送的時間槽從1換為7,這樣每幀報文又在門控打開的時間內被發送了。所以在MCU作為AS從時鐘的情況下,為了讓MCU實現在門控開啟時間段內發送報文,需要根據上述兩個時鐘之間的偏差delta推算出應該在哪個時間槽發送報文,即正確的時間槽。

可通過如下方式推算出正確時間槽的具體數值。假設MAC時鐘比時間槽基準時鐘快了t1。那麼將它除以單個時間槽長度得到t1/T=5。這說明門控開啟時間位於時間槽6的中間,意味著時間槽7完整地落在門控開啟的時間內,因此需要改到時間槽7去發送,實現在交換機門控開啟時間內發出報文的效果。

因此正確時間槽計算公式如下: correct_slot=delta/slot_length+2。但是當偏差delta大於16個時間槽的長度時,按上述公式計算出的correct_slot大於16,顯然不正確。如圖所示,當偏差為t2時,正確的時間槽也是7,和偏差為t1的情況一樣。所以可以先將偏差對16*slot_length取余,即norm_delta=delta%(16*slot_length)。然後按下述公式計算出正確的時間槽。correct_slot=norm_delta/slot_length+2;

在上述公式中,只有delta是未知量,可以通過以下方式獲取這個MAC時鐘和時間槽基準時鐘間的偏差值。首先MAC時鐘可以直接讀取寄存器獲得,而時間槽基準時鐘無法直接獲取,因此需要藉助第三個時鐘systemtime來間接得到。由於MCU上電後,時間槽的時鐘和MAC時鐘是對齊的,並且systemtime和時間槽基準時鐘上電後都無法修改,二者始終保持一個恆定的偏差initdelta,我們在上電後立刻讀取這個偏差initdelta=mactime-systemtime。因此systemtime+initdelta就代表時間槽時基的時鐘值,在任何時刻都可以通過讀取systemtime來獲取時間槽的時鐘值。因此MAC時鐘被修改後,MAC時鐘和時間槽時基的偏差計算公式為delta=mactime-(systemtime+initdelta)=mactime-systemtime-initdelta。

綜上當MCU作為AS從節點時,交換機的配置無需改變,而MCU端配置方面,需要將將報文描述符的 SLOTNUM_THL 欄位改為通過上述方式計算出的正確的時間槽。
5. IEEE802.1Qbv演示+Time slot演示


上面是系統Qbv協議演示,網絡內未添加干擾流量時,視頻流顯示功能正常,當在網絡內添加中等流量時,N2生成干擾流量經過N1發往上位機,N4同樣生成干擾流量發往上位機,此時視頻幀被優先級更高的干擾流量堵塞,視頻顯示功能失效。此時在上位機使能橋節點的Qbv功能(端節點time slot未使能)。門控被部署在N2節點出埠和N1節點出埠,800us的門控周期內有550us單獨預留給視頻流傳輸,從而保障視頻流在網絡內不被干擾流量堵塞。我們可以看到上位機的視頻顯示已經恢復了正常,但是由於端節點沒有使用time slot功能,視頻流在發送時橋節點的門控狀態不固定,其延時出現較大的抖動,從10us級到百us級波動。

此時我們使能TC377的端節點Time slot功能,此時視頻顯示仍然流暢(從肉眼無法看出其流暢度的提高),但是從右下角的散點圖和端到端延時數值可以發現,此時的視頻流端到端延時被固定在了11us,實現了確定性傳輸。

6. IEEE802.1Qbv vs IEEE802.1Qbv+Time slot 對於延時影響比較

在本系統和Qbv配置中,僅在橋節點使用Qbv時,視頻流的端到端延時從11us到250us波動,這是由於時間窗有250us處在關閉狀態,當端節點發送視頻流時若橋節點的門控剛好關閉,則端到端延時就會達到最大值。若恰好門控打開,那端到端延時就是最小值。

而在端節點使能Time slot後並不會縮短其最小延時,但是會大大降低其時延抖動,甚至像本系統一樣完全固定在某一定值。這是由於端節點在使能Time slot後,在發送視頻流時橋節點的門控一定處在打開狀態,這就使視頻流不會因為恰好遇到橋節點門控關閉而堵塞一段時間。

四、《IEEE802.1CB幀複製和消除協議的實現原理和演示》

1. IEEE802.1CB實現原理介紹

車載以太網和傳統以太網一樣,需要用到交換機在各個終端之間進行數據交互。但對於傳統以太網,如果某個交換機的轉發出了問題而導致幀的丟失,往往需要好幾秒的時間才能重新找到傳輸路徑並完成傳輸,這對於車載以太網而言是絕對不能接受的,這不能滿足車載以太網對於安全性和可靠性的要求。因此,IEEE 802.1CB協議的提出就是為了保證車載以太網通信的安全性的。IEEE 802.1CB通過提出一種幀的複製和刪除的方法,向車載以太網通信提供了無縫冗餘特性,降低了網絡的丟包率,從而改善了車載以太網的可靠性。IEEE 802.1CB幀的複製和刪除的方法由序列生成函數、獨立恢複函數以及序列恢複函數協作完成,其具體的實現如下圖所示:


圖9 幀的複製和刪除方法的實現

當一幀報文被發送的時候,序列號生成函數會生成一個序列號,並將其放入報文中。這幀報文被發送時會被複製(複製不會改變其序列號),並被發送出去,而如果報文的轉發存在多條路徑,則獨立恢複函數會判斷是否需要消除或者重新複製出一幀報文並向多個路徑方向發送。一個節點在收到一條報文時,序列恢複函數會檢查其是否是同一幀報文以及該報文是否應該轉發,從而減少網絡中那單一路徑上不存在重複的報文。通過這種不斷地複製和消除的機制,最終保證這幀報文最終會到達目的地,同時由目的地消除多餘的一幀,從而保證網絡中報文傳輸的安全性和可靠性。

序列生成函數負責對每一幀報文生成一個序列號,為保證不同報文的序列號不同,IEEE 802.1CB規定其範圍為0~65535。當有報文需要被發送時,該序列號就會增加1,並賦予該報文同時將該報文進行發送,當序列號達到最大值時,則對其進行復位。

而報文的消除則是通過序列恢複函數完成。當一幀報文被接收時,該函數就會運行,並對該報文的序列號進行評估,從而決定時轉發還是丟棄這幀報文。序列恢複函數有很多種恢復算法,這裡介紹一下向量恢復算法。向量恢復算法里定義了最大序列號、序列號歷史以及序列號歷史長度,最大序列號保存著當前收到的最大的序列號,序列號歷史記錄了最近收到的報文,序列號歷史長度則用來描述一個範圍內的序列號。最大序列號、序列號歷史以及序列號歷史長度共同構成了一個接收窗口,具體例子如下圖所示:


圖10 向量恢復算法

這裡設定最大序列號為100,序列號歷史長度為50,則窗口大小為50~150。對於收到的報文,其序列號如果處於50~100,就檢查它的序列號歷史,如果該報文被接受過則丟棄,否則則進行轉發,對於序列號在100~150的則直接轉發,並更新最大序列號。

由於序列恢復埠是針對單個埠的,而如果圖 3‑10中最左邊節點如果往上發的成員流1的埠出了故障,其將一遍又一遍地重複發送某個序列號的數據,直到序列生成函數完成一次跳轉,重新生成該序列號時才會結束,這無疑是對網絡帶寬的一種浪費。因此,獨自恢複函數的主要用途就是防止傳輸過時數據流失敗時不斷地發送同一中數據的情況。

2. IEEE802.1CB演示

上面是系統CB冗餘功能演示。

演示系統中,來自N2節點的視頻流使能了CB幀複製功能,視頻流可以通過鏈路P2到達N1節點後上傳至上位機。

當斷開N1與N2之間的繼電器後,繼電器2紅燈亮起,表明N1與N2之間的鏈路P2斷開,但由於使能了CB協議,N2視頻流的另一條成員流會經過N3,N4節點到達N1後上傳至上位機,實現視頻流的冗餘傳輸。

恢復繼電器2狀態為開,如果斷開N3和N4節點之間的繼電器1,N3和N4之間的鏈路失效,未使能CB協議的N3視頻流由於鏈路失效,無法上傳至上位機。而N2節點的視頻流仍可以通過另一條方向上鏈路P2達到N1節點後上傳,實現冗餘效果。

而對於控制流量,我們都配置了CB協議,所以無論哪條鏈路被繼電器斷開,都能正常控制車模節點。


掃描二維碼,關注英飛凌汽車電子尋找更多應用或產品信息

★博文內容參考自 網站,與平台無關,如有違法或侵權,請與網站管理員聯繫。

★文明上網,請理性發言。內容一周內被舉報5次,發文人進小黑屋喔~

參考來源

false: https://mp.weixin.qq.com/s/4jbWtXi3enhoRszoHgeWKQ

評論