本文基于Aspice模型中V流程開發(fā)模式，從汽車控制系統(tǒng)的需求分析、架構(gòu)設(shè)計、軟硬件需求分析、代碼/模型開發(fā)實現(xiàn)、系統(tǒng)測試及驗證整個V模型各階段，結(jié)合ISO 26262功能安全標(biāo)準(zhǔn)在各階段的要求，提出一種Aspice與ISO 26262相融合的汽車控制系統(tǒng)開發(fā)流程，并結(jié)合實踐開展過程，闡明各開發(fā)過程使用的開發(fā)工具配置情況。
隨著汽車行業(yè)電動化、智能化、網(wǎng)聯(lián)化的發(fā)展以及客戶對整車舒適性及安全性要求日益提高，整車上電子電氣系統(tǒng)數(shù)量也隨著增多。在軟件定義汽車大背景下，整車上電子電氣系統(tǒng)的開發(fā)過程和品質(zhì)保證過程都應(yīng)有相關(guān)的標(biāo)準(zhǔn)和流程作為風(fēng)向標(biāo)，國際和國家標(biāo)準(zhǔn)化組織陸續(xù)制定頒布相關(guān)功能安全標(biāo)準(zhǔn)ISO 26262及GB/T34590。截至目前國內(nèi)有部分軟件企業(yè)已經(jīng)按照Aspice模型這一專門針對汽車軟件開發(fā)的規(guī)范及實踐來指導(dǎo)汽車軟件開發(fā)[1]。但近年來由于車輛中嵌入式電子系統(tǒng)復(fù)雜性的增加，來自于軟件系統(tǒng)損壞以及隨機硬件損壞的風(fēng)險也在日漸上升，將ISO 26262的功能安全規(guī)范要求納入車輛軟件開發(fā)過程中，也能改善車輛系統(tǒng)軟件開發(fā)產(chǎn)品品質(zhì)、開發(fā)工作效率，提升產(chǎn)品開發(fā)過程的穩(wěn)定性。因此本文基于Aspice模型中V流程開發(fā)模式，從汽車控制系統(tǒng)的技術(shù)需求分析、架構(gòu)設(shè)計、軟硬件需求分解、代碼/模型設(shè)計及實現(xiàn)、測試驗證等各階段，結(jié)合ISO 26262標(biāo)準(zhǔn)對各階段的開發(fā)要求，提出一種多標(biāo)準(zhǔn)相融合的汽車控制系統(tǒng)開發(fā)流程，同時結(jié)合工程實踐，闡明各階段使用的開發(fā)工具配置情況。
1 Aspice簡介及軟件開發(fā)流程
1.1 Aspice簡介
SPICE是Software Process Improvement and Capability Determination的縮寫簡稱，是由ISO、IEC、JTC這3家國際機構(gòu)共同提出的標(biāo)準(zhǔn)，根據(jù)此標(biāo)準(zhǔn)，行業(yè)分別派生出了各種更具體的規(guī)范，包括醫(yī)藥設(shè)備領(lǐng)域制訂的Medi SPICE、航天領(lǐng)域制訂的SPICE for SPACE，而汽車行業(yè)建立了Automotive SPICE，即Aspice[2]。Aspice是汽車行業(yè)開展軟件產(chǎn)品研發(fā)過程的最佳模型，用以衡量汽車軟件開發(fā)組織的開發(fā)實力和組織流程的管理能力，指導(dǎo)汽車軟件開發(fā)團隊開展軟件開發(fā)，從而改善軟件品質(zhì)和提高開發(fā)效率。
1.2 Aspice軟件開發(fā)流程
Aspice作為汽車行業(yè)軟件開發(fā)過程最佳模型，規(guī)定了V開發(fā)流程和支持過程各階段開展的研發(fā)內(nèi)容及輸入輸出交付規(guī)定，如圖1所示。
圖1 V模型流程
2 ISO 26262軟件開發(fā)流程
ISO 26262適用對象是道路車輛的功能安全，對產(chǎn)品項目的安全管理、產(chǎn)品開發(fā)、生產(chǎn)、運行、服務(wù)、報廢、支持過程整個生命周期明確了要求。其中產(chǎn)品開發(fā)包括系統(tǒng)層級、軟件層級、硬件層級三方面。功能安全開發(fā)流程總覽如圖2所示，產(chǎn)品開發(fā)的系統(tǒng)、硬件和軟件的研發(fā)過程如圖3所示[3]。
圖2 ISO 26262標(biāo)準(zhǔn)概覽
圖3 產(chǎn)品開發(fā)系統(tǒng)、軟硬件要求
3 Aspice和ISO 26262融合的開發(fā)研究
結(jié)合Aspice與ISO 26262功能安全的要求，將產(chǎn)品開發(fā)各階段進行融合研究，并將各層面技術(shù)要求結(jié)合工程實踐進行闡述，融合的產(chǎn)品開發(fā)框架如圖4所示。各階段開發(fā)工作描述如下。
圖4 Aspice與ISO26262相融合的產(chǎn)品開發(fā)框架
1）概念設(shè)計。概念設(shè)計階段確定干系人要求，并確認(rèn)這種要求可以被正確理解，同時對相關(guān)項目做出界定，辨識由相關(guān)項目中的功能異常表現(xiàn)導(dǎo)致的危險事項，提出避免危險事項出現(xiàn)和降低危險程度的安全目標(biāo)并確定基于關(guān)聯(lián)項目的可能危險事項，對關(guān)聯(lián)項目做出評價。對重大危險事項實施系統(tǒng)性評價，并明確了安全目標(biāo)以及ASIL級別。其中，危險辨識與危險性的評價可采用FMEA、HAZOP、頭腦風(fēng)暴等方式，而ASIL級別則按照嚴(yán)重程度、暴露機率與可控性等三種原因設(shè)定，三因素級別詳見表1~表3。根據(jù)安全目標(biāo)分解出相應(yīng)ASIL等級的安全需求，此階段輸出相關(guān)項定義、HARA分析報告及干系人需求說明書，其中干系人需求說明書涵蓋安全需求。干系人需求通過需求管理工具PTC Integrity進行需求記錄，同時管理需求狀態(tài)及實現(xiàn)情況。
表1 嚴(yán)重度等級
表2 關(guān)于運行場景的暴露概率等級
表3 可控性等級
2）技術(shù)需求分析。技術(shù)需求分析階段需根據(jù)干系人需求說明書進行需求分析，將干系人需求和安全需求分解成技術(shù)需求、定義安全機制，用于探測故障并防止或減輕出現(xiàn)在系統(tǒng)輸出端的違反功能安全要求的失效，形成系統(tǒng)需求和建立系統(tǒng)架構(gòu)。在系統(tǒng)需求分析過程中，對需求進行分類分析，明確功能需求、非功能需求和接口需求，組織專家評審并確定需求的正確性和可驗證性；對系統(tǒng)需求的優(yōu)先級進行分析，明確系統(tǒng)需求實現(xiàn)的順序；同時建立客戶需求和系統(tǒng)需求的雙向追蹤關(guān)系。系統(tǒng)架構(gòu)建立后將安全要求分配給系統(tǒng)的各要素，進行需求安全等級分解，明確各條目需求的ASIL等級。同時對子系統(tǒng)進行安全分析，避免系統(tǒng)性失效。技術(shù)需求分析方法采用結(jié)構(gòu)分析法，從系統(tǒng)頂層向下設(shè)計、逐層分解設(shè)計，明確系統(tǒng)各組件之間的程序流和數(shù)據(jù)流。此階段輸出系統(tǒng)需求、系統(tǒng)架構(gòu)及系統(tǒng)獨立失效分析報告。其中系統(tǒng)架構(gòu)安全設(shè)計分析方法參見表4。架構(gòu)設(shè)計采用ENTERPRISE ARCHITECT。
表4 系統(tǒng)架構(gòu)設(shè)計分析
3）軟硬件需求分析。軟硬件需求分析階段將系統(tǒng)需求和安全需求分別轉(zhuǎn)變?yōu)橛布枨蟆④浖枨蟆Ｔ谲浖枨蠓治鲞^程中，分析軟件需求之間的依賴關(guān)系，保證需求的正確性、技術(shù)可行性及可驗證性；同時構(gòu)建與系統(tǒng)需求的一致性和可追溯性。根據(jù)相應(yīng)的軟硬件需求，開發(fā)滿足軟硬件安全要求和其他軟硬件要求的軟件架構(gòu)設(shè)計和硬件架構(gòu)設(shè)計，指導(dǎo)軟硬件的詳細(xì)設(shè)計開發(fā)，同時對軟件架構(gòu)進行安全分析。此階段輸出軟件需求、硬件需求、軟件架構(gòu)及架構(gòu)安全分析報告。其中軟件架構(gòu)和硬件架構(gòu)設(shè)計原則見表5和表6。軟硬件需求記錄、分析及狀態(tài)跟蹤通過PTC Integrity。
表5 軟件架構(gòu)設(shè)計原則
表6 硬件架構(gòu)設(shè)計原則
4）詳細(xì)設(shè)計及代碼開發(fā)。詳細(xì)設(shè)計及代碼開發(fā)階段將根據(jù)軟硬件需求進行硬件設(shè)計、軟件詳細(xì)設(shè)計、代碼開發(fā)，其中代碼設(shè)計遵循原則見表7。代碼開發(fā)時利用模塊化設(shè)計思路，將程序軟件劃分成獨立子功能的模塊，然后將模塊集成形成整體軟件程序，從而滿足客戶的需求。代碼和模型開發(fā)采用MATLAB/Simulink。
表7 軟件單元設(shè)計和實現(xiàn)的設(shè)計原則
5）單元測試及硬件調(diào)試。定義軟件單元測試規(guī)范，明確單元測試的技術(shù)和方法，制定單元測試驗證計劃模板及測試報告模板。軟件單元測試包括靜態(tài)測試和動態(tài)測試，靜態(tài)測試主要是對代碼靜態(tài)分析和模型代碼審核，代碼靜態(tài)分析借助常用工具，如Model Analysis、QAC。而模型代碼審核依據(jù)則是由專家已編寫的代碼或模型Checklist。動態(tài)測試前為設(shè)計測試案例，即基于設(shè)計說明或設(shè)計模型期望輸入輸出信號，測試案例設(shè)計過程根據(jù)需求分析、等價類的生成和分析、邊界值分析、經(jīng)驗等進行開展，測試類型主要包括基于需求的試驗、接口測試、故障注入試驗和背靠背的試驗等，并在此階段輸出單元測試報告。硬件調(diào)試階段包括對硬件模塊實施調(diào)試，并按照調(diào)試清單進行調(diào)試，其中調(diào)試清單中的項目和模塊均由硬件設(shè)計相關(guān)專家編寫，最后產(chǎn)出硬件調(diào)試報告。
6）集成及測試驗證。將各應(yīng)用層和基礎(chǔ)層模型及代碼集成嵌入式軟件，根據(jù)軟件架構(gòu)設(shè)計說明進行集成測試。集成測試通過后，根據(jù)軟件需求開展嵌入式軟件功能測試，輸出嵌入式軟件測試報告。根據(jù)系統(tǒng)需求編寫系統(tǒng)測試用例，編制系統(tǒng)測試計劃，通過HILL臺架或者發(fā)動機試驗臺架開展系統(tǒng)測試，輸出系統(tǒng)測試報告。根據(jù)客戶需求編寫整車驗證用例，編制整車驗證計劃，利用整車資源開展整車驗證，輸出整車驗證報告。其中測試驗證方法見表8。
表8 測試驗證
4 結(jié)束語
目前汽車控制系統(tǒng)研發(fā)過程中，Aspice模型在實際應(yīng)用中具有重要的價值，將ISO 26262功能安全標(biāo)準(zhǔn)的要求融入Aspice汽車軟件開發(fā)流程中，并以此指導(dǎo)汽車軟件開發(fā)實踐，會大幅改善汽車軟件開發(fā)品質(zhì)、開發(fā)效率以及提高產(chǎn)品的安全性。
轉(zhuǎn)自智能汽車設(shè)計
