隨著軟件定義汽車的趨勢日益加強，道路車輛電子電器系統(tǒng)滿足功能安全已經(jīng)成為基本要求。近期，在歐盟車輛型式批準(zhǔn)(typeapproval依據(jù)部分UNECE法規(guī))和我國車輛的CCC認(rèn)證中，對采用電子控制的轉(zhuǎn)向、制動、動力電池管理系統(tǒng)等也引入了功能安全要求。高效的軟件架構(gòu)設(shè)計顯然對功能安全的實施和落地起著引導(dǎo)性作用，所以電子電器系統(tǒng)滿足功能安全要求已經(jīng)成為產(chǎn)品基本屬性。

針對軟件架構(gòu)如何滿足功能安全要求，業(yè)內(nèi)人士紛紛借鑒了E-Gas架構(gòu)，E-Gas最先被應(yīng)用于發(fā)動機控制器EMS，由Level1功能層、Level2功能監(jiān)控層、Level3控制器監(jiān)控層三部分組成。國內(nèi)相關(guān)論文分別將E-Gas架構(gòu)應(yīng)用于各個控制功能中，其中專利、文獻、文獻、文獻、文獻都針對功能安全標(biāo)準(zhǔn)設(shè)計了整車控制器硬件和軟件，但并未涉及Level2軟件架構(gòu)。

因此，為了彌補E-Gas架構(gòu)未明確提出基于模型開發(fā)MBD的Level2軟件架構(gòu)的缺陷，且架構(gòu)設(shè)計要滿足高內(nèi)聚低耦合、合適的分層等功能安全要求，本文針對整車控制器VCU設(shè)計了一種Level2功能監(jiān)控層軟件架構(gòu)，不但符合功能安全架構(gòu)設(shè)計要求，而且可應(yīng)用于其他ECU功能安全Level2設(shè)計中，有助于功能安全設(shè)計進一步落地，降低實施難度。

一、VCU模型整體架構(gòu)

設(shè)計整車控制器VCU模型Level1、Level2架構(gòu)，如圖1所示，包括時序調(diào)度、輸入信號、Level1、Level2和輸出信號模塊，需滿足功能安全可理解性、一致性、簡單性、可驗證性、模塊化、抽象化、封裝性、可維修性等架構(gòu)設(shè)計原則和要求。

圖1 VCU控制模型架構(gòu)

Level1被稱為功能層，包含整車控制基本功能，如電機扭矩需求、能量回收等，整車高低壓電源管理，如高壓安全、低壓管理等，以及在檢測到故障時控制系統(tǒng)的反應(yīng)。Level2被稱為功能監(jiān)控層，檢測Level1功能軟件的缺陷過程。例如，通過監(jiān)測計算的需求扭矩值或車輛縱向加速度，當(dāng)系統(tǒng)發(fā)生故障時，會觸發(fā)系統(tǒng)反應(yīng)，進入安全狀態(tài)。Level1和Level2獨立的開發(fā)和各自生產(chǎn)代碼要運行到不同的分區(qū)內(nèi)，避免共因失效和免于干擾，并且Level2監(jiān)控層代碼要運行到硬件安全核內(nèi)。

二、Level1功能層軟件架構(gòu)

設(shè)計VCU模型Level1功能層架構(gòu)，如圖2所示，Level1進行ECU基本功能實現(xiàn)和應(yīng)用時，ECU的基礎(chǔ)功能必須存在，包括時序調(diào)度、輸入信號匯總、輸出信號匯總、控制功能模塊(如整車運行狀態(tài)控制、扭矩控制、能量管理、診斷處理、加速踏板控制、擋位控制、續(xù)駛里程、低壓電源控制、儀表顯示控制等模塊)，各模型庫均采用模型應(yīng)用(ModelRefercence)方法引用，方便各模塊庫維護、復(fù)用或移植。

圖2 VCU控制模型Level1功能層架

三、Level2功能監(jiān)控層架構(gòu)

VCU模型Level2功能監(jiān)控架構(gòu)，如圖3所示，包括信號校驗、Level2過程監(jiān)控、輸出監(jiān)控三個模塊，其作用是對ECU的Level1功能層中實現(xiàn)的設(shè)計功能安全相關(guān)模塊進行監(jiān)控，屬于監(jiān)控模塊，增加該模塊可以滿足功能安全要求，可以對功能安全進行如下分解：Level1功能安全等級為QM(X)，Level2功能安全等級為X(X)，其中X可以根據(jù)具體功能分為ASILA/B/C/D。

1.Level2信號校驗軟件架構(gòu)

(1)輸入輸出接口

信號校驗?zāi)K輸入輸出接口，如表1所示。

表1 Level2信號校驗?zāi)K接口

(2)安全機制

Level2輸入模塊對相應(yīng)的安全相關(guān)的信號進行完整性、有效范圍、合理性等校驗，然后分別輸出給Level1和Level2過程監(jiān)控和輸出監(jiān)控用，具體校驗機制和時序圖，如圖4所示。

圖4 信號校驗?zāi)K架

假設(shè)每隔TBDms接收接口1信號，首先對信號進行timeout超時檢測，當(dāng)超過TBD信號周期內(nèi)沒有接收到，判定信號丟失;然后進行CRC檢測，當(dāng)校驗沒有通過時，判定這幀信號CRC錯誤;再進行alivecounter檢測，當(dāng)校驗沒有通過時，判定信號alivecounter錯誤;最后進行valid和范圍檢測，當(dāng)校驗沒有通過時，判定信號為invalid;檢測到以上任意錯誤時，發(fā)送接口3為無效且發(fā)送接口2為默認(rèn)值或上一周期信號給其他模塊。

2.Level2過程監(jiān)控軟件架構(gòu)

(1)輸入輸出接口

Level2過程監(jiān)控模塊輸入輸出接口，如表2所示。

(2)安全機制

根據(jù)Level1功能層中安全相關(guān)功能，其安全信號輸出作為Level2監(jiān)控層的輸入，由Level2監(jiān)控層對Level1進行監(jiān)控，架構(gòu)圖如圖5所示：無論Level1功能層如何，被監(jiān)控的功能應(yīng)在Level2監(jiān)控層中采取冗余異構(gòu)算法對接口4進行校驗，并在出現(xiàn)錯誤或異常時觸發(fā)系統(tǒng)反應(yīng)，將其帶入可控狀態(tài)，即輸出接口6、接口7、接口8、接口9。

3.Level2輸出監(jiān)控軟件架構(gòu)

(1)輸入輸出接口

Level2輸出監(jiān)控模塊輸入輸出接口，如表3所示。

(2)安全機制

Level2對level1的最終的輸出結(jié)果、CAN收發(fā)器或硬線驅(qū)動輸出，以及執(zhí)行器最終的執(zhí)行情況進行閉環(huán)實時監(jiān)控，架構(gòu)圖如圖6所示，具體策略分為三個層次，一是模型輸出信號監(jiān)控：Level2采用獨立于Level1控制策略對接口10進行監(jiān)控，避免邏輯錯誤或輸出未連線;二是驅(qū)動輸出監(jiān)控：接口10輸出給輸出驅(qū)動，Level2需Debounce一定時間后監(jiān)控驅(qū)動是否正確輸出;三是執(zhí)行器監(jiān)控：執(zhí)行器響應(yīng)接口11信號后，執(zhí)行動作并反饋接口12，Level2監(jiān)控其執(zhí)行狀態(tài)是否滿足預(yù)期結(jié)果，以上若出現(xiàn)一個或多個監(jiān)控故障，則需通過接口14發(fā)送儀表提醒駕駛員，且通過接口15或16使系統(tǒng)進入安全狀態(tài)。

四、分析和測試驗證

通過在軟件架構(gòu)級別應(yīng)用安全分析(FMEA和FTA)和DFA相關(guān)失效分析，找出失效原因(Fault)，以及分析失效影響(Effect)。結(jié)果表明Level2軟件架構(gòu)提供監(jiān)控功能、行為和ASIL等級滿足設(shè)計要求。

利用靜態(tài)測試工具MODELINSPECTOR選擇功能安全標(biāo)準(zhǔn)和MAB標(biāo)準(zhǔn)進行模型集成靜態(tài)語句掃描、語義分析、識別軟件行為，無需人工設(shè)計測試用例，無需運行代碼的自動分析過程，直至結(jié)果表明滿足功能安全架構(gòu)設(shè)計要求;利用動態(tài)測試工具MODELVERIFIER，針對Level2模型要素之間特有的集成層次和接口進行測試，人工設(shè)計“打樁”代碼，在原始碼中植入“檢測代碼”，需要人工設(shè)計測試用例，運行代碼或測試用例，獲取軟件運行過程產(chǎn)生的數(shù)據(jù)，對數(shù)據(jù)進行安全分析迭代修正，直至測試結(jié)果表明集成的軟件組件滿足其功能安全軟件架構(gòu)設(shè)計需求。

審核編輯：湯梓紅