車載基礎軟件——AUTOSAR CP典型應用案例SOME/IP和TSN時間同步我是穿拖鞋的漢子，魔都中堅持長期主義的一個屌絲工程師！今天是2023年2月7日，上海還在下著雨，估計是到了梅雨時節（提前到來？），真想說句我勸天公重安排，不讓梅雨早時來！！！老規矩分享一段喜歡的文字，避免自己成為高知識低文化的工科男：“ Return to today's topic!本章節將分享幾個基于 AUTOSAR CP 基礎協議棧的典型應用案例供讀者參考。
一、SOME/IP 應用案例在自動駕駛項目中，整車和傳感器通過 CAN 總線與自動駕駛域控制器的 MCU 進行交互，MCU 再將從 CAN 總線接收到的數據組包轉發給 SOC 的各應用模塊，MCU 與 SOC 之間則通過基于以太網的 SOME/IP 通信協議進行交互。常用的 SOME/IP 以太網消息類型有：-> REQUEST;-> REQUEST_NO_RETURN;-> NOTIFICATION;-> RESPONSE。其中 REQUEST 為期待響應的請求，客戶端有需求時才會向服務端發送請求，且客戶端會等待服務端反饋的結果。例如，客戶端如果需要向服務端請求 VIN 碼，則可發送 REQUEST 類型的消息。RESPONSE 則為響應消息，即服務端的用于響應客戶端 REQUEST 類型的報文。例如：客戶端向服務端請求 VIN 碼，服務端則通過 RESPONSE 類型的消息給客戶端回復 VIN 碼。REQUEST_NO_RETURN 為不期待響應的請求，客戶端有需求時才會向服務端發送請求，但客戶端不關注結果。若客戶端如果需要向服務端請求打開車窗，客戶端可發送 REQUEST_NO_RETURN 類型的消息。NOTIFICATION 為事件通知，客戶端先向服務端訂閱消息，服務端當發現被訂閱的消息發生變化時則主動通知客戶端。例如，客戶端向服務端訂閱車速信息，服務端如果發現車速變化則可發送 NOTIFICATION 類型的消息給客戶端。在本案例中，由于 MCU 與 SOC 的通信數據具有數據量大、通信數據類型確定、數據周期性發送等特點，因此 SOME/IP 消息采用 NOTIFICATION 類型。自動駕駛域控制器的軟件架構如圖 2.1-8 所示。MCU一側基于AUTOSAR CP搭建應用軟件， 主 要 包 括 三 個 應 用 模 塊：VDC（Vehicle Data Center）將整車相關 CAN 數據做預處理，此類 CAN 數據主要指 VCU、EPS、EPB 等控制器數據；XDC（X Sensor Data Center）將各傳感器的 CAN 數據做預處理，此類 CAN 數據主要指毫米波雷達、組合導航、智能攝像頭等傳感器數據；IDC（Internal Data Center）將預處理后的 CAN 數據轉換成以太網數據并通過 SOME/IP 協議發送到 SOC 一側。
SOC 一側基于 AUTOSAR AP 搭建，其中 SDC（Service Date Center）將以太網數據轉換為 SOC 應用模塊所需要的數據。在 SOME/IP 通信中，SOC 側的 SDC 作為客戶端，啟動后即開始訂閱 MCU 側的所有已知服務，MCU 一側收到訂閱后即開始以固定周期向 SDC 側發送訂閱的報文，為保證實時性，SOME/IP 的數據傳輸周期與 CAN 報文周期一致。SOME/IP 序列化方式采用大端一字節對齊。因為一字節對齊是最簡單的對齊方式，大多編譯器很容易實現；并且采用一字節對齊，序列化后沒有冗余數據，報文的有效負載段都是有意義的數據，所以總體傳輸效率得到了一定提升。另外，SOME/IP 通信報文中的 Payload 也會添加時間戳和 Rolling Counter等信息，SOC 一側的應用在使用 MCU 傳來的數據之前，會先把時間戳取出來，并作數據校驗、對齊、分等工作。SOME/IP 報文結構如下圖所示。本案例中的 SOME/IP 協議均基于 UDP 協議開發，它在用戶有需求的時候才發送報文，這種方法有以下幾點優勢：1、效率高。與 CAN 等周期性的網絡相比，總線上不會出現過多不必要的數據，從而減少了資源消耗，點對點的全雙工傳輸模式也讓通信效率變得更高。2、通信速率快。對于雷達這類較大的數據，需要 MCU 能在短時間內及時地將數據傳輸到 SOC，使用以太網是目前各類總線通信中速率最快的，它最能滿足大數據量的通信需求。3、數據長度長。CAN-FD 報文數據長度最大 64 字節，LIN 報文數據長度最大 8 字節，單幀 Flexray 報文數據長度最大 254 字節，而基于 UDP 的以太網單幀報文長度可達 1500 字節，能滿足大數據的通信需求。4、實現較簡單。以太網已有成熟的 TCP/IP 協議棧，基于 Linux 平臺還有開源的 Vsomeip 協議棧，可直接移植使用。
二、時間同步應用案例在智能駕駛中，時間是一個非常重要的參數，各個系統中需要保證時間一致：-> 車云系統之間時間一致；-> 域控之間時間一致；-> 域控與各個 ECU 之間時間一致；-> ECU 與各個傳感器之間時間一致等。車云系統為保證時間一致，常在車載 ECU 中加裝 GPS 模塊，ECU 通過 GPS 數據與云平臺時間保持一致。車內系統（域控之間、域控與 ECU 之間、ECU 與傳感器之間）為保證時間一致主要采用：PTP（PrecisionTime Protocol 高精度時間同步協議）、PPS（同步脈沖信號）、AUTOSAR CP 同步方案等。如下圖多傳感器融合系統中，Camera ECU 通過高精度攝像頭采集車道線、障礙物、標識等信息；Radar ECU 通過毫米波雷達進行障礙物、障礙物速度等信息的采集；Camera/Radar ECU 通過CAN-FD 將處理的數據交給 ADCU 進行數據融合，ADCU 中自帶 GNSS 芯片保證與云端時間一致。由于該系統對數據實時性、真實性要求比較高，所以需要保證 Camera/Radar ECU 采集的數據時間一致。為了達到該目的，如下圖時間同步步驟所示，本案例采用了 AUTOSAR CP 時間同步解決方案，即ADCU 作為 Time Master 實體，Camera/Radar ECU 作為 Time Slave 實體，由 ADCU 對 Camera/Radar ECU 進行時間同步。時間同步的步驟與方法如下：1、ADCU 以 1s 為周期發送同步幀，即圖中 t1 時刻發送 t0 時刻的時間戳。2、Camera/Radar ECU 在 t2 時刻收到同步幀后，記錄 t2 時刻的時間戳。3、ADCU 間隔固定時間（100ms）后發送跟隨幀，發送內容即 Δt0 時間。4、Camera/Radar ECU 在 t3 時刻接收到跟隨幀后，進行絕對時間計算并將絕對時間更新到 ECU 中，公式為：t3 = t0 +Δt0 + t3–t2。注：如上內容僅是自己在查詢資料做的匯總，拱同行做入門學習！ 愿你我相信時間的力量， 做一個長期主義者！ |
|
|
