汽車背后那些看不見的軟件系統是怎樣誕生的？汽車產業需要工程師們具備怎樣的軟件能力呢？產業變局中的每條賽道究竟是個怎樣的現狀呢？
2019年，全球范圍內先后至少有6起特斯拉汽車自燃事件，其中最轟動的是發生在上海的那起：4月21日，在上海的地下車庫停放的Model S無征兆自燃事件將特斯拉送上輿論熱點。在初步判斷為電池短路問題后，特斯拉官方也做出了最快的應對：于5月開展了旨在“保護電池，改善電池耐用度”的2019.16.1和2019.16.2版軟件升級。隨后至今的數月當中，Model S自燃的事故數量大大降低，軟件升級起到了立桿見影的效果。這是第一次讓我們看到汽車上看不見的軟件系統的力量，本文將對汽車軟件系統的相關開發過程進行(深度剖析) 。
沒有召回汽車，甚至沒有提醒車主注意事項，特斯拉只進行了一次例行公事的OTA升級就很好地渡過了這次危機，軟硬件協調能力令人側目。 特斯拉所展現的軟件能力，已經成為廣大主機廠們普遍的追求；而塑造自身軟件能力的行動，則正在汽車產業內廣泛地落地。
根據美國電氣和電子工程師協會與IHS咨詢公司報告，上世紀80年代初，一輛轎車的電子系統只有5萬行代碼，而現在高端豪華汽車的電子系統就有6500萬行程序代碼，提升了1300倍。即便已到達近億的數量級，大陸汽車集團總裁仍然認為在未來的數年中，這個數字還將翻數倍甚至十倍！
汽車軟件如此重要，汽車產業上下游也理所當然地將軟件能力提升到戰略地位：大眾集團計劃在未來的五年當中，不惜花費研發投入的50%來“生產”整輛汽車代碼中的60%，為此需要將其軟件團隊數量擴容到5000人；而在3年前，零部件巨頭博世就制定了面向未來的3S戰略，Software便是3大核心之一；大陸汽車CEO則認為，面向未來，大陸集團的整個工程師團隊都應該具備軟件背景。
那么目前的汽車產業需要工程師們具備怎樣的軟件能力呢？產業變局中的每條賽道究竟是個怎樣的現狀呢？下文將試圖針對以上問題做出回答。
汽車軟件系統同硬件系統一道實時獲取、理解駕駛員需求，通過邏輯運算得出機械部件需要做出的響應并發出指令。軟件、硬件相互合作，它們一同組成了汽車電子系統。
當你跨入汽車，按下啟停鍵，你點燃汽車動力核心，儀表亮起。掛擋，踩滿油門，你感受到十足的推背感。
高速上，打開自動巡航，汽車駕駛輔助系統為你接管大部分行駛功能。
到達目的地，按下自動泊車，汽車自主轉動方向盤控制油門進入車位。
這些年來，你能感受到汽車新功能帶來的駕駛樂趣和出行便利，你能看到駕駛室內日漸豐富的中控系統。而在汽車炫酷的外表下，你看不見的是：
上百個電子控制單元中循環執行的代碼功能塊;
在連接各電控單元的線束中不斷穿梭的電子信號;
終端執行器在接受電子指令后的精準運作;
以及遍布汽車各個角落的傳感器和實時傳回的感知數據。
這套隱形而強大的系統就是汽車軟件系統。
它同硬件系統一道實時獲取、理解駕駛員需求，通過邏輯運算得出機械部件需要做出的響應并發出指令。軟件、硬件相互合作，它們一同組成了汽車電子系統。
一、汽車電子系統
遙想1950年，當時豪華車搭載的電子設備屈指可數：啟動機、電池、車燈、轉向燈和火花塞。只要40根銅導線就可以滿足整車的電子部件通信和電能供給。
隨著汽車向“四化”不斷推進，汽車軟件系統的功能越發可靠和多樣。
如今普及的大型車載互動屏幕在當時是不可想象的，那個年代收音機是車載娛樂系統的全部。為了力保這唯一的多媒體設備能夠正常工作，外置收音天線成為整車中要求最高的一根電線：畢竟它要在車外風吹雨淋，工作環境嚴苛。
1980年代。隨著IT技術的起步和興起，在當時機械主宰的汽車行業內掀起了一場電子電氣化革命。今天汽車標配的安全氣囊、防抱死系統ABS、車輛穩定系統ESP、發動機電控系統和導航系統都集中誕生于那個年代。搭載軟件系統的電子控制器開始在車上出現。
隨著控制器數量逐漸增多，不同控制器之間的通信問題亟需解決，如今人們熟悉的CAN總線、LIN總線等應運而生。
1990年，用于發動機管理和防抱死系統的電子控制器成為所有汽車的標準配置，軟件成為汽車的重要組成部分，整車廠也逐漸意識到因為通信總線不斷延長而日益升高的成本。2000年奔馳S級轎車的電子系統已經擁有80個電控單元，1900條總長達4km的通信總線。2007年奧迪Q7和保時捷卡宴的總線長度突破6km。
(汽車各大系統的軟件功能逐年快速增長)
從上圖可以看到，以奧迪為例，汽車各大系統的軟件功能逐年快速增長。軟件系統越做越大，越做越復雜，硬件系統跟著齊頭并進。
在這些硬件數量爆發的背后，究其根本原因是汽車業需要滿足客戶逐漸提高的駕駛性和舒適性需求，同時要滿足一系列汽車安全性能行業標準。
下圖可以看到軟件系統最小單元“功能函數”的總數隨著時間推進，迅速增長。但是電子控制器的數量卻在2010年前后開始放慢增長。這是因為越來越多的控制器，急劇增加了整車成本。整車廠面對成本壓力不得不開始考慮應對策略，逐步將小型控制器集成到一個大型控制器。汽車電子系統從分散化轉向集中化，減少控制器數量，降低總線長度，從而降低成本。
(離不開硬件的軟件)
要理解為什么軟件、硬件不能分家，只有組合在一起才可以組成汽車電子系統，我們需要首先搞明白汽車是如何與駕駛員和環境互動的。
下圖是一個抽象出來的控制模型。駕駛員通過方向盤、踏板和換擋桿等給出期望(W*)操控汽車。這一系列實實在在、看得見摸得著的期望被轉化為抽象的電子信號(W)進入電控單元。隨后電控單元通過比較駕駛員期望(W)和傳感器傳回的當前實際值(R)進行對比。若對比發現，期望與現實存在差距，電控單元中的軟件程序會通過邏輯計算給出指令(U)操控執行器做出響應(Y)。控制對象在執行器的動作和環境的影響(Z)下，開始做出駕駛員期待的反應(X)。這一反應(X)又會通過傳感器監控、感知，當前狀態(R)將再次返回電控單元完成控制閉合回路。
(控制模型)
聽起來十分復雜抽象，這里舉一個剎車輔助系統的例子來說明。
緊急剎車時，如果駕駛員腳力不足或反應較慢，沒有及時將剎車完全踩死、踩滿會導致剎車系統無法全力工作，在這種情況下這套系統就將被激活。在駕駛員剎車踏板輸入不變的前提下，自動提高制動力使汽車更快減速。
例如，行車中遇到緊急情況，駕駛員抬起油門后，快速用力地踩下剎車踏板期望汽車迅速減速(W*)。剎車踏板通過采集踏板值變化率、踏板受力等信號(W)得到駕駛員踩剎車踏板的輕重、緩急等信息，理解駕駛員意圖。W作為電子信號傳入相應的電控單元中。同樣傳入電控單元的還有傳感器的實時測量數據(R)，例如當前輪胎轉速或車速。若軟件通過比較發現，當前輪速高、車速快、減速度不足，駕駛員踩下的剎車踏板深度不足以讓剎車系統發揮出最大功能，最終得出液壓制動系統需要進一步剎車的結論(U)。
(電子控制單元)
位于輪胎附近的制動卡鉗接到指令(U)開始工作讓輪胎轉速變慢。結果由于路面結冰的影響(Z)車輪在強制動力的作用下開始抱死打滑，一系列制動工作沒有讓汽車達到預期的減速效果。傳感器將發生的這一切以電子信號的形式通過通信線束(R)實時傳回電控單元。軟件邏輯將因此激活防抱死系統ABS，操控制動系統做出響應并不斷接受傳感器的控制反饋，最終達到讓汽車減速這一駕駛員期望。
這一次次的控制，在電控單元中以10ms甚至更快的速度循環進行著。
(電子控制單元及其剖面圖)
以上是一個十分簡單的電控例子，只有一個電控單元參與其中。而現如今許多復雜的汽車功能常常需要由多個電控單元、多個傳感器聯合控制才能實現。
例如自適應定速巡航功能ACC，駕駛員通過設定期望巡航速度、與前車保持的期望距離等實現駕駛輔助系統一定程度上接管汽車的功能。這一功能就需要多個電控單元協作完成并且通過總線讓它們隨時保持通信聯系。ACC控制器、雷達控制器、發動機控制器、ESP控制器、變速箱控制器、人機交互控制器以及數不清的傳感器和執行器都將參與其中。
可以說，軟件和硬件系統相互合作，共同為汽車創造出一個個新的功能奇跡。
(自適應定速巡航功能ACC控制網絡)
二、軟件系統的出現
急劇攀升的軟件代碼量、龐雜的總線通信導致汽車電子系統日漸復雜。
根據ADAC(全德汽車俱樂部，德國最大的交通協會)統計，德國2004年有40%的車輛故障最終歸咎于軟件問題或電子部件故障。為此，必須在保證電子系統整體可控的前提下研發新功能，軟件工程師絕不能容忍自己迷失在親手創建的龐大系統中。
正如汽車行業的那句老話：Divide et Impera!維基百科對應的中文詞條將它翻譯為“分而治之”。德語將這句拉丁語翻譯為Teile und beherssche!，直譯中文是拆解和掌控。
首先，如上圖所示將電子系統研發拆解為軟件系統、硬件系統、傳感器和執行器研發四大部分，經過V模型流程研發，最終再次集成。這個V模型涵蓋了從系統層面到軟件層面以及集成后的功能測試和系統測試等流程，是當今汽車行業廣泛應用的開發流程。因為其形狀如字母V而因此得名。
下面將以下圖所示的軟件系統開發為例，分步驟介紹V模型。
1、分析終端客戶需求、定義邏輯系統架構
這一步是根據終端客戶的需求以及法規需求定義出整車軟件系統的邏輯架構。其中包含各大功能塊的定義，功能塊接口定義和功能塊之間的通信定義。這一步僅考慮滿足原始需求，不會涉及任何技術層面的具體分析。
2、分析邏輯系統架構需求、定義技術層面系統架構
邏輯系統架構為定義具體的技術層面系統架構提供了基礎。在這一步中開始討論具體的技術問題，哪些功能將通過軟件實現、軟件塊分裝在哪些電子控制單元以及電控單元之間采用什么通信協議等等。軟件系統初現雛形。
3、分析軟件需求、定義軟件架構
這里開始具體到電控單元中對于軟件本身的需求分析。根據需求，定義出合適的軟件架構。同時，還要考慮電控單元存儲資源的最優使用、為滿足安全法規的冗余系統設計等等。這里，會把軟件進一步細分為更小的軟件部件，定義各個部件之間的接口、分層和邊界。
4、定義軟件部件
針對每個軟件部件會繼續定義出需求。這里的需求集中在功能層面，尚不考慮具體的軟件實現方式等。
5、設計、實現及測試軟件部件
依據具體的需求，工程師開始分別搭建不同的軟件部件。在前面一系列的拆解、分析和定義后，終于抵達了軟件最核心最具體的世界——代碼。與人們熟知的程序員直接寫代碼稍有區別，傳統的汽車軟件研發采用的是基于模型開發。
如下圖所示，邏輯運算通過模型的方式表達出來，相比于代碼更加直觀，便于日后的標定工作和維護。在一個電控單元中，有上千個這樣的功能函數，如下圖所示的功能模型組合到一起，會形成一份上萬頁的文件。這份文件是接下來所有流程的基礎。
當然這套模型只是工程師之間便于交流的高級語言，最終它們會被人工或計算機轉為代碼進入控制器中工作。
早年間，模型到代碼中間的轉換工作由人工完成。這造成的問題是，代碼無法統一化和標準化。面對一個軟件邏輯模型，程序員可以用多種方法完成代碼編譯工作，達到同樣的功能效果。
但是，代碼運行所占用的硬件資源或嚴謹度會大不相同。因此，近年來轉碼工作逐漸被機器取代。軟件工程師事先定義標準的編譯規范，保證最終代碼統一和標準。
每一個軟件部件完成后，要進行相應的軟件測試。這里還不會聚焦功能層面的測試，僅僅針對軟件本身。
例如軟件中是否因設計不當產生死循環、每個信號定義的范圍是否恰當、會不會造成溢出錯誤或者會不會出現除以零的運算情況等等。針對這些，工程師要事先定義測試方案，由計算機進行全方位全覆蓋的軟件邏輯測試。例如，對于if, else語句需要把每一種可能的情況都測試檢查到。
6、集成及測試軟件部件
單一軟件部件研發測試完成后，將它們集成到一起就形成了每個電控單元中完整的軟件包。
這套軟件包在集成后依然需要測試，檢查各部件之間是否兼容，是否有開放接口等等。
7、系統集成及測試
當軟件包集成測試結束，它們將被刷進每一個電子控制器中。每個控制器與相應的傳感器、執行器等用線束相連，最后控制器之間接通總線通信。
這樣整套電子系統終于誕生。如新生兒一般，這套系統依然十分脆弱和稚嫩，還有很大的潛力等待被開發。
系統集成后的第一批測試往往是問題重重。因為系統高度復雜，各個研發部件被分工研發，即便之前有嚴格的測試流程，仍會有許多漏網之bug。如果分工研發的各部門之間沒有在開發過程中充分交流，集成后可能會出現各類兼容性問題。
針對每一個問題，工程師們都不會忘記前面提到的拆解和掌控。拆解表象問題，找到根源，修復軟件bug，掌控整套系統。
8、標定
系統測試結束后將進入軟件標定階段，這也是軟件開發中的重要階段。在軟件實現階段，工程師會在軟件中預留一些可標定參數而不是固定的數值，等待標定。
這是基于成本考量，車型繁多的整車廠不可能為每款車型單獨開發一套軟件系統。一般的解決方案是研發平臺軟件，適用于多款車型。然而每款車型都有自己的特點，平臺軟件無法讓這些特點發光，標定可以。
通過改變不同的參數數值，可以讓車輛實現不同的駕駛性能，這也給了標定工程師很大的發揮空間。
9、系統測試及接受度測試
標定完成后，就進入了整套流程的最終階段。依據流程一開始提出的需求，忽略那些具體的技術實現手段，站在整個系統的高度檢驗它是否達到了終端客戶的需求。
到了這一步，整套軟件系統已經十分成熟。在正式進入量產前會從一個時間點開始，停止所有軟件和標定變更，為最終量產做準備。
整套V模型走下來可以看到，左側和右側的每個環節相互對應。需求為定義測試方案提供基礎，而測試結果又會帶動進一步的開發和完善。
你或許會問，如果從V模型的左上角好不容易一路走到右上角，結果最后一步測試發現當初第一步的系統構架出了設計問題，那豈不是為時已晚?難道還要一切重新來過?的確，軟件系統十分復雜，研發周期長。如果只是沿著V模型慢慢悠悠從左到右走一遍，等最后一步才發現問題，那確實一切都來不及了。
因此，在實際研發中會持續不斷地集成、持續不斷地測試，工程師們會把V模型從左到右重復走許多遍。
研發初期連原型車都還沒有的時候，軟件測試會依靠整車仿真系統在計算機中進行，發動機、變速箱、電子控制器、總線等都虛擬存在于工程師電腦中(SiL, Software in the Loop)。在仿真系統中，汽車可以如真實般開動，模擬各種工況提供給工程師測試。
隨著車型研發推進，某些電子控制器研發完成，他們可以取代那些虛擬的電子控制器進入測試環境，但是其他部件仍為虛擬仿真(HiL, Hardware in the Loop)。
直到有一天，原型車研發完成，軟件集成和測試進入試驗臺架。最終，原型車調試完畢落地，軟件測試進入實車階段。
可以說，軟件開發的起始點非常早，從虛擬到現實一路走來，一直延續到最后的量產前夕。其實目的只有一個，通過不斷集成和測試，盡可能發現所有問題，保證汽車的駕駛性、舒適性和安全性。
三、未來展望
毋庸置疑，汽車軟件的蓬勃發展必將持續下去。
電動汽車的興起，省去了機械加工復雜且精密的發動機，汽車廠商競爭的重點從機械中轉移出來。為了讓產品更有吸引力更能脫穎而出，軟件因為其研發的靈活性，逐漸成為廠商間新的競技場。
展望未來，大型中央控制器將成為主流以減少分散在汽車各個角落的小型控制器，降低總線長度。另外，速度更快、帶寬更大、傳輸信息更有效率的總線將逐漸成為行業新標準。
5G通訊技術的興起會讓車聯網和更加炫酷的車載娛樂成為可能，而這一切都要依靠軟件的繼續發展。電子控制器中的軟件也將有可能在云端運行，與汽車實時互動溝通，這些都為軟件工程師們打開了更廣闊的空間。
而不變的是，為了讓汽車能夠經受住最嚴苛的環境考驗，汽車軟件工程師們將繼續如極客般完成軟件的標定和測試。
他們冬天穿梭在零下30度的北極圈內，與極光、麋鹿、雪松為伴。夏天在滾滾熱浪中，面對太陽的炙烤，坐在尚未開發完成的原型車內，將電腦與車輛相連進行測試。汽車進入緊急狀態，空調失效時有發生。但這些都無法阻擋他們不斷突破科技極限、創造汽車未來的決心。
因為，當燈光亮起，幕布掀開，新車閃亮發布，世界為之鼓掌時，這一切努力都將顯得意義非凡。
來源：汽車技術課程 微信號
作者：Sam GIU
參考文獻
[1]. J. Sch?uffele, T. Zurawka, Automotive Software Engineering: Grundlagen, Prozesse, Methoden und Werkzeuge effizient einsetzen (ATZ/MTZ-Fachbuch) , 5. Auflage, 2013.
[2]. S. Thiel, Petri-Netz basierte Verifikation von funktionalen Testf?llen
[3]. H Richter, Elektronik und Datenkommunikation im Automobil
以上就是100唯爾(100vr.com)小編為您介紹的關于汽車的知識技巧了，學習以上的汽車背后那些看不見的軟件系統是怎樣誕生的？汽車產業需要工程師們具備怎樣的軟件能力呢？產業變局中的每條賽道究竟是個怎樣的現狀呢？知識，對于汽車的幫助都是非常大的，這也是新手學習汽修專業所需要注意的地方。如果使用100唯爾還有什么問題可以點擊右側人工服務，我們會有專業的人士來為您解答。
本站在轉載文章時均注明來源出處，轉載目的在于傳遞更多信息，未用于商業用途。如因本站的文章、圖片等在內容、版權或其它方面存在問題或異議，請與本站聯系(電話：0592-5551325，郵箱：help@onesoft.com.cn)，本站將作妥善處理。
向客服提問汽車課程推薦
汽修專業熱門資料
汽修專業技術文檔
推薦閱讀
