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