Data collection reporting method, vehicle-mounted terminal and vehicle

Abstract

This application discloses a data acquisition and reporting method, an in-vehicle terminal, and a vehicle, relating to the field of intelligent connected vehicles. The data acquisition and reporting method monitors vehicle signals based on input parameters in a vehicle condition change table, matches the corresponding target vehicle condition model based on the table's mapping relationship, processes the monitored data to obtain vehicle condition information, and completes vehicle condition reporting when reporting conditions are met. By using the vehicle condition change table, the vehicle condition acquisition logic is separated from the code layer, achieving decoupling between logic and data. This prevents the vehicle condition acquisition and judgment logic from being coupled into the TBOX firmware in a fixed code form, avoiding the need to develop customized code for different vehicle conditions. The vehicle condition acquisition capability can be updated and expanded without modifying the firmware program, effectively improving the universality of the vehicle condition judgment logic, the standardization of the acquisition process, and the iterative efficiency and execution stability of vehicle condition acquisition and reporting.

Description

Technical Field

[0001] This application relates to the field of intelligent connected vehicles, and in particular to a data collection and reporting method, an in-vehicle terminal, and a vehicle. Background Technology

[0002] With the development of vehicle intelligence and connectivity, remote collection and reporting of vehicle condition information has become a basic function of vehicle networking systems.

[0003] The logic for collecting and reporting vehicle condition data is typically predefined during the vehicle development phase or during OTA (Over-The-Air) upgrade cycles. The T-BOX (Telematics Box, in-vehicle communication terminal) internally defines the signal acquisition path, judgment logic, and reporting strategy corresponding to specific vehicle conditions. Once a vehicle is on the market, if users have new needs for viewing vehicle conditions, or if operators need to collect new vehicle status data, OTA upgrades are usually necessary to modify the program code or configuration files within the in-vehicle terminal. However, OTA upgrades involve multiple stages, including version development, testing and verification, approval, and installation push, resulting in long time cycles and slow response times. This makes it difficult to meet the rapid iteration of vehicle condition data collection needs, impacting user experience and operational efficiency. Summary of the Invention

[0004] The first aspect of this application provides a data collection and reporting method, including:

[0005] Based on the input parameters in the vehicle condition change table stored in the vehicle, the vehicle signal is monitored to obtain monitoring data, and the monitoring data corresponds to at least one input parameter; the vehicle condition change table contains the mapping relationship between the vehicle condition to be collected and at least two vehicle condition models, and at least one input parameter corresponding to each vehicle condition model represents the vehicle condition to be collected.

[0006] Based on the mapping relationship in the vehicle condition change table, the target vehicle condition model is determined, and the input parameters of the target vehicle condition model correspond to the monitoring data;

[0007] The target vehicle condition model is invoked to process the monitoring data and obtain vehicle condition information that represents a change in the vehicle's condition. The vehicle condition information corresponds to the monitoring data.

[0008] The vehicle condition information output by the target vehicle condition model is reported to the vehicle network platform.

[0009] In one possible implementation, determining the target vehicle condition model based on the mapping relationship in the vehicle condition change table includes:

[0010] Determine the operating parameters corresponding to the monitored data;

[0011] Based on the operating parameters corresponding to the monitored data, a vehicle condition model whose input parameters match the operating parameters is searched in the vehicle condition change table as the target vehicle condition model.

[0012] In one possible implementation, the step of searching for a vehicle condition model in the vehicle condition change table that matches the operating parameters of the monitored data as the target vehicle condition model includes:

[0013] Based on the operating parameters, determine the corresponding input parameters in the vehicle condition change table;

[0014] Among the at least two vehicle condition models recorded in the vehicle condition change table, the vehicle condition model corresponding to the input parameters is determined as the target vehicle condition model;

[0015] The at least two vehicle condition models include an instantaneous jump model, a continuous jump model, and a multi-signal logic operation model; the change of the input parameters of the instantaneous jump model is an instantaneous state switch, the input parameters of the continuous jump model need to be maintained for a set duration, and the input parameters of the multi-signal logic operation model are multiple signals with logical operation relationships.

[0016] In one possible implementation, determining the vehicle condition model corresponding to the input parameter as the target vehicle condition model from at least two vehicle condition models recorded in the vehicle condition change table includes:

[0017] Among at least two vehicle condition models recorded in the vehicle condition change table, determine the locally existing optional vehicle condition models. The vehicle condition change table includes locally existing optional vehicle condition models and locally non-optional vehicle condition models.

[0018] The optional vehicle condition model corresponding to the input parameters is determined as the target vehicle condition model.

[0019] In one possible implementation, the vehicle signals are monitored based on the input parameters in the vehicle condition change table stored in the vehicle database to obtain the monitoring data, including:

[0020] Identify each vehicle condition code recorded in the vehicle condition change table, with each vehicle condition code corresponding to at least one input parameter;

[0021] Based on the preset correspondence between vehicle condition codes and input parameters, the operating parameters corresponding to the vehicle condition codes are determined, and the operating parameters correspond to the input parameters;

[0022] The vehicle signals are monitored based on the aforementioned operating parameters to obtain monitoring data.

[0023] In one possible implementation, the step of invoking the target vehicle condition model, processing the monitored data, and obtaining vehicle condition information characterizing changes in vehicle condition includes:

[0024] Based on the input parameters corresponding to the target vehicle condition model, data corresponding to the input parameters is obtained from the monitoring data as input data;

[0025] The input data is input into the target vehicle condition model to obtain vehicle condition information. The vehicle condition information indicates that the input data meets the vehicle condition change conditions of the target vehicle condition model, and the vehicle condition information is at least a part of the input data.

[0026] One possible implementation also includes:

[0027] After the vehicle is started, an update request carrying a version identifier of the local vehicle condition change table is sent to the vehicle network platform so that the vehicle network platform can determine whether there is a vehicle condition change table to be updated based on the version identifier of the update request.

[0028] If the feedback information indicates that there is no vehicle condition change table to be updated, the vehicle condition change table currently stored in the vehicle shall be used as the standard, and the vehicle signal shall be monitored based on the input parameters in the vehicle condition change table stored in the vehicle to obtain the monitoring data.

[0029] If the feedback information includes a vehicle condition change table to be updated, update the vehicle condition change table stored in the vehicle according to the received vehicle condition change table; based on the updated vehicle condition change table, execute the step of monitoring the vehicle signal according to each input parameter in the vehicle condition change table stored in the vehicle to obtain monitoring data.

[0030] One possible implementation also includes:

[0031] In response to the remote update command from the vehicle networking platform, obtain the update data packet from the vehicle networking platform;

[0032] The update data packet is parsed to obtain the vehicle condition model to be updated;

[0033] Store the vehicle condition model to be updated in a preset storage location;

[0034] Update the vehicle condition change table to include the relevant configuration of the vehicle condition model to be updated.

[0035] A second aspect of this application provides an in-vehicle terminal, comprising:

[0036] The storage module is used to store a vehicle condition change table and at least two vehicle condition models; the vehicle condition change table contains the mapping relationship between the vehicle condition to be collected and at least two vehicle condition models, and at least one input parameter corresponding to each vehicle condition model represents the vehicle condition to be collected.

[0037] The processing module is used to execute the data acquisition and reporting method of the first aspect or any implementation thereof.

[0038] A third aspect of this application provides a vehicle, comprising:

[0039] ontology;

[0040] The vehicle-mounted terminal installed on the main body is used to implement the data collection and reporting method of the first aspect or any implementation of the first aspect.

[0041] In summary, this application provides a data acquisition and reporting method, an in-vehicle terminal, and a vehicle. This method involves monitoring vehicle signals based on input parameters in a vehicle condition change table, matching the corresponding target vehicle condition model based on the table's mapping relationship, processing the monitored data to obtain vehicle condition information, and completing vehicle condition reporting when reporting conditions are met. By using the vehicle condition change table, the vehicle condition acquisition logic is separated from the code layer, achieving decoupling between logic and data. This prevents the vehicle condition acquisition and judgment logic from being coupled into the TBOX firmware in a fixed code form, avoiding the need to develop customized code for different vehicle conditions. The vehicle condition acquisition capability can be updated and expanded without modifying the firmware program, effectively improving the universality of the vehicle condition judgment logic, the standardization of the acquisition process, and the iterative efficiency and execution stability of vehicle condition acquisition and reporting. Attached Figure Description

[0042] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0043] Figure 1 This is a flowchart illustrating a data collection and reporting method provided in an embodiment of this application;

[0044] Figure 2 This is a schematic diagram of the vehicle condition change table provided in the embodiments of this application;

[0045] Figure 3 This is a flowchart illustrating the process of determining the target vehicle condition model based on the mapping relationship in the vehicle condition change table, as provided in an embodiment of this application.

[0046] Figure 4 This is a flowchart illustrating the process of finding a vehicle condition model that matches the input parameters and operating parameters in the vehicle condition change table based on the operating parameters corresponding to the monitoring data, as the target vehicle condition model, according to an embodiment of this application.

[0047] Figure 5 This is a flowchart illustrating how vehicle signals are monitored and monitored to obtain monitoring data based on the input parameters in the vehicle condition change table stored in the vehicle, as provided in this application embodiment.

[0048] Figure 6 This is another flowchart illustrating the data collection and reporting method provided in this application embodiment;

[0049] Figure 7 This is another flowchart illustrating the data collection and reporting method provided in the embodiments of this application;

[0050] Figure 8 This is a flowchart illustrating a traditional data acquisition method.

[0051] Figure 9 This is a flowchart illustrating a data collection and reporting method provided in this application;

[0052] Figure 10 This is a schematic diagram of the structure of a vehicle-mounted terminal provided in an embodiment of this application;

[0053] Figure 11 This is a schematic diagram of the structure of a vehicle provided in an embodiment of this application. Detailed Implementation

[0054] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.

[0055] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0056] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0057] Reference Figure 1 , Figure 1 This is a flowchart illustrating a data collection and reporting method provided in an embodiment of this application. This method is applied to an in-vehicle terminal, such as... Figure 1 As shown in the figure, the data collection and reporting method provided in this application embodiment may include steps 101 to 104, which are described in detail below.

[0058] 101. Based on the input parameters in the vehicle condition change table stored in the vehicle, the vehicle signal is monitored to obtain monitoring data. The monitoring data corresponds to at least one input parameter. The vehicle condition change table contains the mapping relationship between the vehicle condition to be collected and at least two vehicle condition models. Each vehicle condition model has at least one input parameter that represents the vehicle condition to be collected.

[0059] In this application, the vehicle-mounted terminal uses a T-BOX. In subsequent embodiments, the vehicle-mounted terminal will be referred to as TBOX.

[0060] The vehicle condition change table is a configuration file stored in TBOX non-volatile memory. Its data structure includes at least the vehicle condition identifier to be collected, the vehicle condition model identifier, and input parameters and output parameters.

[0061] Among them, the vehicle condition identifier to be collected is used to index the vehicle status that needs to be monitored. The vehicle condition identifier to be collected can be identified by numerical sequence, such as vehicle condition 1, vehicle condition 2, etc.; or it can be identified by corresponding structural identifiers, such as the left front door open / close status, trunk open / close status, right front window open / close status, seat heating status, seat gravity sensor status, etc.

[0062] The vehicle condition model identifier is used to represent the vehicle condition algorithm model configured in each TBOX. This vehicle condition algorithm model can be set according to various types of vehicle conditions, such as being developed and configured in the TBOX based on changes in various structural signals in the vehicle. After being developed by developers and uploaded to the Telematics Service Platform (TSP), the vehicle condition model is distributed and deployed to each TBOX by the TSP. The vehicle condition model identifier can be identified by a serial number, such as model 1, model 2, model01, model02, etc., or by a model function identifier, such as an instantaneous jump model, a multi-signal logic calculation model, etc. This application does not impose any restrictions on the form of the vehicle condition model identifier.

[0063] The input parameters for the vehicle condition model vary depending on the model. Each input parameter represents the vehicle condition to be collected for that model. These input parameters define the specific signal source required for monitoring the corresponding vehicle condition model, and may include signal source identifiers, signal thresholds, etc.

[0064] Because a large number of signals are generated during vehicle operation, only a portion of these signals may need to be monitored and reported. The input parameters in this vehicle condition change table represent a subset of the numerous signals generated during vehicle operation. This table allows for the identification of specific signals that require monitoring from among the large number of signals, enabling the monitoring of these signals and the generation of monitoring data.

[0065] Because the monitoring targets are dynamically determined by reading the vehicle condition change table, when the vehicle starts or its configuration is updated, TBOX can parse this table to determine all the input parameters that need to be monitored and register the corresponding monitoring events. Once the vehicle signal changes, monitoring is triggered, and monitoring data is generated. This design means that when new vehicle condition data collection needs are added, only the configuration table needs to be modified without modifying the underlying code, reducing development and maintenance costs.

[0066] Figure 2 This is a schematic diagram of a vehicle condition change table provided in an embodiment of this application. The vehicle condition change table includes vehicle condition identifiers, model identifiers, input signals, and output signals. The vehicle condition identifiers include vehicle condition identifiers 1 to 4, and the model identifiers include model identifiers A to C. Each vehicle condition model has corresponding input and output parameters. Specifically, vehicle condition 1 and vehicle condition 2 corresponding to vehicle condition identifiers 1 and 2 belong to vehicle condition model A, vehicle condition 3 corresponding to vehicle condition identifier 3 belongs to vehicle condition model B, and vehicle condition 4 corresponding to vehicle condition identifier 4 belongs to vehicle condition model C. For vehicle condition 1, the input parameters of vehicle condition model A are parameter a, the state enumeration value of parameter a, and the duration, and the output parameter is parameter a; for vehicle condition 2, the input parameters of vehicle condition model A are parameter b, the state enumeration value of parameter b, and the duration, and the output parameter is parameter b; for vehicle condition 3, the input parameters of vehicle condition model B are parameter c and the state enumeration value of parameter c, and the output parameter is parameter c; for vehicle condition 4, the input parameter of vehicle condition model C is parameter def, and the output parameter is parameter g.

[0067] In subsequent embodiments, the detailed process of listening to vehicle signals and obtaining listening data based on the vehicle condition change table will be described in detail, and will not be described in detail here.

[0068] 102. Based on the mapping relationship in the vehicle condition change table, determine the target vehicle condition model, and the input parameters of the target vehicle condition model correspond to the monitoring data;

[0069] After capturing the monitored data, the system determines whether the data meets the reporting conditions based on the configuration logic specified in the vehicle condition model in the vehicle condition change table.

[0070] Based on the input parameters of each vehicle condition model in the mapping relationship in the vehicle condition change table, the target vehicle condition model corresponding to the monitored data is determined.

[0071] In one possible implementation, the input parameters corresponding to the monitored data are used as indexes to reverse-search the associated vehicle condition model identifier in the vehicle condition change table. Since the mapping relationship between input parameters and vehicle condition models is predefined in the vehicle condition change table, this mapping relationship can be used to locate the target vehicle condition model that processes the monitored signal.

[0072] For example, if the monitored signal includes a door lock status signal, and a lookup table shows that its mapped model is Model 1, then Model 1 is determined as the target vehicle condition model. Subsequently, this target vehicle condition model is used to process the door lock status signal. Similarly, if the monitored signal includes both a door lock status signal and a seat weight sensor signal, and a lookup table shows that its mapped model is Model 2, then Model 2 is determined as the target vehicle condition model. Subsequently, this target vehicle condition model is used to process both the door lock status signal and the seat weight sensor signal. This process achieves dynamic binding between data and processing logic; the same input parameter can be mapped to different models under different configurations, enhancing the system's flexibility.

[0073] It should be noted that, since various vehicle conditions may occur during vehicle operation, the target vehicle condition model determined at the same time period can be one or multiple, and this application does not impose any restrictions.

[0074] 103. Call the target vehicle condition model, process the monitoring data, and obtain vehicle condition information that represents the change in vehicle condition. The vehicle condition information corresponds to the monitoring data.

[0075] After determining the target vehicle condition model based on the vehicle condition change table, the target vehicle condition model is called to perform calculations on the monitored data.

[0076] The vehicle condition model is essentially a program module that encapsulates specific judgment logic, such as judging whether a signal changes, whether it lasts for a certain duration, or whether several signal combinations meet specific conditions.

[0077] The system takes the monitoring data corresponding to the input parameters of the target vehicle condition model as input and inputs it into the target vehicle condition model. The target vehicle condition model calculates the input data according to its internally defined rules to obtain the calculation result. If the calculation result meets the preset change conditions, vehicle condition information is generated; otherwise, no information is generated or empty information is generated. By using a model-based processing method, complex business logic is encapsulated within the model, and the outside only needs to call the interface, reducing the coupling of the system.

[0078] As an example, for the instantaneous change model, if the door switch signal changes from 0, which represents the closed state, to 1, which represents the closed state, the instantaneous change model determines that the change is valid and outputs vehicle condition information containing the current state value of the door switch signal.

[0079] 104. Report the vehicle condition information output by the target vehicle condition model to the vehicle network platform.

[0080] The vehicle condition information output by the target vehicle condition model not only includes the changed status value, but also implicitly includes the judgment result that meets the reporting conditions.

[0081] When the target vehicle condition model determines that the vehicle condition information is valid, its output vehicle condition information meets the reporting conditions. Accordingly, the TBOX encapsulates this information into a data packet through the communication module and sends it to the vehicle networking platform.

[0082] The reporting condition is included in the model logic. If the target vehicle condition model processes the monitored data and determines that the monitored data satisfies the judgment logic within the target vehicle condition model, this judgment logic can be used as the decision logic for whether to report. Correspondingly, if the monitored data satisfies the judgment logic within the target vehicle condition model, it also implicitly determines that the current vehicle condition needs to be reported. Through the processing of this vehicle condition model, accurate reporting of vehicle condition changes is achieved, avoiding frequent transmission of invalid data and saving network bandwidth resources.

[0083] For example, the judgment logic in Model 1 is to report when the state changes. So, if the input monitoring data is that the door switch signal changes from 0 to 1, Model 1 can determine that the vehicle condition corresponding to the monitoring data meets the reporting conditions, and can report the door switch signal as 1 as vehicle condition information.

[0084] For example, the judgment logic in Model 2 is to report after the signal lasts for 3 seconds. So, if the input monitoring data is that the seat heating lasts for 3 seconds, Model 2 can determine that the vehicle condition corresponding to the monitoring data meets the reporting conditions, and can report the 3-second seat heating support as vehicle condition information.

[0085] For example, the judgment logic in Model 3 is that multiple signals appear simultaneously and last for 5 monitoring cycles. So, if the input monitoring data is a signal that the car door is closed and a signal that there is a heavy object on the seat, and the duration reaches 5 monitoring cycles, Model 3 can determine that the vehicle condition corresponding to the monitoring data meets the reporting conditions, and can report the signal that there is a heavy object on the seat and lasts for 5 monitoring cycles as vehicle condition information.

[0086] In this embodiment, vehicle signals are monitored based on input parameters in the vehicle condition change table, and the corresponding target vehicle condition model is matched based on the mapping relationship in the table. The monitored data is processed to obtain vehicle condition information, and vehicle condition reporting is completed when the reporting conditions are met. By using the vehicle condition change table, the vehicle condition collection logic is separated from the code layer, realizing the decoupling of logic and data. This prevents the vehicle condition collection and judgment logic from being coupled to the TBOX firmware in the form of fixed code, avoiding the need to develop customized code for different vehicle conditions. The vehicle condition collection capability can be updated and expanded without modifying the firmware program, effectively improving the universality of the vehicle condition judgment logic, the standardization of the collection process, and the iterative efficiency and execution stability of vehicle condition collection and reporting.

[0087] Figure 3This is a flowchart illustrating the process of determining a target vehicle condition model based on the mapping relationship in the vehicle condition change table, as provided in this application embodiment. It may include steps 301 to 302, which are described in detail below.

[0088] 301. Determine the running parameters corresponding to the monitored data;

[0089] This operating parameter is a signal variable transmitted on the vehicle bus. It can be recorded using a set signal ID (Identity Document) or signal name. For example, the signal ID of an operating parameter might be 0x123, and the signal name could be door status signal / doorstatus.

[0090] The monitored data is the specific data of the operating parameter obtained through monitoring. The input parameters recorded in the vehicle condition change table can be the index or identifier of the operating parameter.

[0091] Accordingly, after obtaining the monitored data, the corresponding operating parameters are first determined. For example, after monitoring a set of data, it is determined that the operating parameter corresponding to that set of data is the door status.

[0092] 302. Based on the operating parameters corresponding to the monitored data, find the vehicle condition model in the vehicle condition change table that matches the input parameters and operating parameters as the target vehicle condition model.

[0093] After determining the operating parameters, the corresponding input parameters are found in the vehicle condition change table, and then the vehicle condition model corresponding to the input parameters is determined as the target vehicle condition model.

[0094] Since a vehicle condition model can process multiple operating parameters of the same type, a change in vehicle condition can be characterized by a change in one or more operating parameters, and another change in vehicle condition can be characterized by a change in another or more operating parameters. The matching can be that the operating parameter is the same as the input parameter corresponding to a change in vehicle condition.

[0095] As an example, the operating parameter is the door status signal. The vehicle condition change table is used to query vehicle condition models whose input parameter is the door status signal. Specifically, vehicle condition model A corresponds to vehicle condition 1 with the door status signal as its input parameter, while vehicle condition model B corresponds to vehicle condition 2 with both the door status signal and the seat load signal as its input parameters. It can be determined that the input parameters of vehicle condition model A match the operating parameter, the door status signal. Therefore, vehicle condition model A is selected as the target vehicle condition model.

[0096] In this embodiment, the vehicle bus operating parameters corresponding to the monitored data are first matched, and then the execution flow of the corresponding vehicle condition model is accurately matched based on the mapping relationship of the vehicle condition change table. This breaks the limitation of the traditional solution that solidifies the vehicle condition judgment logic into the terminal firmware. It unifies the vehicle bus signal recognition rules and establishes the association between operating parameters and various vehicle condition models based on input parameters. Moreover, it eliminates the need to develop customized acquisition and judgment code for each type of vehicle condition; the association configuration between operating parameters and vehicle condition models can be quickly completed using the vehicle condition change table. This forms a mapping chain between the monitored data, operating parameters, input parameters, and vehicle condition models, accurately associating underlying signal changes with upper-layer business logic models. This achieves decoupling between the data layer and the logic layer, facilitating independent maintenance and upgrades of the business logic in the future.

[0097] Figure 4 This application provides a flowchart illustrating how, based on the operating parameters corresponding to the monitored data, a vehicle condition model is searched in the vehicle condition change table to find a vehicle condition model whose input parameters match the operating parameters as the target vehicle condition model. This flowchart may include steps 401 to 402, which are described in detail below.

[0098] 401. Based on the operating parameters, determine the corresponding input parameters in the vehicle condition change table;

[0099] Input parameters are the standard access parameters preset by the vehicle condition model for data calculation and judgment. By determining the corresponding input parameter in the vehicle condition change table, the parameter can be mapped to the vehicle condition change table.

[0100] After locking the actual operating parameters corresponding to the vehicle bus, the input parameters corresponding to the operating parameters can be determined from the large number of input parameters recorded in the vehicle condition change table.

[0101] In one possible implementation, the operating parameter and the input parameter use the same naming convention. Correspondingly, the corresponding input parameter is determined by querying the vehicle condition change table to see if the operating parameter exists or by querying the input parameter that is the same as the operating parameter.

[0102] 402. Among the at least two vehicle condition models recorded in the vehicle condition change table, the vehicle condition model corresponding to the input parameters is determined as the target vehicle condition model; wherein, the at least two vehicle condition models include an instantaneous jump model, a continuous jump model, and a multi-signal logic operation model; the change of the input parameters of the instantaneous jump model is an instantaneous state switch, the input parameters of the continuous jump model need to be maintained for a set duration, and the input parameters of the multi-signal logic operation model are multiple signals with logical operation relationships.

[0103] TBOX pre-configures multiple vehicle condition models, each implementing different judgment logic to adapt to different vehicle condition change recognition scenarios.

[0104] Among the numerous input parameters recorded in the vehicle condition change table, after determining the input parameter corresponding to the operating parameter, the vehicle condition model corresponding to the input parameter is further searched, and the vehicle condition model found is used as the target vehicle condition model.

[0105] In one possible implementation, the vehicle condition model includes an instantaneous transition model, a continuous transition model, and a multi-signal logic operation model. The instantaneous transition model is suitable for vehicle condition judgment scenarios where the input parameters undergo instantaneous state switching; the continuous transition model is used to identify vehicle condition changes that take effect only after the input parameter state has been stably maintained for a set duration; the multi-signal logic operation model can simultaneously receive multiple different input parameters and complete the comprehensive vehicle condition judgment based on the preset logical operation relationships between the parameters.

[0106] In this embodiment, the mapping of actual operating parameters to standard input parameters is first completed based on the vehicle condition change table, unifying the interface between the underlying vehicle signals and the vehicle condition judgment model, simplifying the parameter matching logic and reducing the computational burden of the on-board TBOX. Then, the corresponding type of vehicle condition model is matched according to the input parameters. By dividing the vehicle condition model into three different judgment logics—instantaneous jump, continuous jump, and multi-signal logic operation—it can comprehensively adapt to various vehicle condition recognition scenarios such as instantaneous state switching, duration threshold judgment, and multi-signal linkage analysis, thereby improving the comprehensiveness and accuracy of vehicle condition change recognition.

[0107] In one possible implementation, among at least two vehicle condition models recorded in the vehicle condition change table, determining the vehicle condition model corresponding to the input parameter as the target vehicle condition model includes: determining the locally existing optional vehicle condition model among the at least two vehicle condition models recorded in the vehicle condition change table, wherein the vehicle condition change table includes locally existing optional vehicle condition models and locally non-optional vehicle condition models; and determining the optional vehicle condition model corresponding to the input parameter as the target vehicle condition model.

[0108] Due to differences in software versions throughout the vehicle's lifecycle, the vehicle condition models configured in different vehicles may differ. Therefore, the data collection and reporting method in this embodiment also provides a compatibility handling mechanism.

[0109] In practical applications, the vehicle condition change table issued by the vehicle networking platform may contain the latest vehicle condition model configuration. However, some existing vehicles' TBOXes may not have undergone OTA upgrades, resulting in the absence of certain newly defined models in the TBOX's local model library. In this scenario, the vehicle condition models in the TBOX's vehicle condition change table include not only locally available selectable vehicle condition models but also locally unavailable non-selectable vehicle condition models.

[0110] For example, the vehicle condition change table contains 5 vehicle condition models, but TBOX only has models 1 to 3 locally, and models 4 and 5 do not exist. Models 1 to 3 are optional vehicle condition models, while models 4 to 5 are not optional vehicle condition models.

[0111] In one possible implementation, after updating the vehicle condition change table, vehicle condition models existing in local storage can be detected first, and then marked as optional models in the vehicle condition change table before executing subsequent logic. For vehicle condition models that do not exist locally, they are marked as unselectable models in the vehicle condition change table, and the data collection process for the corresponding vehicle condition is skipped. By decoupling model design from model usage, operators do not need to worry about existing vehicles failing to recognize the new model, leading to system crashes or configuration table parsing failures when configuring new vehicle conditions in the cloud. This ensures that existing vehicles can still run other supported models in the vehicle condition change table normally even without upgrades, greatly improving system compatibility and stability.

[0112] In this embodiment, by distinguishing between locally available optional vehicle condition models and non-deployed optional vehicle condition models in the vehicle condition change table, the system prioritizes matching locally configured optional vehicle condition models as target models for business processing. For cases where terminals have not completed OTA upgrades or lack corresponding algorithm models, the corresponding data collection process is skipped directly. This establishes a robust version compatibility and adaptation mechanism, effectively adapting to existing vehicles with different software versions and configuration states. It avoids issues such as program anomalies and judgment failures caused by the lack of corresponding models locally due to the platform issuing the latest configuration, ensuring the stable operation of vehicle condition data collection and reporting. Simultaneously, it eliminates the need to force all vehicles to complete model upgrades simultaneously, reducing the operational pressure and upgrade risks of batch vehicle upgrades while also accommodating the differentiated usage needs of new and existing vehicles. This significantly improves the universality, adaptability, and practicality of the entire vehicle condition data collection and reporting system.

[0113] Figure 5 This is a flowchart illustrating how a vehicle signal is monitored and monitored to obtain monitoring data based on the input parameters in the vehicle condition change table stored in this application embodiment. It may include steps 501 to 503, which are described in detail below.

[0114] 501. Determine each vehicle condition code recorded in the vehicle condition change table. Each vehicle condition code corresponds to at least one input parameter.

[0115] The vehicle condition change table contains the input parameters for each vehicle condition record of each vehicle condition model.

[0116] Before monitoring the signals generated during vehicle operation, the operating parameters that need to be monitored should be determined first.

[0117] In one possible implementation, the vehicle condition change table is traversed to determine the vehicle condition codes recorded therein. Each vehicle condition code corresponds to a set of input parameters. A set of input parameters can be a single input parameter or multiple input parameters.

[0118] 502. Based on the preset correspondence between vehicle condition codes and input parameters, determine the operating parameters corresponding to the vehicle condition codes, and the operating parameters correspond to the input parameters;

[0119] After determining each vehicle condition code based on the vehicle condition change table, the corresponding input parameters for each vehicle condition code are determined using the correspondence in the vehicle condition change table. These input parameters are the operating parameters during vehicle operation. Accordingly, using this correspondence, the operating parameters corresponding to each vehicle condition code can be determined.

[0120] Operating parameters are specific signal variables defined in the vehicle communication protocol, and are signals generated during vehicle operation.

[0121] For example, this operating parameter could be a CAN (Controller Area Network) bus signal ID, etc.

[0122] The vehicle condition code is an identifier used in the vehicle condition change table to index the specific vehicle status. Since signals on the vehicle bus are usually transmitted in hexadecimal IDs or specific message formats, directly using the vehicle condition code cannot locate the underlying signals. Therefore, in this embodiment, the operating parameters corresponding to different vehicle conditions are determined based on the mapping relationship between the vehicle condition code and the input parameters in the vehicle condition change table.

[0123] As an example, by using the input parameters corresponding to each vehicle condition code in the vehicle condition change table, 100 operating parameters can be determined, and these 100 operating parameters correspond to the input information of each vehicle condition code.

[0124] 503. Monitor vehicle signals based on operating parameters to obtain monitoring data.

[0125] After determining the operating parameters corresponding to the vehicle condition code, the signals of vehicle operation can be monitored based on a set of operating parameters corresponding to the vehicle condition code to obtain the monitoring data corresponding to each set of operating parameters.

[0126] Steps 501-502 can be performed after the vehicle condition change table is updated. First, the input parameters involved in the vehicle condition change table are determined so that the corresponding operating parameters can be used to monitor the signals during vehicle operation, thereby realizing the process of collecting and reporting vehicle condition information when the vehicle condition changes.

[0127] In one possible implementation, when TBOX parses the vehicle condition change table, it first reads the vehicle condition code, converts it into specific operating parameters by querying a mapping table, and then registers a listening event for that operating parameter with the vehicle communication interface. During vehicle operation, once the signal corresponding to that operating parameter is transmitted or changes on the bus, the listening is triggered, and the signal value at that moment is captured as listening data. This mapping chain design decouples the vehicle condition concept at the business layer from the underlying communication signals, making the configuration of the vehicle condition change table more in line with the cognitive habits of operations personnel, without needing to concern themselves with the complex details of the underlying communication protocols.

[0128] In this embodiment, various vehicle condition codes are first extracted from the vehicle condition change table. Then, using a preset correspondence, the vehicle condition codes are converted into the actual operating parameters corresponding to the vehicle bus. Finally, vehicle signals are monitored and monitoring data is obtained based on the determined operating parameters. This method separates the upper-layer business vehicle condition definition from the underlying vehicle CAN bus communication signals by mapping and connecting the vehicle condition codes, input parameters, and underlying operating parameters. Staff only need to configure the vehicle condition codes to complete the data collection settings without having to master the complex underlying communication protocols, simplifying the configuration process. At the same time, it can accurately lock the target monitoring signal, reduce redundant data collection, save TBOX computing power and communication resources, and decouple the business configuration from the underlying monitoring logic. Later additions and adjustments to vehicle condition collection requirements only require modification of the mapping relationship to complete the adaptation without modifying the underlying monitoring program, effectively improving the convenience of vehicle condition collection work, resource utilization, and overall solution scalability.

[0129] In one possible implementation, the target vehicle condition model is invoked to process the monitored data and obtain vehicle condition information representing changes in the vehicle's condition, including:

[0130] Based on the input parameters corresponding to the target vehicle condition model, data corresponding to the input parameters is obtained from the monitoring data as input data; the input data is input into the target vehicle condition model to obtain vehicle condition information. The vehicle condition information indicates that the input data meets the vehicle condition change conditions of the target vehicle condition model, and the vehicle condition information is at least a part of the input data.

[0131] Once the monitored data is captured, it is filtered and processed according to the input parameters corresponding to the target vehicle condition model.

[0132] Based on the input parameters required by the target vehicle condition model, relevant data segments are extracted from the monitored data packets as input data. The target vehicle condition model internally executes preset computational logic to determine whether the input data meets its computational requirements. If so, vehicle condition information is output. This output vehicle condition information is the information to be uploaded.

[0133] The target vehicle condition model processes the input data and outputs vehicle condition information. This vehicle condition information indicates that the input data meets the vehicle condition change conditions of the target vehicle condition model. The corresponding changes in the current vehicle condition need to be reported. Subsequently, the output vehicle condition information can be reported.

[0134] The vehicle condition information output by the target vehicle condition model can be the same as the input data, or it can be a portion of the input data.

[0135] For example, if the input data is the door signal changing from 0 to 1, the output vehicle condition information can include the door information being 1; if the input data includes four door signals being 0 and the seat gravity sensor indicating the presence of a heavy object, the output vehicle condition information can be the presence of a heavy object in the seat gravity sensor.

[0136] The instantaneous transition model operates by detecting whether the input data changes state value, for example, the input data changes from 0 to 1; the continuous transition model operates by detecting whether the input data remains in the same state for a set duration, for example, the signal remains in the same state for 3 seconds; the multi-signal logic operation model operates by detecting whether multiple input data satisfy a preset logic formula, for example, signal 1 and signal 2 are combined and maintained for a certain duration.

[0137] In this embodiment, based on the input parameters matched to the target vehicle condition model, corresponding content is extracted from the collected monitoring data as input data. This input data is then imported into the target vehicle condition model. The model's built-in judgment logic verifies whether the data meets the vehicle condition change conditions. If the condition is met, all or part of the input data is extracted to generate reportable vehicle condition information. Different types of vehicle condition models can perform state determination separately. This solution can accurately filter invalid monitoring data, retaining only the valid data required for model determination, significantly reducing the volume of data to be reported and alleviating the data processing pressure on the TBOX and the cloud receiving and storage pressure. By standardizing the built-in judgment rules of the model, the standard for judging vehicle condition changes is unified, ensuring consistent and reliable vehicle condition recognition results for all vehicles. Furthermore, vehicle condition models with different operational logics can fully adapt to various vehicle state change recognition scenarios. Moreover, only necessary fields are extracted to generate reporting information, balancing reporting accuracy and transmission efficiency. The vehicle condition judgment logic is integrated into an independent model, so subsequent modifications to the judgment rules only require adjusting the model parameters and operational logic, without changing the overall data processing flow, further improving the flexibility and practicality of adjusting vehicle condition judgment services.

[0138] Figure 6 This is another flowchart illustrating the data collection and reporting method provided in this application embodiment, which may include steps 601 to 603. These steps are described in detail below.

[0139] 601. After the vehicle is started, send an update request carrying the version identifier of the local vehicle condition change table to the vehicle network platform so that the vehicle network platform can determine whether there is a vehicle condition change table to be updated based on the version identifier of the update request.

[0140] Each time the vehicle is started, TBOX will proactively initiate an update request with the vehicle networking platform, which carries the version identifier of the locally stored vehicle condition change table.

[0141] In one possible implementation, the update request could be a handshake request to establish communication with the vehicle networking platform after the TBOX starts up.

[0142] The version identifier can be a version number, such as V1.0.

[0143] After receiving an update request, the vehicle network platform queries the version of the vehicle condition change table stored on the platform, generates feedback information based on the query results, and sends it to the vehicle terminal.

[0144] If the version of the vehicle condition change table in the vehicle network platform is the same as the version on the vehicle terminal, the generated feedback message indicates that there is no vehicle condition change table to be updated. If the version of the vehicle condition change table in the vehicle network platform is higher than the version on the vehicle terminal, the generated feedback message indicates that there is a vehicle condition change table to be updated, and the higher version of the vehicle condition change table in the vehicle network platform is sent as feedback information to the vehicle terminal.

[0145] As an example, each time the vehicle is powered on and started, the TBOX initiates a handshake request, carrying the version number of the locally stored vehicle condition change table. Upon receiving this request, the vehicle-to-everything (V2X) platform compares the vehicle's local version number with the latest version number of the V2X platform. If the versions match, no update is needed, and the vehicle continues to use its local configuration. If the V2X platform version is higher, such as TBOX version V1.0 and the V2X platform version V1.1, the cloud will send the latest vehicle condition change table to the vehicle.

[0146] In one possible implementation, maintenance personnel enter vehicle condition codes, input parameters, vehicle bus operating parameters, and output parameters into the vehicle network platform backend, bind various vehicle condition models and corresponding judgment rules, and after completing the configuration, uniformly compile and encrypt the version to generate a complete vehicle condition change table, and then distribute the vehicle condition change table to the vehicle TBOX.

[0147] After receiving the feedback information, TBOX parses the feedback information to obtain its content.

[0148] If the feedback information includes a vehicle condition change table, proceed to step 603; otherwise, proceed to step 602.

[0149] 602. If the feedback information indicates that there is no vehicle condition change table to be updated, the vehicle condition change table currently stored in the vehicle shall be used as the standard, and the vehicle signal shall be monitored according to the input parameters in the vehicle condition change table stored in the vehicle to obtain the monitoring data.

[0150] The feedback message did not include a vehicle condition change sheet to be updated, which confirms that the vehicle networking platform does not have a vehicle condition change sheet to be updated, and the vehicle condition change sheet in the TBOX is the latest version.

[0151] Accordingly, after the vehicle's system is started, it can use the vehicle's currently stored vehicle condition change table as a reference to perform the subsequent process of collecting and reporting vehicle condition changes.

[0152] For the process of monitoring, collecting, and reporting data, please refer to the explanation in the aforementioned embodiments; it will not be repeated here.

[0153] 603. If the feedback information includes a vehicle condition change table to be updated, update the vehicle condition change table stored in the vehicle according to the received vehicle condition change table; based on the updated vehicle condition change table, perform the step of monitoring the vehicle signal according to each input parameter in the vehicle condition change table stored in the vehicle to obtain the monitoring data.

[0154] The fact that the feedback message includes a vehicle condition change sheet that needs to be updated confirms that the vehicle networking platform has an updated version of the vehicle condition change sheet, and the vehicle condition change sheet in this TBOX is not the latest version.

[0155] The vehicle condition change table from the feedback information is updated in the vehicle's internal storage to ensure that the stored vehicle condition change table is the latest version. Accordingly, subsequent processes for collecting and reporting vehicle condition changes will be based on this updated vehicle condition change table.

[0156] For the process of monitoring, collecting, and reporting data, please refer to the explanation in the aforementioned embodiments; it will not be repeated here.

[0157] Because the vehicle condition change table is updated when the vehicle starts, the process only requires the transmission of configuration data and does not require flashing or restarting the TBOX system firmware, which greatly shortens the online cycle for new vehicle condition collection needs and enables rapid iteration and flexible operation of vehicle condition services.

[0158] In this embodiment, after the vehicle starts, the TBOX sends an update request to the vehicle network platform carrying the version identifier of the local vehicle condition change table. The vehicle network platform compares the version and returns a feedback result. If there is no new version, the vehicle terminal continues to use the existing local vehicle condition change table to perform signal monitoring and collection. If an updated version exists, the locally stored vehicle condition change table is updated, and the subsequent collection process is executed according to the latest configuration. In this process, configuration version verification and on-demand updates are completed by relying on startup self-check. Only configuration form data is transmitted, without flashing terminal firmware or restarting the device, which greatly reduces the time spent on business updates and speeds up the implementation of new collection requirements. It can ensure that the vehicle always executes vehicle condition collection and reporting with the latest configuration rules, unify the vehicle judgment standard across the network, and avoid meaningless repeated updates, saving network transmission and terminal storage resources. At the same time, configuration updates and underlying firmware are independent of each other, and business rule adjustments do not require changes to the underlying program. It has high iteration flexibility and can efficiently adapt to the dynamically changing vehicle condition collection and management requirements of the operation side.

[0159] Figure 7 This is another flowchart illustrating the data collection and reporting method provided in this application embodiment. This process is for updating the vehicle condition model of the vehicle terminal and may include steps 701 to 704. These steps are described in detail below.

[0160] 701. Responding to the remote update command from the vehicle networking platform, obtain the update data packet from the vehicle networking platform;

[0161] When the vehicle networking platform needs to update the vehicle condition model of each TBOX, it can proactively send a remote update command to the vehicle. Under normal network conditions, the TBOX listens for remote commands sent by the vehicle networking platform in real time. Upon receiving the remote update command for the vehicle condition model sent by the vehicle networking platform, it responds to the update operation and receives the corresponding update data packet sent by the vehicle networking platform.

[0162] The remote update command may include information such as the storage location of the update data packet. Accordingly, after receiving the remote update command, TBOX obtains the update data packet based on the storage location contained in the remote update command.

[0163] This update may include adding new vehicle condition recognition types, updating the original vehicle condition model judgment logic, or expanding vehicle condition collection business scenarios.

[0164] The update data package is an encrypted data file pre-packaged by the vehicle networking platform, specifically used for adding or iteratively updating the vehicle condition model. It can be distributed to upper-level vehicle condition business model data and does not include core underlying files such as the TBOX firmware program and system drivers.

[0165] 702. Parse the update data packet to obtain the vehicle condition model to be updated;

[0166] After receiving a complete update data packet, TBOX can first verify the validity of the data packet, including the integrity of the data packet, the validity of the version, and the matching of the encryption key, to prevent abnormal data packets or illegal data from intruding into the terminal system.

[0167] After the verification is passed, the data content encapsulated inside the update data packet is parsed and deconstructed to extract the valid business data, and finally the vehicle condition model to be updated is obtained.

[0168] The vehicle condition model to be updated can be a brand new vehicle condition recognition model, or an iterative model that optimizes and upgrades the judgment rules, parameter thresholds, and logical algorithms of an existing vehicle condition model. The specific configuration can be flexibly configured according to the platform's operational needs.

[0169] 703. Store the vehicle condition model to be updated to the preset storage location;

[0170] The TBOX has a dedicated model storage partition as the default storage location. This partition is specifically used to store various vehicle condition model files and is independent of the storage area for firmware programs and system data, so they do not interfere with each other.

[0171] After parsing the vehicle condition model to be updated, TBOX writes the complete vehicle condition model to the preset model storage location, completing the local deployment of the new model. This adds a corresponding callable vehicle condition model resource to the TBOX local model library, providing model support for subsequent vehicle condition recognition and data processing.

[0172] This storage process is incremental, which will not overwrite or damage the existing mature vehicle condition model on the terminal, ensuring the normal operation of the original vehicle condition collection business.

[0173] In one possible implementation, the TBOX downloads and parses the data packet using OTA technology, stores the new model algorithm file in the specified model library directory, and completes the algorithm layer upgrade.

[0174] 704. Update the vehicle condition change table to include the relevant configurations of the vehicle condition model to be updated.

[0175] After completing the local storage deployment of the vehicle condition model to be updated, TBOX also needs to iteratively update the vehicle condition change table in the local storage.

[0176] In one possible implementation, after TBOX stores the vehicle condition model to be updated to a preset storage location, the vehicle system restarts. After the system restarts, TBOX sends an update request to the vehicle networking platform.

[0177] Correspondingly, the vehicle networking platform stores the latest version of the vehicle condition change table corresponding to the vehicle condition model to be updated. After receiving an update request from the vehicle-side TBOX, the vehicle networking platform sends the latest version of the vehicle condition change table back to the vehicle.

[0178] In this embodiment, the vehicle-mounted TBOX responds to the remote update command issued by the vehicle networking platform and obtains the corresponding update data packet. It then parses the data packet to obtain the vehicle condition model to be updated, incrementally stores this model in a dedicated preset model storage partition on the terminal, and updates the local vehicle condition change table, completing the configuration association and online adaptation of the newly added vehicle condition model. This process enables remote OTA upgrades of the pure business layer vehicle condition model and vehicle condition change table without requiring any flashing or modification of the TBOX's underlying firmware or system drivers. This fundamentally avoids the risks of upgrade failures, system anomalies, and device malfunctions inherent in traditional firmware upgrades, significantly reducing the maintenance costs and security risks associated with vehicle iterative upgrades. Moreover, this solution supports various iterative scenarios, such as adding new vehicle condition models and optimizing the judgment logic of existing models. It can quickly expand and optimize vehicle condition collection and recognition capabilities simply by updating model files and configuration forms, without modifying the underlying terminal program. This enables lightweight, high-frequency, and high-efficiency iteration of vehicle condition collection services, greatly shortening the launch cycle of new vehicle condition collection requirements. It solves the industry pain points of traditional solutions, such as high firmware coupling, slow iteration, high upgrade risk, and poor adaptability, and significantly improves the scalability, compatibility, and operational flexibility of the vehicle condition collection system.

[0179] To more intuitively demonstrate the advantages of the data collection and reporting method provided in this application compared with traditional collection schemes, this application also provides a flowchart to compare and illustrate the existing technology and the technical solution of this application.

[0180] Figure 8 This is a flowchart illustrating a traditional data acquisition solution. In a traditional solution, there are product demand side, vehicle networking platform, and in-vehicle terminal. The product demand side, also known as the APP (application) side, manages the vehicle user application software. Start

[0181] 801. The product demand side outputs the App function list based on the vehicle function definition, and clarifies the vehicle condition items that need to be collected and reported;

[0182] 802. The vehicle networking platform receives a list of functions, which includes sorting out the vehicle conditions to be collected and the corresponding vehicle signals, and recording them in the vehicle condition change table;

[0183] 803. The vehicle terminal writes code for each vehicle condition change based on the vehicle condition change table.

[0184] In traditional data acquisition solutions, developers hard-code signal monitoring logic, vehicle condition judgment logic, and reporting rules into the TBOX firmware based on the collected signal information. During device operation, the TBOX listens to preset bus signals according to the fixed code, compares the signal values ​​before and after, and triggers vehicle condition reporting directly when the data changes. When new vehicle condition data acquisition needs are added later, the TBOX's underlying program code needs to be modified, and a full firmware OTA upgrade needs to be pushed. The upgrade process includes development, testing, batch push, and vehicle upgrade, resulting in long iteration cycles, high upgrade costs, and the potential for firmware upgrades to cause device malfunctions.

[0185] Figure 9 This is a flowchart illustrating a data collection and reporting method provided in this application. The solution includes a product demand side, a vehicle networking platform, and an in-vehicle terminal. The data collection and reporting method is divided into two stages: a model pre-research stage and a configuration implementation stage.

[0186] Model Preliminary Research Phase:

[0187] 901. The vehicle network platform and the vehicle terminal jointly collect and report vehicle condition rules according to the pre-set requirements, abstract them into various data models, and define the input parameters, algorithm rules and output parameters of each data model.

[0188] 902. The vehicle terminal pre-stores each data model in a local independent storage area;

[0189] After completing the model framework development, the abstracted data model is stored. This step is a one-time development and can be reused repeatedly.

[0190] Configuration and implementation phase:

[0191] 903. The product requirement side outputs a list of App functions based on the overall vehicle function definition;

[0192] 904. List of functions to be received by the vehicle networking platform: sort out the vehicle conditions to be collected, the corresponding vehicle signals and the data models to be used, and record them in the vehicle condition change table;

[0193] 905. The vehicle networking platform will synchronize the vehicle condition change report to the vehicle terminal.

[0194] 906. If the identified vehicle condition cannot be met by the existing model, return to the model pre-research stage, redesign the data model, and implement the data model by the vehicle terminal.

[0195] 907. The vehicle terminal initializes the data model for each vehicle condition and the input parameters of the relevant models based on the vehicle condition change table;

[0196] This input parameter can be a vehicle signal.

[0197] 908. The vehicle terminal continuously monitors the vehicle's signals and pushes the collected signal values ​​to the relevant data model;

[0198] 909. The vehicle terminal uses the data model to determine whether a change in vehicle condition has occurred by utilizing input parameters and its own algorithm rules.

[0199] 910. If a change occurs, the vehicle terminal updates the input parameters of the data model and reports the changed vehicle condition record to the vehicle network platform. If no change occurs, the signal is ignored and monitoring continues.

[0200] Traditional data acquisition solutions embed vehicle condition data collection and judgment logic into the TBOX firmware. Adding new data collection requirements necessitates code modification and firmware upgrades. This application decouples business configuration from the underlying program through a vehicle condition change table. Adding or modifying data collection requirements only requires the TSP to adjust the configuration table in the cloud, without modifying the TBOX firmware. New models can also be added via lightweight remote incremental updates, effectively shortening the implementation cycle of new requirements and reducing iteration costs. Furthermore, the use of multiple model types and a mechanism distinguishing between optional and non-optional models improves system compatibility and vehicle condition recognition coverage.

[0201] The above describes a data collection and reporting method provided by the embodiments of this application. The following will describe the vehicle terminal and vehicle that perform the above data collection and reporting method.

[0202] Please see Figure 10 , Figure 10 This is a schematic diagram of the structure of a vehicle-mounted terminal provided in an embodiment of this application. The vehicle-mounted terminal can be a T-BOX. Figure 10 As shown, the vehicle terminal 1000 includes: a storage module 1001 and a processing module 1002; the processing module and the storage module are connected via an internal bus.

[0203] The storage module 1001 is used to store a vehicle condition change table and at least two vehicle condition models. The vehicle condition change table contains the mapping relationship between the vehicle condition to be collected and at least two vehicle condition models. Each vehicle condition model has at least one input parameter that represents the vehicle condition to be collected.

[0204] The storage module 1001 can use non-volatile memory such as Flash memory or EEPROM (Electrically Erasable Programmable Read-Only Memory) to ensure that the configuration data is not lost after the vehicle is powered off.

[0205] The storage module is internally divided into independent storage areas for storing the vehicle condition change table and the vehicle condition model library, respectively. The vehicle condition change table is stored as a structured data file, recording configuration information such as vehicle condition codes, model codes, input parameters, and model parameters. The vehicle condition model library stores several pre-built algorithm model files, such as instantaneous jump models, continuous jump models, and multi-signal logic operation models. This architecture of separating configuration data from algorithm logic is the foundation for the flexible configuration of this application's solution. When new vehicle condition data collection needs to be added, only the vehicle condition change table in the storage module needs to be updated, without modifying the underlying program code of the processing module.

[0206] The processing module 1002 is used to execute the functions in the various embodiments of the aforementioned data collection and reporting method.

[0207] The processing module can use high-performance MCUs (Microcontroller Units), etc.

[0208] During vehicle operation, the processing module reads the vehicle condition change table from the storage module, parses out the input parameters that need to be monitored, and configures the monitoring events for the vehicle communication interface accordingly. When a change in the vehicle signal is detected, the processing module calls the corresponding vehicle condition model from the storage module to perform logical operations, determines whether the reporting conditions are met, and sends the valid vehicle condition information to the vehicle networking platform through the communication module. During execution, the processing module frequently interacts with the storage module, including reading configurations, calling models, and writing updated configuration tables. Through the collaborative work of the storage module and the processing module,

[0209] It should be noted that the specific implementation and explanation of the function of this processing module can be found in the explanations in the aforementioned method embodiments, and will not be repeated here.

[0210] In this embodiment, the vehicle-mounted terminal includes a storage module and a processing module. The storage module stores a vehicle condition change table and at least two vehicle condition models. The processing module listens to vehicle signals based on input parameters in the vehicle condition change table, matches the corresponding target vehicle condition model based on the mapping relationship within the table, processes the listened data to obtain vehicle condition information, and completes vehicle condition reporting when the reporting conditions are met. By using the vehicle condition change table, the vehicle condition collection logic is decoupled from the code layer, achieving decoupling between logic and data. This prevents the vehicle condition collection and judgment logic from being coupled to the TBOX firmware in the form of fixed code, avoiding the need to develop customized code for different vehicle conditions. The vehicle condition collection capability can be updated and expanded without modifying the firmware program, effectively improving the universality of the vehicle condition judgment logic, the standardization of the collection process, and the iterative efficiency and execution stability of vehicle condition collection and reporting. This vehicle-mounted terminal can support the configurable logic at the software level with its hardware architecture, realizing rapid iteration and flexible expansion of the vehicle condition collection function.

[0211] Please see Figure 11 , Figure 11 This is a structural schematic diagram of a vehicle provided in an embodiment of this application. Specifically, the vehicle can be a fuel-powered vehicle, an electric vehicle, or a hybrid vehicle, or other intelligent connected vehicle with network connectivity. Figure 11 As shown, the vehicle 1100 includes: a main body 1101 and an on-board terminal 1102 disposed on the main body;

[0212] The vehicle-mounted terminal 1102 is used to perform the functions in the various embodiments of the aforementioned data collection and reporting method.

[0213] The vehicle body refers to the physical carrier of the vehicle, including basic hardware facilities such as the body, chassis, powertrain, and electrical system. As the core connected component of the vehicle, the on-board terminal is usually integrated and installed in the interior space of the vehicle body, such as below the dashboard, inside the center console, or on the side wall of the trunk. It establishes a communication connection with various electronic control units within the vehicle body through the vehicle bus, thereby obtaining real-time vehicle operating status data.

[0214] The vehicle bus may include CAN bus, LIN (Local Interconnect Network) bus, or in-vehicle Ethernet, etc.

[0215] In this embodiment, the vehicle-mounted terminal is used to execute the data collection and reporting method. When the vehicle is started and in operation, the vehicle-mounted terminal listens to vehicle signals through the vehicle bus, dynamically calls the matching vehicle condition model to perform logical operations based on the locally stored vehicle condition change table, and reports the vehicle condition information to the vehicle network platform when the conditions are met.

[0216] It should be noted that the specific implementation and explanation of the functions of the vehicle terminal can be found in the explanations in the aforementioned method embodiments, and will not be repeated here.

[0217] In this embodiment, the vehicle includes a main body and an on-board terminal. The on-board terminal listens to vehicle signals based on input parameters in the vehicle condition change table, matches the corresponding target vehicle condition model based on the mapping relationship in the table, processes the listened data to obtain vehicle condition information, and completes vehicle condition reporting when the reporting conditions are met. By using the vehicle condition change table, the vehicle condition collection logic is separated from the code layer, achieving decoupling of logic and data. This prevents the vehicle condition collection and judgment logic from being coupled to the TBOX firmware in the form of fixed code, avoiding the need to develop customized code for different vehicle conditions. The vehicle condition collection capability can be updated and expanded without modifying the firmware program, effectively improving the universality of the vehicle condition judgment logic, the standardization of the collection process, and the iterative efficiency and execution stability of vehicle condition collection and reporting. By integrating the on-board terminal with configurable collection and reporting functions into the vehicle main body, the vehicle product has the flexible iteration capability of the vehicle condition collection logic. When the operation side has a new vehicle condition collection requirement, it only needs to send an updated vehicle condition change table to the vehicle, and the vehicle can quickly respond and execute the new collection strategy without system firmware OTA upgrade. This not only significantly shortens the cycle of vehicle function iteration and reduces software maintenance costs, but also greatly improves the intelligence level and user experience of vehicle products, enhancing the product's competitiveness in the market.

[0218] To more intuitively demonstrate the actual operational effect of the technical solution of the present invention, this application provides an application scenario for door status monitoring and provides a detailed description of the process for collecting and reporting changes in vehicle condition.

[0219] In this scenario, operators need to add a requirement to monitor the unlock status of the left front door on the vehicle networking platform.

[0220] First, the vehicle network cloud platform generates or updates the vehicle status change table, adding a configuration record to the table. This record defines the vehicle status identifier to be collected as Door_Status_FL, the mapped vehicle status model as the instantaneous jump model, the vehicle status model code is model01, the input parameters include the vehicle status code Door_Status_FL and its corresponding operating parameter CAN signal ID is 0x3F1, and the output parameter is the current door status value.

[0221] Once the vehicle is started, the on-board terminal listens to the vehicle signals based on the input parameters in the vehicle condition change table stored in the vehicle, and obtains the listening data.

[0222] The onboard terminal's processing module reads the vehicle status change table and parses out the input parameters that need to be monitored. Based on the vehicle status code Door_Status_FL recorded in the vehicle status change table corresponding to each input parameter, the processing module queries its internal preset mapping table to determine that the operating parameter corresponding to this vehicle status code is CAN signal ID0x3F1. Subsequently, the processing module registers a monitoring event for this operating parameter with the vehicle bus interface.

[0223] When a user presses the remote key to unlock the vehicle while it is in operation, the value of the CAN signal ID0x3F1 on the vehicle bus instantly changes from locked state 0 to unlocked state 1. A monitoring event is triggered, this change is captured, and monitoring data is generated.

[0224] Based on the mapping relationship in the vehicle condition change table, the target vehicle condition model is determined. The processing module extracts the operating parameter 0x3F1 corresponding to the monitored data and searches the vehicle condition change table for a vehicle condition model whose input parameter matches this operating parameter. The table lookup result shows that the vehicle condition model corresponding to this input parameter is an instantaneous jump model, which the system identifies as the target vehicle condition model. The change in the input parameter of the instantaneous jump model represents an instantaneous state switch; that is, as long as a change in the signal value is detected, the condition is considered met.

[0225] The target vehicle condition model is invoked to process the monitored data and obtain vehicle condition information indicating a change in vehicle condition. The processing module obtains the current signal value 1 from the monitored data as input data based on the input parameters corresponding to the target vehicle condition model. The input data is input into the instantaneous transition model, and the internal logic of the model determines that the input data has transitioned relative to the previous state (0), satisfying the vehicle condition change condition condition, and outputs vehicle condition information containing the current state 1.

[0226] When the vehicle condition information meets the reporting conditions of the corresponding vehicle condition model, the corresponding vehicle condition information is reported to the vehicle network platform. Since the judgment logic of the instantaneous jump model has been met, the processing module immediately encapsulates the vehicle condition information into a reporting message and sends it to the vehicle network platform, realizing millisecond-level response reporting of the door unlock status.

[0227] To more intuitively demonstrate the actual operational effect of the technical solution of this invention, this application also provides an application scenario for seat heating monitoring and provides a detailed description of the process for collecting and reporting changes in vehicle condition.

[0228] In this scenario, assume that the status of the driver's seat heating needs to be monitored. The configuration record in the vehicle condition change table defines the vehicle condition code as Seat_Heat_Driver, the mapped vehicle condition model is a continuously changing model, the vehicle condition model code is model02, and the input parameters include operating parameters, which can be signal ID0x4A2, target state value of 1 representing heating on, and duration.

[0229] Similarly, the vehicle terminal monitors signal ID0x4A2 based on the configuration in the vehicle condition change table. When the user activates the seat heating function, the value of signal ID0x4A2 changes to 1. The monitoring event is triggered, and monitoring data is generated.

[0230] The processing module determines the target vehicle condition model as a continuously changing model based on the vehicle condition change table. The input parameters for this model must remain unchanged for a set duration. When this model is called to process monitored data, its internal timing logic is activated. The continuously changing model starts timing after detecting a signal value changing to 1. If the signal value remains unchanged at 1 for the set 3 seconds, the vehicle condition change condition is deemed met, and vehicle condition information is generated and reported. Conversely, if the signal value changes back to 0 within 3 seconds due to jitter or accidental activation, the model determines that the condition is not met and no vehicle condition information is generated.

[0231] This application also provides a computer program product including computer-readable instructions, which, when executed on a vehicle's onboard terminal, enable the onboard terminal to implement any of the vehicle skidding prediction and control methods provided in this application.

[0232] This application embodiment also provides a vehicle-mounted terminal, including at least one processor and a memory connected to the processor, wherein:

[0233] Memory is used to store computer programs;

[0234] The processor is used to execute computer programs, enabling the vehicle terminal to implement any of the vehicle skidding prediction and control methods provided in the embodiments of this application.

[0235] This application also provides a computer-readable storage medium carrying one or more computer programs. When the one or more computer programs are executed by the vehicle's on-board terminal, the on-board terminal can implement any of the vehicle skidding prediction and control methods provided in this application.

[0236] It is understood that before using the technical solutions disclosed in the various embodiments of the present invention, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in the present invention and their authorization should be obtained in accordance with relevant laws and regulations through appropriate means.

[0237] It is understood that the data involved in this technical solution (including but not limited to the data itself, the acquisition or use of the data) shall comply with the requirements of relevant laws, regulations and related provisions.

[0238] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the accompanying drawings of the device embodiments provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0239] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods of the various embodiments of this application.

[0240] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0241] A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

Claims

1. A data collection reporting method, characterized in that, include: Based on the input parameters in the vehicle condition change table stored in the vehicle, the vehicle signal is monitored to obtain monitoring data, and the monitoring data corresponds to at least one input parameter; The vehicle condition change table contains the mapping relationship between the vehicle condition to be collected and at least two vehicle condition models. Each vehicle condition model has at least one input parameter that represents the vehicle condition to be collected. Based on the mapping relationship in the vehicle condition change table, the target vehicle condition model is determined, and the input parameters of the target vehicle condition model correspond to the monitoring data; The target vehicle condition model is invoked to process the monitoring data and obtain vehicle condition information that represents a change in the vehicle's condition. The vehicle condition information corresponds to the monitoring data. The vehicle condition information output by the target vehicle condition model is reported to the vehicle network platform.

2. The data acquisition and reporting method according to claim 1, characterized in that, The determination of the target vehicle condition model based on the mapping relationship in the vehicle condition change table includes: Determine the operating parameters corresponding to the monitored data; Based on the operating parameters corresponding to the monitored data, a vehicle condition model whose input parameters match the operating parameters is searched in the vehicle condition change table as the target vehicle condition model.

3. The data acquisition and reporting method according to claim 2, characterized in that, The step of searching the vehicle condition table for a vehicle condition model whose input parameters match the operating parameters based on the monitoring data as the target vehicle condition model includes: Based on the operating parameters, determine the corresponding input parameters in the vehicle condition change table; Among the at least two vehicle condition models recorded in the vehicle condition change table, the vehicle condition model corresponding to the input parameters is determined as the target vehicle condition model; The at least two vehicle condition models include an instantaneous jump model, a continuous jump model, and a multi-signal logic operation model; the change of the input parameters of the instantaneous jump model is an instantaneous state switch, the input parameters of the continuous jump model need to be maintained for a set duration, and the input parameters of the multi-signal logic operation model are multiple signals with logical operation relationships.

4. The data acquisition and reporting method according to claim 3, characterized in that, The step of determining the vehicle condition model corresponding to the input parameters as the target vehicle condition model from at least two vehicle condition models recorded in the vehicle condition change table includes: Among at least two vehicle condition models recorded in the vehicle condition change table, determine the locally existing optional vehicle condition models. The vehicle condition change table includes locally existing optional vehicle condition models and locally non-optional vehicle condition models. The optional vehicle condition model corresponding to the input parameters is determined as the target vehicle condition model.

5. The data acquisition and reporting method according to claim 1, characterized in that, Based on the input parameters in the vehicle condition change table stored in the vehicle database, the vehicle signals are monitored to obtain the monitoring data, including: Identify each vehicle condition code recorded in the vehicle condition change table, with each vehicle condition code corresponding to at least one input parameter; Based on the preset correspondence between vehicle condition codes and input parameters, the operating parameters corresponding to the vehicle condition codes are determined, and the operating parameters correspond to the input parameters; The vehicle signals are monitored based on the aforementioned operating parameters to obtain monitoring data.

6. The data acquisition and reporting method according to claim 1, characterized in that, The process of calling the target vehicle condition model, processing the monitored data, and obtaining vehicle condition information representing changes in vehicle condition includes: Based on the input parameters corresponding to the target vehicle condition model, data corresponding to the input parameters is obtained from the monitoring data as input data; The input data is input into the target vehicle condition model to obtain vehicle condition information. The vehicle condition information indicates that the input data meets the vehicle condition change conditions of the target vehicle condition model, and the vehicle condition information is at least a part of the input data.

7. The data acquisition and reporting method according to claim 1, characterized in that, Also includes: After the vehicle is started, an update request carrying a version identifier of the local vehicle condition change table is sent to the vehicle network platform so that the vehicle network platform can determine whether there is a vehicle condition change table to be updated based on the version identifier of the update request. If the feedback information indicates that there is no vehicle condition change table to be updated, the vehicle condition change table currently stored in the vehicle shall be used as the standard, and the vehicle signal shall be monitored based on the input parameters in the vehicle condition change table stored in the vehicle to obtain the monitoring data. If the feedback information includes a vehicle condition change table to be updated, update the vehicle condition change table stored in the vehicle according to the received vehicle condition change table; Based on the updated vehicle condition change table, the steps described above are executed to monitor vehicle signals and obtain monitoring data, according to the input parameters in the vehicle condition change table stored in the vehicle.

8. The data acquisition and reporting method according to claim 1, characterized in that, Also includes: In response to the remote update command from the vehicle networking platform, obtain the update data packet from the vehicle networking platform; The update data packet is parsed to obtain the vehicle condition model to be updated; Store the vehicle condition model to be updated in a preset storage location; Update the vehicle condition change table to include the relevant configuration of the vehicle condition model to be updated.

9. A vehicle-mounted terminal, comprising: The storage module is used to store the vehicle condition change table and at least two vehicle condition models; The vehicle condition change table contains the mapping relationship between the vehicle condition to be collected and at least two vehicle condition models. Each vehicle condition model has at least one input parameter that represents the vehicle condition to be collected. The processing module is used to execute the data acquisition and reporting method according to any one of claims 1 to 8.

10. A vehicle comprising: ontology; The vehicle-mounted terminal installed on the main body is used to execute the data collection and reporting method according to any one of claims 1 to 8.

Images