基于AUTOSAR自適應(yīng)平臺的監(jiān)控與容錯(cuò)方案研究

朱元 趙乾翔 張彪 畢承鼎

【歡迎引用】 朱元， 趙乾翔， 張彪， 等. 基于AUTOSAR自適應(yīng)平臺監(jiān)控與容錯(cuò)方案研究[J]. 汽車文摘， 2024（XX）： 1-11.

【Cite this paper】 ZHU Y， ZHAO Q X， ZHANG B， et al. Research on Monitoring and Fault-Tolerance Scheme Based on AUTOSAR Adaptive Platform[J]. Automotive Digest （Chinese）， 2024（XX）：1-11.

【摘要】為了解決面向服務(wù)的AUTOSAR自適應(yīng)平臺（AP）缺乏有效監(jiān)控與容錯(cuò)機(jī)制的問題，并確保軟件系統(tǒng)在故障情況下的高度穩(wěn)定性和安全性，以汽車基礎(chǔ)軟件平臺AP為研究對象，通過自動代客泊車（AVP）軟件系統(tǒng)設(shè)計(jì)了一套完備的監(jiān)控與故障容錯(cuò)機(jī)制，通過分析傳統(tǒng)軟件架構(gòu)與其他面向服務(wù)架構(gòu)的監(jiān)控方案和AP的特性，設(shè)計(jì)了AP的監(jiān)控方案，實(shí)現(xiàn)對平臺基礎(chǔ)設(shè)施（處理器、網(wǎng)絡(luò)、內(nèi)存）和服務(wù)狀態(tài)（響應(yīng)時(shí)間）的監(jiān)控；基于Qt開發(fā)的數(shù)據(jù)顯示模塊通過LT協(xié)議實(shí)現(xiàn)對實(shí)時(shí)監(jiān)控?cái)?shù)據(jù)的采集與顯示；提出了一種支持SOME/IP協(xié)議的服務(wù)調(diào)用鏈追蹤方法，實(shí)現(xiàn)對面向服務(wù)架構(gòu)中復(fù)雜服務(wù)調(diào)用關(guān)系的分析。結(jié)果表明該方案能夠在AVP軟件系統(tǒng)中監(jiān)控和分析服務(wù)故障，并在發(fā)生故障時(shí)采取容錯(cuò)機(jī)制，提升系統(tǒng)可靠性。

關(guān)鍵詞：AUTOSAR；面向服務(wù)架構(gòu)；平臺監(jiān)控；容錯(cuò)機(jī)制

中圖分類號：TP311.131 ? 文獻(xiàn)標(biāo)志碼：A ?DOI： 10.19822/j.cnki.1671-6329.20240021

Research on Monitoring and Fault-Tolerance Scheme Based on AUTOSAR Adaptive Platform

Zhu Yuan1， Zhao Qianxiang1， Zhang Biao2， Bi Chengding2

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

【Abstract】 To address the lack of effective monitoring and fault tolerance mechanisms in the service-oriented AUTOSAR Adaptive Platform （AP） and to ensure high stability and safety of the software system in case of faults， this study takes the automotive basic software platform AP as the research object. A complete monitoring and fault tolerance mechanism is designed through the Automated Valet Parking （AVP） software system. By analyzing traditional software architectures， other service-oriented architecture monitoring solutions， and the characteristics of AP， a monitoring scheme for AP is designed to supervise the platform infrastructure （processors， networks， memory） and service states （response times）. A data display module developed with Qt， using the LT protocol， implements the collection and display of real-time monitoring data. Furthermore， a service call chain tracing method supporting the SOME/IP protocol is proposed， enabling analysis of complex service call relationships within service-oriented architectures. The results indicate that the scheme can monitor and analyze service failures within the AVP software system and implement fault tolerance mechanisms in case of failures， thus enhancing system reliability.

Key words： AUTOSAR， Service-oriented architecture， Platform monitoring， Fault tolerance mechanism

0 引言

電動化、智能化、網(wǎng)聯(lián)化是汽車工業(yè)未來的3大發(fā)展趨勢，三者彼此關(guān)聯(lián)，協(xié)同發(fā)展[1-7]。在新的汽車工業(yè)發(fā)展趨勢下，諸如自動代客泊車（Automated Valet Parking，AVP）系統(tǒng)、高級駕駛輔助系統(tǒng)和車載信息娛樂系統(tǒng)等新技術(shù)不斷地應(yīng)用于汽車領(lǐng)域[8-11]。為了滿足汽車日益增長的高計(jì)算需求，多核高性能微處理器正逐步應(yīng)用于汽車控制系統(tǒng)[12-13]。這些微處理器被用作域控制器，能夠整合原本分散在不同小型控制器中的功能，同時(shí)承擔(dān)更復(fù)雜的智能駕駛算法[14-15]。

在這種背景下，2017年AUTOSAR聯(lián)盟推出了AUTOSAR自適應(yīng)平臺（Adaptive Platform，AP）。AP作為電子控制單元（Electronic Control Unit， ECU）的標(biāo)準(zhǔn)化集成平臺，構(gòu)建在POSIX操作系統(tǒng)之上，致力于滿足汽車領(lǐng)域的最新發(fā)展趨勢[16-17]。

與此同時(shí)，隨著車載軟件功能需求的不斷增長，通過增加相應(yīng)的監(jiān)控手段與容錯(cuò)機(jī)制，是保證汽車軟件可靠性的有效手段[18-20]。然而，在AP領(lǐng)域尚未存在有效的監(jiān)控與容錯(cuò)方案。

本文以AVP軟件系統(tǒng)為例，針對AP領(lǐng)域缺少對系統(tǒng)的有效監(jiān)控手段和故障容錯(cuò)機(jī)制的問題，設(shè)計(jì)了平臺監(jiān)控方案完成對系統(tǒng)的實(shí)時(shí)監(jiān)控，協(xié)助開發(fā)過程中故障定位分析與運(yùn)行時(shí)故障發(fā)現(xiàn)，并設(shè)計(jì)了故障容錯(cuò)機(jī)制，保證故障發(fā)生后系統(tǒng)能夠正常運(yùn)行。

1 AUTOSAR自適應(yīng)平臺數(shù)據(jù)監(jiān)測方案

1.1 設(shè)計(jì)方案

針對AP平臺，設(shè)計(jì)了數(shù)據(jù)監(jiān)測系統(tǒng)（圖1），包括分布式數(shù)據(jù)采集模塊及其軟件應(yīng)用組件（Software Compenent， SWC）在ARA（AUTOSAR Runtime for Adaptive Applications）上運(yùn)行，數(shù)據(jù)存儲與分析模塊，數(shù)據(jù)顯示模塊。

數(shù)據(jù)采集模塊負(fù)責(zé)采集基礎(chǔ)設(shè)施相關(guān)的數(shù)據(jù)，分布式的部署到每一個(gè)需要監(jiān)視的操作系統(tǒng)中，對中央處理器（Central Processing Unit， CPU）、內(nèi)存相關(guān)的數(shù)據(jù)進(jìn)行監(jiān)測，這些數(shù)據(jù)主要通過操作系統(tǒng)提供的接口或者文件進(jìn)行獲取。數(shù)據(jù)采集模塊以固定的周期對這些數(shù)據(jù)進(jìn)行采集，并通過LT（Log and Trace）協(xié)議發(fā)送至數(shù)據(jù)存儲模塊和數(shù)據(jù)顯示模塊。

數(shù)據(jù)存儲與分析模塊負(fù)責(zé)對所有采集到的數(shù)據(jù)進(jìn)行匯總，包括數(shù)據(jù)采集模塊的數(shù)據(jù)，以及應(yīng)用主動上報(bào)的數(shù)據(jù)，即Method的響應(yīng)時(shí)間等，并將這些數(shù)據(jù)進(jìn)行存儲，以離線文件的形式提供給數(shù)據(jù)顯示模塊。該模塊會對數(shù)據(jù)進(jìn)行統(tǒng)計(jì)分析，通過配置文件確定判斷故障的條件，從而根據(jù)已有的數(shù)據(jù)統(tǒng)計(jì)故障的數(shù)量。

數(shù)據(jù)顯示模塊負(fù)責(zé)可視化監(jiān)測數(shù)據(jù)，通過表格、曲線圖以及柱狀圖的方式將數(shù)據(jù)加以顯示。數(shù)據(jù)顯示模塊并非安裝在汽車內(nèi)，而是以上位機(jī)的形式安裝在個(gè)人計(jì)算機(jī)（Personal Computer，PC）中，既能夠?qū)崟r(shí)通過LT協(xié)議接收監(jiān)測數(shù)據(jù)，也能將數(shù)據(jù)存儲與分析模塊的離線監(jiān)控?cái)?shù)據(jù)進(jìn)行解析和顯示。

方案使用AUTOSAR中的Dlt模塊實(shí)現(xiàn)數(shù)據(jù)的收集工作，Dlt模塊是AUTOSAR標(biāo)準(zhǔn)中使用的日志模塊，通過LT協(xié)議傳輸日志，無需在AP上安裝其他組件即可實(shí)現(xiàn)Dlt日志的發(fā)送與控制。

LT協(xié)議報(bào)文格式，包含3部分：基礎(chǔ)頭部（Base Header）、擴(kuò)展頭部（Extension Header）和有效載荷（Payload），見圖2。

1.2 監(jiān)測數(shù)據(jù)選擇

數(shù)據(jù)監(jiān)測模塊中的數(shù)據(jù)指標(biāo)的選取需要確保該指標(biāo)確實(shí)與服務(wù)狀態(tài)直接或間接相關(guān)，并在記錄時(shí)標(biāo)上監(jiān)測的時(shí)間信息，形成數(shù)據(jù)在時(shí)間上的關(guān)聯(lián)。

在AP中，與SOME/IP服務(wù)相關(guān)的直接數(shù)據(jù)指標(biāo)包括：

（1）Method響應(yīng)時(shí)間

在AP中，通過SOME/IP Method實(shí)現(xiàn)遠(yuǎn)程過程調(diào)用時(shí)服務(wù)調(diào)用方與服務(wù)提供方之間常見的交互方式。Method的響應(yīng)時(shí)間是衡量SOME/IP服務(wù)狀態(tài)的重要指標(biāo)，在一些對于時(shí)間要求比較高的場景中，如果響應(yīng)時(shí)間超過約定好的指標(biāo)，可以被認(rèn)為本次交互失敗。

Method響應(yīng)時(shí)間有2種計(jì)算方式，一種是從服務(wù)提供方角度進(jìn)行計(jì)算，即服務(wù)提供方接收到Method請求和完成Method計(jì)算的時(shí)間間隔；另一種是從服務(wù)調(diào)用方角度進(jìn)行計(jì)算，即服務(wù)調(diào)用方發(fā)起Method和接收到結(jié)果的時(shí)間間隔。與前者相比，后者計(jì)算出的響應(yīng)時(shí)間包括了中間件對服務(wù)報(bào)文的處理時(shí)間和服務(wù)報(bào)文在網(wǎng)絡(luò)中的傳輸時(shí)間。本設(shè)計(jì)中，這2種Method響應(yīng)時(shí)間都應(yīng)被監(jiān)測。

對于Method響應(yīng)時(shí)間這項(xiàng)數(shù)據(jù)指標(biāo)，在具體實(shí)現(xiàn)上，應(yīng)當(dāng)由服務(wù)提供方和服務(wù)調(diào)用方主動上報(bào)，上報(bào)格式為見圖3。

其中Context用來區(qū)分Method響應(yīng)時(shí)間的計(jì)算方式，“Call”表示服務(wù)調(diào)用方計(jì)算的響應(yīng)時(shí)間，“Impl”表示服務(wù)提供方計(jì)算的響應(yīng)時(shí)間。

（2）Event發(fā)送/接收時(shí)間間隔

在AP中，Event可以被用來傳輸周期性的數(shù)據(jù)（例如周期性采集的雷達(dá)數(shù)據(jù)）。這種應(yīng)用場景下，該周期必須是確定的，如果服務(wù)調(diào)用方在周期間隔內(nèi)未收到 Event數(shù)據(jù)，可能會導(dǎo)致服務(wù)調(diào)用方故障。

Event發(fā)送時(shí)間是服務(wù)提供方的Event發(fā)送時(shí)間點(diǎn)，Event接收時(shí)間是服務(wù)接收方接收到Event的時(shí)間。

對于Event發(fā)送/接受時(shí)間這項(xiàng)數(shù)據(jù)指標(biāo)，在具體實(shí)現(xiàn)上，應(yīng)當(dāng)由服務(wù)提供方和服務(wù)調(diào)用方主動上報(bào)，上報(bào)格式見圖4。

其中Context用來區(qū)分Event發(fā)送/接收時(shí)間，“Send”表示Event發(fā)送時(shí)間，“Recv”表示Event接收時(shí)間。

除了服務(wù)狀態(tài)的直接數(shù)據(jù)指標(biāo)外，數(shù)據(jù)監(jiān)測模塊還應(yīng)當(dāng)采集與SOME/IP服務(wù)相關(guān)的基礎(chǔ)設(shè)施數(shù)據(jù)指標(biāo)：

（3）CPU利用率與CPU負(fù)載

CPU資源是硬件平臺中非常重要的系統(tǒng)資源，如果CPU資源耗盡，將造成硬件平臺中的大部分進(jìn)程得不到調(diào)度，引起進(jìn)程饑餓問題。汽車中，CPU負(fù)載過高的原因有很多，包括程序設(shè)計(jì)失誤造成應(yīng)用進(jìn)入死循環(huán)、系統(tǒng)超過CPU處理能力。

CPU使用率是一段時(shí)間內(nèi)CPU運(yùn)行時(shí)間占總時(shí)間的比值，CPU負(fù)載是一段時(shí)間內(nèi)處于可運(yùn)行狀態(tài)和不可中斷狀態(tài)的進(jìn)程平均數(shù)量。

在CPU處于高負(fù)載狀態(tài)時(shí)，CPU負(fù)載更能反應(yīng)CPU的真實(shí)狀況，因?yàn)楦哓?fù)載狀態(tài)時(shí)CPU使用率已經(jīng)接近100%，無法得出更多CPU的負(fù)載信息，CPU負(fù)載能夠反映出此時(shí)正在運(yùn)行和等待運(yùn)行的進(jìn)程數(shù)。

（4）網(wǎng)絡(luò)延遲

延遲通常采用網(wǎng)絡(luò)數(shù)據(jù)包從發(fā)送端到接收端再回到接收端所經(jīng)歷的時(shí)間。分布式架構(gòu)對底層網(wǎng)絡(luò)十分依賴，網(wǎng)絡(luò)的運(yùn)行狀況直接影響服務(wù)的健康狀況。當(dāng)網(wǎng)絡(luò)發(fā)生擁堵時(shí)，會造成服務(wù)的響應(yīng)時(shí)間變長，進(jìn)而通過服務(wù)間的依賴引起連鎖反應(yīng)。

（5）內(nèi)存使用率

內(nèi)存使用率，即已使用的內(nèi)存占總內(nèi)存的比重。AP應(yīng)用在啟動后，會將可執(zhí)行文件中的代碼和數(shù)據(jù)放入內(nèi)存中，等待CPU訪問。Linux等支持虛擬內(nèi)存的操作系統(tǒng)在內(nèi)存資源耗盡時(shí)，會將一些內(nèi)存中的數(shù)據(jù)轉(zhuǎn)移到容量更大的外部存儲器中，以緩解內(nèi)存的緊張。

數(shù)據(jù)采集模塊負(fù)責(zé)周期性地對基礎(chǔ)設(shè)施數(shù)據(jù)指標(biāo)進(jìn)行采集，并將采集到的數(shù)據(jù)日志形式上報(bào)至數(shù)據(jù)分析與存儲模塊以及數(shù)據(jù)顯示模塊，基礎(chǔ)設(shè)施數(shù)據(jù)的Dlt日志結(jié)構(gòu)見圖5。

1.3 數(shù)據(jù)顯示模塊

數(shù)據(jù)顯示模塊是安裝在PC中的上位機(jī)程序，能夠?qū)ΡO(jiān)控?cái)?shù)據(jù)進(jìn)行可視化的展示，監(jiān)控?cái)?shù)據(jù)可以使用離線數(shù)據(jù)，也可以通過LT協(xié)議對監(jiān)控?cái)?shù)據(jù)進(jìn)行采集（見圖6）。

數(shù)據(jù)顯示模塊包含2個(gè)子處理模塊——Dlt Client 和數(shù)據(jù)可視化部分。AP中Dlt守護(hù)進(jìn)程通過LT協(xié)議將日志信息發(fā)送至Dlt Client，LT協(xié)議分為Server和 Client，Dlt守護(hù)進(jìn)程為Server，數(shù)據(jù)顯示模塊是Client。Dlt Client收到日志信息后需要對內(nèi)容進(jìn)行過濾和篩選，將監(jiān)控方案需要的信息存儲下來，通過數(shù)據(jù)可視化功能進(jìn)行顯示。

數(shù)據(jù)可視化部分負(fù)責(zé)對收到的監(jiān)控?cái)?shù)據(jù)進(jìn)行顯示，在設(shè)計(jì)的監(jiān)控方案中，數(shù)據(jù)可視化采用Qt實(shí)現(xiàn)。Qt是圖形用戶界面程序開發(fā)框架，支持?jǐn)?shù)據(jù)表格、折線圖、柱狀圖、自定義圖形繪制等功能。監(jiān)控?cái)?shù)據(jù)中采集的上報(bào)數(shù)據(jù)顯示到Qt數(shù)據(jù)表格中，對于服務(wù)響應(yīng)時(shí)間，繪制響應(yīng)時(shí)間的時(shí)間分布圖和隨時(shí)間變化的曲線圖，對于系統(tǒng)基礎(chǔ)設(shè)施，繪制各項(xiàng)監(jiān)控?cái)?shù)據(jù)隨時(shí)間變化的曲線圖。

2 服務(wù)調(diào)用鏈追蹤

汽車軟件系統(tǒng)中會存在大量的服務(wù)和服務(wù)節(jié)點(diǎn)，同時(shí)服務(wù)節(jié)點(diǎn)之間會存在復(fù)雜的服務(wù)調(diào)用關(guān)系，如：A服務(wù)調(diào)用B服務(wù)，B服務(wù)調(diào)用C和D服務(wù)。在這樣的情況下，如果C服務(wù)出現(xiàn)故障，那么B服務(wù)和A服務(wù)將也會出現(xiàn)故障。

如果選用傳統(tǒng)的故障定位方式，通過日志模塊將每個(gè)節(jié)點(diǎn)調(diào)用服務(wù)和被請求服務(wù)的行為記錄到日志中，逐一分析日志的來排查故障。但是這些服務(wù)節(jié)點(diǎn)的日志是分散的，彼此沒有很強(qiáng)的聯(lián)系，無法從中整理出C服務(wù)故障是B服務(wù)與A服務(wù)故障的根本原因。為了將這些服務(wù)節(jié)點(diǎn)的內(nèi)部行為和相互關(guān)系加以整理，本章引入了服務(wù)調(diào)用鏈動態(tài)追蹤技術(shù)。通過這樣的技術(shù)，能夠?qū)⒁粭l完整的服務(wù)調(diào)用鏈信息從離散的服務(wù)節(jié)點(diǎn)日志中提取出來，這條調(diào)用鏈信息包含了所有服務(wù)節(jié)點(diǎn)，服務(wù)調(diào)用關(guān)系，服務(wù)處理時(shí)間、時(shí)延和故障信息。

因此需要設(shè)計(jì)一種基于AP、支持SOME/IP協(xié)議的服務(wù)調(diào)用鏈追蹤方法。旨在解決上述面向服務(wù)架構(gòu)中故障定位困難和SOME/IP協(xié)議不支持調(diào)用鏈追蹤的問題，以此幫助開發(fā)人員梳理服務(wù)節(jié)點(diǎn)之間的動態(tài)調(diào)用關(guān)系，監(jiān)控方案在運(yùn)行時(shí)的服務(wù)調(diào)用情況，更加容易地觀察服務(wù)依賴關(guān)系，定位故障所在的服務(wù)節(jié)點(diǎn)。

2.1 設(shè)計(jì)方案

在服務(wù)調(diào)用方安裝調(diào)用鏈追蹤工具Client組件，在服務(wù)提供方安裝調(diào)用鏈追蹤工具Server組件，在PC上安裝調(diào)用鏈追蹤工具。服務(wù)調(diào)用鏈追蹤系統(tǒng)結(jié)構(gòu)見圖7，服務(wù)調(diào)用鏈追蹤系統(tǒng)時(shí)序圖見圖8。

當(dāng)AP應(yīng)用A作為服務(wù)調(diào)用方發(fā)起SOME/IP服務(wù)調(diào)用時(shí)，被視為一條服務(wù)調(diào)用鏈的開始，調(diào)用鏈追蹤工具Client組件會生成唯一的調(diào)用鏈Trace Id。將該 Trace Id和該應(yīng)用的節(jié)點(diǎn)信息、調(diào)用服務(wù)的Service Id 與Method Id等信息組成調(diào)用鏈信息報(bào)文，通過UDP 多播協(xié)議發(fā)送至作為服務(wù)提供方的AP應(yīng)用B，同時(shí)將這些調(diào)用鏈信息通過LT協(xié)議以日志的形式發(fā)送到服務(wù)調(diào)用鏈追蹤工具。當(dāng)作為服務(wù)提供方的AP應(yīng)用 B接收此次SOME/IP服務(wù)調(diào)用時(shí)，也會從接收到與本次SOME/IP服務(wù)調(diào)用對應(yīng)的調(diào)用鏈信息，在完成服務(wù)調(diào)用的基本功能的同時(shí)，會同時(shí)將這些調(diào)用鏈信息通過LT協(xié)議以日志的形式發(fā)送到服務(wù)調(diào)用鏈追蹤工具。

如果AP應(yīng)用B服務(wù)繼續(xù)調(diào)用其他服務(wù)時(shí)，會將自身的信息加入調(diào)用鏈信息，繼續(xù)重復(fù)上述操作。

數(shù)據(jù)顯示模塊會收集上述所有的日志信息，通過Trace Id將所有調(diào)用鏈信息日志加以區(qū)分，最終分析出每一條調(diào)用鏈的信息，并以可視化形式展現(xiàn)。

2.2 調(diào)用鏈信息報(bào)文設(shè)計(jì)

調(diào)用鏈追蹤工具通過UDP多播發(fā)送調(diào)用鏈信息報(bào)文實(shí)現(xiàn)調(diào)用鏈信息的傳輸，在調(diào)用鏈信息報(bào)文中加入 SOME/IP報(bào)文的信息（Client Id、Session Id、Service Id 和Method Id），實(shí)現(xiàn)與SOME/IP報(bào)文的唯一對應(yīng)。此方法不需要修改SOME/IP報(bào)文信息和ARXML配置文件，并且能夠與未安裝調(diào)用鏈追蹤工具的AP應(yīng)用實(shí)現(xiàn)SOME/IP通信。調(diào)用鏈信息報(bào)文見圖9。

（1）Trace Id [32 bit]

調(diào)用鏈Trace Id是調(diào)用鏈的唯一標(biāo)識，因此必須保持該標(biāo)識的唯一性。

Trace Id使用當(dāng)前時(shí)間加隨機(jī)數(shù)的方法來獲?。ㄒ妶D10）。同一時(shí)間的服務(wù)調(diào)用鏈發(fā)起數(shù)量有限，對于開始時(shí)間完全相同的服務(wù)調(diào)用鏈，通過加入隨機(jī)數(shù)的方式，避免Trace Id沖突的可能。

（2）Span Id [32 bit]

在服務(wù)調(diào)用鏈中，服務(wù)調(diào)用的服務(wù)調(diào)用方和服務(wù)提供方都被認(rèn)為是一個(gè)節(jié)點(diǎn)，節(jié)點(diǎn)的唯一標(biāo)識符即為 Span Id。在一條服務(wù)調(diào)用鏈中，同一個(gè)服務(wù)可能被反復(fù)調(diào)用，所以對于同一服務(wù)被多次調(diào)用的情況，服務(wù)提供方的Span Id不能相同，服務(wù)調(diào)用方的Span Id也不能相同。因此Span Id被設(shè)計(jì)為節(jié)點(diǎn)IP地址主機(jī)號+服務(wù)Id +當(dāng)前時(shí)間（見圖11），來實(shí)現(xiàn)上述需求。

（3）Parent Id [32 bit]

當(dāng)服務(wù)調(diào)用方向服務(wù)提供方調(diào)用服務(wù)時(shí)，服務(wù)調(diào)用方的Span Id即為服務(wù)提供方的Parent Id。通過每一個(gè)調(diào)用鏈信息中Span Id和Parent Id就能分析出該條調(diào)用鏈的服務(wù)調(diào)用關(guān)系。

（4）Client Id [16 bit]和Session Id [16 bit]

即為服務(wù)調(diào)用方的Client Id和服務(wù)調(diào)用方調(diào)用服務(wù)時(shí)的Session Id。在同一時(shí)間，可能有多個(gè)服務(wù)調(diào)用方并發(fā)訪問服務(wù)提供方提供的同一服務(wù)，這些 SOME/IP服務(wù)請求報(bào)文的到達(dá)時(shí)間與調(diào)用鏈信息報(bào)文的到達(dá)時(shí)間并不是有序的。通過比對SOME/IP服務(wù)請求報(bào)文中的Client Id與Session Id與調(diào)用鏈信息報(bào)文中的Client Id與Session Id，能夠?qū)⒄{(diào)用鏈信息報(bào)文與 SOME/IP報(bào)文唯一關(guān)聯(lián)。

（5）請求服務(wù)的Service Id與Method Id

一個(gè)AP應(yīng)用會同時(shí)作為多個(gè)服務(wù)的服務(wù)提供方，在調(diào)用鏈信息報(bào)文中加入Service Id和Method Id，能夠幫助調(diào)用鏈追蹤工具Server組件準(zhǔn)確的識別該條調(diào)用鏈信息報(bào)文是與哪個(gè)服務(wù)相關(guān)聯(lián)的。

2.3 Dlt日志設(shè)計(jì)

調(diào)用鏈信息由調(diào)用鏈追蹤工具Server和Client組件通過Dlt模塊以日志的形式，發(fā)送至調(diào)用鏈追蹤工具，調(diào)用鏈追蹤工具通過收集和處理這些包含了調(diào)用鏈信息的日志分析調(diào)用鏈的服務(wù)調(diào)用關(guān)系和其他信息。為了與其他的日志加以區(qū)分，服務(wù)調(diào)用鏈日志將LT協(xié)議的Extended Header中Context Id設(shè)置為“Trace”作為標(biāo)記。

LT協(xié)議的Payload用來存儲調(diào)用鏈信息，結(jié)構(gòu)如圖12所示。為了使日志具有可讀性，對于上報(bào)日志中的每一項(xiàng)信息采取不定長的字符串加以記錄，以‘＼20（空格）作為間隔加以區(qū)分。

其中Call Context表示當(dāng)前上報(bào)信息的時(shí)機(jī)，包括“Client Start”、“Client End”、“Server Start”和“Server End”四種狀態(tài)。“Client Start”表示服務(wù)調(diào)用方發(fā)起服務(wù)調(diào)用時(shí)，“Client End”表示服務(wù)調(diào)用方完成服務(wù)調(diào)用時(shí)，“Server Start”表示服務(wù)提供方接收服務(wù)調(diào)用時(shí)，“Server End”表示服務(wù)提供方處理完成服務(wù)調(diào)用時(shí)。

2.4 調(diào)用鏈信息報(bào)文處理與傳輸?shù)膶?shí)現(xiàn)

調(diào)用鏈信息報(bào)文的處理與傳輸由調(diào)用鏈追蹤工具 Client組件與Server組件完成。

調(diào)用鏈追蹤工具Client組件的流程圖見圖13。AP應(yīng)用通過調(diào)用鏈追蹤工具Client組件接口發(fā)起服務(wù)調(diào)用時(shí)，組件會讀取AP應(yīng)用發(fā)起服務(wù)調(diào)用時(shí)上下文中是否有Trace Id信息。如果有，讀取上下文中Trace Id，賦值到調(diào)用鏈信息的Trace Id，將上下文中的 Span Id賦值到調(diào)用鏈信息的Parent Id。如果沒有，則生成新的Trace Id，并將Parent Id設(shè)置為0，即為調(diào)用鏈根節(jié)點(diǎn)。根據(jù)服務(wù)調(diào)用時(shí)的SOME/IP報(bào)文，設(shè)置調(diào)用鏈信息中的Client Id、Session Id、Service Id和 Method Id信息。通過LT協(xié)議向調(diào)用鏈追蹤工具發(fā)送調(diào)用鏈信息日志，通過用戶數(shù)據(jù)報(bào)協(xié)議（User Datagram Protocol，UDP）協(xié)議向服務(wù)提供方傳輸調(diào)用鏈信息報(bào)文，通過基于IP的可擴(kuò)展面向服務(wù)的中間件（Scalabe Service-Oriented Middleware Over IP，SOME/IP）協(xié)議發(fā)起對服務(wù)提供方的服務(wù)調(diào)用。

調(diào)用鏈追蹤工具Server組件包括主流程和報(bào)文接收與處理兩部分。報(bào)文接收與處理部分的流程見圖14（b）所示，當(dāng)接收到服務(wù)調(diào)用鏈信息的UDP報(bào)文時(shí)，解析該報(bào)文中的所有信息，如果Service Id和Method Id與本應(yīng)用提供的服務(wù)匹配時(shí)，存儲本條服務(wù)調(diào)用鏈信息，否則丟棄該報(bào)文。

當(dāng)接收到SOME/IP服務(wù)請求時(shí)，觸發(fā)調(diào)用鏈追蹤工具Server組件的主流程，如圖14a所示。根據(jù)SOME/IP服務(wù)請求中的Client Id、Session Id、Service Id和Method Id信息查找對應(yīng)的服務(wù)調(diào)用鏈信息。因?yàn)榫W(wǎng)絡(luò)傳輸?shù)牟淮_定性，SOME/IP報(bào)文和服務(wù)調(diào)用鏈信息的報(bào)文到達(dá)服務(wù)提供方的先后順序未知，如果此時(shí)服務(wù)調(diào)用鏈信息的報(bào)文未到達(dá)，則等待，直到完成查找。服務(wù)調(diào)用鏈信息查找完成后，通過Dlt模塊向調(diào)用鏈追蹤工具發(fā)送包含調(diào)用鏈信息的日志。設(shè)置執(zhí)行調(diào)用的上下文信息，即Trace Id和Span Id，并執(zhí)行此次服務(wù)請求的調(diào)用。服務(wù)調(diào)用執(zhí)行完成后，通過Dlt模塊向調(diào)用鏈追蹤工具發(fā)送包含調(diào)用鏈信息的日志。

3 AUTOSAR自適應(yīng)平臺服務(wù)容錯(cuò)機(jī)制

3.1 汽車面向服務(wù)架構(gòu)的服務(wù)容錯(cuò)概述

在面向服務(wù)架構(gòu)中，服務(wù)錯(cuò)誤可能無法完全避免，表現(xiàn)為服務(wù)無響應(yīng)或?qū)τ跁r(shí)間要求嚴(yán)格的服務(wù)未能在規(guī)定時(shí)間內(nèi)響應(yīng)。對于汽車環(huán)境內(nèi)時(shí)間敏感的軟件，服務(wù)未及時(shí)響應(yīng)意味著服務(wù)不可用。

這些服務(wù)錯(cuò)誤主要由以下因素引起：

（1）基礎(chǔ)設(shè)施故障：例如，CPU負(fù)載過高、內(nèi)存不足、存儲器訪問速度過慢等，導(dǎo)致服務(wù)執(zhí)行時(shí)間超出規(guī)定，無法按時(shí)響應(yīng)。

（2）網(wǎng)絡(luò)故障：例如網(wǎng)絡(luò)擁塞、數(shù)據(jù)包丟失、網(wǎng)絡(luò)中斷，導(dǎo)致服務(wù)底層網(wǎng)絡(luò)報(bào)文無法或無法按時(shí)到達(dá)服務(wù)。

（3）服務(wù)提供方故障：如程序異常退出、服務(wù)邏輯錯(cuò)誤、限流策略等，導(dǎo)致服務(wù)提供方無法正常處理請求。

當(dāng)服務(wù)調(diào)用方調(diào)用的服務(wù)出現(xiàn)錯(cuò)誤時(shí)，沒有合適的容錯(cuò)機(jī)制，錯(cuò)誤可能會擴(kuò)散，導(dǎo)致整個(gè)服務(wù)鏈路出現(xiàn)問題，造成更嚴(yán)重的“服務(wù)雪崩”現(xiàn)象，見圖15。

因此，針對服務(wù)故障，必須采取相應(yīng)的容錯(cuò)措施以提高服務(wù)的可靠性。針對不同模塊對服務(wù)可靠性的需求，采用不同的容錯(cuò)策略，以保持資源利用率與服務(wù)可靠性之間的平衡。

3.2 失敗重試

失敗重試是一種策略，指的是在服務(wù)調(diào)用出現(xiàn)錯(cuò)誤時(shí)，會在一定的時(shí)間間隔后重新嘗試調(diào)用該服務(wù)，直到服務(wù)能夠正常響應(yīng)，見圖16。

這種方法在汽車軟件領(lǐng)域，特別適用于智能座艙等對服務(wù)響應(yīng)時(shí)間要求不高的場景。它最大限度地確保服務(wù)的可用性，但不能保證服務(wù)的響應(yīng)時(shí)間能夠滿足要求。

3.2.1 服務(wù)重試風(fēng)暴問題

服務(wù)重試能夠應(yīng)對網(wǎng)絡(luò)擁堵等問題導(dǎo)致的服務(wù)調(diào)用錯(cuò)誤，但重試的頻率和策略必須慎重設(shè)計(jì)，否則可能引發(fā)系統(tǒng)中的服務(wù)重試風(fēng)暴災(zāi)難。

服務(wù)失敗重試的前提是故障可能在一段時(shí)間內(nèi)得以恢復(fù)，但通常恢復(fù)時(shí)間不會特別快。如果服務(wù)調(diào)用方在短時(shí)間內(nèi)頻繁發(fā)起大量服務(wù)重試，可能會加劇故障。例如，如果網(wǎng)絡(luò)擁塞導(dǎo)致服務(wù)超時(shí)，若持續(xù)進(jìn)行大量服務(wù)重試，將進(jìn)一步加劇網(wǎng)絡(luò)擁堵，進(jìn)而造成更大規(guī)模的服務(wù)故障。

此外，在多級服務(wù)調(diào)用場景下，設(shè)計(jì)不良的服務(wù)失敗重試策略可能導(dǎo)致服務(wù)重試在服務(wù)鏈中迅速蔓延。例如，A服務(wù)調(diào)用B服務(wù)，而B服務(wù)進(jìn)一步調(diào)用C服務(wù)。如果C服務(wù)的故障無法在短時(shí)間內(nèi)恢復(fù)，A和B服務(wù)均采用服務(wù)失敗重試策略以應(yīng)對服務(wù)調(diào)用錯(cuò)誤，當(dāng)B服務(wù)在多次重試調(diào)用C服務(wù)后返回異常，A服務(wù)仍然持續(xù)嘗試多次重試調(diào)用B服務(wù)，最終造成C服務(wù)的重復(fù)調(diào)用達(dá)到了多次。

3.2.2 等待時(shí)間隨機(jī)指數(shù)補(bǔ)償與限制鏈路失敗重試

針對產(chǎn)生服務(wù)重試風(fēng)暴的第一種場景，本方案采用了等待時(shí)間指數(shù)補(bǔ)償策略，即服務(wù)發(fā)生錯(cuò)誤后，等待時(shí)間為重試次數(shù)的指數(shù)冪：

[t1=bc] ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? （1）

式中：t1為服務(wù)錯(cuò)誤后的等待時(shí)間，b為等待時(shí)間的基數(shù)，c為失效重試的次數(shù)。

然而，當(dāng)網(wǎng)絡(luò)在特定時(shí)刻發(fā)生擁堵時(shí)，大量服務(wù)超時(shí)，并在同樣的等待時(shí)間后發(fā)起服務(wù)重試，極有可能再次引發(fā)網(wǎng)絡(luò)擁堵，此種現(xiàn)象稱為“服務(wù)重試碰撞”。

為了避免這種碰撞現(xiàn)象的發(fā)生，必須保證每個(gè)服務(wù)調(diào)用方的服務(wù)重試時(shí)間是不同的，因此將服務(wù)重試時(shí)間調(diào)整為：

[t2=b×k， k∈[0.2c -1]， c

式中：t2為避免“服務(wù)重試碰撞”的重試時(shí)間，重試時(shí)間t2為等待時(shí)間基數(shù)b的k倍，其中k為[0，2-1]區(qū)間內(nèi)的任意整數(shù)，并且重試次數(shù)c小于最大重試次數(shù)cMAX。

以等待時(shí)間基數(shù)為2 ms，最大重試次數(shù)4次為例：

a.如果服務(wù)調(diào)用方首次調(diào)用服務(wù)超時(shí)，則在等待0 ms 或2 ms發(fā)起服務(wù)重試。

b.如果仍然超時(shí)，則在等待0 ms、2 ms、4 ms或者6 ms后發(fā)起服務(wù)重試。

c.當(dāng)重試4次后仍然無法正常調(diào)用該服務(wù)，則重試終止。

針對產(chǎn)生服務(wù)重試風(fēng)暴的第二種場景，本方案采用了限制鏈路失敗重試，即當(dāng)一條調(diào)用鏈路中的A服務(wù)在盡力嘗試服務(wù)失敗重試后仍無法完成服務(wù)調(diào)用后，調(diào)用A服務(wù)的服務(wù)不應(yīng)繼續(xù)采用服務(wù)失敗重試。

針對SOME/IP通信協(xié)議的具體實(shí)施方案是：

a.設(shè)計(jì)統(tǒng)一的服務(wù)調(diào)用失敗錯(cuò)誤碼，用來表示本服務(wù)已經(jīng)采用服務(wù)失敗重試，仍發(fā)生錯(cuò)誤。

b.任意一級服務(wù)在采用服務(wù)失敗重試后，仍發(fā)生錯(cuò)誤，將該錯(cuò)誤碼寫入SOME/IP報(bào)文的Return Code，返回至上一層服務(wù)調(diào)用者。

c.上一層服務(wù)調(diào)用者收到該錯(cuò)誤碼后，不會繼續(xù)執(zhí)行服務(wù)重試，直接向更上一層傳遞該錯(cuò)誤碼。

3.3 失敗轉(zhuǎn)移機(jī)制

3.3.1 失敗轉(zhuǎn)移策略

失敗重試雖然可以在一段時(shí)間內(nèi)可恢復(fù)的故障情況下確保服務(wù)的可用性，但并不適用于故障無法短時(shí)間內(nèi)恢復(fù)或?qū)τ陧憫?yīng)時(shí)間要求嚴(yán)格的場景，如感知服務(wù)和路徑規(guī)劃服務(wù)。在這些情況下，長時(shí)間無響應(yīng)可能帶來嚴(yán)重后果。

為了解決這些問題，才引入失敗轉(zhuǎn)移策略，見圖17。在這種策略下，在同一個(gè)服務(wù)部署多個(gè)提供方，這些提供方具備相同的服務(wù)功能，但位于不同的硬件平臺。當(dāng)單一硬件平臺發(fā)生故障時(shí)，冗余的服務(wù)提供方可以確保服務(wù)的可用性。

對于服務(wù)調(diào)用方而言，如果某個(gè)服務(wù)提供方在服務(wù)調(diào)用時(shí)發(fā)生錯(cuò)誤，可以立即切換至其他可用的服務(wù)提供方，無需等待故障服務(wù)的恢復(fù)。這種方法有效提高了服務(wù)調(diào)用方在服務(wù)錯(cuò)誤發(fā)生時(shí)的響應(yīng)速度。

服務(wù)可用度的計(jì)算方式可以用于衡量服務(wù)的穩(wěn)定性和可靠性。這個(gè)指標(biāo)可以用數(shù)學(xué)公式來描述，其計(jì)算方式為：

[A=TDTS] ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?（3）

式中：A為服務(wù)可用度，TD為服務(wù)正常工作時(shí)間，TS為服務(wù)工作總時(shí)間。

或者，可以使用以下公式來表示：

[A=MTBDMTBD+MDT×100%] ? ? ? ? ? ? ? ? ? ?（4）

式中：[MTBD]為服務(wù)的平均無故障時(shí)間，[MDT]為服務(wù)的平均故障修復(fù)時(shí)間。

增加服務(wù)的平均無故障時(shí)間或減少服務(wù)的平均故障修復(fù)時(shí)間都能提高服務(wù)的可用度。引入服務(wù)冗余是提高服務(wù)可用度的有效方法。當(dāng)服務(wù)采用1∶1的冗余時(shí)，只有當(dāng)兩個(gè)服務(wù)同時(shí)失效時(shí)，系統(tǒng)才會發(fā)生故障。因此，加入服務(wù)冗余機(jī)制后的服務(wù)可用度Ar為：

[Ar=1-1-A2×100%] ? ? ? ? ? ? ? ? （5）

舉例說明，假設(shè)初始時(shí)服務(wù)可用度[A]為90%，在引入服務(wù)冗余機(jī)制后，服務(wù)可用度Ar為99%。可見，合理的服務(wù)冗余機(jī)制能夠顯著提高服務(wù)的可用性。

3.3.2 失敗轉(zhuǎn)移實(shí)現(xiàn)

失敗轉(zhuǎn)移策略代表著同一個(gè)服務(wù)有多個(gè)服務(wù)提供方（多個(gè)服務(wù)實(shí)例），服務(wù)調(diào)用方可以使用所有這些服務(wù)實(shí)例，并且可以自由地切換到另一個(gè)可用的服務(wù)實(shí)例。

通常，為了實(shí)現(xiàn)這種多重綁定，可以在服務(wù)的代理（Proxy）中使用多個(gè)服務(wù)實(shí)例句柄見圖18。每個(gè)服務(wù)實(shí)例句柄都對應(yīng)不同服務(wù)提供方提供的服務(wù)實(shí)例。當(dāng)服務(wù)調(diào)用方使用查找服務(wù)的方法（如FindService（））時(shí)，需要指定查找所有服務(wù)實(shí)例，而不是特定實(shí)例ID的服務(wù)實(shí)例。在基于SOME/IP SD的服務(wù)發(fā)現(xiàn)中，可以通過將多個(gè)服務(wù)實(shí)例綁定到同一個(gè)AP應(yīng)用的端口（Port）上，這樣在調(diào)用FindService（）方法時(shí)，只需提供相應(yīng)的端口，就可以找到與該端口綁定的所有服務(wù)實(shí)例。

這種方法允許系統(tǒng)中的服務(wù)調(diào)用方靈活地使用可用的服務(wù)實(shí)例，從而實(shí)現(xiàn)了失敗轉(zhuǎn)移策略，提高了系統(tǒng)的可用性和穩(wěn)定性。

3.4 聚合調(diào)用機(jī)制

聚合調(diào)用是一種容錯(cuò)策略，與失敗轉(zhuǎn)移有所不同。在聚合調(diào)用中，服務(wù)調(diào)用方會同時(shí)向系統(tǒng)內(nèi)所有可用的服務(wù)實(shí)例發(fā)起服務(wù)調(diào)用。只要有一個(gè)服務(wù)實(shí)例正常響應(yīng)，系統(tǒng)就會立即返回結(jié)果給服務(wù)調(diào)用方，見圖19。這與失敗轉(zhuǎn)移策略的最大不同在于，聚合調(diào)用不會等待單個(gè)服務(wù)實(shí)例的失敗或恢復(fù)，而是只要有任意一個(gè)服務(wù)實(shí)例處于正常運(yùn)行狀態(tài)，即使其他服務(wù)實(shí)例發(fā)生故障，系統(tǒng)也能正常提供服務(wù)。

這種策略適用于對服務(wù)響應(yīng)時(shí)間要求非常嚴(yán)格的場景。通過同時(shí)發(fā)起多個(gè)服務(wù)調(diào)用，可以顯著縮短服務(wù)的響應(yīng)時(shí)間，因?yàn)橹恍璧却我庖粋€(gè)服務(wù)實(shí)例的響應(yīng)即可立即返回結(jié)果。這樣可以提高系統(tǒng)的可用性和性能，并確保即使部分服務(wù)實(shí)例出現(xiàn)問題，系統(tǒng)仍能繼續(xù)工作。

然而，聚合調(diào)用也可能會增加系統(tǒng)的負(fù)載和復(fù)雜度。同時(shí)對多個(gè)服務(wù)實(shí)例發(fā)起調(diào)用可能需要更多的資源，并且在某些情況下，可能會導(dǎo)致重復(fù)的、不必要的服務(wù)調(diào)用。因此，在選擇容錯(cuò)策略時(shí)，需要根據(jù)實(shí)際場景和需求權(quán)衡不同的方案。

聚合調(diào)用在提高系統(tǒng)可靠性和服務(wù)時(shí)效性方面帶來了明顯的優(yōu)點(diǎn)。它確實(shí)能夠在系統(tǒng)中存在可用服務(wù)實(shí)例時(shí)，確保服務(wù)請求不會發(fā)生故障，并保持較高的響應(yīng)速度。然而，這種策略也存在一些潛在的問題。

除了消耗更多的操作系統(tǒng)內(nèi)存資源外，聚合調(diào)用可能會對CPU和網(wǎng)絡(luò)資源造成更高的負(fù)載。飽和式的服務(wù)請求可能會導(dǎo)致更多的CPU資源和網(wǎng)絡(luò)資源消耗，增加系統(tǒng)的負(fù)擔(dān)，可能對系統(tǒng)整體性能產(chǎn)生影響。在汽車軟件中，這對于執(zhí)行模塊等對服務(wù)響應(yīng)時(shí)間要求較高的模塊來說，可能會對系統(tǒng)性能和穩(wěn)定性產(chǎn)生影響。

在實(shí)施聚合調(diào)用策略時(shí)，需要平衡提高可靠性和時(shí)效性所帶來的額外資源消耗，必須謹(jǐn)慎考慮系統(tǒng)的資源限制以及負(fù)載情況，確保所使用的策略能夠在提高可靠性的同時(shí)，不會對系統(tǒng)整體性能造成嚴(yán)重影響。

聚合調(diào)用、失敗重試與失敗轉(zhuǎn)移是三種服務(wù)容錯(cuò)機(jī)制，它們在消耗系統(tǒng)資源和代碼入侵程度上各不相同，同時(shí)最終實(shí)現(xiàn)的容錯(cuò)效果也有所差異（見表1）。因此，在選擇適當(dāng)?shù)姆?wù)容錯(cuò)機(jī)制時(shí)，應(yīng)根據(jù)AP應(yīng)用的重要程度進(jìn)行權(quán)衡和選擇。

4 測試與分析

本章將通過Pilot3.0控制器、PC機(jī)，搭建測試環(huán)境，對基于AP的AVP軟件系統(tǒng)進(jìn)行測試。并通過AP監(jiān)控方案，實(shí)現(xiàn)對AVP軟件系統(tǒng)的監(jiān)控。并對AVP軟件系統(tǒng)中路徑規(guī)劃應(yīng)用注入故障，以驗(yàn)證不同容錯(cuò)機(jī)制在不同故障場景下的表現(xiàn)。

4.1 測試環(huán)境

測試系統(tǒng)包含了Pilot 3.0控制器，PC機(jī)，CANoe 測試工具。Pilot 3.0控制器基于地平線征程三代芯片（Journey 3，J3）的自動駕駛控制器（見圖20），包含三顆J3芯片（下文分別稱為J3A，J3B，J3C）和一顆英飛凌TC397芯片，每顆J3芯片擁有獨(dú)立的存儲器和外圍電路，能夠獨(dú)立工作。控制器支持以太網(wǎng)通信，算力上能夠滿足AVP軟件系統(tǒng)的算力要求。具體參數(shù)見表2。

PC機(jī)運(yùn)行AP應(yīng)用的測試工具CANoe軟件和AP 應(yīng)用監(jiān)控?cái)?shù)據(jù)顯示模塊，參數(shù)見表3。

CANoe是VECTOR公司發(fā)布的專門用于汽車 ECU開發(fā)、測試與分析的綜合工具，其功能包括了汽車分布式網(wǎng)絡(luò)設(shè)計(jì)、仿真與測試，單個(gè)ECU的功能仿真與測試，通信協(xié)議的分析，支持CAN、以太網(wǎng)、SOME/IP、LIN等汽車網(wǎng)絡(luò)協(xié)議。測試使用CANoe工具實(shí)現(xiàn)SOME/IP節(jié)點(diǎn)仿真和SOME/IP報(bào)文抓取，實(shí)現(xiàn)對AP應(yīng)用的仿真與測試，版本為CANoe 15.0 （SP1）。

AP MICROSAR是VECTOR公司發(fā)布的用于AP 應(yīng)用開發(fā)的工具，主要功能包括了系統(tǒng)設(shè)計(jì)，代碼生成，代碼編譯。且所有AP應(yīng)用均在AP MICROSAR工具中完成開發(fā)，AP MICROSAR工具版本見表4。

4.2 基于AP的AVP軟件系統(tǒng)測試

在本試驗(yàn)中，在Pilot 3.0控制器和PC的虛擬中安裝了AP必需的系統(tǒng)模塊，并在Pilot 3.0控制器的J3A 中安裝了信息采集應(yīng)用和感知應(yīng)用，J3B中安裝了行為規(guī)劃應(yīng)用和路徑規(guī)劃應(yīng)用，PC中的虛擬機(jī)安裝了控制應(yīng)用，其中J3A、J3B與PC通過以太網(wǎng)交換芯片相連（圖21）。為了對通信報(bào)文進(jìn)行捕獲，在PC中安裝了CANoe軟件。

4.2.1 AVP例程基本通信功能測試

Pilot 3.0控制器上電后，J3A，J3B，J3C分別進(jìn)入操作系統(tǒng)，EM模塊作為操作系統(tǒng)啟動后的第一個(gè)AP 進(jìn)程運(yùn)行，并在運(yùn)行后將系統(tǒng)中應(yīng)當(dāng)啟動的AP系統(tǒng)模塊（SOME/IP守護(hù)進(jìn)程等）和AVP軟件系統(tǒng)的各個(gè)模塊。PC中通過CANoe軟件對SOME/IP報(bào)文進(jìn)行捕獲，如圖22所示，顯示了SOME/IP通信的部分報(bào)文，即AVP軟件系統(tǒng)中所有AP應(yīng)用發(fā)送的Offer Service報(bào)文，報(bào)文中包含了服務(wù)Id，服務(wù)實(shí)例Id，服務(wù)實(shí)例通信地址等信息。

J3A啟動信息采集應(yīng)用與感知應(yīng)用，對外提供相應(yīng)的服務(wù)。感知應(yīng)用周期性發(fā)送代價(jià)地圖的信息，代價(jià)地圖的數(shù)據(jù)與Simulink仿真中的數(shù)據(jù)保持一致，以驗(yàn)證部署到AP的路徑規(guī)劃模塊與Simulink仿真中路徑規(guī)劃應(yīng)用的結(jié)果一致性。J3B的行為規(guī)劃應(yīng)用和路徑規(guī)劃應(yīng)用啟動后，發(fā)送查找所需服務(wù)的SOME/IP報(bào)文，以定位服務(wù)所在的地址，訂閱需要的Event。路徑規(guī)劃應(yīng)用在接收到代價(jià)地圖、當(dāng)前位置等信息后，會根據(jù)部署的路徑規(guī)劃算法計(jì)算出到達(dá)下一目標(biāo)位置的所有路徑點(diǎn)和到達(dá)時(shí)運(yùn)動方向，并將計(jì)算結(jié)果以RefPoses和Directions Event的方式發(fā)送到所有Event訂閱者。PC中的控制應(yīng)用啟動后，訂閱路徑規(guī)劃應(yīng)用提供的RefPoses和Directions Event?？刂茟?yīng)用對收到的RefPoses與Directions數(shù)值進(jìn)行分析與Simulink算法仿真的計(jì)算結(jié)果一致。

通過上述試驗(yàn)結(jié)果可以驗(yàn)證，AVP中各個(gè)AP應(yīng)用通過SOME/IP協(xié)議實(shí)現(xiàn)面向服務(wù)的通信功能是正常的，并且通過Simulink進(jìn)行算法建模，生成C++代碼，集成到AP應(yīng)用的開發(fā)方式是可行的。

4.2.2 基于AP監(jiān)控方案的AVP例程測試

將開發(fā)的AP監(jiān)控方案的數(shù)據(jù)采集模塊安裝到Pilot3.0控制器中，虛擬機(jī)中安裝監(jiān)控?cái)?shù)據(jù)分析與存儲模塊，PC中安裝數(shù)據(jù)顯示模塊如圖23所示。

數(shù)據(jù)顯示模塊使用Qt工具開發(fā)UI界面（見圖24），支持通過LT協(xié)議與AP應(yīng)用相連，或者從分析與存儲模塊獲取離線數(shù)據(jù)，并以圖形化的形式顯示AVP例程中服務(wù)和平臺相關(guān)的監(jiān)測數(shù)據(jù)。

AP服務(wù)監(jiān)控功能實(shí)現(xiàn)了對Method響應(yīng)時(shí)間、Event發(fā)送/接收時(shí)間間隔的信息采集以及顯示功能，列表中顯示了所有Method，Event相關(guān)的上報(bào)信息，并將信息加以處理，顯示出Method響應(yīng)時(shí)間和Event 發(fā)送/接收時(shí)間的時(shí)間間隔的分布圖，折線圖中顯示了上述兩個(gè)變量隨時(shí)間變化的曲線。

以路徑規(guī)劃模塊提供的PathService為例，該模塊中部署了路徑規(guī)劃算法，控制應(yīng)用調(diào)用了PathService 中GetRefPoses Method200次后，該Method的響應(yīng)時(shí)間分布見圖25，從圖中能夠看出響應(yīng)時(shí)間主要集中在232 ms左右。

基礎(chǔ)設(shè)施監(jiān)控功能顯示了AP相關(guān)基礎(chǔ)設(shè)施的工作狀態(tài)，包括了網(wǎng)絡(luò)延遲、CPU使用率、CPU負(fù)載和內(nèi)存使用率的時(shí)間變化曲線。

通過對J3B的基礎(chǔ)設(shè)施進(jìn)行監(jiān)控，從監(jiān)控?cái)?shù)據(jù)能夠看出AP啟動前后基礎(chǔ)設(shè)施狀態(tài)的對比。網(wǎng)絡(luò)延遲在AP啟動后未發(fā)生較大改變（見圖26），因?yàn)楫?dāng)網(wǎng)絡(luò)中報(bào)文數(shù)量沒有發(fā)生擁堵時(shí)，網(wǎng)絡(luò)延遲不會有明顯上升。CPU使用率從0%上升到了8.5%左右（見圖27），反映了AP和AVP應(yīng)用啟動后使用的CPU。CPU負(fù)載未出現(xiàn)明顯的上升（見圖28），根據(jù)3.2節(jié)分析，當(dāng)CPU使用率過高時(shí)才會引起CPU負(fù)載的上升，CPU使用率維持在8.5%水平時(shí)，不會造成明顯的進(jìn)程排隊(duì)（CPU負(fù)載）。內(nèi)存使用率反映了AP和AVP應(yīng)用需要消耗的內(nèi)存，從內(nèi)存使用率曲線圖中可以看到（見圖29），路徑規(guī)劃應(yīng)用、行為規(guī)劃應(yīng)用以及AP總共使用了J3B 0.6%的內(nèi)存，J3B中總共4 GB內(nèi)存，也就是24.5 MB左右的內(nèi)存。

調(diào)用鏈追蹤功能夠根據(jù)調(diào)用鏈組件上報(bào)Dlt日志，分析出服務(wù)調(diào)用鏈信息。圖30顯示了調(diào)用鏈追蹤相關(guān)的信息列表，包含了時(shí)間、Trace Id、Method Id等信息。圖31顯示了其中一條調(diào)用鏈的調(diào)用關(guān)系，即控制應(yīng)用調(diào)用路徑規(guī)劃模塊的GetRefPoses Method時(shí)的服務(wù)調(diào)用關(guān)系。從圖中可以看到，控制應(yīng)用調(diào)用該方法時(shí)，共計(jì)用時(shí)304 ms。GetRefPoses共調(diào)用了其他服務(wù)中的四個(gè)Method，其中RefCostmapGetter方法耗時(shí)最多，消耗了165 ms，原因是代價(jià)地圖的數(shù)據(jù)比較大，數(shù)據(jù)傳輸時(shí)消耗時(shí)間較長。

4.3 AP服務(wù)容錯(cuò)測試

AP服務(wù)容錯(cuò)機(jī)制的測試中，將以路徑規(guī)劃應(yīng)用為例，測試不同容錯(cuò)機(jī)制的表現(xiàn)將冗余的路徑規(guī)劃應(yīng)用安裝到J3C中（見圖32），AVP軟件系統(tǒng)中存在了兩個(gè)提供PathService的服務(wù)實(shí)例。從CANoe中抓取的報(bào)文中可以看到（見圖33），PathService（服務(wù)ID為006A）有兩個(gè)不同的服務(wù)實(shí)例，服務(wù)實(shí)例ID分別為306和320。

AP服務(wù)容錯(cuò)測試通過對AP路徑規(guī)劃應(yīng)用注入故障的方式進(jìn)行測試。本試驗(yàn)對路徑規(guī)劃應(yīng)用與冗余的路徑規(guī)劃應(yīng)用，在一個(gè)故障注入周期內(nèi)注入連續(xù)的服務(wù)故障時(shí)間，并且這連續(xù)的服務(wù)故障時(shí)間會隨機(jī)的出現(xiàn)在一個(gè)故障注入周期中。失敗重試中最大重試次數(shù)設(shè)置為3次，等待時(shí)間的基數(shù)設(shè)置為5 ms。該試驗(yàn)中，因?yàn)槁窂揭?guī)劃應(yīng)用和冗余應(yīng)用有概率同時(shí)出現(xiàn)故障，失敗轉(zhuǎn)移和聚合調(diào)用也會采用失敗重試，參數(shù)與單獨(dú)使用失敗重試時(shí)相同。當(dāng)在1 s故障注入周期內(nèi)注入100 ms服務(wù)故障時(shí)間時(shí)，試驗(yàn)結(jié)果如下：未采取任何容錯(cuò)措施時(shí)（見圖34），故障率為10%，符合本試驗(yàn)注入故障的時(shí)間比例；當(dāng)采用重試的容錯(cuò)機(jī)制時(shí)（見圖35），故障率降至0，平均響應(yīng)時(shí)間為228.767 ms，最長響應(yīng)時(shí)間為599.253 ms，能夠顯著減少故障率；采用錯(cuò)誤轉(zhuǎn)移時(shí)（見圖36），平均響應(yīng)時(shí)間為229.904 ms，最慢響應(yīng)時(shí)間586.102 ms。采用聚合調(diào)用機(jī)制時(shí)（見圖37），平均響應(yīng)時(shí)間為221.808 ms，最慢響應(yīng)時(shí)間為423.519 ms。

對PathService采用聚合調(diào)用的容錯(cuò)策略，需要新啟用一個(gè)微處理器做冗余，并且每次都需要所有的路徑規(guī)劃應(yīng)用做運(yùn)算，資源消耗很大。然而根據(jù)上述試驗(yàn)結(jié)果，聚合調(diào)用策略并沒有起到特別優(yōu)異的效果。通過對基礎(chǔ)設(shè)施的監(jiān)控發(fā)現(xiàn)，當(dāng)采用聚合調(diào)用的容錯(cuò)策略時(shí)，會對網(wǎng)絡(luò)造成非常大的擁堵。如圖38所示，937.8 s 后采用了聚合調(diào)用的容錯(cuò)策略，此時(shí)的網(wǎng)絡(luò)延遲相比于其他容錯(cuò)策略高了很多，這是造成聚合調(diào)用策略 Method響應(yīng)時(shí)間很高的原因。

造成網(wǎng)絡(luò)延遲升高的主要原因是，采用容錯(cuò)策略，服務(wù)調(diào)用方的每次服務(wù)調(diào)用都會對2個(gè)服務(wù)實(shí)例發(fā)送服務(wù)請求，網(wǎng)絡(luò)負(fù)載將是未啟用該策略時(shí)的2倍。CANoe軟件捕獲的PC上網(wǎng)卡的收發(fā)數(shù)據(jù)量表明，當(dāng)采用聚合調(diào)用策略后，數(shù)據(jù)量提升了一倍。當(dāng)路徑規(guī)劃應(yīng)用與冗余的路徑規(guī)劃應(yīng)用收到服務(wù)請求后，均會請求更多的服務(wù)，尤其是獲取代價(jià)地圖的方法（RefCostmapGetter），會傳輸大量的數(shù)據(jù)，當(dāng)這些代價(jià)地圖數(shù)據(jù)需要傳輸兩次時(shí)，網(wǎng)絡(luò)就有可能產(chǎn)生擁堵的情況。

為了對短時(shí)間不可恢復(fù)故障下不同容錯(cuò)機(jī)制的表現(xiàn)進(jìn)行測試，本試驗(yàn)分別在1 s故障注入周期內(nèi)注入 100 ms服務(wù)故障時(shí)間；1 s故障注入周期內(nèi)注入200 ms 服務(wù)故障時(shí)間；5 s故障注入周期內(nèi)注入500 ms服務(wù)故障時(shí)間；5 s故障注入周期內(nèi)注入1 s服務(wù)故障時(shí)間4種情況下，對比不同容錯(cuò)機(jī)制的表現(xiàn)。結(jié)果如圖39所示，通過采用服務(wù)容錯(cuò)機(jī)制，能夠有效地減少調(diào)用服務(wù)時(shí)的故障率。

5 結(jié)論與展望

5.1 結(jié)論

對AUTOSAR自適應(yīng)平臺采取監(jiān)控與容錯(cuò)機(jī)制，能夠提升故障分析效率，降低故障發(fā)生率，提高軟件系統(tǒng)可靠性。研究了AP的工作原理與開發(fā)流程，以及適用于AP的監(jiān)控方案和服務(wù)故障發(fā)生時(shí)的容錯(cuò)機(jī)制?？偨Y(jié)如下：

（1）針對AP缺少監(jiān)控機(jī)制、面向服務(wù)架構(gòu)中故障定位困難的問題，以AVP軟件系統(tǒng)為案例，提出了AP的監(jiān)控方案。

（2）針對AP沒有提供故障容錯(cuò)機(jī)制的問題，提出了基于AP的失敗重試、失敗轉(zhuǎn)移和聚合調(diào)用3種容錯(cuò)機(jī)制。

5.2 展望

采用面向服務(wù)架構(gòu)的AUTOSAR自適應(yīng)平臺為研究對象，對其工作原理和整體架構(gòu)進(jìn)行了分析，并以AVP軟件系統(tǒng)為例，針對AP缺少監(jiān)控機(jī)制、面向服務(wù)架構(gòu)中故障定位困難問題以及運(yùn)行階段可能出現(xiàn)服務(wù)故障問題，設(shè)計(jì)了監(jiān)控方案和容錯(cuò)機(jī)制，通過AVP軟件系統(tǒng)驗(yàn)證了上述功能的可行性，但在下述方面仍有欠缺：

（1）監(jiān)控方案采集了當(dāng)前系統(tǒng)基礎(chǔ)設(shè)施的狀態(tài)以及服務(wù)的響應(yīng)時(shí)間，能夠分析出當(dāng)前的系統(tǒng)狀態(tài)。換言之，只有出現(xiàn)故障時(shí)，監(jiān)控方案才能發(fā)現(xiàn)。進(jìn)一步工作可以根據(jù)當(dāng)前采集的數(shù)據(jù)，預(yù)測出未來是否可能發(fā)生故障，這樣將能夠在故障發(fā)生前采取相應(yīng)措施。

（2）容錯(cuò)機(jī)制中采取服務(wù)冗余的方式能夠提高服務(wù)的可靠性，然而冗余服務(wù)造成的數(shù)據(jù)量增加有可能導(dǎo)致網(wǎng)絡(luò)擁堵。進(jìn)一步工作可以考慮對網(wǎng)絡(luò)結(jié)構(gòu)進(jìn)行優(yōu)化，避免所有報(bào)文都需要從同一交換芯片進(jìn)行轉(zhuǎn)發(fā)，該交換芯片滿負(fù)載可能會造成通信網(wǎng)絡(luò)整體堵塞。

參 考 文 獻(xiàn)

[1] 初士雨， 安濤， 王秋鋒. 中國新能源汽車產(chǎn)業(yè)發(fā)展展望[J]. 科研， 2016， 17（7）： 209-210.

[2] 劉佳熙， 丁鋒. 面向未來汽車電子電氣架構(gòu)的域控制器平臺[J]. 中國集成電路， 2019， 28（9）： 82-87.

[3] 稀土信息編輯部. 國家發(fā)布《智能汽車創(chuàng)新發(fā)展戰(zhàn)略》智能汽車正加速駛來[J]. 稀土信息， 2020（3）： 33-35.

[4] 劉宗巍， 匡旭， 趙福全. 中國車聯(lián)網(wǎng)產(chǎn)業(yè)發(fā)展現(xiàn)狀， 瓶頸及應(yīng)對策略[J]. 科技管理研究， 2016（4）： 121-127.

[5] 賈文偉， 徐匡一， 王海波， 等.智能汽車電子架構(gòu)分析與研究[J]. 時(shí)代汽車， 2020（4）： 43-46.

[6] 孫婭蘋， 田慧蓉.車聯(lián)網(wǎng)網(wǎng)絡(luò)安全標(biāo)準(zhǔn)化研究進(jìn)展[J]. 電信網(wǎng)技術(shù)， 2017 （6）： 18-21.

[7] 李兵， 趙磊， 林方圓.車載信息娛樂系統(tǒng)軟件開發(fā)流程研究與應(yīng)用[J]. 汽車實(shí)用技術(shù)， 2019（20）： 3.

[8] 吳鍇. 智能自動泊車系統(tǒng)研究[D]. 南京： 南京理工大學(xué)， 2008.

[9] BAYYOU D. Artificially Intelligent Self-driving Vehicle Technologies， Benefits and Challenges[J]. International Journal of Emerging Technology in Computer Science and Electronics， 2019， 26（3）： 5-13.

[10] TRAUB M， MAIER A， BARBEH?N K L. Future Automotive Architecture and the Impact of IT Trends[J]. IEEE Software， 2017， 34（3）： 27-32.

[11] F?RST S， BECHTER M. AUTOSAR for Connected and Autonomous Vehicles： The AUTOSAR Adaptive Platform [C]//2016 46th Annual IEEE/IFIP International Conference on Dependable Systems and Networks Workshop （DSN-W）， 2016.

[12] STOLZ W， KORNHAAS R， KRAUSE R， et al. Domain Control Units-the Solution for Future E/E Architectures[J]. SAE Technical Paper， 2010.

[13] NAVALE V M， WILLIAMS K， LAGOSPIRIS A， et al. （R） Evolution of E/E architectures[J]. SAE International Journal of Passenger Cars-Electronic and Electrical Systems， 2015， 8（2）： 282-288.

[14] CHEN S， HU J， SHI Y， et al. Vehicle-to-everything （V2X） Services Supported by LTE-based Systems and 5G[J]. IEEE Communications Standards Magazine， 2017， 1（2）： 70-76.

[15] YAQOOB I， KHAN L U， KAZMI S M A， et al. Autonomous Driving Cars in Smart Cities： Recent Advances， Requirements， and Challenges[J]. IEEE Network， 2019， 34（1）： 174-181.

[16] 劉聰， 陳敏. 面向服務(wù)的電子電氣架構(gòu)研究與應(yīng)用[J]. 北京汽車， 2021（6）： 34-40.

[17] BARRY D K. Web Services， Service-oriented Architectures， and Cloud Computing[EB/OL]. 2003[2024-05-11]. https：//www.service-architecture.com.

[18] 于磊， 林宗楷， 郭玉釵， 等. 多服務(wù)器系統(tǒng)中的負(fù)載平衡與容錯(cuò)[J].系統(tǒng)仿真學(xué)報(bào)， 2001， 13（3）： 325-328.

[19] 童蕾. 事件驅(qū)動的消息發(fā)布/訂閱研究和實(shí)現(xiàn)[D]. 北京： 中國科學(xué)院研究生院 （軟件研究所）， 2005.

[20] DONOVAN P. Payback Time for Network Management[J]. Telecommunications， 2000， 34（1）： 71.

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