在汽車行業的嵌入式軟件開發怎么確保很低的bug發生率?

本人現在主要從事量產ECU軟件的測試和維護工作,正常的開發流程是按照具體功能變更的點按照V模型做測試,因為我們現在主要做功能增加和變更,實際代碼量很小。我的問題是在ECU軟件開發從0到1的階段,或者說代碼量比較大的階段是如何做測試的呢?同時國內現在很多公司開始做新能源汽車他們是怎么做測試的呢?會按照流程嚴格執行嗎?
一個kebab   (常駐歐洲,去過30個國家)     512018-09-02 21:56:52

目前在軟件開發中保證軟件質量,包括保證低bug發生率的最佳解決方案,就是遵照ASPICE Level3 的質量標準來制定軟件開發流程。

Automotive SPICE的具體內容可以參考以下文檔:

automotivespice.com/fil

目前以我的經驗來看,全球范圍內在ASPICE流程應用上做得最好的是德系廠商,德國人的死板可能也就在這里最有用了。之后魚龍混雜的是美國廠商和歐洲其他廠商,一些比較差的所謂的“老牌歐美車企”在流程上實話說還不如我們領先的自主車企。

最后在流程上進步最快的是國內的自主車企。大概五年前當我首次參與和國內主機廠合作的時候他們還完全沒有流程的概念,講究的只是短期的研發成本和時間,什么軟件版本管理,軟件變更管理只是單靠郵件和本地文件編號。

而五年后的今天,最近和一些主機廠的管理層聊過,他們現在專門設立了軟件流程管理的專家職位和對應的流程工程師團隊,支付百萬年薪招人來建立遵循ASPICE標準的軟件開發流程。


ASPICE的標準本身讀起來會和ISO 26262一樣晦澀,關鍵流程遍布在V模型從左到右,從設計到測試再到項目支持的所有角落。Automotive SPICE告訴了你他的審核標準,也就是告訴車企應該實現什么樣的V模型,展現的是一張最終效果圖。但是和ISO 26262一樣SPICE沒有告訴你的是這些流程具體是什么樣的,也就是怎么實現的問題。這也是為什么不同的車企,有類似的V模型構架,根據SPICE的要求,但是構架中的流程以及流程管理方法卻不盡相同。

截取自ASPICE標準

我個人總結了一下,應用的時候簡略來說只需要記住三個分解之后的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,敬請關注。

新疆25选7历史开奖