Vehicle state acquisition method and device, middleware and storage medium

Abstract

The application relates to the technical field of Internet of Vehicles, in particular to a vehicle state acquisition method and device, middleware and a storage medium, wherein the method is applied to the middleware and comprises the following steps: acquiring a message reported by a vehicle; determining an actual state of the vehicle according to the message; and updating a state list of the vehicle according to the actual state, wherein a server acquires the actual state of the vehicle from the state list of the middleware. Therefore, the problem of inaccurate vehicle real-time online state information in the related art is solved, and the safety of the vehicle and the user experience are poor.

Description

Technical Field

[0001] This application relates to the field of vehicle networking technology, and in particular to a method, device, middleware, and storage medium for obtaining vehicle status. Background Technology

[0002] In the existing TSP system, there is an occasional problem: the vehicle online status is inaccurate. For example, the vehicle may be online, but the system may show that the vehicle is offline. When a customer issues a command, the vehicle must be woken up first, which is time-consuming and results in a poor user experience. In case of an emergency that requires an immediate response to a command, it may even lead to a safety accident. Moreover, because it is an occasional problem that is difficult to reproduce, it is also very difficult to troubleshoot.

[0003] In related technologies, the online status of a vehicle is indirectly determined based on login, logout, and high- and low-frequency messages sent from MongoDB (a distributed file storage database). This method has certain errors. For example, the vehicle may be offline due to network issues and unable to send a logout message, resulting in inaccurate online / offline information. Furthermore, the vehicle's online status is obtained through this indirect method rather than by directly obtaining the status value, which introduces some error. Summary of the Invention

[0004] This application provides a vehicle status acquisition method, device, middleware, and storage medium to solve the problem of occasional inaccuracies in real-time online vehicle status information in related technologies, which leads to poor vehicle safety and poor user experience.

[0005] A first aspect of this application provides a vehicle status acquisition method, which is applied to middleware. The method includes the following steps: acquiring a message reported by a vehicle; determining the actual status of the vehicle based on the message; and updating the vehicle status list based on the actual status, wherein the server acquires the actual status of the vehicle from the status list of the middleware.

[0006] Optionally, determining the actual status of the vehicle based on the message includes: if the message is a login message, then determining that the actual status is online; if the message is a logout message, then determining that the actual status is offline.

[0007] Optionally, before determining the actual status of the vehicle based on the message, the method further includes: obtaining the client identifier of the vehicle's TBOX (vehicle networking system); querying the vehicle identifier based on the client identifier; and querying the display status of the corresponding vehicle based on the vehicle identifier.

[0008] Optionally, updating the vehicle's status list based on the actual status includes: obtaining the vehicle's current status; determining whether the current status is consistent with the actual status; if they are inconsistent, updating the displayed status in the status list to the actual status.

[0009] Optionally, before obtaining the message reported by the vehicle, the process includes: encoding the target message event to obtain a configuration file for the target message event; adding the target server address interface to the configuration file, setting the type of the target message event, and pushing the configuration file to the vehicle terminal.

[0010] A second aspect of this application provides a vehicle status acquisition method, which is applied to a server. The method includes the following steps: sending an acquisition request to middleware; acquiring a status list sent by the middleware, wherein the middleware determines the actual status of the vehicle using messages reported by the vehicle and updates the vehicle status list according to the actual status; and acquiring the actual status of the vehicle according to the status list.

[0011] A third aspect of this application provides a vehicle status acquisition device, which is applied to middleware. The device includes: a first acquisition module for acquiring messages reported by a vehicle; a determination module for determining the actual status of the vehicle based on the messages; and an update module for updating the vehicle status list based on the actual status. The server acquires the actual status of the vehicle from the status list of the middleware.

[0012] A fourth aspect of this application provides a vehicle status acquisition device, which is applied to a server. The device includes: a sending module for sending an acquisition request to middleware; a second acquisition module for acquiring a status list sent by the middleware, wherein the middleware determines the actual status of the vehicle using messages reported by the vehicle and updates the vehicle status list according to the actual status; and a third acquisition module for acquiring the actual status of the vehicle according to the status list.

[0013] A fifth aspect of this application provides middleware, including: 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 status acquisition method as described in the above embodiments.

[0014] A sixth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the vehicle status acquisition method as described in the above embodiments.

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

[0016] This application obtains the messages reported by the vehicle to determine the actual status of the vehicle, updates the vehicle status list according to the actual status, and the server can obtain the actual status of the vehicle from the status list of the middleware. Thus, the online status of the vehicle can be accurately and directly obtained through the function of the middleware, which improves the user experience and vehicle safety.

[0017] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0018] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0019] Figure 1 This is a flowchart of a vehicle status acquisition method according to an embodiment of this application;

[0020] Figure 2 Here is a flowchart of a vehicle status acquisition method according to another embodiment of this application.

[0021] Figure 3 This is a flowchart illustrating the vehicle status acquisition method according to an embodiment of this application.

[0022] Figure 4 This is a logic diagram for processing offline events according to an embodiment of this application;

[0023] Figure 5 This is a block diagram of a vehicle status acquisition device according to an embodiment of the present application;

[0024] Figure 6 This is a block diagram of a vehicle status acquisition device according to another embodiment of this application;

[0025] Figure 7 This is a schematic diagram of the structure of the middleware according to an embodiment of this application. Detailed Implementation

[0026] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0027] The vehicle status acquisition method, apparatus, middleware, and storage medium of this application are described below with reference to the accompanying drawings. Addressing the issue of inaccurate vehicle online status mentioned in the background art, this application provides a vehicle status acquisition method. In this method, messages reported by the vehicle are acquired to determine the vehicle's actual status. The vehicle's status list is updated based on the actual status, and the server can obtain the vehicle's actual status from the status list in the middleware. This allows for accurate and direct acquisition of the vehicle's online status, improving user experience and vehicle safety. Thus, the problem of occasional inaccuracies in real-time vehicle online status information in related technologies, leading to poor vehicle safety and a poor user experience, is solved.

[0028] Specifically, Figure 1 This is a flowchart illustrating a vehicle status acquisition method provided in one embodiment of this application.

[0029] like Figure 1 As shown, this vehicle status acquisition method is applied to middleware, and the method includes the following steps:

[0030] In step S101, the message reported by the vehicle is obtained.

[0031] It is understood that the embodiments of this application obtain the messages reported by the vehicle in order to know the actual status of the vehicle.

[0032] In this embodiment of the application, before obtaining the message reported by the vehicle, the process includes: encoding the target message event to obtain a configuration file for the target message event; adding the target server address interface to the configuration file, setting the type of the target message event, and pushing the configuration file to the vehicle terminal.

[0033] It is understood that, in this embodiment of the application, the target message event is encoded by opening the webhook function in the management window of the middleware EMQX, the configuration file of the target message event is obtained, and the target server address interface is added to the configuration file so that the server can query the vehicle online status through the interface. The type of the target message event is set, and the configuration file is pushed to the vehicle terminal so that the vehicle status can be obtained by using the configuration file.

[0034] Specifically, first, in the EMQX management window, enable the webhook function, and then modify the webhook configuration file on the EMQX server: the emqx_web_hook.conf file. Next, add the value of web.hook.api.url to the server interface address that receives push messages, such as: web.hook.rule.client.unsubscribed.1 = {"action": "on_client_unsubscribe"}. Configure the message events to be pushed, such as: web.hook.rule.session.unsubscribed.1 = {"action": "on_session_unsubscribe"}. For push message types, only push messages with specific topics, such as only pushing messages with the topic "winmu / vehicle / up". This can greatly reduce the load on the receiving server; web.hook.rule.message.publish.1 = {"action": "on_message_publish", "topic": "winmu / vehicle / up"}. After modifying the configuration, you need to execute the emqx_ctl restart command to restart the service for the changes to take effect.

[0035] It's important to note that because EMQX push messages are encoded from protobuf into JSON strings, and UTF-8 is multi-byte, this encoding is lossy and irreversible. In other words, the obtained message body payload cannot be decoded to extract useful information such as VIN and event type. To solve this critical problem, another extended feature of EMQX is needed: the rules engine. The first step of the rules engine is to create a webhook resource, which can be created using the management platform provided by EMQX, such as... Figure 5 As shown, EMQX's rule engine uses SQL statements similar to those in development and provides rich functions for data processing. The core of this rule is the statement `SELECT client_id, base64_encode(payload) asenpayload, topic, event FROM "winmu / vehicle / up"`. It retrieves the `client_id` and the content of the reported issue from the required topic and uses the `base64_encode` function for encoding. This encoding allows the receiving server to perform base64 decoding, convert the obtained message into the actual business information, and then push it to the system for processing in conjunction with the resource's webhook.

[0036] In step S102, the actual state of the vehicle is determined based on the message.

[0037] It is understood that the embodiments of this application determine the actual state of the vehicle based on the message, so as to update the vehicle's state list according to the actual state of the vehicle in the future.

[0038] In this embodiment of the application, before determining the actual state of the vehicle based on the message, the method further includes: obtaining the client identifier of the vehicle's TBOX; querying the vehicle identifier based on the client identifier; and querying the display state of the corresponding vehicle based on the vehicle identifier.

[0039] It is understood that in this application embodiment, the vehicle identifier and the client identifier are mapped. The vehicle identifier is queried by obtaining the client identifier of the vehicle's TBOX, and the display status of the corresponding vehicle is queried by the vehicle identifier.

[0040] Specifically, as shown in Table 1 below, the Vin code is queried based on the clientld; then, the vehicle's online status is queried through Table 2 below, where 0 indicates the vehicle is offline and 1 indicates the vehicle is online; if the current status is inconsistent with the queried status, the vehicle's online status needs to be updated, and the mapping relationship between clientld and Vin also needs to be updated. The actual vehicle status, Vin, and clientld are then stored in Redis. Redis is a cache that supports high concurrency and high availability, uses I / O multiplexing technology to improve throughput, and uses sentinel mode to ensure availability; its data structure design also enables fast read and write operations.

[0041] Table 1. Mapping Relationship between clientld and Vin Code

[0042] field name type describe Remark clientld KEY TBOX client number vin VALUE Vehicle VIN code

[0043] Table 2. Mapping Relationship between Vin Code and Vehicle Online Status

[0044]

[0045] In this embodiment of the application, determining the actual status of the vehicle based on the message includes: if the message is a login message, then determining that the actual status is online; if the message is a logout message, then determining that the actual status is offline.

[0046] It is understood that in this embodiment of the application, when the message is displayed as a login message, the actual status is determined to be online, and when the message is displayed as a logout message, the actual status is determined to be offline, so as to facilitate subsequent updates to the vehicle's current online status based on the actual status.

[0047] In step S103, the vehicle status list is updated according to the actual status, wherein the server obtains the actual status of the vehicle from the status list of the middleware.

[0048] It is understood that in this embodiment of the application, the vehicle status list is updated according to the actual status, and the server can obtain the actual status of the vehicle from the status list of the middleware, thereby accurately and directly obtaining the online status of the vehicle, improving the user experience and vehicle safety.

[0049] In this embodiment of the application, updating the vehicle status list according to the actual status includes: obtaining the current status of the vehicle; determining whether the current status is consistent with the actual status; if they are inconsistent, updating the displayed status in the status list to the actual status.

[0050] It is understood that the embodiments of this application obtain the current status of the vehicle, determine whether the current status is consistent with the actual status, and if they are inconsistent, update the displayed status of the status list to the actual status, so as to improve the accuracy of the vehicle's online status.

[0051] Specifically, such as Figure 3 As shown, the process first obtains the vehicle's message status (after the vehicle is started, the TBOX on the vehicle sends a login message to the eMQX). When the message is a login message, the system queries the vehicle's online status, the message reception time, and the client identifier of the vehicle's TBOX based on the Vin code. Then, it determines the message reception time. Due to network issues, there may be situations where logout messages arrive before login messages, so the system needs to receive the latest message status. Expired or outdated messages are discarded. Next, the system determines whether the vehicle's online status is logged in or logged out based on the latest message status, and checks whether the Vin code query for the vehicle's online status matches the latest online status. If not, the system updates the vehicle's online status to the latest online status. Finally, it checks whether the client identifiers of the vehicle's TBOXes are the same (since one TBOX device corresponds to one clientID, but there may be cases where the vehicle's TBOX is replaced). If they are different, it means it is a new vehicle, and the mapping relationship needs to be re-inserted for later queries.

[0052] In addition, there is a special case such as Figure 4 As shown, a logout message is sent when a vehicle exits normally. However, if a special situation occurs, such as a vehicle suddenly losing its traffic lights, EMQX will send a disconnected event based on the heartbeat mechanism. Based on this event, the vehicle needs to be updated to be offline, which is an abnormal update.

[0053] According to the vehicle status acquisition method proposed in this application, the message reported by the vehicle is acquired to determine the actual status of the vehicle, the vehicle status list is updated according to the actual status, and the server can obtain the actual status of the vehicle from the status list of the middleware, thereby accurately and directly obtaining the online status of the vehicle, improving the user experience and vehicle safety.

[0054] Figure 2 This is a flowchart illustrating a vehicle status acquisition method provided in another embodiment of this application.

[0055] like Figure 2 As shown, this vehicle status acquisition method is applied to a server, and the method includes the following steps:

[0056] In step S201, a request to acquire is sent to the middleware.

[0057] It is understood that in this embodiment of the application, an acquisition request is sent to the middleware in order to obtain the status list sent by the middleware in the future.

[0058] In step S202, the status list sent by the middleware is obtained, wherein the middleware determines the actual status of the vehicle using the messages reported by the vehicle, and updates the vehicle status list according to the actual status.

[0059] It is understood that in this application embodiment, the middleware obtains the status list sent by the middleware, uses the messages reported by the vehicle to determine the actual status of the vehicle, and updates the vehicle's status list according to the actual status, so as to make the online status of the vehicle more accurate.

[0060] In step S203, the actual status of the vehicle is obtained according to the status list.

[0061] It is understood that the embodiments of this application obtain the actual status of the vehicle based on the status list, thereby accurately and directly obtaining the online status of the vehicle, improving the user experience and vehicle safety.

[0062] According to the vehicle status acquisition method proposed in this application, an acquisition request is sent to the middleware and a status list sent from the middleware is received. The actual status of the vehicle is obtained according to the status list, thereby accurately and directly obtaining the online status of the vehicle, improving the user experience and vehicle safety.

[0063] The method for obtaining vehicle status will be explained in detail below:

[0064] Firstly, vehicle data reporting uses TBOX, which employs the MQTT protocol and transmits data through the industry-leading EMQX middleware. The main steps involve setting up a server that receives various event-type messages pushed by EMQX's webhook function, parses and determines the vehicle's online status information, and configures message filtering to prevent a large number of useless push messages from degrading server performance. A rules engine is used to address message decoding issues, and Redis caching is employed for fast vehicle online status retrieval. The specific steps are as follows:

[0065] (1) Set up an EMQX server cluster, configure a topic to receive messages sent from TBOX. The information sent from TBOX needs to include VIN, event type, and information such as vehicle login. Enable webhook functionality in EMQX, configure the webhook push service address and push event type. For publish events, configure the corresponding topic and the resource information of the rule engine, the corresponding webhook and push address.

[0066] Specifically, in the EMQX management window, enable the webhook feature, and then modify the webhook configuration file on the EMQX server: the emqx_web_hook.conf file. Add the value of web.hook.api.url to the server interface address that receives push messages, such as: web.hook.rule.client.unsubscribed.1 = {"action": "on_client_unsubscribe"}. Configure the message events to be pushed, such as: web.hook.rule.session.unsubscribed.1 = {"action": "on_session_unsubscribe"}. For push message types, only push messages with specific topics, such as only pushing messages with the topic "winmu / vehicle / up". This can greatly reduce the load on the receiving server; web.hook.rule.message.publish.1 = {"action": "on_message_publish", "topic": "winmu / vehicle / up"}. After modifying the configuration, you need to execute the emqx_ctl restart command to restart the service for the changes to take effect.

[0067] (2) Build a Redis cluster and use Sentinel mode to ensure high availability, store vehicle online and offline information and mapping relationship with clientld.

[0068] Redis middleware is used to store vehicle online / offline information and its binding relationship with the clientld. The Redis data structure is shown in Tables 1 and 2. The Vin code is retrieved from the clientld in Table 1. Then, the vehicle's online status is retrieved from Table 2, where 0 indicates the vehicle is offline and 1 indicates it is online. If the current status differs from the queried status, the vehicle's online status needs to be updated, along with the mapping relationship between the clientld and Vin. The actual vehicle status, Vin, and clientld are then stored in Redis. Since the vehicle identifier in the business is Vin, and the EMQX middleware is business-independent, it does not have Vin information; instead, it uniquely identifies a connected device using the clientld associated with that device. Furthermore, in communication with the TBOX vendor, the current algorithm randomly regenerates the clientld each time a connection is re-established; if the clientlds are the same, the later connection will kick the earlier one offline. Therefore, two structures need to be maintained: one to associate the mapping relationship between the clientld and the vin, and the other to actually store the online / offline status of the vin for the system to obtain directly, quickly, and accurately. Among them, Redis itself is a cache that supports high concurrency and high availability, uses I / O multiplexing technology to improve throughput, and uses sentinel mode to ensure availability. Its data structure design is also designed for fast read and write, making it very suitable for this scenario.

[0069] (3) Build an application service that accepts webhook information push, use Spring Boot technology to quickly build web interface, perform different logic processing for different message events, decode and judge to obtain the online and offline information of the vehicle and the mapping relationship between vin and clientld, and maintain it in Redis.

[0070] The next step is to design and implement the message receiving processing logic, determine the vehicle's online / offline information based on different events and save the status, while maintaining the relationship with the current clientld.

[0071] like Figure 3 and Figure 4 As shown, it primarily accepts disconnected events to handle offline status maintenance, and parses the vehicle's VIN code and the user-defined business type of the message from the publish event, reducing server load. It only processes login messages to maintain the mapping relationship between vehicle online status, VIN, and client, as detailed below:

[0072] First, the vehicle's message status is obtained (after the vehicle is started, the TBOX sends a login message to the eMQX). When the message is a login message, the vehicle's online status, message reception time, and the TBOX's client identifier are queried based on the Vin code. Then, the message reception time is determined. Due to network issues, logout messages may arrive before login messages, so the latest message status needs to be received. Expired or outdated messages are discarded. Next, the vehicle's online status is determined based on the latest message status; it is then checked whether the vehicle is logged in or logged out. The Vin code query for the vehicle's online status matches the latest online status. If they do not match, the vehicle's online status is updated to the latest online status. Finally, the client identifiers of the vehicle's TBOX are checked to see if they are the same (since one TBOX device corresponds to one clientID, but there may be cases where the TBOX is replaced). If they are different, it means it is a new vehicle, and the mapping relationship needs to be re-inserted for later queries.

[0073] In addition, there is a special case. Normally, a vehicle will send a logout message when it exits. However, if a special situation occurs, such as a vehicle suddenly losing its traffic lights, EMQX will send a disconnected event based on the heartbeat mechanism. Based on this event, the vehicle needs to be updated to be offline, which is an abnormal update.

[0074] (4) Provides an interface for quick and easy querying of vehicle online and offline information, and reserves candidate solutions for configurable switching to the old mode.

[0075] The middleware provides a true online vehicle status query interface, which can be retrieved directly from the Redis cache based on the vin, which is accurate and fast. When the system is newly launched, the old logic is used for vehicle data that does not yet exist. The vehicle online status information obtained by the old logic is also stored in Redis. As the system is gradually used, the old logic is gradually replaced, and the vehicle owner is completely unaware of it.

[0076] (5) Process message parsing.

[0077] Because EMQX push messages are encoded from protobuf into JSON strings, and UTF-8 is multi-byte, this encoding is lossy and irreversible. In other words, the obtained message body payload cannot be decoded to extract useful information, such as VIN and event type. To solve this critical problem, another EMQX extension is needed: the rules engine; this also requires version 3.1 or higher. The current EMQX version can be checked using the `emqx_ctl status` command.

[0078] The first step of the rules engine is to create a webhook resource, which can be created by the management platform provided by EMQX. Based on this created resource, the rules that need to be pushed can be actually created. The EMQX rules engine uses SQL statements similar to those in development and provides a wealth of functions to help process data. Among them, the rule SELECT client_id, base64_encode(payload) as enpayload, topic, event FROM "winmu / vehicle / up" is the core content. It retrieves the client_id and the content of the reported issue from the required topic, and uses the base64_encode function to encode it. It is because of this encoding that the receiving server can perform base64 decoding, and then convert the obtained message into the actual business information needed. Then, it is combined with the webhook of the resource and pushed to the system for processing.

[0079] The entire system requires EMQX middleware version 3.1.0 or higher, a Java runtime environment of JDK 8 or higher, and a caching system of Redis version 3.0 or higher. It also needs to provide a Linux environment for application deployment. For high availability, the servers receiving push services and EMQX should preferably use a multi-node cluster. Spring Boot version 1.5 or higher should be used to facilitate rapid development of the web push interface.

[0080] In summary, the embodiments of this application can obtain vehicle online and offline information very accurately, and can obtain vehicle offline status information even when the vehicle network is poor. It also provides a fast and convenient query interface function, which balances accuracy and speed. Moreover, this function can be abstracted and reused as a separate component for all systems in the entire department to use to obtain vehicle online information, without relying heavily on MongoDB messages.

[0081] Next, a vehicle status acquisition device according to an embodiment of this application is described with reference to the accompanying drawings.

[0082] Figure 5 This is a block diagram of a vehicle status acquisition device according to an embodiment of this application.

[0083] like Figure 5 As shown, the vehicle status acquisition device 10 is applied to middleware, wherein the device includes: a first acquisition module 110, a determination module 120 and an update module 130.

[0084] The first acquisition module 110 is used to acquire the message reported by the vehicle; the determination module 120 is used to determine the actual status of the vehicle based on the message; and the update module 130 is used to update the vehicle status list based on the actual status, wherein the server acquires the actual status of the vehicle from the status list of the middleware.

[0085] It should be noted that the foregoing explanation of the vehicle status acquisition method embodiment also applies to the vehicle status acquisition device of this embodiment, and will not be repeated here.

[0086] According to the vehicle status acquisition device proposed in the embodiments of this application, the device acquires the messages reported by the vehicle to determine the actual status of the vehicle, updates the vehicle status list according to the actual status, and the server can obtain the actual status of the vehicle from the status list of the middleware, thereby accurately and directly obtaining the online status of the vehicle, improving the user experience and vehicle safety.

[0087] Next, a vehicle status acquisition device according to another embodiment of this application is described with reference to the accompanying drawings.

[0088] Figure 6 This is a block diagram of a vehicle status acquisition device according to an embodiment of this application.

[0089] like Figure 6 As shown, the vehicle status acquisition device 20 is applied to middleware, wherein the device includes: a sending module 210, a second acquisition module 220 and a third acquisition module 230.

[0090] The sending module 210 is used to send an acquisition request to the middleware; the second acquisition module 220 is used to acquire the status list sent by the middleware, wherein the middleware uses the messages reported by the vehicle to determine the actual status of the vehicle and updates the vehicle status list according to the actual status; the third acquisition module 230 is used to acquire the actual status of the vehicle according to the status list.

[0091] It should be noted that the foregoing explanation of the vehicle status acquisition method embodiment also applies to the vehicle status acquisition device of this embodiment, and will not be repeated here.

[0092] According to the vehicle status acquisition device proposed in the embodiments of this application, an acquisition request is sent to the middleware and a status list is received from the middleware. The actual status of the vehicle is obtained according to the status list, thereby accurately and directly obtaining the online status of the vehicle, improving the user experience and vehicle safety.

[0093] Figure 7 A schematic diagram of the structure of a vehicle provided in an embodiment of this application. The vehicle may include:

[0094] The memory 701, the processor 702, and the computer program stored on the memory 701 and executable on the processor 702.

[0095] When the processor 702 executes the program, it implements the vehicle status acquisition method provided in the above embodiments.

[0096] Furthermore, the vehicle also includes:

[0097] Communication interface 703 is used for communication between memory 701 and processor 702.

[0098] The memory 701 is used to store computer programs that can run on the processor 702.

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

[0100] If the memory 701, processor 702, and communication interface 703 are implemented independently, then the communication interface 703, memory 701, and processor 702 can be interconnected via a bus to complete communication between them. 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 address bus, data bus, control bus, etc. For ease of representation, Figure 7 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0101] Optionally, in a specific implementation, if the memory 701, processor 702, and communication interface 703 are integrated on a single chip, then the memory 701, processor 702, and communication interface 703 can communicate with each other through an internal interface.

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

[0103] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the vehicle status acquisition method described above.

[0104] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

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

[0106] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0107] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (FPGAs), field-programmable gate arrays (FPGAs), etc.

[0108] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0109] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A method for obtaining vehicle status, characterized in that, The method is applied to middleware, and the method includes the following steps: Obtain the messages reported by the vehicle; The actual status of the vehicle is determined based on the message, wherein, before determining the actual status of the vehicle based on the message, the method further includes: obtaining the client identifier of the vehicle's TBOX; querying the vehicle identifier based on the client identifier; querying the display status of the corresponding vehicle based on the vehicle identifier; the step of determining the actual status of the vehicle based on the message includes: if the message is a login message, then determining the actual status as online; if the message is a logout message, then determining the actual status as offline. The vehicle status list is updated according to the actual status, wherein the server obtains the actual status of the vehicle from the status list of the middleware, and updating the vehicle status list according to the actual status includes: obtaining the current status of the vehicle; determining whether the current status is consistent with the actual status, and if they are inconsistent, updating the displayed status in the status list to the actual status.

2. The vehicle status acquisition method according to claim 1, characterized in that, Before obtaining the message reported by the vehicle, the following is included: The target message event is encoded to obtain the configuration file for the target message event; Add the target server address interface to the configuration file, set the type of the target message event, and push the configuration file to the vehicle terminal.

3. A vehicle status acquisition device, characterized in that, The device is used in middleware, wherein the device includes: The first acquisition module is used to acquire the messages reported by the vehicle; The determination module is used to determine the actual status of the vehicle based on the message. Before determining the actual status of the vehicle based on the message, the module further includes: obtaining the client identifier of the vehicle's TBOX; querying the vehicle identifier based on the client identifier; and querying the display status of the corresponding vehicle based on the vehicle identifier. The determination of the actual status of the vehicle based on the message includes: if the message is a login message, determining that the actual status is online; if the message is a logout message, determining that the actual status is offline. An update module is used to update the vehicle status list according to the actual status. The server obtains the actual status of the vehicle from the status list of the middleware. Updating the vehicle status list according to the actual status includes: obtaining the current status of the vehicle; determining whether the current status is consistent with the actual status; if they are inconsistent, updating the displayed status in the status list to the actual status.

4. A middleware, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the vehicle state acquisition method as described in any one of claims 1-2.

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

Images