?對于下一代集中式電子電器架構(gòu)而言，采用central+zonal 中央計(jì)算單元與區(qū)域控制器布局已經(jīng)成為各主機(jī)廠或者tier1玩家的必爭選項(xiàng)，關(guān)于中央計(jì)算單元的架構(gòu)方式，有三種方式：分離SOC、硬件隔離、軟件虛擬化。集中式中央計(jì)算單元將整合自動(dòng)駕駛，智能座艙和車輛控制三大域的核心業(yè)務(wù)功能，標(biāo)準(zhǔn)化的區(qū)域控制器主要有三個(gè)職責(zé)：電力分配、數(shù)據(jù)服務(wù)、區(qū)域網(wǎng)關(guān)。因此，中央計(jì)算單元將會(huì)集成一個(gè)高吞吐量的以太網(wǎng)交換機(jī)。

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

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

本文將重點(diǎn)重軟硬件解耦的方向講解如何對SOA進(jìn)行軟硬件部署。

01 SOA的軟件架構(gòu)設(shè)計(jì)原理

如下圖表示了典型的SOA軟件架構(gòu)設(shè)計(jì)原理。這種以服務(wù)為目標(biāo)的開發(fā)架構(gòu)實(shí)際上是實(shí)現(xiàn)面向服務(wù)開發(fā)的SOA架構(gòu)模型方案，讓產(chǎn)品經(jīng)理專注于服務(wù)的設(shè)計(jì)，而系統(tǒng)軟件則深入到產(chǎn)品的開發(fā)過程中，這也是解決汽車軟件危機(jī)的重大突破。整個(gè)SOA架構(gòu)可以總結(jié)為由邏輯架構(gòu)構(gòu)建起的一個(gè)軟硬解耦的系統(tǒng)和由服務(wù)架構(gòu)完成的服務(wù)抽象與適配，最終建立了一個(gè)標(biāo)準(zhǔn)化的服務(wù)體系。 

其整體邏輯架構(gòu)設(shè)計(jì)過程可概括為：

電子電氣架構(gòu)：設(shè)計(jì)可拓展的架構(gòu)（也叫計(jì)算與通信架構(gòu)）需要滿足分層設(shè)計(jì)、分層測試、分層驗(yàn)證要求，避免在開發(fā)階段軟件更迭的連鎖反應(yīng)和集成測試中問題集中爆發(fā)，使得發(fā)現(xiàn)問題更加迅速，軟件版本更迭更加快速。

硬件計(jì)算平臺(tái)：可擴(kuò)展的硬件平臺(tái)包括SOA基礎(chǔ)服務(wù)管理和SOA硬件I/O控制管理，可兼容自動(dòng)駕駛系統(tǒng)的多個(gè)傳感器和外部設(shè)備，支持多異構(gòu)芯片和硬件升級(jí)。

操作系統(tǒng)內(nèi)核/服務(wù)中間件：作為文件調(diào)度和驅(qū)動(dòng)的核心，操作系統(tǒng)在支撐軟硬件解耦和軟件在硬件上的部署方面可以實(shí)現(xiàn)最好的支配能力。

通信架構(gòu)：通信架構(gòu)的可擴(kuò)展性可以很好的確保平臺(tái)化車型開發(fā)中快速適配，車型之間的差異可以減少到最少，開發(fā)下階段車型秩序進(jìn)行通信擴(kuò)展借鑒當(dāng)前這代產(chǎn)品，不用再進(jìn)行很多額外的開發(fā)工作，這樣可以大大減少后期產(chǎn)品線維護(hù)的壓力。

為了滿足車輛控制實(shí)時(shí)性的要求，核心網(wǎng)將會(huì)采用如TSN等的可靠通訊技術(shù)。在區(qū)域控制器下的局域網(wǎng)內(nèi)，傳統(tǒng)的CAN、Lin等通訊方式將會(huì)繼續(xù)存在。局域網(wǎng)內(nèi)可以以傳統(tǒng)的信號(hào)的方式進(jìn)行通信，在核心的以太網(wǎng)骨干網(wǎng)絡(luò)中，將會(huì)以服務(wù)的方式進(jìn)行數(shù)據(jù)之間的交互，就需要如DDS等通信中間件。

服務(wù)層/應(yīng)用層：標(biāo)準(zhǔn)化的服務(wù)層及可編排的應(yīng)用層包含SOA系統(tǒng)功能管理、單元域功能管理、整車功能控制管理、云端服務(wù)管理幾個(gè)重要部分。

02 SOA中的設(shè)備抽象技術(shù)

在詳細(xì)分析以中央域控為核心的軟件架構(gòu)部署核心技術(shù)之前，需要詳細(xì)說明一下相關(guān)聯(lián)的幾個(gè)重要概念。Autosar中的傳感器/執(zhí)行器設(shè)計(jì)模式描述了在整體架構(gòu)環(huán)境中ECU如何處理在環(huán)的傳感器/執(zhí)行器。

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

設(shè)備抽象體現(xiàn)了應(yīng)用層軟件通過平臺(tái)軟件及底層驅(qū)動(dòng)軟件在其他不同硬件變體之間的可互換性。

表1平臺(tái)軟件與設(shè)備抽象關(guān)系（傳感器）

表2 平臺(tái)軟件與設(shè)備抽象關(guān)系（執(zhí)行器）

 總結(jié)來講，BEG設(shè)備抽象概念和設(shè)計(jì)可概括如下：

應(yīng)用軟件獨(dú)立于連接到特定ECU的具體傳感器和執(zhí)行器；

不同傳感器和執(zhí)行器之間代碼可復(fù)用；

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

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

設(shè)備抽象解決了S&A層Module向上暴露功能及服務(wù)接口，向下連接平臺(tái)軟件，目標(biāo)是盡可能地暴露接口，實(shí)現(xiàn)軟硬件解耦，避免因S&A變化導(dǎo)致地軟件變更。

03 SOA中的設(shè)備抽象示例

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

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

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

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

隨后，將硬件抽象模塊中的電壓值按照8bit驅(qū)動(dòng)進(jìn)行分階處理，并由傳感器電子設(shè)備驅(qū)動(dòng)調(diào)用生成基礎(chǔ)原始值。該值通過傳感器虛擬設(shè)備驅(qū)動(dòng)Virtual Device Dri 行人、路標(biāo)等。

最終，AP Autosar中的應(yīng)用軟件通過實(shí)時(shí)運(yùn)行環(huán)境RTE對傳感器感知目標(biāo)級(jí)數(shù)據(jù)進(jìn)行實(shí)時(shí)的讀取，用于后續(xù)的應(yīng)用軟件的規(guī)劃控制和決策控制。

從如上示例可看出，設(shè)備抽象具備如下優(yōu)勢，Sensor&Actuator的變化不會(huì)引起平臺(tái)軟件和應(yīng)用軟件的連帶更改，總結(jié)起來大致有如下幾種變換導(dǎo)致的軟硬件解耦類型。 

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

同一類型的傳感器和執(zhí)行器模塊可共用某些相同的處理模塊，比如對于側(cè)視攝像頭的處理模式，可以直接將對其中一個(gè)側(cè)視攝像頭的處理算法直接應(yīng)用于其余三個(gè)，而只需要重新對該三個(gè)攝像頭的相機(jī)參數(shù)進(jìn)行標(biāo)定即可，如果有部分?jǐn)z像頭需要更新?lián)Q代為更高分辨率攝像頭，對于底層驅(qū)動(dòng)軟件和平臺(tái)軟件來講也是無需做很大變動(dòng)的，至少I/O接口形式和數(shù)據(jù)輸入模式都不用在動(dòng)，只是在處理圖像的算法模塊需要重新進(jìn)行調(diào)優(yōu)，比如原來采用的低分辨率處理算法可能無法達(dá)到高分辨率處理模塊對其實(shí)時(shí)性的要求，這時(shí)需要研究神經(jīng)網(wǎng)絡(luò)加速模型的優(yōu)化方式，但是整體的算法架構(gòu)模型是仍舊不變的。

04 總結(jié)

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