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

【歡迎引用】 朱元， 蘇子鈞， 徐世寒， 等. 面向服務(wù)的理念在汽車電子軟件架構(gòu)中的實(shí)現(xiàn)路線研究[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.

【摘要】為了適應(yīng)軟件定義汽車的發(fā)展趨勢(shì)并解決面向服務(wù)的架構(gòu)（SOA）在汽車行業(yè)應(yīng)用的適應(yīng)性調(diào)整問題，首先總結(jié)了在汽車架構(gòu)開發(fā)中應(yīng)用SOA的環(huán)節(jié)及其優(yōu)點(diǎn)；其次，以自動(dòng)緊急制動(dòng)系統(tǒng)軟件架構(gòu)開發(fā)為例，提出一種VSOA實(shí)施路線，提出一種實(shí)施路線需求分析流程，并分析了服務(wù)劃分原則，指導(dǎo)了服務(wù)邏輯架構(gòu)和軟件架構(gòu)的建立；最后，根據(jù)服務(wù)邏輯、軟件架構(gòu)、架構(gòu)前瞻性，為分析案例建立一種域集中硬件通信架構(gòu)，旨在促進(jìn)汽車電子軟件開發(fā)中對(duì)SOA的理解和應(yīng)用，為實(shí)現(xiàn)更靈活、可擴(kuò)展的汽車軟件系統(tǒng)提供有益的經(jīng)驗(yàn)和指導(dǎo)。

關(guān)鍵詞：面向服務(wù)的架構(gòu)（SOA）；實(shí)施路線；汽車電子軟件架構(gòu)

中圖分類號(hào)：TP311.131; U46? 文獻(xiàn)標(biāo)志碼：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 引言

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

本文對(duì)汽車領(lǐng)域SOA進(jìn)行了解讀，并分析VSOA的特點(diǎn)及其對(duì)行業(yè)產(chǎn)生的影響。提出了VSOA的標(biāo)準(zhǔn)化開發(fā)路線。以建立一個(gè)自動(dòng)緊急制動(dòng)系統(tǒng)為例，分解開發(fā)路線，深入分析汽車電子軟件領(lǐng)域中面向SOA的實(shí)施方法。分析汽車電子軟件系統(tǒng)的特點(diǎn)，展示了服務(wù)粒度劃分原則和軟件架構(gòu)建立路線，并以軟件架構(gòu)為例設(shè)計(jì)了決策時(shí)延評(píng)價(jià)服務(wù)?；趯?duì)數(shù)據(jù)解耦、服務(wù)實(shí)現(xiàn)、通信網(wǎng)絡(luò)復(fù)雜度等多方面考量，設(shè)計(jì)了一種域集中型環(huán)網(wǎng)通信架構(gòu)。

1 相關(guān)工作

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

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

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

2 汽車電子軟件領(lǐng)域SOA概述

2.1 服務(wù)的概念

面向服務(wù)的體系結(jié)構(gòu)由服務(wù)、執(zhí)行服務(wù)的機(jī)器以及連接這些機(jī)器的網(wǎng)絡(luò)組成[32]。服務(wù)的概念來源于互聯(lián)網(wǎng)，其本義是將應(yīng)用程序功能抽象成能夠作為與服務(wù)消費(fèi)者相關(guān)粒度發(fā)布的服務(wù)集的形式，來提供和使用策略、實(shí)踐和框架。使用單一的、基于標(biāo)準(zhǔn)化的接口形式從實(shí)現(xiàn)中抽象出可以調(diào)用、發(fā)布和發(fā)現(xiàn)的服務(wù)[33]。

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

2.2 汽車軟件SOA的特點(diǎn)

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

AUTOSAR組織在面向信號(hào)的CP中引入服務(wù)的思想，實(shí)現(xiàn)了接口標(biāo)準(zhǔn)化。SOME/IP協(xié)議在CP的基礎(chǔ)上引入面向服務(wù)的通信理念，實(shí)現(xiàn)信號(hào)到服務(wù)實(shí)例的轉(zhuǎn)換。在面向服務(wù)構(gòu)建了AP之后，CP和AP能夠以統(tǒng)一的面向服務(wù)的通信中間件實(shí)現(xiàn)數(shù)據(jù)交互。

在服務(wù)的獨(dú)立性和松耦合方面，AUTOSAR平臺(tái)的軟件分層結(jié)構(gòu)降低了軟件與軟件間、軟件與硬件間的耦合度。在CP中，軟件組件（SoftWare Component，SWC）之間的數(shù)據(jù)交互通過虛擬功能總線（Virtual Functional Bus，VFB）實(shí)現(xiàn)，雙方只需要留出標(biāo)準(zhǔn)接口，不需要知道其他信息。在AP中，自適應(yīng)應(yīng)用運(yùn)行時(shí)環(huán)境（AUTOSAR Runtime for Adaptive application，ARA）為SWC預(yù)留了服務(wù)集合接口，上層應(yīng)用通過調(diào)用ARA服務(wù)實(shí)現(xiàn)業(yè)務(wù)內(nèi)容。算法主體部署在完成接口配置的SWC中，算法工程師能夠?qū)⒐ぷ髦攸c(diǎn)集中在算法內(nèi)容的開發(fā)。在通信過程中，SOA通過通信中間件在系統(tǒng)啟動(dòng)時(shí)建立通信路徑，調(diào)用底層服務(wù)定義數(shù)據(jù)序列化。與面向信號(hào)的通信方式具有靜態(tài)的通信矩陣不同，服務(wù)可以動(dòng)態(tài)的建立，不會(huì)對(duì)其他服務(wù)交互產(chǎn)生干擾。在冗余設(shè)計(jì)場(chǎng)景下，一個(gè)客戶端具有多個(gè)相同的服務(wù)源，當(dāng)原始服務(wù)源失效時(shí)能夠通過服務(wù)代理獲取替代服務(wù)端，提高失效安全性。

面向SOA的軟件架構(gòu)開發(fā)，利用服務(wù)的高內(nèi)聚和低耦合，實(shí)現(xiàn)軟件的全生命周期管理。服務(wù)的開發(fā)、部署、測(cè)試、標(biāo)定和升級(jí)，由獨(dú)立的團(tuán)隊(duì)和服務(wù)接口配置的SWC完成[35]。團(tuán)隊(duì)只需在開發(fā)階段，與相關(guān)的服務(wù)團(tuán)隊(duì)溝通，定義服務(wù)內(nèi)容和依賴關(guān)系。后續(xù)的工作都在團(tuán)隊(duì)內(nèi)部進(jìn)行。如圖2所示，功能模塊分解為粗粒度和細(xì)粒度的服務(wù)，適應(yīng)不同產(chǎn)品的需求變化。新增細(xì)粒度服務(wù)，不影響原有服務(wù)，便于軟件組件的開發(fā)。功能升級(jí)和擴(kuò)展也更高效，重用原有資源[36]。

圖2中原子服務(wù)的范圍由對(duì)應(yīng)的硬件功能決定，在完備的原子服務(wù)集合上，合理的組合與劃分服務(wù)邊界，能夠?qū)崿F(xiàn)服務(wù)高效復(fù)用和靈活的功能分配。組合服務(wù)集合中的角色不限于原子服務(wù)，也不限于服務(wù)部署位置。原子服務(wù)可以在獨(dú)立的測(cè)試環(huán)境中完成開發(fā)-測(cè)試-反饋閉環(huán)，減少了對(duì)其他組件的依賴。原子服務(wù)綜合到組合服務(wù)、應(yīng)用服務(wù)中進(jìn)行測(cè)試，有利于故障發(fā)現(xiàn)與定位，提高測(cè)試效率和全面性。

根據(jù)業(yè)務(wù)功能的定義可以衍生出流程服務(wù)的概念，流程服務(wù)是組合服務(wù)的一種，它基于服務(wù)邏輯關(guān)系或業(yè)務(wù)內(nèi)容，系統(tǒng)調(diào)用多個(gè)原子服務(wù)及組合服務(wù)。

3 SOA在汽車中的實(shí)現(xiàn)

面向服務(wù)的架構(gòu)可以通過自上而下/自下而上2種建模路線實(shí)現(xiàn)。自上而下的路線需要結(jié)合功能特性以及系統(tǒng)的需求、用例和邏輯功能架構(gòu)等，以系統(tǒng)功能的描述手段作為輸入，指導(dǎo)軟件架構(gòu)和硬件架構(gòu)的建立；自下而上的路線以原有架構(gòu)為基礎(chǔ)，分析服務(wù)實(shí)現(xiàn)方案，并在服務(wù)開發(fā)到部署的過程中對(duì)原有架構(gòu)進(jìn)行適應(yīng)性改動(dòng)。

3.1 實(shí)施路線圖

自上而下/自下而上的建模路線并非是對(duì)立的，在建模過程中可以靈活運(yùn)用2種建模路線，實(shí)現(xiàn)“中間相遇”，平衡需求實(shí)現(xiàn)和架構(gòu)資源。本文基于SOME/IP實(shí)現(xiàn)面向服務(wù)通信的方法論，根據(jù)面向服務(wù)的架構(gòu)開發(fā)經(jīng)驗(yàn)，提出如圖3所示的SOA開發(fā)路線。該路線實(shí)現(xiàn)了需求到電子軟件架構(gòu)的轉(zhuǎn)換，具有用例驅(qū)動(dòng)和面向服務(wù)2個(gè)特點(diǎn)，前者指導(dǎo)需求分析，后者指導(dǎo)軟件架構(gòu)建模。用例驅(qū)動(dòng)是指從系統(tǒng)外部觀察系統(tǒng)的使用場(chǎng)景、使用方法、功能體現(xiàn)等方面，建立起需求和系統(tǒng)功能邏輯之間的追溯關(guān)系。

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

選擇AEB系統(tǒng)進(jìn)行建模是因?yàn)樵撓到y(tǒng)包含人機(jī)交互、環(huán)境感知、底盤控制等方面，能夠涵蓋車輛高級(jí)駕駛輔助系統(tǒng)、車身、底盤3個(gè)主要功能域。軟件平臺(tái)需要AP和CP的支持，包含了面向服務(wù)的軟件架構(gòu)和面向信號(hào)的軟件架構(gòu)。本文以該系統(tǒng)為例，在建模前對(duì)AEB系統(tǒng)提出以下假設(shè)，簡(jiǎn)化建模環(huán)節(jié)：

（1）假設(shè)硬件架構(gòu)末端節(jié)點(diǎn)（部件）均為電子控制單元（Electronic Control Unit，ECU），并且ECU中能夠部署CP平臺(tái)；

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

（3）假設(shè)AEB系統(tǒng)默認(rèn)開啟。

3.2 實(shí)施方案—AEB系統(tǒng)SOA實(shí)施方案

需求的提出到需求的實(shí)現(xiàn)需要經(jīng)過3個(gè)階段：需求生成、需求分析、確定需求。需求主要來源于用戶調(diào)研、用例分析、競(jìng)品分析，以及從功能安全和信息安全的角度對(duì)系統(tǒng)功能提出具體要求。采用專業(yè)語言對(duì)需求進(jìn)行描述，研究當(dāng)前需求的前置需求和子需求，挖掘潛在需求。在需求分析階段，從安全性、用戶偏好、競(jìng)品熱度等方面對(duì)需求進(jìn)行優(yōu)先級(jí)排序，保證高優(yōu)先級(jí)的需求首先得到實(shí)施。根據(jù)外部對(duì)需求的反饋評(píng)估需求的可實(shí)現(xiàn)性，將需求定位到功能實(shí)施實(shí)體或?qū)?yīng)的實(shí)施環(huán)節(jié)中，分析實(shí)施實(shí)體和實(shí)施環(huán)節(jié)是否存在潛在需求。最后確定需求內(nèi)容，指導(dǎo)服務(wù)邊界、電子軟件架構(gòu)的建立。

根據(jù)所提出需求分析路線對(duì)AEB系統(tǒng)展開需求分析，確定出以下需求：

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

a. 視覺信號(hào)可以通過傳感系統(tǒng)獲取。

b. 傳感系統(tǒng)應(yīng)配備中程毫米波雷達(dá)。

c. 可以識(shí)別障礙物的類型。

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

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

（2）系統(tǒng)根據(jù)環(huán)境信息和主車輛信息進(jìn)行不同級(jí)別的響應(yīng)。

a. 車門未關(guān)閉或乘客未系安全帶時(shí)，不得啟動(dòng)制動(dòng)。

b. 自動(dòng)緊急制動(dòng)（AEB）和制動(dòng)輔助需要ESC和ABS的支持。如果ESC關(guān)閉或ABS出現(xiàn)故障，則不應(yīng)啟動(dòng)制動(dòng)器。

（3）系統(tǒng)應(yīng)具有安全距離報(bào)警模式（需求2的擴(kuò)展）。

a. 只有當(dāng)速度大于65 km/s時(shí)，此模式才能激活。

b. 當(dāng)車輛間距小于安全距離時(shí)，激活報(bào)警。報(bào)警應(yīng)包括語音提示和儀表盤提示。

（4）系統(tǒng)應(yīng)具有制動(dòng)輔助模式（需求2的擴(kuò)展）。

a. 當(dāng)前制動(dòng)力不足且速度大于30 km/s時(shí)，制動(dòng)輔助啟動(dòng)。

b. 制動(dòng)輔助模式應(yīng)減少對(duì)駕駛員的干擾，提高非致敏性。報(bào)警僅包括儀表盤提示。

（5）系統(tǒng)應(yīng)具有AEB模式（需求2的擴(kuò)展）。

a. 當(dāng)系統(tǒng)檢測(cè)到碰撞風(fēng)險(xiǎn)且速度大于30 km/s時(shí)，激活此模式。

b. 此模式下的報(bào)警應(yīng)為高強(qiáng)度報(bào)警。報(bào)警應(yīng)包括語音提示和儀表盤提示，并具有方向盤抖動(dòng)。

c. 此模式激活時(shí)，制動(dòng)燈應(yīng)點(diǎn)亮。

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

底盤控制算法具有硬實(shí)時(shí)要求，部署在面向信號(hào)的AUTOSAR CP平臺(tái)上。ADAS 域和座艙域需要大數(shù)據(jù)并行處理，部署在AUTOSAR AP平臺(tái)上。CP平臺(tái)軟件層可以沿用面向信號(hào)的設(shè)計(jì)方法，也可以面向服務(wù)重新構(gòu)建，設(shè)計(jì)服務(wù)架構(gòu)時(shí)需要考慮服務(wù)和信號(hào)的轉(zhuǎn)換。

在信號(hào)服務(wù)化的過程中應(yīng)當(dāng)注意服務(wù)的內(nèi)容是由信號(hào)抽象而來，還是由對(duì)象所提供的響應(yīng)抽象而來。比如，將制動(dòng)信號(hào)抽象為服務(wù)，服務(wù)的提供方是制動(dòng)信號(hào)的發(fā)送方，消費(fèi)方是制動(dòng)信號(hào)的接收方（制動(dòng)器）；而把制動(dòng)這一動(dòng)作抽象為服務(wù)，服務(wù)的提供方是制動(dòng)器，制動(dòng)信號(hào)的來源請(qǐng)求制動(dòng)器提供服務(wù)。2種方案從原理上而言，需要不同的服務(wù)實(shí)現(xiàn)方式（方法或者事件）。從具體實(shí)現(xiàn)上而言，底盤相關(guān)模塊采用信號(hào)抽象為服務(wù)的方式更符合控制系統(tǒng)行為，也能有利于軟件開發(fā)人員邏輯展開。

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

式中：[Snp]為應(yīng)用服務(wù)，[Su1m]為[Snp]下的元服務(wù)，[Svc]為[Snp]下的組合服務(wù)，[Su2m]為[Svc]下的元服務(wù)，[Sv2cs]為[Svc]下的子組合服務(wù)。

根據(jù)服務(wù)的粒度，子組合服務(wù)下可以存在更細(xì)粒度的組合服務(wù)和元服務(wù)。服務(wù)的粒度并非越細(xì)越好，需要根據(jù)服務(wù)內(nèi)容進(jìn)行合理分析，盲目劃分服務(wù)粒度會(huì)給服務(wù)架構(gòu)的全生命周期管理帶來麻煩。

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

將ADAS域中服務(wù)的分析方法擴(kuò)展到AEB系統(tǒng)的完全實(shí)現(xiàn)，可以得出如圖6所示的服務(wù)架構(gòu)。圖中CockpitSensorStatus（駕駛艙傳感器狀態(tài)）框中，Cockpit_Ctrl（駕駛艙控制）為服務(wù)消費(fèi)方，CockpitSensorProcess（駕駛艙傳感器處理）為服務(wù)提供方，虛線用來映射端口角色。

為了更直觀的表達(dá)，服務(wù)架構(gòu)中重用了部分接口，而在軟件架構(gòu)建模時(shí)需要對(duì)一些接口進(jìn)行拆分使服務(wù)邊界清晰化。

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

在SOA軟件架構(gòu)中，弱化了軟件組件和硬件單元的映射關(guān)系，部署在不同ECU的軟件組件可以通過方法實(shí)現(xiàn)RPC，提高了軟件組件的可伸縮性。

在軟件架構(gòu)中可以將QoS在開發(fā)到后續(xù)升級(jí)的任意環(huán)節(jié)作為服務(wù)被引入軟件架構(gòu)中，這也體現(xiàn)了面向服務(wù)的靈活性。端到端延遲一定程度上決定著應(yīng)用的性能，在AEB系統(tǒng)中出于功能安全的考慮，從傳感器傳出數(shù)據(jù)到?jīng)Q策系統(tǒng)提供決策結(jié)果這一環(huán)節(jié)產(chǎn)生的時(shí)延對(duì)AEB系統(tǒng)的安全性、有效性具有至關(guān)重要的作用，因此引入AEB決策時(shí)延評(píng)價(jià)服務(wù)。假設(shè)車身模塊不會(huì)干擾決策結(jié)果，將上述環(huán)節(jié)簡(jiǎn)化為圖8，并增加時(shí)間戳。圖中[Ts1]、[Ts2]、[Ts3]、[Ts4]分別為第一個(gè)傳感器信號(hào)發(fā)出時(shí)、最后一個(gè)傳感器信號(hào)發(fā)出時(shí)、傳感器信號(hào)融合結(jié)果輸出時(shí)、決策結(jié)果輸出時(shí)的全局時(shí)鐘時(shí)間戳。

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

式中：[Δtmax]為設(shè)置的時(shí)間間隔閾值。

為避免QoS對(duì)AEB系統(tǒng)產(chǎn)生影響，式（2）中的約束為軟約束。當(dāng)[tI4，1>kΔtmax]時(shí)，觸發(fā)[tI4，1]記錄器。記錄器采集[R=tI，04，1，tI，14，1，…，tI，m4，1]，分析[R]的正態(tài)分布峰值點(diǎn)坐標(biāo)[tnp4，1]，若[tnp4，1]滿足式（3）時(shí)，認(rèn)為AEB服務(wù)具有不可靠性，并停用AEB制動(dòng)服務(wù)。

之后，AEB決策時(shí)延評(píng)價(jià)服務(wù)會(huì)一直運(yùn)行記錄器[R]，當(dāng)連續(xù)[δ]個(gè)記錄周期[R]滿足式（4），則重新啟用AEB制動(dòng)服務(wù)。

4 域集中式硬件通信架構(gòu)

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

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

分布在車身各位置的傳感器、ECU、執(zhí)行器等由區(qū)域控制器采用控制器局域網(wǎng)絡(luò)（CAN）、串行通信網(wǎng)絡(luò)（LIN）、通用串行總線（USB）、以太網(wǎng)（Ethernet）等多種通信方式就近連接（本文構(gòu)建的硬件模型中僅采用了CAN、USB的連接方式），區(qū)域控制器主要承擔(dān)區(qū)域網(wǎng)關(guān)的任務(wù)，Ethernet實(shí)現(xiàn)中央高性能計(jì)算機(jī)到各區(qū)域控制器的主干通信網(wǎng)。根據(jù)以上分析，本文構(gòu)建出如圖9所示的域集中環(huán)網(wǎng)通信網(wǎng)絡(luò)。

環(huán)網(wǎng)架構(gòu)的優(yōu)點(diǎn)在于能夠自動(dòng)選取負(fù)載較小的路由路線實(shí)現(xiàn)數(shù)據(jù)傳輸，并且在主干網(wǎng)絡(luò)發(fā)生損壞時(shí)仍能保證通信系統(tǒng)正常工作。設(shè)從中央 Switch發(fā)出的數(shù)據(jù)流[SFL]、[SFR]、[SRL]、[SRR]的終點(diǎn)分別為對(duì)應(yīng)的區(qū)域控制器，而每段Ethernet承載的數(shù)據(jù)流為[S1]、[S2]、[S3]、[S4]、[S5]，當(dāng)Ethernet發(fā)生故障時(shí)，主干通信網(wǎng)上的數(shù)據(jù)流如式（5）所示。

圖9中還提供了其他的主干通信網(wǎng)連接變體，在采用Connection variant后可以形成雙環(huán)網(wǎng)通信架構(gòu)，能夠進(jìn)一步降低Ethernet ①、②的負(fù)載，并能夠提供更多的信號(hào)路由方式。

在進(jìn)行信號(hào)路由之前，需要將SWC映射到域集中硬件通信架構(gòu)。算法主體將部署到中央高性能計(jì)算機(jī)，傳感器/執(zhí)行器相關(guān)服務(wù)映射網(wǎng)絡(luò)末端節(jié)點(diǎn)ECU中。以實(shí)現(xiàn)RR Brake Light 服務(wù)為例，路由路線起點(diǎn)為座艙 MPU，經(jīng)過中央 Switch、FR Switch、RR Switch到達(dá)RR Zone，區(qū)域控制器承擔(dān)網(wǎng)關(guān)的角色，通過CAN發(fā)送點(diǎn)亮右后制動(dòng)燈的信號(hào)。

5 總結(jié)與展望

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

參 考 文 獻(xiàn)

[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.

（責(zé)任編輯 明慧）

【作者簡(jiǎn)介】

朱元（1976—），男，同濟(jì)大學(xué)，博士，副教授，研究方向?yàn)樾履茉雌囯姍C(jī)控制技術(shù)、汽車電子嵌入式軟件、智能駕駛多傳感器融合技術(shù)。

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

蘇子鈞（1998—），男，同濟(jì)大學(xué)，碩士研究生，研究方向?yàn)槠囯娮忧度胧杰浖?/p>

E-mail：1070548611@qq.com

徐世寒（1997—），男，同濟(jì)大學(xué)，博士研究生，研究方向?yàn)樾履茉雌囯姍C(jī)控制技術(shù)、汽車電子嵌入式軟件。

E-mail：sh_xu@#edu.cn

王恩東（1991—），男，一汽解放汽車有限公司，工程師，研究方向?yàn)槠囯娮忧度胧交A(chǔ)軟件技術(shù)。

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

劉振東（1992—），男，一汽解放汽車有限公司，助理工程師，研究方向?yàn)槠囯娮忧度胧交A(chǔ)軟件技術(shù)。

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