某車型啟動后快速請求燈光無響應問題分析

【摘" 要】文章針對某車型啟動后快速請求燈光無響應問題進行分析研究，系統分析問題產生的原因，重點聚焦在SOME/IP通信丟幀上，進而追溯到SOME/IP服務發現及服務建立上，并對多個優化及解決辦法進行分析以及對性能進行比對之后，提出最終的解決辦法，對類似SOME/IP丟幀等問題的解決有重要的指導意義和實際工程應用價值。

【關鍵詞】以太網;SOME/IP;服務發現;線程池

中圖分類號：U463.65" " 文獻標識碼：B" " 文章編號：1003-8639（ 2024 ）06-0078-05

Research on the Problem of No Response to Rapid Request for Lighting After Vehicle Started

ZHANG Qichao，LI Zhenpeng

（Zhitu（Shanghai）Intelligent Technology Co.，Ltd.，Shanghai 200082，China）

【Abstract】This article analyzes and studies the problem of no response to rapid light requests after vehicle is started. Analyzed the causes of the problem，focusing on the loss of frames in SOME/IP communication，and then tracing back to the discovery and establishment of SOME/IP services. Analyzed multiple optimization and solution methods，compared their performance，and proposed the final solution，which has important guiding significance and practical engineering application value for solving problems as SOME/IP frame loss.

【Key words】ethernet;SOME/IP;SOME/IP-SD;thread pool

作者簡介

張啟超（1990—），男，碩士，工程師，研究方向為平臺軟件開發。

隨著中國汽車工業的蓬勃發展，對大算力、高帶寬的要求越來越大，以太網通信在汽車通信領域中的比重也日趨升高。而基于IP的可擴展的面向服務的中間件（Scalable service-Oriented MiddlewarE over IP，SOME/IP）作為汽車行業以太網通信的重要協議在整車零部件中的使用率也逐漸升高。但要實現SOME/IP通信，Server端和Client端需要正常并快速建立連接。本文圍繞某款車型啟動后，對云端快速請求燈光無響應問題進行分析，主要探討車身控制模塊（Body Control Module，BCM）作為SOME/IP Client端無法快速獲得Server端發布的消息而導致丟幀的問題，并對SOME/IP及SOME/IP-SD協議進行詳細介紹，然后對多個優化方案進行時效性及性能的對比，提出最終解決方案，最后通過試驗驗證方案的有效性[1]。

1" 問題描述

某款車型啟動后，快速通過云端對車身燈光進行請求，燈光無響應，而啟動時間長后，再次請求燈光效果，燈光響應滿足請求。BCM控制器作為Client端與Server端車聯網系統（Telematics BOX，T-BOX）進行SOME/IP通信，通信框圖如圖1所示。云端通過消息隊列遙測傳輸（Message Queuing Telemetry Trans port，MQTT）協議將請求發送到T-BOX，T-BOX再通過SOME/IP協議將請求發送到BCM。

根據錄取的數據記錄，車輛啟動運行一段時間后，BCM控制器才能收到T-BOX發送的消息，導致Server端發送的前幾幀丟失，并且從車輛開始運行到BCM收到第1幀消息的時間不確定。BCM丟幀如圖2所示。因此整車運行后，不能立即發送工作請求給BCM端，即使發送，BCM控制器也無法正確接收，導致請求失敗，出現問題。

2" SOME/IP協議及線程池介紹

2.1" SOME/IP介紹

SOME/IP由AUTOSAR組織發布，是一種嵌入式通信協議，支持遠程過程調用（Method和Field的Get/Set功能）和事件通知（Event和Field的Notifier功能）。

SOME/IP是在傳輸層UDP/TCP協議基礎之上，擁有特定的服務交互機制，服務發布后廣播告知域內其他節點，其他節點收到服務廣播后，根據自身需求，請求或者訂閱相關服務接口。不同于傳統車載網絡的通信方式，當有請求發出時，SOME/IP才會發送數據，否則不發送，因此總線上沒有不必要的數據，降低了負荷[2-4]。

SOME/IP定義服務的接口支持請求/響應模式的遠程服務調用，也可以支持訂閱/發布模式的消息通知。SOME/IP報文格式見表1。

1）Message ID：報文的唯一標識符。高16位為Service ID;第16位為0時，低15位表示的是Method ID;第16位為1時，低15位表示的是Event ID。

2）Length：占32位，Length段后數據的長度。

3）Request ID：占32位，表示請求ID，用于區分每條請求，Server端將其復制到反饋報文中。Client ID，高16位，區分請求同一服務的不同客戶端。Session ID，低16位，同一客戶端請求同一服務的次數，從0x0001開始，達到0xFFFF后重新從0x0001開始循環。

4）Protocol Version：占8位，表示SOME/IP協議的版本，當前為0x01。

5）Message Type：占8位，表示報文類型。

6）Return Code：占8位，表示請求是否成功處理。

2.2" SOME/IP-SD及狀態機介紹

2.2.1" SOME/IP-SD介紹

SOME/IP-SD是SOME/IP的一種特殊服務（其Message ID為固定的0xFFFF8100），可以讓Client知道Server提供哪些服務。SOME/IP有兩種動態發現服務的機制：一種是Offer Service，由Server向網絡上的其他節點告知它所提供的服務;另一種是Find Service，由Client向Server請求可用的服務。SOME/IP-SD也基于SOME/IP報文，用來實現服務發現和事件訂閱，SOME/IP-SD消息通過UDP進行傳輸。SOME/IP服務發現及訂閱流程如圖3所示。

2.2.2" 客戶端SOME/IP-SD的狀態機

客戶端SOME/IP-SD狀態機如圖4所示，含Initial WaitPhase、RepetitionPhase及MainPhase等狀態。

1）InitialWaitPhase：啟動InitialDelay計時器，初始時間（取InitialDelayMaxValue和InitialDelayMinValue之間隨機值）超時后，發送第1幀Find Service。

2）RepetitionPhase：此階段重復發送Find Service，次數為InitialRepetitionsMax，間隔為InitialRepetitionsBaseDelay，每發送一次，間隔是前一間隔的2倍。如果此階段收到Offer Service，延遲RequestResponseDelay（取RequestResponse DelayMaxValue和RequestResponseDelayMinValue之間隨機值）時間后，觸發發送SubscribeEventgroup（），并停止發送計數和計時，立即進入Main Phase;如果服務請求被釋放，進入Down Phase;若有訂閱，則發送StopSubscribe Eventgroup。

3）MainPhase：不再周期發送Find Service;如果此階段收到Offer Service，延遲RequestResponseDelay（取Request ResponseDelayMaxValue和RequestResponseDelayMinValue之間隨機值）時間后，觸發發送SubscribeEventgroup（）。如果此階段收到StopOfferService，則停止所有計時器;如果服務請求被釋放，則進入Down Phase;若有訂閱，則發送StopSubscribeEventgroup。

2.3" 線程池的介紹

線程池是一種并發編程中常用的技術，用于管理和重用線程，由線程池管理器、工作隊列和線程池線程組成。線程池的設計思想是為了避免頻繁地創建和銷毀線程的開銷，以及控制并發執行的線程數量，從而提高系統的性能和資源利用率[5-6]，其優點主要包括以下幾點。

1）重用線程：線程和任務分離，提升線程重用性。線程池會在內部維護一組可重用的線程，避免頻繁地創建和銷毀線程的開銷，提高了線程的利用率。例如創建線程用的時間為T1，執行任務用的時間為T2，銷毀線程用的時間為T3，那么使用線程池就免去了T1和T3的時間。

2）控制并發度：線程池可以限制并發執行的線程數量，防止系統過載。通過調整線程池的大小，可以控制并發度，避免資源消耗過大。

3）提供線程管理和監控：線程池提供了一些管理和監控機制，例如線程池的創建、銷毀、線程狀態的監控等，方便開發人員進行線程的管理和調試。

4）提供任務隊列：線程池通常會使用任務隊列來存儲待執行的任務，這樣可以實現任務的緩沖和調度。

3" 問題分析

1）如圖1所示，BCM接收信號需經過T-BOX轉發，如果T-BOX未能正確接收云端發送的消息，將會導致BCM無法正確處理請求，不能響應云端請求。根據Trace分析，T-BOX接收云端的消息正常，并完成了正確的轉發，因此可以判斷是T-BOX與BCM通信導致的問題，如圖2所示。

2）分析Client端BCM代碼，發現BCM訂閱多個Server端的服務，如圖5所示。測試BCM只訂閱燈光請求一個服務，可快速建立連接，并快速響應云端請求，將不出現問題。甚至將燈光請求服務放到最前面進行服務發現，仍能優化云端燈光請求問題，但處于后面的服務會存在無法快速響應的問題。

3）如圖5所示，燈光請求（T-BOX）的服務發現動作放在了比較靠后的位置。因為是單線程處理服務發現，且為阻塞型處理，單線程方案流程如圖6所示。燈光請求T-BOX服務的訂閱需要在其他服務建立連接或超時后，才會去執行服務發現并建立連接，因此時間嚴重超時，導致無法接收Server端發送的前幾幀信號，出現丟幀現象，故無法快速進行服務發現及服務建立。問題原因分析框圖如圖7所示。

4）另外，如果Client端BCM先執行，并服務發現超時后，Server端才啟動，則無法建立通信，而本文出現的是丟幀問題而非無法建立通信問題，因此該原因不會導致本文問題的發生。

4" 問題優化及驗證

針對問題分析中的單線程處理服務發現，導致后運行的服務需阻塞等待先運行的服務超時或建立通信后才能執行的問題，最直接的辦法是建立多線程或線程池。

4.1" 優化方案分析

4.1.1" 多線程

使用多線程執行服務發現，可以優化服務發現的效率。但如果所有服務的服務發現都執行單獨的線程，則線程的創建和銷毀，以及線程間的數據共享等，將存在較大的問題。因為服務發現線程，執行的是服務發現動作，并不是BCM真正的工作線程。服務發現后，這些線程將銷毀，浪費CPU資源。單獨從執行服務發現動作的角度考慮，多線程方案將不是最優方案。多線程方案流程如圖8所示。

4.1.2" 線程池

1）多態的使用：針對多服務接口要想正確使用各接口功能，需要建立基類，其定義如圖9所示。在基類中建立各服務的工作函數，如mfStartClient、mfRun等，各工作任務Public繼承此基類，并重寫這些接口函數[7]。

2）任務隊列的使用：為了更好地管理任務，需要建立任務隊列，并對其進行添加任務及刪除任務功能，注意多線程間共享此任務隊列，需要增加線程安全手段，如互斥鎖、條件變量等。

3）線程池的使用：需要建立初始化及工作線程，每個工作線程會從任務隊列中取出任務（服務發現功能）并執行，然后將此任務從任務隊列中刪除，線程池方案流程圖如圖4所示。根據圖4可知，Client端的服務發現動作具有發送次數限制，因此如果無法正確建立通信連接，需再次將此任務添加到任務隊列中，直到任務隊列為空。然后線程池阻塞等待任務隊列不為空，直到任務完成，直至退出[8]。

無論Client端先啟動還是Server端先啟動，都將輪詢服務是否建立，Client端直到服務建立后才執行真正的工作。將所有服務的服務發現工作放到線程池中，每個服務等待的時間盡量縮短。如果此服務未正常建立，則將其重新加入到線程池任務隊列，而空出來的線程將執行另一個服務的服務發現，直到所有的服務都建立后，線程池才退出。線程池的使用可以降低多次創建線程所消耗的時間以及CPU負載率。

4.2" 問題驗證

針對原來的單線程以及多線程和線程池3種方案，對服務發現建立的時間和CPU負載率進行測試驗證，臺架驗證如圖11所示。計算開始執行到所有的服務均被發現為止的這段時間為服務發現的時間。因為是多核多線程方案，所以會存在CPU負載率大于100%的情況。

執行多次求均值后，驗證結果見表2。線程池方案在服務發現時間上具有明顯優勢，為單線程方案的近1/4，多線程方案的近1/2。在CPU負載率上，單線程方案具有最大優勢，多線程方案幾乎相當于3核完全在執行，線程池方案為3.4%左右，完全在CPU可允許負載范圍內。綜合服務發現時間和CPU負載率，線程池為最優方案。

利用線程池方案進行臺架和實車驗證，丟幀問題得到明顯優化，甚至不丟幀。車輛啟動后快速請求燈光問題也得到很好的優化和解決，如圖12所示。

5" 結論

1）單線程執行并不是每次都出現本文問題，只有先執行的Client對應的Server未啟動時，而后執行的Client需要等待前面Client的超時，導致后運行的Client服務發生阻塞，最終因丟幀引發本文出現的請求燈光無響應問題。由于很難確定哪個Server什么時候啟動，所以單線程執行并非最優方案。

2）針對本文提到的某車型車輛啟動后，快速請求燈光無響應問題，是BCM作為Client端和Server端的T-BOX在SOME/IP通信上存在丟幀問題導致。而后經過分析驗證，是在Client端服務發現未及時與Server端快速建立通信連接導致的。分析BCM代碼發現是服務發現為單線程阻塞執行，導致后運行的服務發現阻塞時間較長。為了解決單線程阻塞問題，驗證了多線程和線程池的方案，得出無論是在服務發現時間還是CPU負載率上，線程池的方案均優于多線程的方案。

3）針對某車型啟動后快速請求燈光無響應問題，使用線程池進行服務發現的方案在臺架和整車上都得到了很好的優化和驗證，為同類其他車型控制器尤其是多服務接口的Client端在SOME/IP通信丟幀問題提供了解決思路。

參考文獻：

[1] 喬俊賢. 某乘用車發動機蓋疲勞耐久問題分析解決[J]. 汽車實用技術，2024，49（1）：136-140.

[2] 張海濤，胡勝，仇林至. 基于AUTOSAR的SOME IP通信及其多核應用的實現[J]. 上海汽車，2021（1）：17-28.

[3] 張毅峰，歐陽頌華，魏鵬，等. SOME/IP車載以太網服務協議的關鍵技術與性能分析[J]. 現代電子技術，2023，46（5）：15-19.

[4] 李志濤，姬志博，耿偉峰. 車載以太網SOME/IP測試的研究與分析[J]. 汽車電器，2022（6）：95-98.

[5] 歐小龍. 基于中間件的C-V2X車載單元消息分發機制研究與設計[D]. 重慶：重慶郵電大學，2020.

[6] 韋通明，張送，溫豐蔚，等. 一種異步汽車數據接收端實現方案[J]. 汽車實用技術，2021，46（13）：91-93.

[7] 李家宏，孫慶英. C++多態性的實現過程[J]. 無線互聯科技，2023，19（2）：131-134.

[8] 李佳潔，陳哲，陳龍騰. 一種基于無鎖隊列的運行時多線程并行驗證方法[J]. 小型微型計算機系統，2024（5）：1249-1256.

（編輯" 凌" 波）

收稿日期：2024-04-24;修回日期：2024-05-29