Vehicle condition data real-time updating method, device and equipment and storage medium

Abstract

The invention discloses a vehicle condition data real-time updating method, device and equipment and a storage medium, and relates to the technical field of Internet of Vehicles, and the vehicle condition data real-time updating method comprises the steps: obtaining target subscription data, target vehicle condition data and historical vehicle condition data; comparing the target vehicle condition data with the historical vehicle condition data to obtain a comparison result; when the comparison result is different, extracting a vehicle identification code from the target vehicle condition data; according to the vehicle identification code and the target subscription data, screening from the target vehicle condition data to obtain to-be-pushed data; and pushing the to-be-pushed data to a mobile terminal through a publish-subscribe normal form message protocol, so that the mobile terminal updates the vehicle condition data on a mobile terminal interface according to the to-be-pushed data. The vehicle condition data can be accurately displayed in real time, a user can master the latest state of the vehicle in real time, the real-time monitoring capability of the user on the vehicle state is enhanced, and the user stickiness is improved.

Description

Technical Field

[0001] The present application relates to the field of vehicle networking technology, and in particular to a method, device, equipment and storage medium for real-time updating of vehicle condition data. Background Art

[0002] With the rapid development of Internet of Vehicles technology, the amount of data generated by vehicles has increased dramatically, including location information, driving data, endurance data, etc. These data are crucial for vehicle monitoring, maintenance and user experience. Users want to know the status of the vehicle in real time so that they can make timely responses and decisions. Therefore, it is particularly important to display vehicle condition data in real time and accurately on the Internet of Vehicles APP, which can not only improve the user experience, but also enhance the intelligent management of vehicles.

[0003] At present, the method of displaying vehicle condition data on the APP side mainly relies on calling the back-end API to query vehicle condition data. After receiving the request, the back-end service will query the vehicle condition data in the database and return the query results to the APP. This method is a traditional polling mechanism. Users need to manually pull down and refresh the interface to obtain the latest vehicle condition data, or rely on a scheduled polling mechanism to update the data.

[0004] However, this implementation has some obvious disadvantages. First, because data acquisition depends on timed polling or user-triggered requests, true real-time data updates cannot be achieved, resulting in the inability to guarantee the real-time nature of the data. Secondly, frequent API calls may increase the load on the server, affecting server performance and response speed. In addition, for multiple users in the same car, if user A pulls down to refresh and user B does not pull down to refresh, the vehicle condition data seen by the two users on the APP will be inconsistent, which will affect the user experience. Therefore, how to display vehicle condition data in real time and accurately has become an urgent problem to be solved.

[0005] The above contents are only used to assist in understanding the technical solution of the present application and do not constitute an admission that the above contents are prior art. Summary of the invention

[0006] The purpose of this application is to provide a method, device, equipment and storage medium for real-time updating of vehicle condition data, aiming to solve the technical problem of how to display vehicle condition data in real time and accurately.

[0007] To achieve the above purpose, the present application proposes a method for real-time updating of vehicle condition data, the method comprising: Obtain target subscription data, target vehicle condition data, and historical vehicle condition data; Comparing the target vehicle condition data with the historical vehicle condition data to obtain a comparison result; When the comparison result is different, extracting a vehicle identification code from the target vehicle condition data; Filtering the target vehicle condition data to obtain the data to be pushed according to the vehicle identification code and the target subscription data; The data to be pushed is pushed to the mobile terminal through a publish-subscribe paradigm message protocol, so that the mobile terminal updates the vehicle condition data on the mobile terminal interface according to the data to be pushed.

[0008] In one embodiment, the step of filtering the target vehicle condition data to obtain the data to be pushed according to the vehicle identification code and the target subscription data includes: Searching and obtaining a subscription field from the target subscription data according to the vehicle identification code; When the subscription field is not empty, the data to be pushed is obtained by filtering the target vehicle condition data according to the subscription field.

[0009] In one embodiment, the step of searching for a subscription field from the target subscription data according to the vehicle identification code comprises: Calculating a hash value of the vehicle identification code according to a preset hash function; According to the hash value, a corresponding hash bucket is searched from the target subscription data; The hash bucket and the linked list on the hash bucket are traversed to find and obtain the subscription field.

[0010] In one embodiment, the step of obtaining target vehicle condition data includes: Get vehicle condition data message; Converting the vehicle condition data message into a byte sequence; Extracting each field from the byte sequence according to a preset protocol structure; Construct a JSON object based on the fields; The JSON object is converted into a JSON string format to obtain the target vehicle condition data.

[0011] In one embodiment, the step of obtaining target subscription data includes: Get the first subscription data from the cache data; In the case where the second subscription data sent by the mobile terminal is not received, using the first subscription data as the target subscription data; When the second subscription data sent by the mobile terminal is received, the first subscription data in the cache data is replaced by the second subscription data, and the second subscription data is used as the target subscription data.

[0012] In one embodiment, the step of pushing the data to be pushed to the mobile terminal through a publish-subscribe paradigm message protocol so that the mobile terminal updates the vehicle condition data on the mobile terminal interface according to the data to be pushed includes: Establish connections with multiple mobile terminals through a publish-subscribe paradigm messaging protocol; When the connection is successfully established, obtaining an initial message to be sent according to the data to be pushed and the subscription field; Serializing, encrypting and compressing the initial message to be sent to obtain a target message to be sent; The target message to be sent is sent to the mobile terminal according to a preset push strategy, so that the mobile terminal updates the vehicle condition data on the mobile terminal interface according to the target message to be sent.

[0013] In one embodiment, when the comparison result is different, the step of extracting a vehicle identification code from the target vehicle condition data includes: When the comparison result is different, the target vehicle condition data is parsed to obtain a JSON key-value pair; A vehicle status dictionary is constructed based on the JSON key-value pairs and the preset container structure; Get the key name corresponding to the vehicle identification code; The vehicle identification code is obtained by searching the vehicle status dictionary according to the key name.

[0014] In addition, to achieve the above purpose, the present application also proposes a vehicle condition data real-time update device, the device comprising: A data acquisition module is used to acquire target subscription data, target vehicle condition data, and historical vehicle condition data; A data comparison module, used for comparing the target vehicle condition data with the historical vehicle condition data to obtain a comparison result; A data extraction module, used for extracting a vehicle identification code from the target vehicle condition data when the comparison result is different; A data screening module, used for screening the target vehicle condition data to obtain the data to be pushed according to the vehicle identification code and the target subscription data; The data push module is used to push the data to be pushed to the mobile terminal through the publish-subscribe paradigm message protocol, so that the mobile terminal updates the vehicle condition data on the mobile terminal interface according to the data to be pushed.

[0015] In addition, to achieve the above-mentioned purpose, the present application also proposes a real-time update device for vehicle condition data, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, and the computer program is configured to implement the steps of the real-time update method for vehicle condition data as described above.

[0016] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by the processor, the steps of the real-time update method of vehicle condition data as described above are implemented.

[0017] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, it implements the steps of the real-time update method of vehicle condition data as described above.

[0018] One or more technical solutions proposed in this application have at least the following technical effects: Obtain target subscription data, target vehicle condition data and historical vehicle condition data; compare the target vehicle condition data with the historical vehicle condition data to obtain a comparison result; when the comparison result is different, extract the vehicle identification code from the target vehicle condition data; filter the target vehicle condition data to obtain the data to be pushed according to the vehicle identification code and the target subscription data; push the data to be pushed to the mobile terminal through the publish-subscribe paradigm message protocol, so that the mobile terminal updates the vehicle condition data on the mobile terminal interface according to the data to be pushed. First, collect the target subscription data to understand the user's personalized needs for vehicle condition information, which helps to provide customized services; then, the system obtains the target vehicle condition data and compares it with the historical vehicle condition data to determine whether there is a new change in the vehicle status. This step avoids unnecessary data transmission and improves the efficiency of data processing. If a change is detected, the system will extract the vehicle identification code from the target vehicle condition data to ensure that the data is accurately matched with the specific vehicle, thereby enhancing the accuracy of data push. Then, the system filters the data to be pushed according to the vehicle identification code and the data type subscribed by the user. This process ensures that only the data that the user cares about and has changed is sent, which improves the relevance of information and user experience. Finally, the system sends the data to be pushed to the mobile terminal. After receiving the data, the mobile terminal updates the vehicle condition information on the interface, and can display the vehicle condition data in real time and accurately, allowing users to instantly grasp the latest status of the vehicle, improving user experience and satisfaction. At the same time, it also enhances the user's real-time monitoring ability of the vehicle status, and overall improves the response speed and user stickiness of the Internet of Vehicles service. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0020] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0021] Figure 1 A flowchart diagram of a first embodiment of a method for real-time updating of vehicle condition data of the present application; Figure 2 A schematic diagram of a subscription data storage format provided in the first embodiment of the vehicle condition data real-time update method of the present application; Figure 3 A schematic diagram of a subscription process provided in Embodiment 1 of the method for real-time updating of vehicle condition data of this application; Figure 4 A flowchart diagram of the second embodiment of the method for real-time updating of vehicle condition data of the present application; Figure 5 A schematic diagram of a brief flow chart of a method for real-time updating of vehicle condition data provided in Example 2 of the present application; Figure 6 A schematic diagram of the system architecture of the method for real-time updating of vehicle condition data provided in the second embodiment of the present application; Figure 7 A schematic diagram for comparing real-time updating of data in a method for real-time updating of vehicle condition data provided in Embodiment 2 of the present application; Figure 8 This is a schematic diagram of the module structure of the vehicle condition data real-time updating device according to an embodiment of the present application; Fig. 9 Schematic diagram of the device structure of the hardware operating environment involved in the real-time update method of vehicle condition data in the embodiment of the present application.

[0022] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0023] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0024] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0025] With the development of Internet of Vehicles technology, the amount of data generated by vehicles has increased dramatically, including information such as location, driving and endurance, which is crucial for vehicle monitoring, maintenance and user experience. Users want to know the vehicle condition in real time to make quick decisions, so it is important to display the vehicle condition in real time and accurately on the Internet of Vehicles APP, which not only improves the user experience but also strengthens the intelligent management of vehicles. At present, the APP queries and displays vehicle condition data by calling the back-end API, using the traditional polling mechanism, that is, users need to refresh manually or the system automatically refreshes at a fixed time to obtain the latest data. This method is not only difficult to ensure the real-time nature of the data, but may also increase the server burden and reduce response efficiency due to frequent API requests. It will also cause data inconsistency among multiple users, affecting the user experience.

[0026] The main solution of the embodiment of the present application is: first, collect the user's personalized needs for vehicle condition information to provide customized services; then, the system obtains and compares the target vehicle condition data with historical data, detects changes in vehicle status, reduces unnecessary data transmission, and improves efficiency. If changes are found, the system will accurately match the data based on the vehicle identification code, and filter out relevant change information based on user subscriptions to ensure the accuracy and relevance of the push, thereby optimizing the user experience. Finally, push the updated data to the mobile terminal, and the mobile terminal will update the vehicle condition information immediately after receiving it.

[0027] It should be noted that the execution subject of the embodiment of the present application can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device capable of realizing the above functions, a cloud server system, etc. The following takes the cloud server system as an example to illustrate this embodiment and the following embodiments.

[0028] Based on this, the embodiment of the present application provides a method for updating vehicle condition data in real time. Figure 1 , Figure 1 This is a flow chart of the first embodiment of the real-time updating method for vehicle condition data of the present application.

[0029] In this embodiment, the vehicle condition data real-time updating method includes steps S10 to S50: Step S10, obtaining target subscription data, target vehicle condition data and historical vehicle condition data; It should be noted that the cloud server includes a connection layer framework, a message decoding service, a large data stream processing program, and a data management service. The target subscription data refers to the type of vehicle condition data subscribed by the APP end user according to personal needs. In this embodiment, the APP end user can subscribe to the vehicle condition data of interest by calling the subscription interface of the data management (DM) service, such as the mileage of the vehicle, the temperature inside the vehicle, etc. These subscription conditions will be stored in the Redis cache by the DM service so that the corresponding vehicle condition data can be pushed according to the user's subscription conditions in the future. Specifically, the key in Redis is the unique identifier of the vehicle (such as vinId), the hashKey is the topic (the identifier of the APP user), and the hashValue is the type of vehicle condition data subscribed by the user. Therefore, the target subscription data is the user's customized data requirement, which is used to guide the DM service to push the vehicle condition information they care about to specific users. The target vehicle condition data refers to the actual status data of the vehicle at the current moment. These data include but are not limited to the vehicle's location information, driving data, endurance data, etc. The target vehicle condition data is real-time updated data, which is the latest information that the DM service needs to push to users who have subscribed to these data. Historical vehicle condition data specifically refers to the vehicle status information that was successfully acquired and pushed to the user last time. This data is used as a comparison benchmark to identify changes in vehicle status.

[0030] It can be understood that, first, the DM service obtains the target subscription data by querying the Redis cache. This step involves retrieving the types of vehicle condition data subscribed by the APP-side user identifier (such as IMEI) associated with the specific vehicle VIN code, in order to filter out the data items that the user is interested in. Then, the big data Flink program monitors the real-time changes in vehicle status, collects target vehicle condition data, and saves historical vehicle condition data, which includes the hexadecimal messages received from the TBox. After being converted into JSON format by the decoding service, the Flink program monitors these data to identify any changes in the vehicle status.

[0031] Please refer to Figure 2 , Figure 2A schematic diagram of the subscription data storage format provided for the first embodiment of the method for real-time updating of vehicle condition data of the present application shows the table format for storing subscription data in the cloud server system, where each row represents the subscription information of a user. The first column of the table is ID, which is a self-incrementing serial number used to uniquely identify each subscription entry. Two subscription entries are shown here, with IDs 1 and 2 respectively. The second column is Key, which represents the unique identifier of the vehicle, such as the VIN code, which is represented here by topic1 and topic2. The third column is Value, which lists the types of vehicle condition data subscribed by the user, separated by commas, for example, topic1 subscribes to "mile", and topic2 subscribes to "mile" and "temperature". The rightmost column is "Enter keyword search" to implement the search function. The design of the entire table is to quickly match the vehicle with the data subscribed by the user so that the system can efficiently push real-time vehicle condition information.

[0032] As an example, the steps of obtaining target vehicle condition data include: obtaining a vehicle condition data message; converting the vehicle condition data message into a byte sequence; extracting each field from the byte sequence according to a preset protocol structure; constructing a JSON object according to the fields; converting the JSON object into a JSON string format to obtain the target vehicle condition data.

[0033] The vehicle condition data message refers to a data packet collected and generated by the vehicle's onboard intelligent terminal (Telematics Box, TBox). It contains various status information of the vehicle, such as location, speed, battery status, etc. These data originally exist in the form of internal vehicle communication protocols and need to be transmitted to the cloud for further processing. Byte sequence refers to the representation of the vehicle condition data message in the computer system, that is, a collection of a series of bytes. In this embodiment, the vehicle condition data message collected by the TBox will be converted into a byte sequence before being sent to the cloud server for transmission over the network. The preset protocol structure refers to the data communication format and rules agreed upon between the TBox and the cloud. This structure defines the arrangement order, data type and length of each data item in the vehicle condition data message, so that the cloud server can correctly parse the message content. In this embodiment, the message decoding service of the cloud server will parse the byte sequence according to this preset protocol structure. Field refers to a specific data item extracted from the vehicle condition data message according to the preset protocol structure. For example, one field can be the speed value of the vehicle, and another field can be the battery power of the vehicle. Each field corresponds to a specific state or parameter of the vehicle. A JSON object refers to a data structure constructed using the JavaScript Object Notation (JSON) format. It consists of a series of key-value pairs, where the key is a string and the value can be a string, a number, a Boolean value, an array, or another JSON object. In this embodiment, the message decoding service constructs the extracted fields into a JSON object for subsequent processing and transmission. The JSON string format refers to the string form in which the JSON object is converted. This format is easy to read and write, and is also convenient for data storage and exchange. In this embodiment, the constructed JSON object will be converted into a JSON string format, so that the target vehicle condition data can be transmitted on the network in text form, and can be further processed and analyzed by the big data Flink program on the cloud server.

[0034] First, the system collects the real-time status information of the vehicle through TBox to form vehicle condition data packets, which are original data packets containing various status information of the vehicle. Then, these vehicle condition data packets are converted into byte sequences for transmission to the cloud through the network. Byte sequences are the binary representation of data in computers, which enables data to be transmitted in different systems and networks. Then, the cloud-based message decoding service extracts each specific data field from the byte sequence, such as speed, battery power, etc., according to the communication protocol structure preset with TBox. These fields are specific components of vehicle condition data, and each field represents a specific parameter of the vehicle. Subsequently, these fields are used to construct a JSON object, which is a lightweight data exchange format that organizes data in the form of key-value pairs, making the data structure clear, easy to understand and process. Finally, this JSON object is converted into JSON string format, so that the target vehicle condition data exists in a standardized text form, which is convenient for storage, transmission and further processing, thus completing the conversion process from vehicle status information to actionable data.

[0035] As an example, the step of obtaining target subscription data includes: obtaining first subscription data from cached data; when second subscription data sent by the mobile terminal is not received, using the first subscription data as target subscription data; when the second subscription data sent by the mobile terminal is received, replacing the first subscription data in the cached data with the second subscription data, and using the second subscription data as target subscription data.

[0036] The cached data refers to the vehicle condition data subscription information stored in the Redis cache of the DM service. This information includes the user's (i.e., APP) subscription requirements for vehicle status information. They are temporarily stored in the cache for quick access and processing. The first subscription data refers to the last subscription information stored in the Redis cache of the DM service. This data defines the type of vehicle condition data that the user was interested in last time. For example, the user may have subscribed to information such as the vehicle's mileage and battery status. The mobile terminal here refers to the Internet of Vehicles APP used by the user. It is the interface for the user to interact with the vehicle condition data. The user subscribes to the vehicle condition data they want to receive through this APP and receives real-time updates from the DM service. The second subscription data refers to the updated subscription information sent by the user to the DM service through the mobile terminal (Internet of Vehicles APP). This may be due to the user changing the type of vehicle condition data they want to receive, or adding new subscription requirements. When the user updates their subscription preferences, these new subscription information are called second subscription data.

[0037] First, the system extracts the first subscription data originally set by the user from the Redis cache. These data reflect the user's last subscription preference for vehicle condition information. Then, if the system does not receive updated second subscription data from the mobile terminal (i.e., the Internet of Vehicles APP used by the user), the system will directly use these first subscription data as target subscription data to determine which vehicle condition information needs to be pushed to the user. However, if the system receives the second subscription data sent by the user through the mobile terminal, these data may contain updates or changes to the user's subscription preferences. The system will replace the original first subscription data in the cache with these second subscription data, and use the updated second subscription data as the target subscription data to ensure that users can receive the latest vehicle condition information they are interested in. This process ensures real-time updating and personalization of subscription data to meet users' latest needs for vehicle condition information.

[0038] Please refer to Figure 3 , Figure 3 The subscription process diagram provided for the first embodiment of the method for real-time updating of vehicle condition data of this application shows the specific process of a mobile terminal (APP terminal) user subscribing to vehicle data. Starting from the APP calling the subscription data interface, the system first checks whether the Redis cache is empty to determine whether there is any user's subscription data. If the cache is not empty, the system checks whether the specific vehicle identification code (VIN) and topic exist in the cache. For new car users or newly subscribed data, the system creates a new hash table entry in Redis, uses the VIN and topic as keys, and stores the subscribed data field set in the field of the hash table. If there are multiple subscribers subscribing to the data of the same vehicle, the system merges the data of these subscribers. Finally, the system sets the expiration time of the entry in Redis to ensure the timeliness of the data. The whole process ensures that users can receive real-time updates on the vehicle status they subscribe to, and improves the speed of data retrieval and push through the efficient caching mechanism of Redis.

[0039] Step S20, comparing the target vehicle condition data with the historical vehicle condition data to obtain a comparison result; It should be noted that the comparison result refers to the conclusion obtained by comparing the target vehicle condition data (i.e., the latest status data of the vehicle) with the historical vehicle condition data (i.e., the vehicle status data successfully pushed to the user last time) item by item. This comparison process is to identify whether the vehicle status has changed since the last data push. Specifically, the comparison result includes two cases: (1) Same: If each field in the target vehicle condition data is exactly the same as the corresponding field in the historical vehicle condition data and has not changed, then the comparison result is "same". This means that the relevant status of the vehicle has not changed since the last data push, so there is no need to push these unchanged data to the user again. (2) Different: If any field in the target vehicle condition data is inconsistent with the corresponding field in the historical vehicle condition data, indicating that the vehicle status has changed, then the comparison result is "different". In this case, the system will mark the changed data and prepare to push these updated data to the user so that the user can be aware of the latest status of the vehicle in a timely manner.

[0040] It can be understood that it starts with the JSON string format of the latest vehicle condition data received by the big data Flink program in the cloud server. Then, the cloud server system will compare these latest data with the historical vehicle condition data stored in the database or cache item by item. The purpose of the comparison is to identify which data items have changed, such as key parameters such as the vehicle's location, speed, and battery power. If the value of any data item is found to be inconsistent between the latest data and the historical data, the system will mark these changes and use these changes as the comparison results. A comparison result of "different" means that there is new data that needs to be pushed to the user, while "same" means that the vehicle status has not changed and no update is required. This comparison mechanism ensures that only data that has truly changed is pushed, optimizing data transmission efficiency and improving user experience.

[0041] Step S30, when the comparison result is different, extracting a vehicle identification code from the target vehicle condition data; It should be noted that the Vehicle Identification Number (VIN) refers to the unique identifier of a vehicle. VIN is a set of 17 characters that uniquely identify motor vehicles, including cars, motorcycles, trucks and other vehicles. Each VIN contains information about the vehicle's manufacturer, year of production, place of production, chassis type, engine type, etc.

[0042] It is understandable that when the comparison results show that the target vehicle condition data is inconsistent with the historical vehicle condition data, that is, there is a difference, the system will extract the vehicle identification number (VIN) from the target vehicle condition data. This step is to ensure that the specific vehicle can be accurately identified and associated during the data push process. The vehicle identification number (VIN) is a unique identifier for the vehicle. It contains key information such as the manufacturer, model, and production year of the vehicle, so that each vehicle can be individually identified. In the JSON object of the target vehicle condition data, VIN is stored and transmitted as a key field. The system parses this JSON object to find and extract the value of the VIN field, which is then used to match specific vehicles and users to ensure that only relevant users receive the latest status updates of their vehicles. This process is critical to maintaining the accuracy and security of the data because it prevents data from being mistakenly pushed to irrelevant users, while also ensuring that users receive the correct information about the vehicles they care about.

[0043] As an example, when the comparison result is different, the step of extracting the vehicle identification code from the target vehicle condition data includes: when the comparison result is different, parsing the target vehicle condition data to obtain a JSON key-value pair; constructing a vehicle status dictionary based on the JSON key-value pair and a preset container structure; obtaining the key name corresponding to the vehicle identification code; and searching the vehicle identification code from the vehicle status dictionary according to the key name.

[0044] JSON key-value pairs refer to the basic elements that make up a JSON object, where a "key" is a string that identifies the name of a data item, and a "value" can be a string, a number, a Boolean value, an array, or another JSON object. In the context of vehicle condition data, each key-value pair represents a specific vehicle condition information, for example, "speed" may correspond to a numeric value, and "engine status" may correspond to a descriptive string. The preset container structure refers to a data structure that is pre-defined during system design and is used to organize and store vehicle condition data. This structure is usually a template that defines how to organize JSON key-value pairs into higher-level data structures, such as dictionaries or objects. In this embodiment, the preset container structure refers to a specific data model that specifies how vehicle status information should be organized and accessed. The vehicle status dictionary refers to a data structure constructed according to the preset container structure. It organizes JSON key-value pairs into a format that can be easily accessed and processed. It is usually a set of keys mapped to values. In this dictionary, each key corresponds to a specific vehicle condition data item, and the value is the specific information of the data item. The vehicle status dictionary enables the system to quickly retrieve and operate vehicle condition data. A key is a string used to identify a data item in a JSON key-value pair. In the vehicle status dictionary, the key is used to quickly locate and access specific vehicle status data. For example, if the vehicle identification number (VIN) is stored under a key called "vin", then "vin" is the key.

[0045] The system first parses the target vehicle condition data, which is usually a string in JSON format. The system converts it into JSON key-value pairs, which are the basic elements that make up the JSON object. Each key corresponds to a specific vehicle condition data item, for example, "speed" may correspond to the current speed of the vehicle. Then, the system constructs a vehicle status dictionary based on these key-value pairs and the preset container structure. This dictionary is a data structure that organizes vehicle condition data in a predefined format so that each vehicle condition data item can be accessed through a unique key name. Then, the system determines the key name corresponding to the vehicle identification number (VIN). This key name is predefined and is used to identify the data item of the vehicle identification number. Finally, the system uses this key name as an index to find and extract the vehicle identification number from the vehicle status dictionary. For example, if the vehicle status dictionary is constructed like this: {"vin": "1HGCM82633A004352", "speed": "65 mph", "engine_temperature": "85°C"}, then "vin" is the key name corresponding to the vehicle identification code. The system will use this key name to find and extract the vehicle identification code "1HGCM82633A004352" to ensure the accuracy and pertinence of data push.

[0046] Step S40, filtering the target vehicle condition data to obtain the data to be pushed according to the vehicle identification code and the target subscription data; It should be noted that the data to be pushed refers to the vehicle status information that is prepared to be sent to a specific user after being filtered according to the subscription data.

[0047] It can be understood that, first, the system locates the latest status information of a specific vehicle in the target vehicle condition data through the vehicle identification number (VIN), which may include multiple fields such as speed, temperature, and battery power. Then, the system refers to the target subscription data, that is, the type of vehicle status information subscribed by the user through the APP, such as the user may subscribe to the battery status and location information of the vehicle. Next, the system filters out the data items of interest to the user from the located vehicle status information based on the user's subscription preferences. For example, if the user subscribes to the battery status, the system will extract the specific value of the battery status from the target vehicle condition data. Finally, the filtered data items are combined into data to be pushed, which will be packaged and prepared to be pushed to users in real time to ensure that users can receive the latest vehicle status information they care about. This process ensures that only the relevant data subscribed by the user will be pushed, which improves the pertinence and efficiency of data push.

[0048] Step S50: Push the data to be pushed to the mobile terminal through a publish-subscribe paradigm message protocol, so that the mobile terminal updates the vehicle condition data on the mobile terminal interface according to the data to be pushed.

[0049] It should be noted that Message Queuing Telemetry Transport (MQTT) refers to a lightweight, publish / subscribe-based messaging protocol designed for low-bandwidth, high-latency or unreliable network environments. MQTT allows devices to publish messages to specific topics, while other devices can subscribe to these topics to receive messages. This protocol is very popular in the Internet of Things (IoT) and the Internet of Vehicles (IoV) because it can effectively transmit messages between devices and maintain high performance and reliability even under poor network conditions. The mobile interface refers to the user interface of the Internet of Vehicles APP used by users. This is the front-end display for users to interact with vehicle data. On this interface, users can view various vehicle status data, such as the vehicle's location, speed, battery status, etc. When the MQTT protocol sends the data to be pushed to the user's mobile phone or other mobile device, the mobile interface will update the displayed information based on the newly received data, so that users can see the latest status of the vehicle in real time. This real-time update improves the user experience and enables users to understand the dynamic changes of the vehicle in a timely manner.

[0050] It is understandable that first, the DM service will filter out the data that users are concerned about from the target vehicle condition data based on the vehicle information and vehicle identification code subscribed by the user, and form the data to be pushed. This is done to ensure that only the information they are interested in is sent to users, improving the relevance of information and user experience. Then, the DM service encapsulates these data to be pushed into messages through the MQTT protocol and sends them to a specific topic associated with the user's vehicle. This is because the MQTT protocol supports an efficient publish-subscribe model, which can ensure that messages are accurately delivered to all users who have subscribed to the topic, and maintain the reliability of messages even in unstable network conditions. Finally, after receiving these messages, the mobile terminal will parse and update the vehicle condition information on the APP interface based on these data, such as updating the vehicle location, battery status, etc. The effect of this is that users can see the latest status of the vehicle in real time without manual refresh, thereby providing instant and accurate information feedback, enhancing users' understanding of the vehicle status and satisfaction with the APP.

[0051] As an example, the step of pushing the data to be pushed to a mobile terminal through a publish-subscribe paradigm message protocol so that the mobile terminal updates the vehicle condition data on the mobile terminal interface according to the data to be pushed includes: establishing connections with multiple mobile terminals through a publish-subscribe paradigm message protocol; when the connection is successfully established, obtaining an initial message to be sent based on the data to be pushed and the subscription field; serializing, encrypting and compressing the initial message to be sent to obtain a target message to be sent; and sending the target message to be sent to the mobile terminal according to a preset push strategy, so that the mobile terminal updates the vehicle condition data on the mobile terminal interface according to the target message to be sent.

[0052] Connection refers to the network communication link established with multiple mobile terminals (such as the Internet of Vehicles APP on a smartphone or tablet) through the publish-subscribe paradigm messaging protocol (MQTT). This step is to ensure that data can be transmitted from the server (DM service) to the client (the user's mobile device). After the connection is established, the server can identify each client and send messages to it according to the topic it subscribes to. The initial message to be sent refers to the message generated based on the data to be pushed (the vehicle status information subscribed by the user) and the subscription field (the data item of interest specified by the user). This message contains all the information that the user needs to receive, but it needs to be serialized, encrypted and compressed before sending. Serialization refers to the conversion of data structure or object state into a storable or transmittable format (such as JSON, XML, etc.). Encryption is to ensure the security of data during transmission and prevent unauthorized access to data. Compression is to reduce the size of data, speed up transmission speed, and save bandwidth. These three steps ensure the safe and efficient transmission of data. The target message to be sent is the initial message to be sent after serialization, encryption and compression. This message is ready to be sent to the mobile terminal. It is both safe and efficient and can be transmitted quickly over the network. A preset push policy refers to a set of rules predefined according to business needs and network conditions to determine when and how to push messages to the mobile terminal, which may include push priority, time interval, network conditions (such as only pushing on Wi-Fi to save data traffic), etc. For example, if the battery power of the vehicle is below a certain threshold, the system may push a warning message immediately, while other less urgent information may be pushed in batches at certain time intervals. For example, assuming that the user subscribes to the real-time location and battery status of the vehicle, the system first establishes an MQTT connection with the user's mobile terminal. When there is new vehicle condition data, the system generates an initial to-be-sent message containing the location and battery status. Then, the system serializes this message into JSON format, encrypts it, and compresses it to reduce the data size to form the target to-be-sent message. Finally, according to the preset push policy (such as giving priority to pushing urgent information), the system sends this message to the user's mobile terminal, which receives and parses the message, and then updates the vehicle's location and battery status information on the interface. In this way, the user can see the latest status of the vehicle in real time.

[0053] This embodiment provides a method for real-time updating of vehicle condition data, which obtains target subscription data, target vehicle condition data and historical vehicle condition data; compares the target vehicle condition data with the historical vehicle condition data to obtain a comparison result; when the comparison result is different, extracts a vehicle identification code from the target vehicle condition data; filters the target vehicle condition data according to the vehicle identification code and the target subscription data to obtain the data to be pushed; pushes the data to be pushed to the mobile terminal through the publish-subscribe paradigm message protocol, so that the mobile terminal updates the vehicle condition data on the mobile terminal interface according to the data to be pushed. First, collect the target subscription data to understand the user's personalized needs for vehicle condition information, which helps to provide customized services; then, the system obtains the target vehicle condition data and compares it with the historical vehicle condition data to determine whether there is a new change in the vehicle status. This step avoids unnecessary data transmission and improves the efficiency of data processing. If a change is detected, the system will extract the vehicle identification code from the target vehicle condition data to ensure that the data accurately matches the specific vehicle, thereby enhancing the accuracy of data push. Then, the system selects the data to be pushed based on the vehicle identification code and the data type subscribed by the user. This process ensures that only the data that the user cares about and has changed is sent, which improves the relevance of information and user experience. Finally, the system sends the data to be pushed to the mobile terminal through the MQTT protocol. After receiving the data, the mobile terminal updates the vehicle condition information on the interface, which can display the vehicle condition data in real time and accurately, allowing users to instantly grasp the latest status of the vehicle, improving user experience and satisfaction, while also enhancing the user's ability to monitor the vehicle status in real time, and overall improving the response speed and user stickiness of the Internet of Vehicles service.

[0054] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can refer to the above introduction, and will not be repeated later. Figure 4 , Figure 4 This is a flow chart of a second embodiment of the method for real-time updating of vehicle condition data of the present application. Step S40 of the method for real-time updating of vehicle condition data includes steps S41-S42: Step S41, searching for a subscription field from the target subscription data according to the vehicle identification code; It should be noted that subscription fields refer to specific vehicle condition data types or attributes specified by users in their subscription settings. These are the data items that users want to receive updates for. Each subscription field corresponds to a specific vehicle status parameter, such as "battery level", "location", "speed", etc. When the system searches from the target subscription data based on the vehicle identification number (VIN), it is actually looking for the user subscription information associated with the vehicle identification number. The system retrieves the types of vehicle condition data that the user wants to receive. These types are "subscription fields", which define which vehicle condition data will be monitored in real time and pushed to the user. For example, if a user subscribes to the "battery level" and "location" information of the vehicle, then "battery level" and "location" are two subscription fields. The system will filter and push relevant vehicle condition data based on these fields to ensure that users can receive the specific information they care about. This process makes data push more personalized and efficient because it only involves the data items that the user actually subscribes to.

[0055] It is understandable that the system uses the vehicle identification number (VIN) as a unique identifier to retrieve the user subscription information associated with the VIN from the target subscription data. This step involves looking up the subscription preferences set by the user in the Internet of Vehicles APP. These preferences define the type of vehicle condition data that the user wishes to receive, that is, the subscription field. The system checks the subscription data stored in the database or cache, identifies the records that match the specific VIN, and extracts the subscription fields set by the user, such as "battery power", "location" or "engine status". These fields indicate the specific vehicle condition information that the system needs to monitor and push. Through this process, the system can ensure that only data changes that the user cares about will be identified and prepared to be pushed, thereby providing personalized vehicle condition update services and enhancing user experience.

[0056] As an example, the step of searching for a subscription field from the target subscription data according to the vehicle identification code includes: calculating a hash value of the vehicle identification code according to a preset hash function; searching for a corresponding hash bucket from the target subscription data according to the hash value; and traversing the hash bucket and the linked list on the hash bucket to search for the subscription field.

[0057] A hash function is a predefined algorithm that converts an input (in this case, a vehicle identification number, VIN) into a fixed-length hash value. This function is designed to evenly distribute inputs of arbitrary length into a small address space. For example, a simple hash function might be to add the ASCII values ​​of each character of the VIN and then modulo some number (such as the size of the table) to get an index value. The hash value is the result of the preset hash function processing the vehicle identification number. It is a usually short fixed-length value used to quickly locate data in the hash table. The hash value, as a digital representation of the VIN, helps to quickly access and retrieve information related to a specific VIN. A hash bucket is a storage unit in a hash table that stores all elements whose hash values ​​fall on the index of the bucket. In a hash table, each hash value is mapped to a hash bucket. If different VINs have the same hash value after being processed by the hash function, they will be stored in the same hash bucket. A linked list is a basic data structure consisting of a series of nodes, each containing data and a pointer to the next node. In the context of a hash table, a linked list is used to resolve hash collisions, i.e. when multiple VIN hash values ​​are mapped to the same hash bucket, they will be stored in a linked list, with each node corresponding to the subscription data of a VIN. For example, if the preset hash function is to add the ASCII values ​​of each character of the VIN modulo 10, then the hash value of the VIN "1HGCM82633A004352" may be the result of calculating the sum of the ASCII values ​​of each character modulo 10. This value will be used to find the corresponding hash bucket in the hash table, and then look up the specific subscription field in the linked list of that bucket, such as the vehicle status information subscribed by the user.

[0058] The system first processes the vehicle identification number (VIN) using a preset hash function, which converts the VIN into a hash value, which is a number used to quickly locate data in a hash table. The system then uses this hash value to find the corresponding hash bucket in the target subscription data (the hash table that stores user subscription information). The hash bucket is a container in the hash table for storing all VIN records mapped to the index. The system then traverses this hash bucket and any linked lists (when multiple VINs are mapped to the same hash bucket, their records are stored in a linked list) to find records that match a specific VIN. This process ultimately enables the system to retrieve the subscription fields associated with the VIN, which is the type of vehicle condition data that the user specifies that they want to receive. This approach improves search efficiency because hash tables provide fast data access and can quickly locate specific subscription information even in large-scale data sets.

[0059] Step S42: when the subscription field is not empty, the data to be pushed is obtained by filtering from the target vehicle condition data according to the subscription field.

[0060] It is understandable that when the subscription fields stored in the system are not empty, it means that the user has specified the type of vehicle condition data they want to receive. In this case, the system will filter from the target vehicle condition data containing comprehensive vehicle condition information based on these subscription fields. Specifically, the system will identify each data type listed in the subscription field and then find the corresponding data item in the target vehicle condition data. For example, if the subscription fields include "battery power" and "vehicle location", the system will extract the specific values ​​of these two items from the target vehicle condition data. This screening process ensures that only the data that the user is interested in is selected to generate a data set to be pushed. Finally, these data to be pushed will be packaged and sent to the user's mobile device through a message protocol such as MQTT, so that the user can see the changes in the vehicle condition they care about in real time on the APP interface. This approach not only improves the relevance of information push, but also optimizes the efficiency of data transmission, ensuring that users can receive the vehicle information that is most important to them in a timely manner.

[0061] In this embodiment, the subscription field is searched from the target subscription data according to the vehicle identification code; when the subscription field is not empty, the data to be pushed is filtered from the target vehicle condition data according to the subscription field. First, the system uses the vehicle identification code (VIN) as a key identifier to retrieve the subscription fields associated with the VIN in the target subscription data. These fields represent the types of vehicle condition information that the user is concerned about for a specific vehicle, such as battery status, location, etc. This step can accurately identify the user's personalized data needs and provide a precise target for subsequent data push. Subsequently, when the system confirms that the subscription field is not empty, it filters out relevant data from the target vehicle condition data according to these fields to form a data set to be pushed. This ensures that only the vehicle condition data that the user really cares about is sent to their mobile devices, improves the relevance of data push, reduces unnecessary data transmission, and also improves the user experience, because users only receive information that they are interested in. In addition, this process also helps to reduce the use of network bandwidth, improve the overall efficiency and response speed of the system, and thus provide users with more timely and accurate vehicle condition update services.

[0062] For example, in order to help understand the implementation process of the vehicle condition data real-time update method obtained by combining this embodiment with the above-mentioned embodiment 1, please refer to Figure 5 , Figure 5 A brief flowchart of a method for real-time updating of vehicle condition data is provided, specifically: The figure shows a brief flow of the cloud server system processing vehicle condition data push, starting from the vehicle condition data sent by the DM service consuming big data Flink program through Kafka. The system first extracts the vehicle identification number (VIN) in the vehicle condition data, and then determines whether the VIN has subscribed to the vehicle condition data push. If subscribed, the system further checks whether the vehicle condition data contains the fields subscribed by the user. If the vehicle condition data contains the subscription field, the system pushes the corresponding vehicle condition data to the APP end according to the subscription conditions, so that users can view the latest vehicle status in real time on their mobile devices. If the vehicle condition data does not contain the subscription field, it will not be pushed. This process ensures that only the data that users are interested in is sent to their devices, improving the relevance of data push and user experience.

[0063] Please refer to Figure 6 , Figure 6 The system architecture diagram of the real-time update method of vehicle condition data provided in the second embodiment of the present application shows the real-time data interaction architecture between the big data Flink program and the vehicle TBox, Kafka message queue, connection layer framework, message decoding service, DM service and APP end in the cloud server system. The system first monitors the vehicle status in real time through the TBox, and once the vehicle condition data is detected to change, it is reported to the cloud through the Kafka message queue. The connection layer framework is responsible for receiving these reported data messages and selecting the appropriate Kafka partition to ensure the order of data consumption. The message decoding service then decodes these messages into JSON format and extracts the VIN code of the vehicle. The DM service subscribes to the vehicle condition data corresponding to these VIN codes, and pushes these data to a specific APP end through Kafka according to the user's subscription field. Users can subscribe or unsubscribe to specific vehicle condition data fields through the APP end to personalize the information they receive. The entire process ensures the real-time, sequential and personalized subscription of the data, providing users with an efficient and reliable Internet of Vehicles service experience.

[0064] Please refer to Figure 7 , Figure 7A schematic diagram of the real-time update comparison of the vehicle condition data real-time update method provided in Example 2 of the present application, which shows the real-time update and comparison of the vehicle status data in the mobile terminal interface, and shows in detail the various status data of the vehicle at different time points. The figure lists the status of vehicle functions such as remote start, locks, windows, trunk, smart air conditioning, and key information such as the temperature in the car, the position of the vehicle, and the remaining power. By comparing the data at different time points, such as the temperature changes from 23.0℃ to 25.0℃, and the power changes from unscheduled to scheduled charging status, the figure intuitively shows the real-time changes of the vehicle status. In addition, it also includes real-time updates of vehicle mileage. This real-time update mechanism ensures that users can keep abreast of the latest status of the vehicle at any time, improves the accuracy and convenience of user monitoring of the vehicle, and also shows how the system pushes real-time data so that users can obtain timely updated vehicle condition information on the APP side.

[0065] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the real-time update method of vehicle condition data of the present application. More simple transformations based on this technical concept are all within the scope of protection of the present application.

[0066] This application also provides a real-time update device for vehicle condition data, please refer to Figure 8 , the vehicle condition data real-time updating device comprises: The data acquisition module 10 is used to acquire target subscription data, target vehicle condition data and historical vehicle condition data; A data comparison module 20 is used to compare the target vehicle condition data with the historical vehicle condition data to obtain a comparison result; A data extraction module 30, configured to extract a vehicle identification code from the target vehicle condition data when the comparison result is different; A data screening module 40, configured to screen the target vehicle condition data to obtain the data to be pushed according to the vehicle identification code and the target subscription data; The data push module 50 is used to push the data to be pushed to the mobile terminal through the publish-subscribe paradigm message protocol, so that the mobile terminal updates the vehicle condition data on the mobile terminal interface according to the data to be pushed.

[0067] In one embodiment, the data screening module 40 is further used to search for a subscription field from the target subscription data according to the vehicle identification code; when the subscription field is not empty, the data to be pushed is screened from the target vehicle condition data according to the subscription field.

[0068] In one embodiment, the data screening module 40 is further used to calculate the hash value of the vehicle identification code according to a preset hash function; search for a corresponding hash bucket from the target subscription data according to the hash value; and traverse the hash bucket and the linked list on the hash bucket to search for a subscription field.

[0069] In one embodiment, the data acquisition module 10 is also used to acquire a vehicle condition data message; convert the vehicle condition data message into a byte sequence; extract each field from the byte sequence according to a preset protocol structure; construct a JSON object according to the field; convert the JSON object into a JSON string format to obtain the target vehicle condition data.

[0070] In one embodiment, the data acquisition module 10 is also used to obtain first subscription data from cached data; when the second subscription data sent by the mobile terminal is not received, the first subscription data is used as target subscription data; when the second subscription data sent by the mobile terminal is received, the second subscription data replaces the first subscription data in the cached data, and the second subscription data is used as the target subscription data.

[0071] In one embodiment, the data push module 50 is also used to establish connections with multiple mobile terminals through a publish-subscribe paradigm message protocol; when the connection is successfully established, an initial message to be sent is obtained based on the data to be pushed and the subscription field; the initial message to be sent is serialized, encrypted and compressed to obtain a target message to be sent; and the target message to be sent is sent to the mobile terminal according to a preset push strategy, so that the mobile terminal updates the vehicle condition data on the mobile terminal interface according to the target message to be sent.

[0072] In one embodiment, the data extraction module 30 is also used to parse the target vehicle condition data to obtain JSON key-value pairs when the comparison result is different; construct a vehicle status dictionary based on the JSON key-value pairs and a preset container structure; obtain the key name corresponding to the vehicle identification code; and search the vehicle identification code from the vehicle status dictionary based on the key name.

[0073] The real-time vehicle condition data updating device provided by the present application adopts the real-time vehicle condition data updating method in the above-mentioned embodiment, which can solve the technical problem of how to display the vehicle condition data in real time and accurately. Compared with the prior art, the beneficial effects of the real-time vehicle condition data updating device provided by the present application are the same as the beneficial effects of the real-time vehicle condition data updating method provided by the above-mentioned embodiment, and the other technical features in the real-time vehicle condition data updating device are the same as the features disclosed in the above-mentioned embodiment method, which will not be described in detail here.

[0074] The present application provides a real-time update device for vehicle condition data, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the real-time update method for vehicle condition data in the above-mentioned embodiment one.

[0075] Reference below Fig. 9 , which shows a schematic diagram of the structure of a real-time vehicle condition data update device suitable for implementing the embodiment of the present application. The real-time vehicle condition data update device in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Fig. 9 The vehicle condition data real-time update device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0076] like Fig. 9As shown, the vehicle condition data real-time update device may include a processing device 1001 (such as a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to the program stored in a read-only memory (ROM: Read Only Memory) 1002 or the program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the vehicle condition data real-time update device are also stored. The processing device 1001, ROM1002 and RAM1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the vehicle condition data real-time update device to communicate with other devices wirelessly or by wire to exchange data. Although the figure shows a vehicle condition data real-time update device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or provided instead.

[0077] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0078] The vehicle condition data real-time update device provided by the present application adopts the vehicle condition data real-time update method in the above embodiment, which can solve the technical problem of how to display the vehicle condition data in real time and accurately. Compared with the prior art, the beneficial effects of the vehicle condition data real-time update device provided by the present application are the same as the beneficial effects of the vehicle condition data real-time update method provided by the above embodiment, and the other technical features in the vehicle condition data real-time update device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0079] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0080] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0081] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, and the computer-readable program instructions are used to execute the vehicle condition data real-time updating method in the above-mentioned embodiment.

[0082] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM: Random Access Memory), a read-only memory (ROM: Read Only Memory), an erasable programmable read-only memory (EPROM: Erasable Programmable Read Only Memory or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM: CD-Read Only Memory), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency: Radio Frequency), etc., or any suitable combination of the above.

[0083] The computer-readable storage medium may be included in the vehicle condition data real-time updating device; or may exist independently without being assembled into the vehicle condition data real-time updating device.

[0084] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by the real-time update device for vehicle condition data, the real-time update device for vehicle condition data: obtains target subscription data, target vehicle condition data and historical vehicle condition data; compares the target vehicle condition data with the historical vehicle condition data to obtain a comparison result; when the comparison result is different, extracts a vehicle identification code from the target vehicle condition data; filters the target vehicle condition data to obtain data to be pushed based on the vehicle identification code and the target subscription data; and pushes the data to be pushed to the mobile terminal through a publish-subscribe paradigm message protocol, so that the mobile terminal updates the vehicle condition data on the mobile terminal interface according to the data to be pushed.

[0085] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0086] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0087] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0088] The readable storage medium provided by the present application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned vehicle condition data real-time update method, and can solve the technical problem of how to display vehicle condition data in real time and accurately. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by the present application are the same as the beneficial effects of the vehicle condition data real-time update method provided by the above-mentioned embodiment, and will not be elaborated here.

[0089] The present application also provides a computer program product, including a computer program, which implements the steps of the above-mentioned method for real-time updating of vehicle condition data when executed by a processor.

[0090] The computer program product provided by this application can solve the technical problem of how to display vehicle condition data in real time and accurately. Compared with the prior art, the beneficial effects of the computer program product provided by this application are the same as the beneficial effects of the vehicle condition data real-time update method provided by the above embodiment, which will not be repeated here.

[0091] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A method for real-time updating of vehicle condition data, characterized in that: The method comprises: Obtain target subscription data, target vehicle condition data, and historical vehicle condition data; Comparing the target vehicle condition data with the historical vehicle condition data to obtain a comparison result; When the comparison result is different, extracting a vehicle identification code from the target vehicle condition data; Filtering the target vehicle condition data to obtain the data to be pushed according to the vehicle identification code and the target subscription data; The data to be pushed is pushed to the mobile terminal through a publish-subscribe paradigm message protocol, so that the mobile terminal updates the vehicle condition data on the mobile terminal interface according to the data to be pushed.

2. The method according to claim 1, characterized in that The step of filtering the target vehicle condition data to obtain the data to be pushed according to the vehicle identification code and the target subscription data comprises: Searching and obtaining a subscription field from the target subscription data according to the vehicle identification code; When the subscription field is not empty, the data to be pushed is obtained by filtering the target vehicle condition data according to the subscription field.

3. The method according to claim 2, characterized in that The step of searching for a subscription field from the target subscription data according to the vehicle identification code comprises: Calculating a hash value of the vehicle identification code according to a preset hash function; According to the hash value, a corresponding hash bucket is searched from the target subscription data; The hash bucket and the linked list on the hash bucket are traversed to find and obtain the subscription field.

4. The method according to claim 1, characterized in that The step of obtaining target vehicle condition data comprises: Get vehicle condition data message; Converting the vehicle condition data message into a byte sequence; Extracting each field from the byte sequence according to a preset protocol structure; Construct a JSON object based on the fields; The JSON object is converted into a JSON string format to obtain the target vehicle condition data.

5. The method according to claim 1, characterized in that The step of obtaining target subscription data includes: Get the first subscription data from the cache data; In the case where the second subscription data sent by the mobile terminal is not received, using the first subscription data as the target subscription data; When the second subscription data sent by the mobile terminal is received, the first subscription data in the cache data is replaced by the second subscription data, and the second subscription data is used as the target subscription data.

6. The method according to claim 1, characterized in that The step of pushing the data to be pushed to the mobile terminal through the publish-subscribe paradigm message protocol so that the mobile terminal updates the vehicle condition data on the mobile terminal interface according to the data to be pushed includes: Establish connections with multiple mobile terminals through a publish-subscribe paradigm messaging protocol; When the connection is successfully established, obtaining an initial message to be sent according to the data to be pushed and the subscription field; Serializing, encrypting and compressing the initial message to be sent to obtain a target message to be sent; The target message to be sent is sent to the mobile terminal according to a preset push strategy, so that the mobile terminal updates the vehicle condition data on the mobile terminal interface according to the target message to be sent.

7. The method according to any one of claims 1 to 6, characterized in that When the comparison result is different, the step of extracting the vehicle identification code from the target vehicle condition data comprises: When the comparison result is different, the target vehicle condition data is parsed to obtain a JSON key-value pair; A vehicle status dictionary is constructed based on the JSON key-value pairs and the preset container structure; Get the key name corresponding to the vehicle identification code; The vehicle identification code is obtained by searching the vehicle status dictionary according to the key name.

8. A vehicle condition data real-time update device, characterized in that: The device comprises: A data acquisition module is used to acquire target subscription data, target vehicle condition data, and historical vehicle condition data; A data comparison module, used for comparing the target vehicle condition data with the historical vehicle condition data to obtain a comparison result; A data extraction module, used for extracting a vehicle identification code from the target vehicle condition data when the comparison result is different; A data screening module, used for screening the target vehicle condition data to obtain the data to be pushed according to the vehicle identification code and the target subscription data; The data push module is used to push the data to be pushed to the mobile terminal through the publish-subscribe paradigm message protocol, so that the mobile terminal updates the vehicle condition data on the mobile terminal interface according to the data to be pushed.

9. A vehicle condition data real-time update device, characterized in that: The device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the vehicle condition data real-time updating method according to any one of claims 1 to 7.

10. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the method for real-time updating of vehicle condition data according to any one of claims 1 to 7 are implemented.

Images