CN115202323A - 车辆的服务请求管理方法、装置、车辆及介质 - Google Patents

Abstract

本申请涉及车辆技术领域，特别涉及一种车辆的服务请求管理方法、装置、车辆及存储介质，其中，方法包括：接收一个或多个客户端的服务请求；根据服务请求识别每个服务端的当前状态，确定忙碌客户端和空闲客户端；丢弃忙碌客户端的服务请求，并发送第一拒绝接入消息至忙碌客户端，并且响应空闲客户端的服务请求，发送第二拒绝接入消息至未响应的客户端。由此，解决了相关技术中服务请求时容易出现相互干扰的情况，容易导致部分数据丢失等问题。

Description

车辆的服务请求管理方法、装置、车辆及介质

技术领域

本申请涉及车辆技术领域，特别涉及一种车辆的服务请求管理方法、装置、车辆及存储介质。

背景技术

随着汽车电子技术更新迭代，越来越多的汽车增加了OTA(Over-the-AirTechnology，空中升级)在线升级功能；同时，汽车生产线也保留了传统线下诊断功能，可以应对各种配置写入和产线功能的检测。

其中，(1)常用的汽车电子器件OTA升级方式是通过网络将升级包下载到车身控制器，将升级包利用统一诊断服务协议中的诊断命令，通过车载网络，发送一系列的诊断请求，将新的软件由传输至指定的被刷控制器中，并指导指定的被刷控制器进行软件升级。(2)传统线下诊断是通过车身预留的OBD(On-Board Diagnostics，车载自动诊断系统)口连接线下诊断设备，诊断设备通过车载网络，利用统一诊断服务协议中的诊断命令，发送一系列诊断请求，将配置信息和车辆VIN(Vehicle Identification Number，车辆识别代码)码等信息写入控制器中，同时读取控制器一些状态。

然而，相关技术中OTA升级和线下诊断均是利用统一诊断服务协议中的诊断命令进行诊断请求，难免会出现相互干扰，造成部分数据丢失的情况。

发明内容

本申请提供一种车辆的服务请求管理方法、装置、车辆及存储介质，以解决相关技术中服务请求时容易出现相互干扰的情况，容易导致部分数据丢失等问题。

本申请第一方面实施例提供一种车辆的服务请求管理方法，包括以下步骤：接收一个或多个客户端的服务请求；根据所述服务请求识别每个服务端的当前状态，确定忙碌客户端和空闲客户端；丢弃所述忙碌客户端的服务请求，并发送第一拒绝接入消息至所述忙碌客户端，并且响应所述空闲客户端的服务请求，发送所述第二拒绝接入消息至未响应的客户端。

根据上述技术手段，本申请实施例可以在多个客户端请求同一服务端时，合理管理多个服务请求，避免服务请求的相关干扰冲突，以及部分数据丢失的问题，保证数据的完整性，并在客户端请求失败时反馈失败消息，可以使得用户可以准确获知服务请求的响应情况，提升用户的使用体验。

进一步地，所述当前状态包括忙碌状态和空闲状态，所述根据所述服务请求识别每个服务端的当前状态，确定忙碌客户端和空闲客户端，包括：在服务端处于所述忙碌状态时，确定发送服务请求至所述服务端的客户端为所述忙碌客户端；在服务端处于所述空闲状态时，确定发送服务请求至所述服务端的客户端为所述空闲客户端。

根据上述技术手段，本申请实施例可以根据服务端的忙碌及空闲状态确定客户端的状态，即是否属于可以接入的客户端，从而通过记录客户端的接入状态实现服务请求的管理，有效提升服务请求的管理效率。

进一步地，在发送第一拒绝接入消息至所述忙碌客户端，或者，发送所述第二拒绝接入消息至未响应的客户端之后，还包括：根据所述第一拒绝接入消息或所述第二拒绝接入消息生成报警提示信息，并基于所述报警提醒信息进行提醒。

根据上述技术手段，本申请实施例的还可以在客户端请求失败时，通过报警提醒的方式提醒用户请求失败，使得用户可以及时获知客户端服务请求的状态，提升用户的使用体验。

进一步地，在空闲客户端包括升级客户端或诊断客户端时，所述响应所述空闲客户端的服务请求，包括：检测所述升级客户端和所述诊断客户端发送服务请求的间隔时间；如果所述间隔时间大于或等于预设时间，则响应发送时间早的客户端；如果所述间隔时间小于预设时间，并在所述服务端未响应所述升级客户端和所述诊断客户端中的任意一个时，响应发送时间晚的客户端。

根据上述技术手段，本申请实施例可以根据服务请求的不同间隔时间确定对应的响应规则，以便于服务请求的管理。

本申请第二方面实施例提供一种车辆的服务请求管理装置，包括：接收模块，用于接收一个或多个客户端的服务请求；确定模块，用于根据所述服务请求识别每个服务端的当前状态，确定忙碌客户端和空闲客户端；管理模块，用于丢弃所述忙碌客户端的服务请求，并发送第一拒绝接入消息至所述忙碌客户端，并且响应所述空闲客户端的服务请求，发送所述第二拒绝接入消息至未响应的客户端。

进一步地，所述当前状态包括忙碌状态和空闲状态，所述确定模块用于：在服务端处于所述忙碌状态时，确定发送服务请求至所述服务端的客户端为所述忙碌客户端；在服务端处于所述空闲状态时，确定发送服务请求至所述服务端的客户端为所述空闲客户端。

进一步地，还包括：提醒模块，用于在发送第一拒绝接入消息至所述忙碌客户端，或者，发送所述第二拒绝接入消息至未响应的客户端之后，根据所述第一拒绝接入消息或所述第二拒绝接入消息生成报警提示信息，并基于所述报警提醒信息进行提醒。

进一步地，所述管理模块用于在空闲客户端包括升级客户端或诊断客户端时：检测所述升级客户端和所述诊断客户端发送服务请求的间隔时间；如果所述间隔时间大于或等于预设时间，则响应发送时间早的客户端；如果所述间隔时间小于预设时间，并在所述服务端未响应所述升级客户端和所述诊断客户端中的任意一个时，响应发送时间晚的客户端。

本申请第三方面实施例提供一种车辆，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序，以实现如上述实施例所述的车辆的服务请求管理方法。

本申请第四方面实施例提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行，以用于实现如上述实施例所述的车辆的服务请求管理方法。

由此，本申请至少具有如下有益效果：

本申请实施例可以在多个客户端请求同一服务端时，合理管理多个服务请求，避免服务请求的相关干扰冲突，以及部分数据丢失的问题，保证数据的完整性，并在客户端请求失败时反馈失败消息，可以使得用户可以准确获知服务请求的响应情况，提升用户的使用体验。由此，解决了相关技术中服务请求时容易出现相互干扰的情况，容易导致部分数据丢失等技术问题。

本申请附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为根据本申请实施例提供的车辆的服务请求管理方法的流程示意图；

图2为根据本申请一个实施例提供的服务请求的响应示意图；

图3为根据本申请另一个实施例提供的服务请求的响应示意图；

图4为根据本申请实施例提供的整个车辆的CAN网络拓扑图；

图5为根据本申请实施例提供的OTA接入示意图；

图6为根据本申请实施例提供的诊断仪接入示意图；

图7为根据本申请实施例提供的车辆的服务请求管理装置的示例图；

图8为根据本申请实施例提供的车辆的结构示意图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本申请，而不能理解为对本申请的限制。

为便于理解，以下实施例中使用的部分术语解释如下：

UDS(Unified Siagnostic Services，统一诊断服务)，用于汽车行业；

OBD：车载自动诊断系统，诊断仪通过OBD接口连接网关；

OTA：空中升级，这里特指汽车无线升级；

Client：客户端，可以指UDS发起主动请求一方；

Server：服务端，可以指UDS被请求命令，执行一方。

UDS统一诊断包含UDS诊断协议层、数据传输层以及CAN(Controller AreaNetwork，控制器域网)驱动层，其可实现完整的诊断协议栈；UDS诊断会话采用的是一问一答方式进行数据传输，客户端问，服务端答；汽车上的ECU控制器作为服务端，响应OTA或线下诊断仪发送的诊断请求。一个汽车ECU(Electronic Control Unit，电子控制单元)只有一个CAN物理寻址以及对应CAN的回复ID(Identification Card，身份识别卡)。当在ECU在接收到来自客户端发送的对应CAN物理寻址ID诊断请求命令时，根据接收到的内容，用对应的CAN回复ID进行UDS诊断服务后回复。

汽车点火开关接通后，集成了OTA软件模块的控制器网关(Client)开始使用诊断命令收集汽车各ECU软硬件版本号，然后将ECU软硬件版本号发送至云端，云端判断是否有ECU需要进行OTA升级；如果需要OTA升级，则提示用户有ECU需要升级，用户确认后，可以进行OTA升级。

汽车装配完成后，需要诊断仪进行生产下线检测和配置，诊断仪接通汽车OBD，通过OBD与网关连接，网关将诊断仪报文路由到对应CAN网络，进行对应控制器线下诊断和配置。

当OTA模块和诊断仪同时对同一个ECU进行诊断访问时，ECU会根据统一诊断规范要求，忽略掉其中一个访问，回复另一个访问的诊断命令。由于CAN报文的广播性，OTA模块和诊断仪都会收到此ECU回复，被忽略掉的访问会错误接收到被回复的诊断命令，导致数据出错。

为此，本申请实施例提出了一种OTA升级和线下诊断管控方案，解决OTA和线下诊断之间冲突问题，合理管控数据通道中统一诊断服务协议(例如IOS-14229)中的诊断命令。

下面将参考附图描述本申请实施例的车辆的服务请求管理方法、装置、车辆及存储介质。具体而言，图1为本申请实施例所提供的一种车辆的服务请求管理方法的流程示意图。

如图1所示，该车辆的服务请求管理方法包括以下步骤：

在步骤S101中，接收一个或多个客户端的服务请求。

其中，客户端可以包括升级客户端或诊断客户端，比如，升级客户端可以为集成了OTA软件模块的控制器网关，诊断客户端可以为线下诊断仪。以下实施例中，以集成了OTA软件模块的控制器网关和线下诊断仪为例。

服务请求可以包括升级服务请求和诊断服务请求，其中，(1)升级服务请求可以为汽车ECU的OTA对汽车ECU进行软件升级时的请求，可以对原ECU软件功能进行漏洞修复或者功能优化；零部件ECU厂商将新的软件编译为2进制可执行文件，交给汽车整车厂；由汽车整车将可执行文件放在云端；汽车OTA软件模块在点火开关打开后发起收集版本号动作，网关OTA软件模块依次发送UDS诊断命令读取各ECU软件版本号；读取完成后，通过车身4G\5G模块传入云端，云端对比放在云端的软件版本号，有需要升级的ECU，反馈给OTA模块。(2)诊断服务请求可以为汽车线下诊断时的请求，汽车生产下线时，需要将车辆配置信息和车辆VIN码写入车辆ECU；另外，4S店在保养汽车以及维修汽车时，也需要通过诊断仪发送UDS命令对汽车ECU进行内部故障读取，判断汽车是否异常，从而进行维修。

在步骤S102中，根据服务请求识别每个服务端的当前状态，确定忙碌客户端和空闲客户端。

其中，当前状态包括忙碌状态和空闲状态，根据服务请求识别每个服务端的当前状态，确定忙碌客户端和空闲客户端，包括：在服务端处于忙碌状态时，确定发送服务请求至服务端的客户端为忙碌客户端；在服务端处于空闲状态时，确定发送服务请求至服务端的客户端为空闲客户端。

可以理解的是，本申请实施例可以根据服务端的忙碌及空闲状态确定客户端的状态，即是否属于可以接入的客户端，从而通过记录客户端的接入状态实现服务请求的管理，有效提升服务请求的管理效率。

具体而言，由于本申请实施例是通过UDS进行OTA升级和线下诊断，而UDS传输层是允许打断的。因此，UDS在接收到诊断请求后，在处理UDS统一诊断服务之前，再接收到新的诊断命令，会中断之前的，处理新的命令。如果正在处理，或者发送处理结果，则会忽略掉新的诊断命令。当多个客户端同时请求一个服务端诊断命令时，由于UDS的打断机制，只能允许server回复其中一个client端的服务请求，其它客户端可能会被UDS的传输层丢弃，服务端无法回应客户端被丢弃的服务请求，并且也不会告知客户端此服务被丢弃；由于CAN具有广播性，即所有客户端都能收到服务端回复的未丢弃的客户端服务请求，被丢弃诊断服务的服务端均会接收到错误的服务端回复，导致数据出错。

由此，本申请实施例网关需要记录客户端接入状态，以通过记录客户端的接入状态实现服务请求的管理，有效提升服务请求的管理效率。

在步骤S103中，丢弃忙碌客户端的服务请求，并发送第一拒绝接入消息至忙碌客户端，并且响应空闲客户端的服务请求，发送第二拒绝接入消息至未响应的客户端。

可以理解的是，本申请实施例可以在多个客户端请求同一服务端时，合理管理多个服务请求，避免服务请求的相关干扰冲突，以及部分数据丢失的问题，保证数据的完整性，并在客户端请求失败时反馈失败消息，可以使得用户可以准确获知服务请求的响应情况，提升用户的使用体验。

举例而言，当OTA发起诊断请求后，将接入client状态置为有效，OBD再请求诊断设备路由时，网关直接拒绝路由；当OTA无诊断请求时，OBD请求路由，网关路由成功后，将client状态置为有效，同时关闭OTA模块功能，拒绝其发起诊断请求；同时，如果有用户再操作界面请求进入OTA，网关则发送正在路由OBD的错误状态返回给车机，车机通过显示屏告知用户有诊断仪接入，无法OTA。

在本申请实施例中，在空闲客户端包括升级客户端或诊断客户端时，响应空闲客户端的服务请求，包括：检测升级客户端和诊断客户端发送服务请求的间隔时间；如果间隔时间大于或等于预设时间，则响应发送时间早的客户端；如果间隔时间小于预设时间，并在服务端未响应升级客户端和诊断客户端中的任意一个时，响应发送时间晚的客户端。

其中，预设时间可以根据实际情况进行设置或标定，比如50ms等，不作具体限定。

可以理解的是，本申请实施例可以根据服务请求的不同间隔时间确定对应的响应规则，以便于服务请求的管理。

具体而言，如图2所示，UDS只有一个client请求时，server正常回复，UDS采用一问一答的统一诊断服务机制，当Client端发送完UDSdata.requst1请求，收到server端回复的UDSdata.response1后，再发送UDSdata.requst2，等待server的UDSdata.response2，依次请求，达成诊断功能。

如图3所示，当多个client对一个server发起诊断请求时，当UDSdata.requst1和UDSdata.requst2先后在间隔时间很短(小于50ms)发出，被server收到，server还未来得及处理UDSdata.requst1时，又收到了UDSdata.requst2，server会丢弃UDSdata.requst1直接处理UDSdata.requst2，回复UDSdata.response2。

如图3所示，当UDSdata.requst3和UDSdata.requst4先后在间隔时间很短(小于50ms)发出，被server收到，server已经在处理UDSdata.requst3或者处理完UDSdata.request3正在回复UDSdata.response3时，又收到了UDSdata.requst4，server会丢弃UDSdata.requst4继续处理UDSdata.requst3，回复UDSdata.response3。

在本申请实施例中，在发送第一拒绝接入消息至忙碌客户端，或者，发送第二拒绝接入消息至未响应的客户端之后，还包括：根据第一拒绝接入消息或第二拒绝接入消息生成报警提示信息，并基于报警提醒信息进行提醒。

可以理解的是，本申请实施例的还可以在客户端请求失败时，通过报警提醒的方式提醒用户请求失败，使得用户可以及时获知客户端服务请求的状态，提升用户的使用体验。

根据本申请实施例提出的车辆的服务请求管理方法，可以在多个客户端请求同一服务端时，合理管理多个服务请求，避免服务请求的相关干扰冲突，以及部分数据丢失的问题，保证数据的完整性，并在客户端请求失败时反馈失败消息，可以使得用户可以准确获知服务请求的响应情况，提升用户的使用体验。

下面将通过一个具体实施例对车辆的服务请求管理方法进行阐述，具体如下：

(1)通过UDS统一诊断服务发送OTA命令以及线下诊断命令；

(2)网关通过控制OBD路由和OTA软件模块来实现管控：进行OTA时拒绝OBD路由；OBD路由时拒绝OTA升级；其中，网关通过UDS统一诊断服务进行被刷控制器版本号查询，线下诊断仪通过网关对制定控制器进行CAN报文映射，网关管理线下诊断仪与OTA对统一诊断服务使用权限；

(3)网关反馈被管控状态给用户：拒绝OTA时通过车机输出给用户，拒绝OBD路由通过诊断仪输出给用户；

(4)UDS统一诊断服务，传输层是允许打断的。UDS在接收到诊断请求后，在处理UDS统一诊断服务之前，再接收到新的诊断命令，会中断之前的，处理新的命令。如果正在处理，或者发送处理结果，则会忽略掉新的诊断命令。

举例而言，如图4所示，诊断仪通过OBD口连接车辆内部的网关，请求网关路由到各路CAN3总线，网关路由后，得到图4所示的整个车辆的CAN网络拓扑图。如图5所示，网关内部OTA模块正在执行，发送诊断命令到CAN3网络，诊断仪通过OBD请求网关路由到CAN3,网关查询到有client在CAN3，拒绝诊断仪路由请求，同时反馈给诊断路由失败，诊断仪报警，显示连接失败。如图6所示，网关正路由通过OBD连接的诊断仪，此时OTA发起执行请求，网关查询到有Client连接到CAN3，拒绝OTA请求，同时通过车机告知用户，有诊断仪在执行，拒绝OTA。

综上，本申请实施例的网关接收到来自OBD口的诊断仪路由请求时，如果OTA正在进行ECU的OTA升级，则反馈给诊断仪，路由请求失败，且网关保持OBD口连接时，禁止网关集成的OTA软件模块发起诊断命令，从而可以拒绝正在升级时诊断仪接入，保证OTA升级过程不被中断，防止ECU无法使用情况出现；诊断仪接入时，拒绝OTA发起的版本收集请求以及升级请求，保证诊断仪工作的完整性，将诊断仪接入状态反馈给用户，提醒用户有诊断仪接入，消除用户对OTA功能失败误会。

其次参照附图描述根据本申请实施例提出的车辆的服务请求管理装置。

图7是本申请实施例的车辆的服务请求管理装置的方框示意图。

如图7所示，该车辆的服务请求管理装置10包括：接收模块100、确定模块200和管理模块300。

其中，接收模块100用于接收一个或多个客户端的服务请求；确定模块200用于根据服务请求识别每个服务端的当前状态，确定忙碌客户端和空闲客户端；管理模块300用于丢弃忙碌客户端的服务请求，并发送第一拒绝接入消息至忙碌客户端，并且响应空闲客户端的服务请求，发送第二拒绝接入消息至未响应的客户端。

在本申请实施例中，当前状态包括忙碌状态和空闲状态，确定模块200用于：在服务端处于忙碌状态时，确定发送服务请求至服务端的客户端为忙碌客户端；在服务端处于空闲状态时，确定发送服务请求至服务端的客户端为空闲客户端。

进一步地，本申请实施例的装置10还包括：提醒模块。其中，提醒模块用于在发送第一拒绝接入消息至忙碌客户端，或者，发送第二拒绝接入消息至未响应的客户端之后，根据第一拒绝接入消息或第二拒绝接入消息生成报警提示信息，并基于报警提醒信息进行提醒。

进一步地，管理模块300用于在空闲客户端包括升级客户端或诊断客户端时：检测升级客户端和诊断客户端发送服务请求的间隔时间；如果间隔时间大于或等于预设时间，则响应发送时间早的客户端；如果间隔时间小于预设时间，并在服务端未响应升级客户端和诊断客户端中的任意一个时，响应发送时间晚的客户端。

需要说明的是，前述对车辆的服务请求管理方法实施例的解释说明也适用于该实施例的车辆的服务请求管理装置，此处不再赘述。

根据本申请实施例提出的车辆的服务请求管理装置，可以在多个客户端请求同一服务端时，合理管理多个服务请求，避免服务请求的相关干扰冲突，以及部分数据丢失的问题，保证数据的完整性，并在客户端请求失败时反馈失败消息，可以使得用户可以准确获知服务请求的响应情况，提升用户的使用体验。

图8为本申请实施例提供的车辆的结构示意图。该车辆可以包括：

存储器801、处理器802及存储在存储器801上并可在处理器802上运行的计算机程序。

处理器802执行程序时实现上述实施例中提供的车辆的服务请求管理方法。

进一步地，车辆还包括：

通信接口803，用于存储器801和处理器802之间的通信。

存储器801，用于存放可在处理器802上运行的计算机程序。

存储器801可能包含高速RAM(Random Access Memory，随机存取存储器)存储器，也可能还包括非易失性存储器，例如至少一个磁盘存储器。

如果存储器801、处理器802和通信接口803独立实现，则通信接口803、存储器801和处理器802可以通过总线相互连接并完成相互间的通信。总线可以是ISA(IndustryStandard Architecture，工业标准体系结构)总线、PCI(Peripheral Component，外部设备互连)总线或EISA(Extended Industry Standard Architecture，扩展工业标准体系结构)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图8中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

可选的，在具体实现上，如果存储器801、处理器802及通信接口803，集成在一块芯片上实现，则存储器801、处理器802及通信接口803可以通过内部接口完成相互间的通信。

处理器802可能是一个CPU(Central Processing Unit，中央处理器)，或者是ASIC(Application Specific Integrated Circuit，特定集成电路)，或者是被配置成实施本申请实施例的一个或多个集成电路。

本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上的车辆的服务请求管理方法。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不是必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或N个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本申请的描述中，“N个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更N个用于实现定制逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，N个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。如，如果用硬件来实现和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列，现场可编程门阵列等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (10)

1.一种车辆的服务请求管理方法，其特征在于，包括以下步骤：

接收一个或多个客户端的服务请求；

根据所述服务请求识别每个服务端的当前状态，确定忙碌客户端和空闲客户端；以及

丢弃所述忙碌客户端的服务请求，并发送第一拒绝接入消息至所述忙碌客户端，并且响应所述空闲客户端的服务请求，发送所述第二拒绝接入消息至未响应的客户端。

2.根据权利要求1所述的方法，其特征在于，所述当前状态包括忙碌状态和空闲状态，所述根据所述服务请求识别每个服务端的当前状态，确定忙碌客户端和空闲客户端，包括：

在服务端处于所述忙碌状态时，确定发送服务请求至所述服务端的客户端为所述忙碌客户端；

在服务端处于所述空闲状态时，确定发送服务请求至所述服务端的客户端为所述空闲客户端。

3.根据权利要求1所述的方法，其特征在于，在发送第一拒绝接入消息至所述忙碌客户端，或者，发送所述第二拒绝接入消息至未响应的客户端之后，还包括：

根据所述第一拒绝接入消息或所述第二拒绝接入消息生成报警提示信息，并基于所述报警提醒信息进行提醒。

4.根据权利要求1-3任意一项所述的方法，其特征在于，在空闲客户端包括升级客户端或诊断客户端时，所述响应所述空闲客户端的服务请求，包括：

检测所述升级客户端和所述诊断客户端发送服务请求的间隔时间；

如果所述间隔时间大于或等于预设时间，则响应发送时间早的客户端；

如果所述间隔时间小于预设时间，并在所述服务端未响应所述升级客户端和所述诊断客户端中的任意一个时，响应发送时间晚的客户端。

5.一种车辆的服务请求管理装置，其特征在于，包括：

接收模块，用于接收一个或多个客户端的服务请求；

确定模块，用于根据所述服务请求识别每个服务端的当前状态，确定忙碌客户端和空闲客户端；以及

管理模块，用于丢弃所述忙碌客户端的服务请求，并发送第一拒绝接入消息至所述忙碌客户端，并且响应所述空闲客户端的服务请求，发送所述第二拒绝接入消息至未响应的客户端。

6.根据权利要求5所述的装置，其特征在于，所述当前状态包括忙碌状态和空闲状态，所述确定模块用于：

在服务端处于所述忙碌状态时，确定发送服务请求至所述服务端的客户端为所述忙碌客户端；

在服务端处于所述空闲状态时，确定发送服务请求至所述服务端的客户端为所述空闲客户端。

7.根据权利要求6所述的装置，其特征在于，还包括：

提醒模块，用于在发送第一拒绝接入消息至所述忙碌客户端，或者，发送所述第二拒绝接入消息至未响应的客户端之后，根据所述第一拒绝接入消息或所述第二拒绝接入消息生成报警提示信息，并基于所述报警提醒信息进行提醒。

8.根据权利要求5-7任意一项所述的装置，其特征在于，所述管理模块用于在空闲客户端包括升级客户端或诊断客户端时：

检测所述升级客户端和所述诊断客户端发送服务请求的间隔时间；

如果所述间隔时间大于或等于预设时间，则响应发送时间早的客户端；

如果所述间隔时间小于预设时间，并在所述服务端未响应所述升级客户端和所述诊断客户端中的任意一个时，响应发送时间晚的客户端。

9.一种车辆，其特征在于，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序，以实现如权利要求1-4任一项所述的车辆的服务请求管理方法。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行，以用于实现如权利要求1-4任一项所述的车辆的服务请求管理方法。

Images