ASPICE流程
關注創建者：匿名 創建時間：2026-01-04
ASPICE流程的實例教程
基于ASPICE 流程標準
的車載電控單元正向開發研究
ASPICE 是汽車行業軟件開發的流程標準， 可用于提高車載電控單元的研發質量；文章基于 ASPICE 流程 框架， 結合實際研發項目及 ASPICE L2 等級認證過程的經驗， 闡述了正向開發過程中各層級交付物的界定及追溯 關系， 并給出設計實例， 說明了正向開發過程中軟、 硬件設計交付物的承接關系。
隨著我國汽車自主品牌的發展， 車載電控單元的自主研 發成為主機廠的關鍵技術之一。為確保電控單元軟、 硬件產 品的設計質量， 產品的正向開發流程越來越受到國內廠商的 重視。
ASPICE 作為汽車行業內軟件開發的流程標準， 較 CMMI 更適合汽車行業的軟件開發 [1] ， 難點在于研發實踐中， 如何對不同層級的交付物進行界定， 如何建立需求與設計的追溯關系， 以及如何梳理軟件設計與硬件設計的承接關系。
另一方面， 在正向開發過程中， 如何將整車功能需求分 解到零部件的設計要求中， 也是業內探討的熱點， 有研究人 員指出：零件之間構成的整車系統的功能實現、 場景描述有 限， 更缺少部分性能指標的定義 [2] 。
注：本圖與文無關，文章轉摘自2020年設計研究，作者廣汽研究院曾備，僅供學習參考！
綜上所述， ASPICE 標準中要求的系統開發流程（SYS）及軟件開發流程（SWE） 可對應到車載電控單元零部件級別 （L3）、 組件級別（L4） 及模塊級別（L5） 的交付物。各層 級的架構設計文檔， 對上層的設計需求進行了分解， 并根據 下層的接口關系進行功能的分配， 進而建立了上下層級設計 需求的追溯關系。
展開 基于 AbsInt 的靜態性能分析
? 客戶收益
· 評估資源使用率，指導芯片選型和工程優化
· 保證軟件的任務、中斷預留堆棧空間和分配周期合理性
· 保證芯片內存占用率和 CPU 負載在閾值范圍內
· 開展符合功能安全和 ASPICE 流程要求的測試
? 測試內容
· 內存：自動化分析最差工況的堆棧用量、RAM/ROM/Flash 占用率
· WCET：分析最差工況下的執行時間，測試周期穩定性和任務實時性
· 調度仿真：模擬任務調度，建模仿真 CPU 負載率和任務占比
? 方案特點
· 借助 AbsInt 工具，針對工程二進制可執行文件進行自動化分析，無需依賴源碼
· 支持 PPC、V850、Tricore、ARM 等多種架構芯片的堆棧、時間分析
· 分析遍歷工況，結果涵蓋程序的各個入口
· 圖形化展示最差工況下的執行路徑和占比用量，指導性能優化
· 不依賴測試用例，執行效率高，項目周期短
· AbsInt 工具滿足 ASIL D 等級功能安全標準
基于 AbsInt 的測試流程
函數調用關系及用量顯示
數據化表格用量展示
基于 RVS 的動態性能測試
? 客戶收益
· 在 PIL、HIL、車載環境下進行時序分析，確保軟件行為安全
· 可視化監測任務調度和 CPU 負載，為系統升級提供優化參考
· 保證多任務和多核運行的合理性，規避優先級反轉、死鎖等時序問題
· 開展符合功能安全和 ASPICE 流程要求的測試
展開 如果按照ASPICE流程要求做條目化，可能所有層級的需求加起來會有幾萬條甚至更多。那我們來看一下這幾個例子。
對于SOA架構帶來的問題，其中一條需求是將服務區分成安全相關服務與非安全相關服務，在安全相關服務中執行雙向身份認證。對于虛擬化帶來的問題，其中一條是使用覆蓋多平臺的自動化漏洞管理系統。對于異構計算帶來的問題，其中一條是，盡可能選擇能夠抵抗側信道攻擊與故障注入攻擊的芯片。條件允許的情況下也可以進行相關的測試。
對于集成化趨勢誕生的中央行車電腦，具有遠程連接功能的控制網或者通信單元或者是域控制器，由于其在整車架構中的重要作用，可以直接把目標設定到最高，也就是參考ISO21434的CAL等級，可以直接設定到CAL4。所有能做到的需求都上，測試也全上。對于技術移植帶來的問題，可以這樣考慮。既然ICT領域有這么多現成的工具，為什么不移植過來做測試呢。設計人員也可以學習滲透工具的嘛。比如Kali Linux上面的各種工具，可能已經有很多人這樣做了。當然，僅限于測試用途。
06
解決方案在整車層級的部署
當我們生成了大量的需求，整合層一個大的綜合方案之后。在整車級怎么部署呢？首先還是將需求分層，我們從頂層視角看的時候，會發現有大量的需求是部署在云端和管端的，而且在云端部署的這些需求，大多都是跨層級跨終端的需求。例如PKI, 漏洞管理系統，IDPS在云端的安全日志分析器等等。然后下一步就是將遠程通信，近場端通信，車內通信的通信協議及安全措施定下來。比如TLS和SecOC。而制定通信協議類的需求，也是需要從整體考慮的。
展開 那么，ASPICE和敏捷結合之后的結果是什么呢？在行業中，結果往往是敏捷主導著整個開發流程，ASPICE流于形式。因為，兩者從“價值觀”上就是沖突的。
了解ASPICE的人就該明白：
ASPICE更加注重文檔：這里的文檔泛指可被第三方檢查的證據。ASPICE Level1的認證就是根據你的文檔輸出(outcome)來倒推你是否有按Base Practice干的。如果你沒有這些，Level 1過不了。
ASPICE更加注重流程和計劃，GP(Generic Practice)2.1.1~2.1.6基本講的就是流程、計劃。如GP2.1.6里面寫明了：必須識別、準備、安排合適的資源來保證流程按計劃的進行。要知道，你想通過ASPICE Level 2的認證，GP2.1.1~2.1.6是必要條件。
另外，實行“敏捷”的一大好處就是“提高客戶滿意度”，你沒事就給客戶交點東西，讓他提意見，然后按他的意見改，他能不滿意嗎？在客戶滿意了之后，還要啥ASPICE啊？
2. ASPICE的種種弊端
ASPICE在汽車行業很多年了，它的好處大家應該都很清楚：它對工程流程覆蓋的非常全面，可以幫助與指導軟件開發，并提高交付的質量。我這里主要講講它的壞處。不過在講這個之前，先講一個笑話和親身經歷。
有一個軟件工程師有一天遇到了上帝，上帝跟他說：“我可以滿足你一個愿望”。工程師想了想，說“我想做一個好的項目”。上帝想了想，于是讓這個工程師得到了“永生”。
做為“軟件工程師”，想做一個好的項目實在太難，但我有幸遇到了。大概在2013年時，我和另外5個小伙伴一起做一個TBOX的項目，大概做了3個多月吧，交付給測試，質量出奇的好。
展開 沒有ASPICE認證，很多OEM壓根就不會把項目給你。
然后，來說為什么要用“敏捷”？答案也很顯然，被客戶爸爸們逼的。沒事改需求，交付周期壓縮到巴不得明天就上等等，不“敏捷”怎么活？
那么，ASPICE和敏捷結合之后的結果是什么呢？在行業中，結果往往是敏捷主導著整個開發流程，ASPICE流于形式。因為，兩者從“價值觀”上就是沖突的。
了解ASPICE的人就該明白：
ASPICE更加注重文檔：這里的文檔泛指可被第三方檢查的證據。ASPICE Level1的認證就是根據你的文檔輸出(outcome)來倒推你是否有按Base Practice干的。如果你沒有這些，Level 1過不了。
ASPICE更加注重流程和計劃，GP(Generic Practice)2.1.1~2.1.6基本講的就是流程、計劃。如GP2.1.6里面寫明了：必須識別、準備、安排合適的資源來保證流程按計劃的進行。要知道，你想通過ASPICE Level 2的認證，GP2.1.1~2.1.6是必要條件。
另外，實行“敏捷”的一大好處就是“提高客戶滿意度”，你沒事就給客戶交點東西，讓他提意見，然后按他的意見改，他能不滿意嗎？在客戶滿意了之后，還要啥ASPICE啊？
2. ASPICE的種種弊端
ASPICE在汽車行業很多年了，它的好處大家應該都很清楚：它對工程流程覆蓋的非常全面，可以幫助與指導軟件開發，并提高交付的質量。我這里主要講講它的壞處。不過在講這個之前，先講一個笑話和親身經歷。
展開 
ASPICE流程的相關專題、標簽、搜索
ASPICE流程的最新內容
基于 AbsInt 的靜態性能分析
? 客戶收益
· 評估資源使用率，指導芯片選型和工程優化
· 保證軟件的任務、中斷預留堆棧空間和分配周期合理性
· 保證芯片內存占用率和 CPU 負載在閾值范圍內
· 開展符合功能安全和 ASPICE 流程要求的測試
? 測試內容
· 內存：自動化分析最差工況的堆棧用量、RAM/ROM
畢竟ASPICE在流程層面只提到了做什么，至于“怎么做則是由各企業的流程體系中定義的。為了滿足快速開發快速迭代，那么“Agile”的開發方式自然就提上議事日程了，用敏捷的方式落地ASPICE，應該可以事半功倍吧？
用敏捷的方式如何落地ASPICE呢？
基于ASPICE 流程標準
的車載電控單元正向開發研究
ASPICE 是汽車行業軟件開發的流程標準， 可用于提高車載電控單元的研發質量；文章基于 ASPICE 流程 框架， 結合實際研發項目及 ASPICE L2 等級認證過程的經驗， 闡述了正向開發過程中各層級交付物的界定及追溯 關系， 并給出設計實例， 說明了正向開發過程中軟、 硬件設計交付物的承接關系。
來源 |
汽車電子與軟件
前言
在軟件定義汽車趨勢下，一方面”快速交付”、“OTA”已成為行業的共識；另一方面“交付質量”雖可適度下降但仍要有底線；這兩者的沖突已超出了傳統的ASPICE研發流程體系的能力范圍，“敏捷開發”是否可以解決這一切呢？
接口的建模在系統設計過程中實施，如ASPICE流程中的SYS.2。
2.3 需求定義技術（Techniques for Specifying Requirements）
概念階段的功能安全需求（Functional Safety Requirement）是后續功能安全開發活動的基礎。
接口的建模在系統設計過程中實施，如ASPICE流程中的SYS.2。
2.3 需求定義技術（Techniques for Specifying Requirements）
概念階段的功能安全需求（Functional Safety Requirement）是后續功能安全開發活動的基礎。
以標準的ASPICE軟件認證開發流程為基礎藍本，傳統的開發流程以系統驗證為SOP節點，后續運行維護及上市后不再進行軟件更新，而基于SOA的軟件開發模式需要在系統驗收后持續不斷的更新軟件，迭代更多實用性功能，提升已有軟件性能。SOP Release需要包括所有可能的Basic Service，不需要所有的Service都一次開發完成。
如果按照ASPICE流程要求做條目化，可能所有層級的需求加起來會有幾萬條甚至更多。那我們來看一下這幾個例子。
對于SOA架構帶來的問題，其中一條需求是將服務區分成安全相關服務與非安全相關服務，在安全相關服務中執行雙向身份認證。對于虛擬化帶來的問題，其中一條是使用覆蓋多平臺的自動化漏洞管理系統。對于異構計算帶來的問題，其中一條是，盡可能選擇能夠抵抗側信道攻擊與故障注入攻擊的芯片。
這個是很多Tier1實踐下的結果，不信的可以自己試試
Traceability——看上去很美的骨感現實：ASPICE幾乎每個流程都會講雙向可追溯性(Traceability)，大部分項目要么就是把所有的需求全部鏈接到一個模塊上，要么就是只拿一個小模塊來做這事。
在汽車軟件開發流程中，開發和測試成V字型進行，俗稱軟件開發V模型，感興趣的同學可以查看汽車軟件開發流程ASPICE。
統開發流程中非常強調測試軟件環節的。要知道手機軟件出問題最多也就是秒退而已，車輛軟件出問題影響的是人命。
