?車載算力平臺的發展：功能集成度、算力需求、軟硬件復雜度、通信需求指數升高；隨著EE架構發展，逐步走向計算中央化、數據和能源區域化的形態。整車EE架構與車載算力平臺發展的瓶頸在于其簡單的邏輯處理、軟硬件不通用、應用功能固化、軟件不可迭代等不利因素，導致當前這代智能駕駛產品的應用能力無法真正適用于未來的智能汽車開發過程。對于下一代自動駕駛來說，需要強大的數據處理能力，比如使用千兆以太骨干網，5G高帶寬，AI計算平臺技術；同時，開放的API與IDE也可以將多種傳感器數據進行融合，實現數據與API的開放共享，從而擁有強大的應用管理程序APP開發集成環境。

為實現智能車載軟件的快速開發，包含面向服務的設計過程，應對不斷測試過程中出現的新場景的快速迭代，滿足客戶千人千面的需求，縮短整個汽車開發周期。此外，通過軟件的快速部署，軟硬分離，軟件重組，應用新增，實現外部資源的有效整合，增加車輛服務的豐富性。

基于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從系統設計到代碼實現模型的流程圖。

基于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、開發測試規范及啟動、延遲、穩定性等方面的測試。服務接口測試包含基于服務接口規范開發基礎服務、擴展服務和應用服務接口定義的一致性測試，消息時序、數據合法性和魯棒性測試。服務邏輯測試主要是按照不同層級的需求建立部件級、系統級和實車級測試規范，越向上層，測試用例復用度越高?；赟OA特點，將實現機制、應用場景相結合，在不同層級增加測試用例，如可引起資源消耗場景，端到端服務穩定性和交互響應性能測試，服務與信號轉換的性能測試。

如何搭建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測試規范、步驟和需求結果。

總結

本文首先對基于SOA的集中式域控制器設計邏輯、架構進行了描述，并且對于該設計將如何滿足第二部分對SOA的有效性測試進行了關聯。SOA的整個開發過程需要進行類似數據閉環，即從設計、開發到測試的整個流程都需要有完整的關聯。如果是合作開發的模式，需要分清主機廠和供應商之間的責任界定，確保最終的測試結果滿足開發需求預期。當然，無論從開發還是測試，整個基于服務的工具鏈應該確保一致性，避免出現邊緣化不一致導致的結果偏差。?