某车型启动后快速请求灯光无响应问题分析

【摘" 要】文章针对某车型启动后快速请求灯光无响应问题进行分析研究，系统分析问题产生的原因，重点聚焦在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