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