導(dǎo)讀：車上現(xiàn)在五花八門的功能應(yīng)接不暇，這些功能是如何從文字版需求變成用戶可以感受到的功能呢？趁疫情在家，閑來無事聊聊軟件需求話題。
首先是需求的來源，對(duì)于車載控制器而言，需求的來源通常有兩個(gè)大途徑，一個(gè)是供應(yīng)商內(nèi)部，比如內(nèi)部各模塊log的存儲(chǔ)方案、任務(wù)調(diào)度策略、參數(shù)管理等；另一個(gè)是主機(jī)廠，這是需求的大頭，有來自法規(guī)對(duì)車輛的要求，也有來自于為了滿足用戶的駕駛需求，還有來自于各試驗(yàn)場(chǎng)測(cè)試反饋問題的變更需求。
主機(jī)廠的兄弟通過與系統(tǒng)工程師(需求工程師)反復(fù)開會(huì)澄清需求，并以正式的方式輸入。然后需求工程師從中提取真正的軟件需求，并且將需求輸入到需求管理系統(tǒng)，比如常用的西門子的Polarion、IBM的Doors等。
為了減少系統(tǒng)工程師與軟件開發(fā)工程師、測(cè)試工程師之間的反復(fù)扯皮，一份合格的需求必須具備以下特性：
1、軟件需求只包含必要描述性、定義性的信息，而不能包含解釋性的內(nèi)容。
2、每條需求都必須是組成某個(gè)功能的最基本單元，不能夠再繼續(xù)分解。
3、每條軟件需求都必須具備可測(cè)試性，意味著有明確的輸入輸出。
一份清晰而又準(zhǔn)確的需求文檔是一個(gè)項(xiàng)目是否優(yōu)秀的基石。
系統(tǒng)工程師需求寫好之后，開始召集相關(guān)的軟件開發(fā)工程師、測(cè)試工程師，進(jìn)行需求的宣導(dǎo)，并且對(duì)齊各方對(duì)需求的理解偏差。這樣需求就交接給他們了。軟件工程師在收到需求后，開始編碼進(jìn)行功能實(shí)現(xiàn)，為了使編碼符合編碼規(guī)范，一方面團(tuán)隊(duì)會(huì)有一份編碼規(guī)范文檔，在入職會(huì)進(jìn)行宣貫，以及考試驗(yàn)收，第二通常會(huì)在IDE中集成靜態(tài)代碼檢查工具來執(zhí)行MISRA C/C++靜態(tài)代碼檢查，保證代碼的質(zhì)量。另外在開發(fā)過程中，難免還需要與系統(tǒng)工程師反復(fù)地確認(rèn)需求。
當(dāng)開發(fā)工程師完成開發(fā)后，就開始反復(fù)地測(cè)試、優(yōu)化過程了。
首先開發(fā)工程師會(huì)進(jìn)行自測(cè)，如果是模型開發(fā)，會(huì)有模型在環(huán)MIL、軟件在環(huán)SIL等仿真測(cè)試。然后會(huì)在單板離線環(huán)境進(jìn)行功能的自測(cè)。
這些測(cè)試OK之后，團(tuán)隊(duì)內(nèi)有個(gè)內(nèi)部的測(cè)試小組，會(huì)對(duì)每條需求進(jìn)行硬件在環(huán)HIL測(cè)試，以及老化測(cè)試，測(cè)試后會(huì)將結(jié)果反饋給開發(fā)工程師，工程師對(duì)FAIL項(xiàng)進(jìn)行確認(rèn)和修復(fù)，然后繼續(xù)測(cè)試，直到所有的需求都測(cè)試通過。
團(tuán)隊(duì)內(nèi)部測(cè)試OK之后，會(huì)出具測(cè)試報(bào)告，然后將測(cè)試報(bào)告和軟件包交給獨(dú)立的測(cè)試部門，進(jìn)行測(cè)試。這里又會(huì)有一個(gè)反復(fù)的過程，比如測(cè)試部測(cè)完之后，如果有測(cè)試FAIL項(xiàng)，會(huì)將測(cè)試結(jié)果反饋給開發(fā)團(tuán)隊(duì)，團(tuán)隊(duì)的開發(fā)和測(cè)試小組會(huì)進(jìn)行FAIL項(xiàng)的確認(rèn)、分析和修復(fù)。團(tuán)隊(duì)內(nèi)部測(cè)試OK之后，再次提交給測(cè)試部測(cè)試。
當(dāng)測(cè)試部測(cè)試完成之后，會(huì)整理測(cè)試報(bào)告和測(cè)試結(jié)果，將軟件釋放給主機(jī)廠。這其實(shí)就是汽車行業(yè)傳統(tǒng)的V模型開發(fā)模式。
圖片來源網(wǎng)絡(luò)
主機(jī)廠收到軟件包之后，會(huì)進(jìn)行簡(jiǎn)單的驗(yàn)收測(cè)試，驗(yàn)收OK之后，將軟件功能描述、供應(yīng)商測(cè)試報(bào)告、驗(yàn)收?qǐng)?bào)告匯總成一份匯報(bào)PPT，在部門會(huì)議上進(jìn)行匯報(bào)，主要目的是申請(qǐng)將測(cè)試軟件釋放到測(cè)試車輛和測(cè)試臺(tái)架上。
會(huì)議同意釋放之后，軟件包和測(cè)試報(bào)告以及會(huì)議記錄會(huì)發(fā)布至主機(jī)廠內(nèi)部的測(cè)試團(tuán)隊(duì)，他們會(huì)將軟件更新到各個(gè)測(cè)試車輛進(jìn)行測(cè)試。
在車型開發(fā)過程中，都會(huì)有大量的測(cè)試車輛在全國(guó)各地跑功能、耐久、道路適應(yīng)性測(cè)試。另外還有大量的測(cè)試件在環(huán)境倉、測(cè)試臺(tái)架進(jìn)行持續(xù)的測(cè)試。
除此之外，還有每年夏季和冬季的標(biāo)定測(cè)試，比如夏季去溫度最高的吐魯番以及海南、進(jìn)行為期幾個(gè)月的測(cè)試，同時(shí)還會(huì)其青海、昆侖山等進(jìn)行高原測(cè)試，冬季則去大東北，漠河或者內(nèi)蒙，進(jìn)行為期幾個(gè)月的冬季測(cè)試。
當(dāng)功能在這些大量的測(cè)試下測(cè)試OK之后，才會(huì)真正的將功能釋放給用戶車輛。
這種長(zhǎng)期的測(cè)試和驗(yàn)收流程，保證了車輛軟件以及功能的可靠性，也是軟件bug少的原因，另外這也是為什么汽車軟件更新很慢的原因，不像手機(jī)軟件，一周給你推送一個(gè)版本，甚至還會(huì)推送開發(fā)者版本給客戶提前嘗鮮，這種對(duì)車輛上核心的駕駛功能控制器來說，這是不可能的。
來源： 汽車ECU開發(fā) eng2mot
