傳統(tǒng)整車開發(fā)流程，思路，方法論要研發(fā)一輛不含有輔助駕駛或者低階輔助駕駛（AEB,ESP等）的汽車并沒有想象中那么低效，原因是因為這個級別的開發(fā)往往并沒有本質(zhì)上影響到汽車的傳統(tǒng)構(gòu)成。傳感器比重很低，執(zhí)行器并不需要特殊改造，控制器沒有OTA強需求，應(yīng)用邏輯功能簡單，軟件比重并不高。一切看起來都能應(yīng)對。
無論是軟件上的ASPICE流程還是硬件上的整車開發(fā)流程或者零部件開發(fā)流程，基本都采用了V模型的開發(fā)思路，有嚴(yán)格的質(zhì)量管理體系支撐。硬要說缺點，就是整車開發(fā)周期往往很長。
這里特別要提的就是MBD（Model Based Design）軟件開發(fā)模式，這種模式如果不是汽車航天領(lǐng)域的很少接觸到，和大家知道的C++，C，python代碼開發(fā)有很多區(qū)別。基于模型設(shè)計是一種方法，較之傳統(tǒng)軟件開發(fā)而言，使開發(fā)者能夠更快捷、以更少的成本花費進行開發(fā)。這種開發(fā)方式有很多優(yōu)勢
明確、清晰、唯一，便于交流、便于維護。
-
代碼自動生成，編寫效率高，質(zhì)量高，BUG引入少
-
文檔自動化生產(chǎn)，無需額外撰寫，版本一致性好
-
工具都有完整的功能安全認(rèn)證，滿足車規(guī)質(zhì)量要求
-
有配套流程的完整工具鏈可供使用，效率質(zhì)量都有保障
總的來看，這是一套成熟有效的研發(fā)體系，然而隨著技術(shù)發(fā)展，這種模式開始逐漸行不通了。這些變化表現(xiàn)在硬件，軟件和算法三個層面上，核心的動因都是用戶需求變化頻率的快速提高。
-
造車流程和思路在大體上沒有變化，其周期的縮短，主要得益于電動車零部件數(shù)量的降低，當(dāng)然考慮特斯拉車身和電池的一體化設(shè)計。按照傳統(tǒng)車企的組織架構(gòu)和一般邏輯是永遠(yuǎn)造不出來的。因此造車邏輯同樣有很多變革的方向，只是速度很慢，且在當(dāng)下競爭格局上還沒有這么急迫。
-
電子電氣架構(gòu)，域控制等的研發(fā)流程同樣沒有什么變化，只是產(chǎn)品級別上的開發(fā)思路變化比較劇烈。域控制，OTA升級帶來了集中化的設(shè)計方向。
-
軟件是整個研發(fā)流程變化最劇烈的部分，從流程，工具鏈到應(yīng)用上都產(chǎn)生了巨大變化。核心的動因還是由于代碼量的指數(shù)級增加。另外，代碼的復(fù)雜度也提升了好幾個維度，這導(dǎo)致原有體系流程和工具鏈的失效。
MBD的開發(fā)邏輯首當(dāng)其沖。作為一個夾在MBD和代碼開發(fā)之間的工程師，必須承認(rèn)兩者開發(fā)模式在自動駕駛的研發(fā)上各有優(yōu)勢，MBD開發(fā)的比重會降低，但遠(yuǎn)沒有到消失的地步。
針對面向標(biāo)量的復(fù)雜邏輯計算MBD仍然具有舉足輕重的作用，因此汽車底層邏輯算法在安全芯片的開發(fā)模式選擇仍然優(yōu)先推薦MBD。但是考慮更復(fù)雜的自動駕駛規(guī)則算法的開發(fā)以及深度學(xué)習(xí)算法的開發(fā)，MBD方式就表現(xiàn)出了很多軟肋，其靈活性無法滿足上述兩種算法的開發(fā)要求。
因此這些應(yīng)用開始使用傳統(tǒng)互聯(lián)網(wǎng)公司都使用的“代碼編寫”的開發(fā)方式。由此也引入了互聯(lián)網(wǎng)思維下的工具鏈。其中基于Devops的開發(fā)流程框架被引入自動駕駛的研發(fā)。針對更加復(fù)雜的基于深度學(xué)習(xí)的算法開發(fā)，還引入了更深層次的自動化數(shù)據(jù)處理閉環(huán)平臺，作為Devops架構(gòu)的深入。如果devops是為了讓工程師更好的控制代碼質(zhì)量并提升效率。那自動化數(shù)據(jù)處理閉環(huán)平臺進一步希望通過自動化的優(yōu)化流程，降低工程師的參與，進一步提高性能和效率。
工業(yè)領(lǐng)域V模型的開發(fā)思路也在被挑戰(zhàn)，混合V模型流程以及敏捷開發(fā)流程的自動駕駛軟件開發(fā)流程正在被更多討論。我們不僅希望我們的流程可以保障軟件的發(fā)布質(zhì)量，還希望這個流程可以讓軟件發(fā)布的速度更快，簡單來說就是”在籠子里跳舞”。
從更加宏觀的層面上，整車開發(fā)各個層面上的生命周期也在發(fā)生著劇烈變化，原來軟件開發(fā)往往在整車生產(chǎn)環(huán)節(jié)就完成了鎖定，SOP后更不可能再發(fā)生變化。這種開發(fā)邏輯給自動駕駛帶來了不少負(fù)面影響。本質(zhì)原因是整車開發(fā)流程給軟件預(yù)留的時間往往只夠一些簡單邏輯的開發(fā)。過去這不是問題。但面對更加復(fù)雜的自動駕駛軟件，這個周期往往是不足的，不僅對于開發(fā)本身，測試的時間也同樣無法滿足。如果按照傳統(tǒng)流程處理，自動駕駛永遠(yuǎn)無法交付。
但OTA升級改變了這個現(xiàn)狀，軟件的生命周期得到延續(xù)，可以在整車發(fā)布之后，繼續(xù)對軟件功能進行必要的升級。這是一個區(qū)別于傳統(tǒng)的汽車的典型特征。也給自動駕駛車留出了必要的時間。
另外通過對用戶數(shù)據(jù)的搜集，自動駕駛的算法改進獲得了持續(xù)不斷的燃料，為后續(xù)算法的開發(fā)提供了寶貴的素材。過去這些數(shù)據(jù)都必須通過大規(guī)模的內(nèi)部路測來獲得，且質(zhì)量和規(guī)模遠(yuǎn)不及客戶帶來的。用戶營運和用戶畫像分析同樣從這種機制中獲得收益。這些數(shù)據(jù)應(yīng)用使軟件開發(fā)平臺和數(shù)據(jù)閉環(huán)平臺的生命周期普遍延長到了整個車輛的使用周期,甚至很多跨越了多個平臺的使用周期。
汽車行業(yè)出生的軟件工程師看到這些估計得流淚，但時代發(fā)展確實快過我們的想象，一起努力吧。
轉(zhuǎn)載汽車電子相關(guān)文章
轉(zhuǎn)自汽車電子與設(shè)計
上海創(chuàng)程
