RTaW-Pegase構建可預測QoS的TSN網絡架構
當今汽車上多達數以百計的ECU(電子控制單元),MCU(微控制處理器單元)及其上面運行著的大量的嵌入式軟件代碼,以及復雜的CAN、LIN、FlexRay等整車通訊網絡決定了汽車不同于其他的IOT設備或智能手機。汽車上的電子電氣架構一直在朝著為智能化和體驗服務的方向在演化和迭代,只是這個過程相比消費電子行業需要更長的時間。現今主流的汽車電子電氣架構發展的三個階段:以控制器為中心的階段、域控制器階段、中央計算機階段。

1.1 OEM視角的SOA和中央計算平臺
SOA和中央計算平臺的優點:
- 硬件和軟件解耦 (面向不同的客戶和具體的服務需求)
- 服務的重新使用和模塊化(構建塊)
- 簡化基于軟件的創新方式
- 定制化,新業務模式,借助軟件更新

SOA和中央計算還能夠轉變傳統的通信模型:借助多平臺中間件(例SOME/IP)、網絡配置更加靈活和自動化、保障網絡數據傳輸的QoS。
1.2 服務和應用程序的層次結構
服務執行方式有以下幾種:
- 用于專用電子控制單元,例如:攝像頭和雷達
- 用于基本服務的區域控制器,例如:傳感器數據處理
- 用于組合服務的高性能計算ECU,例如:ADAS
- 用于云端,例如:信息娛樂
- 用于基礎架構,例如:速度限制
這些服務可分組使用,以定義可重復使用的軟件組件或完整的虛擬ECU。
SOA用例1:Lighting Service
當數百個服務生成的數千個數據流爭奪網絡資源時,配置通信服務如下圖所示:
SOA用例2:智能傳感器融合用例
智能傳感器:將模擬數據轉換為服務通信(例如攝像頭和雷達) 使用(硬件或軟件中的)CBS整形解決方案,預整形脈沖信號
2.E/E架構:拓撲、協議棧、服務特征及其QoS要求
2.1 E/E架構的以太網仿真模型
下圖是RTaW-Pegase中建立的以太網仿真模型,其中包括:
- 1臺中央計算機(物理計算單元:Physical Computing Unit)→ PCU服務器組合服務及應用程序;
- 17個以太網上的ECU,包括3個前置/后置攝像頭、2個雷達、3個顯示屏、車外模塊+專用ECU,例如用于PIU后的5個拆分CAN上的I/O和底座;
- 5個區域控制器(物理接口單元:Physical Interface Units)→PIU服務器基本服務
2.2 用于流量分段和整形的協議棧
- TCP:可靠且分段的傳輸,但不是實時的;
- SOME/IP TP:可預測時序和分段傳輸,但沒有整形功能;對不使用SOME/IP
TP的服務器,將服務器報文劃分為多個Events可能是一種解決方法; - CBS:流出端口中的存儲有限,可能需要對發送端通信堆棧中的軟件進行其他整形,但尚未有標準解決方案。
2.3 通過服務配置TSN QoS機制
在配置時應確保所有流(不僅是服務)都滿足其時間限制

服務的配置挑戰:
-
請求-響應處理的截止時間,不僅是單獨傳輸
-
一些報文和typ. resp.可能需要分段和整形
-
在大量數據流傳輸時需要一個自動化處理的模型
2.5 服務的特性
單獨一項服務可以產生大量流量,例如,組合服務的100個單播流和5個多播流可為10個客戶提供10種方法和5個事件。
3.針對服務的優化TSN配置,最大化網絡容量并減少內存消耗
3.1 過載分析
網絡過載意味著一個或多個連接的負載高于100%,沒有TSN協議能滿足其時序約束,從過載分析圖我們可以得知:
- 超過75個服務(3920個流)上10%的網絡超載
- 建議無論采用哪種TSN策略,此架構最多支持60-80個服務
- 連接:從CGW到PCU2。將其切換到1Gb/s增加網絡容量
3.2 手動配置
手動配置時流量優先級:
- TSN機制:優先級、無整形
- 根據截止時間手動調整流量分類:緊急服務的截止時間應小于10ms


整形對于ADAS服務的數據流傳輸幾乎沒有作用:因為ADAS服務為低優先級的數據流,且對不分段的報文包進行整形并沒有多大用處;另外搶占式處理的機制也是無效的,因為超過截止時間的數據流都不會是高優先級的。由上圖可以得知,數據流數量越多,相應在最壞情況下傳輸的截止時間也會不斷縮短。
3.3 基于算法的配置
具有簡潔優先級算法的流量優先級
- TSN機制:優先級機制,無整形
- 自動化流量分類:不同類型的數據流將混合在所有優先級中


由上圖可知,使用CBS減少每個設備的內存使用量最大值:97%,平均:12.3%。
了解更多TSN解決方案的技術信息及商務服務,請訪問http://www.softtest.cn/留言,或按以下方式聯系旋極信息:
?








浙公網安備 33010602011771號