在汽車行業的嵌入式軟體開發怎麼確保很低的bug發生率？
目前在軟體開發中保證軟體質量，包括保證低bug發生率的最佳解決方案，就是遵照ASPICE Level3 的質量標準來制定軟體開發流程。
Automotive SPICE的具體內容可以參考以下文檔：
http://www.automotivespice.com/fileadmin/software-download/Automotive_SPICE_PAM_30.pdf目前以我的經驗來看，全球範圍內在ASPICE流程應用上做得最好的是德系廠商，德國人的死板可能也就在這裡最有用了。之後魚龍混雜的是美國廠商和歐洲其他廠商，一些比較差的所謂的「老牌歐美車企」在流程上實話說還不如我們領先的自主車企。
最後在流程上進步最快的是國內的自主車企。大概五年前當我首次參與和國內主機廠合作的時候他們還完全沒有流程的概念，講究的只是短期的研發成本和時間，什麼軟體版本管理，軟體變更管理只是單靠郵件和本地文件編號。
而五年後的今天，最近和一些主機廠的管理層聊過，他們現在專門設立了軟體流程管理的專家職位和對應的流程工程師團隊，支付百萬年薪招人來建立遵循ASPICE標準的軟體開發流程。
ASPICE的標準本身讀起來會和ISO 26262一樣晦澀，關鍵流程遍布在V模型從左到右，從設計到測試再到項目支持的所有角落。Automotive SPICE告訴了你他的審核標準，也就是告訴車企應該實現什麼樣的V模型，展現的是一張最終效果圖。但是和ISO 26262一樣SPICE沒有告訴你的是這些流程具體是什麼樣的，也就是怎麼實現的問題。這也是為什麼不同的車企，有類似的V模型構架，根據SPICE的要求，但是構架中的流程以及流程管理方法卻不盡相同。
我個人總結了一下，應用的時候簡略來說只需要記住三個分解之後的V模型。
一個是遵循ASPICE的組織構架上的「倒V"
如果要滿足ASPICE Level3的要求，我們不僅要有一套完整的軟體開發流程，還必須有這個流程的監督者和流程的管理者。
- PM和PM所領導的所有軟體工程師將是這個流程的使用者，會將所有相關的流程，比如Concern&Change Mangement， Configuration Management 從始至終應用在項目中。
- QM和QM所領導的QA將是這個流程的監督者，他們將會監督是否小到每個軟體的變更到每版可以用於公共道路測試的軟體都是按照相關的流程來嚴格實現的。比如是否有對應的軟體修改分析文檔，是否有具體的修改細節記錄，是否有對應的測試報告，是否有具體的版本追溯，是否和需求閉環，是否有層層Review。在整車開發中每次過」質量門「的時候都是QM和QA集中檢查流程應用是否合規的重要節點。
- Process manager和Process Engineer將是整個流程的制定和維護者。滿足ASPICE Level3要求的流程不僅需要有流程本身，還需要有一個管理流程的流程（是不是聽起來很拗口）。這就需要有一個專門管理軟體開發流程的部門，負責制定一套管理流程的方法論。比如如何改進流程，如何接收流程使用者PM和流程監督者QM的反饋。
第二個V也是ASPICE軟體開發流程中最重要的部分，就是具體可以被應用在軟體開發過程中的每個細分"流程」：
可以是每個軟體開發步驟需要遵循的指導文檔，也可以是軟體開發每個步驟會用到的模板。
上圖中我舉例了一下流程，比如：
我們用的最多的流程是軟體修改流程。
在任何一個或大或小的軟體修改或者新軟體的編寫過程中我們都必須經過關鍵的幾步：軟體修改前的分析（會用到具體的分析文檔） ---> 是否進行軟體修改的決策（會有具體的決策者定義和具體的審批流程） ----> 軟體修改流程 （會有具體的基於模型設計的語法規範，以及具體的Review模板） ----> 軟體修改之後的測試流程（會有具體的測試步驟，每個測試結束需要使用的測試報告模板），等等。。。
上面提到的這個，只是眾多流程中的一個非常細小的部分。
第三個V，也是最為「技術」的一部分，就是和上面第二個V搭配的各種軟體工具。
我們會在軟體開發流程中定義具體每一步需要使用哪些工具，生成具體哪些內容。
- 在軟體開發的初始階段，我們需要使用DOORS或者Integrity來生成軟體需求。
- 在基於模型的軟體設計階段我們會根據具體軟體類型和應用需求使用Simulink+Simulink Coder，或者Simulink+Targetlink或者ASCET來編寫軟體。
- 而在軟體編寫之後，測試之前，我們會用Simulink V&V，以及MXAM這樣的工具來做靜態代碼檢查。
- 最後在軟體測試階段，我們又會有具體的基於Simulink的模擬測試以及SiL測試，還有有基於PiL台架或者HiL台架的實時測試，或者基於整車使用INCA和CANape，CANalyzer的整車測試。
最後要回答題主的一個細節問題，就是理論上來說，不論是從0開始設計的軟體，還是簡單的軟體變更，都需要嚴格依照上面提到的三個"V"來操作。
這樣做的好處非常明顯：可以保證軟體質量，避免量產後的產品缺陷和各種昂貴的召回。但是短期的缺點卻更加顯眼：需要比所謂的「快速開發」多花兩倍到三倍的人力物力財力和時間，量產項目中絕對無法「速成"。
至於現在眾多公司在流程上的應用情況，以我個人的經驗，就是最為嚴謹的老牌車企也很難做到100%嚴格按照流程辦事，哪怕流程本身已經滿足ASPICE要求。而國內自主車企雖然上升速度快，但是對於流程的管理和實現大多還處在沒有認證的試探階段。至於專註新能源的新車企，國內的先不說了，我曾經接觸過一個歐美的新能源車企，目前屬於專心讓車型上市，對於流程暫時有心無力的階段。
其他關於軟體流程的內容，也可以參考我以前的一場Live：
車載控制軟體設計：從需求到量產如果有細節問題的可以在評論中繼續討論。年底前如果有時間的話我也會再單獨組織ASPICE和ISO 26262這兩個標準具體實現步驟和應用細節的Live，敬請關注。