車載算力平台的發展：功能內建度、算力需求、軟硬體複雜度、通信需求指數升高；随着EE架構發展，逐漸走向計算中央化、資料和能源區域化的形态。整車EE架構與車載算力平台發展的瓶頸在于其簡單的邏輯處理、軟硬體不通用、應用功能固化、軟體不可疊代等不利因素，導緻目前這代智能駕駛産品的應用能力無法真正适用于未來的智能汽車開發過程。對于下一代自動駕駛來說，需要強大的資料處理能力，比如使用千兆以太骨幹網，5G高帶寬，AI計算平台技術；同時，開放的API與IDE也可以将多種傳感器資料進行融合，實作資料與API的開放共享，進而擁有強大的應用管理程式APP開發內建環境。
為實作智能車載軟體的快速開發，包含面向服務的設計過程，應對不斷測試過程中出現的新場景的快速疊代，滿足客戶千人千面的需求，縮短整個汽車開發周期。此外，通過軟體的快速部署，軟硬分離，軟體重組，應用新增，實作外部資源的有效整合，增加車輛服務的豐富性。
1. 基于SOA的集中式域控架構設計
對于高性能計算平台而言，通常采用集中化跨域融合的域控架構，需要實作多存在于互聯類功能或域控間直接互動實作的功能，通過單一大腦HPC+區域控制的架構方案，要求區域控制器承擔代理（Proxy）功用，往往與面向服務的SOA架構一起綁定來進行設計，這将導緻靈活性擴充性較高的SOA在下一代集中式域控架構中的滲透率将非常高。
采用SOA設計理念，在SOA服務中實作軟硬體解耦，控制IO虛拟化、服務化。進行車内多層級服務的定義和部署是下一代域控平台通用的設計方案。對于集中式域控制器平台而言，設計過程中需将車輛控制、自動駕駛、智能座艙多域融合，硬體資源共享，資料實時共享域控硬體：各領域内最先進的晶片，通過高帶寬低延遲時間Switch級聯軟體，除了實作實作算力擴充和多域融合，也可以實作高安全、硬實時OS、中間件及應用運作環境域控與其他控制單元之間通信。
如下圖顯示了一種基于中央計算單元+區域控制單元的實體架構，對于實作真正的中央計算平台而言，還需要設定1-多個區域控制器PDC、VDC等組成的環網架構用于實作資料和能源網關的功能，進而減少線束數量/長度，優化能源智能化管理模式，有效提升中央域控制器軟體化的功能。
此外，對于上述大資料互動來說，也需要設定相應的交換傳輸單元進行相應的資料交換。這些交換單元包括PCIe Switch、Ehternet Switch、TSN Switch；其中，PCIe Switch滿足算力晶片之間的實時大資料互動；解決高帶寬、低延時的痛點需求實作任意端到端之間的資料傳輸，且帶寬在20Gb/s以上，實體隔離，單點失效不影響系統失效。TSN Switch具備CAN/CANFD/LIN到以太網的雙向傳輸協定轉換功能。實作了TSN協定中的NC/EE/BE不同優先級資料流轉發和資料交換。可相容其它符合車載規範的TSN裝置。Ethernet Switch 用于連接配接以太網之間或者以太網與快速以太網之間的交換機，該交換機通過實體編址、網絡拓撲結構、錯誤校驗、幀序列以及流控，進而節省了資源和時間，提高了資料傳輸的速率。
這裡我們需要說明一下，集中式域控設計中需要支撐SOA實作的技術載體。包括了面向服務的通信SOC：DDS、SOME/IP等及服務接口定義和實作；同時面向服務的軟體架構支撐SOSA：如AP，是可滿足功能安全的一定實時性要求的方案；面向服務重用共享架構設計SORS：自上而下與自下而上的結合，保證服務重用共享以及擴充；
基于SOA範式的産物包含了服務實作的代碼/模型，內建了（服務代碼+SOC代碼+支援SOSA系統環境）的控制器，整車由該控制器組成的子系統。下圖顯示了一種典型的對域控來說基于SOA從系統設計到代碼實作模型的流程圖。
2. 基于SOA服務的終端測試
1、基于SOA服務的終端測試流程
對于下一代自動駕駛系統SOA來說，除了應該明确掌握SOA本身的定義外，還需要掌握如何測試SOA，了解其實作的技術産物是什麼，基于SOA的實作實體又是什麼，基于SOA理念的新EE架構将如何開展測試。本章節将詳細講述SOA的測試流程和方法。
要清楚了解SOA的測試流程，首先需要掌握SOA的設計流程。他包括9個子流程，分别如下：
A1：整車Feature List定義；
A2：Feature的usecase分析；
A3：邏輯子系統定義；
A4：功能需求規範；
A5: 針對SOA服務和服務接口定義，其中服務包含從可行性和必要性角度，哪些功能适用于作為服務，定義其顆粒度，基礎服務、擴充服務、應用服務，同時需要定義服務接口；
A6：網絡拓撲定義；包括定義拓撲結構、所需通信技術選擇；
A7：功能配置設定和服務部署；
A8：面向服務和面向信号的通信設計；
A9：開發（AP、CP、ROS、COTS等平台選擇）、內建、測試；
對于SOA測試對象來說，是參照一種樹形結構的方式進行測試的，如下圖所示。
首先，是需要進行整車層面分析，使得整個過程更加智能（如自動/輔助駕駛、人車監測）、更加友好（如語音控制、娛樂沖浪）、更加靈活（如功能更新）；其次，是要進行系統層面分析，包括傳統基于信号的分布式功能實作，基于高内聚低耦合的服務及服務組合實作，實作混合異構。
在下一層是進行部件層面分析，包含ECU功用和形态分析，即實作“階層”分化。首先是核心階層、大腦級，包含域控制器、計算平台多系統多處理器AP+CP，應用服務的提供者和消費者，大網關。橋梁中樞，新生代的區域控制器（VIU類），大量通信端口與IO同時存在，CP；區域網關/代理網關（S2S），兼顧區域部分控制功能，提供基本服務和擴充服務。延續過度，夾心層：底盤控制、被動安全類，典型嵌入式系統，功能安全即實時性要求高的系統；終端層包含傳感器及執行器等。
2、基于SOA服務的終端測試方法論
對于SOA的測試來說，首先需要建立和适配測試規範。我們知道，整個測試的分層包括部件、系統、實車。其中部件和系統級别包括驗證功能等行為是否與需求規範一緻；對于實車來說需要确認是否滿足使用者、法律法規等需求。
測試的關鍵是基于需求規範、使用者使用、行業法規和标準角度開發測試用例；基于經驗和場景開發測試用例和被測對象。增量和變量需求包括新車載通信技術SOME/IP、DDS、TSN、同步CAN等；新增測試類别包括服務接口測試；新增形态和載體包括服務、S2S、異構型域控/HPC、ZCU/VIU/PDC；新功能和應用場景包括個性化配置、遠端診斷、網絡/資料安全等。
整個測試規範的開發包括，新的車載通信技術測試、服務接口測試、服務“邏輯”測試。
這三大測試包括SOME/IP中的TC8的協定一緻性測試、基于自定義需求規範和配置規範，開發測試規範，源自經驗的魯棒性和場景測試；DDS中有基于自定義需求規範和配置規範，開發測試規範，如端到端延時、QoS配置不相容等；TSN中針對AS、開發測試規範及啟動、延遲、穩定性等方面的測試。服務接口測試包含基于服務接口規範開發基礎服務、擴充服務和應用服務接口定義的一緻性測試，消息時序、資料合法性和魯棒性測試。服務邏輯測試主要是按照不同層級的需求建立部件級、系統級和實車級測試規範，越向上層，測試用例複用度越高。基于SOA特點，将實作機制、應用場景相結合，在不同層級增加測試用例，如可引起資源消耗場景，端到端服務穩定性和互動響應性能測試，服務與信号轉換的性能測試。
3. 如何搭建SOA的測試環境呢？
首先，新架構下面的ECU“階層”分化，傳統“三大件”（包括底盤、車身、動力）控制模式從原始的感覺控制一體機朝向功能實作“高内聚”&“低耦合”的趨勢，軟體疊代越來越快，ICT等行業的實作技術和流程技術将更多的注入到整個變化挑戰中。
其影響是在部件級測試中，針對核心控制器的自動化測試更重要，而測試環境的複雜度取決于ECU處于何種階層。系統級測試則更為重要，環境複雜取決于功能實作方式和配置設定方案。整車級測試是對傳統大VV HIL将一定程度弱化。通常，HIL測試系統正常硬體IO的比重大幅降低，通信資源類型和數量更多，特殊需求采用特殊方案；如TSN、LVDS等專門的通信測試。而對于HIL測試系統軟體及工程開發而言，測試系統軟體的适應性、擴充性更為關鍵，這主要可以降低二次開發工作量：如對SOME/IP、DDS、HTTP、MQTT等協定支援。另一方面，仿真環境開發工作将增加：如需要搭建SOME/IP、DDS“參考ECU”的“互動行為”開環模型。對CI/CT的支援：包括系統遠端/雲端控制、實時監測和自我保護；支援被測對象的遠端刷寫和編碼；支援軟體疊代變更點與測試範圍的關聯等。
對于整個SOA測試而言，其測試手段主要包括虛拟ECU測試技術，其中需要了解實作原理、其适應對象分析、前提條件分析、實作關鍵技術建構等。同時使用汽車行業主流工具鍊對前端模型、軟體代碼進行有效測試，同時除“線上”自動化測試外，基于資料的“離線”測試也成為可選和補充。為了保證測試顆粒度更細，可以通過将測試工作前移，快速建構，适配性強，适應“适合于”汽車領域的靈活開發。
如下圖表示了針對基于SOA服務模型開發過程中，典型的服務接口測試規範執行個體。可以看出整體的SOA測試規範、步驟和需求結果。
4. 總結
本文首先對基于SOA的集中式域控制器設計邏輯、架構進行了描述，并且對于該設計将如何滿足第二部分對SOA的有效性測試進行了關聯。SOA的整個開發過程需要進行類似資料閉環，即從設計、開發到測試的整個流程都需要有完整的關聯。如果是合作開發的模式，需要厘清主機廠和供應商之間的責任界定，確定最終的測試結果滿足開發需求預期。當然，無論從開發還是測試，整個基于服務的工具鍊應該確定一緻性，避免出現邊緣化不一緻導緻的結果偏差。