劉永宏 張巧娥 樊昀

摘要：本文詳細論述了基于AUTOSAR的車身控制系統(tǒng)（BCM）的診斷開發(fā)，重點介紹了基于AUTOSAR的診斷模塊功能及診斷實現(xiàn)，包括診斷通信管理和診斷事件管理兩大核心模塊，以及診斷功能定義、診斷軟件設計、診斷測試等內容。本文對主機廠開發(fā)電控系統(tǒng)診斷具有一定的指導和借鑒意義。

關鍵詞：AUTOSAR;車身控制系統(tǒng)（BCM）;診斷開發(fā)

1 前言

隨著車輛中電子控制系統(tǒng)越來越多，對算法和控制精度要求越來越高，系統(tǒng)中任意一個部件的故障，比如機械故障或電氣故障，都可能導致整個系統(tǒng)的故障，對于這些故障，由于電子控制系統(tǒng)的復雜性，傳統(tǒng)的汽車診斷和維修的方法難以滿足故障診斷在實時性和準確性上的需求^[1]。車身控制系統(tǒng)（ BCM）主要功能是控制汽車外部燈光、內飾燈、門燈、前后雨刮、中控門鎖、后視鏡折疊、防盜等，并配合其他控制器完成對車窗、電動座椅的控制，主要是用于增強汽車的安全、舒適和方便性。幾乎與車上的所有電子單元有直接或者間接的關聯(lián)，包涵了網絡，智能化控制，軟件標準化等研究議題。為加強汽車電子控制系統(tǒng)軟件的功能，提高車用電子控制系統(tǒng)軟件的可重用性，增強系統(tǒng)軟件的可配置性，加快汽車電子控制系統(tǒng)軟件的開發(fā)效率，改善系統(tǒng)軟件的可靠性和穩(wěn)定性，由全球汽車制造商、部件供應商及其他電子、半導體和軟件系統(tǒng)公司聯(lián)合推出了汽車開放系統(tǒng)架構標準AUTOSAR（ Automofive Open System ArChitecture），其目的是為汽車電子軟件開發(fā)提供開放的、標準化的軟件架構^[2]。AUTOSAR的出現(xiàn)不僅解決了汽車電子軟件開發(fā)中遇到的問題，也解決了目前汽車電子控制系統(tǒng)故障診斷所遇到的問題。在AUTOSAR架構中，其中很重要的一部分就是診斷系統(tǒng)，AUTOSAR診斷系統(tǒng)的目的是適應所有的診斷標準和協(xié)議。

2 AUTOSAR診斷系統(tǒng)介紹

2.1 AUTOSAR分層架構

AUTOSAR的目標是實現(xiàn)汽車電子軟件系統(tǒng)的基本功能，并標準化功能接口，使得軟件模塊易于集成和復用，切實提高軟件的更新和開發(fā)的效率。為了實現(xiàn)這個目標，AUTOSAR按照層次化、模塊化的軟件開發(fā)和設計思想，將ECU軟件架構分成了應用層（ Application Layer）、運行時環(huán)境（ Runtime Environment，RTE）層以及基礎軟件（ Basic Software，BSW）層^[3]，如圖1所示。

在AUTOSAR標準中也對診斷相關模塊進行了定義，其架構如圖2所示，AUTOSAR中的診斷模塊主要包括：應用層診斷策略模塊（ SWC）、處于BSW層的主要有FIM模塊（根據診斷結果使能或禁止軟件構件內部的功能實體）、ECUStateManager（ECU狀態(tài)管理）、DCM（診斷通信管理）、DEM（診斷事件管理）、NVRAMManager（非易失性存儲器管理）。DEM和DCM是診斷中的核心模塊：DEM將故障的故障碼和凍結幀存儲到存儲器中，在需要時將數據提供給DCM;DCM為診斷提供通信服務以及根據外部診斷工具的要求和DEM共同提供診斷服務，它會將外部診斷工具所需要的信息從DEM中獲取并傳遞過去^[4]。

2.2 診斷核心模塊介紹

2 .2.1 診斷通信管理模塊（ Diagnostic Communication Manager）

DCM模塊遵循ISO I4229-1、ISO I5031-5、ISO 15765-4和SAE J1979標準，能直接處理0x10、0x27和0x3E服務。DCM模塊的主要功能在于保證診斷的數據流管理診斷狀態(tài)，尤其是診斷會話和安全狀態(tài)。此外，DCM模塊需要榆查所請求的診斷服務是否支持以及所請求的服務是否能在當前會話狀態(tài)下執(zhí)行，當收到AUTOSAR支持的OBD診斷服務的請求時，DCM會通過調用DEM或SWC模塊提供的接口來響應。

AUTOSAR建議使用三個功能子模塊實現(xiàn)DCM，分別是DSL（Diagnostic Sessinn Layer，以下簡稱DSL）、DSD（ Diagnostic Service Dispatcher，以下簡稱DSD）和DSP（ Diagrmstic ServiceProcessing，以下簡稱DSP）^[5]。主要功能塊組成如下：

（1） DSL（診斷會話層）子模塊負責確保診斷請求和響應的數據流，監(jiān)控診斷協(xié)議的時間和管理診斷狀態(tài)。其主要功能有：請求處理，轉發(fā)診斷請求給DSD子模塊;響應處理，轉發(fā)DSD子模塊的響應給上位機;通信安全等級管理;會話狀態(tài)管理，在會話狀態(tài)改變時通知相關模塊;診斷協(xié)議管理，能夠處理不同的診斷協(xié)議，管理相關資源;通信模式處理。

（ 2） DSD（診斷服務分配）主要負責檢查從網絡上接收到的診斷請求的合法性，并將其轉發(fā)給一個數據處理器。當DSL確認收到了一個診斷請求時，會通知DSD子模塊，這時DSD會對這個請求進行分析，確認診斷會話的合理性，是否達到了允許的服務安全等級，然后分析診斷請求信息中的診斷服務標識來啟動相應的處理，將診斷請求轉發(fā)給對應的數據處理器，如DSP。當數據處理器完成數據的處理后，會觸發(fā)DSD發(fā)出一個響應信息。

（ 3） DSP（診斷服務處理）主要處理相應的診斷服務的請求，這是DCM中最核心的模塊。當收到DSD發(fā)來的請求時，DSP會處理這個診斷服務，主要包括以下幾步：分析這個診斷請求信息;檢查請求的格式，并且確}人這個請求是否支持;從DEM、SWC或AUTOSAR中其他的模塊中請求所需要的數據，主要是DEM和swc;收集好所有數據后，按照標準組織好返回信息。

2.2.2診斷事件管理模塊（Diagnostic Event Manager）

DEM模塊遵循的標準與DCM相同，負責直接處理與DTC（ Diagnostic Trouhle Code）相關的服務。當應用軟件組件中的Monitor Function（故障診斷算法）檢測到故障時，將通知DEM模塊處理和存儲相應的故障診斷事件（由Event ID進行標識）。如果經過判定確診為故障，則調用NVRAMManager（非易失存儲器管理器），提供的接口將其存取到非易失存儲器中（如Flash或者EEPROM），同時通知應用層軟件點亮故障燈，提醒駕駛人員相應的故障信息。

3 診斷設計

當前，整車廠和供應商采用在線診斷與離線診斷相結合的診斷方法。在線診斷通過ECU內部軟硬件實現(xiàn)自診斷。BCM借鑒傳統(tǒng)的診斷方式，在汽車運行過程中，自診斷系統(tǒng)實時監(jiān)控電子控制系統(tǒng)各組成部分的工作狀態(tài)，從而檢測電子控制系統(tǒng)中的故障。自診斷系統(tǒng)一方面將檢測出的故障通過一定的方式（比如報警指示燈）向駕駛員發(fā)出警告，另一方面將故障代碼及相關數據存人ECU存儲器。離線診斷通過外部診斷設備讀取相應的診斷信息，實現(xiàn)診斷操作。實現(xiàn)離線診斷的關鍵在于如何實現(xiàn)診斷設備和ECU之間的通信機制和診斷服務，即診斷協(xié)議。

目前，診斷協(xié)議標準主要分為ISO和SAE兩種體系。美國使用SAE標準體系，包括中國在內的多數國家使用ISO標準體系。在乘用車領域，OEM正從自定義診斷協(xié)議逐漸轉向ISO標準。在商用車領域，OEM沿用SAE診斷，歐洲OEM在此基礎上增加了ISO診斷。表1列出了部分ISO和SAE標準對照。

目前通行的車輛控制器的診斷服務有兩種：法規(guī)要求的和擴展的診斷服務。

1）法規(guī)要求的服務是基于IS015031-5并要ECU強制執(zhí)行的服務。服務范圍0x01-0x0A，

主要目的在于控制和減少車輛排放。

2）擴展服務基于IS014229-1，并且是非強制性的。用于建立對于診斷系統(tǒng)的通用需求。其中，擴展服務可以讀取非排放相關的DTC，和對ECU的flash內存進行編程。乘用車BCM的故障診斷，主要是基于IS014229的UDS擴展診斷。目前，AUTOSAR Version 3.1診斷功能共支持9個OBD服務。參照表3-1可知，AUTOSAR不支持OBD診斷標準中的Ox05服務（請求氧傳感器監(jiān)測結果），原因在于基于CAN總線的Ox05服務可以通過0x06服務實現(xiàn)。

主要包括讀寫基本信息（0x22&0x2E）、輸入輸出控制功能（0x2F）、故障診斷碼定義等內容。

讀寫基本信息（0x22&0x2E）包括：

OEM整車配置定義，比如車速上鎖、防盜報警配置;

ECU生產時間標識;

軟硬件版本號;

讀寫ESK和PIN碼等。

輸入輸出控制功能（0x2F）包括：

室外燈控制，比如左右轉向燈閃爍、前霧燈繼電器控制、后霧燈繼電器控制、遠光燈繼電器控制等;

雨刮/雨刷洗滌輸入輸出狀態(tài)，比如前雨刮低速模式、前雨刮高速模式等;

報警狀態(tài)，比如防盜/中控鎖LED、報警喇叭等;

MCU輸出狀態(tài)，比如中控上鎖繼電器（執(zhí)行一次上鎖動作后自動轉為ECU控制）、中控解鎖繼電器（執(zhí)行一次上鎖動作后自動轉為ECU控制）、電動車窗使能繼電器（持續(xù)打開）、行李箱開啟繼電器（執(zhí)行一次上鎖動作后自動轉為ECU控制）等;

室內燈控制及電池節(jié)電輸出狀態(tài)，比如室內燈（持續(xù)100%占空比運行）、節(jié)電輸H{繼電器（持續(xù)打開）等;

后除霜控制，比如后除霜繼電器控制。

故障診斷碼（讀取故障碼（0x，清除故障碼0x14）主要包括：

前雨刮雨刷，比如前雨刮停止位開關故障、前雨刷洗滌開關故障（周期內停止開關狀態(tài)一直未變）、前雨刷洗滌開關故障等;

燈光故障，比如遠光燈電路故障（對電池短路/對地短路）、近光燈電路故障（對電池短路/對地短路）、位置燈電路故障（對地短路或開路/對電池短路）、室內燈電路故障、前霧燈電路故障等;

發(fā)動機防盜系統(tǒng)故障，比如天線線圈故障、基站通訊故障、無發(fā)射器或發(fā)射器無效、沒收到EMS挑戰(zhàn)碼等。

車窗故障，比如左前車窗欠壓故障（電壓低于9V）、右前車窗控制器內部故障（電機溫度超過設定值）、右前車窗按鍵故障（搖窗機按鍵閉合時間>60s）、右前車窗電機故障（電機無法正常運行）、右前車窗欠壓故障（電壓低于9V）、左后車窗控制器內部故障、左后車窗按鍵故障、左后車窗電機故障、右后車窗控制器內部故障等。

例程控制（ 0x31）

包括鑰匙學習命令和鑰匙擦除命令等。

考慮到系統(tǒng)基于CAN總線的診斷操作和軟件升級的需要，需要對系統(tǒng)進行安全認證和模式切換的管理。系統(tǒng)被分為三個模式：默認模式，擴展模式和編程模式。除了對車輛軟件進行bootloader升級在編程模式下外，其它操作都在默認和擴展模式下。其中車輛正常運行時在默認模式下。進入編程模式和擴展模式都需要安全認證。安全訪問的流程如下：

1）客戶端請求種子;

2）服務器端發(fā)送種子;

3）客戶端發(fā)送密鑰;

4）服務器端響應密鑰是有效的，并且進行自身解鎖。

4 離線診斷測試

為了使BCM的診斷測試更加方便快捷，開發(fā)了一套Windows平臺下基于CAN總線的車身診斷系統(tǒng)軟件。裝有該軟件的平板電腦，通過OBD接口適配器與汽車總線相連，在整個診斷過程中，適配器主要實現(xiàn)兩個功能，一是將平板發(fā)送的數據轉換成CAN或者K信號發(fā)送到整車網絡上，二是將整車網絡上ECU返回的應答信號轉換成USB或者藍牙信號返回給PC機。從而實現(xiàn)PC機遇整車網絡上的ECU數據交互。

通過對圖形化界面的操作進行診斷測試。該軟件可以實現(xiàn)讀取故障碼和清除故障碼、讀寫數據流、執(zhí)行器測試、防盜匹配、鑰匙學習、軟件升級等主要功能，系統(tǒng)架構如圖3所示，通過上位機pad的診斷軟件發(fā)送診斷請求，通過OBD適配器進行數據傳輸實現(xiàn)與ECU的診斷通信。

如圖4所示，診斷儀軟件架構分為幾個部分：

1、底層通信模塊，主要實現(xiàn)CAN通信;

2、診斷通信模塊，實現(xiàn)診斷服務;

3、功能界面，實現(xiàn)診斷服務動態(tài)庫的調用已實現(xiàn)各診斷功能。

通過診斷儀直觀，方便快捷的診斷測試和圖形化的顯示方式，使得BCM的診斷操作更加直觀;通過讀數據流、故障碼、例程控制等操作，可以快速實現(xiàn)診斷測試通過CAN總線的數據監(jiān)測，可以很好的分析過程數據，幫助查找問題原因。功能選取界面、讀取數據流界面、數據分析界面分別如圖5、圖6、圖7所示：

5 結論

AUTOSAR的出現(xiàn)加強汽車電子控制系統(tǒng)軟件的功能，提高車用電子控制系統(tǒng)軟件的可重用性，增強系統(tǒng)軟件的可配置性，加快汽車電子控制系統(tǒng)軟件的開發(fā)效率，改善系統(tǒng)軟件的可靠性和穩(wěn)定性。不僅解決了汽車電子軟件開發(fā)中遇到的問題，也解決了月前汽車電子控制系統(tǒng)故障診斷所遇到的問題，AUTOSAR將成為必然趨勢，對汽車電子軟件開發(fā)的T作流程和商業(yè)模式都將帶來意義深遠的變革。

參考文獻：

[1]羅端，李紅等基于AUTOSAR的汽車電子診斷系統(tǒng)的開發(fā)[J].汽車工程，2012，（ V01.34） N0 2：179-183.

[2]AUTOSAR.Autosar Technical Overview[S/OL].http：//www.autosar.org/

[3]AUTOSAR GbR. AUTOSAR Methodology V1.2.1 [S]. 2008

[4]AUTOSAR GbR. Specification ofDiagnostic Event Manager V3.1[S]. 2008

[5]AUTOSAR GbR. Specification of Diagnoscic Communication Manager V3.1[S]. 2008