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