仰曉芳,喻曉軍,汪貴冬,周圣文,齊家軍
(安徽海博智能科技有限責任公司,安徽 蕪湖 241200)
隨著“智慧礦山”概念的提出,礦山自動駕駛的研究和應(yīng)用也日益增多。由于自動駕駛的功能越來越復(fù)雜,且需要融合多傳感器信息,另AP(Adaptive)AUTOSAR 自適應(yīng)汽車開放式架構(gòu)的系統(tǒng)具有高性能、高運算、動態(tài)可擴展性的特點,因此,AP AUTOSAR 的架構(gòu)未來被會廣泛地應(yīng)用在自動駕駛產(chǎn)品中[1-3]。其中診斷系統(tǒng)作為AP AUTOSAR 的重要組成部分,其開發(fā)是基于DoIP(Diagnostic Communication over IP)和UDS(Unified Diagnostic Services)協(xié)議,實現(xiàn)UDSonIP(UDS on Internet Protocol implementation)的診斷[4-9]。
以華為MDC300F 為平臺,基于AP AUTOSAR 和UDS 相關(guān)標準,二次開發(fā)了礦車自動駕駛故障診斷系統(tǒng),并深入介紹了AP AUTOSAR 診斷系統(tǒng)的整體框架和相關(guān)模塊的設(shè)計。以華為的MCDTool 作為上位機,與控制器實現(xiàn)DoIP 通信進行診斷相關(guān)服務(wù)的測試,實驗結(jié)果表明,該系統(tǒng)能準確判斷出故障,并記錄故障發(fā)生時的車輛信息,便于測試和維修人員定位故障[1-2]。
AP AUTOSAR 標準定義了一套基于service 和APIs 兩種接口類型的ARA(AUTOSAR Runtime for Adaptive Applications)運行環(huán)境,并由平臺服務(wù)和平臺基礎(chǔ)為分組的多個功能集群組成。其主要特點有:面向服務(wù)的架構(gòu),實時性高,安全性高,動態(tài)可擴展等。
本文采用的AP AUTOSAR 架構(gòu)如圖1 所示。
AP AUTOSAR 診斷基于AP AUTOSAR,位于平臺基礎(chǔ)層,簡稱診斷管理(DM)。診斷管理模塊可以支持多個ECU 的應(yīng)用場景,且支持應(yīng)用部署的動態(tài)可擴展[3]。診斷管理由UDS 傳輸層和診斷應(yīng)用層組成,其中診斷應(yīng)用層又包含診斷通信管理和診斷事件存儲管理兩部分,其結(jié)構(gòu)框圖如圖2 所示。
AP AUTOSAR 診斷系統(tǒng)支持標準的C++API,實現(xiàn)與UDS 傳輸層的連接。但是目前,AP AUTOSAR 的診斷只支持基于以太網(wǎng)的傳輸協(xié)議,將來的AP AUTOSAR 版本也將支持不同總線的傳輸協(xié)議,比如:CAN、CANFD 和Flexray 等[4]。
AP AUTOSAR 診斷系統(tǒng)的傳輸層主要實現(xiàn)的功能有:轉(zhuǎn)發(fā)UDS 診斷請求和回復(fù)的消息;支持DoIP協(xié)議;通過UDS 診斷請求地址(物理尋址和功能尋址)調(diào)度不同的ECU,從而與ECU 建立通信。
診斷通信管理子集實現(xiàn)了上位機與ECU 的診斷服務(wù)功能,類似于CP AUTOSAR 中的DCM 功能。目前,診斷通信管理子集只支持部分有限的診斷服務(wù),后續(xù)將會擴展支持更多的診斷服務(wù)。
診斷通信管理中主要的功能有:診斷會話和UDS服務(wù)功能。其中,診斷會話既能響應(yīng)不同的診斷ECU和client 的會話消息,即支持偽并行處理,又能在默認會話層支持client 端的全并行處理。本文中的診斷通信管理主要支持$10、$11、$14、$19、$22、$27、$2E等幾種常見的診斷服務(wù)功能,其中0x22 和0x2E 服務(wù)支持調(diào)用外部函數(shù)實現(xiàn)診斷自適應(yīng)應(yīng)用功能,即通過二次開發(fā)礦車系統(tǒng)診斷DiagAPP 實現(xiàn)特有的DID(Data Identifier)讀寫功能。該二次開發(fā)讀寫DID 的功能主要是由DiagAPP 提供服務(wù)及callback 函數(shù)[5],若診斷管理收到DID 請求,查詢到服務(wù)后會調(diào)用DiagAPP的讀/寫callback 函數(shù),將收到的返回值發(fā)送出去,其動態(tài)圖如圖3 所示。
診斷事件存儲管理子集主要負責故障碼(DTC)的存儲與管理。Diagnostic Event 是故障診斷和其相關(guān)數(shù)據(jù)存儲的基本單元,每個故障碼對應(yīng)了一個Diagnostic Event。二次開發(fā)的DiagAPP 實時監(jiān)測Diagnostic Event 的狀態(tài),在故障觸發(fā)或者恢復(fù)時[6],DiagAPP 會及時將Diagnostic Event 的狀態(tài)信息上報到DM,同時DM會將該事件的狀態(tài)信息、快照數(shù)據(jù)和擴展數(shù)據(jù)存儲到非易失性存儲區(qū)域,從而達到故障碼的存儲與管理。其中二次開發(fā)的DiagAPP 上報故障碼的動態(tài)圖見圖4。
以MDC300F 為平臺并將其集成到礦車中,與上位機MCDTool 完成組網(wǎng)連接,通過上位機MCDTool遠程訪問MDC300F,對礦車系統(tǒng)進行診斷,見圖5。
在上述硬件平臺的基礎(chǔ)上,華為需要基于礦車診斷系統(tǒng)的需求對AP AUTOSAR 的診斷管理模塊進行配置,并可以提供二次開發(fā)故障診斷功能的C++API,包括DID 的讀寫和故障碼的上報。本文主要基于AP AUTOSAR 開發(fā)自己的APP 實現(xiàn)DID 的讀寫和故障碼的上報,達到開發(fā)礦車自動駕駛診斷特有功能部分,并將該診斷系統(tǒng)應(yīng)用于礦車自動駕駛系統(tǒng)中。上位機和MDC 診斷服務(wù)管理以及二次開發(fā)APP間的關(guān)系如圖6 所示。
搭建測試臺架,PC 端啟動MCDTool 遠程登錄車輛,并將二次開發(fā)的APP 編譯生成的可執(zhí)行文件部署至車輛的MDC300F 產(chǎn)品中,其中MCDTool 遠程登錄車輛顯示界面如圖7 所示。本文以二次開發(fā)功能相關(guān)服務(wù)進行測試,具體測試服務(wù)有0x22、0x2E、0x19、0x14,其中測試的DID 有F189 -軟件版本信息、F1A2-產(chǎn)品的生產(chǎn)日期以及不支持的F197,測試的故障碼以礦車連接的慣導丟失故障碼0xC03887 測試為例。診斷報文的發(fā)送和解析參照ISO13400-2 和ISO14229-5。
軟件版本和生產(chǎn)日期可以協(xié)助開發(fā)或者維修人員定位產(chǎn)品所支持的功能,以及當前產(chǎn)品是否存在問題,是車輛診斷必不可少的診斷信息,故本次測試以DID_F189 和DID_F1A2 為例測試。通過MCDTool 測試了二次開發(fā)的DID 讀取,DID 寫入,以及不在范圍內(nèi)的DID 讀取和寫入三種情況,具體解析的UDS 測試數(shù)據(jù)如表1 所示。
表1 DID 讀寫服務(wù)測試
由以上測試結(jié)果,可以驗證DID 讀寫數(shù)據(jù)服務(wù)測試通過,該礦車自動駕駛系統(tǒng)DID 讀寫數(shù)據(jù)二次開發(fā)功能正常。
慣導作為車輛定位數(shù)據(jù)的主要來源,是礦車自動駕駛不可或缺的一部分,以慣導丟失故障-0xC03887為例測試二次開發(fā)故障碼的功能[7]。主要測試慣導丟失后故障碼狀態(tài)位變化、快照數(shù)據(jù)以及擴展數(shù)據(jù)的記錄情況。MCDTool 解析的測試數(shù)據(jù)如表2 所示。
表2 讀取故障碼測試
由以上測試結(jié)果,可以驗證讀取故障碼服務(wù)測試通過,且礦車自動駕駛系統(tǒng)上報故障碼二次開發(fā)功能正常。
基于上述慣導丟失故障測試,恢復(fù)慣導丟失狀態(tài),緊接著測試$14 服務(wù)清除故障碼的測試。MCDTool解析的測試數(shù)據(jù)如表3 所示。
表3 清除故障碼測試
由以上測試結(jié)果,可以驗證清除故障碼服務(wù)測試通過,該礦車自動駕駛系統(tǒng)二次開發(fā)上報的故障碼能正常清除。
未來自動駕駛領(lǐng)域采用AP AUTOSAR 的架構(gòu)會越來越多,通過搭載第三方成熟的軟硬件平臺,快速開發(fā)出符合自己產(chǎn)品的軟件成為趨勢。開發(fā)出的軟件具有高可靠、一致性強、穩(wěn)定性高的特點,還能大大降低產(chǎn)品開發(fā)成本,加快開發(fā)周期[8-9]。
本文以MDC300F 為平臺,結(jié)合礦車自動駕駛需要讀取和寫入車輛相關(guān)狀態(tài)信息,以及針對礦車實際的硬件和系統(tǒng)的故障監(jiān)測進行二次開發(fā),實現(xiàn)了基于AP AUTOSAR 的礦車自動駕駛診斷的應(yīng)用,對礦車自動駕駛領(lǐng)域的研發(fā)有著積極意義。