ASPICE流程的案例
基于ASPICE流程標(biāo)準(zhǔn)的車載電控單元正向開發(fā)研究
基于ASPICE 流程標(biāo)準(zhǔn)
的車載電控單元正向開發(fā)研究
ASPICE 是汽車行業(yè)軟件開發(fā)的流程標(biāo)準(zhǔn)， 可用于提高車載電控單元的研發(fā)質(zhì)量；文章基于 ASPICE 流程 框架， 結(jié)合實際研發(fā)項目及 ASPICE L2 等級認證過程的經(jīng)驗， 闡述了正向開發(fā)過程中各層級交付物的界定及追溯 關(guān)系， 并給出設(shè)計實例， 說明了正向開發(fā)過程中軟、 硬件設(shè)計交付物的承接關(guān)系。
隨著我國汽車自主品牌的發(fā)展， 車載電控單元的自主研 發(fā)成為主機廠的關(guān)鍵技術(shù)之一。為確保電控單元軟、 硬件產(chǎn) 品的設(shè)計質(zhì)量， 產(chǎn)品的正向開發(fā)流程越來越受到國內(nèi)廠商的 重視。
ASPICE 作為汽車行業(yè)內(nèi)軟件開發(fā)的流程標(biāo)準(zhǔn)， 較 CMMI 更適合汽車行業(yè)的軟件開發(fā) [1] ， 難點在于研發(fā)實踐中， 如何對不同層級的交付物進行界定， 如何建立需求與設(shè)計的追溯關(guān)系， 以及如何梳理軟件設(shè)計與硬件設(shè)計的承接關(guān)系。
另一方面， 在正向開發(fā)過程中， 如何將整車功能需求分 解到零部件的設(shè)計要求中， 也是業(yè)內(nèi)探討的熱點， 有研究人 員指出：零件之間構(gòu)成的整車系統(tǒng)的功能實現(xiàn)、 場景描述有 限， 更缺少部分性能指標(biāo)的定義 [2] 。
注：本圖與文無關(guān)，文章轉(zhuǎn)摘自2020年設(shè)計研究，作者廣汽研究院曾備，僅供學(xué)習(xí)參考！
綜上所述， ASPICE 標(biāo)準(zhǔn)中要求的系統(tǒng)開發(fā)流程（SYS）及軟件開發(fā)流程（SWE） 可對應(yīng)到車載電控單元零部件級別 （L3）、 組件級別（L4） 及模塊級別（L5） 的交付物。各層 級的架構(gòu)設(shè)計文檔， 對上層的設(shè)計需求進行了分解， 并根據(jù) 下層的接口關(guān)系進行功能的分配， 進而建立了上下層級設(shè)計 需求的追溯關(guān)系。
展開 ECU電控軟件開發(fā)及測試介紹
基于 AbsInt 的靜態(tài)性能分析
? 客戶收益
· 評估資源使用率，指導(dǎo)芯片選型和工程優(yōu)化
· 保證軟件的任務(wù)、中斷預(yù)留堆棧空間和分配周期合理性
· 保證芯片內(nèi)存占用率和 CPU 負載在閾值范圍內(nèi)
· 開展符合功能安全和 ASPICE 流程要求的測試
? 測試內(nèi)容
· 內(nèi)存：自動化分析最差工況的堆棧用量、RAM/ROM/Flash 占用率
· WCET：分析最差工況下的執(zhí)行時間，測試周期穩(wěn)定性和任務(wù)實時性
· 調(diào)度仿真：模擬任務(wù)調(diào)度，建模仿真 CPU 負載率和任務(wù)占比
? 方案特點
· 借助 AbsInt 工具，針對工程二進制可執(zhí)行文件進行自動化分析，無需依賴源碼
· 支持 PPC、V850、Tricore、ARM 等多種架構(gòu)芯片的堆棧、時間分析
· 分析遍歷工況，結(jié)果涵蓋程序的各個入口
· 圖形化展示最差工況下的執(zhí)行路徑和占比用量，指導(dǎo)性能優(yōu)化
· 不依賴測試用例，執(zhí)行效率高，項目周期短
· AbsInt 工具滿足 ASIL D 等級功能安全標(biāo)準(zhǔn)
基于 AbsInt 的測試流程
函數(shù)調(diào)用關(guān)系及用量顯示
數(shù)據(jù)化表格用量展示
基于 RVS 的動態(tài)性能測試
? 客戶收益
· 在 PIL、HIL、車載環(huán)境下進行時序分析，確保軟件行為安全
· 可視化監(jiān)測任務(wù)調(diào)度和 CPU 負載，為系統(tǒng)升級提供優(yōu)化參考
· 保證多任務(wù)和多核運行的合理性，規(guī)避優(yōu)先級反轉(zhuǎn)、死鎖等時序問題
· 開展符合功能安全和 ASPICE 流程要求的測試
展開 適用于新型電子電氣架構(gòu)的信息安全綜合解決方案
如果按照ASPICE流程要求做條目化，可能所有層級的需求加起來會有幾萬條甚至更多。那我們來看一下這幾個例子。
對于SOA架構(gòu)帶來的問題，其中一條需求是將服務(wù)區(qū)分成安全相關(guān)服務(wù)與非安全相關(guān)服務(wù)，在安全相關(guān)服務(wù)中執(zhí)行雙向身份認證。對于虛擬化帶來的問題，其中一條是使用覆蓋多平臺的自動化漏洞管理系統(tǒng)。對于異構(gòu)計算帶來的問題，其中一條是，盡可能選擇能夠抵抗側(cè)信道攻擊與故障注入攻擊的芯片。條件允許的情況下也可以進行相關(guān)的測試。
對于集成化趨勢誕生的中央行車電腦，具有遠程連接功能的控制網(wǎng)或者通信單元或者是域控制器，由于其在整車架構(gòu)中的重要作用，可以直接把目標(biāo)設(shè)定到最高，也就是參考ISO21434的CAL等級，可以直接設(shè)定到CAL4。所有能做到的需求都上，測試也全上。對于技術(shù)移植帶來的問題，可以這樣考慮。既然ICT領(lǐng)域有這么多現(xiàn)成的工具，為什么不移植過來做測試呢。設(shè)計人員也可以學(xué)習(xí)滲透工具的嘛。比如Kali Linux上面的各種工具，可能已經(jīng)有很多人這樣做了。當(dāng)然，僅限于測試用途。
06
解決方案在整車層級的部署
當(dāng)我們生成了大量的需求，整合層一個大的綜合方案之后。在整車級怎么部署呢？首先還是將需求分層，我們從頂層視角看的時候，會發(fā)現(xiàn)有大量的需求是部署在云端和管端的，而且在云端部署的這些需求，大多都是跨層級跨終端的需求。例如PKI, 漏洞管理系統(tǒng)，IDPS在云端的安全日志分析器等等。然后下一步就是將遠程通信，近場端通信，車內(nèi)通信的通信協(xié)議及安全措施定下來。比如TLS和SecOC。而制定通信協(xié)議類的需求，也是需要從整體考慮的。
展開 敏捷與ASPICE：SDV趨勢下軟件研發(fā)體系的挑戰(zhàn)與思考
那么，ASPICE和敏捷結(jié)合之后的結(jié)果是什么呢？在行業(yè)中，結(jié)果往往是敏捷主導(dǎo)著整個開發(fā)流程，ASPICE流于形式。因為，兩者從“價值觀”上就是沖突的。
了解ASPICE的人就該明白：
ASPICE更加注重文檔：這里的文檔泛指可被第三方檢查的證據(jù)。ASPICE Level1的認證就是根據(jù)你的文檔輸出(outcome)來倒推你是否有按Base Practice干的。如果你沒有這些，Level 1過不了。
ASPICE更加注重流程和計劃，GP(Generic Practice)2.1.1~2.1.6基本講的就是流程、計劃。如GP2.1.6里面寫明了：必須識別、準(zhǔn)備、安排合適的資源來保證流程按計劃的進行。要知道，你想通過ASPICE Level 2的認證，GP2.1.1~2.1.6是必要條件。
另外，實行“敏捷”的一大好處就是“提高客戶滿意度”，你沒事就給客戶交點東西，讓他提意見，然后按他的意見改，他能不滿意嗎？在客戶滿意了之后，還要啥ASPICE啊？
2. ASPICE的種種弊端
ASPICE在汽車行業(yè)很多年了，它的好處大家應(yīng)該都很清楚：它對工程流程覆蓋的非常全面，可以幫助與指導(dǎo)軟件開發(fā)，并提高交付的質(zhì)量。我這里主要講講它的壞處。不過在講這個之前，先講一個笑話和親身經(jīng)歷。
有一個軟件工程師有一天遇到了上帝，上帝跟他說：“我可以滿足你一個愿望”。工程師想了想，說“我想做一個好的項目”。上帝想了想，于是讓這個工程師得到了“永生”。
做為“軟件工程師”，想做一個好的項目實在太難，但我有幸遇到了。大概在2013年時，我和另外5個小伙伴一起做一個TBOX的項目，大概做了3個多月吧，交付給測試，質(zhì)量出奇的好。
展開 
敏捷與ASPICE：SDV趨勢下軟件研發(fā)體系的挑戰(zhàn)與思考
沒有ASPICE認證，很多OEM壓根就不會把項目給你。
然后，來說為什么要用“敏捷”？答案也很顯然，被客戶爸爸們逼的。沒事改需求，交付周期壓縮到巴不得明天就上等等，不“敏捷”怎么活？
那么，ASPICE和敏捷結(jié)合之后的結(jié)果是什么呢？在行業(yè)中，結(jié)果往往是敏捷主導(dǎo)著整個開發(fā)流程，ASPICE流于形式。因為，兩者從“價值觀”上就是沖突的。
了解ASPICE的人就該明白：
ASPICE更加注重文檔：這里的文檔泛指可被第三方檢查的證據(jù)。ASPICE Level1的認證就是根據(jù)你的文檔輸出(outcome)來倒推你是否有按Base Practice干的。如果你沒有這些，Level 1過不了。
ASPICE更加注重流程和計劃，GP(Generic Practice)2.1.1~2.1.6基本講的就是流程、計劃。如GP2.1.6里面寫明了：必須識別、準(zhǔn)備、安排合適的資源來保證流程按計劃的進行。要知道，你想通過ASPICE Level 2的認證，GP2.1.1~2.1.6是必要條件。
另外，實行“敏捷”的一大好處就是“提高客戶滿意度”，你沒事就給客戶交點東西，讓他提意見，然后按他的意見改，他能不滿意嗎？在客戶滿意了之后，還要啥ASPICE啊？
2. ASPICE的種種弊端
ASPICE在汽車行業(yè)很多年了，它的好處大家應(yīng)該都很清楚：它對工程流程覆蓋的非常全面，可以幫助與指導(dǎo)軟件開發(fā)，并提高交付的質(zhì)量。我這里主要講講它的壞處。不過在講這個之前，先講一個笑話和親身經(jīng)歷。
展開 詳解功能安全概念階段
在ISO 26262流程中，概念階段（包括功能安全概念和技術(shù)安全概念）是最重要的階段，這個階段出現(xiàn)的任何紕漏，都會影響后續(xù)的功能安全開發(fā)活動。由于ISO 26262采用的是V模型，概念階段變更引起的工作量會十分巨大。本文希望通過一些重要概念的解釋和實用技術(shù)的說明，理清功能安全概念的過程，幫助功能安全開發(fā)人員，實現(xiàn)正確的功能安全概念。
版權(quán)聲明：本文為CSDN博主「coroutines」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，獲作者轉(zhuǎn)載權(quán)限。
詳解功能安全概念階段
在ISO 26262流程中，概念階段（包括功能安全概念和技術(shù)安全概念）是最重要的階段，這個階段出現(xiàn)的任何紕漏，都會影響后續(xù)的功能安全開發(fā)活動。由于ISO 26262采用的是V模型，概念階段變更引起的工作量會十分巨大。本文希望通過一些重要概念的解釋和實用技術(shù)的說明，理清功能安全概念的過程，幫助功能安全開發(fā)人員，實現(xiàn)正確的功能安全概念。
新能源汽車動力系統(tǒng)部件測試大揭秘
在汽車軟件開發(fā)流程中，開發(fā)和測試成V字型進行，俗稱軟件開發(fā)V模型，感興趣的同學(xué)可以查看汽車軟件開發(fā)流程ASPICE。
統(tǒng)開發(fā)流程中非常強調(diào)測試軟件環(huán)節(jié)的。要知道手機軟件出問題最多也就是秒退而已，車輛軟件出問題影響的是人命。
當(dāng)年豐田剎車門事件，美國政府就派了嵌入式軟件專家和卡耐基梅隆的計算機教授詳細審查了發(fā)動機控制系統(tǒng)的軟件代碼，豐田對全局變量的濫用（上萬個）以及軟件安全機制的混亂就遭到了巨額處罰。如果豐田重視軟件測試工作的話，這件事也許不會發(fā)生。
最后再聊下零部件在整車極限環(huán)境下的測試情況：整車耐久測試這部分工作一般是整車廠的測試&標(biāo)定工程師負責(zé)。整車耐久試驗的花銷很大，造工程樣車（每輛100萬左右）、租用測試場地、工程師團隊花銷，很考驗廠家的資金實力，沒有強大的資金池根本無法運行起來。但在極寒、高溫、高濕度等各種極限環(huán)境下的測試進行的越多，越能充分的驗證零部件的功能、性能以及耐久表現(xiàn)，越早發(fā)現(xiàn)問題，解決修復(fù)所耗費的成本越低。
1. 低溫耐久測試，主要測試?yán)淦饎有阅埽话阍诤诤?#x2F;牙克石進行。電池包的低溫充放電能力、低溫保護策略、電池包加熱功能在該項測試中都會進行考核。
2. 高溫耐久測試，一般在格爾木進行。主要測試電池包在高溫下充放電能力、電池包冷卻功能和過熱保護策略。下圖是蔚來在澳大利亞墨爾本進行高溫測試，為了整車開發(fā)整車廠都是不惜成本。
3. 高溫+高濕環(huán)境耐久測試，一般在海南進行，海水環(huán)境會加速部件腐蝕，零部件的耐久會經(jīng)受嚴(yán)格考驗。（Ps：傳統(tǒng)車還有重要的高原測試，主要測試在低氣壓下發(fā)動機的性能表現(xiàn)。電動車一般不需要進行此項測試。）
電池包做的比較好的都會承諾使用壽命內(nèi)的電池衰減，比如蔚來ES8就承諾10年30萬公里電池容量衰減不超過20%，做電池開發(fā)的都知道做到這個水平是非常不容易的。
展開 基于SOA設(shè)計平臺的技術(shù)難點解析
所有的服務(wù)通過服務(wù)總線或流程管理器來連接。這種松散耦合的架構(gòu)使得各服務(wù)在交互過程中無需考慮雙方的內(nèi)部實現(xiàn)細節(jié)，以及部署在什么平臺上。SOA的細顆粒度、松耦合、服務(wù)可重用及標(biāo)準(zhǔn)化的服務(wù)接口等特性有利于OEM快速推出新功能，靈活迭代，支持軟件定義汽車。利于更多方參與軟件開發(fā)，以O(shè)EM為核心建立汽車生態(tài)系統(tǒng)。同時，精確定義的服務(wù)契約，獨立于硬件、操作系統(tǒng)和編程語言的開發(fā)模式有利于更多方參與軟件開發(fā)，以O(shè)EM為核心建立汽車生態(tài)系統(tǒng)。此外，便捷的云端訪問，服務(wù)于精確封裝，可有效地保證數(shù)據(jù)安全，使得車輛不在是信息孤島，而是物聯(lián)網(wǎng)中的一個節(jié)點，建立了真正的車-云通道。
可以說SOA完美的解決了汽車軟件架構(gòu)面臨的各種挑戰(zhàn)，并且為迎接汽車產(chǎn)業(yè)的變革打下必備的基礎(chǔ)。
SOA車端E/E架構(gòu)設(shè)計要素
SOA的開發(fā)過程相對于傳統(tǒng)開發(fā)模式而言，仍然是以需求為輸入，將需求以全面服務(wù)的模式進行細化，最終將定義的服務(wù)映射到軟硬件架構(gòu)中。
如上圖所示，面向服務(wù)SOA架構(gòu)的基本工作流程包括在底層設(shè)計過程中需要面向?qū)ο筮M行服務(wù)設(shè)計、服務(wù)分組以及服務(wù)映射。其中需要根據(jù)服務(wù)列表及服務(wù)接口設(shè)計服務(wù)，從而根據(jù)功能邏輯將服務(wù)映射值不同的模型，最后以服務(wù)組件到軟件組件（SWC）的映射服務(wù)接口到軟件接口。
SOA在自動駕駛架構(gòu)設(shè)計中需要重點考慮基于服務(wù)設(shè)計的完整性和功能安全設(shè)計的完整性。以標(biāo)準(zhǔn)的ASPICE軟件認證開發(fā)流程為基礎(chǔ)藍本，傳統(tǒng)的開發(fā)流程以系統(tǒng)驗證為SOP節(jié)點，后續(xù)運行維護及上市后不再進行軟件更新，而基于SOA的軟件開發(fā)模式需要在系統(tǒng)驗收后持續(xù)不斷的更新軟件，迭代更多實用性功能，提升已有軟件性能。SOP Release需要包括所有可能的Basic Service，不需要所有的Service都一次開發(fā)完成。
展開 舍與得——主機廠與供應(yīng)商的ASPICE博弈
為了滿足快速開發(fā)快速迭代，那么“Agile”的開發(fā)方式自然就提上議事日程了，用敏捷的方式落地ASPICE，應(yīng)該可以事半功倍吧？
用敏捷的方式如何落地ASPICE呢？
哪些過程域和實踐可以裁剪、任務(wù)的優(yōu)先級如何設(shè)定、如何在裁剪之后仍然能滿足質(zhì)量要求、工具鏈應(yīng)當(dāng)如何選取如何配置如何使用、取舍之下主機廠和供應(yīng)商在哪些方面可以達成共識……，這一系列的問題并沒有因為采取了敏捷得到解決，如果沒有合適的方法論和扎實的落地能力，最終看到的也許只是一地雞毛，什么敏捷，還不如按照原來的做法呢，至少還省掉了白折騰的時間。
有什么方法不白折騰就能部署一套適用的流程么？
很多廠商在一頓折騰后又回到了原點，沒有豐富實踐和方法論的流程咨詢，別說ASPICE和敏捷，任何的流程改進都是空談。而這也是當(dāng)年為什么華為要斥巨資請IBM進行流程咨詢，最終形成了以IPD為代表的一套體系流程實現(xiàn)組織的持續(xù)發(fā)展。
咨詢公司靠譜么？
實際上并不是所有的廠商都如華為有如此財力、魄力引入咨詢公司的流程體系自我革新，況且外來的流程體系還有“水土不服”的風(fēng)險。咨詢公司在流程體系方面固然可能很專業(yè)，但畢竟是外人，對本組織的技術(shù)細節(jié)和業(yè)務(wù)發(fā)展理解有限，就算有了深入理解合同期滿也不再負責(zé)。因而即使請了咨詢公司，內(nèi)部也需要一個團隊負責(zé)流程落地的責(zé)任。例如埃森哲針對汽車電子的開發(fā)，結(jié)合敏捷、ASPICE、功能安全、信息安全等標(biāo)準(zhǔn)和方法論定制出來AutoScrum，在流程部署上倒是面面俱到。
公司內(nèi)部如何建立部署流程的咨詢團隊呢？
展開 