本文來源：智車科技

軟件定義汽車（Software Defined Vehicles, SDV）這個(gè)話題，已經(jīng)算是老生常談了。尤其是汽車新四化技術(shù)不斷發(fā)展的這幾年，軟件定義汽車這個(gè)話題在不同的場合被人們提及和重申。當(dāng)然，也有一些文章、一些人群表示了不同的觀點(diǎn)，認(rèn)為該表述有些以偏概全、夸大其詞的意味。那實(shí)際情況又是什么樣的呢？可能很多人是會(huì)有一些疑問，比如：為什么是軟件定義汽車？軟件如何定義汽車？誰來定義軟件？

其實(shí)對于前兩個(gè)問題業(yè)內(nèi)已經(jīng)有較為普遍的共識：汽車產(chǎn)業(yè)經(jīng)過上百年的發(fā)展，發(fā)動(dòng)機(jī)、底盤、懸架、座椅、車身這些傳統(tǒng)的部分已經(jīng)很難在做出什么新花樣了，與之對應(yīng)的投入也逐漸減少。而在軟件相關(guān)開發(fā)成本上加大投入，需求量也在不斷擴(kuò)大。決定未來汽車的是以人工智能為核心的軟件技術(shù)，而不再是汽車的馬力大小，是否真皮沙發(fā)座椅，機(jī)械性能好壞。因此，軟件定義汽車是大勢所趨，即通過軟件來表達(dá)汽車這一產(chǎn)品的很多特性、功能、服務(wù)成為一種趨勢。

圖 單車平均代碼長度變化

今天筆者最想分享的是前面提到的第三個(gè)問題：既然軟件定義汽車，那究竟誰來定義軟件？

這里不賣關(guān)子，先直接亮明筆者的觀點(diǎn)：軟件定義汽車，需求定義軟件。為什么呢？下面是筆者的一些拙見。

為什么是“需求”？

在這里先講一個(gè)筆者親歷的故事：在筆者從業(yè)的最開始幾年一直埋頭研究算法，然后搭建模型（主要基于simulink）,最后基于快速原型系統(tǒng)上車驗(yàn)證。當(dāng)時(shí)的工作狀態(tài)是真的好：自己搞算法調(diào)研、自己設(shè)計(jì)算法、用simulink搭建模型實(shí)現(xiàn)、再通過快速原型設(shè)備上車進(jìn)行驗(yàn)證……實(shí)現(xiàn)自己想要功能時(shí)，真的是發(fā)自內(nèi)心的自豪和開心。每天早上上班真的想趕緊去公司向領(lǐng)導(dǎo)匯報(bào)昨天的成果，那種狀態(tài)真的是好極了！但是這種狀態(tài)有一天被改變了。

一次團(tuán)隊(duì)從GM挖來一位資深的汽車動(dòng)力學(xué)控制的專家，當(dāng)時(shí)筆者負(fù)責(zé)運(yùn)動(dòng)控制模塊的算法出現(xiàn)了一點(diǎn)棘手的問題需要解決。那位專家剛來的第一天領(lǐng)導(dǎo)便安排這位專家與我進(jìn)行了溝通，簡單的寒暄之后我們的聊天進(jìn)入正題。那位專家問出了第一個(gè)問題：咱們現(xiàn)在的需求是什么，有文檔嗎？面對這個(gè)問題有些不知所措，因?yàn)楫?dāng)時(shí)我們的開發(fā)似乎沒有什么明確的需求，只是想到哪做到哪。

其實(shí)在此之前看到過一篇mathwork高級應(yīng)用工程師董淑成的文章，是關(guān)于MBD（基于模型的開發(fā)）開發(fā)的，里面講到汽車的“V”流程開發(fā)，講到了系統(tǒng)需求、軟件需求，如何進(jìn)行單元測試、集成測試以及如何形成開發(fā)工作的閉環(huán)反饋。

展開來說，如果你的團(tuán)隊(duì)完全是嚴(yán)格按照“V”進(jìn)行正向開發(fā)的話，當(dāng)系統(tǒng)需求分析沒有完成或沒有通過集體評審的話，是無法進(jìn)行系統(tǒng)架構(gòu)設(shè)計(jì)的。但是，實(shí)際中真的是這樣嗎？當(dāng)然不是，這種完全一步一個(gè)腳印，按部就班的開發(fā)過程在實(shí)際中幾乎是不存在的，受到項(xiàng)目周期的約束和版本快速迭代的壓力，很多工作往往都是同步進(jìn)行，交叉開展的。舉個(gè)例子：當(dāng)系統(tǒng)工程師把系統(tǒng)需求分析搞完并編寫出初版“***系統(tǒng)需求文檔”時(shí)，即便這個(gè)時(shí)候文檔并未完成評審和釋放，架構(gòu)師也可以開始進(jìn)行架構(gòu)設(shè)計(jì)了，在后面需求評審中如有某些變化架構(gòu)設(shè)計(jì)可以基于變化進(jìn)行相應(yīng)的微調(diào)即可，這樣不斷迭代循環(huán)完成設(shè)計(jì)。這是需求的在”V”流程中左側(cè)過程的意義，當(dāng)然也是對于軟件開發(fā)的意義。

再來看”V”流程右側(cè)的測試過程，在這一過程中是對左側(cè)工作成果的確認(rèn)和驗(yàn)證，也就是保證“開發(fā)做了正確的事和正確的做了事”。對于不同層級的測試過程，都需要基于需求去展開測試，測試工程師的測試用例不是憑空捏造和主觀臆斷的，而是有理有據(jù)的。有多少條需求，就要針對這些需求設(shè)計(jì)相應(yīng)的測試用例來驗(yàn)證它。當(dāng)然，并不是有N條需求就對應(yīng)N條測試用例，有可能一個(gè)需求需要多個(gè)測試用力來驗(yàn)證，這就是測試覆蓋度。因此，在“V”流程的右側(cè)工作過程中仍然離不開“需求”，軟件開發(fā)正確與否測試人員直接是看不出來的，必須要基于你的需求文檔來逐條驗(yàn)證才行。所以有的時(shí)候工程師往往會(huì)出現(xiàn)“補(bǔ)文檔”的情況。單從“補(bǔ)文檔”這一非正規(guī)操作來看，就足以說明需求必不可少，就更不要說嚴(yán)格按照正向研發(fā)流程展開的軟件產(chǎn)品開發(fā)工作了。所以，當(dāng)上面那位專家提出那個(gè)問題的時(shí)候，我再一次意識到了需求的重要性。

隨著對”V”流程的不斷理解，加之在后面的工作、培訓(xùn)以及與不同層次的人的溝通中對需求這一概念的不斷理解，慢慢認(rèn)識到需求才是開發(fā)的源頭、邊界、目標(biāo)，需求才是核心。因此，才有了我開始的回答。在產(chǎn)品開發(fā)中，很多時(shí)候會(huì)忽略需求的重要性而過于強(qiáng)調(diào)某項(xiàng)技術(shù)。實(shí)際技術(shù)是為產(chǎn)品服務(wù)的，而產(chǎn)品又是由需求來定義的。回到我們的問題：誰來定義軟件？如果回答不是需求那還能是什么呢？在汽車嵌入式系統(tǒng)開發(fā)流程中，從系統(tǒng)需求到子系統(tǒng)需求到硬件需求、軟件需求，這一過程既是設(shè)計(jì)與開發(fā)的過程，又是需求不斷細(xì)化和深入的過程。任何一個(gè)工作過程都是在上一層需求的基礎(chǔ)上展開開發(fā)，如果某一工作過程偏離、超出甚至脫離了上一層的需求，哪這一工作將出現(xiàn)極大風(fēng)險(xiǎn)并失去意義，進(jìn)而對整個(gè)產(chǎn)品開發(fā)造成巨大損失。

以上是筆者一些粗淺的觀點(diǎn)和認(rèn)識。既然需求如此之重要，那如何進(jìn)行需求開發(fā)呢？

需求怎么定義

談到到需求開發(fā)，筆者立馬想起自己在工作中認(rèn)識的一位外國朋友Chakri。他是一位來自印度的軟件工程專家，是他讓筆者第一次較為系統(tǒng)的了解需求開發(fā)。第一次與他交流時(shí)，我用極其貧瘠的英文詞匯和他展開對話。但我令我驚奇的是他總能第一時(shí)間理解我想表達(dá)的內(nèi)容，并給與回答和補(bǔ)充。那次交流使我對需求開發(fā)有了全面且系統(tǒng)的認(rèn)識，并從此開啟了我的“正規(guī)”開發(fā)之路。

說到需求開發(fā)，就必須了解需求工程。需求工程包括兩部分工作過程：需求開發(fā)和需求管理。

需求工程是指應(yīng)用已證實(shí)有效的技術(shù)、方法進(jìn)行需求分析，確定客戶需求，幫助分析人員理解問題并定義目標(biāo)系統(tǒng)的所有外部特征的一門學(xué)科。它通過合適的工具和記號系統(tǒng)地描述待開發(fā)系統(tǒng)及其行為特征和相關(guān)約束，形成需求文檔（需求規(guī)格說明書），并對用戶不斷變化的需求演進(jìn)給予支持。

對于需求管理我們先不展開，因?yàn)樗�涉及到一些�?xiàng)目管理的內(nèi)容，這里主要講需求開發(fā)。

在進(jìn)行需求開發(fā)時(shí)，對于一個(gè)產(chǎn)品或系統(tǒng)而言，需求是分不同層級的。一般來說分：業(yè)務(wù)需求、用戶需求和系統(tǒng)需求，系統(tǒng)需求往下細(xì)分又可以分為不同的子系統(tǒng)需求。對于自動(dòng)駕駛系統(tǒng)開發(fā)來說，子系統(tǒng)需求一般包含：硬件需求和軟件（應(yīng)用軟件）需求。硬件需求通常指的是對域控制器的需求，用于指導(dǎo)、約束、定義控制器的開發(fā)；軟件需求指的是對感知、定位、預(yù)測、規(guī)劃、控制等模塊整體的需求，用于指導(dǎo)、約束、定義軟件系統(tǒng)的開發(fā)。

這里的軟件需求一定是對于整個(gè)系統(tǒng)的需求而不是對某個(gè)模塊而言的。為什么去這樣強(qiáng)調(diào)，原因是在需求開發(fā)時(shí)需求工程時(shí)很容易混淆需求邊界，導(dǎo)致將系統(tǒng)需求、子系統(tǒng)需求、模塊需求混為一談。理解需求層級邊界的一個(gè)很好理解解釋就是在定義某一層需求時(shí)將這個(gè)系統(tǒng)或模塊看作是一個(gè)黑盒子，只關(guān)心它對外提供什么功能或服務(wù)，而不要關(guān)心它是如何實(shí)現(xiàn)的。拿系統(tǒng)需求開發(fā)中的簡單例子，如：“在不具備換道條件時(shí)，系統(tǒng)應(yīng)控制車輛保持在車道中心行駛”。這里我們暫且不去細(xì)究這條需求描述的準(zhǔn)確性，單從“黑盒”理念（暫且這兒叫）來看，這條需求是符合的。到這里我們可以得出一個(gè)結(jié)論：在不同層級需求開發(fā)的過程中其實(shí)就是在定義這個(gè)系統(tǒng)（子系統(tǒng)、模塊）的功能、特性、邊界。

說完了需求分層理論，這里再聊一個(gè)更重要的東西：需求的特性。換句話說就是什么樣的需求才是規(guī)范的需求，優(yōu)秀的需求。這一點(diǎn)對于需求開發(fā)者、對于研發(fā)工程師，甚至對于每一個(gè)產(chǎn)品相關(guān)的人員來說都很重要。通常來說需求應(yīng)具備以下特性：

①　完整性：完整描述每項(xiàng)需求的功能

②　正確性：經(jīng)過用戶和用戶代理人的審閱

③　可行性：在已知能力和約束條件中實(shí)現(xiàn)

④　必要性：每項(xiàng)需求功能都隱私用戶正真需要的

⑤　無歧義：對所有讀者只有一種一致的解釋

⑥　無交叉重疊：在不同的需求功能中沒有重復(fù)的內(nèi)容

⑦　可驗(yàn)證性：可以設(shè)計(jì)測試方法來監(jiān)察

⑧　正確的詳細(xì)層次：不同需求層次的結(jié)構(gòu)要清晰

⑨　劃分優(yōu)先級 ：提供了實(shí)現(xiàn)優(yōu)先的次序

⑩　與實(shí)現(xiàn)無關(guān)性：與后續(xù)的設(shè)計(jì)開發(fā)如何實(shí)現(xiàn)無關(guān)

用來自GM專家的話說：需求開發(fā)的精細(xì)程度要達(dá)到每條需求對應(yīng)這一行代碼。這句話我仍然記憶猶新。

說了這么多，我們拿兩個(gè)常見的feature來看一下需求是如何定義的。

從以上的需求列表中我們可以看到，雖然這是系統(tǒng)級的需求，但很大程度上這些需求已經(jīng)對軟件的設(shè)計(jì)進(jìn)行一定程度定義和約束。那進(jìn)一步的如果到達(dá)模塊級的需求講把軟件模塊的功能和邊界定義的很清楚。我們再來再來看幾個(gè)軟件模塊的需求：

Req1:橫向控制模塊應(yīng)輸出目標(biāo)方向盤轉(zhuǎn)角作為控制量。

Req2:橫向控制模塊應(yīng)將最終輸出的目標(biāo)轉(zhuǎn)角值限制在[-500,500]度以內(nèi)。

Req3:橫向控制模塊應(yīng)將目標(biāo)轉(zhuǎn)角的變化率限制在[-300,300]度每秒以內(nèi)。

Req4:橫向控制模塊應(yīng)對目標(biāo)轉(zhuǎn)角進(jìn)行低通濾波處理以消除信號抖動(dòng)。

看到上面的這幾條需求是不是已經(jīng)很細(xì)化了，基本上達(dá)到了需求的最理想狀態(tài)：每一條需求可以對應(yīng)一行代碼。沒錯(cuò)，需求寫到這個(gè)程度已經(jīng)很不錯(cuò)了，這樣軟件代碼是不會(huì)存在無緣無故的多寫和少寫的。這就是需求定義軟件的真諦！

換句話說，只要需求寫清楚了，那么產(chǎn)品也就清楚了、軟件也就清楚了，最終不管是用什么算法、什么語言去開發(fā)其結(jié)果都是可預(yù)見的。

免責(zé)聲明：

凡本公眾號注明“來源：XXX（非智車科技）”的作品，均轉(zhuǎn)載自其它媒體，轉(zhuǎn)載目的在于傳遞和分享更多信息，并不代表本平臺贊同其觀點(diǎn)和對其真實(shí)性負(fù)責(zé)，版權(quán)歸原作者所有，如有侵權(quán)請聯(lián)系我們刪除。

       原文標(biāo)題 : 軟件定義汽車，那誰來定義軟件？