Vehicle state query method and device, vehicle, program product and storage medium

Abstract

The present disclosure provides a vehicle state query method and device, a vehicle, a program product and a storage medium, and relates to the technical field of vehicles. The method comprises: in response to a vehicle state query instruction, determining whether the vehicle state query instruction meets a first condition; wherein the first condition comprises: the vehicle is in a dormant state, the vehicle state parameter queried by the vehicle state query instruction is a dynamic parameter, and the calibration validity duration of the vehicle state parameter has expired; the dynamic parameter is a parameter whose parameter value changes in the dormant state; and in the case where the vehicle state query instruction meets the first condition, the vehicle is woken up, the parameter value of the vehicle state parameter is queried, and the parameter value is returned. The real-time performance of the vehicle state response can be significantly improved while reducing the energy consumption of the vehicle.

Description

Technical Field

[0001] This disclosure relates to the field of vehicle technology, specifically to the field of vehicle-to-everything (V2X) communication technology, and particularly to methods, devices, vehicles, software products, and storage media for querying vehicle status. Background Technology

[0002] With the rapid development of vehicle networking technology, remotely checking vehicle status (such as door lock status, window status, battery level, driving range, tire pressure, vehicle location, etc.) via mobile applications (APP) has become a standard feature of smart cars.

[0003] However, in existing solutions, the reporting strategies for vehicle status data are either too static, making it difficult to guarantee the real-time nature of vehicle status changes; or they adopt a continuous high-frequency reporting method, which, while ensuring real-time performance, brings serious problems of vehicle energy consumption and data usage. Summary of the Invention

[0004] This disclosure provides a method, apparatus, vehicle, program product, and storage medium for querying vehicle status, which can significantly improve the real-time performance of vehicle status response while reducing vehicle energy consumption.

[0005] In a first aspect, this application provides a method for querying vehicle status, applied to a Telematics Service Provider (TSP), comprising: responding to a vehicle status query instruction, determining whether the vehicle status query instruction meets a first condition; wherein the first condition includes: the vehicle is in a dormant state, the vehicle status parameter queried by the vehicle status query instruction is a dynamic parameter, and the calibration validity period of the vehicle status parameter has expired; a dynamic parameter is a parameter whose value changes in the dormant state; if the vehicle status query instruction meets the first condition, waking up the vehicle, querying the parameter value of the vehicle status parameter, and returning the parameter value.

[0006] The vehicle status query method provided in this application, upon receiving a vehicle status query command, selectively wakes up the vehicle to obtain the latest parameter value by using three judgment conditions: the vehicle is in a dormant state, the queried vehicle status parameter is a dynamic parameter, and the calibration validity period of the dynamic parameter has expired. This effectively avoids frequent wake-ups of the vehicle terminal due to invalid queries, and significantly reduces vehicle energy consumption and cloud server load while ensuring data real-time performance.

[0007] In some possible implementations, the method further includes: querying the parameter values ​​of the target vehicle state parameters in the vehicle during the process of the vehicle switching from a wake-up state to a sleep state; determining the calibration validity period of the dynamic parameters in the target vehicle state parameters; wherein the calibration validity period of different dynamic parameters is different; and saving the parameter values ​​and calibration validity periods of the dynamic parameters in the target vehicle state parameters, as well as the parameter values ​​of the static parameters in the target vehicle state parameters, to the local machine.

[0008] Based on this implementation, during the vehicle's transition from wake-up to sleep mode, timely querying of the target vehicle status parameters ensures that the TSP has the latest parameter cache baseline after the vehicle enters sleep mode, avoiding data gaps caused by state transitions. Furthermore, determining the calibration validity period for different dynamic parameters adapts to the varying characteristics of each parameter during sleep mode. This allows the parameter values ​​and calibration validity periods of the dynamic parameters in the target vehicle status parameters, as well as the parameter values ​​of the static parameters, to be saved locally. This facilitates quick assessment of the availability of locally stored parameter values ​​based on the calibration validity period when the APP queries the data, reducing unnecessary vehicle wake-ups.

[0009] In some possible implementations, determining the effective calibration duration of dynamic parameters in the target vehicle state parameters includes: determining the historical query frequency and vehicle-side change frequency of dynamic parameters in the target vehicle state parameters; and determining the effective calibration duration of dynamic parameters in the target vehicle state parameters based on the historical query frequency and vehicle-side change frequency.

[0010] Based on this implementation method, by using historical query frequency and vehicle-side change frequency, it is possible to determine the effective calibration duration that matches the current user attention and parameter change activity, thereby improving the accuracy of parameter values ​​queried by the APP in dormant state, reducing unnecessary vehicle wake-up times, and optimizing the user interaction experience.

[0011] In some possible implementations, the effective calibration duration of the dynamic parameters in the target vehicle status parameters is determined based on the historical query frequency and the vehicle-side change frequency, including: determining the larger frequency value between the historical query frequency and the vehicle-side change frequency; and finding the duration corresponding to the larger frequency value from a preset correspondence, which is used as the effective calibration duration of the dynamic parameters in the target vehicle status parameters.

[0012] Based on this implementation method, the greater of the historical query frequency and the vehicle-side change frequency can be used to more accurately determine the effective calibration duration, thereby improving the matching degree between the caching strategy and the actual needs of users and the parameter change patterns, and effectively reducing vehicle energy consumption while ensuring the real-time nature of parameter values.

[0013] In some possible implementations, the vehicle status query command is sent by the target application to the TSP when the parameter identifier bit of the vehicle status parameter is invalid; the TSP sends an invalid command to the target application to invalidate the parameter identifier bit after the target application has changed the parameter value of the vehicle status parameter since the last query.

[0014] Based on this implementation, a vehicle status query command is sent to the TSP to request the latest parameter value only when the target application determines that the parameter identifier bit of the locally cached vehicle status parameter is invalid and there is a need to display the parameter. This reduces invalid requests in network communication and avoids waste of network resources caused by blind polling.

[0015] In some possible implementations, if the target application requires displaying vehicle status parameters and the parameter identifier bit of the vehicle status parameters is valid, it displays the parameter value of the vehicle status parameters that the target application queried last time.

[0016] Based on this implementation method, when there is a need to display vehicle status parameters and the parameter identifier of the vehicle status parameters is valid, the parameter value of the vehicle status parameters last queried by the target application can be directly displayed. This can avoid unnecessary network requests, reduce communication latency, and improve the immediacy and smoothness of user interaction while ensuring the accuracy of data display.

[0017] In some possible implementations, the method further includes: querying the parameter value of the vehicle status parameter and returning the parameter value when the vehicle is in a wake-up state; when the vehicle is in a sleep state and the vehicle status parameter is a static parameter; or, when the vehicle is in a sleep state, the vehicle status parameter is a dynamic parameter and the calibration validity period has not expired, reading the parameter value of the vehicle status parameter stored locally and returning the parameter value.

[0018] Based on this implementation, when the vehicle is in a woken-up state, directly querying and returning the vehicle status parameter values ​​ensures that users obtain the most accurate and timely status information of the vehicle during active periods, fully meeting the high requirements for data freshness in highly interactive scenarios such as driving and charging. Furthermore, when the vehicle is in a dormant state and the queried parameter is a static parameter, or a dynamic parameter whose calibrated validity period has not yet expired, there is no need to wake the vehicle; the locally stored cached value is directly read and returned. This effectively avoids increased static power consumption caused by frequent wake-ups of the vehicle terminal, reduces vehicle energy consumption and network resource consumption, extends the vehicle's static range, and still ensures the availability and accuracy of the data obtained by the user within its validity period.

[0019] Secondly, this application provides a vehicle status query device applied to a remote information service provider (TSP), comprising: a determination module and a wake-up module; the determination module is used to respond to a vehicle status query command and determine whether the vehicle status query command meets a first condition; wherein, the first condition includes: the vehicle is in a dormant state, the vehicle status parameter queried by the vehicle status query command is a dynamic parameter, and the calibration validity period of the vehicle status parameter has expired; the dynamic parameter is a parameter whose value changes in the dormant state; the wake-up module is used to wake up the vehicle, query the parameter value of the vehicle status parameter, and return the parameter value when the vehicle status query command meets the first condition.

[0020] In some possible implementations, the determining module is also used to query the parameter values ​​of the target vehicle state parameters in the vehicle during the process of the vehicle switching from a wake-up state to a sleep state; determine the calibration validity period of the dynamic parameters in the target vehicle state parameters; wherein the calibration validity period of different dynamic parameters is different; and save the parameter values ​​and calibration validity periods of the dynamic parameters in the target vehicle state parameters, as well as the parameter values ​​of the static parameters in the target vehicle state parameters, to the local machine.

[0021] In some possible implementations, the determining module is specifically used to determine the historical query frequency and vehicle-side change frequency of the dynamic parameters in the target vehicle state parameters; based on the historical query frequency and vehicle-side change frequency, it determines the effective calibration duration of the dynamic parameters in the target vehicle state parameters.

[0022] In some possible implementations, the determining module is specifically used to determine the larger frequency value between the historical query frequency and the vehicle-side change frequency; and to find the duration corresponding to the larger frequency value from the preset correspondence, which is used as the calibration effective duration of the dynamic parameters in the target vehicle state parameters.

[0023] In some possible implementations, the vehicle status query command is sent by the target application to the TSP when the parameter identifier bit of the vehicle status parameter is invalid; the TSP sends an invalid command to the target application to invalidate the parameter identifier bit after the target application has changed the parameter value of the vehicle status parameter since the last query.

[0024] In some possible implementations, if the target application requires displaying vehicle status parameters and the parameter identifier bit of the vehicle status parameters is valid, it displays the parameter value of the vehicle status parameters that the target application queried last time.

[0025] In some possible implementations, the determining module is also used to query the parameter values ​​of the vehicle status parameters and return the parameter values ​​when the vehicle is in a wake-up state; when the vehicle is in a sleep state and the vehicle status parameters are static parameters; or, when the vehicle is in a sleep state, the vehicle status parameters are dynamic parameters and the calibration validity period has not expired, to read the parameter values ​​of the vehicle status parameters stored locally and return the parameter values.

[0026] Thirdly, this application provides a control device, including: a memory and a processor; the memory and the processor are coupled; the memory is used to store a computer program; when the processor executes the computer program, it implements the vehicle status query method of any of the above embodiments.

[0027] Fourthly, this application provides a computer-readable storage medium storing computer program instructions that, when executed by a processor, implement the vehicle status query method of any of the above embodiments.

[0028] Fifthly, this application provides a computer program product including computer program instructions that, when executed by a processor, implement the vehicle status query method of any of the above embodiments.

[0029] Sixthly, this application provides a vehicle including the control device of any of the preceding embodiments; or the computer-readable storage medium of any of the preceding embodiments; or the computer program product of any of the preceding embodiments. Attached Figure Description

[0030] To more clearly illustrate the technical solutions in this disclosure, the accompanying drawings used in some embodiments of this disclosure will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings.

[0031] Figure 1 A schematic diagram of the architecture of a vehicle status query system provided in an embodiment of this disclosure; Figure 2 A flowchart of a vehicle status query method provided in this embodiment of the disclosure Figure 1 ; Figure 3 A flowchart of a vehicle status query method provided in this embodiment of the disclosure Figure 2 ; Figure 4 The flowchart of a vehicle status query method provided in this embodiment of the disclosure Figure 3 ; Figure 5The flowchart of a vehicle status query method provided in this embodiment of the disclosure Figure 4 ; Figure 6 The flowchart of a vehicle status query method provided in this embodiment of the disclosure Figure 5 ; Figure 7 The flowchart of a vehicle status query method provided in this embodiment of the disclosure Figure 6 ; Figure 8 A schematic diagram of the structure of a vehicle status query device provided in an embodiment of this disclosure; Figure 9 This is a schematic diagram of the structure of a control device provided in some embodiments of this disclosure. Detailed Implementation

[0032] The technical solutions of this disclosure will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0033] It should be noted that, in this disclosure, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in this disclosure should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0034] Hereinafter, 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 one or more of that feature.

[0035] In the description of this disclosure, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Furthermore, "at least one" means one or more, and "more than one" means two or more.

[0036] As mentioned in the background section, existing solutions are mainly divided into two categories: one is that the APP polls the vehicle status from the TSP platform at fixed time intervals, and the TSP platform then obtains the latest data from the vehicle terminal in real time; the other is to assign a fixed validity period (Time To Live, TTL) to different status data, during which the APP directly uses the local cache, and only requests it again after it expires.

[0037] However, while the former ensures real-time data delivery, it has significant drawbacks: the vehicle terminal needs to be frequently woken up, leading to a significant increase in static power consumption; at the same time, continuous polling requests consume enormous server and network resources, making it particularly difficult to support a scale of millions of vehicles. The latter, while reducing resource consumption, lacks dynamic adaptability due to its fixed TTL mechanism. When the vehicle terminal is in a woken-up state (such as when the vehicle is in motion, charging, or when the user is frequently operating it), data updates are not timely, severely impacting user experience. Furthermore, it cannot differentiate the varying timeliness requirements of the same state data based on different scenarios.

[0038] To address the aforementioned technical issues, this disclosure provides a method for querying vehicle status. The idea is to wake up the vehicle and query the parameter values ​​of the vehicle status parameters only when the vehicle is in a dormant state, the vehicle status parameters are dynamic parameters, and the calibration validity period of the vehicle status parameters has expired, thereby effectively reducing vehicle energy consumption and improving the real-time performance of the vehicle status parameters.

[0039] The vehicle status query system provided in the embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0040] See Figure 1 This is a schematic diagram of the architecture of a vehicle status query system provided in an embodiment of this disclosure. Figure 1 As shown, the vehicle status query system 100 includes: an in-vehicle terminal 110, a remote information service provider 120, and an application 130.

[0041] Among them, the vehicle terminal 110 and the application 130 are respectively connected to the remote information service provider 120.

[0042] For example, the vehicle terminal 110 is installed on the vehicle to collect vehicle status parameters and send the vehicle status parameters to the remote information service provider 120.

[0043] The vehicle terminal 110 remains silent when the vehicle is in a dormant state, without collecting or communicating any vehicle status parameters; when the vehicle is awake, the vehicle terminal 110 enters a normal working mode and performs the collection, processing and reporting of vehicle status parameters.

[0044] For example, the vehicle terminal 110 may be a vehicle-mounted telematics box (T-Box) installed in the vehicle, serving as a communication hub between the vehicle and the telematics service provider 120.

[0045] For example, in response to a vehicle status query command, the remote information service provider 120 determines whether the vehicle status query command meets a first condition; if the vehicle status query command meets the first condition, it wakes up the vehicle, queries the parameter values ​​of the vehicle status parameters, and returns the parameter values ​​to the application 130.

[0046] The first condition includes: the vehicle is in a dormant state, the vehicle status parameter queried by the vehicle status query command is a dynamic parameter, and the calibration validity period of the vehicle status parameter has expired; dynamic parameters are parameters whose values ​​change in the dormant state.

[0047] For example, the telematics service provider 120 can store vehicle status parameters and maintain the working status of the vehicle terminal 110.

[0048] For example, the application 130 is used to receive the user's open or pull-to-refresh operation, initiate a vehicle status query command to the remote information service provider 120, and receive the parameter values ​​of the vehicle status parameters returned by the remote information service provider 120.

[0049] The application 130 is installed on the terminal device and can display the parameter values ​​of the vehicle status parameters to the user.

[0050] For example, terminal devices can be mobile phones, tablets, wearable devices, in-vehicle devices, augmented reality (AR) / virtual reality (VR) devices, laptops, ultra-mobile personal computers (UMPCs), netbooks, personal digital assistants (PDAs), etc. It is understood that the application scenarios of the embodiments of this disclosure are not limited. The system architecture and business scenarios described in the embodiments of this disclosure are for the purpose of more clearly illustrating the technical solutions of the embodiments of this disclosure, and do not constitute a limitation on the technical solutions provided by the embodiments of this disclosure. As those skilled in the art will know, with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided by the embodiments of this disclosure are also applicable to similar technical problems.

[0051] The method for querying vehicle status provided in this embodiment will be described in detail below.

[0052] This disclosure provides a method for querying vehicle status, applied to a remote information service provider (TSP) in a vehicle status query system, such as... Figure 2 As shown, the method includes the following steps: S201. In response to the vehicle status query command, determine whether the vehicle status query command meets the first condition.

[0053] Among them, the vehicle status query command is used to represent the user's intention to actively initiate a request to obtain vehicle status data through the target application.

[0054] As a feasible implementation method, the vehicle status query command is sent to the TSP by the target application upon receiving an open or refresh operation from the user.

[0055] In an exemplary embodiment, when a user opens the vehicle status page of the target application or refreshes the page by pulling down, the application sends a vehicle status query command to the TSP.

[0056] It should be understood that opening or pull-to-refresh are only two exemplary triggering methods, and the specific settings can be made according to the interface interaction design of different applications. This application embodiment does not limit this.

[0057] As another feasible implementation, the vehicle status query command is sent by the target application to the TSP when the parameter identifier bit of the vehicle status parameter is invalid.

[0058] In an exemplary embodiment, if the TSP changes the value of the vehicle status parameter after the target application previously queried the parameter value, the TSP sends an invalid instruction to the target application to invalidate the parameter identifier bit.

[0059] In an exemplary embodiment, if the TSP sends an invalid instruction to the target application, the parameter value of the vehicle status parameter cached in the target application is in an expired state, and an incremental query request needs to be initiated to the TSP, that is, a vehicle status query instruction is sent to the TSP.

[0060] It should be understood that when the vehicle status data on the TSP side is updated, the TSP notifies the target application that its local cached data has expired by sending an invalid command. In response to the invalid command, the target application initiates an incremental query to obtain the latest parameter values ​​after the change, thereby ensuring that the vehicle status displayed on the APP is consistent with the actual vehicle status.

[0061] For example, the first condition includes: the vehicle is in a dormant state, the vehicle status parameter queried by the vehicle status query command is a dynamic parameter, and the calibration validity period of the vehicle status parameter has expired.

[0062] The vehicle is in sleep mode to indicate that the on-board terminal is entering a low-power operating mode, suspending the collection and reporting of vehicle status parameters.

[0063] For example, if the vehicle meets the second condition, it can be determined that the vehicle is in a dormant state.

[0064] The second condition includes: no data reported by the vehicle terminal is received within the first preset time period, the vehicle is in a turned-off state, and the vehicle is in a non-charging state.

[0065] Optionally, if it cannot be confirmed whether the vehicle meets the second condition, a conservative strategy is adopted, and the vehicle status is defaulted to hibernation to avoid the vehicle being frequently woken up due to uncertainty of the status.

[0066] Vehicle status parameters include static parameters and dynamic parameters.

[0067] Static parameters are those whose values ​​remain unchanged for a long time after the vehicle is parked.

[0068] For example, static parameters include, but are not limited to: door locks, windows, sunroof, and electronic tailgate.

[0069] Dynamic parameters are parameters whose values ​​change during sleep mode.

[0070] For example, dynamic parameters include, but are not limited to: remaining battery power, available battery, driving range, tire pressure, and vehicle location.

[0071] The calibration validity period is used to characterize the effective duration of vehicle status parameters. When the vehicle status parameters are within the calibration validity period, the TSP can directly return the stored parameter values ​​to the APP without requesting the latest data from the vehicle terminal. After the calibration validity period is exceeded, the parameter values ​​of the vehicle status parameters become invalid and need to be retrieved again.

[0072] The effective calibration duration can be determined based on the variation characteristics of various dynamic parameters of the vehicle during the dormant period. Each dynamic parameter has a separate, dynamically configured effective calibration duration.

[0073] For example, static parameters can be assigned a long-term calibration validity period, based on the fact that such state parameters (such as door locks, windows, sunroofs, etc.) rarely change after the vehicle is parked. The purpose is to maximize the cache hit rate and reduce unnecessary vehicle wake-ups.

[0074] Dynamic parameters are assigned short-term calibration validity periods. This is based on the fact that such status parameters (such as battery level, tire pressure, etc.) change continuously during the dormant period, requiring a relatively high refresh rate. The purpose is to balance the conflict between data freshness and the number of times the vehicle is woken up.

[0075] Optionally, the effective calibration duration can be dynamically adjusted based on real-time changes in the vehicle's status.

[0076] For example, when a vehicle is detected to be charging, the effective calibration time corresponding to the battery level and driving range can be further shortened because the battery level changes more frequently during the charging process and users tend to pay more attention to the charging progress, in order to improve the real-time performance of data updates.

[0077] The calibration validity period of the vehicle status parameters has expired. This means that the time since the last update of the vehicle status parameters that the user needs to query is longer than the calibration validity period. The parameter values ​​of the vehicle status parameters currently cached by the TSP may have some deviation from the actual values ​​and need to be retrieved again.

[0078] It should be understood that when a vehicle is in sleep mode, it is impossible to obtain the latest vehicle status data in real time. To avoid unnecessary wake-ups, it can be first determined whether the cached value of the vehicle status parameter queried by the user is a dynamic parameter. If so, it can be further determined whether it is within the calibrated valid time period. If it is within the valid time period, the cached value is returned directly, reducing energy consumption while ensuring the real-time performance of data response.

[0079] S202. If the vehicle status query command meets the first condition, wake up the vehicle, query the parameter values ​​of the vehicle status parameters, and return the parameter values.

[0080] It should be understood that if the vehicle status query command meets the first condition, it indicates that the vehicle is in sleep mode and the calibration validity period of the queried dynamic parameter has expired. It is necessary to wake up the vehicle terminal to obtain the latest parameter value of the dynamic parameter, so as to ensure the accuracy and real-time nature of the data returned to the APP.

[0081] As a feasible implementation method, waking up the vehicle refers to switching the vehicle from a dormant state to a wake-up state, restoring the vehicle terminal's communication capabilities, and automatically switching to real-time mode for subsequent APP requests.

[0082] The real-time mode includes: in response to a vehicle status query command, the TSP determines that the vehicle is in a wake-up state, directly sends a query command to the vehicle terminal, obtains the latest parameter values ​​of the vehicle status parameters, and returns the latest parameter values ​​of the vehicle status parameters to the APP.

[0083] The vehicle status query method provided in this application, upon receiving a vehicle status query command, selectively wakes up the vehicle to obtain the latest parameter value by using three judgment conditions: the vehicle is in a dormant state, the queried vehicle status parameter is a dynamic parameter, and the calibration validity period of the dynamic parameter has expired. This effectively avoids frequent wake-ups of the vehicle terminal due to invalid queries, and significantly reduces vehicle energy consumption and cloud server load while ensuring data real-time performance.

[0084] Optionally, when the user clicks the manual refresh control, the manual refresh control is triggered. This control does not require conditional judgment. The target application directly sends a vehicle status query command to the TSP, and the TSP directly wakes up the vehicle to obtain the latest parameter values ​​of the vehicle status parameters.

[0085] In some embodiments, if the target application requires displaying vehicle status parameters and the parameter identifier bit of the vehicle status parameters is valid, it displays the parameter value of the vehicle status parameters that the target application queried last time.

[0086] It should be understood that when a user needs to check the vehicle status, if the parameter value cached locally by the application is still marked as valid, there is no need to send a query request to the TSP. The cached value can be used directly for display, thereby reducing unnecessary network communication and vehicle wake-up.

[0087] As a feasible implementation method, the process of determining the need to display vehicle status parameters includes: detecting that the user has opened the vehicle status query page, performing a pull-to-refresh operation, or the application triggering an automatic refresh due to the page switching to the foreground.

[0088] The process of determining that the parameter identifier of the vehicle status parameter is valid includes: the TSP has not sent an invalid instruction for the parameter to the target application, and the parameter has not been marked as changed since the last query.

[0089] In the exemplary embodiment, each vehicle status parameter has a corresponding independent parameter identifier bit in the target application. When the identifier bit is valid, it means that the locally cached parameter value is available and can be displayed directly; when the bit is invalid, it means that the cached value has expired and a new query needs to be sent to the TSP.

[0090] Optionally, the target application may also display the "last update time" to inform users of the timeliness of the currently displayed data; it also provides a manual refresh button so users can access the latest data whenever they need to view it in real time. Furthermore, when the vehicle is in a wake-up state, the application may display a "real-time mode" status indicator to enhance user awareness of the data update pattern and improve the user experience.

[0091] In some embodiments, such as Figure 3 As shown, the methods for querying vehicle status also include: S301. When the vehicle is in a wake-up state, query the parameter values ​​of the vehicle status parameters and return the parameter values.

[0092] Among them, the wake-up state refers to the vehicle terminal being in normal working mode. In this mode, the vehicle terminal can collect the current values ​​of various status parameters of the vehicle in real time, and can return the latest data immediately according to the query request of the TSP platform, or actively report business data to the TSP.

[0093] For example, the vehicle is determined to be in a wake-up state when the vehicle meets a third condition.

[0094] The third condition includes at least one of the following: receiving a heartbeat report from the vehicle terminal within the most recent second preset time period; receiving a business data report from the vehicle terminal within the most recent third preset time period; the vehicle is in ignition state; the vehicle is in charging state; and the communication connection between the TSP platform and the vehicle terminal remains active.

[0095] In the exemplary embodiment, the TSP receives a vehicle status query command sent by the APP; detects that the vehicle terminal of the corresponding vehicle is in a wake-up state; directly sends a query command to the vehicle terminal to obtain the parameter value of the vehicle status parameter; and returns the parameter value of the vehicle status parameter to the APP with a very short validity period so that the APP can display the parameter value of the vehicle status parameter and update the local cache.

[0096] S302. When the vehicle is in a dormant state and the vehicle status parameters are static parameters, read the parameter values ​​of the vehicle status parameters stored locally and return the parameter values.

[0097] It should be understood that when a vehicle is in a dormant state and its status parameters are static, it means that the values ​​of such static parameters (such as door lock status, window status, sunroof status, etc.) remain stable for a relatively long period of time after the vehicle is parked and enters a dormant state. They will not change due to the dormant state. The parameter values ​​stored locally by the TSP are still valid data at the current moment. Therefore, the parameter values ​​of the vehicle status parameters stored locally can be read directly and the parameter values ​​can be returned without initiating a query request to the vehicle terminal to wake up the vehicle.

[0098] S303. When the vehicle is in a dormant state, the vehicle status parameters are dynamic parameters, and the calibration validity period has not expired, read the parameter values ​​of the vehicle status parameters stored locally and return the parameter values.

[0099] For example, when the vehicle is in a dormant state, the Time To Live (TTL) mode is used to query the parameter values ​​of the vehicle status parameters.

[0100] The TTL mode includes: the TSP receives the vehicle status query command sent by the APP; detects that the corresponding vehicle's on-board terminal is in a sleep state; checks the parameter values ​​of the vehicle status parameters stored locally; if the calibration validity period of the vehicle status parameter value has not expired, it directly returns the parameter value of the vehicle status parameter along with the new remaining validity period; if the calibration validity period of the vehicle status parameter value has expired, it wakes up the on-board terminal to query the latest parameter value and returns it.

[0101] It should be noted that steps S301, S302, and S303 can be executed in parallel with step S202.

[0102] It should be understood that when the vehicle is in a dormant state, the vehicle status parameters are dynamic parameters, and the calibration validity period has not expired, although the vehicle status parameters may change during the dormant period, their parameter values ​​are still within the pre-configured calibration validity period. The TSP can recognize this value as reliable data, and can directly read the parameter values ​​of the vehicle status parameters stored locally without initiating a real-time query to the vehicle terminal, and return the parameter values.

[0103] In some embodiments, such as Figure 4 As shown, the methods for querying vehicle status also include: S401. During the process of switching the vehicle from wake-up state to sleep state, query the parameter value of the target vehicle status parameter in the vehicle.

[0104] During the process of the vehicle switching from the wake-up state to the sleep state, the vehicle terminal is about to enter the low power mode. At this time, the vehicle status parameters are queried and recorded as the last valid values ​​before sleep, which provides the basis for the cached parameter values ​​in the subsequent sleep state. The timestamp of the last active time is recorded as the marker of the start time of sleep.

[0105] In the exemplary embodiment, when the vehicle is detected to meet the hibernation conditions (such as the engine being off and there is no communication activity), the TSP actively initiates a final status query to the vehicle terminal to obtain the current parameter values ​​of each vehicle status parameter and store them in the TSP cache, while marking this moment as the last update time of the batch of data.

[0106] It should be understood that by performing a final data query during the hibernation transition phase, the TSP side can ensure that it has the latest parameter cache after the vehicle enters hibernation. This allows the TSP to directly return the cached value when responding to APP queries during hibernation, thereby minimizing the number of times the vehicle is woken up during hibernation.

[0107] S402. Determine the effective calibration duration of the dynamic parameters in the target vehicle's state parameters.

[0108] The effective calibration duration varies for different dynamic parameters.

[0109] For example, the effective calibration duration is determined based on the frequency and magnitude of changes in dynamic parameters during vehicle hibernation.

[0110] Specifically, the higher the frequency and the greater the amplitude of change of a dynamic parameter, the shorter its effective calibration time; conversely, the lower the frequency and the smaller the amplitude of change of a dynamic parameter, the longer its effective calibration time.

[0111] For example, the remaining battery power changes slowly during vehicle sleep due to battery self-discharge and standby power consumption, so a moderate calibration validity period (e.g., 15 minutes) can be set; tire pressure changes relatively slowly due to temperature, so a longer calibration validity period (e.g., 30 minutes) can be set; and the vehicle position usually remains unchanged during vehicle sleep, so a longer calibration validity period (e.g., 1 hour) can be set.

[0112] It should be understood that by configuring and calibrating the effective duration for different dynamic parameters, the cache hit rate can be maximized while ensuring data freshness, reducing unnecessary vehicle wake-ups, and achieving a balance between data real-time performance and vehicle energy consumption.

[0113] S403. Save the parameter values ​​and calibration validity period of the dynamic parameters in the target vehicle state parameters, as well as the parameter values ​​of the static parameters in the target vehicle state parameters, to the local machine.

[0114] In the exemplary embodiment, after obtaining the vehicle status parameters, the TSP stores the current value of the dynamic parameters and their corresponding calibration validity period, as well as the current value of the static parameters, in the TSP local cache, and records the storage timestamp for each dynamic parameter separately, so as to determine whether the parameter is still within the calibration validity period.

[0115] It should be understood that by storing parameter values ​​and their validity duration information in the TSP's local cache, when the APP initiates a query, the TSP can quickly determine whether the cached data is valid based on the stored timestamp and the calibrated validity duration, and thus decide whether to directly return the cached value or wake up the vehicle to obtain the latest value.

[0116] As a feasible implementation method, such as Figure 5 As shown, step S402 above can be specifically implemented as follows: S501. Determine the historical query frequency and vehicle-side change frequency of the dynamic parameters in the target vehicle status parameters.

[0117] Among them, the historical query frequency is used to characterize how frequently a user or target application queries the dynamic parameter within a preset historical time period, reflecting the user's attention to the real-time nature of the parameter.

[0118] For example, the historical query frequency can be determined based on the ratio of the total number of times the dynamic parameter was requested by the target application within the most recent fourth preset time period to the total duration of the fourth preset time period.

[0119] The vehicle-side change frequency is used to characterize how frequently the dynamic parameter actually changes at the vehicle end, reflecting the dynamic characteristics of the parameter in a dormant state.

[0120] The frequency of change at the vehicle end can be determined based on the ratio of the number of times the dynamic parameter changes on the vehicle terminal side within the most recent fifth preset time period to the total duration of the fifth preset time period.

[0121] S502. Based on historical query frequency and vehicle-side change frequency, determine the effective calibration duration of dynamic parameters in the target vehicle status parameters.

[0122] In an exemplary embodiment, the specific value of the calibration validity period is determined based on the historical query frequency and the vehicle-side change frequency. The higher the historical query frequency, the higher the user's attention to the real-time nature of the parameter, and the shorter the calibration validity period is accordingly. The higher the vehicle-side change frequency, the more active the parameter is during the dormant period, and the shorter the calibration validity period is accordingly.

[0123] It should be understood that the essence of calibrating the effective duration is to seek a balance between "data freshness" and "vehicle wake-up frequency". The frequency of historical queries reflects the user's demand for the real-time nature of parameters, while the frequency of changes on the vehicle side reflects the dynamic characteristics of the parameters themselves. By dynamically determining the calibrated effective duration by combining these two dimensions, it can accurately match the user's actual viewing habits and adapt to the inherent change patterns of the parameters, thereby minimizing unnecessary vehicle wake-ups while ensuring a good user experience.

[0124] As a feasible implementation method, such as Figure 6 As shown, step S502 above can be specifically implemented as follows: S601. Determine the larger frequency value between the historical query frequency and the vehicle-side change frequency.

[0125] It should be noted that the historical query frequency and vehicle-side change frequency are constantly adjusted with time and user behavior. An update cycle can be set, such as recalculating every 24 hours or every week, to ensure that the frequency data used can reflect the user's recent query habits and the recent trend of parameter changes, so that the configuration of the effective calibration period is adaptive.

[0126] S602. Find the duration corresponding to the larger frequency value from the preset correspondence and use it as the effective calibration duration of the dynamic parameters in the target vehicle state parameters.

[0127] The preset correspondence is a mapping table between larger frequency values ​​and calibrated valid duration, which is used to quickly query and determine the corresponding valid duration value based on the larger frequency value.

[0128] The preset correspondence can be set based on the system's preset configuration strategy, which can be comprehensively formulated according to the vehicle model, parameter type, typical usage habits of user groups, and system performance goals (such as maximum allowable cache latency, target energy saving ratio, etc.).

[0129] Specifically, the frequency value is divided into several frequency intervals according to a number of preset frequency thresholds, and each frequency interval corresponds to a preset calibration validity period; different parameter types can be configured with their own mapping tables to adapt to the differences in the variation characteristics and user attention of different parameters.

[0130] To facilitate understanding, the following example illustrates how to query vehicle status.

[0131] For example, such as Figure 7 As shown, the method for querying vehicle status can be implemented through the following steps: S701, The target application receives a request to display vehicle status parameters.

[0132] S702. The target application determines whether the parameter identifier bit of the vehicle status parameter is valid. If yes, proceed to step S703; otherwise, proceed to step S704.

[0133] S703: Display the parameter values ​​of the vehicle status parameters that were last queried by the target application.

[0134] S704, The target application sends a vehicle status query command to the remote information service provider.

[0135] S705. The telematics service provider determines whether the vehicle is in a dormant state. If not, proceed to step S706; if yes, proceed to step S707.

[0136] S706. The remote information service provider queries the parameter values ​​of the vehicle status parameters and returns the parameter values.

[0137] S707. The telematics service provider determines whether the vehicle status parameters are dynamic parameters. If not, proceed to step S708; if yes, proceed to step S709.

[0138] S708, the remote information service provider reads the parameter values ​​of the vehicle status parameters stored locally and returns the parameter values.

[0139] S709. The remote information service provider determines whether the calibration validity period of the dynamic parameters has expired. If not, proceed to step S708; if yes, proceed to step S710.

[0140] S710 wakes up the vehicle terminal, queries the parameter values ​​of the vehicle status parameters, and returns the parameter values ​​to the target application.

[0141] It should be understood that, compared to the fixed strategies in traditional solutions, this application is the first to achieve dynamic switching of data acquisition strategies based on the real-time status of the vehicle terminal. Specifically, this solution can adaptively adjust the data acquisition method according to different vehicle states such as sleep or wake-up. In the wake-up state, it provides users with real-time data to meet the needs of high-frequency interaction scenarios such as driving and charging. In the sleep state, a caching strategy minimizes the need to wake up the vehicle terminal. Actual testing shows that the number of vehicle terminal wake-ups can be reduced by more than 70%, and server load can be reduced by more than 60%. Furthermore, through the categorized management of vehicle status parameters and the dynamic adjustment of the effective duration of scenario-based calibration, this solution achieves an optimal balance between data freshness and system resource consumption. At the same time, the state switching mechanism is completely transparent to the user, and data consistency is effectively guaranteed. The APP relies on local caching logic to reduce network waiting time, significantly improving the user experience. Both the state classification and validity period strategies in this solution support flexible configuration, can quickly adapt to new state types, have good scalability, and can adapt to future business development needs.

[0142] The foregoing primarily describes the solutions of the embodiments of this disclosure from a methodological perspective. It is understood that, in order to achieve the aforementioned functions, the vehicle status query device includes at least one of the hardware structures and software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, in conjunction with the units and algorithm steps of the various examples described in the embodiments disclosed herein, the embodiments of this disclosure can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this disclosure.

[0143] This disclosure embodiment can divide the vehicle status query device into functional modules according to the above method embodiment. For example, each function can be divided into a separate functional module, or two or more functions can be integrated into one functional module. The integrated module can be implemented in hardware or software. It should be noted that the module division in this disclosure embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods. The following description uses the example of dividing each function into a separate functional module.

[0144] Figure 8 This is a schematic diagram of a vehicle status query device provided in an embodiment of this disclosure. This vehicle status query device is applied to a TSP (Traffic Service Provider) and can execute the vehicle status query method provided in the above-described method embodiment. Figure 8 As shown, the vehicle status query device 800 includes: a determination module 801 and a wake-up module 802; the determination module 801 is used to determine whether the vehicle status query command meets a first condition in response to the vehicle status query command; wherein, the first condition includes: the vehicle is in a dormant state, the vehicle status parameter queried by the vehicle status query command is a dynamic parameter, and the calibration validity period of the vehicle status parameter has expired; the dynamic parameter is a parameter whose value changes in the dormant state; the wake-up module 802 is used to wake up the vehicle, query the parameter value of the vehicle status parameter, and return the parameter value when the vehicle status query command meets the first condition.

[0145] In some possible implementations, the determining module 801 is further configured to query the parameter values ​​of the target vehicle state parameters in the vehicle during the process of the vehicle switching from a wake-up state to a sleep state; determine the calibration validity duration of the dynamic parameters in the target vehicle state parameters; wherein the calibration validity duration of different dynamic parameters is different; and save the parameter values ​​and calibration validity duration of the dynamic parameters in the target vehicle state parameters, as well as the parameter values ​​of the static parameters in the target vehicle state parameters, to the local storage.

[0146] In some possible implementations, the determining module 801 is specifically used to determine the historical query frequency and vehicle-side change frequency of the dynamic parameters in the target vehicle state parameters; based on the historical query frequency and vehicle-side change frequency, to determine the effective calibration duration of the dynamic parameters in the target vehicle state parameters.

[0147] In some possible implementations, the determining module 801 is specifically used to determine the larger frequency value between the historical query frequency and the vehicle-side change frequency; and to find the duration corresponding to the larger frequency value from the preset correspondence, which is used as the calibration effective duration of the dynamic parameters in the target vehicle state parameters.

[0148] In some possible implementations, the vehicle status query command is sent by the target application to the TSP when the parameter identifier bit of the vehicle status parameter is invalid; the TSP sends an invalid command to the target application to invalidate the parameter identifier bit after the target application has changed the parameter value of the vehicle status parameter since the last query.

[0149] In some possible implementations, if the target application requires displaying vehicle status parameters and the parameter identifier bit of the vehicle status parameters is valid, it displays the parameter value of the vehicle status parameters that the target application queried last time.

[0150] In some possible implementations, the determining module 801 is further configured to query the parameter values ​​of the vehicle status parameters and return the parameter values ​​when the vehicle is in a wake-up state; when the vehicle is in a sleep state and the vehicle status parameters are static parameters; or, when the vehicle is in a sleep state, the vehicle status parameters are dynamic parameters and the calibration validity period has not expired, read the parameter values ​​of the vehicle status parameters stored locally and return the parameter values.

[0151] When implementing the functions of the integrated modules described above in hardware, this disclosure provides a possible structure for the control device involved in the above embodiments. For example... Figure 9 As shown, the control device 900 includes a processor 902 and a bus 904. Optionally, the control device 900 may also include a memory 901; optionally, the control device 900 may also include a communication interface 903.

[0152] Processor 902 may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with embodiments of this disclosure. Processor 902 may be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with embodiments of this disclosure. Processor 902 may also be a combination that implements computing functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0153] The communication interface 903 is used to connect to other devices via a communication network. This communication network can be Ethernet, wireless access network, wireless local area network (WLAN), etc.

[0154] The memory 901 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto.

[0155] In one possible implementation, the memory 901 can exist independently of the processor 902. The memory 901 can be connected to the processor 902 via a bus 904 and is used to store instructions or program code. When the processor 902 calls and executes the instructions or program code stored in the memory 901, it can implement the vehicle status query method provided in this embodiment. In another possible implementation, the memory 901 can also be integrated with the processor 902.

[0156] The 904 bus can be an extended industry standard architecture (EISA) bus, etc. The 904 bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 9 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.

[0157] Some embodiments of this disclosure provide a computer-readable storage medium (e.g., a non-transitory computer-readable storage medium) storing computer program instructions that, when executed on a processor, cause the processor to perform a vehicle status query method as described in any of the above embodiments.

[0158] Exemplary examples of computer-readable storage media may include, but are not limited to: magnetic storage devices (e.g., hard disks, floppy disks, or magnetic tapes), optical discs (e.g., compact disks (CDs), digital versatile disks (DVDs), etc.), smart cards, and flash memory devices (e.g., erasable programmable read-only memory (EPROMs), cards, sticks, or key drives, etc.). The various computer-readable storage media described in this disclosure may represent one or more devices and / or other machine-readable storage media for storing information. The term "machine-readable storage medium" may include, but is not limited to, wireless channels and various other media capable of storing, containing, and / or carrying instructions and / or data.

[0159] This disclosure provides a computer program product containing instructions that, when run on a processor, cause the processor to execute the vehicle status query method of any of the above embodiments.

[0160] This disclosure provides a vehicle including the control device of any of the preceding embodiments; or the computer-readable storage medium of any of the preceding embodiments; or the computer program product of any of the preceding embodiments.

[0161] The vehicle provided in this application may be a passenger vehicle or a freight vehicle, and may also be an electric vehicle or a hybrid vehicle. This application does not limit the specific purpose or power type of the vehicle, and the choice can be made according to actual needs.

[0162] A vehicle consists of a body and wheels. The body is used for passengers and for carrying goods, while the wheels are mounted underneath the body to support it and allow it to roll on the road, thus enabling the vehicle to move.

[0163] In some possible examples, the vehicle is equipped with a control system, which typically adopts a layered distributed architecture. From the bottom layer to the top layer, it can be roughly divided into a perception layer, a control layer, a coordination layer, and an interaction layer. The layers communicate with each other through an in-vehicle network.

[0164] The perception layer mainly consists of various sensors distributed inside and outside the vehicle body, including but not limited to external environment cameras, millimeter-wave radar, lidar, ultrasonic sensors, in-vehicle driver monitoring cameras, microphone arrays, and various vehicle status sensors (such as wheel speed sensors, inertial measurement units, temperature sensors, etc.). The perception layer is responsible for collecting the parameter values ​​of vehicle status parameters in real time.

[0165] The control layer consists of dozens to hundreds of electronic control units (ECUs), distributed across multiple functional domains including powertrain, chassis, body, intelligent driving, and infotainment. Each ECU embeds real-time control software that performs closed-loop control of the vehicle's actuators based on preset control strategies or upper-level commands, and generates corresponding alarm signals when abnormal conditions are detected. Typical ECUs include the engine control unit, transmission control unit, brake control unit, steering control unit, vehicle stability control unit, airbag control unit, intelligent driving domain controller, and in-vehicle infotainment unit.

[0166] The coordination layer typically exists in the form of a domain controller or a central computing platform, responsible for cross-domain data fusion, global state management, and collaborative decision-making. The coordination layer centrally processes and schedules the sensing data and control commands that were originally scattered across various functional domains, connecting downwards to various electronic control units and supporting human-machine interaction functions upwards.

[0167] The interaction layer mainly includes in-cabin display devices (such as instrument panel, central control screen, head-up display), voice interaction system, haptic feedback device, etc., which are responsible for presenting vehicle status, warning information and driving suggestions to the driver in the form of visual, auditory or tactile, while receiving the driver's touch, voice and other input commands.

[0168] Data transmission and interaction between different layers are achieved through the vehicle bus network. Common vehicle bus protocols include CAN (Controller Area Network), CAN FD (CAN with Flexible Data-Rate), LIN (Local Interconnect Network), FlexRay, and vehicle Ethernet, which supports high-bandwidth data transmission. Among these, CAN and CAN FD buses are widely used for communication in real-time control domains such as powertrain and chassis, while vehicle Ethernet is gradually being applied to high-bandwidth sensor data transmission in the intelligent driving domain and multimedia interaction scenarios in the cockpit domain.

[0169] In some possible examples, the domain controller, as the core of the in-vehicle computing platform, is configured with a processor and memory to execute the vehicle status query method provided in the embodiments of this application.

[0170] For example, the control device of this application is arranged in a domain controller.

[0171] For example, a domain controller may have multiple functional modules deployed to perform the various method steps.

[0172] The above are merely specific embodiments of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any changes or substitutions within the technical scope disclosed in this disclosure should be included within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.

Claims

1. A method for querying vehicle status, characterized in that, Applied to Remote Information Service Providers (TSPs), the method includes: In response to a vehicle status query command, determine whether the vehicle status query command meets a first condition; wherein, the first condition includes: the vehicle is in a dormant state, the vehicle status parameter queried by the vehicle status query command is a dynamic parameter, and the calibration validity period of the vehicle status parameter has expired; the dynamic parameter is a parameter whose value changes in the dormant state. If the vehicle status query command meets the first condition, the vehicle is woken up, the parameter value of the vehicle status parameter is queried, and the parameter value is returned.

2. The vehicle status query method according to claim 1, characterized in that, The method further includes: During the process of the vehicle switching from the wake-up state to the sleep state, the parameter value of the target vehicle state parameter in the vehicle is queried. Determine the effective calibration duration of the dynamic parameters in the target vehicle state parameters; wherein, the effective calibration duration is different for different dynamic parameters; Save the parameter values ​​and calibration validity period of the dynamic parameters in the target vehicle state parameters, as well as the parameter values ​​of the static parameters in the target vehicle state parameters, to the local storage.

3. The method for querying vehicle status according to claim 2, characterized in that, The determination of the calibration validity period of the dynamic parameters in the target vehicle state parameters includes: Determine the historical query frequency and vehicle-side change frequency of the dynamic parameters in the target vehicle status parameters; Based on the historical query frequency and the vehicle-side change frequency, the effective calibration duration of the dynamic parameters in the target vehicle status parameters is determined.

4. The vehicle status query method according to claim 3, characterized in that, The determination of the effective calibration duration of the dynamic parameters in the target vehicle status parameters based on the historical query frequency and the vehicle-side change frequency includes: Determine the larger frequency value between the historical query frequency and the vehicle-side change frequency; The duration corresponding to the larger frequency value is found from the preset correspondence and used as the effective calibration duration of the dynamic parameters in the target vehicle state parameters.

5. The method for querying vehicle status according to claim 1, characterized in that, The vehicle status query command is sent by the target application to the TSP when the parameter identifier bit of the vehicle status parameter is invalid; the TSP sends an invalid command to the target application to invalidate the parameter identifier bit when the target application changes the parameter value of the vehicle status parameter after the target application last queried the parameter value of the vehicle status parameter.

6. The method for querying vehicle status according to claim 5, characterized in that, When the target application requires display of the vehicle status parameters and the parameter identifier of the vehicle status parameters is valid, the target application displays the parameter value of the vehicle status parameters that was last queried by the target application.

7. The method for querying vehicle status according to claim 1, characterized in that, The method further includes: When the vehicle is in a wake-up state, query the parameter value of the vehicle status parameter and return the parameter value; When the vehicle is in the dormant state and the vehicle status parameter is a static parameter; or, when the vehicle is in the dormant state, the vehicle status parameter is a dynamic parameter, and the calibration validity period has not expired, read the parameter value of the vehicle status parameter stored locally, and return the parameter value.

8. A vehicle status query device, characterized in that, The device, applied to a remote information service provider (TSP), includes: a determination module and a wake-up module; The determining module is used to respond to a vehicle status query command and determine whether the vehicle status query command meets a first condition; wherein, the first condition includes: the vehicle is in a dormant state, the vehicle status parameter queried by the vehicle status query command is a dynamic parameter, and the calibration validity period of the vehicle status parameter has expired; the dynamic parameter is a parameter whose value changes in the dormant state. The wake-up module is used to wake up the vehicle, query the parameter value of the vehicle status parameter, and return the parameter value when the vehicle status query command meets the first condition.

9. A control device, characterized in that, The control device includes: a memory and a processor; the memory and the processor are coupled; the memory is used to store instructions executable by the processor; when the processor executes the instructions, it performs the vehicle status query method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed on a processor, cause the processor to perform the vehicle status query method as described in any one of claims 1 to 7.

11. A computer program product, characterized in that, It includes a computer program; when the computer program is executed, it is capable of implementing the method for querying the vehicle status as described in any one of claims 1 to 7.

12. A vehicle, characterized in that, It includes the control device as claimed in claim 9; or the computer-readable storage medium as claimed in claim 10; or the computer program product as claimed in claim 11.

Images