面向服務的理念在汽車電子軟件架構中的實現路線研究

朱元 蘇子鈞 徐世寒 王恩東 劉振東

【歡迎引用】 朱元， 蘇子鈞， 徐世寒， 等. 面向服務的理念在汽車電子軟件架構中的實現路線研究[J]. 汽車文摘， 2024（3）： 21-30.

【Cite this paper】 ZHU Y， SU Z J， XU S H， et al. Research on the Implementation Route of Service Oriented Concept in Automotive Electronic Software Architecture[J]. Automotive Digest （Chinese）， 2024（3）： 21-30.

【摘要】為了適應軟件定義汽車的發展趨勢并解決面向服務的架構（SOA）在汽車行業應用的適應性調整問題，首先總結了在汽車架構開發中應用SOA的環節及其優點；其次，以自動緊急制動系統軟件架構開發為例，提出一種VSOA實施路線，提出一種實施路線需求分析流程，并分析了服務劃分原則，指導了服務邏輯架構和軟件架構的建立；最后，根據服務邏輯、軟件架構、架構前瞻性，為分析案例建立一種域集中硬件通信架構，旨在促進汽車電子軟件開發中對SOA的理解和應用，為實現更靈活、可擴展的汽車軟件系統提供有益的經驗和指導。

關鍵詞：面向服務的架構（SOA）；實施路線；汽車電子軟件架構

中圖分類號：TP311.131; U46? 文獻標志碼：A? DOI： 10.19822/j.cnki.1671-6329.20230269

Research on the Implementation Route of Service Oriented Concept in Automotive Electronic Software Architecture

Zhu Yuan1， Su Zijun1， Xu Shihan1， Wang Endong2， Liu Zhendong2

（1. School of Automotive Engineering， Tongji University， Shanghai 201804; 2. Commercial Vehicle Development Institute， FAW Jiefang Automobile Co.， Ltd.， Changchun 130000）

【Abstract】 In order to adapt to the development trend of software-defined vehicles and solve the problem of service-oriented architecture， the application steps and advantages of SOA in the automotive industry is first summarized. Secondly， taking the development of software architecture of automatic emergency braking system as an example， a VSOA implementation route and an implementation route requirement analysis process are proposed. Furthermove， the service division principle is analyzed， which guides the establishment of service logic architecture and software architecture. Finally， according to the service logic， software architecture and the perspectiveness of architecture， a domain-centralized hardware communication architecture is established， which aims to promote the understanding and application of SOA in automotive electronic software development， so as so provide useful experience and guidance for the realization of more flexible and scalable automotive software systems.

Key words： Service -Oriented Architecture（SOA）， Implementation route， Automotive Electronic Software Architecture

0 引言

在汽車行業電動化、智能化、網聯化背景下，整車軟件規模和復雜度進一步提升[1-5]，對通信網絡數據量、數據速率和實時可用性提出了更高的要求[6]。汽車將成為高效的數據交互中心，并最終演變為更大的移動網絡組成部分[7-8]。以車輛為載體實現這些功能，意味著電子電氣架構必須進行范式轉變。航空業率先驗證了從分布式架構到集中式架構的可行性和優點[9]，汽車行業也已經制定從分布式架構到集中式架構的發展路線，并有部分整車企業和供應商已經將集中式解決方案商業化[10]。中央計算+區域控制是當前汽車行業公認的集中式架構發展方向，能夠最大化解耦數據發送方和接收方的依賴關系，這也為引入面向服務的架構（Service Oriented Architecture，SOA）建立了良好的實施環境[11]。近年來，汽車面向服務的架構（Vehicle Service Oriented Architecture，VSOA）能夠集中對軟件架構和通信方式進行優化。盡管SOA理念在汽車行業的重要性已經逐漸被相關研究人員和從業者接受，但對于VSOA思想未形成統一的理解，在具體實施上并未形成標準、具體的解決方案。IT行業的服務理念并不能直接適用于多平臺異構的汽車系統，對于服務粒度的定義也需要根據系統需求、車輛功能域和具體功能進行具體分析。服務內容和服務組成元素需要與電子軟件架構建立起確定性的映射，這就要求服務和整車架構在設計過程中應該相互反饋。

本文對汽車領域SOA進行了解讀，并分析VSOA的特點及其對行業產生的影響。提出了VSOA的標準化開發路線。以建立一個自動緊急制動系統為例，分解開發路線，深入分析汽車電子軟件領域中面向SOA的實施方法。分析汽車電子軟件系統的特點，展示了服務粒度劃分原則和軟件架構建立路線，并以軟件架構為例設計了決策時延評價服務?；趯祿怦?、服務實現、通信網絡復雜度等多方面考量，設計了一種域集中型環網通信架構。

1 相關工作

在軟件定義汽車的發展趨勢下，SOA成為了電子軟件架構的主要模式[12]。SOA具有清晰的軟件層次結構和可伸縮性[13-15]，使軟件質量、電子軟件架構安全性、軟件開發速率、軟件遠程更新、車內/外信息解耦等多方面得到了優化和敏捷性的提升。SOA借助于中間件能夠有效提高服務的標準化、復用性及互操作性。2011年，BMW集團在面向信號的軟件中間件—AUTOSAR Classic Platform（CP）基礎上結合以太網通信技術，將信號轉化為服務開發出面向服務的通信中間件SOME/IP（Scalable service-Oriented MiddlewarE over IP）協議，并于2013年納入AUTOSAR 4.1規范[16]。為適應和促進車輛大數據處理性能與高帶寬數據傳輸，AUTOSAR組織在2017年發布了面向服務的中間件AUTOSAR Adaptive Platform（AP）[17]，借助通信中間件SOME/IP協議完成AP和CP的服務互通，進一步提高整車數據解耦。并在2018年將數據分發服務（Data Distribution Service，DDS）納入AP規范[18]，豐富面向服務通信的實現方案。同年，Edag Group指出將以太網作為域集中架構的主干通信網絡有利于車輛全生命周期實現動態軟件更新和第三方服務的部署[19]。

在面向服務的軟件架構方面，Lotz[20]等采用SWOT分析方法，辯證地探討微服務在汽車系統中的應用，并對面向服務架構在開發、測試等環節的優缺點進行討論。Vetter[21]等基于車機游戲系統的實現，介紹了面向服務的軟件開發流程，討論了企業中軟件開發的標準流程和后續服務更新，但未形成系統性的理論和指導方案。Valls[22]等基于垂直設計方法，開發了中間件iLAND，能夠支持面向服務的分布式實時系統有限時間重構。Harald[23]和Kevin[24]等采用PREEvision和Ptolemy Ⅱ實現了電子電氣架構模型從上層軟件建模到底層硬件實現細節的動態仿真。付朝輝和王華陽[25]從用戶需求出發，指出功能架構建模能夠將功能顆粒度細化，并快速封裝為原子化服務，而功能依賴關系可以作為服務訂閱和發布機制的基礎。Marc[26]等分析了面向服務和面向信號的架構的優缺點，并提出面向服務的架構具有可移植性較強的優點，為實現可重構模塊化車輛提供了極大的便利性。Alexandru[27]等基于需求分析建立面向服務的自動駕駛軟件架構生態系統，并通過英飛凌Aurix控制器和電腦之間的消息交換驗證了互操作性，并測試了端到端延時。Peter[28]等研究了22個用于電子電氣架構不同階段開發的工具，并從功能性、兼容性、可用性、分發性4個方面詳細分析了各工具的特點，為電子電氣架構開發提供了有力指導。

SOA相比較傳統面向信號的通信模式，主要區別在于通信路徑可以實現動態配置，避免節點加載不必要的數據流，能夠支持AP和CP之間的互操作性[4]。并且對實現方式和通信載體都沒有硬性要求，SOME/IP或DDS[29]是當前主流的實現方式，而傳統的CAN總線難以承載上述協議，因此現階段將以太網作為通信載體。SOME/IP和DDS不僅是通信協議，同時也是通信中間件。SOME/IP被認為是一種非常有前途的SOA通信中間件，但它不包括任何保護應用程序和傳輸數據免受惡意攻擊的安全功能[30]。而DDS大量的服務質量（Quality of Service， QoS）機制為數據訪問、加密、認證等多方面提供安全保障[31]。另一方面，大量的QoS也提升了DDS體量，必須裁剪后才能用于AP平臺，在CP平臺需要借助復雜驅動進行定制化開發，從應用角度來說違背了AUTOSAR和面向服務中可重用性的初衷。2者都支持遠程過程調用（Remote Procedure Call， RPC），提高服務的重用性和靈活性。

2 汽車電子軟件領域SOA概述

2.1 服務的概念

面向服務的體系結構由服務、執行服務的機器以及連接這些機器的網絡組成[32]。服務的概念來源于互聯網，其本義是將應用程序功能抽象成能夠作為與服務消費者相關粒度發布的服務集的形式，來提供和使用策略、實踐和框架。使用單一的、基于標準化的接口形式從實現中抽象出可以調用、發布和發現的服務[33]。

一個完整的服務應當具備服務本身（服務的內容）、服務接口以及構成服務的相關角色。服務的內容是一個離散的功能單元，根據服務定義粒度的不同能夠實現服務的獨立執行和遠程訪問；信息通過服務接口與外界建立聯系，但服務接口與底層通信介質無關；在圖1中，SOME/IP實現面向服務的通信展現了一個服務交互的角色集合，包括服務提供方、消費方和代理方。服務的提供方通過代理方注冊服務信息，而服務的消費方在代理方進行服務查找和訂閱。一旦服務的消費方和提供方成功匹配，就能夠進行有效的通信。這種服務交互的方式通過引入代理方，實現了服務的動態發現和訂閱機制。服務提供方將服務信息注冊到代理方，服務消費方通過代理方查詢并訂閱所需服務。這個過程的協同性和靈活性使得系統更加適應復雜多變的汽車電子系統中的服務交互需求。這一體系結構使得服務的提供方和消費方能夠在運行時動態地協商和建立連接，為整個系統的可擴展性和可維護性提供了堅實基礎。代理方的引入不僅簡化了服務交互的管理，還提高了系統的可靠性和靈活性。這種角色集合的協同作用使汽車電子系統的服務通信更高效、更智能。

2.2 汽車軟件SOA的特點

SOA是一種面向服務的架構，它通過標準化的服務接口、松耦合的服務機制以及可擴展性的服務特性，使得軟件具有高度靈活性。在汽車領域，SOA的核心是通過標準化、獨立性、松耦合使軟件具有高度靈活性。標準化是指每個服務之間應具有清晰的邊界，并保留標準化接口以便其他模塊在進行功能變更或升級時進行訂閱；獨立性是指每個服務之間應相互獨立且唯一，避免軟件在實現任務層面的冗余；松耦合是指服務應獨立于車型、硬件平臺，甚至于操作系統和開發語言，提高軟件開發的效率及靈活性[34]。SOA的優勢在于提高了業務靈活性、上市速度、可復用性、可伸縮性、安全永續性以及改善了業務與IT之間的協作。SOA的核心要素是服務，每個服務組件具備獨立的功能，且可被復用；服務組件之間的接口遵循統一標準，可互相訪問，可組合擴展。

AUTOSAR組織在面向信號的CP中引入服務的思想，實現了接口標準化。SOME/IP協議在CP的基礎上引入面向服務的通信理念，實現信號到服務實例的轉換。在面向服務構建了AP之后，CP和AP能夠以統一的面向服務的通信中間件實現數據交互。

在服務的獨立性和松耦合方面，AUTOSAR平臺的軟件分層結構降低了軟件與軟件間、軟件與硬件間的耦合度。在CP中，軟件組件（SoftWare Component，SWC）之間的數據交互通過虛擬功能總線（Virtual Functional Bus，VFB）實現，雙方只需要留出標準接口，不需要知道其他信息。在AP中，自適應應用運行時環境（AUTOSAR Runtime for Adaptive application，ARA）為SWC預留了服務集合接口，上層應用通過調用ARA服務實現業務內容。算法主體部署在完成接口配置的SWC中，算法工程師能夠將工作重點集中在算法內容的開發。在通信過程中，SOA通過通信中間件在系統啟動時建立通信路徑，調用底層服務定義數據序列化。與面向信號的通信方式具有靜態的通信矩陣不同，服務可以動態的建立，不會對其他服務交互產生干擾。在冗余設計場景下，一個客戶端具有多個相同的服務源，當原始服務源失效時能夠通過服務代理獲取替代服務端，提高失效安全性。

面向SOA的軟件架構開發，利用服務的高內聚和低耦合，實現軟件的全生命周期管理。服務的開發、部署、測試、標定和升級，由獨立的團隊和服務接口配置的SWC完成[35]。團隊只需在開發階段，與相關的服務團隊溝通，定義服務內容和依賴關系。后續的工作都在團隊內部進行。如圖2所示，功能模塊分解為粗粒度和細粒度的服務，適應不同產品的需求變化。新增細粒度服務，不影響原有服務，便于軟件組件的開發。功能升級和擴展也更高效，重用原有資源[36]。

圖2中原子服務的范圍由對應的硬件功能決定，在完備的原子服務集合上，合理的組合與劃分服務邊界，能夠實現服務高效復用和靈活的功能分配。組合服務集合中的角色不限于原子服務，也不限于服務部署位置。原子服務可以在獨立的測試環境中完成開發-測試-反饋閉環，減少了對其他組件的依賴。原子服務綜合到組合服務、應用服務中進行測試，有利于故障發現與定位，提高測試效率和全面性。

根據業務功能的定義可以衍生出流程服務的概念，流程服務是組合服務的一種，它基于服務邏輯關系或業務內容，系統調用多個原子服務及組合服務。

3 SOA在汽車中的實現

面向服務的架構可以通過自上而下/自下而上2種建模路線實現。自上而下的路線需要結合功能特性以及系統的需求、用例和邏輯功能架構等，以系統功能的描述手段作為輸入，指導軟件架構和硬件架構的建立；自下而上的路線以原有架構為基礎，分析服務實現方案，并在服務開發到部署的過程中對原有架構進行適應性改動。

3.1 實施路線圖

自上而下/自下而上的建模路線并非是對立的，在建模過程中可以靈活運用2種建模路線，實現“中間相遇”，平衡需求實現和架構資源。本文基于SOME/IP實現面向服務通信的方法論，根據面向服務的架構開發經驗，提出如圖3所示的SOA開發路線。該路線實現了需求到電子軟件架構的轉換，具有用例驅動和面向服務2個特點，前者指導需求分析，后者指導軟件架構建模。用例驅動是指從系統外部觀察系統的使用場景、使用方法、功能體現等方面，建立起需求和系統功能邏輯之間的追溯關系。

本文將采用PREEvision開發一款AEB系統的電子軟件架構。PREEvision是一款專業的汽車電氣/電子（E/E）系統工程工具，由 Vector Informatik公司開發，主要用于支持整個汽車E/E架構的設計、開發和驗證。PREEvision不僅能夠建模整個E/E系統，還能夠針對通信協議進行配置管理，包括對從CAN、LIN到現代的以太網通信，以太網通信中目前支持SOME/IP的靈活配置，使工程師能有效管理系統中不同部分之間的通信[37]。因此，本文選擇PREEvision來進行SOA建模。將上述SOA方案解構為需求分析、服務邏輯分析、軟件架構建模、硬件及通信架構建模4個方面分析面向SOA的實施方案。

選擇AEB系統進行建模是因為該系統包含人機交互、環境感知、底盤控制等方面，能夠涵蓋車輛高級駕駛輔助系統、車身、底盤3個主要功能域。軟件平臺需要AP和CP的支持，包含了面向服務的軟件架構和面向信號的軟件架構。本文以該系統為例，在建模前對AEB系統提出以下假設，簡化建模環節：

（1）假設硬件架構末端節點（部件）均為電子控制單元（Electronic Control Unit，ECU），并且ECU中能夠部署CP平臺；

（2）假設障礙物為車輛時，T-Box能夠獲取C2C信息；

（3）假設AEB系統默認開啟。

3.2 實施方案—AEB系統SOA實施方案

需求的提出到需求的實現需要經過3個階段：需求生成、需求分析、確定需求。需求主要來源于用戶調研、用例分析、競品分析，以及從功能安全和信息安全的角度對系統功能提出具體要求。采用專業語言對需求進行描述，研究當前需求的前置需求和子需求，挖掘潛在需求。在需求分析階段，從安全性、用戶偏好、競品熱度等方面對需求進行優先級排序，保證高優先級的需求首先得到實施。根據外部對需求的反饋評估需求的可實現性，將需求定位到功能實施實體或對應的實施環節中，分析實施實體和實施環節是否存在潛在需求。最后確定需求內容，指導服務邊界、電子軟件架構的建立。

根據所提出需求分析路線對AEB系統展開需求分析，確定出以下需求：

（1）應使用多傳感器融合來感知前方的障礙物。

a. 視覺信號可以通過傳感系統獲取。

b. 傳感系統應配備中程毫米波雷達。

c. 可以識別障礙物的類型。

d. 如果障礙物的類型是車輛，則傳感系統可以從T-Box獲取車對車（C2C）信息。

e. 無論可以獲得什么C2C信息，都可以通過傳感融合來計算相對速度和距離。

（2）系統根據環境信息和主車輛信息進行不同級別的響應。

a. 車門未關閉或乘客未系安全帶時，不得啟動制動。

b. 自動緊急制動（AEB）和制動輔助需要ESC和ABS的支持。如果ESC關閉或ABS出現故障，則不應啟動制動器。

（3）系統應具有安全距離報警模式（需求2的擴展）。

a. 只有當速度大于65 km/s時，此模式才能激活。

b. 當車輛間距小于安全距離時，激活報警。報警應包括語音提示和儀表盤提示。

（4）系統應具有制動輔助模式（需求2的擴展）。

a. 當前制動力不足且速度大于30 km/s時，制動輔助啟動。

b. 制動輔助模式應減少對駕駛員的干擾，提高非致敏性。報警僅包括儀表盤提示。

（5）系統應具有AEB模式（需求2的擴展）。

a. 當系統檢測到碰撞風險且速度大于30 km/s時，激活此模式。

b. 此模式下的報警應為高強度報警。報警應包括語音提示和儀表盤提示，并具有方向盤抖動。

c. 此模式激活時，制動燈應點亮。

完成需求分析后，需要根據需求內容分析服務邏輯，并建立服務邏輯結構。從需求中能夠得知AEB系統需要感知設備獲取環境信息，并結合ESC、ABS、制動踏板等提供的主車狀態信息進行系統介入決策。介入時需要座艙模塊進行介入提示完成人機交互，同時需要獲取車門、安全帶狀態等車身信息，判斷是否滿足制動實施條件。制動階段需要ESC&ABS實現AEB計算出的期望制動力。首先根據以上信息構建出系統工作的邏輯草圖如圖4所示。

底盤控制算法具有硬實時要求，部署在面向信號的AUTOSAR CP平臺上。ADAS 域和座艙域需要大數據并行處理，部署在AUTOSAR AP平臺上。CP平臺軟件層可以沿用面向信號的設計方法，也可以面向服務重新構建，設計服務架構時需要考慮服務和信號的轉換。

在信號服務化的過程中應當注意服務的內容是由信號抽象而來，還是由對象所提供的響應抽象而來。比如，將制動信號抽象為服務，服務的提供方是制動信號的發送方，消費方是制動信號的接收方（制動器）；而把制動這一動作抽象為服務，服務的提供方是制動器，制動信號的來源請求制動器提供服務。2種方案從原理上而言，需要不同的服務實現方式（方法或者事件）。從具體實現上而言，底盤相關模塊采用信號抽象為服務的方式更符合控制系統行為，也能有利于軟件開發人員邏輯展開。

服務粒度的定義可以來源于需求，以ADAS域中的服務分析，需求3、需求4、需求5回答了需求2對于AEB系統應具有不同工作模式的描述。將ADAS服務拆分為傳感器融合、車輛狀態計算與決策、AEB控制系統3個子服務，需求3、需求4、需求5對應著AEB控制服務下的細粒度組合服務。需求3中對安全距離計算提出了需求，安全距離計算包含在車輛狀態計算與決策服務中，可以通過給定的輸入返回確定的計算結果，因此可以將安全距離計算定義為原子服務。即一個應用服務除外部輸入服務以外，如式（1）：

式中：[Snp]為應用服務，[Su1m]為[Snp]下的元服務，[Svc]為[Snp]下的組合服務，[Su2m]為[Svc]下的元服務，[Sv2cs]為[Svc]下的子組合服務。

根據服務的粒度，子組合服務下可以存在更細粒度的組合服務和元服務。服務的粒度并非越細越好，需要根據服務內容進行合理分析，盲目劃分服務粒度會給服務架構的全生命周期管理帶來麻煩。

根據以上分析可以按照如圖2所示粒度劃分原則，定義ADAS域中的服務粒度如圖5所示。

將ADAS域中服務的分析方法擴展到AEB系統的完全實現，可以得出如圖6所示的服務架構。圖中CockpitSensorStatus（駕駛艙傳感器狀態）框中，Cockpit_Ctrl（駕駛艙控制）為服務消費方，CockpitSensorProcess（駕駛艙傳感器處理）為服務提供方，虛線用來映射端口角色。

為了更直觀的表達，服務架構中重用了部分接口，而在軟件架構建模時需要對一些接口進行拆分使服務邊界清晰化。

圖6中將服務按照功能域劃分并建立服務間的邏輯關系（展示座艙部分），可以看作是邏輯草圖（圖4）的擴展。服務邏輯架構采用服務語言為數據交互的端口劃分了不同的角色，并采用了不同的服務實現方式。例如，系統需要獲取語音報警服務時，由Cockpit_Ctrl（駕駛艙控制）向Cockpit_Voice（駕駛艙音量）請求獲取服務，語音服務并不需要Cockpit_Voice提供狀態反饋，因此以FF-方法的方式實現。而SensorFuse（傳感器融合）請求T-Box服務時需要從T-Box獲取數據，因此要以RR-方法的方式實現。SensorFuse獲取底盤傳感器數據時，服務的內容是ChassisSigProcess（底盤信號處理）的計算結果，因此ChassisSigProcess將目標信號包裝為服務，以事件的形式實現服務。圖7更加直觀的描述了RR-方法、FF-方法、事件的區別。

在SOA軟件架構中，弱化了軟件組件和硬件單元的映射關系，部署在不同ECU的軟件組件可以通過方法實現RPC，提高了軟件組件的可伸縮性。

在軟件架構中可以將QoS在開發到后續升級的任意環節作為服務被引入軟件架構中，這也體現了面向服務的靈活性。端到端延遲一定程度上決定著應用的性能，在AEB系統中出于功能安全的考慮，從傳感器傳出數據到決策系統提供決策結果這一環節產生的時延對AEB系統的安全性、有效性具有至關重要的作用，因此引入AEB決策時延評價服務。假設車身模塊不會干擾決策結果，將上述環節簡化為圖8，并增加時間戳。圖中[Ts1]、[Ts2]、[Ts3]、[Ts4]分別為第一個傳感器信號發出時、最后一個傳感器信號發出時、傳感器信號融合結果輸出時、決策結果輸出時的全局時鐘時間戳。

為[Ts1]到[Ts4]的時間間隔[tI4，1]設置如式（2）所示的約束。

式中：[Δtmax]為設置的時間間隔閾值。

為避免QoS對AEB系統產生影響，式（2）中的約束為軟約束。當[tI4，1>kΔtmax]時，觸發[tI4，1]記錄器。記錄器采集[R=tI，04，1，tI，14，1，…，tI，m4，1]，分析[R]的正態分布峰值點坐標[tnp4，1]，若[tnp4，1]滿足式（3）時，認為AEB服務具有不可靠性，并停用AEB制動服務。

之后，AEB決策時延評價服務會一直運行記錄器[R]，當連續[δ]個記錄周期[R]滿足式（4），則重新啟用AEB制動服務。

4 域集中式硬件通信架構

汽車電子電氣架構在近年來經歷了從分布式架構到功能域架構的升級，許多研究機構正在攻克下一代域集中架構的關鍵技術。如果說基于功能域的架構相比較分布式架構體現出了高運算能力、高數據解耦程度、簡化線束等優點，域集中架構可以看作在功能域架構基礎上再次進行升級，并確定了以太網作為主干網絡的地位。中央高性能計算機作為整車的大腦，集整車數據中心、中央網關、中央控制單元、中央處理單元于一體，而區域控制器承擔起區域網關、區域配電、區域功能驅動的角色。與僅提供靜態通信的CAN總線相比，以太網和IP的使用有利于實現動態的面向服務的通信。域集中式架構為SOA提供了良好的開發和部署環境，在SOA的加持下能夠進一步提升整車數據解耦程度，實現軟硬件的高效復用。

上文在服務架構中將AEB服務邏輯劃分為底盤域、ADAS域、座艙域，并依此將服務映射到軟件架構中。底盤域控制算法的特點在于根據確定類型的數據輸入，產生確定性的輸出響應。一般具有較大體量的邏輯運算結構，通常不需要支持復雜的圖形界面和圖像、信號處理能力，因此底盤域的算法被廣泛布置在微控制器（Microcontroller Unit，MCU）中。ADAS域需要進行復雜的圖像處理、傳感器信號融合運算、復雜決策和規劃，往往需要運算單元具有強大的并行浮點運算能力。座艙域需要支持人機交互、圖形界面，同樣具有多任務并行處理的特點。因此將ADAS域、座艙域布置在微處理器（Microprocessor Unit，MPU）中。MPU和MCU及中央交換機可以通過板上總線連接，實現低延時通信。

分布在車身各位置的傳感器、ECU、執行器等由區域控制器采用控制器局域網絡（CAN）、串行通信網絡（LIN）、通用串行總線（USB）、以太網（Ethernet）等多種通信方式就近連接（本文構建的硬件模型中僅采用了CAN、USB的連接方式），區域控制器主要承擔區域網關的任務，Ethernet實現中央高性能計算機到各區域控制器的主干通信網。根據以上分析，本文構建出如圖9所示的域集中環網通信網絡。

環網架構的優點在于能夠自動選取負載較小的路由路線實現數據傳輸，并且在主干網絡發生損壞時仍能保證通信系統正常工作。設從中央 Switch發出的數據流[SFL]、[SFR]、[SRL]、[SRR]的終點分別為對應的區域控制器，而每段Ethernet承載的數據流為[S1]、[S2]、[S3]、[S4]、[S5]，當Ethernet發生故障時，主干通信網上的數據流如式（5）所示。

圖9中還提供了其他的主干通信網連接變體，在采用Connection variant后可以形成雙環網通信架構，能夠進一步降低Ethernet ①、②的負載，并能夠提供更多的信號路由方式。

在進行信號路由之前，需要將SWC映射到域集中硬件通信架構。算法主體將部署到中央高性能計算機，傳感器/執行器相關服務映射網絡末端節點ECU中。以實現RR Brake Light 服務為例，路由路線起點為座艙 MPU，經過中央 Switch、FR Switch、RR Switch到達RR Zone，區域控制器承擔網關的角色，通過CAN發送點亮右后制動燈的信號。

5 總結與展望

本研究結果揭示了汽車行業在采用面向服務的架構時所面臨的挑戰和機遇。通過對IT行業和汽車行業服務思想的比較分析，以及對汽車行業SOA特點和優點的梳理，明確了汽車行業在應用SOA時需要進行適應性調整的問題。在此基礎上，提出了一種VSOA實施路線，以指導汽車行業如何更好地實現面向服務的架構。通過該實施路線，解決了汽車行業在應用SOA時可能遇到的理論和實際問題，為汽車電子軟件架構的發展提供了重要的理論支持和實踐指導。針對汽車行業SOA的特點和優點進行了深入梳理，在此過程中，本研究通過需求分析流程、服務劃分原則等方面的改進和補充，對前人觀點進行了進一步的豐富和發展。因此，本研究結果與前人的一致之處在于對汽車行業SOA的重要性和潛在應用進行了肯定，而不一致之處則在于提出了全新的實施路線和改進方案，以填補前人研究的空白和不足。雖然本文提出了VSOA的實施路線，但對于其中涉及的關鍵技術（如全生命周期管理方案、面向服務的通信中間件等）探索不夠深入，需要進一步研究和完善。在全生命周期管理方面需要根據汽車電子軟件架構的特點設計管理方案，避免架構腐化。在通信方面，面向服務的通信協議如何與時間敏感網絡結合以提高實時性，以及需要根據面向服務的通信邏輯定制信息安全方案。通過進一步的研究和探索，可以不斷完善VSOA實施路線，提高其在汽車電子軟件架構中的實用性和適應性，推動汽車行業SOA的發展和應用。

參 考 文 獻

[1] ZANTEN A T V， ERHARDT R， LANDESFINED K， et al. VDC Systems Development and Perspective[J/OL]. SAE Technical Paper， 1998（2024-02-02）. https：//doi.org/10.4271/980235.

[2] BROY M， KRUGER I H， PRETSCHNER A， et al. Engineering Automotive Software[J]. Proceedings of the IEEE， 2007（2）： 95.

[3] VINAY R， HANUMANTHU B， et al. Assessing the Impact of Migration from SOA to Microservices Architecture[J]. SN Computer Science， 2023， 4（5）： 577.

[4] LOB L， MARIANI R， MUBEEN S， et al. Recent Advances and Trends in On-Board Embedded and Networked Automotive Systems[J]. IEEE Transactions on Industrial Informatics， 2019， 15（2）： 1038-1051.

[5] HADI A， MORTEZA H F， ALOIS K， et al. E/E Architecture Synthesis： Challenges and Technologies[J]. Electronics， 2022， 11（518）： 518

[6] NAVALE V M， KYLE W， ATHANASSIOS L， et al. （R）evolution of E/E Architectures[J]. SAE International Journal of Passenger Cars—Electronic and Electrical Systems， 2015， 8（2）： 2015-01-0196.

[7] APOSTU S， BURKACKY O， DEICHMANN J， et al. Automotive software and electrical/electronic architecture： Implications for OEMs[J]. McKinsey Insights， 2019（2023-12-30）. https：//www.mckinsey.com/industries/automotive-and-assembly/our-insights/automotive-software-and-electrical-electronic-architecture-implications-for-oems.

[8] JIANG S. Vehicle E/E Architecture and Its Adaptation to New Technical Trends[J]. SAE Technical Paper， 2019： 2019-01-0862.

[9] WATKINS C B， RANDY W. Transitioning from federated avionics architectures to integrated modular avionics [C]//2007 IEEE/AIAA 26th Digital Avionics Systems Conference. Dallas， TX， USA： IEEE， 2007.

[10] VICTOR B， GEHAN S， VERA P， et al. Mark Lawford.Making the Case for Centralized Automotive E/E Architectures[J]. IEEE Transactions on Vehicular Technology， 2021， 70（2）： 1230-1245 .

[11] TRAUB M， MAIER A， BARBEHON K， et al. Future automotive architecture and the impact of IT trends[J]. IEEE Software， 2017， 34（3）： 27-32.

[12] SCHULTE W R， NATIS Y. "Service Oriented" Architectures[J].? Wiley Interdisciplinary Reviews： Computational Statistics， 1996， 1（1）： 101-105.

[13] NIKNEGAD N， ISMAIL W， GHANI I， et al. Understanding Service-Oriented Architecture （SOA）： A systematic literature review and directions for further investigation[J]. Information Systems， 2020， 91： 101491

[14] PLESSIS J J D ， MWALEMBA G， et al. Adoption of emerging technologies into ERP systems landscape： A South African study[C]//IEEE International Conference on Emerging Technologies & Innovative Business Practices for the Transformation of Societies. IEEE， 2016.

[15] Emadi S， Hanza R H. Critical Factors in the Effective of Service-Oriented Architecture[J]. Advances in Computer Science An International Journal， 2013（3）： 14388143.

[16] AUTOSAR. Release 4.1 Overview and Revision History[EB/OL]. 2015（2023-12-30）. https：//www.autosar.org/fileadmin/user_upload/standards/classic/4-1/AUTOSAR_TR_ReleaseOverviewAndRevHistory.pdf， 2015.

[17] AUTOSAR. Adaptive Platform Release Overview[EB/OL]. 2017（2023-12-30）. https：//www.autosar.org/fileadmin/user_upload/standards/adaptive/1703/AUTOSAR_TR_AdaptivePlatformReleaseOverview.pdf， 2017.

[18] AUTOSAR. AUTOSAR Adaptive Platform Release Overview[EB/OL]. 2018（2023-12-30）. https：//www.autosar.org/standards/adaptive-platform/adaptive-platform-1803/， 2018.

[19] MARIO M ，GERHARD B ，ULRICH B， et al. Service-oriented EE zone architecture key elements for new market segments[J]. ATZelektronik worldwide， 2018， 13（1）： 36-41 .

[20] LOTZ J， VOGELSANG A， BENDERIUS O， et al. Microservice Architectures for Advanced Driver Assistance Systems： A Case-Study[C]// 2019 IEEE International Conference on Software Architecture Companion （ICSA-C）. Hamburg， Germany： IEEE， 2019.

[21] ANDREAS V， PHILIPP O， HOUSSEM G， et al. Marcel Rumez.Development Processes in Automotive Service-oriented Architectures[C]//2020 9th Mediterranean Conference on Embedded Computing （MECO）. Budva， Montenegro： MECO， 2020.

[22] MARISOL G V， LOPEZ I R， VILLAR L F. iLAND： An Enhanced Middleware for Real-Time Reconfiguration of Service Oriented Distributed Real-Time Systems[J]. IEEE Transactions on Industrial Informatics， 2013， 9（1）： 228-236.

[23] BUCHER H， REICHMANN C， BECKER J. An Integrated Approach Enabling Cross-Domain Simulation of Model-Based E/E-Architectures[J]. SAE Technical Paper， 2017： 2017-01-0006.

[24] KEVIN N， MARCEL R， TREMMEL H， et al. Virtual Verification of E/E Architectures for Secure Automated Driving Functions[C]//2021 IEEE International Symposium on Systems Engineering （ISSE）. Vienna， Austria： IEEE， 2021.

[25] WU H Z ，WANG Q ，WU Z H ， et al. Multi-Material Additively Manufactured Magnetoelectric Architectures with a Structure-Dependent Mechanical-to-Electrical Conversion Capability[J]. Small methods， 2022， 6（12）： e2201127 .

[26] MARC S， HANNES S， HOUSSEM G， et al. A Comparison of Architecture Paradigms for Dynamic Reconf?gurable Automotive Networks[C]//2022 International Conference on Connected Vehicle and Expo （ICCVE）. Lakeland， FL， USA： 2022.

[27] KAMPMANN A， ALRIFAEE B， KOHOUT M， et al. A Dynamic Service-Oriented Software Architecture for Highly Automated Vehicles[C]//International Conference on Intelligent Transportation Systems. Auckland， New Zealand： IEEE， 2019.

[28] WASZECKI P， LUKASIEWYCZ M， MASRUR A， et al. How to engineer tool-chains for automotive E/E architectures？[J]. Acm Sigbed Review， 2013， 10（4）： 6-15.

[29] Object Management Group. Data Distribution Service[EB/OL]. 2015（2023-12-30）. https：//www.omg.org/spec/DDS/1.4/PDF， 2015.

[30] ZUO Z， YANG S C， MA B， et al. Design of a CANFD to SOME/IP Gateway Considering Security for In-Vehicle Networks[J]. Sensors， 2021， 21（23）： 7917.

[31] RUMEZ M， GRIMM D， KRIESTEN R， et al. An Overview of Automotive Service-Oriented Architectures and Implications for Security Countermeasures[J/OL]. IEEE Access， 2020（2023-12-30）. https：//www.researchgate.net/publication/347178480_An_Overview_of_Automotive_Service-Oriented_Architectures_and_Implications_for_Security_Countermeasures.

[32] DI N M， SANGIOVANNI-VINCENTELLI A L. Moving From Federated to Integrated Architectures in Automotive： The Role of Standards， Methods and Tools[J]. Proceedings of the IEEE， 2010， 98（4）： 603-620.

[33] NIKNEJAD N， ISMAIL W， GHANI I， et al. Understanding Service-Oriented Architecture （SOA）： A systematic literature review and directions for further investigation[J]. Information Systems， 91（7）： 101491.

[34] ANDREAS P， MARCEL R， DANIEL G， et al. Generic Patterns for Intrusion Detection Systems in Service-Oriented Automotive and Medical Architectures[J]. Journal of Cybersecurity and Privacy， 2022， 2（37）： 731-749.

[35] DUC M L， DANIEL L， ARMAN S， et al. An Empirical Study of Architectural Decay in Open-Source Software[C]//2018 IEEE International Conference on Software Architecture （ICSA）. Seattle， WA， USA： IEEE， 2018.

[36] BEHERE S， TORNGREN M. A functional reference architecture for autonomous driving[J]. Information and Software Technology， 2016， 73（5）： 136-150.

[37] SCHAUFFELE J. E/E Architectural Design and Optimization using PREEvision[J]. SAE Technical Paper， 2016： 2016-01-0016.

（責任編輯 明慧）

【作者簡介】

朱元（1976—），男，同濟大學，博士，副教授，研究方向為新能源汽車電機控制技術、汽車電子嵌入式軟件、智能駕駛多傳感器融合技術。

E-mail：yuan.zhu@#edu.cn

蘇子鈞（1998—），男，同濟大學，碩士研究生，研究方向為汽車電子嵌入式軟件。

E-mail：1070548611@qq.com

徐世寒（1997—），男，同濟大學，博士研究生，研究方向為新能源汽車電機控制技術、汽車電子嵌入式軟件。

E-mail：sh_xu@#edu.cn

王恩東（1991—），男，一汽解放汽車有限公司，工程師，研究方向為汽車電子嵌入式基礎軟件技術。

E-mail：wangendong1@rdc.faw.com.cn

劉振東（1992—），男，一汽解放汽車有限公司，助理工程師，研究方向為汽車電子嵌入式基礎軟件技術。

E-mail：liuzhendong@rdc.faw.com.cn