新能源商用車車身功能越來越多,給車身控制和整車線束帶來了新的挑戰。為降低控制器數量和成本,減少整車線束的復雜程度,需要將原本多個獨立的控制器集中在一個控制器上,域控制器的概念由此提出[1]。徐工汽車原有車身域控制器設計方案采用單個微控制單元(microcontroller unit,MCU)作為主控處理器,在集成了更多功能以后,原有的設計已經無法滿足功能安全要求,因此本文考慮采用雙MCU協同控制的設計方案。雙MCU的設計已廣泛應用于整車控制器、防抱死系統等整車控制或者主動安全核心裝置,其目的是增加故障冗余,在主MCU發生故障時由從MCU接管控制,實現部分核心功能可以繼續工作從而避免車輛失控[2-5]。

本文采用了主從MCU的方法,對原有車身域控制器方案進行修改,并設計了一套主從MCU的通信協議,在協議內增加了診斷功能。2個MCU可以相互監控對方的工作狀態,如果對方發生死機或工作異常,可以發起MCU復位,并記錄故障信息,不僅滿足了功能設計要求,還提高了功能安全等級。

1 車身域控制器設計需求

新能源商用車的車身域控制器(body domain controller,BDC)集成了車身控制模塊(body control module,BCM)、空調控制器(air conditioner,AC)、副駕駛門控制模塊(pilot door control module,PDCM)和中央網關控制器。其中車身控制模塊負責危險報警燈、天窗、門控、閱讀燈、睡眠燈、喇叭、安全指示燈、行車燈等多個功能[6];空調控制器負責駕駛室空調功能;副駕駛門控制模塊負責車窗升降、后視鏡調節燈功能;中央網關控制器作為不同網絡間信息傳遞的樞紐,負責協調不同CAN總線網絡與其他數據網絡協議間的數據交換、協議轉換以及故障診斷等任務。

為節省控制器數量和成本,減少整車線束,簡化整車網絡結構,本文設計了一種集成中央網關、空調控制器、車身控制器、副駕駛門窗控制器的車身域控制器,并基于功能安全進行優化。

2 ISO 26262功能安全要求

ISO 26262是針對汽車電子系統開發和生產制定的功能安全標準,適用于所有提供安全相關功能的電力、電子和軟件元素組成的設備。

2.1 功能安全目標確認

ISO 26262要求通過危害分析和風險評估(hazard analysis and risk assessment,HARA)來識別產品功能故障引起的危害,對危害事件進行分類,然后定義與之對應的安全目標(safety goal,SG),以避免不可接受的風險[7]。每一安全目標得到相應的汽車安全完整性等級(automotive safety integrity level,ASIL)。ASIL從低到高分為A、B、C、D四個等級,等級越高,表示危害事件的風險越高。

通過整車危害分析與風險評估,得到車身域所有相關功能的安全目標。本文以表1中部分燈光及雨刮器控制功能為例進行說明。

2.2 元器件的安全機制與診斷覆蓋率確認

ISO 26262標準中將診斷覆蓋率分為低、中、高3種等級,各等級的覆蓋率分別可達到60%、90%和99%[8]。

控制器MCU選用國產車規芯片AC78406,該芯片基于ARM CortexM4F內核,144引腳,包含1.128 MB的Flash和124 KB 的系統 SRAM,功能安全符合ASIL B。AC78406芯片具有內核自測、訪問保護、安全管理單元、內部錯誤檢查和糾正 (error checking and correction,ECC)及循環冗余校驗 (cyclic redundancy check,CRC)、時鐘和電源監控等機制,并具有數字回讀功能來檢查數據發送的正確性。

為防止板上5 V供電模塊出現硬件隨機故障,額外增加了一路跛行電源。當供電發生故障時,跛行電源啟動,并由硬件機制直接打開報警燈及轉向燈等,實現對駕駛員的提醒。

高邊驅動選用德州儀器公司的TPS1H100,該驅動帶有過載保護和短路保護功能,并具有自恢復功能的熱關斷/熱調節失地保護和失電保護功能;除此之外帶有一路診斷引腳,可以對開路、短路、過載和接地短路進行檢測以及對電流限制進行診斷。

表2為元器件的安全機制和診斷覆蓋率。

2.3 功能安全指標的硬件參數要求

硬件功能安全確認主要是通過硬件架構指標來衡量是否符合對應的ASIL要求,行業內一般對電路進行失效模式影響與診斷分析(failure mode effect and diagnostic analysis,FMEDA),根據電路圖中各個元器件的失效和失效影響,編制硬件指標計算表格來計算3個參數:單點故障度量(single-point fault metric,SPFM)、潛在故障度量(latent fault metric,LFM)、隨機硬件失效概率度量(probabilistic metric for random hardware failures,PMHF)[9-10]。具體計算公式如下:

式中:下標“SR,HW”表示安全相關的硬件元素;λ為安全相關失效率;MSPF為單點故障度量;MLF為潛在故障度量;MPMHF為隨機硬件失效概率度量;λSPF為單點故障失效率;λRF為殘余故障失效率;λMPF,Latent為潛在多點故障失效率;T為產品生命周期。

失效率的單位是FIT(failures in time),1 FIT表示器件每運行109 h失效1次。高的單點故障度量意味著相關硬件的單點故障和殘余故障所占比例低,所以單點故障度量的值越高越好。

功能安全對硬件指標的要求如表3所示。

表3 硬件度量指標

3 單MCU方案硬件架構指標計算

3.1 單MCU方案硬件失效度量計算

下文以安全目標SG1(控制器正確響應轉向燈)為例,結合系統的診斷措施進行硬件失效分析。轉向燈控制電路如圖1所示。

轉向燈開關作為信號輸入,經過上拉操作后接入MCU,MCU輸出引腳驅動高邊驅動。當MCU檢測到開關為低電平時,設置控制輸出引腳高電平,驅動高邊驅動輸出高電壓給燈組。TPS1H100會有一路診斷引腳輸出電流診斷信號,該引腳通過電阻接地。MCU根據該引腳的電壓反饋來判斷高邊驅動的故障情況。由于域控制器主控MCU引腳不足,輸入需要采用復選芯片。

當R6出現對地短路時,U1出現過流故障,故障反饋信號會拉高,并關斷輸出。而當U2發生故障時,由于缺少足夠的診斷措施覆蓋,所以該失效單點故障率較高。當MCU發生諸如ECC錯誤、外部時鐘不穩定等失效時,使用安全機制SM1～4可以有效檢測該類故障。

根據ISO 26262-5中列出的電子元器件的失效模式及其分布律和各失效模式下適用的安全機制及其診斷覆蓋率,再參考GB/T 37963—2019[11]標準中對電子元器件失效率的標準規定,編制了表4所示的轉向燈控制電路的硬件指標計算表格。

3.2 硬件隨機失效分析結論

硬件指標計算結果如表5所示。單點故障度量為88.5%,潛在故障度量為41.1%,僅符合ASIL A的要求。

以上結果表明單MCU的設計方案無法滿足ASIL B的目標。原因是缺少外部芯片監控主控MCU是否工作正常,導致缺少對多點故障失效的覆蓋,影響潛在失效率;其次,由于車身域控制器集成了多個功能以后,單MCU由于引腳不足,必須要使用多路復選IC才能滿足設計要求,造成單點失效率大幅增加,從而無法滿足技術安全目標。

4 功能安全優化

4.1 功能安全優化電路

為了解決以上問題,可以采用更高規格的MCU作為主控芯片,比如英飛凌公司的TRAVEO T2G系列車身控制專用芯片和恩智浦公司的S32K344系列都符合設計要求,但是兩者的價格都遠超AC78406,成本過高。

本文提出了一種可以提高車身域控制器功能安全的有效方式。為了消除多路復選芯片的硬件隨機失效率,同時增加對MCU失效的診斷覆蓋,最終符合功能安全目標,選擇額外增加一個相同的MCU作為從MCU,同時設計一套主從MCU的通信協議,在協議內增加診斷功能。2個MCU分別獨立接入總線診斷網絡,支持診斷讀取和清除,與使用高規格進口芯片相比,使用2個國產MCU也更具有成本優勢。

根據以上設計,該車身域控制器增加了SM7安全機制,即雙MCU之間相互監控,診斷覆蓋率定為90%。

新的轉向燈控制電路如圖2所示,2個MCU直接接入對方復位引腳,從MCU直接驅動讀取外部IO信號。由于增加了SM7這種安全機制,2個MCU可以互相監控,所以當其中一個MCU發生共因失效時,另一個MCU可以及時發現,并復位系統進入安全狀態,魯棒性較高,同時避免了多路復選芯片失效造成的單點故障。

相較于圖1,圖2減少了元器件U2,同時增加了從MCU。根據新的控制原理圖,結合新增加的診斷條件,重新計算轉向燈控制電路硬件指標。由于增加了診斷機制SM7,主從MCU在發生單點失效和潛在多點失效時均可以被該機制覆蓋。經過計算,改進后硬件指標結果如表6所示。

由表6可以看出,優化后轉向燈控制系統硬件架構的單點故障度量為94.7%,潛在故障度量為78.8%,參照ISO 26262硬件架構指標要求,該指標符合ASIL B。

通過前文的分析,額外增加一個MCU的方式可以在僅增加少量成本下,提高單點故障度量和潛在故障度量,并降低隨機硬件失效概率度量,由此將功能安全等級從ASIL A提高到ASIL B,從而提高車身域控制器的可靠性。

4.2 硬件設計驗證

ISO 26262推薦了3種硬件集成測試方法,分別是功能測試、故障注入測試、電氣測試。這里采用故障注入測試,在電路上增加測試點,手動模擬故障的發生,并使用示波器監視控制器輸出信號,從而驗證安全機制的完整性和正確性。以TPH1S100為例,正常工作時,診斷引腳會將輸出以電流的形式反饋,當發生故障對地短路以后,診斷引腳反饋會超過正常范圍,MCU可以通過該引腳判斷驅動芯片的工作狀態。當手動在R6位置觸發短路故障時,診斷引腳電平如圖3所示,符合設計要求。

5 主從MCU通信協議設計

5.1 通信流程

為保證主從MCU通信的準確性和實時性,基于串行外設接口(serial peripheral interface,SPI)通信設計了一種主從MCU間的通信協議,如圖4所示。其中,主MCU為主機,從MCU為從機。由于SPI為全雙工通信,主從MCU可同時相互進行數據交換,全部通信的最大超時時間為200 μs。

如圖5～6所示,通信分為讀、寫2組數據包,2組數據包均為16字節,包含了序列號、數據幀和循環冗余校驗。寫數據包由主MCU發送給從MCU,用于從MCU數字輸出以及脈沖寬度調制(pulse width modulation,PWM)占空比的控制;讀數據包由從MCU回復給主MCU,用于返回從MCU數字輸入的讀取值和錯誤狀態。

如圖7所示,通過使用邏輯分析儀獲取的波形可以清楚地看出,主從MCU的通信過程與所設計的通信協議一致。

5.2 通信故障診斷

本文制定的基于SPI的通信協議有2種故障:通信超時故障、校驗錯誤故障。

通信超時故障:在主從MCU通信中,當主MCU連續2個周期沒有收到從MCU回復的信息,則從MCU通信超時,主MCU將從MCU復位,錯誤計數器清零,并記錄故障信息。

校驗錯誤:校驗錯誤分為序列號校驗、數據幀校驗和CRC校驗。序列號校驗是總線上傳輸的每個單獨的安全相關幀中包含一個作為信息一部分的計數器,在生成每個連續幀時計數器值增加。接收方隨后能通過驗證計數器的值是否加1來探測任何的幀丟失或者幀未更新。數據幀每個字節的bit0為奇校驗位。讀寫數據包的最后2個字節為CRC校驗部分。通過以上校驗方式可以確保主從通信過程的穩定性和安全性。

6 硬件在環仿真測試

6.1 硬件在環仿真系統

本文采用基于Vector設備的硬件在環 (hardware in loop,HIL)仿真測試系統對車身域控制器進行功能測試。硬件在環仿真是一種半實物的閉環仿真方式,通過將真實的控制器接入虛擬建模出來的環境中進行各項功能的測試和驗證,從而提高開發質量,縮短研發周期[12]。測試機柜由電源管理模塊、程控電源、調理電源、工控機以及一系列Vector功能板卡組成[13]。測試時控制器通過擴展架與HIL機柜相連,以總線仿真與測試工具CANoe為載體搭建測試工程,以此來實現控制器與HIL機柜之間的信號實時交互;根據測試工程面板創建的輸入輸出信號按鍵來控制HIL機柜模擬實車給控制器發送開關量信號,同時將控制器的輸出響應信號通過機柜顯示到上位機用于觀察結果。LabCar臺架作為一個接近實車尺寸大小的物理裝置,其中各類器件均按照實車結構進行布局[14]。按照實車零部件、線束、蓄電池等電器部件位置在LabCar臺架上進行實物搭建。將通過HIL機柜驗證后的控制器安裝到LabCar上進行測試,檢查車燈、轉向燈等零部件是否可以正常工作。

6.2 車身域控制器測試平臺搭建

如圖8所示,將一鍵啟動控制器、主駕駛門控、胎壓傳感器、整車控制器等報文節點添加到模擬設置窗口中,它們之間通過總線板卡連接。測試系統根據整車通信規則,通過模擬節點發送總線報文并使用數字接口模擬整車信號,通過判斷被測控制器的響應情況來檢查控制器是否符合功能設計要求。

根據該車身域控制器的功能及具體的HIL測試條件搭建測試面板,它包含商用車的前大燈、轉向燈、駕駛室內部照明燈、雨刮、天窗、空調等功能的控制。此外,將各個執行部件的控制信號也做在面板上,以便于及時觀察控制器控制信號的響應情況。

6.3 車身域控制器功能測試

測試項目工程搭建完畢后,基于車身域控制器的功能規范編寫測試用例,再通過上述測試平臺所搭建的測試面板對車身域控制器的功能進行逐一驗證。該過程既可以驗證應用層的功能邏輯的正確性,又能驗證控制器底層對于輸入輸出的數字信號、模擬信號、PWM調速信號以及CAN信號處理的實效性。表7羅列了域控制器的所有功能測試項,將測試項目按照用例編寫成腳本進行自動化測試,僅最后對測試結果進行分析,可省去大量測試時間。CANoe測試腳本運行結果如圖9所示。

經過測試,車身域控制器上述功能滿足設計要求,車身域、門控及空調的應用層功能都可以被正確地執行。該種控制器對域控制器功能中所涉及的數字信號、模擬信號、PWM信號以及CAN信號的處理能力均達到設計要求,對應用層邏輯的處理符合預期目標。

7 結束語

本文根據企業實際需求,在兼顧成本和實用性的情況下,提出了一種雙MCU架構的車身域控制器設計方法。通過使用注入測試和HIL功能測試,證明該控制器符合設計要求。該方案具有良好的可靠性和工程實用性,給未來車身域控制器設計提供了新的思路。