作者 | 不可說
出品 | 汽車電子與軟件
01 ASPICE介紹
ASPICE是Automotive SPICE的縮寫，是一種用于評估和改進汽車軟件開發過程的國際標準；ASPICE定義了一組標準化的軟件開發過程和最佳實踐，適用于整個軟件生命周期，包括需求工程、軟件設計、編碼、測試和維護等各個領域。
通過規范化開發過程，ASPICE有助于提高軟件產品的質量和可維護性，確保軟件符合質量要求；同時對于開發者來講，ASPICE的實施要求團隊具備一定的技能和知識，這促進了團隊技能和專業知識的提升，同時也促進了組織內的知識和經驗的共享。
各家OEM與Tire1等可以去花費一定成本去做ASPICE評審，以彰顯自家公司對于軟件開發過程管理和實施能力水平。
評審的等級是基于ISO/IEC 15504的能力成熟度模型，對汽車軟件開發過程的成熟度進行劃分的。
ASPICE評審等級通常劃分為以下六個等級，每個等級代表了不同的水平層次，目前行業內達到L1~L2的較多：
Level 0 - 未實施；
Level 1 - 執行；提供基本的項目管理和開發活動，但缺乏系統的管理；
Level 2 - 管理了過程的執行；企業不僅能夠完成產品研發相關工作，還能提前制定嚴謹和周全的工作計劃，確保各項目能夠有序進行；
Level 3 - 定義了過程的執行；軟件開發過程在組織范圍內得到了定義和標準化，符合需求和目標；
Level 4 - 量化了過程的執行；軟件開發過程的績效進行了量化，通過數據分析和評估改進；
Level 5 - 優化了過程的執行；軟件開發過程持續改進，并與組織的業務目標和策略相一致。
02 SWE介紹
ASPICE過程參考模型
作為汽車軟件開發工程師，應該了解并盡量遵循SWE過程，不僅有助于提高軟件質量，還能夠降低開發成本、縮短開發周期，并增強軟件的可維護性和可擴展性。
ASPICE SWE（Software Engineering Process Group，軟件工程過程組）是ASPICE中的一個關鍵部分，它涵蓋了軟件開發的多個階段和流程。SWE過程組的主要目標是確保軟件開發過程中的各個階段都遵循最佳實踐，以提高軟件質量、減少開發風險，并滿足汽車行業的嚴格要求。
03 SWE.1
軟件需求分析；目的是建立一套與系統需求和系統架構一致的結構化和分析的軟件需求。
對應這一部分的開發者，應該接收來自SYS.2、SYS.3的輸入，即系統需求和系統架構設計。
需要完成六項BP（Base Practices 基礎實踐；ASPICE各項流程均定義了不同的BP，需要開發者遵守并完成）：
-
Specify software requirements. 定義軟件需求
-
Structure software requirements. 結構化軟件需求
-
Analyze software requirements. 分析軟件需求
-
Analyze the impact on the operating environment. 分析需求在操作環境中的影響
-
Ensure consistency and establish bidirectional traceability. 確保一致性和雙向可追溯性
-
Communicate agreed system requirements and impact on the operating environment. 與利益相關者對系統需求及其影響溝通達成一致
舉例說明，以車身控制中外燈系統中的近光燈部分需求點為例，SWE1對應描述如下：
SW_REQ-10001 若整車電源模式是ON，車輛應在打開近光燈開關被按下時打開近光燈；
SW_REQ-10002若整車電源模式是ON，車輛應在關閉所有燈光被按下時關閉近光燈；
SW_REQ-10003車輛應為用戶提供信息（近光指示燈）以提示近光燈的工作狀態。
架構化需求及環境模塊影響分析：
04 SWE.2
軟件架構設計；目的是建立一個與軟件需求一致的且分析過的軟件架構，包括靜態和動態方面。
該過程的輸入既是來源于SWE.1。
5個BP說明如下：
-
Specify static aspects of the software architecture.定義靜態的軟件架構
-
Specify dynamic aspects of the software architecture. 定義動態的軟件架構
-
Analyze software architecture. 分析軟件架構
-
Ensure consistency and establish bidirectional traceability. 確保一致性并建立雙向可追溯性
-
Communicate agreed software architecture. 溝通商定的系統架構
靜態架構示意：
定義軟件模塊的靜態信息，如接口名、信號名、模塊名等；
繼續以上述SW_REQ-10001~ SW_REQ-10003需求為例
動態架構示意：重點在于模塊的動態交互、時序等邏輯體現
05 SWE.3
軟件詳細設計和單元構建；目的是建立與軟件體系結構一致的軟件詳細設計，包括靜態和動態方面，并構建與軟件詳細設計一致的軟件單元。
輸入來源于SWE.1與SWE.2；
同樣包含5個BP：
-
Specify the static aspects of the detailed design. 定義軟件詳細配置
-
Specify dynamic aspects of the detailed design. 定義軟件詳細模塊交互
-
Develop software units. 開發并配置模塊單元
-
Ensure consistency and establish bidirectional traceability. 確保一致性并建立雙向可追溯性
-
Communicate agreed software detailed design and developed software units. 溝通商定的軟件詳細設計和開發的軟件單元
這一環節是對軟件架構設計中的SW Component的進一步設計，同樣的也包含了動態詳細設計與靜態詳細設計兩個方面；通常需要識別出SWE.2環節中設定的軟件模塊SWC中包含哪些子模塊，不過，在通常的正向開發過程中，SWE.2執行過程已經完成這一步分析，如LoBeam SWC中包含了SW unit：電源判斷模塊 與 SW unit：燈光判斷模塊兩個軟件子模塊；
對SW uint進行更詳細的設計：定義操作函數、設定或理解交互接口；
如果涉及到復雜的數據類型或者算法，也需要在這個環節完成；
06 SWE.4
軟件單元驗證；目的是驗證軟件單元是否與軟件詳細設計一致，提供證據證明軟件單元符合軟件詳細設計和非功能軟件需求；
該流程含有5個BP：
-
Specify software unit verification measures. 規定軟件單元驗證措施
-
Select software unit verification measures. 選擇軟件單元驗證措施
-
Verify software units. 驗證軟件單元
-
Ensure consistency and establish bidirectional traceability. 確保一致性，建立雙向可追溯性
-
Summarize and communicate results. 總結并交流結果
所要驗證的對象來自于SWE.3的輸出；
根據BP，實際操作流程可以如下：
-
收齊輸入物（被測模型/代碼），即SWE.1需求，與SWE.3代碼/模型
-
搭建測試環境
在代碼模型里模擬輸入，觀測輸出；如在代碼simulink模型中搭建測試module；
3. 導入測試用例
首先要制定測試用例，以SWE.3中的模塊為例，制定測試case；
4. 執行測試
按照測試case執行測試代碼+功能代碼，記錄測試結果；
5. 針對測試結果及覆蓋度結果補充測試用例
分析測試結果，同步的檢查測試用例制定的完整性
6. 回歸測試
反饋測試NG項，待代碼修改后回歸測試
完整的流程過程物/輸出物應該還包含詳細的測試計劃、測試報告分析等內容。
07 SWE.5
軟件組件驗證和集成驗證；這一環節目的是驗證軟件組件與軟件架構設計一致，并集成軟件元素，驗證集成的軟件元素與軟件架構和軟件詳細設計一致
該流程含有7個BP：
BP1: Specify software integration verification measures 指定軟件集成驗證措施
BP2: Specify verification measures for verifying software component behavior 指定驗證軟件組件行為的驗證措施
BP3: Select verification measures 選擇驗證措施
BP4: Integrate software elements and perform integration verification 集成軟件元素并執行集成驗證
BP5: Perform software component verification 執行軟件組件驗證
BP6: Ensure consistency and establish bidirectional traceability 確保一致性并建立雙向可追溯性
BP7: Summarize and communicate results 總結和交流結果
SWE.4與SWE.5均是做軟件驗證，區別就是范圍不一樣，SWE.4側重于單個軟件單元的驗證，確保單元的正確性和質量；而SWE.5則關注于軟件組件的集成和整體系統的測試，確保系統能夠正確運行并滿足需求。
SWE.5參考流程
SWE.5的關鍵輸入即是SWE.2中的輸出物--軟件架構；軟件集成后，按照SWE.2中SWC模塊逐步進行測試即可；測試過程與相關過程物類型與SWE.4接近，此處不再舉例。
08 SWE.6
軟件驗證；確保集成的軟件與軟件需求一致，也叫軟件合格性測試
該流程含有5個BP：
BP1: Specify verification measures for software verification 規定軟件驗證的驗證措施
BP2: Select verification measures 選擇驗證措施
BP3: Verify the integrated software 驗證集成軟件
BP4: Ensure consistency and establish bidirectional traceability 確保一致性并建立雙向可追溯性。
BP5: Summarize and communicate results 總結并溝通結果
該環節的輸入主要來源于上級SYS.1中的系統需求與SWE.1中的軟件需求；
SWE.6與SWE.4、SWE.5同屬測試范疇，為了更好的區分，特意做出如下對比：
SWE.6參考執行流程
以SWE.1中軟件需求SW_REQ-10001為例，驗證用例和測試結果記錄表格可參考如下：
09 總結
遵循ASPICE開發流程，既要有專業化知識，還要有標準化流程，專業化知識包含了專業的汽車電子技術、編程能力、專業工具使用能力等；標準化流程即是各家主機廠或者供應商根據ASPICE流程制定各家專屬的開發流程及各個流程對應產出物；
有一點貫穿整個軟件開發過程，并且在評審過程中也會相當注重的，就是追溯性；
雙向追溯
1)V模型左邊的需求、設計和實現之間
2)V模型左邊的需求設計實現與V模型右邊的測試規范（或測試用例）之間
3)測試用例與測試結果之間
4)變更與變更影響的工作產品之間
因此，除了功能實現，體現追溯性的各環節文檔與工具等要做好記錄與管控，實現符合ASPICE流程的標準化開發。
