你所在公司的汽車嵌入式代碼質量是如何控制的？

01-14

我是做BMS軟體開發的，很好奇其他零部件供應商對代碼質量的把控是如何做的，我所在的公司只做功能類的測試，感覺不專業啊啊。你所在的公司是如何做的？單元測試？靜態代碼測試？代碼review？
你們用什麼軟體來幫助檢查代碼質量嗎？比如VectorCast或其他？
你們的代碼對MISRA-2004、ISO26262等的遵守程度如何？
你們的底層按AUTOSAR要求的來嗎？

謝邀…..雖然是很久很久以前邀的…

首先肯定是要遵循V型開發的。客戶需求來了以後先會開系統級的研討會。軟體、機械、控制、硬體、安全、品控、測試、系統集成等等每個組都會派人來一起開會討論。軟體組會說大致的解決方案、可能存在的問題/難點等等，並徵求其他組的意見。比如有時候我們不想寫濾波器，就會問機械組能不能多加一個彈簧…

V型開發流程

討論停當以後，軟體組會整理出一個籠統的軟體需求分析，下發到內部的software platform 組開始編製詳細的需求。

platform組在編製需求文檔的同時也會給出測試集，發到我們的外包測試部門去。然後大家擼起袖子把需求拆拆分分，形成若干個小任務、小功能，每人負責一個，就開幹了。

當然，在這些小功能的具體開發過程中，修改測試集甚至修改需求都是免不了的。有了問題我們會反饋給platform組，然後由他們做出相應更新。

自己的功能寫好了，先run QAC 確保符合MISRA-C 規範，有需要的話再run其他動態檢測。然後上板子測試，寫出functional test report，最後更新traceability。都沒問題了就進行peer review。通過以後我們碼農就算交差了。

等大家的小任務都做完了，就會有個牛逼的組長把所有更改集成起來，發布一個新版本的軟體。這個軟體會被送到測試中心去run 測試集。如果都通過了，軟體又會返回來下載到車上測試，也就是vehicle level test。

Vehicle

level test 也沒問題了就要上路測試了。路測包括100英里測試、500英里測試什麼的。一般而言，500英里測試的通過意味著這軟體就可以拿去賣了。我們會正式發布給客戶，下載到量產車裡去。

從接到客戶需求到走完這整套流程，一般需要半年到一年時間。不過，全套做下來以後，可以保證不會有影響駕駛安全的軟體bug出現了。

PS: 其實吧，偶爾偶爾有時候也會違反這套流程…有次某OEM對一個解決方按的測試結果催的實在太緊、等著我們回電話，大老闆就讓我手動改了幾行代碼，直接發到在試車場的同事手裡，尼瑪沒進行任何測試就直接路測了…那次真是嚇尿

我司開發流程規定是必須要提供如下報告的：

1) Peer Review;

2) QAC report;

3) VectorCast Test Report;

4) Function Test Report;

5) Validation Test Report;

但是最後項目究竟是不是完全按這個做的，就要看OEM的要求和項目的緊急程度了。

其中1)到4)是碼農提供，5)是測試人員提供。

最近，為了避免一些共性錯誤的出現，各個模塊又做了一份checklist來把關設計初期會出現的一些問題。

此外，公司也有內部的編碼規範。

我們也在考慮如何減少編碼方面的錯誤，暫時的結論是盡量讓更多的代碼自動生成。

我們是做IPC，感覺德企的開發流程是做的比較好的，嚴格遵循V模型的開發流程。

1.首先從milestone上來說，每一個階段都有嚴格的進入條件，只有滿足了才能進行下一階段。

2.從需求到設計到開發再到測試，都要提供完整的文檔，同時要做好文檔和代碼的trace

3.開發嚴格遵循MISRA-2004，一方面是公司根據MISRA-2004制訂了一套編碼規範，另一方面會有 code review，其次還有代碼分析工具。ISO26262目前不了解遵守程度如何。

4.測試方面，module test是又developer自己搞，integration test是由integrator搞，system test是由測試人員搞，當然相關的report那是必須的。

5.然後工具方面，QAC用來做靜態代碼分析，還有一個內部的工具做測試覆蓋率的檢查。然後還有一系列公司內部開發的代碼自動生成工具和自動測試平台。

6.最後還要做好版本管理和變更管理的工作，使得任何一個需求都能對應到找到設計文檔、代碼、測試用例，以及與OEM澄清的記錄。

簡單說說自動代碼~公司使用的是Ascet，Ascet的模擬功能簡直是渣渣，公司里基本沒有人用。所以和那些使用Simulink建立可以模擬的模型，相信在模型測試方面肯定有很大不同。『

1、畫模型』，必須按照公司規範，比如打包bit位，代碼與變數的儲存區域

1、fdef的peer review，同行審查，能進行review的都是幹了好幾年的系統工程師

2、pit測試計劃，pit測試計劃review

3、pit測試報告，或者使用labcar或者實車測試。

4、發布模塊

我們這完全用自德國佬一套流程開發，包括軟體設計，軟體測試，問題追蹤以及模塊及系統釋放等，這一套流程及其繁瑣，但卻對軟體的質量有極高的保障。

下面列出一些使用或涉及到的工具或軟體：

1. QAC：這個軟體應該很多公司都有用，靜態分析的確能幫助開發者提前發現一些隱藏的問題，我司要求是level6以上的warning必須解決或解釋，底層一些的模塊要求底線是level5。

2. Coverage Test：這個是幫助做代碼覆蓋率測試，需要動態測試，每個模塊或子系統在釋放前必須保證覆蓋率達到一定比例以上，當然代碼寫的不好肯定會備受此軟體的煎熬。

3. Imagix：這個主要是做task之間，甚至與interrupt之間的變數一致性分析，這個一般公司很少會有一款軟體去自動化出report，不過這個report還是很有幫助的。當你在調試程序，怎麼都想不通邏輯會有問題的時候，會不會是其他task或interrupt把你的變數給篡改了呢。

4. DoubleCheck：主要也是靜態分析，類似於QAC，算是給QAC的一個補集吧，主要是報出一些可能存在的問題，數組使用可能越界啦，指針不合理使用啦等問題這玩意都能檢測出來。

5. IDE：什麼？這也算？嗯，待我解釋一下，我司有個team專門維護這個IDE，我覺得他們做的比較好的有兩點，一是用visual studio來做base system的IDE，把代碼編輯，編譯，調試無縫鏈接到VS里，讓你開發嵌入式軟體猶如開發windows app一般，告別source insight，告別運行一個個的腳本；二是上面涉及到的一堆以及我沒有提到的一堆工具，也都無縫插入這個IDE中，你只需點呀點的，就可以得到想要的report啦~

6. JIRA：issue追蹤神器，對軟體開發過程有極好的管理，對問題的追蹤以及team的合作有極強的幫助。

7. FishEye: 代碼review利器，可以和Git關聯起來，自動將新的commit列舉出來，review再也不需要compare之類的工具啦。

就說這麼多吧，這一些些的工具的確對軟體的質量有很大的幫助，當然developer可能就會覺得太繁瑣了，釋放一個模塊居然要跑這麼多的report，但總體來說還是省了不少力，畢竟你只需點啊點的啊。

代碼遵循MISRA是必須的，這個靠QAC之類的工具進行靜態檢查確保代碼不violate MISRA規則，若有不可避免的violation，需要在代碼中進行理由說明。靜態檢查完之後需要提供一個QAC報告。

單元測試一般也有，跟硬體無關的代碼一般在PC端使用embUnit之類的免費框架，有錢的公司也有使用Tessy, Bullseye等商業工具。單元測試有一些metrics, 嚴格點的公司會要求提供code coverage report, 包括C1,MC/DC覆蓋度等。跟硬體相關的代碼一般需要在板子上測試，這種測試目前好像沒有標準的metrics來衡量測試充分性，各個公司可能有不同的要求，一般來講測試要cover掉各個功能需要。對於文檔要求，單元測試一般要求提供兩個文檔：單元測試規範和單元測試報告。

集成測試時必須的，一般放到硬體環境中去測試。常用的工具包括CANalyzer/CANoe/CAPL腳本，這個測試一般要cover掉所有的軟體功能需求。對於文檔要求，集成測試也需要提供兩個文檔：集成測試規範和集成測試報告。

還有個很重要，但一般公司比較忽視的東西：traceability, 這個就是要求系統功能需求，軟體需求，軟體設計，軟體實現，單元測試，集成測試之間要能互相跟蹤。一般比較正規的公司(尤其是德國公司)都有一套私有的tool sets去實現traceability, 通過工具自動生成traceability報告。

針對軟體發布後的後續問題，一般公司都有一套變更管理流程。

總體來說，正規公司的軟體開發流程一般都要達到一定的規範標準，就汽車行業來說，一般要達到Aspice Leve2以上。能不能達到這個標準一般是權威的第三方評估公司說了算。

我們是用心，哦不，用心情控制的

質量是靠流程，工具和開發人員三者共同來控制的。側重點不同，大公司靠流程，中型公司靠工具，小公司靠個人。

替換開發模式，利用matlab或者case工具自動生成代碼，專註於控制模型的驗證或者uml圖的驗證，話說bms的常用開發模式不是simulink自動代碼生成么

我們是做車身控制模塊的，也只是做簡單的功能測試而已！感覺好山寨啊

我說靠經驗你信嗎？

公司說的是按流程，按A-Spice之類的，實際看問題還是靠經驗者的經驗。