SOA中的軟體架構設計及軟硬體解耦方法論

對於下一代集中式電子電器架構而言，採用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 平台軟體與裝置抽象關係（執行器）

抽象分層	作用	#工作原理	工作明細
平台軟體	#輸入PWM，輸出PWM值 解耦軟體與硬體連接	提供物理特性原始介面	機械特性、電氣特性、功能特性和規程特性。
電子設備驅動	#輸入電壓值，輸出過濾後電壓值 確保執行器執行過程有效性	運行電氣設備驅動軟體電氣診斷（如偵測對地、電池短路、開路等）	去噪濾波器 執行器外部供電時的電壓補償
#執行器裝置驅動	##輸入PWM，輸出保護及對應的PWM值 解耦執行機械過程 解耦執行器能力保護	感測器裝置驅動程式代表執行器的物理行為	·疊加輸出值以克服驅動器的摩擦 ·輸出執行訊號值並保證執行有效 ·限制輸出值以防止過度損壞 ·控制設定值(配合感測資料閉環) ·提供限制和能力資訊的介面
虛擬裝置驅動程式	#輸入執行器請求值輸出PWM值，如閥門開度  #解耦傳執行器抖動、非線性化、執行超限等處理	#虛擬設備執行程式抽象執行器的實體表現	·控制端物理請求值轉換 ·非線性值轉換為線性值 ·用於功能測試的診斷測試器介面 ·特殊模式處理 ·啟動執行機構運行 ·透過覆寫設定值或濾波消除執行器階段性抖動 ·協調執行器的安全激活

 總結來講，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架構模式則是便於形成產品線和平台線的分工，產品線負責具體車型項目，平台線，負責建造技術中台。新平台的開發，技術鏈路往往非常長且複雜，分層的架構設計和軟硬體解耦的方式，可很好的便於進行分層測試與驗證，減少集成測試的壓力，問題發現的更充分，也能夠提高版本發布的速度。

以上是SOA中的軟體架構設計及軟硬體解耦方法論的詳細內容。更多資訊請關注PHP中文網其他相關文章！