第2篇 智能技術

第2章 電子電氣架構與計算平臺

2.1 汽車電子電氣架構

2.1.1 汽車電子技術發展歷史

汽車電子技術的發展及其應用是從20世紀70年代末到現在，大致經歷了4個發展階段。

第一個發展階段為1971年以前，汽車開始應用技術原理簡單的交流發電機、電壓調節器、電子閃光器等分立元器件搭建的電路，該階段汽車為純機械控制，電子技術只是作為輔助。

第二個發展階段為1974—1982年，隨著集成電路的快速發展，汽車開始應用16位以下的微控制器，電子汽油噴射技術的發展和ABS（防抱死制動系統）作為該階段的典型代表，是汽車從機械控制逐步向電子控制轉變的開始。

第三個發展階段為1982—1990年，隨著微處理器技術的逐漸成熟，汽車電子開始向智能化方向發展。汽車應用的產品有胎壓控制器、數字式油壓計、直視儀表板、倒車示警器、高速限制器、自動后視鏡系統等，該階段汽車控制系統逐步電子化，同時輔助駕駛系統開始開發應用。

第四個發展階段為2005年至今，隨著汽車智能化、網聯化、電動化的快速發展，自動防撞、動力優化、自動駕駛、高清地圖導航等技術逐步開始應用于汽車，該階段表現為汽車開始轉變為完全由電子系統掌控，不需要駕駛人，同時汽車開始作為一個網絡終端，和其他網絡設備一起構成新一代網絡體系。

2.1.2 汽車電子電氣架構相關知識

1.架構定義

電子電氣架構包括所有的電子和電氣部件、它們之間的互聯結構（拓撲結構），以及它們之間的線束連接。一個完整的電子電氣架構是由不同的車載網絡連接在一起的，為了系統化管理和規劃，按照功能將車輛劃分為不同電子系統管理域，如信息娛樂系統（指示、娛樂和車載導航）、行車安全系統（底盤、主動、輔助駕駛系統）、傳動系統（驅動、廢氣處理）等。通過劃分不同的域，將功能和軟硬件結合到一起，依維柯電子電氣架構如圖2-1所示。從圖中可以看到，整個電子電氣系統由不同的功能模塊組成，功能模塊之間通過總線進行連接。

2.架構模型

電子電氣架構模型從不同的維度描述了電子電氣架構系統，主要包括邏輯模型和實現模型兩種，如圖2-2所示。邏輯模型用來描述抽象邏輯層面上的功能，不依賴于實現該功能的硬件。實現模型用來確認實現功能需要的電子部件，同時會根據功能耦合關系進行合理的功能域分配和接口分配，其中，節點模型用來合并技術鏈不同的技術組件，電子部件硬件模型用來實現節點模型的硬件部分，電子部件軟件模型又分為基礎軟件和應用軟件兩部分，通信網絡模型用來描述通過總線進行連接的部件，電源網絡模型描述負載對電源的需求，安裝空間和線路模型定義具體部件的安裝空間和線纜的走線和固定方式等。

圖2-3所示為功能模型典型案例，它通過作用鏈來描述。該模型將功能和與之相連的傳感器及執行器以粗略的功能塊的形式加以描述，并不涉及其具體技術實現。

圖2-4所示為技術模型實現過程。技術模型中由技術組件形成一個技術鏈，而技術組件要說明功能模塊是采用硬件還是軟件來實現，確認實現主體。

圖2-5所示為節點模型實現過程。它屬于技術鏈的技術組件合并到處于不同位置的節點中去。因此，節點模型包括并描述了電子電氣架構中所有需要的部件。此外，在確定節點模型時還要決定功能的集成度，將功能進行合理的集成。

3.開發流程

電子電氣開發過程遵循V模型開發流程，按照邏輯關系和時間先后順序將開發步驟連接在一起，并對每個設計的輸入/輸出文檔做出規定。

圖2-6所示為汽車電子電氣架構開發V模型，這是一種典型的V模型。汽車電子電氣架構開發過程屬于整車開發過程的需求分析階段和設計階段。在進行電子電氣架構開發的需求管理和需求分析時，要區分功能需求和非功能需求。功能需求產生汽車制造商的功能列表，而非功能需求產生汽車制造商的決策矩陣和設計限制。電子電氣的開發有兩種模式，一種是從下到上的模式，一種是從上到下的模式。從下到上的開發模式是以現有的電子電氣架構為基礎，僅對某些附加功能和通信涉及的新部件加以補充，并執行相應的建模步驟。這種方式最適合于對現有電子電氣架構的下一代進行開發。從上到下的模式則適合應用于新的車輛平臺的開發。

4.開發工具鏈

在電子電氣架構設計過程中需要應用到很多電子設計自動化（Electronics Design Automation, EDA）工具，比較有代表性的有DOORS（需求管理工具）、PreeVision（電子電氣架構設計工具）、Capital（線束設計軟件），通過應用EDA設計軟件，可以提高開發效率和開發準確性。

整車電子電氣系統開發過程中，會涉及需求、功能設計、網絡設計、功能分配、線束設計等多方面內容，由不同的部門或工程團隊進行共同開發。為了實現多團隊并行開發過程中的合理分工與協作，整個電子電氣架構設計需要按照分層設計的思路展開，如圖2-7所示。在模型開發過程中需要進行不斷的評估優化，最終選擇最優的設計方案。

PreeVision開發過程包括按照架構模型的開發邏輯和V模型的開發過程，分為需求定義、功能邏輯設計、硬件系統設計、線束層設計和拓撲層設計幾個部分。

（1）需求定義

該層需要導入需求開發的工作成果——需求規范，也可以直接將需求開發的工作在此階段開展。該層用來描述電子電氣系統要實現的功能需求和非功能需求，是電子電氣架構設計的起始點。

（2）功能邏輯設計

該層約定整個系統功能的邏輯實現方法。功能網絡層的內容包括邏輯傳感器、功能塊、邏輯執行器等功能模塊，以及各功能模塊之間的信息交互接口。當功能網絡層各模塊之間的端口通過信息交互接口連接后，相應模塊就能進行數據和控制信息的交換。在功能網絡里，用戶可以看到各功能模塊之間的邏輯關系。

（3）硬件系統設計

該層主要包括網絡層、部件層和線路原理層。網絡層描述各部件之間的邏輯連接方式，如總線系統、傳統連接、電源供應和地線連接，這些連接將在隨后的線路原理層進行進一步的細化；部件層描述每個部件內部構成及其對外接口的詳細信息；線路原理層描述網絡層中邏輯連接的具體實現情況，如具體的導線、線纜連接方式、保險繼電器盒的內部結構等。

（4）線束層設計

邏輯和原理性的連接關系在線束層中進行物理實現。該層中可以將線路原理層的連接關系在電線和電纜兩方面進一步細化，將線束特定的屬性添加到模型中。在該層中每段電線（或電纜）及相應的接插件都具有其物理屬性（包括單位長度重量、成本、過電流能力等信息）。線束元素將來可以在拓撲結構中形成具體的電線和電纜布局（包括結合點和對接插頭的布局等）。

（5）拓撲層設計

該層描述了電子電氣系統的實際布置情況。設計人員需要根據實際情況，確定各個部件以及線束的最終安裝位置，需要設定不同安裝位置之間的“線路段”的具體長度。之后便可以得出電子電氣系統中的整個線束的統計長度。

2.1.3 汽車電子電氣架構發展趨勢

1.電動化

隨著汽車電子電氣架構的發展，全電力和數據網絡冗余將變得至關重要。對可靠性要求較高的安全類關鍵應用，將利用整個冗余圈來完成所有對安全行駛至關重要的工作，如數據傳輸和電力供應等。電動汽車、中央計算機和高耗能分散式計算網絡都需要具備冗余性的新型能源管理網絡。線控轉向和其他自動駕駛功能所需的高容錯性，同樣需要冗余系統設計。這一切尚難以在目前的故障保護監控應用架構上完成，仍有待進一步突破。

電動汽車屬于新能源范疇，得到了各國政府的大力支持。一方面，電動汽車可以很好地解決各國政府所焦慮的能源結構多元化的問題；另一方面，電動汽車可以解決城市里汽車尾氣污染問題。因此，電動汽車行業便成了各國優先扶持和發展的朝陽產業。通常，一個行業的發展需要技術、政策和市場三方面的支持，而在電動汽車行業發展中，政策明顯走在了市場需求前面。圖2-8所示為各國禁售燃油車時間表，挪威和荷蘭宣布將于2025年禁售傳統燃油車。法國則稱最遲2040年禁售燃油車。印度稱要在2030年禁售傳統燃油車。而向來保守的汽車強國——德國，在2016年11月通過聯邦內閣決議，宣布在2030年禁售傳統燃油車，這在整個汽車市場和汽車行業引起了極大的轟動。

2.智能化

（1）ECU從分布式控制到集中式處理，域控制器成為主流

隨著自動駕駛的發展，軟件功能復雜化和硬件系統冗余化的進一步提升，對處理時延會有更嚴格的要求，因此域控制器作為高性能集中式處理中心的方式更加合理。從系統時間同步、軟硬件解耦合、系統通信速率等方面考慮，集中式處理具有明顯優勢。

智能網聯需求持續推動汽車電子電氣架構變革。隨著汽車智能化、網聯化發展，汽車電子底層硬件不再是由實現單一功能的單一芯片提供簡單的邏輯計算，而是要具備可移植、可迭代和可拓展等特性。智能化與網聯化共同推動了汽車電子電氣架構的變革，一方面是車內網絡拓撲的優化和實時、高速網絡的啟用，另一方面是ECU的功能進一步集成到域控制器。

圖2-9所示為汽車電子電氣架構發展趨勢，從圖中可以看到隨著汽車海量數據處理需求的快速增長，ECU逐步從分布式向集中式架構演進，從車端向云端過渡，以滿足不斷增長的運算需求。

域控制器（Domain Control Unit, DCU）的概念最早由以博世、大陸、德爾福為首的Tier1（一級供應商）提出，是為了解決信息安全和ECU瓶頸的問題。根據汽車電子部件功能將整車劃分為動力總成、車輛安全、車身電子、智能座艙和智能駕駛等幾個域，利用處理能力更強的多核CPU（Central Processing Unit）或者其他高性能AI（人工智能）芯片相對集中地去控制每個域，以取代目前的分布式汽車電子電氣架構。

一個好的域控制器架構，可以帶來未來硬件和軟件的復用，將大大降低車輛的維護成本和提升用戶體驗。這在部分量產車上已經有非常成熟的應用。

而從設計角度來講，多域控制器架構一是能夠將傳感與處理分開，傳感器與ECU不再是一一對應的關系，尤其對于原始設備制造商（Original Equipment Manufacture, OEM）來說，可以隨意更換傳感器的供貨商（在標準協議的基礎上）；二是平臺本身的可擴展性，能夠對接的傳感器類型與數目并不固定，可以根據OEM的需求對應開發。

自動駕駛域控制器注重的是靈活可用，滿足端客戶需求，因此在具體的實現方案上會有多種選擇。域控制器在業內已經形成共識，無論是主機廠還是Tier1，都在加大研發力度。在下一代的車型中，域控制器將會成為主流。

（2）車載傳感器數量將飛速增加且智能化和融合度越來越高

在今后兩到三代汽車產品上，整車企業將安裝多個具備相似功能的傳感器，以確保車輛具有充足的安全冗余。長期看來，行業將開發更完善的傳感器解決方案來減少傳感器數量和成本。未來的高級算法與機器學習可增強傳感器性能和可靠程度，再輔之更加強大的傳感器技術，傳感器冗余將有望減少。集成化的智能傳感器將被用來管理自動駕駛所需的大量數據。傳感器融合和3D定位等高級功能將在中心化運算平臺上進行，預處理、篩選和快速反應則很可能直接在傳感器內完成。據估算，一輛自動駕駛汽車每小時產生的數據量將達4TB，因此傳感器將需要完成部分傳統由ECU完成的工作。為確保正確運轉，新一代傳感器清潔系統，如除冰除塵等，將尤為必要。

圖2-10所示為自動駕駛傳感器功能評級，每種傳感器都有自己最適合的工況，每種傳感器都有自己無法克服的缺陷，因此“量”無法解決“質”的問題。真正的解決之道是綜合不同傳感器采集到的信息。舉例來說，CMOS（互補金屬氧化物半導體）攝像頭在雨霧環境下就會“失明”，強光和弱光環境它也不能處理。現在的雷達技術在分辨率上也有些不合格，因此可以說每種傳感器都有自己的軟肋。

想做到完美的傳感器融合，就要接受不同傳感器的輸入，并利用綜合信息更準確地感知周邊環境，其得出的結果比不同傳感器各自為戰要好得多，因此傳感器融合才是未來的大趨勢。

值得一提的是，將不同傳感器進行融合還能換來一定程度的冗余，即使某個傳感器出了問題（自然原因或人為）也不會影響車輛的安全。在駕駛人依然手握轉向盤的階段，這種冗余看似用處不大，但到了全自動駕駛的時代，一定程度的冗余就能給駕駛人換來自救的時間窗口。

不同等級的自動駕駛具有不同的方案，也需要不同的傳感器。而按照NHTSA（美國國家公路交通安全管理局）和SAE（國際自動機工程師學會）對自動駕駛的劃分，目前市場上在售的諸多具備車身穩定系統、防抱死制動系統、自動緊急制動系統、牽引力控制系統等功能的汽車已經達到了L1等級的自動駕駛，而人們熟悉的谷歌自動駕駛汽車，到目前為止也未能達到L4等級的自動駕駛。目前業界討論的自動駕駛，更多的是L3和L4等級。

圖2-11所示為自動駕駛傳感器市場預測，預計2022年激光雷達市場營收將達到16億美元，雷達市場營收將達到0.44億美元，攝像頭市場營收將達到6億美元，慣性測量單元市場營收將達到9億美元，全球導航衛星系統市場營收將達到1億美元。更長遠地看，預計2032年傳感器硬件的總體營收將達到770億美元，而計算硬件約為520億美元。

3.網聯化

（1）車載高性能網絡快速發展

數據量的提升、自動駕駛的冗余要求、互聯環境下的安全保障，以及跨行業標準協議的需求很有可能催生汽車以太網，并使其成為冗余中央數據總線的關鍵助推因素。以太網解決方案可以實現跨域通信，并通過添加以太網擴展，如AVB（音-視頻橋接）和TSN（時間敏感網絡）等，來滿足實時性要求。

本地互聯網絡、控制器局域網絡等傳統網絡將繼續在車輛上運用，但僅用于封閉式的低級網絡，如傳感器和執行器等。FlexRay和面向媒體的系統傳輸（Media Oriented System Transport, MOST）等技術有可能被汽車以太網及其擴展（如AVB、TSN等）取代。整車企業會嚴控與功能安全及自動駕駛相關的數據互聯，但將為第三方訪問數據開放接口。發送與接收安全關鍵數據的中央互聯網關將始終直接且僅連接到整車企業的后臺，第三方會被允許進行數據訪問（被監管法規排除的場景除外）。然而，在車輛APP化的推動下，資訊娛樂系統的新興開放接口將允許內容和應用程序供應商加載內容，而整車企業將盡可能嚴格地保持各自的標準。

圖2-12所示為域級車載以太網架構，以太網為車載網絡骨干，集成動力總成、底盤、車身、多媒體、輔助駕駛，真正形成一個域級別的汽車網絡。這種網絡架構引入了一個新問題：如何組織ECU和網絡管理者之間的通信，不可否認的是，這種分層式的架構會造成控制器通過以太網骨干網和交換機通信時所需的軟件內容增加。有研究預計，以太網有望在2020年成為主要的汽車網絡技術，預計到2025年可能替換所有其他的車載網絡。

（2）汽車將在云端結合車內及車外信息以及OTA（Over-The-Air）更新

雖然非車企以外的企業參與程度仍取決于監管法規，非敏感數據（即非隱私或安全相關數據）仍然有望更多地在云端進行處理。隨著數據量的增長，大數據分析將被越來越多地應用于數據處理，并將基于數據處理結果制定相應的行動方案。

基于數據的自動駕駛的應用及其他各項數字化創新將依賴于不同企業之間的數據共享。當然現在仍然不清楚不同企業間的數據共享將如何實現、由誰實現，但主要的傳統供應商和技術企業已經開始建立有能力處理這種海量數據的集成化平臺。通過車載測試系統，汽車可以實現自動檢查功能和集成更新，從而推動生命周期管理，以及增強或解鎖產品的售后功能。所有ECU都會與傳感器和執行器交換數據，并檢索數據包來支持創新性用例，如基于車輛參數的路線計算。

OTA更新是自動駕駛的前提條件，它還將有助于開發新功能、確保網絡安全，并使車企得以更快部署功能與軟件。車輛將在全生命周期內獲取功能性及安全性升級。監管部門可能強制要求軟件維護，以確保車輛設計的安全完整性。更新和維護軟件的責任將在車輛維護與運行領域催生新業務模式。

OTA更新的基本流程如下：

1）管理和生成相關的文件：云端服務器是負責監測整個OTA更新過程的主要單元，它不僅要確定更新哪些車輛，是否與車輛建立可靠的連接（生成一個可靠的可信通道）并實時掌握消息，還要把固件包或者更新包從軟件庫里面提取出來，確定分發包的更新順序，管理整個進程，并在完成后校驗。

2）分發和檢查：服務器端負責加密渠道分發，車端控制器負責接收服務器指令，并對更新包進行下載、驗證和解密。針對每次更新，服務器與車端配合對過程進行監控。車端控制器必須具備足夠的存儲空間及計算能力。與服務器相對應的也有作業管理器負責報告當前狀態和錯誤信息，每個更新作業都有一個用于跟蹤使用情況的作業ID（身份識別碼）。

3）更新和刷新安裝：這里一定有讀者會提問，車輛如果像手機一樣刷死機了怎么辦？通常整車企業在決定FOTA前需要做完備的考慮。以特斯拉為例，圖2-13所示為特斯拉OTA架構，通過使用運算的聯網模塊（如儀表盤、中控臺等）實現對整個進程的監控。將更新文件刷入ECU，對于儀表盤來說，每一步操作都會監控整個機制是否完整，并且保證能隨時停止和重新寫入，只要對應的ECU存在可以運行的導引程序，那么就保證了車輛和服務器對整個過程的控制，并把刷死機的風險降到最低。

完成最后的準備工作后，ECU將重新啟動，代理和服務器之間將持續連接，服務器可以獲得當前更新狀態的最新信息。