作者 | Aimme

出品 | 焉知

對著智能汽車趨向于網聯化、智能化、電動化、共享化的發展。最終的智能汽車產品趨向于行車-泊車-底盤-座艙-動力一體化的方案，而階段性的產品是適應用戶需求的快速升級，車企需要開發智能、安全、可靈活擴展、成本可控的E/E架構平臺，以滿足汽車不斷升級的需求。

智能汽車E/E架構發展趨勢如下：

1）ECU從分布式走向集中式；

即從原來的30-150個ECU，各ECU負責功能獨立的系統，且復雜度高、成本高，逐步過渡到多個ECU整合成域控制器，降低成本、重量和功耗，利用硬件和軟件創新實現面向服務的架構（SOA），可直接訪問內存，并行計算載體提供冗余和安全性，面向OEM系統集成的可擴展開放平臺的方向發展，最終實現面向服務的架構（SOA），面向網絡訪問，移動配置和無縫冗余。

目前，量產車型主流為分布式架構，主流OEM在研車型基本采用域控制器架構，基于中央計算平臺或與融合式架構平臺正處于規劃階段，對于已量產的車型從分布式演變到域控制器式，中央控制架構是下一代自動駕駛系統的趨勢。

2）ECU軟硬件體系結構趨向于標準化；

整個ECU軟硬件體系結構從橫縱向兩邊分別涉及軟硬件組件、需求、功能，其中軟硬件組件涉及底層芯片、傳感器、操作系統、中間件、服務應用。需求層包含互聯性、可用性、低延遲、冗余控制、集成策略。功能包含信息/娛樂、AI感知、安全、車身/舒適、動力幾個方面。

3）進一步擴展中間軟件層；

當前，每個ECU的中間件負責ECU的內部通訊，每個功能軟件都是靜態被創建在ECU中，更新一個功能需要對整個ECU軟件進行重新編譯和更新，沒有明確地方法論去降低整個系統的復雜性。未來，中間件具備跨越域訪問Domain ECU的能力。通過故障識別和故障冗余機制可實現功能安全，當車輛啟動時可以通過標準化接口運行增加功能。通過資源透明化，可實現配置優化。

4）車內傳感器數量將持續增加，且傳感器將變得更加智能；

此外，下一代自動駕駛將設置雙電源及網絡冗余，加強以太網技術應用，OEM也會嚴控數據接口，云計算等應用也將越來越重要，OTA升級策略也將成為車輛基礎技術。

從軟件功能開發的角度上講，下一代域控制器架構是實現階段性的智能駕駛行車-泊車一體化控制策略。本文將對其進行詳細的講解和分析。

智能行車-泊車一體化全域解決方案

滿足L2/L3高等級的駕駛輔助功能（智能行車-泊車）需求將集中到一個ECU對行車-泊車等基準控制功能進行有效處理。并且該集中式方案在網絡安全，冗余備份等方面更具優勢，在技術上也更具有挑戰性。智能行車-泊車全域解決方案設計的思想主要集中在以集中式域控做為總體感知處理端口，以不同的SOC對其中的行車和泊車模塊進行軌跡規劃、決策，且過程中綜合考慮駕駛員輸入的行車/泊車控制指令，最終參照一定仲裁的策略對其行車和泊車進行執、控制。

對于智能汽車而言，下一代產品傾向于從智能行車、智慧泊車向行-泊一體化方向演進。何為行泊一體化呢？即主要面向于解決如下多個主要的開發性問題：

1）集中中央控制器

這里的中央控制單元集成行車、泊車整體控制功能，集成度更高，軟件處理能力更強大，包含行車及泊車的整體感知、規劃控制、決策執行的能力。且兩者分布于中央控制器中的不同控制模塊，可有效地降低中央控制器數量。更強大的控制器整合平臺，集成行車和泊車的多個軟件功能模塊。

在行泊一體控制系統中，考慮到執行單元基本都是相同的控制單元，比如縱向控制均是ESP控制加減速，EPS控制轉向，EMS/HCU都用于控制車輛的加速，BCM用于控制車輛的燈光、車門、車窗等控制，IP及IHU負責整個人機交互顯示等。因此在特殊工況下，可能存在行車和泊車同時激活并進行執行單元控制的情況。如低速前行時可能是泊車系統控制加減速，也可能是行車系統控制的加減速，而對于控制器或執行器而言需要對這些加減速進行仲裁。假如從執行端口出發，其接收上層控制單元輸出的控制指令都是一個命令輸出口，那么其頂層仲裁機制就需要在行泊一體中央控制器中進行。

相應的感知控制應用處理框圖如下。

2）增強型網關

由于智能行車和泊車的整個功能集中化，在傳感控制等通信鏈路上都需要增強網關對于各個數據的轉發能力，這種轉發能力包括數據的數量和種類上的不同。如同時需要轉發包含以太網、CANFD甚至Lin信號。這可以通過新建路由機制，可增加路由復雜度和通信吞吐量。

3）通信網絡升級

行車泊車一體控制過程要求其通信帶寬滿足其龐大的數據量要求，這里特指通信網絡能夠適配更多的包含圖像、激光點云、毫米波點云等原始信息。因此，需要整個智能行車-泊車需要更高帶寬，更加靈活的通信機制。

4）冗余設計

從提高系統可靠性的角度出發，在整個智能化行泊一體系統設計中，不管是行車還是泊車，均需要帶有一定的冗余網絡結構及供電系統。以便在主控單元出現問題時，可以由冗余單元接替進行綜合控制。

由于泊車處于低速控制狀態，且往往在各種工況下容易處于倒擋狀態，因此，冗余對于泊車而言不進行前向安全停車的需求，更多的也是包含后向緊急剎停的過程。當然如果僅僅是比較簡單的控制減速停車的方法是采用固定的減速度控制剎停。如果僅僅考慮執行單元的冗余也只需要考慮如功能仲裁機制中的執行命令仲裁方式，然而這里并沒有那么簡單。考慮如智能行車主要考慮前向控制的傳感冗余，泊車系統也需要同時考慮在其主要感知傳感器失效后如何進行后向傳感冗余設計，確保后向緊急剎停過程中實時調整剎車方位角與減速度。

5）功能仲裁機制

這里我們需要重點說明一下行車泊車一體化域控制器控制過程中如何進行感知輸入處理及命令仲裁。對于行泊一體化域控單元，需要在內部分別進行行車感知處理與泊車感知處理。感知的結果在控制單元中首先進行感知融合，再分別生成行車規劃控制軌跡及泊車規劃控制軌跡，在其控制單元中的人機交互端口可以接受駕駛員的操作指令，如一鍵泊車指令輸入后可對行車規控和泊車規控中的執行指令進行有效的仲裁。比如對于低速智能行車和泊車在規控后生成的同一個轉向指令輸入至轉向執行端EPS中時，需要對該指令打上標簽；兩者指令的結合可以有效的指導執行器參照不同的響應方式進行車輛控制，而這個打標簽的過程也是仲裁的一部分。

在整個控制過程中，主要涉及行車及泊車的狀態機如何被仲裁后從待機向激活的整個跳轉過程。

6）面向服務的軟件架構

對于行車-泊車的一體化控制而言，其設計為面向服務的軟件架構顯得尤為必要。因為對于駕駛員來說，其并不關心其駕駛過程中如何實現，而是只是以結果為導向，關心其實現結果是否能夠滿足其設置的目的性要求。何為目的性要求？也就是駕駛員對整車的輸入不再是我需要行車還是泊車，而是我需要到達某個地方，要求本車自動設置導航，自動駕駛到目的地，到達目的地后自動控制車輛找到車位并停車。這一過程中涉及的主要職能車輛控制技術就包括了智能駕駛和智能泊車兩項。

7）基本顯示單元

SOA架構的本質是將原本相互分散的行車-泊車ECU甚至后續會考慮集成智能座艙域ECU，將其對應的基礎軟件功能模塊化、標準化，將各個應用區域相互解耦，重新部署為分層式的軟件架構，汽車可在不增加或更換硬件的條件下通過不同的軟件配置為駕駛員提供不同的服務，從而實現千人千面。

這里的智能行車-泊車一體化控制單元是實現了SOA的第一階段的集中式域控設計，需要充分考慮行車與泊車顯示單元所需求的一切顯示與交互能力。結合智能座艙的交互機理，在人機交互層面上仍然需要仲裁行車與泊車輸出的顯示報警信號。同時對于座艙域輸入的交互信息需要從功能的不同角度分別進行考慮行車和泊車的激活狀態，比如座艙域給定的駕駛員狀態監測結果顯示為疲勞或分心，那么智能行車單元一般的策略是將無法持續控制車輛，發出報警顯示甚至直接降級退出。又如，對于泊車控制而言，其整個泊車過程中，如果駕駛員仍然處于駕駛位上，那么肯定需要實時監控其停車的狀態，隨時準備微調泊車過程或直接接管。如果駕駛員在車外遠程操控自動泊車，那么也仍然需要通過手機實時監控車輛的泊車的完成狀態。

8）車輛互聯

車輛互聯實現車輛信息共享與實時信息交互。安全防護，增加威脅檢測，威脅自修復等防護手段。

總結

隨著汽車科技的進步，圍繞“四化”的需求越來越多，智能汽車電子架構將發生變革。集中化域的電子電氣架構將成為主流解決方案。未來智能汽車是基于功能域控制器的集中化架構趨勢，同時諸如智能行車、泊車的區域控制器將逐漸過渡為局部中央計算單元，基于環形主干網和多域計算架構的方案都將逐漸演進到可實施的方案中。