2.3 新型電子電氣架構的挑戰

互聯網技術和移動通信技術的成熟將大大加快電子電氣架構在當前基礎上的進一步演進。計算機技術的高速發展推動控制器計算能力向中央和云端集中，汽車電子電氣架構朝著集成式、服務器式這一方向演進。

目前，車載服務器已經被開發出來，可用于預定義功能的應用軟件和第三方軟件及服務平臺，憑此可實現新的移動概念，提升終端用戶體驗。這對于汽車電子電氣架構而言，是未來發展的驅動力量和發展機遇，車輛智能網聯化發展為汽車電子電氣架構帶來了更大的挑戰。

1.安全問題

隨著汽車電氣化、智能化、網聯化的發展，汽車功能越來越復雜，數據信息呈指數級增加。而數據涉及用戶隱私和人身安全，必須系統分析安全漏洞與威脅風險，實施有效的安全防護策略，部署相關安全措施，如圖2-16所示。

功能安全是指避免由系統功能故障導致的不可接受的風險，重點關注系統發生故障之后的行為因素，致力于找出所有可能的系統失效原因，并針對這些失效原因制定相應的安全機制，采取相應的安全措施。

電子電氣架構面臨的功能安全挑戰主要體現在感知冗余和自動駕駛控制冗余兩方面。車輛的電子電氣架構從最初的單激光雷達單攝像頭架構，到后來的多激光雷達多攝像頭架構及復合攝像頭架構，這些架構中不同種類的攝像頭、激光雷達都需要進行安全冗余設計。在傳感器出現故障后，系統能夠依靠冗余備份的傳感器進行工作，保證車輛正常行駛。在自動駕駛系統中，自動駕駛域控制器主要負責決策、路徑規劃控制。為了避免由自動駕駛域控制器失效引起的系統故障，自動駕駛域控制器也要采用冗余設計（一般采用雙冗余設計），當主用自動駕駛域控制器失效時，備用自動駕駛域控制器開始工作。

預期功能安全的關注點是由于功能不足、可合理預見的人員誤用所導致的危害和風險。例如，傳感系統在暴雨、積雪等天氣情況下，本身并未發生故障，但能否執行預期的功能是預期功能安全的重點。

信息安全問題一是車載系統本身的網絡安全風險迅速增加，智能網聯化升級帶來代碼數量增加，而代碼所存在的漏洞是與生俱來的；二是汽車智能網聯化功能大幅增加，汽車成為車聯網系統中的關鍵信息節點，人、車、路、云之間的信息傳輸存在風險；三是云端安全隱患，即車聯網云端服務器可能存在安全漏洞，導致黑客通過云端發送惡意文件、向車輛下達指令等問題。

由于汽車產業涉及諸多領域，汽車數據處理能力日益增強，汽車數據規模龐大，汽車數據安全問題和風險隱患也日益突出。例如，汽車數據處理者超越實際需要過度收集重要數據；未經用戶同意，違規處理用戶個人信息，特別是個人敏感信息；未經安全評估，違規出境重要數據等。因此，亟須加強汽車數據安全管理，防范化解上述安全問題和風險隱患。

2.通信架構

隨著汽車電子電氣架構日益復雜化，其中的傳感器、控制器和接口越來越多，自動駕駛也需要海量的數據用于實時分析決策，要求車內外通信具有高傳輸速率、低時延和多通信鏈路，這對架構的通信能力提出了更高的要求。通信架構升級是電子電氣架構亟須解決的問題，如圖2-17所示。

3.計算能力

智能網聯汽車的發展對于電子電氣架構的另一個挑戰是控制器算力。智能網聯汽車功能繁多，對汽車處理器性能的要求越來越高。據評估，自動駕駛等級每提高一級，算力需要增加一個數量級。L2級別大概需要2TFLOPS的算力，L3級別需要24TFLOPS的算力，L4級別為320TFLOPS，L5級別為4000+TFLOPS，如圖2-18所示。如此巨大的算力需求，對于電子電氣架構是個巨大的考驗。

4.硬件超前部署

硬件和軟件的分離，以及軟件的爆炸性增長，遠遠超過了技術的變化。軟件由于標準化的接口和模塊化，可以實現重復使用。一旦汽車成為一個由軟件、應用程序和新功能組成的生態系統的移動數據中心，就需要實現硬件的超前部署。功能不再是一個由ECU和軟件組成的固定品，而是整個生態系統的一部分。雖然過去的標準是將每個ECU的計算和存儲能力及其基礎設施限制在最低水平，但HPC提供了從不同來源（新軟件供應商、開源社區）OTA安裝額外功能的可能性。如果在HPC中提供了足夠的資源作為未來的性能緩沖，那么硬件在未來幾年內都是適用的，也為隨后實現新的基于數據和服務的商業模式（功能升級、新功能）提供了可能性。因此，硬件必須滿足未來5年甚至10年的需求，確保計算能力和存儲能力滿足未來功能的擴展。

5.軟件架構

隨著汽車及其環境中的軟件驅動創新不斷增加，其復雜度也在快速增長，甚至在有些情況下，復雜度已經超出了可以控制的范圍。軟件驅動創新的快速增長也是汽車電子日趨復雜的驅動力之一，如圖2-19所示。

為了管控快速增長的復雜度，汽車軟件需要一個清晰的架構。當今的架構演進是各公司關注的重點。架構的影響是多方面的，主要包括：系統模型、測試、功能安全；具有安全通信、面向服務式高級操作系統（如Adaptive AUTOSAR）；ADAS（高級駕駛員輔助系統）和自動駕駛的多傳感器融合和圖片識別；車輛控制器固件遠程更新所需的端對端信息安全；云技術和IT骨干網與數十億輛汽車及其車載設備的連接，以實現信息娛樂、在線應用、遠程診斷和緊急呼叫處理。

6.開發模式

為了確保汽車中安全攸關系統的安全性和可回溯性，以及為了明確責任認定，汽車軟件行業如今普遍采用ISO 26262和ASPICE等標準作為軟件開發的方法和流程。汽車行業的供應商多數采用傳統的瀑布式流程或V型流程來進行軟件開發，并編制出大量的相關支持文檔。這種流程不僅煩瑣，而且越來越不適應如今快速變化的市場需求。

開發汽車控制軟件毫無疑問是一個系統工程。V型流程通常先凍結需求，再讓軟件和測試團隊開始工作，這在實際操作中是很難實現的。因為客戶需求在不斷變化，軟件團隊也需要不斷調整工作策略。因此，越來越多的軟件團隊如今傾向于使用敏捷框架進行軟件開發，以縮短軟件迭代的時間，在保證軟件安全性和完備性的前提下，更好地實現不同職能團隊之間的協作。

軟件定義汽車整車開發模式結合了傳統軟件開發模式和整車V型開發模式的優點，具備快速迭代、持續集成、并行開發、多平臺適用及用戶個性化等特點，如圖2-20所示。

在軟件定義汽車整車開發模式中，首先進行系統解耦分析，將整車解耦為子系統進行需求分析，然后進入持續集成開發階段，按照“設計-開發-測試-發布”循環往復進行，持續將軟硬件集成至系統主干上，最終完成發布。在持續集成開發階段，各類開發工具平臺如CarSim、PreScan、CARLA等的適用性可使整車開發效率大幅提升。整車投入使用后，根據用戶反饋情況進行快速迭代，再次經歷“系統需求分析-持續集成”的流程并通過OTA技術完成功能發布。

軟件定義汽車整車開發模式繼承了傳統軟件開發模式的優勢，通過并行開發、持續集成，高效利用多開發工具平臺的優勢，可極大地提升整車系統的開發和測試效率。同時，利用快速迭代的軟件開發模式可使用戶個性化需求得到最大程度的滿足，使整車開發貫穿全產品使用周期。

7.供給關系

軟件定義汽車的概念出現后，傳統的主機廠、Tier1的垂直關系會變成主機廠與合作伙伴之間相互交叉、協同和合作的關系，形成一個開發的生態群，大家一起把產品做好，如圖2-21所示。

功能實現不再只依靠硬件，算法、軟件成為功能實現的重要組成部分，隨之也出現以算法、軟件供應商為主的新型Tier0.5級供應商，如自動駕駛算法、自動駕駛解決方案、人工智能、OTA系統、信息安全等全新供應商，新的生態群合作模式會進一步深度化。