基于AP AUTOSAR 的礦車自動駕駛故障診斷系統應用

仰曉芳，喻曉軍，汪貴冬，周圣文，齊家軍

（安徽海博智能科技有限責任公司，安徽 蕪湖 241200）

引言

隨著“智慧礦山”概念的提出，礦山自動駕駛的研究和應用也日益增多。由于自動駕駛的功能越來越復雜，且需要融合多傳感器信息，另AP（Adaptive）AUTOSAR 自適應汽車開放式架構的系統具有高性能、高運算、動態可擴展性的特點，因此，AP AUTOSAR 的架構未來被會廣泛地應用在自動駕駛產品中[1-3]。其中診斷系統作為AP AUTOSAR 的重要組成部分，其開發是基于DoIP（Diagnostic Communication over IP）和UDS（Unified Diagnostic Services）協議，實現UDSonIP（UDS on Internet Protocol implementation）的診斷[4-9]。

以華為MDC300F 為平臺，基于AP AUTOSAR 和UDS 相關標準，二次開發了礦車自動駕駛故障診斷系統，并深入介紹了AP AUTOSAR 診斷系統的整體框架和相關模塊的設計。以華為的MCDTool 作為上位機，與控制器實現DoIP 通信進行診斷相關服務的測試，實驗結果表明，該系統能準確判斷出故障，并記錄故障發生時的車輛信息，便于測試和維修人員定位故障[1-2]。

1 AP AUTOSAR 診斷簡介

AP AUTOSAR 標準定義了一套基于service 和APIs 兩種接口類型的ARA（AUTOSAR Runtime for Adaptive Applications）運行環境，并由平臺服務和平臺基礎為分組的多個功能集群組成。其主要特點有：面向服務的架構，實時性高，安全性高，動態可擴展等。

本文采用的AP AUTOSAR 架構如圖1 所示。

AP AUTOSAR 診斷基于AP AUTOSAR，位于平臺基礎層，簡稱診斷管理（DM）。診斷管理模塊可以支持多個ECU 的應用場景，且支持應用部署的動態可擴展[3]。診斷管理由UDS 傳輸層和診斷應用層組成，其中診斷應用層又包含診斷通信管理和診斷事件存儲管理兩部分，其結構框圖如圖2 所示。

2 AP AUTOSAR 診斷系統的開發

2.1 診斷系統的傳輸層

AP AUTOSAR 診斷系統支持標準的C++API，實現與UDS 傳輸層的連接。但是目前，AP AUTOSAR 的診斷只支持基于以太網的傳輸協議，將來的AP AUTOSAR 版本也將支持不同總線的傳輸協議，比如：CAN、CANFD 和Flexray 等[4]。

AP AUTOSAR 診斷系統的傳輸層主要實現的功能有：轉發UDS 診斷請求和回復的消息；支持DoIP協議；通過UDS 診斷請求地址（物理尋址和功能尋址）調度不同的ECU，從而與ECU 建立通信。

2.2 診斷通信管理子集

診斷通信管理子集實現了上位機與ECU 的診斷服務功能，類似于CP AUTOSAR 中的DCM 功能。目前，診斷通信管理子集只支持部分有限的診斷服務，后續將會擴展支持更多的診斷服務。

診斷通信管理中主要的功能有：診斷會話和UDS服務功能。其中，診斷會話既能響應不同的診斷ECU和client 的會話消息，即支持偽并行處理，又能在默認會話層支持client 端的全并行處理。本文中的診斷通信管理主要支持$10、$11、$14、$19、$22、$27、$2E等幾種常見的診斷服務功能，其中0x22 和0x2E 服務支持調用外部函數實現診斷自適應應用功能，即通過二次開發礦車系統診斷DiagAPP 實現特有的DID（Data Identifier）讀寫功能。該二次開發讀寫DID 的功能主要是由DiagAPP 提供服務及callback 函數[5]，若診斷管理收到DID 請求，查詢到服務后會調用DiagAPP的讀/寫callback 函數，將收到的返回值發送出去，其動態圖如圖3 所示。

2.3 診斷事件存儲管理子集

診斷事件存儲管理子集主要負責故障碼（DTC）的存儲與管理。Diagnostic Event 是故障診斷和其相關數據存儲的基本單元，每個故障碼對應了一個Diagnostic Event。二次開發的DiagAPP 實時監測Diagnostic Event 的狀態，在故障觸發或者恢復時[6]，DiagAPP 會及時將Diagnostic Event 的狀態信息上報到DM，同時DM會將該事件的狀態信息、快照數據和擴展數據存儲到非易失性存儲區域，從而達到故障碼的存儲與管理。其中二次開發的DiagAPP 上報故障碼的動態圖見圖4。

2.4 AP AUTOSAR 診斷平臺搭建及實現

以MDC300F 為平臺并將其集成到礦車中，與上位機MCDTool 完成組網連接，通過上位機MCDTool遠程訪問MDC300F，對礦車系統進行診斷，見圖5。

在上述硬件平臺的基礎上，華為需要基于礦車診斷系統的需求對AP AUTOSAR 的診斷管理模塊進行配置，并可以提供二次開發故障診斷功能的C++API，包括DID 的讀寫和故障碼的上報。本文主要基于AP AUTOSAR 開發自己的APP 實現DID 的讀寫和故障碼的上報，達到開發礦車自動駕駛診斷特有功能部分，并將該診斷系統應用于礦車自動駕駛系統中。上位機和MDC 診斷服務管理以及二次開發APP間的關系如圖6 所示。

3 測試及結果

搭建測試臺架，PC 端啟動MCDTool 遠程登錄車輛，并將二次開發的APP 編譯生成的可執行文件部署至車輛的MDC300F 產品中，其中MCDTool 遠程登錄車輛顯示界面如圖7 所示。本文以二次開發功能相關服務進行測試，具體測試服務有0x22、0x2E、0x19、0x14，其中測試的DID 有F189 -軟件版本信息、F1A2-產品的生產日期以及不支持的F197，測試的故障碼以礦車連接的慣導丟失故障碼0xC03887 測試為例。診斷報文的發送和解析參照ISO13400-2 和ISO14229-5。

3.1 DID 讀寫數據服務測試

軟件版本和生產日期可以協助開發或者維修人員定位產品所支持的功能，以及當前產品是否存在問題，是車輛診斷必不可少的診斷信息，故本次測試以DID_F189 和DID_F1A2 為例測試。通過MCDTool 測試了二次開發的DID 讀取，DID 寫入，以及不在范圍內的DID 讀取和寫入三種情況，具體解析的UDS 測試數據如表1 所示。

表1 DID 讀寫服務測試

由以上測試結果，可以驗證DID 讀寫數據服務測試通過，該礦車自動駕駛系統DID 讀寫數據二次開發功能正常。

3.2 讀取故障碼測試

慣導作為車輛定位數據的主要來源，是礦車自動駕駛不可或缺的一部分，以慣導丟失故障-0xC03887為例測試二次開發故障碼的功能[7]。主要測試慣導丟失后故障碼狀態位變化、快照數據以及擴展數據的記錄情況。MCDTool 解析的測試數據如表2 所示。

表2 讀取故障碼測試

由以上測試結果，可以驗證讀取故障碼服務測試通過，且礦車自動駕駛系統上報故障碼二次開發功能正常。

3.3 清除故障碼測試

基于上述慣導丟失故障測試，恢復慣導丟失狀態，緊接著測試$14 服務清除故障碼的測試。MCDTool解析的測試數據如表3 所示。

表3 清除故障碼測試

由以上測試結果，可以驗證清除故障碼服務測試通過，該礦車自動駕駛系統二次開發上報的故障碼能正常清除。

4 結論

未來自動駕駛領域采用AP AUTOSAR 的架構會越來越多，通過搭載第三方成熟的軟硬件平臺，快速開發出符合自己產品的軟件成為趨勢。開發出的軟件具有高可靠、一致性強、穩定性高的特點，還能大大降低產品開發成本，加快開發周期[8-9]。

本文以MDC300F 為平臺，結合礦車自動駕駛需要讀取和寫入車輛相關狀態信息，以及針對礦車實際的硬件和系統的故障監測進行二次開發，實現了基于AP AUTOSAR 的礦車自動駕駛診斷的應用，對礦車自動駕駛領域的研發有著積極意義。