基于AUTOSAR自適應平臺的監控與容錯方案研究

朱元 趙乾翔 張彪 畢承鼎

【歡迎引用】 朱元， 趙乾翔， 張彪， 等. 基于AUTOSAR自適應平臺監控與容錯方案研究[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.

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

關鍵詞：AUTOSAR；面向服務架構；平臺監控；容錯機制

中圖分類號：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 引言

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

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

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

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

1 AUTOSAR自適應平臺數據監測方案

1.1 設計方案

針對AP平臺，設計了數據監測系統（圖1），包括分布式數據采集模塊及其軟件應用組件（Software Compenent， SWC）在ARA（AUTOSAR Runtime for Adaptive Applications）上運行，數據存儲與分析模塊，數據顯示模塊。

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

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

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

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

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

1.2 監測數據選擇

數據監測模塊中的數據指標的選取需要確保該指標確實與服務狀態直接或間接相關，并在記錄時標上監測的時間信息，形成數據在時間上的關聯。

在AP中，與SOME/IP服務相關的直接數據指標包括：

（1）Method響應時間

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

Method響應時間有2種計算方式，一種是從服務提供方角度進行計算，即服務提供方接收到Method請求和完成Method計算的時間間隔；另一種是從服務調用方角度進行計算，即服務調用方發起Method和接收到結果的時間間隔。與前者相比，后者計算出的響應時間包括了中間件對服務報文的處理時間和服務報文在網絡中的傳輸時間。本設計中，這2種Method響應時間都應被監測。

對于Method響應時間這項數據指標，在具體實現上，應當由服務提供方和服務調用方主動上報，上報格式為見圖3。

其中Context用來區分Method響應時間的計算方式，“Call”表示服務調用方計算的響應時間，“Impl”表示服務提供方計算的響應時間。

（2）Event發送/接收時間間隔

在AP中，Event可以被用來傳輸周期性的數據（例如周期性采集的雷達數據）。這種應用場景下，該周期必須是確定的，如果服務調用方在周期間隔內未收到 Event數據，可能會導致服務調用方故障。

Event發送時間是服務提供方的Event發送時間點，Event接收時間是服務接收方接收到Event的時間。

對于Event發送/接受時間這項數據指標，在具體實現上，應當由服務提供方和服務調用方主動上報，上報格式見圖4。

其中Context用來區分Event發送/接收時間，“Send”表示Event發送時間，“Recv”表示Event接收時間。

除了服務狀態的直接數據指標外，數據監測模塊還應當采集與SOME/IP服務相關的基礎設施數據指標：

（3）CPU利用率與CPU負載

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

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

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

（4）網絡延遲

延遲通常采用網絡數據包從發送端到接收端再回到接收端所經歷的時間。分布式架構對底層網絡十分依賴，網絡的運行狀況直接影響服務的健康狀況。當網絡發生擁堵時，會造成服務的響應時間變長，進而通過服務間的依賴引起連鎖反應。

（5）內存使用率

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

數據采集模塊負責周期性地對基礎設施數據指標進行采集，并將采集到的數據日志形式上報至數據分析與存儲模塊以及數據顯示模塊，基礎設施數據的Dlt日志結構見圖5。

1.3 數據顯示模塊

數據顯示模塊是安裝在PC中的上位機程序，能夠對監控數據進行可視化的展示，監控數據可以使用離線數據，也可以通過LT協議對監控數據進行采集（見圖6）。

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

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

2 服務調用鏈追蹤

汽車軟件系統中會存在大量的服務和服務節點，同時服務節點之間會存在復雜的服務調用關系，如：A服務調用B服務，B服務調用C和D服務。在這樣的情況下，如果C服務出現故障，那么B服務和A服務將也會出現故障。

如果選用傳統的故障定位方式，通過日志模塊將每個節點調用服務和被請求服務的行為記錄到日志中，逐一分析日志的來排查故障。但是這些服務節點的日志是分散的，彼此沒有很強的聯系，無法從中整理出C服務故障是B服務與A服務故障的根本原因。為了將這些服務節點的內部行為和相互關系加以整理，本章引入了服務調用鏈動態追蹤技術。通過這樣的技術，能夠將一條完整的服務調用鏈信息從離散的服務節點日志中提取出來，這條調用鏈信息包含了所有服務節點，服務調用關系，服務處理時間、時延和故障信息。

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

2.1 設計方案

在服務調用方安裝調用鏈追蹤工具Client組件，在服務提供方安裝調用鏈追蹤工具Server組件，在PC上安裝調用鏈追蹤工具。服務調用鏈追蹤系統結構見圖7，服務調用鏈追蹤系統時序圖見圖8。

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

如果AP應用B服務繼續調用其他服務時，會將自身的信息加入調用鏈信息，繼續重復上述操作。

數據顯示模塊會收集上述所有的日志信息，通過Trace Id將所有調用鏈信息日志加以區分，最終分析出每一條調用鏈的信息，并以可視化形式展現。

2.2 調用鏈信息報文設計

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

（1）Trace Id [32 bit]

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

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

（2）Span Id [32 bit]

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

（3）Parent Id [32 bit]

當服務調用方向服務提供方調用服務時，服務調用方的Span Id即為服務提供方的Parent Id。通過每一個調用鏈信息中Span Id和Parent Id就能分析出該條調用鏈的服務調用關系。

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

即為服務調用方的Client Id和服務調用方調用服務時的Session Id。在同一時間，可能有多個服務調用方并發訪問服務提供方提供的同一服務，這些 SOME/IP服務請求報文的到達時間與調用鏈信息報文的到達時間并不是有序的。通過比對SOME/IP服務請求報文中的Client Id與Session Id與調用鏈信息報文中的Client Id與Session Id，能夠將調用鏈信息報文與 SOME/IP報文唯一關聯。

（5）請求服務的Service Id與Method Id

一個AP應用會同時作為多個服務的服務提供方，在調用鏈信息報文中加入Service Id和Method Id，能夠幫助調用鏈追蹤工具Server組件準確的識別該條調用鏈信息報文是與哪個服務相關聯的。

2.3 Dlt日志設計

調用鏈信息由調用鏈追蹤工具Server和Client組件通過Dlt模塊以日志的形式，發送至調用鏈追蹤工具，調用鏈追蹤工具通過收集和處理這些包含了調用鏈信息的日志分析調用鏈的服務調用關系和其他信息。為了與其他的日志加以區分，服務調用鏈日志將LT協議的Extended Header中Context Id設置為“Trace”作為標記。

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

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

2.4 調用鏈信息報文處理與傳輸的實現

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

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

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

當接收到SOME/IP服務請求時，觸發調用鏈追蹤工具Server組件的主流程，如圖14a所示。根據SOME/IP服務請求中的Client Id、Session Id、Service Id和Method Id信息查找對應的服務調用鏈信息。因為網絡傳輸的不確定性，SOME/IP報文和服務調用鏈信息的報文到達服務提供方的先后順序未知，如果此時服務調用鏈信息的報文未到達，則等待，直到完成查找。服務調用鏈信息查找完成后，通過Dlt模塊向調用鏈追蹤工具發送包含調用鏈信息的日志。設置執行調用的上下文信息，即Trace Id和Span Id，并執行此次服務請求的調用。服務調用執行完成后，通過Dlt模塊向調用鏈追蹤工具發送包含調用鏈信息的日志。

3 AUTOSAR自適應平臺服務容錯機制

3.1 汽車面向服務架構的服務容錯概述

在面向服務架構中，服務錯誤可能無法完全避免，表現為服務無響應或對于時間要求嚴格的服務未能在規定時間內響應。對于汽車環境內時間敏感的軟件，服務未及時響應意味著服務不可用。

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

（1）基礎設施故障：例如，CPU負載過高、內存不足、存儲器訪問速度過慢等，導致服務執行時間超出規定，無法按時響應。

（2）網絡故障：例如網絡擁塞、數據包丟失、網絡中斷，導致服務底層網絡報文無法或無法按時到達服務。

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

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

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

3.2 失敗重試

失敗重試是一種策略，指的是在服務調用出現錯誤時，會在一定的時間間隔后重新嘗試調用該服務，直到服務能夠正常響應，見圖16。

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

3.2.1 服務重試風暴問題

服務重試能夠應對網絡擁堵等問題導致的服務調用錯誤，但重試的頻率和策略必須慎重設計，否則可能引發系統中的服務重試風暴災難。

服務失敗重試的前提是故障可能在一段時間內得以恢復，但通常恢復時間不會特別快。如果服務調用方在短時間內頻繁發起大量服務重試，可能會加劇故障。例如，如果網絡擁塞導致服務超時，若持續進行大量服務重試，將進一步加劇網絡擁堵，進而造成更大規模的服務故障。

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

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

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

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

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

然而，當網絡在特定時刻發生擁堵時，大量服務超時，并在同樣的等待時間后發起服務重試，極有可能再次引發網絡擁堵，此種現象稱為“服務重試碰撞”。

為了避免這種碰撞現象的發生，必須保證每個服務調用方的服務重試時間是不同的，因此將服務重試時間調整為：

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

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

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

a.如果服務調用方首次調用服務超時，則在等待0 ms 或2 ms發起服務重試。

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

c.當重試4次后仍然無法正常調用該服務，則重試終止。

針對產生服務重試風暴的第二種場景，本方案采用了限制鏈路失敗重試，即當一條調用鏈路中的A服務在盡力嘗試服務失敗重試后仍無法完成服務調用后，調用A服務的服務不應繼續采用服務失敗重試。

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

a.設計統一的服務調用失敗錯誤碼，用來表示本服務已經采用服務失敗重試，仍發生錯誤。

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

c.上一層服務調用者收到該錯誤碼后，不會繼續執行服務重試，直接向更上一層傳遞該錯誤碼。

3.3 失敗轉移機制

3.3.1 失敗轉移策略

失敗重試雖然可以在一段時間內可恢復的故障情況下確保服務的可用性，但并不適用于故障無法短時間內恢復或對于響應時間要求嚴格的場景，如感知服務和路徑規劃服務。在這些情況下，長時間無響應可能帶來嚴重后果。

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

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

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

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

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

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

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

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

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

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

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

3.3.2 失敗轉移實現

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

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

這種方法允許系統中的服務調用方靈活地使用可用的服務實例，從而實現了失敗轉移策略，提高了系統的可用性和穩定性。

3.4 聚合調用機制

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

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

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

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

除了消耗更多的操作系統內存資源外，聚合調用可能會對CPU和網絡資源造成更高的負載。飽和式的服務請求可能會導致更多的CPU資源和網絡資源消耗，增加系統的負擔，可能對系統整體性能產生影響。在汽車軟件中，這對于執行模塊等對服務響應時間要求較高的模塊來說，可能會對系統性能和穩定性產生影響。

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

聚合調用、失敗重試與失敗轉移是三種服務容錯機制，它們在消耗系統資源和代碼入侵程度上各不相同，同時最終實現的容錯效果也有所差異（見表1）。因此，在選擇適當的服務容錯機制時，應根據AP應用的重要程度進行權衡和選擇。

4 測試與分析

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

4.1 測試環境

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

PC機運行AP應用的測試工具CANoe軟件和AP 應用監控數據顯示模塊，參數見表3。

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

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

4.2 基于AP的AVP軟件系統測試

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

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

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

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

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

4.2.2 基于AP監控方案的AVP例程測試

將開發的AP監控方案的數據采集模塊安裝到Pilot3.0控制器中，虛擬機中安裝監控數據分析與存儲模塊，PC中安裝數據顯示模塊如圖23所示。

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

AP服務監控功能實現了對Method響應時間、Event發送/接收時間間隔的信息采集以及顯示功能，列表中顯示了所有Method，Event相關的上報信息，并將信息加以處理，顯示出Method響應時間和Event 發送/接收時間的時間間隔的分布圖，折線圖中顯示了上述兩個變量隨時間變化的曲線。

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

基礎設施監控功能顯示了AP相關基礎設施的工作狀態，包括了網絡延遲、CPU使用率、CPU負載和內存使用率的時間變化曲線。

通過對J3B的基礎設施進行監控，從監控數據能夠看出AP啟動前后基礎設施狀態的對比。網絡延遲在AP啟動后未發生較大改變（見圖26），因為當網絡中報文數量沒有發生擁堵時，網絡延遲不會有明顯上升。CPU使用率從0%上升到了8.5%左右（見圖27），反映了AP和AVP應用啟動后使用的CPU。CPU負載未出現明顯的上升（見圖28），根據3.2節分析，當CPU使用率過高時才會引起CPU負載的上升，CPU使用率維持在8.5%水平時，不會造成明顯的進程排隊（CPU負載）。內存使用率反映了AP和AVP應用需要消耗的內存，從內存使用率曲線圖中可以看到（見圖29），路徑規劃應用、行為規劃應用以及AP總共使用了J3B 0.6%的內存，J3B中總共4 GB內存，也就是24.5 MB左右的內存。

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

4.3 AP服務容錯測試

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

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

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

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

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

5 結論與展望

5.1 結論

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

（1）針對AP缺少監控機制、面向服務架構中故障定位困難的問題，以AVP軟件系統為案例，提出了AP的監控方案。

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

5.2 展望

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

（1）監控方案采集了當前系統基礎設施的狀態以及服務的響應時間，能夠分析出當前的系統狀態。換言之，只有出現故障時，監控方案才能發現。進一步工作可以根據當前采集的數據，預測出未來是否可能發生故障，這樣將能夠在故障發生前采取相應措施。

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

參 考 文 獻

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

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

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

[4] 劉宗巍， 匡旭， 趙福全. 中國車聯網產業發展現狀， 瓶頸及應對策略[J]. 科技管理研究， 2016（4）： 121-127.

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

[6] 孫婭蘋， 田慧蓉.車聯網網絡安全標準化研究進展[J]. 電信網技術， 2017 （6）： 18-21.

[7] 李兵， 趙磊， 林方圓.車載信息娛樂系統軟件開發流程研究與應用[J]. 汽車實用技術， 2019（20）： 3.

[8] 吳鍇. 智能自動泊車系統研究[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] 劉聰， 陳敏. 面向服務的電子電氣架構研究與應用[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] 于磊， 林宗楷， 郭玉釵， 等. 多服務器系統中的負載平衡與容錯[J].系統仿真學報， 2001， 13（3）： 325-328.

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

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

（責任編輯 明慧）