基于ISO 26262的車(chē)身域控制器開(kāi)發(fā)

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

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

1 車(chē)身域控制器設計需求

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

為節省控制器數量和成本,減少整車(chē)線(xiàn)束,簡(jiǎn)化整車(chē)網(wǎng)絡(luò )結構,本文設計了一種集成中央網(wǎng)關(guān)、空調控制器、車(chē)身控制器、副駕駛門(mén)窗控制器的車(chē)身域控制器,并基于功能安全進(jìn)行優(yōu)化。

2 ISO 26262功能安全要求

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

2.1 功能安全目標確認

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

通過(guò)整車(chē)危害分析與風(fēng)險評估,得到車(chē)身域所有相關(guān)功能的安全目標。本文以表1中部分燈光及雨刮器控制功能為例進(jìn)行說(shuō)明。

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

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

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

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

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

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

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

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

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

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

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

表3 硬件度量指標

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

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

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

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

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

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

3.2 硬件隨機失效分析結論

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

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

4 功能安全優(yōu)化

4.1 功能安全優(yōu)化電路

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

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

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

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

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

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

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

4.2 硬件設計驗證

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

5 主從MCU通信協(xié)議設計

5.1 通信流程

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

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

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

5.2 通信故障診斷

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

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

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

6 硬件在環(huán)仿真測試

6.1 硬件在環(huán)仿真系統

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

6.2 車(chē)身域控制器測試平臺搭建

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

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

6.3 車(chē)身域控制器功能測試

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

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

7 結束語(yǔ)

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