Vehicle data reporting method and device and vehicle-mounted terminal
By acquiring and parsing the vehicle condition configuration file generated by the vehicle networking terminal, the data upload process of the vehicle terminal is optimized, solving the problem of long upload cycles for vehicle condition data by the vehicle terminal and achieving efficient and accurate data transmission.
Patent Information
- Application Number
- CN202511886064.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-12
- Publication Date
- 2026-02-17
AI Technical Summary
In existing technologies, the cycle for vehicle-mounted terminals to upload vehicle status data to vehicle network terminals is relatively long, requiring updates to communication protocols and software, resulting in low data transmission efficiency.
By acquiring the target vehicle condition configuration file generated by the vehicle networking terminal, parsing the vehicle model index information and vehicle condition data type, obtaining the appropriate vehicle condition data from the vehicle condition database, and uploading it to the vehicle networking terminal, the data transmission is optimized using wireless communication and data compression technologies.
This shortens the vehicle status data reporting cycle from the vehicle terminal to the vehicle network terminal, improves data transmission efficiency and accuracy, and reduces communication costs.
Smart Images

Figure CN121547482A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of vehicle technology, specifically to a method, device, and vehicle-mounted terminal for reporting vehicle data. Background Technology
[0002] Currently, the T-BOX (Telematics BOX, in-vehicle terminal) and TSP (Telematics Service Provider, vehicle-to-everything terminal) communicate using a fixed communication protocol. When new vehicle condition data needs to be uploaded, the communication protocol, TSP software, and T-BOX software all need to be updated. Under this update method, the in-vehicle terminal not only needs to upload the new vehicle condition data but also needs to package and upload historical vehicle condition data together, resulting in a long reporting cycle for vehicle condition data transmitted from the in-vehicle terminal to the vehicle-to-everything terminal. Summary of the Invention
[0003] In view of the above problems, embodiments of the present invention provide a method, device and vehicle terminal for reporting vehicle data, which are used to solve the problem of long reporting cycle of vehicle condition data transmitted from vehicle terminal to vehicle network terminal in the prior art.
[0004] According to one aspect of the present invention, a method for reporting vehicle data is provided, the method comprising: Obtain the target vehicle condition configuration file; Parse the target vehicle condition configuration file to obtain the vehicle model index information and vehicle condition data type; Retrieve target vehicle condition data from the vehicle condition database that matches the vehicle model index information and vehicle condition data type; Upload the target vehicle condition data to the vehicle networking terminal.
[0005] According to another aspect of the present invention, a vehicle data reporting device is provided, the reporting device being installed in an in-vehicle terminal, comprising: The acquisition module is used to acquire the target vehicle condition configuration file, which is generated by the vehicle networking terminal and sent to the vehicle terminal. The processing module is used to parse the target vehicle condition configuration file to obtain the vehicle model index information and vehicle condition data type; and to retrieve the target vehicle condition data that matches the vehicle model index information and vehicle condition data type from the vehicle condition database. The upload module is used to upload target vehicle condition data to the vehicle network terminal.
[0006] According to another aspect of the present invention, a vehicle-mounted terminal is provided, comprising: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other via the communication bus; the memory is used to store at least one executable instruction, which causes the processor to perform the following operations: Obtain the target vehicle condition configuration file; Parse the target vehicle condition configuration file to obtain the vehicle model index information and vehicle condition data type; Retrieve target vehicle condition data from the vehicle condition database that matches the vehicle model index information and vehicle condition data type; Upload the target vehicle condition data to the vehicle networking terminal.
[0007] According to another aspect of the present invention, a vehicle data reporting system is provided, including a vehicle network terminal; and the aforementioned in-vehicle terminal, wherein the in-vehicle terminal and the vehicle network terminal are connected for communication via a communication interface.
[0008] According to another aspect of the present invention, a computer-readable storage medium is provided, wherein the storage medium stores at least one executable instruction, the executable instruction causing an on-board terminal to perform the following operations: Obtain the target vehicle condition configuration file; Parse the target vehicle condition configuration file to obtain the vehicle model index information and vehicle condition data type; Retrieve target vehicle condition data from the vehicle condition database that matches the vehicle model index information and vehicle condition data type; Upload the target vehicle condition data to the vehicle networking terminal.
[0009] This invention provides an embodiment of the invention that obtains a target vehicle condition configuration file generated by a vehicle-to-everything (V2X) terminal via an in-vehicle terminal. This configuration file contains specific vehicle model index information and vehicle condition data types. Using this index information and data types, suitable vehicle condition data can be retrieved from a vehicle condition database and fed back to the V2X terminal. Compared to related technologies, because the vehicle model index information and data types associated with the vehicle condition data can be configured via the V2X terminal, specific vehicle condition data can be obtained, reducing the amount of vehicle condition data transmitted from the in-vehicle terminal to the V2X terminal, thereby shortening the reporting cycle of vehicle condition data from the in-vehicle terminal to the V2X terminal.
[0010] The above description is merely an overview of the technical solutions of the embodiments of the present invention. In order to better understand the technical means of the embodiments of the present invention and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description
[0011] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A flowchart illustrating a first embodiment of the vehicle data reporting method provided by the present invention is shown. Figure 2 A flowchart illustrating a second embodiment of the vehicle data reporting method provided by the present invention is shown. Figure 3 A schematic diagram of the structure of a first embodiment of the vehicle data reporting device provided by the present invention is shown. Figure 4 A schematic diagram of an embodiment of the vehicle-mounted terminal provided by the present invention is shown. Detailed Implementation
[0012] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein.
[0013] Figure 1 A flowchart of a first embodiment of the vehicle data reporting method of the present invention is shown, which is executed by an on-board terminal. Figure 1 As shown, the method includes the following steps: Step 110: Obtain the target vehicle condition configuration file, wherein the target vehicle condition configuration file is generated by the vehicle networking terminal and sent to the vehicle terminal.
[0014] The target vehicle condition configuration file is a file generated by the vehicle-to-everything (V2X) terminal according to specific needs and rules. This file contains relevant configuration information about the target vehicle's condition, guiding the onboard terminal to acquire and process specific vehicle condition data. A configuration tool for the vehicle condition configuration file is installed in the V2X terminal, allowing for vehicle condition configuration and output of the configuration file. The target vehicle condition configuration file includes multiple configuration fields, each a key-value pair. These fields can include vehicle condition data type, vehicle model index information, protocol type, etc.
[0015] It should be noted that different vehicle models can use a unified template configuration to generate the target vehicle condition profile. In this case, the template needs to cover the vehicle condition signals of all models. The vehicle condition signals that different models need to report are often different. For vehicle condition states that do not need to be reported for a certain model, the non-reportable vehicle condition state can be set to "null". In this way, all models can share a single vehicle condition profile, reducing the configuration cost of the vehicle condition profile.
[0016] For example, the target vehicle condition profile can be represented as: { "propertyName":"Pure electric driving range", "propertyCode":"eVEstimatedRang", "dataType":"int32", "min":0, "max":2047, "offset":0, "precision":1, "description":null, "report Type": "onchange or cycle"}.
[0017] As can be seen from the above example, the description of a certain car model does not need to be reported and can be set to null.
[0018] Different vehicle models can use different templates to generate target vehicle condition profiles. In this case, vehicle condition profiles can be customized for different vehicle models, and can be generated according to actual needs.
[0019] In one feasible implementation, the vehicle-to-everything (V2X) terminal can send the target vehicle condition configuration file to the vehicle-mounted terminal in the form of data packets via a wireless communication network such as 4G / 5G. The vehicle-mounted terminal receives the data packets through its built-in communication module and parses them to obtain the target vehicle condition configuration file. This method enables fast and stable transmission of the configuration file to the vehicle-mounted terminal, ensuring that the vehicle-mounted terminal obtains the latest vehicle condition configuration requirements in a timely manner, thus improving the real-time performance and reliability of data acquisition.
[0020] In another feasible implementation, the vehicle-to-everything (V2X) terminal and the in-vehicle terminal can connect via short-range wireless communication technologies such as Bluetooth or Wi-Fi, with the V2X terminal transmitting the target vehicle condition configuration file to the in-vehicle terminal. Because short-range wireless communication technologies are characterized by low power consumption and low cost, they can effectively reduce communication costs in short-range transmission scenarios while ensuring data transmission accuracy, making them suitable for data transmission between devices within the vehicle.
[0021] In another feasible implementation, the vehicle-to-everything (V2X) terminal can compress and encrypt the target vehicle condition configuration file before sending it to the in-vehicle terminal. After receiving the data sent by the in-vehicle terminal, the in-vehicle terminal decrypts and decompresses the data to obtain the target vehicle condition configuration file. During the encryption and compression process of the generated target vehicle condition configuration file, the V2X terminal can use appropriate encryption and compression methods based on the data type of each configuration field in the file. For example, for numeric configuration fields, a lightweight symmetric encryption method can be used, coupled with differential encoding for compression. For string configuration fields, AES-128 CBC mode with Base64 encoding can be used for encryption, coupled with LZ77 lightweight compression. Similarly, appropriate decryption and decompression methods can be adaptively selected based on the encryption and compression methods. This approach improves the security and data transmission efficiency of the target vehicle condition configuration file between the in-vehicle terminal and the V2X terminal.
[0022] Step 120: Parse the target vehicle condition configuration file to obtain the vehicle model index information and vehicle condition data type.
[0023] Among them, vehicle model index information is key information used to identify and distinguish different vehicle models. It can be a unique number of the vehicle model, a specific code, or a series of feature combinations that can accurately point to a certain vehicle model. Through vehicle model index information, the relevant data of the corresponding vehicle model can be quickly located.
[0024] Among them, vehicle condition data refers to different types of data related to vehicle condition, such as engine speed, vehicle speed, fuel consumption, water temperature, tire pressure, etc. Different types of vehicle condition data reflect different aspects of the vehicle's operating status.
[0025] In one feasible implementation, the in-vehicle terminal uses a specific parsing algorithm to parse the target vehicle condition configuration file. This algorithm extracts the vehicle model index information and vehicle condition data types contained within the configuration file based on its format and encoding rules. For example, if the configuration file is in JSON format, the parsing algorithm can parse the data structure layer by layer according to JSON syntax rules to obtain the required information. Through a precise parsing algorithm, key information can be accurately extracted from the configuration file, providing an accurate basis for subsequently obtaining target vehicle condition data and avoiding the acquisition of incorrect vehicle condition data due to information extraction errors.
[0026] Step 130: Obtain target vehicle condition data from the vehicle condition database that matches the vehicle model index information and vehicle condition data type.
[0027] The vehicle condition database is a dedicated database system for storing and managing vehicle condition data. It organizes this data according to specific data structures and rules to enable efficient storage, retrieval, and updates. The data stored in this database can be uploaded in real-time by various electronic control units of the vehicle. When data is stored in the database, the storage time is recorded and a storage duration is set. Once the storage duration is reached, the data is deleted to reduce the data storage pressure on the database.
[0028] The target vehicle condition data is selected from the vehicle condition database based on the vehicle model index information and vehicle condition data type specified in the target vehicle condition configuration file, and meets specific requirements.
[0029] In one feasible implementation, the vehicle condition database can store vehicle model index information, vehicle condition data types, and mapping relationships with target vehicle condition data. Based on this mapping relationship, vehicle model index information, and vehicle condition data types, the required target vehicle condition data can be obtained. The vehicle terminal sends a query request to the vehicle condition database using a database query statement, such as an SQL statement, specifying the vehicle model index information and vehicle condition data type as query conditions. The database then filters the stored data according to these conditions, selects the target vehicle condition data that meets the requirements, and returns it to the vehicle terminal. By utilizing the database's query function, the required target vehicle condition data can be quickly and accurately located from a large amount of vehicle condition data, improving the efficiency and accuracy of data acquisition and meeting the need for real-time vehicle condition data acquisition.
[0030] In another feasible implementation, data caching technology can be used to cache vehicle condition data for some commonly used models on the in-vehicle terminal or vehicle condition database server. When the target vehicle condition data is needed, it is first searched in the cache. If data matching the vehicle model index information and vehicle condition data type exists in the cache, it is retrieved directly from the cache; otherwise, it is queried from the database. Data caching technology can reduce frequent access to the database, lower the database load, and improve the response speed of data retrieval. Especially for frequently queried vehicle condition data, it can significantly improve system performance.
[0031] Step 140: Upload the target vehicle condition data to the vehicle network terminal.
[0032] In one feasible implementation, the in-vehicle terminal encapsulates the target vehicle condition data into data packets via a wireless communication network such as 4G / 5G and sends them to the vehicle-to-everything (V2X) terminal according to a specific communication protocol. The V2X terminal receives the data packets, unpacks and verifies them to ensure data integrity and accuracy. By leveraging wireless communication networks to remotely upload data, vehicle condition data can be transmitted to the V2X terminal in a timely manner, enabling the V2X platform to monitor the vehicle's operating status in real time and providing data support for vehicle management, fault warnings, and other functions.
[0033] In another feasible implementation, data compression technology can be used to compress the target vehicle condition data before uploading it to the vehicle-to-everything (V2X) terminal. During the upload process, the V2X terminal receives the compressed data and decompresses it to restore the original data. Because data compression technology can reduce data transmission volume and communication costs, especially when network bandwidth is limited, it can improve data transmission efficiency and ensure that vehicle condition data can be transmitted to the V2X terminal in a timely and complete manner.
[0034] It should be noted that uploading the target vehicle condition data to the vehicle network terminal can facilitate the monitoring and management of the vehicle's operation by the vehicle network terminal user, or enable vehicle fault diagnosis when a vehicle malfunctions.
[0035] In this embodiment, the target vehicle condition configuration file generated by the vehicle-to-everything (V2X) terminal is obtained through the in-vehicle terminal. This target vehicle condition configuration file contains specific vehicle model index information and vehicle condition data types. Using this vehicle model index information and vehicle condition data types, suitable vehicle condition data can be retrieved from the vehicle condition database and fed back to the V2X terminal. Compared to related technologies, because the vehicle model index information and vehicle condition data types associated with the vehicle condition data can be configured through the V2X terminal, specific vehicle condition data can be obtained, reducing the amount of vehicle condition data transmitted from the in-vehicle terminal to the V2X terminal, thereby shortening the reporting cycle of vehicle condition data from the in-vehicle terminal to the V2X terminal.
[0036] In one alternative approach, step 110 includes: Step 111: parse the vehicle condition data acquisition request sent by the vehicle network terminal to obtain the vehicle condition configuration file and the version information of the vehicle condition configuration file.
[0037] Version information is used to identify different versions of the vehicle condition configuration file. It can be in the form of a numerical code, a timestamp, or a specific version string. Version information allows for accurate differentiation of vehicle condition configuration files from different periods and with different content, making it easier for the system to determine whether the configuration file is the latest version or needs to be updated.
[0038] In one feasible implementation, the vehicle condition data acquisition request sent by the vehicle-to-everything (V2X) terminal follows a specific communication protocol. The vehicle terminal can use a parsing library corresponding to that protocol to parse the request data. For example, if the request is based on the HTTP protocol, the parsing library corresponding to that protocol can be used to parse the request header and request body, extracting the vehicle condition configuration file and its version information. Because the protocol parsing library is targeted and efficient, it can accurately parse the request data according to the protocol specifications, ensuring that the obtained vehicle condition configuration file and version information are complete and accurate, providing a reliable basis for subsequent version comparison and configuration file selection.
[0039] In another feasible implementation, a custom parsing function can be written. Developers write a dedicated parsing function based on the format and encoding rules of the vehicle condition data acquisition request. This function parses the request data byte-by-byte or field-by-field according to predetermined logic, separating the vehicle condition configuration file and version information. Custom parsing functions offer flexibility and customizability, allowing for precise adjustments based on actual needs to adapt to request data of different formats and complexities, thus improving the accuracy and adaptability of the parsing.
[0040] Step 112: If the version information is inconsistent with the version information of the initial vehicle condition configuration file currently cached in the vehicle terminal, the vehicle condition configuration file shall be used as the target vehicle condition configuration file.
[0041] In one feasible implementation, a version comparison module is set up in the microprocessor unit of the vehicle terminal. This module reads the version information of the vehicle condition configuration file sent by the vehicle networking terminal and the version information of the initial vehicle condition configuration file cached by the vehicle terminal. It uses string comparison or a specific version number comparison algorithm, such as splitting the version number into numbers for step-by-step comparison, to determine whether the two are consistent. If they are inconsistent, the version comparison module triggers an update mechanism, overwriting the initial vehicle condition configuration file with the newly received vehicle condition configuration file, which becomes the target vehicle condition configuration file. The version comparison module can automatically and accurately complete the version information comparison and configuration file update operations, ensuring that the vehicle terminal always uses the latest version of the vehicle condition configuration file, thereby obtaining vehicle condition data that best matches the current vehicle status and needs, improving the accuracy and practicality of vehicle condition data acquisition.
[0042] In another feasible implementation, the version information of the initial vehicle condition configuration file can be stored in the database of the vehicle terminal. When a vehicle condition configuration file and its version information are received from the vehicle network terminal, the initial version information is retrieved from the database for comparison. If they are inconsistent, the relevant information of the new configuration file is updated in the database through database operations and used as the target vehicle condition configuration file for subsequent use. The database has powerful data storage and management capabilities, enabling convenient querying, updating, and persistent storage of version information. Using a database to manage version information can improve data security and reliability, while also facilitating the traceability and management of historical version information.
[0043] Step 113: If the version information is consistent with the version information of the initial vehicle condition configuration file currently cached in the vehicle terminal, the initial vehicle condition configuration file shall be used as the target vehicle condition configuration file.
[0044] The initial vehicle condition configuration file is a cached configuration file on the in-vehicle terminal in its initial state. It serves as a benchmark file for subsequent version comparisons with newly received vehicle condition configuration files. This file contains vehicle condition-related configuration information for all vehicle models, guiding the in-vehicle terminal in acquiring and processing vehicle condition data. This initial vehicle condition configuration file can be pre-synchronized to the in-vehicle terminal offline, such as by sending it locally via email. This initial vehicle condition configuration file ensures that vehicle condition data can be obtained even in scenarios where vehicle condition data acquisition is abnormal.
[0045] In one feasible implementation, a conditional statement is included in the version comparison logic. When the version comparison module finds that the vehicle condition configuration file version information sent by the vehicle network terminal is consistent with the initial vehicle condition configuration file version information, the conditional statement directly returns the initial vehicle condition configuration file as the target vehicle condition configuration file, without requiring an update operation. This simple conditional statement quickly determines whether an update to the configuration file is needed, avoiding unnecessary file writing and system resource consumption, thus improving system efficiency. It is particularly suitable for scenarios that frequently receive vehicle condition data acquisition requests but where the configuration file version changes infrequently.
[0046] In another feasible implementation, the vehicle terminal's caching system manages the initial vehicle condition configuration file. When comparing versions, the caching management system determines whether the cache needs to be updated based on the version information. If the versions match, the caching management system directly provides the initial vehicle condition configuration file in the cache as the target vehicle condition configuration file for subsequent processes. This caching management mechanism efficiently manages the configuration file cache, reducing frequent read and write operations on storage devices. Furthermore, directly retrieving the target vehicle condition configuration file from the cache improves data retrieval speed and enhances system response performance.
[0047] In this embodiment, the version information of the vehicle condition configuration file is compared with the version information of the initial vehicle condition configuration file to update the version of the vehicle condition configuration file. Subsequently, vehicle condition data can be obtained in real time based on the updated vehicle condition configuration file, improving the convenience and efficiency of vehicle condition data acquisition.
[0048] In an alternative approach, step 130 includes: Step 131: Extract vehicle condition data associated with the vehicle model index information from the vehicle condition database.
[0049] In one feasible implementation, indexes can be created in the vehicle condition database for fields related to vehicle model index information. This allows the database to quickly locate data records containing the specified vehicle model index information during queries. A database caching mechanism is used to cache frequently queried vehicle model index information and its associated vehicle condition data in memory. When a query request for the same vehicle model index information is received again, the data is retrieved directly from the cache without accessing the disk database again. Database indexes can significantly improve data query speed and reduce disk I / O operations. The caching mechanism can further reduce the number of disk database accesses, especially when frequently querying the same vehicle model index information, greatly improving data retrieval efficiency and reducing system response time.
[0050] Step 132: Based on the vehicle condition data type, perform semantic transformation on the extracted vehicle condition data to obtain target vehicle condition data that matches the vehicle condition data type.
[0051] Semantic conversion refers to the process of transforming one semantic representation of data into another related and compatible semantic representation. In the context of vehicle condition data processing, this involves adjusting and converting the raw vehicle condition data extracted from the vehicle condition database according to the semantic rules and format requirements defined by the vehicle condition data type. This ensures that the data accurately and clearly expresses the information required by the vehicle condition data type, enabling more effective use and analysis of the data later.
[0052] In one feasible implementation, custom semantic conversion functions can be written based on the definition and requirements of vehicle condition data types. For example, if the vehicle condition data type requires converting engine speed data from "revolutions per second" to "revolutions per minute," the function can receive the original engine speed data (unit: revolutions per second) and then convert it to "revolutions per minute" by multiplying by 60. Simultaneously, the function can also adjust the data format, such as converting floating-point data to integer format. For instance, if the vehicle condition data only contains air conditioning fan speed settings 0-8, and the vehicle network terminal needs to obtain the air conditioning's on / off status, the vehicle terminal receiving setting 0 will convert it to "air conditioning off" and send it to the vehicle network terminal; receiving settings 1-7 will convert it to "air conditioning on." Custom semantic conversion functions offer high flexibility and specificity, allowing for precise semantic conversion based on different vehicle condition data types and business needs. Developers have complete control over the conversion logic and process, ensuring that the converted target vehicle condition data meets the expected requirements and satisfies various complex application scenarios.
[0053] In another feasible implementation, a semantic mapping table can be constructed, defining the semantic correspondence between the original vehicle condition data and the target vehicle condition data. For example, for tire pressure data, the semantic mapping table can specify that a certain numerical range in the original vehicle condition data corresponds to semantic descriptions such as normal, low, or high in the target data. During semantic transformation, the extracted original vehicle condition data is converted into corresponding target vehicle condition data with clear semantics by querying the semantic mapping table. The semantic mapping table provides an intuitive and easy-to-manage method for semantic transformation. By maintaining and updating the semantic mapping table, the rules for semantic transformation can be easily adjusted without modifying a large amount of code. This approach is suitable for scenarios where the semantic transformation rules are relatively fixed and easy to summarize, improving the efficiency and maintainability of semantic transformation.
[0054] In this embodiment, vehicle condition data is extracted from the vehicle condition database through vehicle model index information, and semantic transformation is performed on the vehicle condition data to obtain target vehicle condition data that matches the vehicle condition data type. In this way, the obtained vehicle condition data can meet expectations.
[0055] Furthermore, step 132 includes: Step 1321: Obtain the semantic features of the vehicle condition data and the target semantic features of the vehicle condition data type.
[0056] Semantic features refer to the inherent semantic attributes of vehicle condition data, reflecting the meaning and characteristics of the data within a specific business scenario and knowledge system. For example, for engine speed data, its semantic features may include the numerical range of the speed, the unit (revolutions per minute), and the engine operating state it represents, such as idling, medium speed, and high speed. These features collectively describe the significance of the data in terms of vehicle operating conditions.
[0057] Among them, target semantic features are the semantic attributes that the vehicle condition data type is expected to possess. They define the meaning and representation that the transformed target vehicle condition data should have. Taking engine speed data type as an example, target semantic features may stipulate that the data should be presented in a specific format, such as retaining two decimal places, and should be associated with the semantic level of engine operating efficiency assessment, such as high speed corresponding to a high efficiency range.
[0058] In one feasible implementation, a knowledge graph encompassing knowledge of vehicle operation and the meaning of vehicle condition data can be constructed. Using vehicle condition data as input, semantic features are extracted through reasoning and matching of entities, relationships, and attributes within the knowledge graph. For example, if the vehicle condition data is an engine speed of 2000 rpm, the knowledge graph may contain an association between the engine speed entity and the operating state entity. Through reasoning, the semantic feature of the corresponding operating state, such as medium-speed operation, can be derived. Similarly, for the target semantic features of the vehicle condition data type, the corresponding standard semantic description is retrieved from the knowledge graph. The knowledge graph integrates knowledge from multiple sources, providing rich semantic association information, making the extraction of semantic features more accurate and comprehensive. Through knowledge reasoning, deeper semantic information behind the data can be uncovered, contributing to a more precise understanding of vehicle condition data and the requirements of vehicle condition data types.
[0059] In another feasible implementation, a large number of labeled vehicle condition data samples can be collected, including vehicle condition data and its corresponding semantic features, as well as vehicle condition data types and their corresponding target semantic features. A machine learning model, such as a convolutional neural network or a recurrent neural network, is trained using these samples. After training, new vehicle condition data is input into the model, which can automatically extract the semantic features of the vehicle condition data and predict the target semantic features based on the vehicle condition data type. The machine learning model has strong adaptive capabilities, enabling it to learn complex semantic feature patterns from large amounts of data. Through training, the model can accurately extract semantic features from vehicle condition data of different types and formats, and can adapt to data changes and updates, improving the accuracy and efficiency of semantic feature acquisition.
[0060] Step 1322: Obtain the preset semantic transformation rules that associate semantic features with target semantic features.
[0061] Among them, the preset semantic transformation rules are a pre-defined set of rules used to guide how to transform vehicle condition data with specific semantic features into target vehicle condition data with target semantic features. These rules are formulated based on business logic, industry standards, or expert knowledge. For example, they stipulate that when the semantic feature of engine speed is displayed within a certain numerical range, unit conversion and state evaluation transformation are performed according to a specific formula to obtain data that conforms to the target semantic features.
[0062] In one feasible implementation, a pre-defined semantic transformation rule base can be established. This rule base uses combinations of semantic features and target semantic features as indexes to store corresponding transformation rules. For example, the rule base might contain a rule: when the semantic feature of vehicle condition data is engine speed between 1500 and 2500 rpm (in rpm), and the target semantic feature is that the engine is in a stable medium-speed operating state, and the operating efficiency needs to be expressed as a percentage, the transformation rule is: Calculate operating efficiency = (current speed - 1500) / (2500 - 1500) * 100%. During transformation, the rule base is queried based on the extracted semantic features and target semantic features to obtain the corresponding pre-defined semantic transformation rule. The rule base query method is simple and direct, and easy to manage and maintain. By centrally storing and managing rules, it is convenient to add, modify, and delete rules, ensuring the consistency and accuracy of the rules. Simultaneously, the query process is efficient, enabling rapid retrieval of the required transformation rules.
[0063] In another feasible implementation, an ontology model for the vehicle condition domain can be constructed. This model defines vehicle condition data, semantic features, target semantic features, and the relationships and rules between them. Using an ontology inference engine, reasoning is performed within the ontology model based on the extracted semantic features and target semantic features to derive corresponding preset semantic transformation rules. For example, the ontology model might define rules regarding the relationship between engine speed and operating status, or the relationship between operating status and efficiency evaluation. Through reasoning, transformation rules from current semantic features to target semantic features can be derived. Ontology-based rule reasoning can leverage the structured knowledge and logical relationships of the ontology model for deeper and more accurate rule derivation. The ontology model clearly expresses the concepts and relationships in the vehicle condition domain, and the inference engine can automatically generate appropriate transformation rules based on these relationships, improving the intelligence and flexibility of rule acquisition.
[0064] Step 1323: Based on preset semantic conversion rules, convert vehicle condition data into target vehicle condition data that is compatible with the vehicle condition data type.
[0065] In one feasible implementation, specific conversion code is written using a programming language based on the obtained preset semantic conversion rules. For example, if the preset semantic conversion rule is to convert temperature data from Celsius to Fahrenheit, with the formula Fahrenheit = Celsius * 9 / 5 + 32, then the formula is implemented in the code to calculate the converted Fahrenheit temperature according to the rule based on the input Celsius temperature.
[0066] In another feasible implementation, the microprocessor unit application of the in-vehicle terminal provides a visual interface and configuration functions. Preset semantic transformation rules are configured into the microprocessor unit application in specific formats such as XML and JSON. Vehicle condition data is then input into the microprocessor unit application, which automatically transforms the data according to the configured rules and outputs target vehicle condition data adapted to the vehicle condition data type. The microprocessor unit application simplifies the data transformation process, eliminating the need for developers to write extensive code. Through the visual interface and configuration functions, users can easily set transformation rules, lowering the technical barrier.
[0067] In this embodiment, by using a preset semantic conversion rule between the semantic features of vehicle condition data and the target semantic features of the vehicle condition data type, the vehicle condition data is converted into target vehicle condition data that is compatible with the vehicle condition data type. In this way, the acquired vehicle condition data can be converted into the expected target vehicle condition data, thereby improving the readability and understandability of the target vehicle condition data.
[0068] In an alternative approach, step 140 includes: Step 141: Determine the data type corresponding to each field name in the target vehicle condition data.
[0069] In this context, field names refer to the names used to identify different data items in the target vehicle condition data. They act like labels, clearly defining the specific meaning of each data point. For example, in data describing the vehicle's engine status, there might be field names such as engine speed and engine temperature. These names clearly indicate which aspect of the engine each data item relates to.
[0070] In this context, data type refers to the type of data corresponding to a field name. It specifies the range of values, storage format, and operable operations of the data. Common data types include integer types (such as numerical values representing engine speed), floating-point types (such as precise numerical values representing engine temperature), string types (such as text information representing vehicle model), and boolean types (such as logical values indicating whether the vehicle is running).
[0071] In one feasible implementation, a data dictionary containing the names of vehicle condition data fields and their corresponding data types can be pre-built. This data dictionary can be stored in a database in tabular form or in a configuration file format such as JSON or XML. When processing target vehicle condition data, the corresponding data type can be quickly obtained by querying the data dictionary based on the field name. For example, the data dictionary might record that the engine speed field corresponds to an integer type, and the engine temperature field corresponds to a floating-point type. The data dictionary provides a centralized way to manage field names and data types, facilitating maintenance and updates. When it is necessary to add a new field or modify the data type, the corresponding operation can be performed in the data dictionary, improving the accuracy and efficiency of data type determination.
[0072] In another feasible implementation, a large number of labeled vehicle condition data samples can be collected, including field names and their corresponding data types. A machine learning model is trained using these samples. After training, the field names of the target vehicle condition data are input into the model, and the model infers the data type corresponding to each field name based on the learned patterns. The machine learning model can automatically learn features and patterns from the data, and can accurately infer the data type of some complex or irregular field names. As the amount of data increases and the model is continuously optimized, the accuracy of the inference will further improve, reducing the need for manual intervention.
[0073] Step 142: Obtain the encoding and storage methods associated with each data type.
[0074] The encoding method can be ProtoBuf binary encoding, which converts data into a binary sequence according to specific rules. This encoding method is efficient and compact, reducing the space occupied by data during network transmission and storage. For example, for integer types, ProtoBuf uses variable-length encoding based on the value size to save space.
[0075] In the ProtoBuf-based scenario, the storage method can be to store the encoded binary data in the file system, such as storing it as a binary file generated after compiling the .proto file, or to store it in a database, such as storing the binary data as a BLOB type field in a relational database, or in a non-relational database that supports binary data storage.
[0076] In one feasible implementation, a rule engine can be built, which defines mapping rules between different data types and their encoding and storage methods. Once the data type is determined, the rule engine performs matching to obtain the corresponding encoding and storage methods. The rule engine can centrally manage the mapping relationships between data types, encoding methods, and storage methods, facilitating unified management and modification. When it is necessary to adjust the encoding or storage method, only the rules in the rule engine need to be modified, improving the system's flexibility and maintainability.
[0077] Step 143: Based on the encoding method and storage method, encode and encapsulate the names of each field in the target vehicle condition data in sequence to obtain the encapsulated target vehicle condition data.
[0078] Based on the acquired encoding and storage methods, corresponding encoding and encapsulation functions can be written for each data type. For example, for integer data, a binary encoding function is written to convert the data to binary format, and a database encapsulation function is written to encapsulate the encoded data according to the storage format of a relational database. When processing target vehicle condition data, these functions are called sequentially to encapsulate and encapsulate the data corresponding to each field name. Writing dedicated functions enables modularization and reusability of encoding and encapsulation logic. Different data types can call corresponding functions for processing, improving code readability and maintainability. Furthermore, function encapsulation makes the encoding and encapsulation process more standardized and unified, reducing the possibility of errors.
[0079] Step 144: Upload the encapsulated target vehicle condition data to the vehicle network terminal.
[0080] In one feasible implementation, the encapsulated target vehicle condition data can be sent as a request body to a specified URL address of the vehicle-to-everything (V2X) terminal via the HTTP protocol. An appropriate content type is set in the request header so that the V2X terminal can correctly parse the data. Simultaneously, authentication information such as username and password, tokens, etc., can be added to ensure the security of data transmission. HTTP is a widely used network protocol, characterized by its simplicity, flexibility, and cross-platform compatibility. Uploading data using HTTP facilitates communication with various V2X terminals without the need for complex protocol development and configuration. Furthermore, HTTP supports multiple data formats and encryption methods, meeting the security and reliability requirements of data transmission.
[0081] In another feasible implementation, MQTT, a lightweight publish / subscribe messaging protocol, is suitable for use in IoT scenarios. MQTT clients are established on both the vehicle-to-everything (V2X) terminal and the in-vehicle terminal. The in-vehicle terminal, acting as the publisher, publishes encapsulated target vehicle condition data to a designated topic, while the V2X terminal, acting as the subscriber, subscribes to the topic and receives the data. The MQTT protocol supports reliable message transmission and quality control, adjusting message transmission quality based on network conditions.
[0082] In this embodiment, by obtaining the data types corresponding to each field name in the target vehicle condition data, and encoding and encapsulating the field names according to the encoding and storage methods corresponding to each data type, appropriate encoding and storage methods can be used to process different data types. Compared with a uniform encoding and storage method, this method can reduce the amount of target vehicle condition data, compress the target vehicle condition data, and thus reduce the data transmission overhead and data transmission pressure between the vehicle network terminal and the vehicle terminal.
[0083] Figure 2 A flowchart of another embodiment of the vehicle data reporting method of the present invention is shown, which is executed by an on-board terminal. Figure 2 As shown, the vehicle terminal includes a microcontroller unit, microprocessor unit core software, and microprocessor unit applications.
[0084] A microcontroller unit (MCU) is an integrated circuit chip that integrates a central processing unit (CPU), memory, input / output interfaces, and other functions onto a single chip. In automotive terminals, the MCU is primarily responsible for low-level, real-time control tasks, such as communicating with the electronic control unit (ECU), acquiring vehicle status signals, and performing preliminary processing and forwarding of these signals. It features low cost, low power consumption, and fast response speed, making it suitable for handling simple control logic and tasks with high real-time requirements.
[0085] The core software of the microprocessor unit is the core program running on the microprocessor unit. It is responsible for in-depth analysis of the vehicle condition signals forwarded from the microcontroller unit, converting the signals into understandable vehicle condition data, and performing data caching and management. This software undertakes the core functions of data processing and storage, providing accurate and reliable data support for subsequent applications.
[0086] Among them, the microprocessor unit application is a specific application developed on top of the microprocessor unit core software. It retrieves the required target vehicle condition data from the vehicle condition database according to specific business needs and performs further processing, analysis, and display operations. The microprocessor unit application can meet different user needs and achieve diverse functions, such as vehicle status monitoring and fault diagnosis.
[0087] Specifically, the method for reporting vehicle data in this application includes the following steps: Step 110: Obtain the target vehicle condition configuration file, wherein the target vehicle condition configuration file is generated by the vehicle networking terminal and sent to the vehicle terminal.
[0088] Step 120: Parse the target vehicle condition configuration file to obtain the vehicle model index information and vehicle condition data type.
[0089] In one feasible approach, the microprocessor unit can acquire a target vehicle condition configuration file and parse it to obtain vehicle model index information and vehicle condition data types. The microprocessor unit can then send the vehicle model index information and vehicle condition data types to the microcontroller unit.
[0090] Step 210: The microcontroller sends vehicle model index information to the electronic control unit, obtains the vehicle condition signal associated with the vehicle model index information uploaded by the electronic control unit, and forwards it to the core software of the microprocessor unit.
[0091] The electronic control unit (ECU) is the core control component of an automotive electronic system. It collects various operating parameters, or vehicle condition signals, from sensors, processes these parameters according to a preset control algorithm, and then controls the corresponding actuators to adjust the vehicle's operating state. For example, the engine control unit can control the engine's fuel injection and ignition timing to ensure efficient engine operation.
[0092] Vehicle condition signals are raw signals reflecting the vehicle's status and performance, collected by various sensors during operation. These signals can be analog signals, such as voltage signals output by temperature sensors, or digital signals, such as pulse signals output by wheel speed sensors. Vehicle condition signals contain a wealth of vehicle information, such as engine speed, vehicle speed, fuel level, and temperature, and are the foundation for obtaining vehicle condition data.
[0093] In one feasible implementation, the microcontroller unit (MCU) connects to the electronic control unit (ECU) via a CAN bus. The MCU encapsulates the vehicle model index information into data frames according to the CAN bus communication protocol and sends them to the CAN bus. Upon receiving the data frames, the ECU parses the vehicle model index information and then uses this information to locate the associated vehicle condition signals. It also encapsulates these vehicle condition signals into data frames according to the CAN bus protocol and uploads them to the CAN bus. The MCU then receives these data frames from the CAN bus and forwards them to the microprocessor unit's core software. The CAN bus features high reliability, strong real-time performance, and good anti-interference capabilities, making it suitable for communication in the complex electromagnetic environment of a car. It ensures accurate and timely transmission of vehicle condition signals, reduces the possibility of data loss and errors, and ensures that the microprocessor unit's core software can obtain accurate vehicle condition information.
[0094] In another feasible implementation, for vehicle status signals with relatively low real-time and bandwidth requirements, the microcontroller unit (MCU) can communicate with the electronic control unit (ECU) via a LIN bus. The MCU sends vehicle model index information to the LIN bus, and the ECU retrieves the corresponding vehicle status signal based on the index information and uploads it. The LIN bus is low-cost, simple to wire, and suitable for connecting low-speed sensors and actuators. Using the LIN bus can reduce system cost and complexity, especially when transmitting simple vehicle status signals, meeting requirements while reducing hardware resource consumption. For the transmission of non-critical vehicle status information, the LIN bus provides an economical and effective solution.
[0095] Step 220: The core software of the microprocessor unit parses the vehicle condition signal associated with the vehicle model index information to obtain vehicle condition data; and caches the parsed vehicle condition data associated with the vehicle model index information in the vehicle condition database.
[0096] In one feasible implementation, the core software of the microprocessor unit predefines a parsing rule base, which contains parsing rules for vehicle condition signals corresponding to different vehicle model index information. Upon receiving a vehicle condition signal, the software searches for the corresponding parsing rule in the rule base based on the vehicle model index information, and then parses the vehicle condition signal according to the rule, converting it into understandable vehicle condition data. After parsing, the vehicle condition data is stored in a vehicle condition database in a specific format. Using a predefined parsing rule base can improve the efficiency and accuracy of parsing. The rule base can be customized according to different vehicle models and vehicle condition signals, ensuring that the parsing process can correctly convert the raw signal into meaningful vehicle condition data. Furthermore, centralized management of the rule base facilitates subsequent maintenance and updates.
[0097] In another feasible implementation, the core software of the microprocessor unit can utilize machine learning algorithms to analyze vehicle condition signals. First, the machine learning model is trained using a large amount of labeled data, allowing the model to learn the mapping relationship between vehicle condition signals and vehicle condition data under different vehicle model indexes. In practical applications, the received vehicle condition signals are input into the trained model, which outputs the corresponding vehicle condition data, which is then cached in the vehicle condition database. Machine learning algorithms possess adaptive and learning capabilities, enabling them to handle complex and nonlinear vehicle condition signal analysis problems. For some new vehicle models or special vehicle condition signals, the machine learning model can improve the accuracy of analysis through continuous learning and optimization. Simultaneously, machine learning algorithms can reduce the workload of manually defining analysis rules, improving the system's intelligence level.
[0098] Step 131: The microprocessor unit uses the vehicle condition database to obtain target vehicle condition data that matches the vehicle model index information and vehicle condition data type.
[0099] In one feasible approach, the microprocessor unit extracts vehicle condition data associated with vehicle model index information from a vehicle condition database; it then performs semantic transformation on the extracted vehicle condition data based on the vehicle condition data type to obtain target vehicle condition data that matches the vehicle condition data type. Specifically, the semantic transformation of the extracted vehicle condition data based on the vehicle condition data type to obtain target vehicle condition data that matches the vehicle condition data type includes: acquiring the semantic features of the vehicle condition data and the target semantic features of the vehicle condition data type; acquiring a preset semantic transformation rule that associates the semantic features and the target semantic features; and converting the vehicle condition data into target vehicle condition data that matches the vehicle condition data type based on the preset semantic transformation rule.
[0100] Step 140: Upload the target vehicle condition data to the vehicle network terminal.
[0101] In one feasible approach, the microprocessor unit uploads target vehicle condition data to the vehicle-to-everything (V2X) terminal. Specifically, the microprocessor unit determines the data type corresponding to each field name in the target vehicle condition data; obtains the encoding and storage methods associated with each data type; based on the encoding and storage methods, it sequentially encodes and encapsulates each field name in the target vehicle condition data to obtain encapsulated target vehicle condition data; and finally, it uploads the encapsulated target vehicle condition data to the V2X terminal.
[0102] In addition, the vehicle networking terminal can set the cycle for the electronic control unit to upload vehicle status signals to the vehicle terminal, which can avoid network paralysis caused by unlimited acquisition of vehicle status signals when the network is busy.
[0103] In this embodiment, the vehicle terminal includes a microcontroller unit, microprocessor unit core software, and microprocessor unit application. Through the coordinated use of the microcontroller unit, microprocessor unit core software, and microprocessor unit application, vehicle condition data is acquired, processed, and uploaded. This method involves the microcontroller unit actively requesting vehicle condition signals from the electronic control unit, enabling the vehicle terminal to request and acquire vehicle condition signals according to actual needs, rather than the electronic control unit uploading in real time, thus reducing the data transmission overhead between the electronic control unit and the vehicle terminal.
[0104] In one alternative approach, step 220 involves parsing the vehicle condition signal associated with the vehicle model index information to obtain vehicle condition data, including: Step S221: Obtain the first parsing rule file associated with vehicle condition signals.
[0105] The first parsing rule file is a document that stores rules for parsing specific vehicle condition signals. It contains detailed parsing instructions for different types of vehicle condition signals, such as the signal's start position in the data frame, length, byte order, calculation method, and verification rules. These rules are pre-defined according to the vehicle communication protocol and signal characteristics, and are used to convert raw CAN signals into meaningful vehicle condition data. This first parsing rule file can be a CAN protocol parsing rule file.
[0106] The aforementioned CAN protocol parsing rule file is a dictionary of the CAN signals for this vehicle model. It is predefined by the automaker and contains all the rule parameters required for parsing. The specific meanings of the fields are as follows: CAN Frame ID: A unique identifier for a certain type of vehicle condition data transmission frame, such as 0x18F00500 corresponding to the engine data frame and 0x18F00600 corresponding to the transmission data frame.
[0107] Signal start bit / data length: Defines the physical location of a signal in the frame data segment. For example, the vehicle speed signal starts at the 3rd bit of byte 1 and has a length of 12 bits.
[0108] Byte order: The order in which signals are concatenated when they span bytes. For example, in big-endian, the most significant byte comes first; in little-endian, the least significant byte comes first. For example, when a vehicle speed signal spans byte 1 and byte 2, the concatenation direction must be determined according to the rules.
[0109] Scale factor / offset: Calculation parameters for converting the original binary value into a physical value. For example, if the original value is 1000, the scale factor is 0.01, and the offset is 0, then the physical value = 1000 * 0.01 = 10 km / h.
[0110] Signal range: The effective range of physical values, such as vehicle speed range 0-250km / h. Data exceeding the range is considered invalid.
[0111] In one feasible approach, a one-to-one mapping relationship between vehicle model index information and CAN protocol parsing rule file can be established. The CAN protocol parsing rule file contains the definition of CAN frame ID, signal start bit, data length, byte order, scaling factor, offset, and signal range for the corresponding vehicle model. The parsing module obtains the vehicle model index information of the current vehicle and loads the corresponding CAN protocol parsing rule file based on the mapping relationship.
[0112] The vehicle model index information mentioned above is a unique identifier that distinguishes different vehicle models. It is usually derived from the vehicle's VIN code, configuration words broadcast on the vehicle's CAN bus, or hardware identifiers written to the vehicle at the factory. For example, index C001 corresponds to the 2024 high-end gasoline model, and index E002 corresponds to the 2024 low-end new energy model.
[0113] Step S222: Filter the vehicle condition signal based on the first parsing rule file to obtain the target signal frame, and extract the data segment of the target signal frame.
[0114] The target signal frame refers to the signal frame that meets specific conditions after being filtered from the numerous received CAN signal frames. It is the basic unit for subsequent data extraction and parsing, containing valid information that needs further processing to obtain vehicle condition data.
[0115] The data segment is the part of the target signal frame that actually stores vehicle-related data. In addition to the data segment, the CAN signal frame also includes control information such as a frame header and frame tail. The data segment contains specific vehicle status parameters, such as engine speed and vehicle speed. Processing the data segment yields the final vehicle condition data.
[0116] In one feasible approach, CAN frame data from the vehicle's CAN bus can be received in real time. The target CAN frame is then filtered according to a loaded CAN protocol parsing rule file, and its data segment is extracted. Specifically, based on the list of valid frame IDs defined in the loaded CAN protocol parsing rule file, frames irrelevant to the current vehicle model, such as frames specific to other configurations, error frames, and remote request frames, are filtered out, retaining only the matching target frames. For example, if the CAN protocol parsing rule file defines valid frame IDs as 0x18F00500 and 0x18F00600, then only frames with these two IDs will be processed.
[0117] Step S223: Based on the rules defined in the first parsing rule file, the data segment is sequentially subjected to signal interception, byte order conversion, data calculation, and data verification to obtain vehicle condition data.
[0118] In one feasible approach, according to the definition in the CAN protocol parsing rule file, signal interception, byte order conversion, and data calculation are performed on the data segment. The initial vehicle condition data is obtained by applying the formula: physical value = original value * scaling factor + offset. The initial vehicle condition data is then verified based on the signal range, and valid vehicle condition data that passes the verification is output. Specifically, based on the start bit + length of each signal in the CAN protocol parsing rule file, the corresponding binary segment is extracted from the data segment.
[0119] For example, for signal truncation, if the data segment is byte 0 (0x0A=00001010) and byte 1 (0x3C=00111100), and a certain signal is defined as: start bit 5, length 8 bits, then 8 bits (01010001, spanning byte 0 and byte 1) are truncated starting from the 5th bit of byte 0.
[0120] For byte order conversion, if the signal spans multiple bytes, it should be concatenated according to the byte order defined in the CAN protocol parsing rule file. For example, in little-endian, the lower 4 bits of byte 1 and the higher 4 bits of byte 0 should be concatenated with byte 0 first and byte 1 last.
[0121] For data calculation, the extracted binary fragments are converted to decimal raw values, such as binary 01010001 being converted to 81. The initial vehicle condition data is obtained by applying the formula: Physical Value = Raw Value * Scale Factor + Offset. For example: Raw value 81, scale factor 0.5, offset -10, then Physical Value = 81 * 0.5 - 10 = 30.5.
[0122] For data verification, the initial vehicle condition data can be compared with the signal range defined in the CAN protocol parsing rule file. If it is within the range, it is considered valid; otherwise, it is marked as abnormal. For example, if the calculated vehicle speed is 300 km / h, exceeding the range of 0-250 km / h, it is considered invalid. The verified signal name + physical value + unit are output in a preset format, such as JSON or binary. For example, output vehicle speed: 100 km / h, engine speed: 2500 rpm.
[0123] In this embodiment, the core software of the microprocessor unit uses the parsing rules corresponding to the CAN vehicle condition signal to parse the CAN vehicle condition signal, thereby meeting the parsing requirements of the CAN vehicle condition signal and obtaining standardized vehicle condition data for subsequent processing.
[0124] In another alternative approach, step 220 involves parsing the vehicle condition signals associated with the vehicle model index information to obtain vehicle condition data, including: Step 224: Obtain the second parsing rule file associated with vehicle condition signals.
[0125] The second parsing rule file can be a SOME / IP protocol parsing rule file.
[0126] In one feasible approach, a one-to-one mapping relationship between vehicle model index information and SOME / IP protocol parsing rule files can be pre-established. The SOME / IP protocol parsing rule files contain the service ID, instance ID, method / event ID, data structure definition, serialization rules, signal conversion rules, and signal range of the corresponding vehicle model. The parsing module obtains the vehicle model index information of the current vehicle, matches and loads the corresponding SOME / IP protocol parsing rule files from the preset rule base based on the mapping relationship.
[0127] Step 225: If the header identifier of the vehicle condition signal is consistent with the preset identifier in the second parsing rule file, the data payload is separated from the vehicle condition signal.
[0128] The data payload is the vehicle condition data body encapsulated according to the SOME / IP protocol. It is the core part of the SOME / IP message that carries the actual business data after the header control information is removed.
[0129] In one feasible approach, one can receive SOME / IP messages, extract the service ID, instance ID, and method / event ID from the message header, compare them with preset identifiers in the loaded parsing rule file, filter to obtain the target message, and then separate the data payload.
[0130] Step 226: Perform deserialization processing on the data payload according to the serialization rules of the second parsing rule file to extract the structured original data.
[0131] Step 227: Calculate the structured raw data according to the calculation rules defined in the second parsing rule file to obtain the initial vehicle condition data.
[0132] In one feasible approach, the data payload is deserialized according to the serialization rules of the second parsing rule file to extract the structured raw data. Then, the initial vehicle condition data is calculated based on the calculation rules defined in the rules. Specifically, deserialization tools, such as code generated based on the rule file or a general serialization library, are called to split the binary payload according to the byte order and data type in the rule file. The split binary fragments are converted to their corresponding data types, such as converting binary 0x55 to uint8 type 85. The data is then mapped to structured raw data according to the field order. Each field of the structured raw data is traversed, matching the corresponding calculation rule in the second parsing rule file. Calculations such as linear transformations, enumeration mappings, and bitwise operations are performed according to the rules to convert the structured raw data into physically meaningful initial vehicle condition data, such as battery SOC = 85% and charging status = fully charged.
[0133] Step 228: Verify the validity of the initial vehicle condition data based on the signal range defined in the second parsing rule file, and use the verified initial vehicle condition data as the vehicle condition data.
[0134] In one feasible approach, each initial vehicle condition data is compared with the corresponding range in the second parsing rule file; if the data is within the range, it is deemed valid and retained; if it exceeds the range, it is marked as abnormal; finally, all validated vehicle condition data are output.
[0135] In this embodiment, the core software of the microprocessor unit uses the parsing rules corresponding to the SOME / IP vehicle condition signal to parse the SOME / IP vehicle condition signal, thereby meeting the parsing requirements of the SOME / IP vehicle condition signal and obtaining standardized vehicle condition data for subsequent processing.
[0136] In other embodiments, the microprocessor unit application can acquire a target vehicle condition configuration file and parse it to obtain vehicle model index information and vehicle condition data types. The microcontroller unit receives vehicle condition signals corresponding to various vehicle models uploaded by the electronic control unit and forwards them to the microprocessor unit core software. The microprocessor unit core software parses the vehicle condition signals corresponding to various vehicle models to obtain vehicle condition data; it caches the parsed vehicle condition data corresponding to various vehicle models in a vehicle condition database; the microprocessor unit application retrieves target vehicle condition data from the vehicle condition database that matches the vehicle model index information and vehicle condition data types, where the vehicle model index information differs for different vehicle models. The target vehicle condition data is then uploaded to the vehicle network terminal. Specifically, the microprocessor unit application uploads the target vehicle condition data to the vehicle network terminal. Specifically, the microprocessor unit application determines the data type corresponding to each field name in the target vehicle condition data; acquires the encoding method and storage method associated with each data type; based on the encoding method and storage method, it sequentially encodes and encapsulates each field name in the target vehicle condition data to obtain encapsulated target vehicle condition data; and uploads the encapsulated target vehicle condition data to the vehicle network terminal. In this way, the electronic control unit can upload vehicle condition data in real time to facilitate monitoring of the vehicle condition data.
[0137] Figure 3 A schematic diagram of an embodiment of the vehicle data device of the present invention is shown. Figure 3 As shown, the device 300 includes: an acquisition module 310, a processing module 320, and an upload module 330.
[0138] The acquisition module 310 is used to acquire the target vehicle condition configuration file, wherein the target vehicle condition configuration file is generated by the vehicle networking terminal and sent to the vehicle terminal; The processing module 320 is used to parse the target vehicle condition configuration file to obtain the vehicle model index information and vehicle condition data type; and to obtain the target vehicle condition data that matches the vehicle model index information and vehicle condition data type from the vehicle condition database. Upload module 330 is used to upload target vehicle condition data to the vehicle network terminal.
[0139] This invention provides an embodiment of the invention that obtains a target vehicle condition configuration file generated by a vehicle-to-everything (V2X) terminal via an in-vehicle terminal. This configuration file contains specific vehicle model index information and vehicle condition data types. Using this index information and data types, suitable vehicle condition data can be retrieved from a vehicle condition database and fed back to the V2X terminal. Compared to related technologies, because the vehicle model index information and data types associated with the vehicle condition data can be configured via the V2X terminal, specific vehicle condition data can be obtained, reducing the amount of vehicle condition data transmitted from the in-vehicle terminal to the V2X terminal, thereby shortening the reporting cycle of vehicle condition data from the in-vehicle terminal to the V2X terminal.
[0140] like Figure 4 As shown, the vehicle-mounted terminal may include: a processor 402, a communications interface 404, a memory 406, and a communication bus 408. The vehicle-mounted terminal also includes a microcontroller unit, wherein the processor 402 includes microprocessor unit applications and microprocessor unit core software. The processor 402, communications interface 404, and memory 406 communicate with each other via the communication bus 408. The communications interface 404 is used to communicate with other devices, such as clients or other server network elements. The processor 402 is used to execute program 410, specifically performing the relevant steps in the above-described embodiment of the method for reporting vehicle data.
[0141] Specifically, program 410 may include program code, which includes computer-executable instructions.
[0142] Processor 402 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention. The vehicle-mounted terminal includes one or more processors, which may be of the same type, such as one or more CPUs; or they may be of different types, such as one or more CPUs and one or more ASICs.
[0143] Memory 406 is used to store program 410. Memory 406 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.
[0144] Specifically, program 410 can be called by processor 402 to cause the vehicle terminal to perform the following operations: Obtain the target vehicle condition configuration file, which is generated by the vehicle networking terminal and sent to the vehicle terminal; Parse the target vehicle condition configuration file to obtain the vehicle model index information and vehicle condition data type; Retrieve target vehicle condition data from the vehicle condition database that matches the vehicle model index information and vehicle condition data type; Upload the target vehicle condition data to the vehicle networking terminal.
[0145] This invention provides an embodiment of the invention that obtains a target vehicle condition configuration file generated by a vehicle-to-everything (V2X) terminal via an in-vehicle terminal. This configuration file contains specific vehicle model index information and vehicle condition data types. Using this index information and data types, suitable vehicle condition data can be retrieved from a vehicle condition database and fed back to the V2X terminal. Compared to related technologies, because the vehicle model index information and data types associated with the vehicle condition data can be configured via the V2X terminal, specific vehicle condition data can be obtained, reducing the amount of vehicle condition data transmitted from the in-vehicle terminal to the V2X terminal, thereby shortening the reporting cycle of vehicle condition data from the in-vehicle terminal to the V2X terminal.
[0146] This invention provides a vehicle data reporting system, including a vehicle network terminal and an in-vehicle terminal, wherein the in-vehicle terminal and the vehicle network terminal communicate with each other through a communication interface.
[0147] This invention provides an embodiment of the invention that obtains a target vehicle condition configuration file generated by a vehicle-to-everything (V2X) terminal via an in-vehicle terminal. This configuration file contains specific vehicle model index information and vehicle condition data types. Using this index information and data types, suitable vehicle condition data can be retrieved from a vehicle condition database and fed back to the V2X terminal. Compared to related technologies, because the vehicle model index information and data types associated with the vehicle condition data can be configured via the V2X terminal, specific vehicle condition data can be obtained, reducing the amount of vehicle condition data transmitted from the in-vehicle terminal to the V2X terminal, thereby shortening the reporting cycle of vehicle condition data from the in-vehicle terminal to the V2X terminal.
[0148] This invention provides a computer-readable storage medium storing at least one executable instruction. When the executable instruction is executed on an in-vehicle terminal, it causes the in-vehicle terminal to perform the vehicle data reporting method in any of the above method embodiments.
[0149] Specifically, the executable instructions can be used to cause the vehicle terminal to perform the following operations: Obtain the target vehicle condition configuration file, which is generated by the vehicle networking terminal and sent to the vehicle terminal; Parse the target vehicle condition configuration file to obtain the vehicle model index information and vehicle condition data type; Retrieve target vehicle condition data from the vehicle condition database that matches the vehicle model index information and vehicle condition data type; Upload the target vehicle condition data to the vehicle networking terminal.
[0150] This invention provides an embodiment of the invention that obtains a target vehicle condition configuration file generated by a vehicle-to-everything (V2X) terminal via an in-vehicle terminal. This configuration file contains specific vehicle model index information and vehicle condition data types. Using this index information and data types, suitable vehicle condition data can be retrieved from a vehicle condition database and fed back to the V2X terminal. Compared to related technologies, because the vehicle model index information and data types associated with the vehicle condition data can be configured via the V2X terminal, specific vehicle condition data can be obtained, reducing the amount of vehicle condition data transmitted from the in-vehicle terminal to the V2X terminal, thereby shortening the reporting cycle of vehicle condition data from the in-vehicle terminal to the V2X terminal.
[0151] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.
Claims
1. A reporting method of vehicle data, characterized by, The method is applied to a vehicle terminal, and comprises the following steps: obtaining a target vehicle condition configuration file, wherein the target vehicle condition configuration file is generated by a vehicle Internet terminal and is sent to the vehicle terminal; parsing the target vehicle condition configuration file to obtain vehicle model index information and vehicle condition data types; obtaining target vehicle condition data from a vehicle condition database, which is adapted to the vehicle model index information and the vehicle condition data types; uploading the target vehicle condition data to the vehicle Internet terminal.
2. The method of claim 1, wherein, The method comprises the following steps: parsing a vehicle condition data acquisition request sent by the vehicle Internet terminal to obtain a vehicle condition configuration file and version information of the vehicle condition configuration file; if the version information is inconsistent with version information of an initial vehicle condition configuration file currently cached in the vehicle terminal, taking the vehicle condition configuration file as the target vehicle condition configuration file; if the version information is consistent with the version information of the initial vehicle condition configuration file currently cached in the vehicle terminal, taking the initial vehicle condition configuration file as the target vehicle condition configuration file.
3. The method of claim 1, wherein, The method comprises the following steps: extracting vehicle condition data associated with the vehicle model index information from the vehicle condition database; performing semantic conversion on the extracted vehicle condition data based on the vehicle condition data types to obtain target vehicle condition data adapted to the vehicle condition data types.
4. The method of claim 3, wherein, The method comprises the following steps: obtaining semantic features of the vehicle condition data and target semantic features of the vehicle condition data types; obtaining a preset semantic conversion rule associated with the semantic features and the target semantic features; based on the preset semantic conversion rule, converting the vehicle condition data into target vehicle condition data adapted to the vehicle condition data types.
5. The method according to any one of claims 1 to 4, characterized in that, The method comprises the following steps: determining data types corresponding to respective field names in the target vehicle condition data; obtaining encoding modes and storage modes respectively associated with the data types; based on the encoding modes and the storage modes, respectively encoding and packaging the respective field names in the target vehicle condition data in sequence to obtain packaged target vehicle condition data; uploading the packaged target vehicle condition data to the vehicle Internet terminal.
6. The method of claim 1, wherein, The vehicle terminal comprises a micro control unit, a micro processing unit core software and a micro processing unit application; before the step of obtaining target vehicle condition data from a vehicle condition database, which is adapted to the vehicle model index information and the vehicle condition data types, the method further comprises the following steps: the micro control unit sends the vehicle model index information to an electronic control unit, obtains vehicle condition signals associated with the vehicle model index information uploaded by the electronic control unit, and forwards the vehicle condition signals to the micro processing unit core software; the micro processing unit core software parses the vehicle condition signals associated with the vehicle model index information to obtain vehicle condition data; and caches the vehicle condition data associated with the vehicle model index information in the vehicle condition database after parsing; and the micro processing unit application obtains the target vehicle condition data from the vehicle condition database, which is adapted to the vehicle model index information and the vehicle condition data types. The target vehicle condition data that is adapted to the vehicle type index information and the vehicle condition data type is acquired from the vehicle condition database. The micro-processing unit acquires the target vehicle condition data that is adapted to the vehicle type index information and the vehicle condition data type from the vehicle condition database.
7. The method of claim 6, wherein, The vehicle condition data is obtained by analyzing the vehicle condition signal associated with the vehicle type index information. A first analysis rule file associated with the vehicle condition signal is acquired. The target signal frame is obtained by filtering the vehicle condition signal based on the first analysis rule file. The data segment of the target signal frame is extracted. The vehicle condition data is obtained by sequentially performing signal interception, byte sequence conversion, data calculation and data verification on the data segment based on the rules defined in the first analysis rule file.
8. The method of claim 6, wherein, The vehicle condition data is obtained by analyzing the vehicle condition signal associated with the vehicle type index information. A second analysis rule file associated with the vehicle condition signal is acquired. If the message header identification of the vehicle condition signal is consistent with the preset identification in the second analysis rule file, the data payload is separated from the vehicle condition signal. The structured original data is extracted by performing deserialization processing on the data payload according to the serialization rule of the second analysis rule file. The initial vehicle condition data is obtained by calculating the structured original data according to the calculation rule defined in the second analysis rule file. The initial vehicle condition data that passes the validity verification based on the signal range defined in the second analysis rule file is taken as the vehicle condition data.
9. A reporting apparatus of vehicle data, characterized by comprising: The reporting device is installed in the vehicle terminal, and the device comprises: An acquisition module is configured to acquire a target vehicle condition configuration file, wherein the target vehicle condition configuration file is generated by a vehicle networking terminal and is delivered to a vehicle terminal. A processing module is configured to analyze the target vehicle condition configuration file to obtain vehicle type index information and vehicle condition data type, and to acquire target vehicle condition data from a vehicle condition database that is adapted to the vehicle type index information and the vehicle condition data type. An uploading module is configured to upload the target vehicle condition data to the vehicle networking terminal.
10. A vehicle terminal, characterized by It comprises: A processor, a memory, a communication interface and a communication bus, the processor, the memory and the communication interface complete mutual communication through the communication bus; The memory is used to store at least one executable instruction, and the executable instruction makes the processor execute the operations of the vehicle data reporting method according to any one of claims 1-8.