?對于下一代集中式電子電器架構而言，采用central+zonal 中央計算單元與區域控制器布局已經成為各主機廠或者tier1玩家的必爭選項，關于中央計算單元的架構方式，有三種方式：分離SOC、硬件隔離、軟件虛擬化。集中式中央計算單元將整合自動駕駛，智能座艙和車輛控制三大域的核心業務功能，標準化的區域控制器主要有三個職責：電力分配、數據服務、區域網關。因此，中央計算單元將會集成一個高吞吐量的以太網交換機。

隨著整車集成化的程度越來越高,越來越多ECU的功能將會慢慢的被吸收到區域控制器當中。而平臺化區域控制器則是采用相同的硬件設計、相同的IO接口看，可以更好的滿足對于不同車型的擴展性要求。所以，區域控制還同時承擔整車硬件抽象的重要職能。其兩者之間都會采用高速以太網代替原始的Can通信進行相互連接。概括來講，可拓展的電子架構就是要屏蔽車型之間的硬件差異。不管采用多少個區域控制器組成的通訊網絡，其相互之間的通訊模式，都遵守同樣的規則。同時區域控制器也承擔其局域網內，ECU功能的抽象之責。

如上以中央計算平臺為核心的集中式架構設置了統一的傳感器及外設接口，能夠支持芯片的升級，其最終目的就是要實現在車生命周期內的硬件可升級，從而延長汽車的智能化生命周期。而各區域控制器各自帶有自己的操作系統中間件SOA Core Middleware，可以提供一個分布式計算和通信框架，對下屏蔽各類操作系統系統內核差異，對上提供統一的服務開發框架。涉及功能包括服務管理、網絡管理、通信管理、升級、診斷、日志、狀態等。

本文將重點重軟硬件解耦的方向講解如何對SOA進行軟硬件部署。

01 SOA的軟件架構設計原理

如下圖表示了典型的SOA軟件架構設計原理。這種以服務為目標的開發架構實際上是實現面向服務開發的SOA架構模型方案，讓產品經理專注于服務的設計，而系統軟件則深入到產品的開發過程中，這也是解決汽車軟件危機的重大突破。整個SOA架構可以總結為由邏輯架構構建起的一個軟硬解耦的系統和由服務架構完成的服務抽象與適配，最終建立了一個標準化的服務體系。 

其整體邏輯架構設計過程可概括為：

電子電氣架構：設計可拓展的架構（也叫計算與通信架構）需要滿足分層設計、分層測試、分層驗證要求，避免在開發階段軟件更迭的連鎖反應和集成測試中問題集中爆發，使得發現問題更加迅速，軟件版本更迭更加快速。

硬件計算平臺：可擴展的硬件平臺包括SOA基礎服務管理和SOA硬件I/O控制管理，可兼容自動駕駛系統的多個傳感器和外部設備，支持多異構芯片和硬件升級。

操作系統內核/服務中間件：作為文件調度和驅動的核心，操作系統在支撐軟硬件解耦和軟件在硬件上的部署方面可以實現最好的支配能力。

通信架構：通信架構的可擴展性可以很好的確保平臺化車型開發中快速適配，車型之間的差異可以減少到最少，開發下階段車型秩序進行通信擴展借鑒當前這代產品，不用再進行很多額外的開發工作，這樣可以大大減少后期產品線維護的壓力。

為了滿足車輛控制實時性的要求，核心網將會采用如TSN等的可靠通訊技術。在區域控制器下的局域網內，傳統的CAN、Lin等通訊方式將會繼續存在。局域網內可以以傳統的信號的方式進行通信，在核心的以太網骨干網絡中，將會以服務的方式進行數據之間的交互，就需要如DDS等通信中間件。

服務層/應用層：標準化的服務層及可編排的應用層包含SOA系統功能管理、單元域功能管理、整車功能控制管理、云端服務管理幾個重要部分。

02 SOA中的設備抽象技術

在詳細分析以中央域控為核心的軟件架構部署核心技術之前，需要詳細說明一下相關聯的幾個重要概念。Autosar中的傳感器/執行器設計模式描述了在整體架構環境中ECU如何處理在環的傳感器/執行器。

BEG設備抽象位于RTE（是試運行環境之上），它是從連接到特定ECU的傳感器和執行器中抽象出來的一組軟件組件，他使用了傳感器或執行器軟件組件，是RTE之上唯一允許訪問ECU抽象接口的組件。設備抽象提取傳感器和執行器的原始信號，如像素點、點云、電壓、PWM信號、數字信號/消息、頻率，并為應用層軟件提供物理接口（例如像素點、點云、壓力、質量、溫度等），實際說來，設備抽象完成了電壓值、數字信號、點云等到物理值的轉換。

設備抽象體現了應用層軟件通過平臺軟件及底層驅動軟件在其他不同硬件變體之間的可互換性。

表1平臺軟件與設備抽象關系（傳感器）

表2 平臺軟件與設備抽象關系（執行器）

 總結來講，BEG設備抽象概念和設計可概括如下：

應用軟件獨立于連接到特定ECU的具體傳感器和執行器；

不同傳感器和執行器之間代碼可復用；

不同的代碼共享合作模式（軟件共享），從而支持不同的商業模式；

將功能部署或重新分配到不同的ECU；該設計模式也被稱為設備抽象；

設備抽象解決了S&A層Module向上暴露功能及服務接口，向下連接平臺軟件，目標是盡可能地暴露接口，實現軟硬件解耦，避免因S&A變化導致地軟件變更。

03 SOA中的設備抽象示例

這里我們列舉一個實例說明在SOA架構中如何進行設備抽象。這種方式只需要了解傳感器類別（如雷達、攝像頭等）來定義輸入的原始數據Rawdata，無需了解這些傳感器的具體連接方式，對于頂層應用層則是只需要應用最終的傳感數據。

以傳感器的設備抽象為例，可以表示如下： 

首先是在底層物理層MCAL通過訪問uC端口的方式進行數據采集并提供原始數據，每隔一定周期（如10ms）檢測一次，這里不需要了解器電器連接方式以及相應的數據含義。比如從底層激光雷達傳感器采集到原始圖像像素點數據，并輸入給微控制器MCU/SOC。 

其次，MCU/SOC從對應物理地址中按照一定周期取出對應的點云值，通過I/O設備給I/O硬件抽象模塊，并通過I/O硬件抽象點檢測所測數據測量點的一級電器連接路由，傳感器基于路由信息和解讀后的原始數據計算的電壓值并進行濾波處理，該過程不需要了解所測數據的含義。

隨后，將硬件抽象模塊中的電壓值按照8bit驅動進行分階處理，并由傳感器電子設備驅動調用生成基礎原始值。該值通過傳感器虛擬設備驅動Virtual Device Dri 行人、路標等。

最終，AP Autosar中的應用軟件通過實時運行環境RTE對傳感器感知目標級數據進行實時的讀取，用于后續的應用軟件的規劃控制和決策控制。

從如上示例可看出，設備抽象具備如下優勢，Sensor&Actuator的變化不會引起平臺軟件和應用軟件的連帶更改，總結起來大致有如下幾種變換導致的軟硬件解耦類型。 

對于替換不同型號的感知傳感器，ECU的選型不再受限制于ECU支持的信號分析模式的型號。如NTC和PTC型號的替換，只需要修改位于Device Driver中軟件模塊即可。

同一類型的傳感器和執行器模塊可共用某些相同的處理模塊，比如對于側視攝像頭的處理模式，可以直接將對其中一個側視攝像頭的處理算法直接應用于其余三個，而只需要重新對該三個攝像頭的相機參數進行標定即可，如果有部分攝像頭需要更新換代為更高分辨率攝像頭，對于底層驅動軟件和平臺軟件來講也是無需做很大變動的，至少I/O接口形式和數據輸入模式都不用在動，只是在處理圖像的算法模塊需要重新進行調優，比如原來采用的低分辨率處理算法可能無法達到高分辨率處理模塊對其實時性的要求，這時需要研究神經網絡加速模型的優化方式，但是整體的算法架構模型是仍舊不變的。

04 總結

當前眾多主機廠比較倡導的開發方式是進行平臺化產品開發，而平臺化講求的就是軟硬件解耦的核心思想，采用SOA架構模式則是便于形成產品線和平臺線的分工，產品線負責具體車型項目，平臺線，負責構建技術中臺。新平臺的開發，技術鏈路往往非常長且復雜，分層的架構設計和軟硬件解耦的方式，可很好的便于進行分層測試與驗證，減少集成測試的壓力，問題發現的更充分，也能夠提高版本發布的速度。?