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