Vehicle service request management method, device, vehicle and medium

Abstract

The present application relates to the field of vehicle technology, and in particular to a vehicle service request management method, device, vehicle and storage medium, wherein the method comprises: receiving service requests from one or more clients; identifying the current state of each server according to the service request, determining busy clients and idle clients; discarding the service request of the busy client, and sending a first access rejection message to the busy client, and responding to the service request of the idle client, and sending a second access rejection message to the unresponsive client. Thus, the problem of mutual interference in service requests in the related technology is solved, which easily leads to the loss of some data.

Description

Technical Field

[0001] The present application relates to the field of vehicle technology, and in particular to a vehicle service request management method, device, vehicle and storage medium. Background Art

[0002] With the updating and iteration of automotive electronic technology, more and more cars have added OTA (Over-the-Air Technology) online upgrade functions; at the same time, automobile production lines have also retained traditional offline diagnostic functions, which can cope with various configuration writing and production line function testing.

[0003] Among them, (1) the commonly used OTA upgrade method for automotive electronic devices is to download the upgrade package to the body controller through the network, use the diagnostic commands in the unified diagnostic service protocol to send a series of diagnostic requests through the vehicle network, transmit the new software to the designated controller to be flashed, and guide the designated controller to perform software upgrades. (2) Traditional offline diagnosis is to connect the offline diagnostic equipment through the OBD (On-Board Diagnostics) port reserved in the vehicle body. The diagnostic equipment sends a series of diagnostic requests through the vehicle network using the diagnostic commands in the unified diagnostic service protocol to write configuration information and vehicle VIN (Vehicle Identification Number) code and other information into the controller, and read some status of the controller at the same time.

[0004] However, in the related art, both OTA upgrades and offline diagnosis utilize diagnostic commands in a unified diagnostic service protocol to make diagnostic requests, which inevitably interfere with each other and cause partial data loss. Summary of the invention

[0005] The present application provides a vehicle service request management method, device, vehicle and storage medium to solve the problem that service requests in the related technology are prone to mutual interference, which may easily lead to partial data loss.

[0006] The first aspect of the present application provides a vehicle service request management method, comprising the following steps: receiving service requests from one or more clients; identifying the current status of each server according to the service request, and determining busy clients and idle clients; discarding the service request of the busy client, and sending a first access rejection message to the busy client, and responding to the service request of the idle client, and sending the second access rejection message to the unresponsive client.

[0007] According to the above-mentioned technical means, the embodiment of the present application can reasonably manage multiple service requests when multiple clients request the same server, avoid related interference conflicts of service requests, and the problem of partial data loss, ensure data integrity, and feedback failure messages when the client request fails, so that users can accurately know the response status of the service request and improve the user experience.

[0008] Furthermore, the current state includes a busy state and an idle state, and identifying the current state of each server according to the service request to determine the busy client and the idle client includes: when the server is in the busy state, determining that the client sending the service request to the server is the busy client; when the server is in the idle state, determining that the client sending the service request to the server is the idle client.

[0009] According to the above technical means, the embodiment of the present application can determine the status of the client according to the busy and idle status of the server, that is, whether it is an accessible client, thereby realizing the management of service requests by recording the access status of the client, effectively improving the management efficiency of service requests.

[0010] Furthermore, after sending the first access rejection message to the busy client, or sending the second access rejection message to the unresponsive client, it also includes: generating an alarm prompt information according to the first access rejection message or the second access rejection message, and providing a reminder based on the alarm prompt information.

[0011] According to the above technical means, the embodiment of the present application can also remind the user of the request failure through an alarm reminder when the client request fails, so that the user can know the status of the client service request in time, thereby improving the user's usage experience.

[0012] Furthermore, when the idle client includes an upgrade client or a diagnostic client, the response to the service request of the idle client includes: detecting the interval time between the upgrade client and the diagnostic client sending service requests; if the interval time is greater than or equal to a preset time, responding to the client with an earlier sending time; if the interval time is less than the preset time, and when the server does not respond to any one of the upgrade client and the diagnostic client, responding to the client with a later sending time.

[0013] According to the above technical means, the embodiment of the present application can determine the corresponding response rules according to the different interval times of the service requests to facilitate the management of the service requests.

[0014] The second aspect of the present application provides a service request management device for a vehicle, including: a receiving module for receiving service requests from one or more clients; a determination module for identifying the current status of each server according to the service request, and determining busy clients and idle clients; a management module for discarding the service request of the busy client, sending a first access rejection message to the busy client, and responding to the service request of the idle client, sending the second access rejection message to the unresponsive client.

[0015] Furthermore, the current state includes a busy state and an idle state, and the determination module is used to: when the server is in the busy state, determine that the client sending the service request to the server is the busy client; when the server is in the idle state, determine that the client sending the service request to the server is the idle client.

[0016] Furthermore, it also includes: a reminder module, which is used to generate an alarm prompt information according to the first access rejection message or the second access rejection message after sending the first access rejection message to the busy client, or sending the second access rejection message to the unresponsive client, and to remind based on the alarm reminder information.

[0017] Furthermore, the management module is used to, when the idle client includes an upgrade client or a diagnosis client: detect the interval time between the upgrade client and the diagnosis client sending service requests; if the interval time is greater than or equal to a preset time, respond to the client with an earlier sending time; if the interval time is less than the preset time, and when the server does not respond to any one of the upgrade client and the diagnosis client, respond to the client with a later sending time.

[0018] A third aspect of the present application provides a vehicle, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the vehicle service request management method as described in the above embodiment.

[0019] The fourth aspect of the present application provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the vehicle service request management method as described in the above embodiment.

[0020] Therefore, this application has at least the following beneficial effects:

[0021] The embodiment of the present application can reasonably manage multiple service requests when multiple clients request the same server, avoid related interference conflicts of service requests, and the problem of partial data loss, ensure data integrity, and feedback failure messages when client requests fail, so that users can accurately know the response status of service requests and improve user experience. Thus, the technical problems such as the situation that service requests are prone to mutual interference and partial data loss in the related technology are solved.

[0022] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through the practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which:

[0024] Figure 1 A schematic diagram of a process flow of a vehicle service request management method provided according to an embodiment of the present application;

[0025] Figure 2 A schematic diagram of a response to a service request provided according to an embodiment of the present application;

[0026] Figure 3 A schematic diagram of a response to a service request provided according to another embodiment of the present application;

[0027] Figure 4 A CAN network topology diagram of the entire vehicle provided according to an embodiment of the present application;

[0028] Figure 5 A schematic diagram of OTA access provided according to an embodiment of the present application;

[0029] Figure 6 A schematic diagram of accessing a diagnostic instrument according to an embodiment of the present application;

[0030] Figure 7 An example diagram of a vehicle service request management device provided according to an embodiment of the present application;

[0031] Figure 8 It is a schematic diagram of the structure of a vehicle provided according to an embodiment of the present application. DETAILED DESCRIPTION

[0032] Embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present application, and should not be construed as limiting the present application.

[0033] For ease of understanding, some of the terms used in the following embodiments are explained as follows:

[0034] UDS (Unified Siagnostic Services), used in the automotive industry;

[0035] OBD: On-board automatic diagnostic system, the diagnostic instrument is connected to the gateway through the OBD interface;

[0036] OTA: Over-the-air upgrade, specifically refers to wireless upgrade of cars;

[0037] Client: The client can refer to the party that initiates the active request of UDS;

[0038] Server: Server, which can refer to the party that executes the UDS command request.

[0039] UDS unified diagnosis includes UDS diagnostic protocol layer, data transmission layer and CAN (Controller Area Network) driver layer, which can realize the complete diagnostic protocol stack; UDS diagnostic session adopts a question-and-answer method for data transmission, the client asks and the server answers; the ECU controller on the car acts as the server, responding to the diagnostic request sent by OTA or offline diagnostic instrument. An automotive ECU (Electronic Control Unit) has only one CAN physical address and a corresponding CAN reply ID (Identification Card). When the ECU receives the corresponding CAN physical address ID diagnostic request command sent from the client, it replies with the corresponding CAN reply ID for UDS diagnostic service according to the received content.

[0040] After the car's ignition switch is turned on, the controller gateway (Client) integrated with the OTA software module starts to use diagnostic commands to collect the software and hardware version numbers of each ECU in the car, and then sends the ECU software and hardware version numbers to the cloud. The cloud determines whether there is an ECU that needs to be upgraded by OTA; if an OTA upgrade is required, the user is prompted that an ECU needs to be upgraded. After the user confirms, the OTA upgrade can be performed.

[0041] After the car is assembled, a diagnostic instrument is needed to perform off-line testing and configuration. The diagnostic instrument is connected to the car's OBD and connected to the gateway through OBD. The gateway routes the diagnostic instrument message to the corresponding CAN network for offline diagnosis and configuration of the corresponding controller.

[0042] When the OTA module and the diagnostic instrument perform diagnostic access to the same ECU at the same time, the ECU will ignore one of the accesses and reply to the diagnostic command of the other access according to the unified diagnostic specification. Due to the broadcast nature of CAN messages, both the OTA module and the diagnostic instrument will receive the ECU reply, and the ignored access will receive the replied diagnostic command by mistake, resulting in data errors.

[0043] To this end, an embodiment of the present application proposes an OTA upgrade and offline diagnosis management and control solution to resolve the conflict between OTA and offline diagnosis, and to reasonably manage the diagnostic commands in the unified diagnostic service protocol (such as IOS-14229) in the data channel.

[0044] The following will describe the vehicle service request management method, device, vehicle and storage medium of the embodiment of the present application with reference to the accompanying drawings. Specifically, Figure 1 A flowchart of a vehicle service request management method provided in an embodiment of the present application.

[0045] like Figure 1 As shown, the vehicle service request management method includes the following steps:

[0046] In step S101, a service request from one or more clients is received.

[0047] The client may include an upgrade client or a diagnostic client. For example, the upgrade client may be a controller gateway integrated with an OTA software module, and the diagnostic client may be an offline diagnostic instrument. In the following embodiments, a controller gateway integrated with an OTA software module and an offline diagnostic instrument are taken as examples.

[0048] Service requests can include upgrade service requests and diagnostic service requests, where (1) upgrade service requests can be requests for OTA software upgrades of automobile ECUs, which can repair vulnerabilities or optimize functions of the original ECU software functions; the ECU component manufacturer compiles the new software into a binary executable file and submits it to the automobile manufacturer; the automobile manufacturer places the executable file in the cloud; the automobile OTA software module initiates the version number collection action after the ignition switch is turned on, and the gateway OTA software module sends UDS diagnostic commands in turn to read the software version numbers of each ECU; after the reading is completed, it is transmitted to the cloud through the body 4G\5G module, and the cloud compares the software version numbers placed in the cloud, and feedback is given to the OTA module if there are ECUs that need to be upgraded. (2) Diagnostic service requests can be requests for offline diagnosis of automobiles. When the automobile is off the production line, the vehicle configuration information and vehicle VIN code need to be written into the vehicle ECU; in addition, when 4S stores maintain and repair automobiles, they also need to send UDS commands to the automobile ECU through the diagnostic instrument to read the internal faults of the automobile ECU to determine whether the automobile is abnormal, so as to perform repairs.

[0049] In step S102, the current state of each server is identified according to the service request, and busy clients and idle clients are determined.

[0050] Among them, the current state includes a busy state and an idle state. The current state of each server is identified according to the service request, and the busy client and the idle client are determined, including: when the server is in a busy state, determining that the client sending the service request to the server is a busy client; when the server is in an idle state, determining that the client sending the service request to the server is an idle client.

[0051] It can be understood that the embodiments of the present application can determine the status of the client based on the busy and idle status of the server, that is, whether it is an accessible client, thereby managing service requests by recording the access status of the client, effectively improving the management efficiency of service requests.

[0052] Specifically, since the embodiment of the present application uses UDS for OTA upgrades and offline diagnosis, and the UDS transport layer allows interruptions. Therefore, after receiving the diagnostic request, if UDS receives a new diagnostic command before processing the UDS unified diagnostic service, it will interrupt the previous one and process the new command. If it is being processed or the processing result is sent, the new diagnostic command will be ignored. When multiple clients request a server-side diagnostic command at the same time, due to the interruption mechanism of UDS, the server can only be allowed to reply to the service request of one of the clients, and other clients may be discarded by the UDS transport layer. The server cannot respond to the discarded service request of the client, and will not inform the client that the service is discarded; because CAN is broadcast, that is, all clients can receive the non-discarded client service request replied by the server, and the server of the discarded diagnostic service will receive an erroneous server reply, resulting in data errors.

[0053] Therefore, the gateway of the embodiment of the present application needs to record the client access status to manage service requests by recording the client access status, thereby effectively improving the management efficiency of service requests.

[0054] In step S103, the service request of the busy client is discarded, and a first access rejection message is sent to the busy client. In addition, in response to the service request of the idle client, a second access rejection message is sent to the unresponsive client.

[0055] It can be understood that the embodiments of the present application can reasonably manage multiple service requests when multiple clients request the same server, avoid related interference conflicts of service requests, and the problem of partial data loss, ensure data integrity, and feedback failure messages when client requests fail, so that users can accurately understand the response status of service requests and improve user experience.

[0056] For example, when OTA initiates a diagnostic request, the client access status is set to valid. When OBD requests diagnostic device routing again, the gateway directly refuses routing. When OTA has no diagnostic request, OBD requests routing. After the gateway routes successfully, the client status is set to valid, and the OTA module function is turned off to refuse the diagnostic request. At the same time, if a user requests to enter OTA through the operation interface, the gateway sends an error status of routing OBD back to the vehicle computer, and the vehicle computer informs the user through the display screen that a diagnostic instrument is connected and OTA cannot be performed.

[0057] In an embodiment of the present application, when the idle client includes an upgrade client or a diagnostic client, responding to the service request of the idle client includes: detecting the interval time between the upgrade client and the diagnostic client sending the service request; if the interval time is greater than or equal to the preset time, responding to the client with an earlier sending time; if the interval time is less than the preset time, and when the server does not respond to any one of the upgrade client and the diagnostic client, responding to the client with a later sending time.

[0058] The preset time may be set or calibrated according to actual conditions, such as 50 ms, etc., without specific limitation.

[0059] It is understandable that the embodiments of the present application can determine corresponding response rules according to different interval times of service requests to facilitate the management of service requests.

[0060] Specifically, if Figure 2 As shown in the figure, when UDS has only one client request, the server responds normally. UDS adopts a unified diagnosis service mechanism of question and answer. When the client sends the UDSdata.requst1 request and receives the UDSdata.response1 replied by the server, it sends UDSdata.requst2 and waits for the server's UDSdata.response2. The requests are made in sequence to achieve the diagnosis function.

[0061] like Figure 3 As shown in the figure, when multiple clients initiate diagnostic requests to a server, when UDSdata.requst1 and UDSdata.requst2 are sent successively with a very short interval (less than 50ms) and received by the server, before the server has time to process UDSdata.requst1, it receives UDSdata.requst2 again. The server will discard UDSdata.requst1 and directly process UDSdata.requst2, and reply with UDSdata.response2.

[0062] like Figure 3 As shown, when UDSdata.requst3 and UDSdata.requst4 are sent successively with a very short interval (less than 50ms) and received by the server, the server is already processing UDSdata.requst3 or has processed UDSdata.request3 and is replying to UDSdata.response3, and then receives UDSdata.requst4, the server will discard UDSdata.requst4, continue to process UDSdata.requst3, and reply to UDSdata.response3.

[0063] In an embodiment of the present application, after sending a first access rejection message to a busy client, or sending a second access rejection message to an unresponsive client, it also includes: generating an alarm prompt information according to the first access rejection message or the second access rejection message, and providing a reminder based on the alarm prompt information.

[0064] It is understandable that the embodiments of the present application can also remind the user of the request failure through an alarm reminder when the client request fails, so that the user can know the status of the client service request in time, thereby improving the user's usage experience.

[0065] According to the vehicle service request management method proposed in the embodiment of the present application, when multiple clients request the same server, multiple service requests can be reasonably managed to avoid related interference conflicts of service requests and the problem of partial data loss, ensure data integrity, and feedback a failure message when the client request fails, so that users can accurately know the response status of the service request and improve the user experience.

[0066] The following will describe a method for managing vehicle service requests through a specific embodiment, as follows:

[0067] (1) Send OTA commands and offline diagnostic commands through the UDS unified diagnostic service;

[0068] (2) The gateway implements management and control by controlling the OBD routing and OTA software modules: rejecting OBD routing when performing OTA; rejecting OTA upgrades when performing OBD routing; the gateway queries the version number of the flashed controller through the UDS unified diagnostic service, and the offline diagnostic instrument maps the CAN message of the designated controller through the gateway. The gateway manages the offline diagnostic instrument and OTA's access rights to the unified diagnostic service;

[0069] (3) The gateway feeds back the controlled status to the user: if OTA is rejected, it is output to the user through the vehicle computer; if OBD routing is rejected, it is output to the user through the diagnostic instrument;

[0070] (4) UDS unified diagnostic service, the transport layer allows interruption. After receiving the diagnostic request, before processing the UDS unified diagnostic service, if UDS receives a new diagnostic command, it will interrupt the previous one and process the new command. If it is processing or sending the processing result, it will ignore the new diagnostic command.

[0071] For example, Figure 4 As shown, the diagnostic instrument connects to the gateway inside the vehicle through the OBD port, and requests the gateway to route to each CAN3 bus. After the gateway routes, it obtains Figure 4 The CAN network topology of the entire vehicle is shown in Figure 1. Figure 5 As shown in the figure, the OTA module inside the gateway is executing and sending diagnostic commands to the CAN3 network. The diagnostic instrument requests the gateway to route to CAN3 through OBD. The gateway finds that there is a client on CAN3 and rejects the routing request of the diagnostic instrument. At the same time, it feedbacks that the diagnostic routing fails. The diagnostic instrument alarms and displays a connection failure. Figure 6 As shown in the figure, the gateway is routing the diagnostic instrument connected through OBD. At this time, OTA initiates an execution request. The gateway finds that there is a Client connected to CAN3 and rejects the OTA request. At the same time, it informs the user through the vehicle computer that the diagnostic instrument is executing and rejects OTA.

[0072] In summary, when the gateway of the embodiment of the present application receives a diagnostic instrument routing request from the OBD port, if the OTA is performing an OTA upgrade of the ECU, feedback is given to the diagnostic instrument that the routing request fails, and while the gateway maintains the OBD port connection, the OTA software module integrated in the gateway is prohibited from initiating diagnostic commands, thereby rejecting the access of the diagnostic instrument during the upgrade, ensuring that the OTA upgrade process is not interrupted, and preventing the ECU from being unusable; when the diagnostic instrument is connected, the version collection request and upgrade request initiated by the OTA are rejected to ensure the integrity of the diagnostic instrument's work, and the diagnostic instrument access status is fed back to the user to remind the user that the diagnostic instrument is connected, thereby eliminating the user's misunderstanding of the failure of the OTA function.

[0073] Next, a vehicle service request management device according to an embodiment of the present application will be described with reference to the accompanying drawings.

[0074] Figure 7 It is a block diagram of a vehicle service request management device according to an embodiment of the present application.

[0075] like Figure 7 As shown, the vehicle service request management device 10 includes: a receiving module 100 , a determining module 200 and a management module 300 .

[0076] Among them, the receiving module 100 is used to receive service requests from one or more clients; the determining module 200 is used to identify the current status of each server according to the service request, and determine the busy client and the idle client; the management module 300 is used to discard the service request of the busy client, and send a first access rejection message to the busy client, and respond to the service request of the idle client, and send a second access rejection message to the unresponsive client.

[0077] In an embodiment of the present application, the current state includes a busy state and an idle state, and the determination module 200 is used to: when the server is in a busy state, determine that the client sending a service request to the server is a busy client; when the server is in an idle state, determine that the client sending a service request to the server is an idle client.

[0078] Furthermore, the device 10 of the embodiment of the present application further includes: a reminder module. The reminder module is used to generate an alarm prompt information according to the first access rejection message or the second access rejection message after sending the first access rejection message to the busy client, or sending the second access rejection message to the unresponsive client, and to remind based on the alarm prompt information.

[0079] Furthermore, the management module 300 is used to, when the idle client includes an upgrade client or a diagnosis client: detect the interval time between the upgrade client and the diagnosis client sending service requests; if the interval time is greater than or equal to a preset time, respond to the client with an earlier sending time; if the interval time is less than the preset time, and when the server does not respond to any one of the upgrade client and the diagnosis client, respond to the client with a later sending time.

[0080] It should be noted that the above explanation of the vehicle service request management method embodiment is also applicable to the vehicle service request management device of this embodiment, and will not be repeated here.

[0081] According to the vehicle service request management device proposed in the embodiment of the present application, when multiple clients request the same server, multiple service requests can be reasonably managed to avoid related interference conflicts of service requests and the problem of partial data loss, ensure data integrity, and feedback a failure message when the client request fails, so that users can accurately know the response status of the service request and improve the user experience.

[0082] Figure 8 A schematic diagram of the structure of a vehicle provided in an embodiment of the present application. The vehicle may include:

[0083] A memory 801 , a processor 802 , and a computer program stored in the memory 801 and executable on the processor 802 .

[0084] When the processor 802 executes the program, the vehicle service request management method provided in the above embodiment is implemented.

[0085] Furthermore, the vehicle also includes:

[0086] The communication interface 803 is used for communication between the memory 801 and the processor 802 .

[0087] The memory 801 is used to store computer programs that can be executed on the processor 802 .

[0088] The memory 801 may include a high-speed RAM (Random Access Memory) memory, and may also include a non-volatile memory, such as at least one disk memory.

[0089] If the memory 801, the processor 802 and the communication interface 803 are implemented independently, the communication interface 803, the memory 801 and the processor 802 can be connected to each other through a bus and communicate with each other. The bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 8 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0090] Optionally, in a specific implementation, if the memory 801, the processor 802 and the communication interface 803 are integrated on a chip, the memory 801, the processor 802 and the communication interface 803 can communicate with each other through an internal interface.

[0091] The processor 802 may be a CPU (Central Processing Unit), or an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of the present application.

[0092] An embodiment of the present application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-mentioned vehicle service request management method.

[0093] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms are not necessarily directed to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or N embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples, without contradiction.

[0094] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of the features. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise clearly and specifically defined.

[0095] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, fragment or portion of code comprising one or more executable instructions for implementing the steps of a custom logical function or process, and the scope of the preferred embodiments of the present application includes alternative implementations in which functions may not be performed in the order shown or discussed, including performing functions in a substantially simultaneous manner or in reverse order depending on the functions involved, which should be understood by technicians in the technical field to which the embodiments of the present application belong.

[0096] It should be understood that the various parts of the present application can be implemented by hardware, software, firmware or a combination thereof. In the above-mentioned embodiment, the N steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit having a logic gate circuit for implementing a logic function for a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array, a field programmable gate array, etc.

[0097] A person skilled in the art may understand that all or part of the steps in the method for implementing the above-mentioned embodiment may be completed by instructing related hardware through a program, and the program may be stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiment.

[0098] Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and cannot be understood as limitations on the present application. Ordinary technicians in the field can change, modify, replace and modify the above embodiments within the scope of the present application.

Claims

1. A vehicle service request management method, characterized in that: The following steps are involved: Receive service requests from one or more clients; Identify the current state of each server according to the service request, and determine busy clients and idle clients; as well as discarding the service request of the busy client, sending a first access rejection message to the busy client, and responding to the service request of the idle client, sending a second access rejection message to the unresponsive client; The current state includes a busy state and an idle state, and the identifying the current state of each server according to the service request and determining a busy client and an idle client includes: When the server is in the busy state, determining that the client sending the service request to the server is the busy client; When the server is in the idle state, determining that the client sending the service request to the server is the idle client; When the idle client includes an upgrade client or a diagnosis client, the responding to the service request of the idle client includes: Detecting the interval between the upgrade client and the diagnosis client sending service requests; If the interval time is greater than or equal to the preset time, the response is sent to the client with the earlier sending time; If the interval time is less than the preset time, and when the server does not respond to any one of the upgrade client and the diagnosis client, the server responds to the client with the later sending time.

2. The method according to claim 1, characterized in that After sending the first access rejection message to the busy client, or sending the second access rejection message to the unresponsive client, the method further includes: Generate alarm prompt information according to the first access rejection message or the second access rejection message, and give a reminder based on the alarm prompt information.

3. A vehicle service request management device, characterized in that: include: A receiving module, used for receiving service requests from one or more clients; A determination module, used to identify the current state of each server according to the service request, and determine busy clients and idle clients; as well as a management module, configured to discard the service request of the busy client, send a first access rejection message to the busy client, and respond to the service request of the idle client, and send a second access rejection message to the unresponsive client; the current state includes a busy state and an idle state, and the determination module is configured to: When the server is in the busy state, determining that the client sending the service request to the server is the busy client; When the server is in the idle state, determining that the client sending the service request to the server is the idle client; The management module is used for: when the idle client includes an upgrade client or a diagnosis client: Detecting the interval between the upgrade client and the diagnosis client sending service requests; If the interval time is greater than or equal to the preset time, the response is sent to the client with the earlier sending time; If the interval time is less than the preset time, and when the server does not respond to any one of the upgrade client and the diagnosis client, the server responds to the client with the later sending time.

4. The device according to claim 3, characterized in that Also includes: A reminder module is used to generate an alarm prompt information according to the first access rejection message or the second access rejection message after sending the first access rejection message to the busy client, or sending the second access rejection message to the unresponsive client, and to remind based on the alarm prompt information.

5. A vehicle, characterized in that: include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the vehicle service request management method as described in any one of claims 1 to 2.

6. A computer-readable storage medium having a computer program stored thereon, characterized in that: The program is executed by a processor to implement the vehicle service request management method as described in any one of claims 1-2.

Images