作者介紹：何先生，某汽車公司，前標定工程師，現汽車軟件工程師
前幾天在知乎回答了一個關於汽車軟件行業的問題，講述汽車行業的“寫代碼”的一些習慣，引來了不少爭議，因此今天在這兒談談軟件在汽車行業的現狀。
之前有人問我，汽車行業也有碼農嗎？確實，以前機械控制的時代，汽車行業確實沒有碼農一說，不過現在都進入電控時代好多年了，而且隨著電氣化、智能化的深入發展，汽車行業對軟件工程師的需求也越來越大。
首先要明確的是，汽車軟件屬於嵌入式軟件開發，跟互聯網行業軟件開發差別很大。
汽車軟件開發特點
一：基於模型的開發MBD
MBD的全稱是Model Based Design，基於模型設計能夠節省開發時間和成本。MBD 的主要優勢在於：
1， 圖形化設計
汽車軟件大部分是基於模型的軟件開發。這一點在大公司尤為明顯，我們用Simulink將要實現的邏輯用圖像的形式表現出來。圖形化的設計邏輯明確、清晰，便於交流和維護。對於代碼的第一任作者以及以後可能的作者，他們只需要看懂圖形，就能知道代碼實現了什麼功能。而如果不看圖，要去重新翻閱成千上百行代碼，非常耗時。
對於軟件工程師來說，最重要的任務是算法的實現。比如我現在有一個自適應巡航系統，汽車需要根據前車位置、速度來決定自己的跟車速度，以及要不要切換跟車目標，這些“做出決策”的過程就是邏輯判斷，都需要工程師設計。
2， 代碼自動生成
在模型開發裡，圖像化的算法最後依靠工具來自動生成代碼。代碼效率明顯提高，手工代碼耗費時間長，且容易出差錯。自動代碼只要工具好使，就不會有差錯，比手工代碼質量高。
二：代碼書寫標準統一
無論軟件是自動代碼生成還是手工書寫，都需要遵循一定的標準。汽車行業為了規範軟件形式，提出了很多統一的代碼書寫標準，比如我們熟知的MISRA標準。
MISRA C Coding Standard是一個工業標準的C編程規範，全稱是 (The Motor Industry Software Reliability Association 汽車工業可靠性聯合協會) ，成員包括了大部分的歐美汽車廠商。
這個標準包括了大概100多條C語言編碼標準，目的是為了幫助汽車廠商開發出安全、高可靠性的嵌入式軟件。有些編碼標準讓其他行業碼農看上去都覺得可笑，比如mi下面這幾條：
Rule 1: 不得使用三元操作符；
Rule2： 所有標識符不得超過31字符；
Rule3：不得殘留被註釋掉的代碼；
Rule4：不得使用goto以及continue；
如果完全按照這個標準來書寫代碼，則你的代碼是可讀性強、可靠、可移植性強和易於維護的。遵循這個標準對於代碼的質量也能起到很好的管理作用，不過Misra標準過於嚴苛，一般企業都會根據實際情況執行。
三：軟件架構的統一
代碼編寫有規範，軟件架構就更有統一規範了。
這就是AUTOSAR(AUTOmotive Open System Architecture 汽車開放系統架構)。
AUTOSAR聯盟由歐美主要汽車廠商成立，致力於為汽車工業開發一套支持分佈式、功能驅動的汽車電子軟件開發方法和軟件架構標準化方案。也是為了應對越來越複雜的汽車電子系統，在電動化，智能化背景下，汽車ECU日益增多，迫切需要一套全新的整車軟件設計標準來應對複雜的設計，使基本的軟件元素、接口和總線系統能夠實現標準化，降低開發成本。
通過AUTOSAR架構，整車軟件對車載網絡，系統內存及總線的診斷功能進行深度管理。AUTOSAR的分層設計目標主要有三個：
1， 建立獨立於硬件的分層軟件架構；
2， 為實施應用提供方法論，包括制定無縫的軟件架構堆疊流程並將應用軟件整合至ECU；
3， 制定各種車輛應用接口規範，作為應用軟件整合標準，方便軟件構件在不同汽車平臺複用。
AUTOSAR整體框架為分層式設計，以中間件RTE為界，隔離上層的應用層以及下層的基礎軟件層。
AUTOSAR的優點在於可以模塊化設計，並將“配置”的理念深入到軟件開發中，真正讓軟件變成可設計的、能即插即用的軟件結構。
汽車行業與互聯網行業軟件開發區別
經常看到一些觀點說汽車行業是傳統行業，保守；互聯網行業是新興行業，創新有活力。就連同為造車的新勢力公司都忙著和傳統汽車企業撇清關係。
“相比互聯網行業軟件能夠快速迭代開發、遠程升級，汽車行業只能按部就班走流程來設計軟件，因此汽車嵌入式軟件是為互聯網的碼農所不齒的。”
但是，有這樣想法的人大概是不瞭解汽車行業軟件開發。
想來想去，兩個行業的軟件最大的區別是什麼？是代碼數量還是架構不一樣嗎?這些只是技術層面的東西，我覺的是汽車軟件更側重安全和可靠性。
互聯網的軟件，如果有bug，只需要後臺進行推送更新升級就行，頂多造成使用不方便，一般不會有人身事故和財產損失。而汽車軟件是容不下一個Bug，以及任何有歧義的代碼。汽車軟件有問題輕則會影響汽車正常使用，重則會造成生命財產安全。
而且，汽車軟件造成的問題後期保養維護很麻煩，需要安排大量人力物力進行售後，這對於汽車公司都是巨大的財產損失。
所以汽車軟件必須小心翼翼，按照以下方法來幹活：
·使用自動代碼，因為機器往往比人靠譜，不太會犯錯；
·即使手工代碼，也嚴格按照汽車行業標準來書寫，保證沒有歧義，沒有意外的情況發生；
·在開發過程中，我們也按照ASPICE流程來指導我們的開發和測試，保證軟件符合需求，並且質量過關；
·同時，汽車軟件還有功能安全來進行冗餘設計，防止軟件可能的故障而造成無可挽回的後果。
這也就是因為汽車軟件開發有這麼多條條框框需要遵守，每一個軟件使用前都有這麼多流程需要走完，因此，汽車軟件基本就跟“快速響應”、“迭代開發”這些名詞無緣了。
所以我們一直被造車新勢力稱為“傳統造車企業”。
汽車行業軟件工程師都是些什麼人
目前汽車行業無論是傳統ECU開發，還是混動/電動控制器/自動駕駛都離不開軟件工程師。不過汽車行業的碼農不同於其他行業，這個行業要求碼農們不僅僅要精通代碼，還要有以下技能樹：
1， 對汽車/受控系統要十分了解。無論是傳統車還是自動駕駛系統，都需要對汽車有一定的瞭解，不然無法開發控制算法。而汽車又是個十分複雜的機械系統，不是臨時看看資料就能瞭解的，因此汽車行業的碼農都需要有一定的機械學科背景。
2， 電學知識。汽車軟件要接收來自傳感器的大量的外部信號輸入，包括各種數字信號（開關信號）、模擬信號（傳感器值），軟件工程師有時候需要對這些值進行濾波、計算，轉換為自己有意義的輸入。因此對於想加入汽車軟件行業的初學者也需要一定的電學基礎。
3， 需要標定能力。汽車軟件很多算法是無法在開發軟件的時候得到，需要後期在實車/Labcar上實驗得到。所以汽車軟件的標定功能是強於其他行業的，汽車軟件工程師也需要一定的標定能力來測試和開發軟件。
汽車軟件行業趨勢
1， ECU整合度將提升
早在去年，大眾就宣佈力爭讓汽車上只有一個ECU。在一些供應商巨頭內部，確實也在這麼做。特別是在ADAS和自動駕駛下，整合的ECU架構尤為重要。
2， ECU將承載更多的傳感器
未來汽車將需要更多的傳感器來感知環境，以及依靠傳感器來保證冗餘設計。這對ECU的能力來說也是考驗。不過高級算法與機器學習的發展，有望取代一部分傳感器，減少傳感器數量。
3， 汽車以太網發展
長期以來，汽車ECU都是在一個封閉的網絡環境下。不過隨著智能汽車技術、物聯網的發展，很有可能會催生汽車以太網，實現跨域通信。不過如何保證功能安全，這將又是對汽車軟件的一大考驗。
閱讀更多 2030出行研究室 的文章
