基于AUTOSAR的BCM診斷開發

劉永宏 張巧娥 樊昀

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

關鍵詞：AUTOSAR;車身控制系統（BCM）;診斷開發

1 前言

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

2 AUTOSAR診斷系統介紹

2.1 AUTOSAR分層架構

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

在AUTOSAR標準中也對診斷相關模塊進行了定義，其架構如圖2所示，AUTOSAR中的診斷模塊主要包括：應用層診斷策略模塊（ SWC）、處于BSW層的主要有FIM模塊（根據診斷結果使能或禁止軟件構件內部的功能實體）、ECUStateManager（ECU狀態管理）、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模塊的主要功能在于保證診斷的數據流管理診斷狀態，尤其是診斷會話和安全狀態。此外，DCM模塊需要榆查所請求的診斷服務是否支持以及所請求的服務是否能在當前會話狀態下執行，當收到AUTOSAR支持的OBD診斷服務的請求時，DCM會通過調用DEM或SWC模塊提供的接口來響應。

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

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

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

（ 3） DSP（診斷服務處理）主要處理相應的診斷服務的請求，這是DCM中最核心的模塊。當收到DSD發來的請求時，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內部軟硬件實現自診斷。BCM借鑒傳統的診斷方式，在汽車運行過程中，自診斷系統實時監控電子控制系統各組成部分的工作狀態，從而檢測電子控制系統中的故障。自診斷系統一方面將檢測出的故障通過一定的方式（比如報警指示燈）向駕駛員發出警告，另一方面將故障代碼及相關數據存人ECU存儲器。離線診斷通過外部診斷設備讀取相應的診斷信息，實現診斷操作。實現離線診斷的關鍵在于如何實現診斷設備和ECU之間的通信機制和診斷服務，即診斷協議。

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

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

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

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

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

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

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

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

ECU生產時間標識;

軟硬件版本號;

讀寫ESK和PIN碼等。

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

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

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

報警狀態，比如防盜/中控鎖LED、報警喇叭等;

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

室內燈控制及電池節電輸出狀態，比如室內燈（持續100%占空比運行）、節電輸H{繼電器（持續打開）等;

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

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

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

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

發動機防盜系統故障，比如天線線圈故障、基站通訊故障、無發射器或發射器無效、沒收到EMS挑戰碼等。

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

例程控制（ 0x31）

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

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

1）客戶端請求種子;

2）服務器端發送種子;

3）客戶端發送密鑰;

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

4 離線診斷測試

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

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

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

1、底層通信模塊，主要實現CAN通信;

2、診斷通信模塊，實現診斷服務;

3、功能界面，實現診斷服務動態庫的調用已實現各診斷功能。

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

5 結論

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

參考文獻：

[1]羅端，李紅等基于AUTOSAR的汽車電子診斷系統的開發[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