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

朱元 趙乾翔 張彪 畢承鼎

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

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

中圖分類號：TP311.131 ? 文獻標志碼：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]。為了滿足汽車日益增長的高計算需求，多核高性能微處理器正逐步應(yīng)用于汽車控制系統(tǒng)[12-13]。這些微處理器被用作域控制器，能夠整合原本分散在不同小型控制器中的功能，同時承擔更復雜的智能駕駛算法[14-15]。

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

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

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

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

1.1 設(shè)計方案

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（3）CPU利用率與CPU負載

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

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

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

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

延遲通常采用網(wǎng)絡(luò)數(shù)據(jù)包從發(fā)送端到接收端再回到接收端所經(jīng)歷的時間。分布式架構(gòu)對底層網(wǎng)絡(luò)十分依賴，網(wǎng)絡(luò)的運行狀況直接影響服務(wù)的健康狀況。當網(wǎng)絡(luò)發(fā)生擁堵時，會造成服務(wù)的響應(yīng)時間變長，進而通過服務(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)存資源耗盡時，會將一些內(nèi)存中的數(shù)據(jù)轉(zhuǎn)移到容量更大的外部存儲器中，以緩解內(nèi)存的緊張。

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

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

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

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

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

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

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

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

2.1 設(shè)計方案

在服務(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)時序圖見圖8。

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

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

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

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

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

（1）Trace Id [32 bit]

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

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

（2）Span Id [32 bit]

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

（3）Parent Id [32 bit]

當服務(wù)調(diào)用方向服務(wù)提供方調(diào)用服務(wù)時，服務(wù)調(diào)用方的Span Id即為服務(wù)提供方的Parent Id。通過每一個調(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ù)時的Session Id。在同一時間，可能有多個服務(wù)調(diào)用方并發(fā)訪問服務(wù)提供方提供的同一服務(wù)，這些 SOME/IP服務(wù)請求報文的到達時間與調(diào)用鏈信息報文的到達時間并不是有序的。通過比對SOME/IP服務(wù)請求報文中的Client Id與Session Id與調(diào)用鏈信息報文中的Client Id與Session Id，能夠?qū)⒄{(diào)用鏈信息報文與 SOME/IP報文唯一關(guān)聯(lián)。

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

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

2.3 Dlt日志設(shè)計

調(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”作為標記。

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

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

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

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

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

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

當接收到SOME/IP服務(wù)請求時，觸發(fā)調(diào)用鏈追蹤工具Server組件的主流程，如圖14a所示。根據(jù)SOME/IP服務(wù)請求中的Client Id、Session Id、Service Id和Method Id信息查找對應(yīng)的服務(wù)調(diào)用鏈信息。因為網(wǎng)絡(luò)傳輸?shù)牟淮_定性，SOME/IP報文和服務(wù)調(diào)用鏈信息的報文到達服務(wù)提供方的先后順序未知，如果此時服務(wù)調(diào)用鏈信息的報文未到達，則等待，直到完成查找。服務(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ù)容錯機制

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

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

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

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

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

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

當服務(wù)調(diào)用方調(diào)用的服務(wù)出現(xiàn)錯誤時，沒有合適的容錯機制，錯誤可能會擴散，導致整個服務(wù)鏈路出現(xiàn)問題，造成更嚴重的“服務(wù)雪崩”現(xiàn)象，見圖15。

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

3.2 失敗重試

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

這種策略適用于對服務(wù)響應(yīng)時間要求非常嚴格的場景。通過同時發(fā)起多個服務(wù)調(diào)用，可以顯著縮短服務(wù)的響應(yīng)時間，因為只需等待任意一個服務(wù)實例的響應(yīng)即可立即返回結(jié)果。這樣可以提高系統(tǒng)的可用性和性能，并確保即使部分服務(wù)實例出現(xiàn)問題，系統(tǒng)仍能繼續(xù)工作。

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

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

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

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

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

4 測試與分析

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

4.1 測試環(huán)境

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

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

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

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

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

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

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

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

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

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

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

將開發(fā)的AP監(jiān)控方案的數(shù)據(jù)采集模塊安裝到Pilot3.0控制器中，虛擬機中安裝監(jiān)控數(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)控功能實現(xiàn)了對Method響應(yīng)時間、Event發(fā)送/接收時間間隔的信息采集以及顯示功能，列表中顯示了所有Method，Event相關(guān)的上報信息，并將信息加以處理，顯示出Method響應(yīng)時間和Event 發(fā)送/接收時間的時間間隔的分布圖，折線圖中顯示了上述兩個變量隨時間變化的曲線。

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

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

通過對J3B的基礎(chǔ)設(shè)施進行監(jiān)控，從監(jiān)控數(shù)據(jù)能夠看出AP啟動前后基礎(chǔ)設(shè)施狀態(tài)的對比。網(wǎng)絡(luò)延遲在AP啟動后未發(fā)生較大改變（見圖26），因為當網(wǎng)絡(luò)中報文數(shù)量沒有發(fā)生擁堵時，網(wǎng)絡(luò)延遲不會有明顯上升。CPU使用率從0%上升到了8.5%左右（見圖27），反映了AP和AVP應(yīng)用啟動后使用的CPU。CPU負載未出現(xiàn)明顯的上升（見圖28），根據(jù)3.2節(jié)分析，當CPU使用率過高時才會引起CPU負載的上升，CPU使用率維持在8.5%水平時，不會造成明顯的進程排隊（CPU負載）。內(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)用鏈組件上報Dlt日志，分析出服務(wù)調(diào)用鏈信息。圖30顯示了調(diào)用鏈追蹤相關(guān)的信息列表，包含了時間、Trace Id、Method Id等信息。圖31顯示了其中一條調(diào)用鏈的調(diào)用關(guān)系，即控制應(yīng)用調(diào)用路徑規(guī)劃模塊的GetRefPoses Method時的服務(wù)調(diào)用關(guān)系。從圖中可以看到，控制應(yīng)用調(diào)用該方法時，共計用時304 ms。GetRefPoses共調(diào)用了其他服務(wù)中的四個Method，其中RefCostmapGetter方法耗時最多，消耗了165 ms，原因是代價地圖的數(shù)據(jù)比較大，數(shù)據(jù)傳輸時消耗時間較長。

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

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

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

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

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

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

5 結(jié)論與展望

5.1 結(jié)論

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

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

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

5.2 展望

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

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

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

參 考 文 獻

[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]. 時代汽車， 2020（4）： 43-46.

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

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

[8] 吳鍇. 智能自動泊車系統(tǒng)研究[D]. 南京： 南京理工大學， 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)中的負載平衡與容錯[J].系統(tǒng)仿真學報， 2001， 13（3）： 325-328.

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

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

（責任編輯 明慧）