作者:英飛凌汽車電子生態圈 同濟大學
本文長約9000字,乾貨滿滿,建議收藏。
上一篇我們提到針對常用TSN協議實現的難點,同濟大學開發了基於英飛凌AURIX™ TC3xx的時間敏感性網絡演示系統。今天,我們將結合IEEE 802.1AS,IEEE 802.1Qbv,IEEE 802.1CB協議標準,深入解析基於英飛凌AURIX™ TC3xx的時間敏感性網絡演示系統如何解決這些難點。
![](https://edit.wpgdadawant.com/uploads/news_file/blog/2024/14156/tinymce/1.jpg)
圖1 系統架構
![](https://edit.wpgdadawant.com/uploads/news_file/blog/2024/14156/tinymce/2.jpg)
-
路徑延遲計算與校正
IEEE 802.1AS協議里說明了三種傳輸方式(包括全雙工以太網鏈路、IEEE 802.11無線傳輸以及EPON),每一種不同的傳輸方式都有不同的方法來測量傳播時間,但它們都是基於相同的原則:測量一個設備A發出一幀特定報文的時間,緊接著在接收設備B測量該設備接收到該特定報文的時間,然後反過來,由設備B發出另一幀特定的報文,再測量這幀報文的發送時間和接收時間。該機制的實現過程可以通過下圖來說明:
![](https://edit.wpgdadawant.com/uploads/news_file/blog/2024/14156/tinymce/3.jpg)
![](https://edit.wpgdadawant.com/uploads/news_file/blog/2024/14156/tinymce/4.jpg)
-
時鐘同步和校準
![](https://edit.wpgdadawant.com/uploads/news_file/blog/2024/14156/tinymce/5.jpg)
時間感知系統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之間的差(即停留時間),均以最優主時鐘的本地時鐘實體作為時間基準。
![](https://edit.wpgdadawant.com/uploads/news_file/blog/2024/14156/tinymce/14.jpg)
端節點和橋節點在上電後自行運行時間同步協議棧,位於四塊板卡上的這兩個PPS的紅色LED燈光指示大致同步情況,同時每個控制器節點的時間同步狀態會上傳至上位機,在上位機端顯示大致的同步情況。
![](https://edit.wpgdadawant.com/uploads/news_file/blog/2024/14156/tinymce/6.jpg)
IEEE 802.1Qbv協議在實現調度的過程中引入了傳輸窗口的概念,每一個傳輸窗口都對應著一個隊列,傳輸窗口具有開和閉兩個狀態,分別對應著相應的隊列是否被發送。當一個隊列的傳輸窗口打開時,意味著該隊列的報文可以被其相應的傳輸選擇算法發送出去;而當傳輸窗口閉合時,則不允許發送該隊列的報文。
![](https://edit.wpgdadawant.com/uploads/news_file/blog/2024/14156/tinymce/7.jpg)
傳輸窗口由兩個參數,窗口狀態參數表示埠中每個隊列的窗口的狀態值,開啟或關閉狀態。傳輸窗口則會立即設置為窗口狀態參數中指示的狀態,因此,當列表中下一時刻的窗口狀態與上一時刻的狀態不一致時,在任何隊列中都會產生關閉窗口事件或開啟窗口事件。另一個參數為時間間隔,表示的是上一次傳輸窗口控制和下一次傳輸窗口控制的間隔。
正是有了通過控制傳輸窗口的手段,才使得對實時性要求高的關鍵報文得以被通過分時調度的方式及時發送出去。尤其是在多類報文對實時性要求高,而又可能會相互響應的情況下,這時候就需要保證在特定的時間內,只有同一類關鍵性報文會被發送,從而協調這些關鍵性報文的發送而又不影響其實時性,其具體實現如下圖所示:
![](https://edit.wpgdadawant.com/uploads/news_file/blog/2024/14156/tinymce/8.jpg)
當實時性要求高的等級為3的隊列中有報文等待發送時,由於此時正在有一些對實時性要求不高的數據在發送,這個時候,首先是需要對隊列3需要發送時間T1之前的一段時間(guard band,T0到T1)對網絡進行保護,以免非關鍵性報文占用了網絡資源,然後在T1設置傳輸窗口的狀態為ccccoccc,即關閉其他傳輸而只打開隊列3的傳輸窗口,以保證關鍵性報文的及時傳輸。當隊列3的傳輸窗口的打開時間T2之後,則設置傳輸窗口的狀態為oooocooo,即關閉隊列3的傳輸窗口而打開其他隊列的傳輸窗口,以保證其他數據的正常發送。
![](https://edit.wpgdadawant.com/uploads/news_file/blog/2024/14156/tinymce/9.jpg)
在時間槽功能初始化階段,其配置圍繞SLOT_FUNCTION_CONTROL_STATUS寄存器展開,針對發送通道的單個時間槽長度參數和是否使能時間槽比較功能進行配置。
對於以太網報文與發送時間槽綁定的過程,主要是針對描述符 TDES3部分的 SLOTNUM_THL欄位進行配置,設定當前報文的具體傳輸時間槽,待時間槽序列進行到設定時間槽後再開始數據發送。
完成上述報文描述符配置後,將報文通過配置好的發送通道進行發送,那麼報文就能夠在對應的時間槽內被發送。
時間槽機制與標準的Qbv機制相比,存在著一些局限性。在分時調度表配置層面,標準 802.1Qbv 分時調度機制需要分時調度表內的每個條目均有自己的觸發時長,其單個時間片長度和時間片內門控開啟情況也要是可獨立控制的。TC3xx 的時間槽機制規定一個循環周期內存在 16 個時間槽,且單個時間槽的長度範圍為 1~4096 微秒,且各時間槽長度均相等,通過劃定報文的指定發送時間槽即可控制報文的發送窗口,這種特性限制了時間片的長度獨立可控,其控制粒度限制了 TC3xx 可實現的調度複雜性上限。
在交換機端,門控列表的循環周期設置為800us,並配置兩條表項。如圖所示,在循環周期的前100us中,隊列7的門控打開,讓時間敏感流的報文順利通過,而其餘隊列的門控關閉,以免來自非關鍵流量報文的干擾。而循環周期剩下的700us中,隊列7的門控關閉,因為這段時間內沒有來自時間敏感流的報文抵達交換機,而其餘隊列的門控開啟,讓非關鍵流量的報文得以傳輸。
![](https://edit.wpgdadawant.com/uploads/news_file/blog/2024/14156/tinymce/10.jpg)
而當MCU作為AS從時鐘時,MAC時鐘在上電後會被修改,導致時間槽基準時鐘和同步域各節點MAC時鐘不一致。在同步達到穩定狀態後,兩個時鐘之間存在一個穩定但未知的偏差值delta。由於交換機門控列表的時鐘源是MAC時鐘,所以如圖所示,此時MCU如果仍然在slot1發送報文,顯然無法做到在敏感流所屬隊列門控打開的時間段發出報文,不符合預期的效果。
![](https://edit.wpgdadawant.com/uploads/news_file/blog/2024/14156/tinymce/11.jpg)
可通過如下方式推算出正確時間槽的具體數值。假設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 欄位改為通過上述方式計算出的正確的時間槽。
![](https://edit.wpgdadawant.com/uploads/news_file/blog/2024/14156/tinymce/15.jpg)
上面是系統Qbv協議演示,網絡內未添加干擾流量時,視頻流顯示功能正常,當在網絡內添加中等流量時,N2生成干擾流量經過N1發往上位機,N4同樣生成干擾流量發往上位機,此時視頻幀被優先級更高的干擾流量堵塞,視頻顯示功能失效。此時在上位機使能橋節點的Qbv功能(端節點time slot未使能)。門控被部署在N2節點出埠和N1節點出埠,800us的門控周期內有550us單獨預留給視頻流傳輸,從而保障視頻流在網絡內不被干擾流量堵塞。我們可以看到上位機的視頻顯示已經恢復了正常,但是由於端節點沒有使用time slot功能,視頻流在發送時橋節點的門控狀態不固定,其延時出現較大的抖動,從10us級到百us級波動。
此時我們使能TC377的端節點Time slot功能,此時視頻顯示仍然流暢(從肉眼無法看出其流暢度的提高),但是從右下角的散點圖和端到端延時數值可以發現,此時的視頻流端到端延時被固定在了11us,實現了確定性傳輸。
而在端節點使能Time slot後並不會縮短其最小延時,但是會大大降低其時延抖動,甚至像本系統一樣完全固定在某一定值。這是由於端節點在使能Time slot後,在發送視頻流時橋節點的門控一定處在打開狀態,這就使視頻流不會因為恰好遇到橋節點門控關閉而堵塞一段時間。
![](https://edit.wpgdadawant.com/uploads/news_file/blog/2024/14156/tinymce/12.jpg)
序列生成函數負責對每一幀報文生成一個序列號,為保證不同報文的序列號不同,IEEE 802.1CB規定其範圍為0~65535。當有報文需要被發送時,該序列號就會增加1,並賦予該報文同時將該報文進行發送,當序列號達到最大值時,則對其進行復位。
而報文的消除則是通過序列恢複函數完成。當一幀報文被接收時,該函數就會運行,並對該報文的序列號進行評估,從而決定時轉發還是丟棄這幀報文。序列恢複函數有很多種恢復算法,這裡介紹一下向量恢復算法。向量恢復算法里定義了最大序列號、序列號歷史以及序列號歷史長度,最大序列號保存著當前收到的最大的序列號,序列號歷史記錄了最近收到的報文,序列號歷史長度則用來描述一個範圍內的序列號。最大序列號、序列號歷史以及序列號歷史長度共同構成了一個接收窗口,具體例子如下圖所示:
![](https://edit.wpgdadawant.com/uploads/news_file/blog/2024/14156/tinymce/13.jpg)
由於序列恢復埠是針對單個埠的,而如果圖 3‑10中最左邊節點如果往上發的成員流1的埠出了故障,其將一遍又一遍地重複發送某個序列號的數據,直到序列生成函數完成一次跳轉,重新生成該序列號時才會結束,這無疑是對網絡帶寬的一種浪費。因此,獨自恢複函數的主要用途就是防止傳輸過時數據流失敗時不斷地發送同一中數據的情況。
![](https://edit.wpgdadawant.com/uploads/news_file/blog/2024/14156/tinymce/16.jpg)
上面是系統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協議,所以無論哪條鏈路被繼電器斷開,都能正常控制車模節點。
掃描二維碼,關注英飛凌汽車電子尋找更多應用或產品信息
評論