從研發到測試SDV域控制器的調試日志

在汽車軟件復雜度不斷攀升的今天，對不同核或分區上運行的復雜軟件進行調試或追蹤極具挑戰性，并且在POSIX系統或車輛上的復雜軟件進行分步調試往往更具挑戰。所以，如何在SDV域控制器開發測試環境中，將應用程序、中間件和內核日志與時間戳等信息同步結合匯聚到同一個日志流，以便更好服務軟件工廠或“黑燈”測試工廠，亦或為云端AI平臺提供日志調試軟件？AUTOSAR推出的組件DLT，其邏輯已從診斷日志追蹤（DiagnosticLog andTrace）演變為更加寬泛意義的開發日志追蹤（DevelopmentLog andTrace）。

圖1 面向SDV平臺集成DLT調試日志

通常部分軟件開發工程師有配置ECU的硬件調試環境，但其它工程師幾乎沒有配置“Debug”ECU問題的環境。DLT作為ECU軟件的模塊匯聚調試日志并追蹤ECU內部問題，可以加速問題排查和解決。過往通過CANoe或CANoe Option AMD/XCP集成不同調試器或XCP獲取軟件狀態，但是面向研發環境表現出廣泛的多樣性：

不同品牌調試器和調試器擴展模塊

ECU平臺多樣性和電路連接多樣性

不同軟件配置環境的License

不同的構建設置（例如，軟件工廠、HIL Farm）

圖2 CANoe Option AMD/XCP集成不同調試器或XCP獲取日志

通過統一的DLT作為調試手段增加軟件測試的靈活性和效果，允許根據嚴重性級別（例如“致命”、“錯誤”或“信息”）對調試信息進行過濾。該過濾器可以通過外部日志工具發送的DLT控制消息在運行時進行修改。還可以直接通知應用程序新的過濾級別，以便僅針對所選的嚴重性級別生成調試信息，運行時將消息分配到另一個通信總線上，或將修改后的DLT配置存儲為NV存儲（如果硬件支持的話）。開發與測試工程師使用CANoe Option AMD/XCP在支持CCP/XCP的同時，也可直接用其實現DLT數據進行在線采集或離線分析。

圖3 CANoe Option AMD/XCP直接獲取XCP或DLT日志

Part 1

DLT應用場景和協議概述

DLT是一個AUTOSAR基礎軟件模塊。雖然DLT協議與總線無關，但建議使用高帶寬總線，如以太網。盡管如此，DLT協議并不局限于以太網的使用，使得在沒有調試器的情況下調試ECU成為可能，并允許用戶在運行時進行配置。

使用DLT進行常規日志記錄：

應用程序/軟件組件向DLT模塊提供日志消息

日志消息要么被過濾，要么由DLT模塊創建DLT消息（取決于日志級別）

DLT模塊將DLT消息發送到通信總線

外部客戶端接收并存儲DLT消息

圖4 AUTOSAR DLT常規日志記錄

中間件VFB日志：

中間件調用DLT模塊提供的接口函數，該函數調用DLT API生成追蹤消息

DLT模塊將追蹤消息發送到DLT通信模塊接口

DLT通信模塊將追蹤消息轉發到網絡

外部客戶端接收并存儲追蹤消息

圖5 中間件通過DLT記錄日志

運行時配置DLT日志：

外部客戶端設置日志和追蹤級別，并將更改發送至DLT模塊

通過DLT控制消息將更改發送到DLT模塊

DLT模塊相應地調整其過濾設置的配置

DLT模塊通知應用程序新的日志級別

圖6 運行時配置DLT日志

非冗長模式（Non-verbose）傳輸日志：使用外部解析文件的方式來高效解析有效數據載荷，從而避免在通信總線上發送關于變量的元素數據，達到節省總線通信開銷的目的。外部DLT客戶端將這些元數據與接收到的參數值合并存儲。

應用程序/軟件組件向DLT模塊提供Non-verbose的日志數據

DLT模塊過濾并生成DLT消息

DLT模塊將DLT消息發送到通信總線

外部客戶端從外部文件中獲取元信息

合并的信息由外部客戶端存儲

圖7 Non-verbose模式日志

DLT協議是一種高層協議，與具體使用哪種總線無關。AUTOSAR規范中的DLT協議目前定義了v1和v2兩個版本，并在Log and Trace Protocol Specification中隨AUTOSAR各個Release逐步演進和規范化，例如在AUTOSAR FO R19-11及后續R24-11（PRS）中對相關能力進行了完善和擴展。在AUTOSAR發布的早期階段（約2010年前后），Vector在ECU軟件與工具鏈中對日志與追蹤機制進行了大量工程實踐，用于開發調試和問題分析，并隨著AUTOSAR 規范的演進持續支持和實現DLT協議，最終發展到當前廣泛使用的v2版本。

DLT v1版本包頭簡單、報文開銷小，因而在帶寬受限或資源受限的ECU上能夠實現低成本部署。

圖8 DLT v1版本標準報頭

圖9 DLT v1版本擴展報頭

DLT v2支持可變長度ID（動態ID）、高精度時間戳、分段傳輸（即報文超過單幀長度可切分并重組），更適合大載荷的場景。

圖10 DLT v2版本標準報頭

圖11 DLT v2版本擴展報頭

協議中還定義了兩種模式，分別是Verbose和Non-verbose模式，兩種模式在日志消息的嚴重性等級均提供：FATAL、ERROR、WARNING、INFO、DEBUG和VERBOSE。兩種模式的區別為：

Verbose模式：發送包含所有參數/文本的完整消息，便于閱讀與分析，但會消耗更多帶寬。

Non-verbose模式：可發送更緊湊的消息（例如僅發送參數或ID），消息結構可以通過FIBEX或ARXML數據庫文件解析，適合在帶寬受限場景降低開銷。

Part 2

日志追蹤“利器”

– 帶有DLT功能的CANoe Option AMD/XCP

通過收集日志信息來驗證ECU的正確功能，捕獲ECU的追蹤數據確保狀態流的正確變化，檢測ECU是否報告了錯誤（例如，配置錯誤或基礎軟件BSW錯誤），驗證從ECU生成的事件順序是否正確。針對如上需求，ECU需要集成對應的DLT軟件模塊：

基于XCP的DLT集成：現有XCP協議棧上只需將DLT API調用添加到定義事件中，配置中啟用相關功能則DET和DEM事件將自動傳輸，DEM事件支持按需過濾。

基于AUTOSAR的DLT集成：作為XCP DLT的替代方案，允許API更改DLT的日志級別，滿足整車廠集成DLT的功能要求。根據AUTOSAR日志定義控制日志級別（致命、錯誤、警告、調試、信息、詳細），將所有日志和追蹤聚集到集中式AUTOSAR服務組件中，基于軟件的時間信息、多核和分區日志。如AUTOSAR AP中ara::log提供每個階段的日志信息API，日志通過配置發送到特定日志接收器，若需要可通過DLT實現遠程調試。

CANoe Option AMD/XCP支持在開發與調試過程中加載A2L文件到CANoe中，并支持DaVinci工具在配置協議棧時可額外配置測量代碼，直接生成測試代碼用于CPU負載、任務執行等信息用于后續自動化驗證。

圖12 CANoe支持A2L集成用于DLT與運行測量

CANoe支持在線和離線分析DLT數據，可通過總線接口卡連接真實ECU獲取調試日志，對虛擬機如WSL中的vECU可通過集成SIL Kit來獲取調試日志。

圖13 真實ECU或虛擬ECU可通過CANoe實現DLT調試日志

CANoe支持Non-verbose和Verbose兩種模式，支持一鍵生成對應FIBEX中變量到CANoe工程，也可在配置工程節點后導入對應變量。

圖14 CANoe中DLT配置流程

對于Non-verbose模式消息的解析，插件根據FIBEX文件自動生成的變量，DLT變量緊隨每幀Ethernet Packet，直接被解析并顯示在Trace窗口，并可在Graphics窗口中以動態曲線方式顯示DLT日志信息。

圖15 CANoe解析Non-verbose模式日志

對于Verbose模式消息的解析，具體的Payload會直接被解析成結構體，并在Trace窗口顯示。

圖16 CANoe解析Verbose模式日志

同時CANoe支持發送DLT Control Message，如Set Log Level命令。

圖17 使用CANoe發送DLT Control Message

Part 3

總結和展望

SDV發展迭代必然需要更豐富的調試手段。AUTOSAR DLT作為調試器之外的另一種獲取調試日志的方式，將更好服務車輛開發各環節。CANoe Option AMD/XCP配合DLT功能提供更加全面的功能，在獲取CCP/XCP數據日志信息的同時，助力工程師更好地通過DLT分析和調試ECU。當然在車輛生產時，DLT應當關閉以滿足網絡安全需求。DLT技術也在迭代，CANoe也將更好支持“軟調試”技術，進一步提升便利性。