A method and system for processing internet of vehicles data

Abstract

The application provides a vehicle networking data processing method and system, comprising the following steps: determining a protocol type of a protocol message through a protocol parser and calling a matched analysis rule to analyze the protocol message; judging whether there is a target processing logic rule according to combined protocol information corresponding to the protocol message through a semantic mapping engine; if not, querying and reading a first mapping configuration file matched with the combined protocol information from a configuration file library, constructing a target processing logic rule based on configuration data of the first mapping configuration file, and processing the analyzed protocol message into target vehicle networking data according to the target processing logic rule; if yes, directly processing the target vehicle networking data according to the target processing logic rule; and generating a vehicle networking unified data model object according to a target structure and the target vehicle networking data through an object generator and sending the vehicle networking unified data model object to a business system. The application realizes complete decoupling between an upper layer business and a lower layer protocol, improves the overall maintainability and expansibility, and improves the data processing efficiency.

Description

A method and system for processing vehicle network data Technical Field

[0001] This application relates to the field of vehicle network data processing, and more specifically, to a method and system for processing vehicle network data. Background Technology

[0002] With the rapid development of intelligent connected vehicles and the Internet of Vehicles industry, in-vehicle communication and vehicle-to-cloud data interaction protocols are becoming increasingly heterogeneous and fragmented, encompassing a complex system from the underlying vehicle bus to cloud telemetry, and from international standards to manufacturer-specific protocols.

[0003] Therefore, processing the aforementioned vehicle-to-everything (V2X) data presents the following problems: Development is cumbersome, as each new protocol requires rewriting the parsing code, modifying the database, and changing the business logic. Data is chaotic, as the same data has inconsistent names, units, and precision across different protocols, making it unusable directly. Integration is difficult, as data from different protocols is hard to correlate and analyze (e.g., combining CAN engine data and GPS location data). Summary of the Invention

[0004] This application provides a method and system for processing vehicle network data, which completely decouples upper-layer services from lower-layer protocols, significantly improves the system's maintainability, scalability, and data fusion capabilities, and also increases data processing efficiency.

[0005] In a first aspect, embodiments of this application provide a method for processing vehicle network data, applied to a unified data model, the unified data model comprising: a target interface, a protocol parser, a semantic mapping engine, and an object generator; the method comprising:

[0006] Based on the target interface, protocol messages from different vehicle terminals are received. The protocol parser determines the protocol type of the protocol message and calls the parsing rules that match the protocol type to parse the protocol message and obtain the first key field data. The protocol message includes vehicle network data.

[0007] The semantic mapping engine determines whether there are target processing logic rules for each original protocol and target structure in the combined protocol information based on the combined protocol information corresponding to the vehicle network data.

[0008] If it does not exist, then query and read the first mapping configuration file that matches the combined protocol information from the configuration file library, construct the target processing logic rule based on the configuration data in the first mapping configuration file, and process the first key field data into target vehicle network data that matches the target structure according to the target processing logic rule; if it exists, then directly process the first key field data into target vehicle network data that matches the target structure according to the target processing logic rule.

[0009] The object generator generates a unified data model object for the Internet of Vehicles based on the target structure and the target Internet of Vehicles data, and then sends the unified data model object to the business system.

[0010] In one possible implementation, the first mapping configuration file is determined by the following method:

[0011] Based on the combined protocol information corresponding to the vehicle network data, the storage address matching the combined protocol information is queried from the pre-configured file search manual, and the second mapping configuration file is obtained from the storage address;

[0012] Based on the attribute information and operation behavior information of the second mapping configuration file, determine the target verification method for the second mapping configuration file;

[0013] The second mapping configuration file is verified according to the target verification method, and a verification pass flag is added to the second mapping configuration file that passes the verification to obtain the first mapping configuration file.

[0014] In one possible implementation, the second mapping configuration file is dynamically loaded in the following manner to ensure uninterrupted service updates and data consistency:

[0015] Loading timing control: Combining real-time query per second (QPS), CPU utilization, and queue backlog, configuration loading is triggered when the system load is below a preset threshold; and it supports loading new configurations in batches by device type, tenant ID, or protocol type, including applying the configuration to a preset proportion of non-core devices, and then fully promoting it after observing for a preset period of time without any abnormalities.

[0016] Atomicity and version management: New configurations are loaded into an independent memory area. After verification, the pointer is atomically switched to point to the new version. Old configurations are released asynchronously after they are no longer referenced. Each load generates a unique version ID. If the new configuration causes the error rate to increase, it can be rolled back to the previous stable version.

[0017] Loading and scheduling optimization: Configuration loading is handled by an independent thread pool, which does not block I / O threads; only modified mapping rule fragments are reloaded, instead of the full configuration; configuration is read from the local disk / memory cache first, and the latest version is asynchronously pulled from the remote server in the background to achieve fast startup and eventual consistency;

[0018] Observability and circuit breaker fallback: Record the time taken for each loading, the number of successes / failures, the trigger source and the affected protocol type to generate observability metrics; if three consecutive loading failures occur, automatically pause automatic updates and issue an alarm to prevent incorrect configurations from repeatedly impacting the system; and when loading fails, continue to use the currently effective configuration and record error logs to ensure business continuity.

[0019] In one possible implementation, determining the target verification method for the second mapping configuration file based on its attribute information and operation behavior information includes:

[0020] Based on the operation behavior information of the second mapping configuration file, it is determined whether the second mapping configuration file meets the scene verification conditions. If it does, the first verification method matching the scene verification conditions is obtained. If it does not meet, the first verification method is not obtained. The second mapping configuration file meeting the scene verification conditions includes reading the second mapping configuration file for the first time or the time since the last scene verification being greater than a preset time.

[0021] Based on the attribute information of the second mapping configuration file, determine the second verification method that matches the attribute information;

[0022] The first verification method and the second verification method are determined as the target verification method; or, the second verification method is determined as the target verification method.

[0023] In one possible implementation, the second mapping configuration file includes configuration data; when the second mapping configuration file is validated, it is parsed into structured data in computer memory.

[0024] The first verification method includes: verifying the correctness of the physical characteristics of the vehicle network data, the feasibility of the vehicle network data business logic, and the security of the vehicle network data for the structured data in the second mapping configuration file;

[0025] The second verification method includes: pre-processing of syntax and semantic verification and sandbox simulation verification. Pre-processing of syntax and semantic verification includes: performing JSON / YAML format validity checks, field mapping path existence checks, and circular dependency detection before loading. Sandbox simulation verification includes: using historical message samples to test the new configuration in an isolated environment to verify whether the output model meets expectations.

[0026] In one possible implementation, the verification of vehicle-to-everything (V2X) data security for the structured data in the second mapping configuration file includes:

[0027] In the unified data model registry center, security compliance metadata is defined for the target metrics. The security compliance metadata includes the data classification tags of the target metrics and the identifiers of the data processing components that must be associated with them.

[0028] After loading the semantic mapping rules in the second mapping configuration file, the system retrieves the policy metadata corresponding to the target metric from the registry center and determines whether the data category label of the target metric belongs to a predefined controlled data category. If it does, the system further verifies whether the configuration of the semantic mapping rule has correctly associated with the data processing component that must be associated as specified in the policy metadata. If it is not correctly associated, the system determines that the verification has failed and prevents the semantic mapping rule from taking effect or issues a security alert. The semantic mapping rule defines the mapping relationship from the data source to the target metric and includes reference information to the data processing component.

[0029] In one possible implementation, the step of constructing the target processing logic rules based on the configuration data in the first mapping configuration file, and processing the first key field data into target vehicle network data matching the target structure according to the target processing logic rules, includes:

[0030] A rule execution network is constructed in memory, which includes at least: a rule hash table: the key of which is a composite key generated by concatenating the protocol identifier of the original protocol and the original field name, and the value of which is the corresponding target mapping rule and the pre-compiled executable unit; a condition judgment tree: used to organize and manage mapping rules containing conditional expressions, the nodes of the tree are condition judgment logic, and the leaf nodes are the corresponding mapping rule sets;

[0031] The first key field data is used as the raw data input, and the semantic mapping engine performs matching and retrieval in the rule hash table based on the composite key generated by its protocol identifier and the original field name.

[0032] If a match is successful, the semantic mapping engine executes a predefined programmable data transformation process to generate standard data for the target structure. The programmable data transformation process includes at least numerical calculations based on configuration expressions. If a match fails, the engine traverses the conditional judgment tree to find matching conditional rules, executes the pre-compiled executable unit corresponding to the matching rule, and generates standard data for the target structure.

[0033] In one possible implementation, the pre-compiled executable unit includes: an expression executor, a unit converter, an enumeration normalizer, a conditional filter, and a hot update listener; the pre-compiled executable unit that executes the matching rule generates standard data for the target structure, including:

[0034] The expression executor executes user-defined expressions to dynamically calculate, transform, or logically process the original field values, generating the values ​​of the target VUDM fields.

[0035] The unit converter provides standardized unit conversion capabilities, automatically converting non-standard units in the raw data into uniform units defined in the VUDM model;

[0036] The enumeration normalizer maps enumeration values ​​from different protocols to unified semantic enumeration values ​​defined in the VUDM model; the enumeration values ​​include at least: status codes, text descriptions, and Boolean values;

[0037] The conditional filter determines whether to map or filter a certain piece of data based on user-defined conditional expressions, and supports complex combinations of multiple conditions.

[0038] The hot update listener monitors for changes to the semantic mapping configuration file and automatically reloads the mapping rules when a change is detected, without requiring a system restart.

[0039] In one possible implementation, the unified data model further includes a protocol fingerprint extraction module, a templated mapping module, and a mode switching control module; the method further includes:

[0040] When the real-time load metric of the protocol message processing by the response server meets the mode switching condition or when a user with specified permissions triggers the mode switching switch, the control module switches from the current mode to the high-performance degradation mode.

[0041] In the high-performance degradation mode, the target vehicle network data matching the target structure in the protocol message is obtained through the protocol fingerprint extraction module, the templated mapping module, and the asynchronous fallback verification module.

[0042] The determination that the real-time load indicators of the protocol message processing meet the mode switching conditions includes: real-time monitoring of the server's throughput, CPU utilization, memory usage, and queue backlog for protocol messages; when at least one of the protocol message throughput, CPU utilization, memory usage, and queue backlog is detected to meet the corresponding threshold conditions within a unit time, and the current business context does not belong to a non-critical data scenario, it is determined that the real-time load indicators of the protocol message processing meet the mode switching conditions.

[0043] The protocol fingerprint extraction module uses a pre-trained lightweight model to extract the message header and key fields to generate a protocol fingerprint. The key fields include: device ID, message type, and timestamp. The templated mapping module uses an offline-trained time-series prediction model to fill in the missing data of the key fields and matches a predefined unified model template according to the protocol fingerprint, outputting the processing result through the unified model template. The asynchronous fallback verification module puts the processing result into a low-priority queue, which is then verified and corrected by a background task to obtain the target vehicle network data.

[0044] Secondly, embodiments of this application provide a vehicle network data processing system, including: a target interface, a protocol parser, a semantic mapping engine, and an object generator; wherein,

[0045] The target interface is used to receive protocol messages from different vehicle terminals;

[0046] The protocol parser is used to determine the protocol type of the protocol message and call the parsing rules that match the protocol type to parse the protocol message and obtain the first key field data;

[0047] The semantic mapping engine is used to determine whether there are target processing logic rules for each original protocol and target structure in the combined protocol information based on the combined protocol information corresponding to the vehicle network data. If not, it queries and reads the first mapping configuration file that matches the combined protocol information from the configuration file library, constructs the target processing logic rules based on the configuration data in the first mapping configuration file, and processes the first key field data into target vehicle network data that matches the target structure according to the target processing logic rules. If it exists, it directly processes the first key field data into target vehicle network data that matches the target structure according to the target processing logic rules.

[0048] The object generator is used to generate a unified data model object for the Internet of Vehicles based on the target structure and the target Internet of Vehicles data, and then send the unified data model object to the business system.

[0049] The vehicle network data processing method and system provided in this application embodiment constructs a standardized and scalable "Vehicle Network Unified Data Model" (VUDM) and combines it with a semantic mapping engine to achieve dynamic parsing and unified conversion of heterogeneous data from multiple sources such as CAN, UDS, MQTT, JT / T808, and vendor proprietary protocols. Through flexible configuration files supporting expression calculation, unit conversion, and enumeration standardization, the system can shield underlying protocol differences and output a data structure with unified semantics, allowing upper-layer business platforms to directly use the data without needing to be aware of protocol details. This method thoroughly solves problems such as strong coupling between protocols and services, fragmented data semantics, and difficulties in system expansion and maintenance, significantly improving the maintainability, scalability, and cross-protocol data fusion capabilities of vehicle network data processing, and also increasing data processing efficiency. Attached Figure Description

[0050] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0051] Figure 1 shows a flowchart of a first method for processing vehicle network data according to an embodiment of this application;

[0052] Figure 2 shows a flowchart of a second method for processing vehicle network data provided in an embodiment of this application;

[0053] Figure 3 shows a flowchart of a third method for processing vehicle network data provided in an embodiment of this application;

[0054] Figure 4 shows a flowchart of the fourth method for processing vehicle network data provided in an embodiment of this application;

[0055] Figure 5 shows a schematic diagram of a vehicle network data processing system provided in an embodiment of this application;

[0056] Figure 6 shows a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0057] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0058] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0059] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0060] The following problems exist when processing the aforementioned vehicle network data: Development is cumbersome, as each new protocol requires rewriting parsing code, modifying the database, and changing business logic. Data is chaotic, as the same data has inconsistent names, units, and precision across different protocols, making it unusable directly. Integration is difficult, as data from different protocols is hard to correlate and analyze (e.g., combining CAN engine data and GPS location data). Based on this, this application provides a method and system for processing vehicle network data. This solution dynamically maps heterogeneous data from multiple protocols into a unified semantic model, achieving complete decoupling between upper-layer business and lower-layer protocols, significantly improving system maintainability, scalability, and data fusion capabilities, and increasing data processing efficiency.

[0061] As shown in Figure 1, this application provides a method for processing vehicle network data, applied to a unified data model. The unified data model includes: a target interface, a protocol parser, a semantic mapping engine, and an object generator; the method includes:

[0062] S101. Based on the target interface, receive protocol messages from different vehicle terminals, determine the protocol type of the protocol message through a protocol parser, and call the parsing rules matching the protocol type to parse the protocol message to obtain the first key field data; the protocol message includes vehicle network data.

[0063] S102. The semantic mapping engine determines whether there are target processing logic rules for each original protocol and target structure in the combined protocol information based on the combined protocol information corresponding to the vehicle network data.

[0064] S103. If it does not exist, query and read the first mapping configuration file that matches the combined protocol information from the configuration file library, construct the target processing logic rule based on the configuration data in the first mapping configuration file, and process the first key field data into target vehicle network data that matches the target structure according to the target processing logic rule; if it exists, directly process the first key field data into target vehicle network data that matches the target structure according to the target processing logic rule.

[0065] S104. Generate a unified data model object for the Internet of Vehicles (IoV) based on the target structure and the target IoV data using an object generator, and send the unified data model object to the business system.

[0066] This application utilizes the aforementioned method and system for processing vehicle network data. This solution achieves complete decoupling between upper-layer services and lower-layer protocols by dynamically mapping heterogeneous data from multiple protocols into a unified semantic model. This significantly improves the maintainability, scalability, and data fusion capabilities of the system, and also enhances data processing efficiency.

[0067] The exemplary embodiments described above will be explained below:

[0068] S101. Based on the target interface, receive protocol messages from different vehicle terminals, determine the protocol type of the protocol message through a protocol parser, and call the parsing rules matching the protocol type to parse the protocol message to obtain the first key field data; the protocol message includes vehicle network data.

[0069] In this embodiment of the application, different vehicle terminals typically use different protocols to send messages, and the protocols used by the vehicle terminals to send different vehicle network data are also typically different. The above protocols include: 1. Vehicle bus protocols: CAN (Controller Area Network), LIN (Local Interconnect Network), FlexRay, Ethernet (including DoIP, Diagnostic over IP), etc., used for real-time communication and diagnosis between ECUs; 2. Diagnostic protocols: UDS (ISO 14229), KWP2000, OBD-II (SAE J1979), etc., used for vehicle fault diagnosis, parameter reading and flashing; 3. Telemetry and cloud platform protocols: MQTT, HTTP / JSON, CoAP, WebSocket, gRPC and other general IoT protocols, supporting vehicle status reporting, remote control and OTA upgrades; 4. Standard vehicle networking protocols: (1) JT / T808: Communication protocol for vehicle terminals of road transport vehicle satellite positioning system issued by designated institutions, widely used for the supervision of passenger and dangerous goods vehicles and freight vehicles; (2) JT / T 794, JT / T 1078: respectively specify the technical requirements of vehicle terminals and audio and video transmission protocols; (3) GB / T 32960: Technical Specification for Remote Service and Management System for Electric Vehicles, used for data reporting of new energy vehicles; (4) GT06 / GT06N: Commonly found in low-cost GPS positioning terminals, widely used in electric bicycles, motorcycles, and logistics tracking equipment. The protocol structure is simple but the market share is high; 5. OEM private protocol: ECU communication format and data encapsulation specifications customized by each car manufacturer, such as MQB platform CAN matrix of car manufacturer 1, TNGA platform diagnostic protocol of car manufacturer 2, DiLink data frame of car manufacturer 3, NAD service protocol of car manufacturer 4, etc.; 6. Private protocol of vehicle network terminal manufacturers: (1) Manufacturer 1: Its protocol is widely used in commercial vehicles, construction machinery, and shared mobility fields, and supports custom data packet structure and encrypted fields; (2) Manufacturer 2: The protocol supports TCP / UDP custom binary format and is often used for fleet management and asset tracking; (3) Other manufacturers also have their own private protocol systems, and the data structure, field definition, heartbeat mechanism, and alarm type are not uniform.

[0070] The aforementioned protocol message includes vehicle-to-everything (V2X) data. Specifically, the protocol parser compares "connection layer characteristics (e.g., network port or physical channel / interface)" and message structure characteristics (e.g., fixed header, length field, and checksum) with a built-in "protocol feature library" to determine the specific protocol type. Alternatively, the protocol parser can also use connection layer characteristics (e.g., device pre-registration information and session state) to assist in determining the protocol type. After determining the protocol type, the protocol parser outputs a unique protocol identifier. The protocol parser then queries a pre-maintained "protocol knowledge base" for parsing rules that match the protocol identifier and parses the protocol message based on these rules to obtain the first key field data. The "protocol knowledge base" pre-maintains parsing rules corresponding to different protocol identifiers; in the vehicle network data, the "first key field data" can be vehicle status and operation data, diagnostic and alarm data, terminal and device metadata, multimedia and extended data, and response data of control commands; the above-mentioned vehicle status and operation data can be location-related (such as original latitude and longitude values, altitude, original speed values, heading / heading angle), power system-related (such as "engine speed, original engine temperature, fuel level / electricity SOC (percentage or original voltage value), instantaneous fuel consumption, cumulative mileage), chassis and body-related, etc.

[0071] S102. The semantic mapping engine determines whether there are target processing logic rules for each original protocol and target structure in the combined protocol information based on the combined protocol information corresponding to the vehicle network data.

[0072] In this embodiment, each piece of vehicle network data has corresponding combined protocol information. Different combined protocol information is pre-configured to adapt to business needs. For example, the combined protocol information includes "A1+B1+C1+D1, A2+B3+C1+D4", where ABCD represents different protocols and 1234 represents different versions. Each business corresponds to one type of combined protocol information, and the vehicle network data under that business corresponds to that combined protocol information. The semantic mapping engine determines whether there are target processing logic rules for each original protocol and target structure in the pre-generated combined protocol information based on the combined protocol information corresponding to the vehicle network data. It should be noted that the target processing logic rules for each type of combined protocol information can be stored for a preset duration (e.g., 24 hours). They are regenerated based on user operations with specific permissions or after the preset duration is reached.

[0073] Here, the target structure is the structure of a unified data model (such as VUDM, Virtual Unified Device Model), which is a standardized and scalable data structure (as shown in Table 1) used to carry the parsing results from any protocol. It contains at least the following fields, and the above data is the target vehicle network data obtained by processing the data of the first key field based on the target processing logic rules.

[0074] Table 1

[0075]

[0076] S103. If it does not exist, query and read the first mapping configuration file that matches the combined protocol information from the configuration file library, construct the target processing logic rule based on the configuration data in the first mapping configuration file, and process the first key field data into target vehicle network data that matches the target structure according to the target processing logic rule; if it exists, directly process the first key field data into target vehicle network data that matches the target structure according to the target processing logic rule.

[0077] In this embodiment of the application, if there is a target processing logic rule corresponding to the combined protocol information, the first key field data is directly processed into target vehicle network data matching the target structure according to the target processing logic rule; if it does not exist, the first mapping configuration file (i.e., the original configuration file) matching the combined protocol information is queried and read from the configuration file library, and the target processing logic rule is constructed based on the configuration data in the first mapping configuration file, and the first key field data is processed into target vehicle network data matching the target structure according to the target processing logic rule.

[0078] S104. Generate a unified data model object for the Internet of Vehicles (IoV) based on the target structure and the target IoV data using an object generator, and send the unified data model object to the business system.

[0079] The object generator generates a unified data model object for the Internet of Vehicles based on the target structure and corresponding data of the specified fields in Table 1 above, and sends the unified data model object to the business system.

[0080] Furthermore, as shown in Figure 2, the vehicle network data processing method provided in this application embodiment determines the first mapping configuration file through the following method:

[0081] S201. Based on the combined protocol information corresponding to the vehicle network data, query the storage address that matches the combined protocol information from the pre-configured file search manual, and obtain the second mapping configuration file from the storage address.

[0082] S202. Determine the target verification method for the second mapping configuration file based on the attribute information and operation behavior information of the second mapping configuration file.

[0083] S203. Verify the second mapping configuration file according to the target verification method, and add a verification pass flag to the second mapping configuration file that passes the verification to obtain the first mapping configuration file.

[0084] In conjunction with the above S201-S203, the first mapping configuration file used to construct the target processing logic rule in this embodiment of the application has been pre-verified and passed the verification. Specifically, each combination protocol information matches a different second mapping configuration file. Therefore, the storage address that matches the selected combination protocol information is first determined, and the second mapping configuration file is obtained from the storage address. Then, based on the attribute information and operation behavior information of the second mapping configuration file, the target verification method for the second mapping configuration file is determined, and the second mapping configuration file is verified according to the target verification method. A verification pass identifier is added to the second mapping configuration file that passes the verification to obtain the first mapping configuration file.

[0085] Specifically, determining the target verification method for the second mapping configuration file based on its attribute information and operation behavior information includes: determining whether the second mapping configuration file meets the scenario verification conditions based on the operation behavior information of the second mapping configuration file (e.g., whether it is the first operation or the time since the last scenario verification); if it meets the conditions, obtaining the first verification method matching the scenario verification conditions; if it does not meet the conditions, not obtaining the first verification method; wherein, the second mapping configuration file meeting the scenario verification conditions includes reading the second mapping configuration file for the first time or the time since the last scenario verification being greater than a preset time; then, determining the second verification method matching the attribute information based on the attribute information of the second mapping configuration file (e.g., vehicle network scenario attributes); the target verification method may include the first verification method and the second verification method, or the target verification method may only include the second verification method.

[0086] The second mapping configuration file includes configuration data; when validating the second mapping configuration file, the second mapping configuration file is parsed into structured data in computer memory;

[0087] The first verification method includes: verifying the correctness of the physical characteristics of the vehicle network data, the feasibility of the vehicle network data business logic, and the security of the vehicle network data for the structured data in the second mapping configuration file.

[0088] Here, "verification of the correctness of the physical characteristics of vehicle network data" includes: verification of the reasonableness of the numerical range, that is, whether the converted data value is within the possible physical range; verification of unit consistency, that is, whether the units in the calculation formula can be converted and matched to avoid errors such as "dividing meters by seconds to get liters"; verification of the continuity of the rate of change, that is, whether the change of the data value conforms to physical inertia; and verification of sensor range matching, that is, whether the accuracy and range of the data after empty mapping are consistent with the known specifications of the vehicle-mounted sensors.

[0089] "Feasibility verification of vehicle network data business logic" includes: business rule conflict verification, including whether the data combination violates the preset business logic; correctness verification of derived indicator calculation, that is, checking whether the business indicators calculated by the expression are correct; and completeness of enumeration value mapping, that is, ensuring that all possible original enumeration values ​​are mapped to the standardized values ​​recognized by the business system without omission.

[0090] The second verification method includes: pre-verification of syntax and semantics and sandbox simulation verification. Pre-verification of syntax and semantics includes: performing JSON / YAML format validity checks, field mapping path existence checks, and circular dependency detection before loading. Sandbox simulation verification includes: using historical message samples to test the new configuration in an isolated environment to verify whether the output model meets expectations. Here, through the above pre-verification of syntax and semantics and sandbox testing, the initial loading success rate is improved.

[0091] 1. Pre-processing of syntax and semantics validation:

[0092] Execute before loading:

[0093] (1) JSON / YAML format validity check;

[0094] (2) Does the field mapping path exist (e.g., is ${device.model} defined in the protocol)?

[0095] (3) Circular dependency detection (A→B→A mapping dead loop).

[0096] 2. Sandbox simulation operation:

[0097] Using historical message samples, we tested the new configuration in an isolated environment to verify whether the output model met the expected schema and intercepted 90%+ of configuration errors.

[0098] Furthermore, the vehicle network data processing method provided in this application embodiment includes verifying the vehicle network data security of the structured data in the second mapping configuration file, comprising:

[0099] S1. In the unified data model registry center, define security compliance metadata for the target metrics. The security compliance metadata includes the data classification tags of the target metrics and the identifiers of the data processing components that must be associated with them.

[0100] S2. After loading the semantic mapping rules in the second mapping configuration file, obtain the policy metadata corresponding to the target indicator from the registry center, and determine whether the data classification label of the target indicator belongs to the predefined controlled data category; if it does, further verify whether the configuration of the semantic mapping rule has been correctly associated with the data processing component that must be associated as specified in the policy metadata; if it is not correctly associated, determine that the verification has failed, and prevent the semantic mapping rule from taking effect or issue a security alarm; wherein, the semantic mapping rule defines the mapping relationship from the data source to the target indicator and contains reference information to the data processing component.

[0101] Specifically, during the system design phase, each indicator (such as vehicle_location) is pre-labeled with a security tag (e.g., category: highly sensitive geographic information) in the "data dictionary" (registration center), and the components that must be associated when processing this data are forcibly specified (e.g., mandatory associated components: geofence blurring processor, data transmission encryptor). When a set of mapping rules is written (e.g., "map the latitude and longitude fields of the JT808 protocol to the vehicle_location indicator"), the system will automatically check the "security profile" of vehicle_location in the registration center when loading, and find that it belongs to the "predefined controlled data category" (e.g., "personal privacy" or "important data"). The system then checks whether the configuration of this mapping rule explicitly references (or configures) the data processing components required in the security profile. For example, does the rule specify that "vehicle_location data must be processed by GeoFuzzProcessor (geofometry component) before output"? If the verification fails (for example, sensitive location data is mapped without any desensitization or encryption components), the system will automatically prevent this mapping rule from going live, fundamentally preventing insecure data from being produced. Security personnel will also be notified to intervene.

[0102] Furthermore, the vehicle network data processing method provided in this application embodiment dynamically loads the second mapping configuration file in the following manner to achieve uninterrupted service updates and ensure data consistency, specifically including:

[0103] Loading timing control: Combining real-time query per second (QPS), CPU utilization, and queue backlog, configuration loading is triggered when the system load is below a preset threshold; and it supports loading new configurations in batches by device type, tenant ID, or protocol type, including applying the configuration to a preset proportion of non-core devices, and then fully promoting it after observing for a preset period of time without any abnormalities.

[0104] Atomicity and version management: New configurations are loaded into an independent memory area. After verification, the pointer is atomically switched to point to the new version. Old configurations are released asynchronously after they are no longer referenced. Each load generates a unique version ID. If the new configuration causes the error rate to increase, it can be rolled back to the previous stable version.

[0105] Loading and scheduling optimization: Configuration loading is handled by an independent thread pool, which does not block I / O threads; only modified mapping rule fragments are reloaded, instead of the full configuration; configuration is read from the local disk / memory cache first, and the latest version is asynchronously pulled from the remote server in the background to achieve fast startup and eventual consistency;

[0106] Observability and circuit breaker fallback: Record the time taken for each loading, the number of successes / failures, the trigger source and the affected protocol type to generate observability metrics; if three consecutive loading failures occur, automatically pause automatic updates and issue an alarm to prevent incorrect configurations from repeatedly impacting the system; and when loading fails, continue to use the currently effective configuration and record error logs to ensure business continuity.

[0107] In this embodiment of the application, the above-mentioned dynamic loading of the "mapping configuration file" mechanism is adopted. In addition to enabling uninterrupted service updates, dynamic loading of the "mapping configuration file" can also introduce the following key mechanisms to ensure high success rate, low latency, and data consistency.

[0108] 1. Loading timing control: Avoiding interference during peak business periods:

[0109] (1) Traffic-aware scheduling: Combining real-time query per second (QPS), central processing unit (CPU) utilization, queue backlog and other indicators, loading is triggered during business off-peak periods (such as at night (11 pm to 6 am the next day) and weekends) or when the system load is below the threshold, so as to reduce the impact on online requests.

[0110] (2) Gray window mechanism: Supports loading new configurations in batches according to device type, tenant ID or protocol type to avoid avalanche caused by full mutation.

[0111] Example: First apply the new mapping rule to 5% of non-core devices, observe for 10 minutes if there are no abnormalities, and then promote it to the whole device.

[0112] 2. Atomicity and Version Control: Preventing Intermediate State Pollution

[0113] (1) Double buffer / shadow configuration mechanism: The new configuration is loaded into an independent memory area (such as config_v2). After the verification is passed, the pointer is atomically switched to point to the new version. The old configuration is released asynchronously after it is no longer referenced. This mechanism avoids reading the unfinished configuration during the loading process.

[0114] (2) Configure version number + rollback capability:

[0115] Each load generates a unique version ID (such as GitCommitHash (i.e., version fingerprint) or timestamp). If the new configuration causes the error rate to increase, it can be rolled back to the previous stable version in seconds.

[0116] 3. Pre-verification and sandbox testing: Improve the initial load success rate.

[0117] (1) Pre-processing of syntax and semantics verification:

[0118] Before loading, perform the following checks: JSON / YAML format validity; existence of field mapping paths (e.g., whether ${device.model} is defined in the protocol); and detection of circular dependencies (A→B→A mapping dead loop).

[0119] (2) Sandbox simulation operation: Use historical packet samples to test the new configuration in the isolated environment, verify whether the output model meets the expected schema, and intercept 90%+ of configuration errors.

[0120] 4. Loading and scheduling optimization: Balancing efficiency and resource consumption:

[0121] (1) Asynchronous non-blocking loading: Configuration loading is handled by an independent thread pool, which does not block I / O threads and avoids service lag caused by parsing large files.

[0122] (2) Incremental update support: If only some mapping rules are modified (such as adding a new device model), only the changed fragment is reloaded instead of the full reload, and the loading time is reduced from seconds to milliseconds.

[0123] (3) Local caching + remote synchronization: The configuration file is read from the local disk / memory cache first, while the latest version is asynchronously pulled from the remote disk (such as from Nacos / Apollo / etcd) in the background to achieve fast startup and eventual consistency.

[0124] 5. Observability and circuit breaker backup:

[0125] (1) Loading success rate monitoring: Record the loading time, number of successes / failures, trigger source (manual / API / automatic) and affected protocol type for each loading;

[0126] (2) Failure circuit breaker mechanism: If the loading fails 3 times in a row, the automatic update will be automatically suspended and an alarm will be issued to notify the operation and maintenance to intervene, so as to prevent the system from being repeatedly impacted by incorrect configuration.

[0127] (3) Degradation strategy: When loading fails, continue to use the currently effective configuration and record the error log to ensure business continuity.

[0128] In this application embodiment, the dynamic loading described above is not a simple hot update. The core principle of dynamic loading is:

[0129] The goal of the aforementioned "dynamic loading" is not only "non-stop operation," but also "seamless, reliable, and traceable." Through four layers of protection—pre-verification, atomic switching, gray-scale scheduling, and circuit breaker rollback—it can support the dynamic mapping needs of millions of devices and thousands of protocols in complex production environments. The specific details of the "dynamic loading" in this application are shown in Table 2 below:

[0130] Table 2

[0131]

[0132] Furthermore, as shown in Figure 3, the vehicle network data processing method provided in this application embodiment, wherein the step of constructing the target processing logic rule based on the configuration data in the first mapping configuration file, and processing the first key field data into target vehicle network data matching the target structure according to the target processing logic rule, includes:

[0133] S301. Construct a rule execution network in memory, the rule execution network including at least: a rule hash table: its key is a composite key generated by concatenating the protocol identifier of the original protocol and the original field name, and its value is the corresponding target mapping rule and the pre-compiled executable unit; a condition judgment tree: used to organize and manage mapping rules containing condition expressions, the nodes of the tree are condition judgment logic, and the leaf nodes are the corresponding mapping rule sets.

[0134] S302. The first key field data is used as the input raw data, and the semantic mapping engine performs matching and retrieval in the rule hash table based on the composite key generated by its protocol identifier and the original field name.

[0135] S303. If the match is successful, the semantic mapping engine executes a predefined programmable data transformation process to generate standard data of the target structure. The programmable data transformation process includes at least numerical calculation based on the configuration expression. If the match fails, the condition judgment tree is traversed to find the matching condition rule, and the pre-compiled executable unit corresponding to the matching rule is executed to generate standard data of the target structure.

[0136] Specifically, the aforementioned pre-compiled executable unit includes: an expression executor, a unit converter, an enumeration normalizer, a conditional filter, and a hot update listener; the pre-compiled executable unit corresponding to the execution matching rule generates standard data for the target structure, including:

[0137] The expression executor executes user-defined expressions to dynamically calculate, transform, or logically process the original field values, generating the values ​​of the target VUDM fields.

[0138] The unit converter provides standardized unit conversion capabilities, automatically converting non-standard units in the raw data into uniform units defined in the VUDM model.

[0139] The enumeration normalizer maps enumeration values ​​from different protocols to unified semantic enumeration values ​​defined in the VUDM model; the enumeration values ​​include at least: status codes, text descriptions, and Boolean values;

[0140] The conditional filter determines whether to map or filter a certain piece of data based on user-defined conditional expressions, and supports complex combinations of multiple conditions.

[0141] The hot update listener monitors for changes to the semantic mapping configuration file and automatically reloads the mapping rules when a change is detected, without requiring a system restart.

[0142] In this embodiment, the semantic mapping engine is responsible for dynamically mapping the raw fields output by the protocol parser to VUDM objects. Its core modules include:

[0143] (1) Mapping configuration loader: reads the mapping configuration file in JSON / YAML format and builds the mapping rule table;

[0144] (2) Expression executor: Supports JavaScript / SpEL expressions to achieve dynamic calculation (e.g., (value-32)*5 / 9);

[0145] (3) Unit converter: Built-in unit conversion rules (e.g., mph→km / h, °F→°C);

[0146] (4) Enumeration Standardizer: Maps enumeration values ​​of different protocols to a unified standard value (e.g., 1 → "OPEN", "open" → "OPEN").

[0147] (5) Conditional filters: support conditional expressions (such as ifprotocol=="UDS"andfield=="dtc");

[0148] (6) Hot update listener: listens for changes in configuration files and automatically reloads mapping rules without restarting the service.

[0149] Furthermore, a key feature of this application embodiment is the introduction of big data and AI solutions to replace the "protocol parser + semantic mapping engine" to improve efficiency. Specifically, the vehicle network data processing method provided in this application embodiment includes a protocol fingerprint extraction module, a templated mapping module, and a mode switching control module in the unified data model; the method also includes:

[0150] S3. The response server controls the mode switching control module to switch from the current mode to the high-performance degradation mode when the real-time load index of the protocol message processing meets the mode switching conditions or responds to the trigger operation of the mode switching switch by a user with specified permissions.

[0151] S4. In the high-performance degradation mode, target vehicle network data matching the target structure in the protocol message is obtained through the protocol fingerprint extraction module, the templated mapping module, and the asynchronous fallback verification module.

[0152] The determination that the real-time load indicators of the protocol message processing meet the mode switching conditions includes: real-time monitoring of the server's throughput, CPU utilization, memory usage, and queue backlog for protocol messages; when at least one of the protocol message throughput, CPU utilization, memory usage, and queue backlog is found to meet the corresponding threshold condition within a unit time, and the current business context does not belong to a non-critical data scenario (such as device heartbeat, telemetry data, log reporting), it is determined that the real-time load indicators of the protocol message processing meet the mode switching conditions.

[0153] The protocol fingerprint extraction module uses a pre-trained lightweight model to extract the message header and key fields to generate a protocol fingerprint. The key fields include: device ID, message type, and timestamp. The templated mapping module uses an offline-trained time-series prediction model to fill in the missing data of the key fields and matches a predefined unified model template according to the protocol fingerprint, outputting the processing result through the unified model template. The asynchronous fallback verification module puts the processing result into a low-priority queue, which is then verified and corrected by a background task to obtain the target vehicle network data.

[0154] This application provides a conventional processing mode and a high-performance degradation mode for vehicle network data. The former ensures both efficiency and accuracy, while the latter, compared to the former, sacrifices some accuracy but still meets high concurrency requirements. These are explained in detail below:

[0155] A. Standard processing mode (medium concurrency):

[0156] Under moderate concurrent loads (e.g., 100,000 protocol packets per second), the system employs a complete "protocol parser + semantic mapping engine" chain for processing. This process includes:

[0157] (1) Protocol decoding: Parse binary / text messages field by field according to standard or proprietary protocol specifications;

[0158] (2) Semantic validation: Validate the legality of fields and business constraints (such as range, enumeration, and dependency relationships);

[0159] (3) Contextual association: Semantic completion is performed by combining the device's historical state and the session context;

[0160] (4) Model mapping: Convert the original message structure into a unified data model.

[0161] This mode ensures high accuracy (≥99.9%) and strong consistency, making it suitable for scenarios with stringent data quality requirements (such as billing, alarms, and auditing). The end-to-end processing latency is controlled within seconds, meeting the real-time requirements of most business systems.

[0162] B. High-performance degradation mode (high-concurrency burst scenarios):

[0163] When a system faces extremely high concurrency pressure (such as 1 million+ messages per second) or millisecond-level response requirements (such as edge computing, real-time risk control, and IoT device flow control), the complete parsing chain may become a performance bottleneck. In such cases, introducing big data models and AI can enable a FastPath algorithm based on feature recognition and lightweight inference. Its core mechanism is as follows:

[0164] 1. Specific conditions (triggering downgrade mode):

[0165] (1) The system detects that the protocol message throughput per unit time exceeds the threshold (e.g., >500,000 TPS).

[0166] (2) Or the CPU / memory / queue backlog indicators reach the preset level;

[0167] (3) The current business context allows for a certain degree of fault tolerance (such as non-critical telemetry data, status heartbeat, and log reporting).

[0168] 2. Special method (FastPath implementation):

[0169] (1) Protocol fingerprint extraction: Using a pre-trained lightweight model (such as decision tree, embedding vector matching) or rule engine, only the message header / key fields (such as device ID, message type, timestamp) are extracted to generate a "protocol fingerprint";

[0170] (2) Templated mapping: Based on fingerprint matching, a predefined "unified model template" is used to skip field-level validation and complex semantic reasoning;

[0171] 3. AI-assisted completion (optional): Use offline trained time series prediction models (such as LSTM) to perform probability imputation on missing fields (only for non-critical fields);

[0172] 4. Asynchronous fallback verification: The FastPath processing result is placed in a low-priority queue, and the background task performs post-processing verification and correction.

[0173] In this application embodiment, the above-mentioned high-performance degradation mode is applicable to the following scenarios:

[0174] 1. High business tolerance: This scenario is mostly used for monitoring, statistics, and trend analysis data. A small amount of error will not affect the overall decision-making (such as "device online rate 98% vs 99.9%" is above the alarm threshold).

[0175] 2. Higher priority for timeliness: Millisecond-level latency can avoid problems such as misjudgment of device disconnection and failure of real-time strategies;

[0176] 3. Errors are controllable and traceable:

[0177] (1) The accuracy rate remains at 95%~98% (verified by A / B testing).

[0178] (2) All FastPath data is tagged with processing_mode=fast, which makes it easier for the upper layer to filter or use it with weights as needed;

[0179] (3) The asynchronous verification mechanism can correct about 70% of the misjudgments, and the remaining errors are included in the system SLA tolerance range.

[0180] The advantages of the above high-performance degradation mode are summarized in Table 3:

[0181] Table 3

[0182]

[0183] The following description, in conjunction with Figure 4 and specific embodiments, illustrates a method for processing vehicle network data (i.e., a unified vehicle network data model (VUDM) and its semantic mapping method), comprising the following components and steps:

[0184] 1. Construct a unified data model for vehicle-to-everything (VUDM):

[0185] VUDM is a standardized, scalable data structure (as shown in Table 1) used to carry parsing results from any protocol. It contains at least the following fields: (one field; data used by different protocols, compatible with many protocols; the data is standardized and structured).

[0186] 2. Build a semantic mapping engine:

[0187] The semantic mapping engine is responsible for dynamically mapping the raw fields output by the protocol parser to VUDM objects. Its core modules include:

[0188] Mapping configuration loader: Reads mapping configuration files in JSON / YAML format and builds a mapping rule table;

[0189] Expression executor: Supports JavaScript / SpEL expressions and enables dynamic calculation (e.g., (value-32)*5 / 9);

[0190] Unit converter: Built-in unit conversion rules (e.g., mph→km / h, °F→°C);

[0191] Enumeration Standardizer: Maps enumeration values ​​from different protocols to a unified standard value (e.g., 1 → "OPEN", "open" → "OPEN").

[0192] Conditional filters: support conditional expressions (such as ifprotocol=="UDS"andfield=="dtc");

[0193] Hot update listener: Listens for changes in configuration files and automatically reloads mapping rules without requiring a service restart.

[0194] 3. Define the semantic mapping configuration file:

[0195] The mapping configuration file uses YAML or JSON format, and each rule contains source field definitions and target VUDM field definitions:

[0196] mappings:

[0197] -source:

[0198] protocol:"UDS_0x22"#Original Protocol ID

[0199] field:"engine_temp_raw"# Original field name

[0200] target:

[0201] metric:"engine_temperature"#Standardized metric name

[0202] unit: "°C"# Standardized unit

[0203] expression: "value*0.1" # Expression: Original value 856 → 85.6°C

[0204] quality: "good" # Default quality level

[0205] -source:

[0206] protocol: "MQTT_OBD"

[0207] field:"speed_mph"

[0208] target:

[0209] metric: "vehicle_speed"

[0210] unit: "km / h"

[0211] expression:"value*1.60934"#mph→km / h

[0212] -source:

[0213] protocol: "CAN_0x301"

[0214] field:"door_status"

[0215] target:

[0216] metric:"door_status"

[0217] unit:"enum"

[0218] expression:"value==1?'OPEN':'CLOSED'"

[0219] 4. System workflow:

[0220] Protocol parsers (such as PDM engines) output raw field objects:

[0221] {protocol:"UDS_0x22",field:"engine_temp_raw",value:856}

[0222] The semantic mapping engine matches mapping rules based on protocol + field;

[0223] Perform expression calculations, unit conversions, and enumeration mappings;

[0224] Generate standard VUDM objects:

[0225] {

[0226] "deviceId":"ECU_ENGINE_01",

[0227] "timestamp":1747382400000,

[0228] "metric":"engine_temperature",

[0229] "value":85.6,

[0230] "unit":"°C",

[0231] "quality":"good",

[0232] "sourceProtocol":"UDS_0x22"

[0233] }

[0234] Output to a message queue (Kafka / RabbitMQ) or directly push to the business system;

[0235] Business systems consume VUDM data without needing to be aware of the underlying protocol details.

[0236] 5. Supports integration with Protocol Description Model (PDM):

[0237] This application can be used in conjunction with the PDM (Protocol Description Model) method for dynamic parsing of multiple protocols in vehicle-to-everything (V2X) communication:

[0238] The PDM engine is responsible for parsing the protocol and raw fields.

[0239] This application is responsible for the semantic mapping of raw fields to VUDM;

[0240] A dual-model architecture of "PDM+VUDM" is formed to achieve end-to-end conversion from raw byte stream to unified semantic model.

[0241] 6. Model Registry Center and Version Management:

[0242] (1) Establish a VUDM indicator registry center for unified management:

[0243] A dictionary of indicator names (e.g., engine_temperature, vehicle_speed);

[0244] Unit systems (e.g., °C, km / h, rpm);

[0245] Enumeration value criteria (e.g., door_status:OPEN / CLOSED);

[0246] Data quality definition;

[0247] (2) Supports VUDM model version management (such as v1.0, v2.0), and different versions can be bound to different devices.

[0248] The vehicle network data processing system provided in this application has the following significant advantages:

[0249] 1. Complete decoupling of protocols and business logic: Adding a new protocol only requires adding mapping configuration, with zero modification to the business code;

[0250] 2. Highly unified data semantics: The same physical quantity uses a unified index name, unit, and enumeration value, supporting cross-protocol aggregation analysis;

[0251] 3. The upper-layer platform is completely unaware: the business system only needs to be developed for VUDM, shielding it from the complexity of the underlying protocol;

[0252] 4. Supports dynamic semantic calculation: Unit conversion, scaling, and conditional mapping are implemented through the expression engine;

[0253] 5. Hot update capability: Mapped configurations take effect within seconds, ensuring 24 / 7 business continuity;

[0254] 6. Reduce development and maintenance costs: Business development efficiency increased by 50%+, and test case reuse rate increased by 80%+;

[0255] 7. Supports AI and rule engines: Standardized semantic models facilitate machine learning feature engineering and business rule writing;

[0256] 8. High scalability: Supports custom extensions through metadata fields, ensuring compatibility with future new metrics and protocols.

[0257] Based on the same inventive concept, this application also provides a vehicle network data processing system corresponding to the vehicle network data processing method. Since the principle of the system in this application is similar to the vehicle network data processing method described above in this application, the implementation of the system can refer to the implementation of the method, and the repeated parts will not be described again.

[0258] Referring to Figure 5, this application embodiment provides a vehicle network data processing system, including: a target interface, a protocol parser, a semantic mapping engine, and an object generator; wherein,

[0259] The target interface 501 is used to receive protocol messages from different vehicle terminals;

[0260] Protocol parser 502 is used to determine the protocol type of the protocol message and call the parsing rules that match the protocol type to parse the protocol message and obtain the first key field data;

[0261] The semantic mapping engine 503 is used to determine whether there are target processing logic rules for each original protocol and target structure in the combined protocol information based on the combined protocol information corresponding to the vehicle network data. If not, it queries and reads the first mapping configuration file that matches the combined protocol information from the configuration file library, constructs the target processing logic rules based on the configuration data in the first mapping configuration file, and processes the first key field data into target vehicle network data that matches the target structure according to the target processing logic rules. If it exists, it directly processes the first key field data into target vehicle network data that matches the target structure according to the target processing logic rules.

[0262] Object generator 504 is used to generate a unified data model object for the Internet of Vehicles based on the target structure and the target Internet of Vehicles data, and send the unified data model object to the business system.

[0263] Furthermore, the vehicle network data processing system provided in this application embodiment determines the first mapping configuration file through the following method:

[0264] Based on the combined protocol information corresponding to the vehicle network data, the storage address matching the combined protocol information is queried from the pre-configured file search manual, and the second mapping configuration file is obtained from the storage address;

[0265] Based on the attribute information and operation behavior information of the second mapping configuration file, determine the target verification method for the second mapping configuration file;

[0266] The second mapping configuration file is verified according to the target verification method, and a verification pass flag is added to the second mapping configuration file that passes the verification to obtain the first mapping configuration file.

[0267] Furthermore, the vehicle network data processing system provided in this application embodiment dynamically loads the second mapping configuration file in the following manner to achieve uninterrupted service updates and ensure data consistency, specifically including:

[0268] Loading timing control: Combining real-time query per second (QPS), CPU utilization, and queue backlog, configuration loading is triggered when the system load is below a preset threshold; and it supports loading new configurations in batches by device type, tenant ID, or protocol type, including applying the configuration to a preset proportion of non-core devices, and then fully promoting it after observing for a preset period of time without any abnormalities.

[0269] Atomicity and version management: New configurations are loaded into an independent memory area. After verification, the pointer is atomically switched to point to the new version. Old configurations are released asynchronously after they are no longer referenced. Each load generates a unique version ID. If the new configuration causes the error rate to increase, it can be rolled back to the previous stable version.

[0270] Loading and scheduling optimization: Configuration loading is handled by an independent thread pool, which does not block I / O threads; only modified mapping rule fragments are reloaded, instead of the full configuration; configuration is read from the local disk / memory cache first, and the latest version is asynchronously pulled from the remote server in the background to achieve fast startup and eventual consistency;

[0271] Observability and circuit breaker fallback: Record the time taken for each loading, the number of successes / failures, the trigger source and the affected protocol type to generate observability metrics; if three consecutive loading failures occur, automatically pause automatic updates and issue an alarm to prevent incorrect configurations from repeatedly impacting the system; and when loading fails, continue to use the currently effective configuration and record error logs to ensure business continuity.

[0272] Furthermore, in the vehicle network data processing system provided in this application embodiment, the step of determining the target verification method for the second mapping configuration file based on the attribute information and operation behavior information of the second mapping configuration file includes:

[0273] Based on the operation behavior information of the second mapping configuration file, it is determined whether the second mapping configuration file meets the scene verification conditions. If it does, the first verification method matching the scene verification conditions is obtained. If it does not meet, the first verification method is not obtained. The second mapping configuration file meeting the scene verification conditions includes reading the second mapping configuration file for the first time or the time since the last scene verification being greater than a preset time.

[0274] Based on the attribute information of the second mapping configuration file, determine the second verification method that matches the attribute information;

[0275] The first verification method and the second verification method are determined as the target verification method; or, the second verification method is determined as the target verification method.

[0276] Furthermore, in the vehicle network data processing system provided in this application embodiment, the second mapping configuration file includes configuration data; when verifying the second mapping configuration file, the second mapping configuration file is parsed into structured data in computer memory;

[0277] The first verification method includes: verifying the correctness of the physical characteristics of the vehicle network data, the feasibility of the vehicle network data business logic, and the security of the vehicle network data for the structured data in the second mapping configuration file;

[0278] The second verification method includes: pre-processing of syntax and semantic verification and sandbox simulation verification. Pre-processing of syntax and semantic verification includes: performing JSON / YAML format validity checks, field mapping path existence checks, and circular dependency detection before loading. Sandbox simulation verification includes: using historical message samples to test the new configuration in an isolated environment to verify whether the output model meets expectations.

[0279] Furthermore, the vehicle network data processing system provided in this application embodiment includes verifying the vehicle network data security of the structured data in the second mapping configuration file, including:

[0280] In the unified data model registry center, security compliance metadata is defined for the target metrics. The security compliance metadata includes the data classification tags of the target metrics and the identifiers of the data processing components that must be associated with them.

[0281] After loading the semantic mapping rules in the second mapping configuration file, the system retrieves the policy metadata corresponding to the target metric from the registry center and determines whether the data category label of the target metric belongs to a predefined controlled data category. If it does, the system further verifies whether the configuration of the semantic mapping rule has correctly associated with the data processing component that must be associated as specified in the policy metadata. If it is not correctly associated, the system determines that the verification has failed and prevents the semantic mapping rule from taking effect or issues a security alert. The semantic mapping rule defines the mapping relationship from the data source to the target metric and includes reference information to the data processing component.

[0282] Furthermore, the vehicle network data processing system provided in this application embodiment, wherein the step of constructing the target processing logic rule based on the configuration data in the first mapping configuration file, and processing the first key field data into target vehicle network data matching the target structure according to the target processing logic rule, includes:

[0283] A rule execution network is constructed in memory, which includes at least: a rule hash table: the key of which is a composite key generated by concatenating the protocol identifier of the original protocol and the original field name, and the value of which is the corresponding target mapping rule and the pre-compiled executable unit; a condition judgment tree: used to organize and manage mapping rules containing conditional expressions, the nodes of the tree are condition judgment logic, and the leaf nodes are the corresponding mapping rule sets;

[0284] The first key field data is used as the raw data input, and the semantic mapping engine performs matching and retrieval in the rule hash table based on the composite key generated by its protocol identifier and the original field name.

[0285] If a match is successful, the semantic mapping engine executes a predefined programmable data transformation process to generate standard data for the target structure. The programmable data transformation process includes at least numerical calculations based on configuration expressions. If a match fails, the engine traverses the conditional judgment tree to find matching conditional rules, executes the pre-compiled executable unit corresponding to the matching rule, and generates standard data for the target structure.

[0286] Furthermore, in the vehicle network data processing system provided in this application embodiment, the pre-compiled executable unit includes: an expression executor, a unit converter, an enumeration normalizer, a conditional filter, and a hot update listener; the pre-compiled executable unit corresponding to the execution matching rule generates standard data of the target structure, including:

[0287] The expression executor executes user-defined expressions to dynamically calculate, transform, or logically process the original field values, generating the values ​​of the target VUDM fields.

[0288] The unit converter provides standardized unit conversion capabilities, automatically converting non-standard units in the raw data into uniform units defined in the VUDM model;

[0289] The enumeration normalizer maps enumeration values ​​from different protocols to unified semantic enumeration values ​​defined in the VUDM model; the enumeration values ​​include at least: status codes, text descriptions, and Boolean values;

[0290] The conditional filter determines whether to map or filter a certain piece of data based on user-defined conditional expressions, and supports complex combinations of multiple conditions.

[0291] The hot update listener monitors for changes to the semantic mapping configuration file and automatically reloads the mapping rules when a change is detected, without requiring a system restart.

[0292] Furthermore, the vehicle network data processing system provided in this application embodiment further includes a protocol fingerprint extraction module, a templated mapping module, and a mode switching control module in the unified data model; the method further includes:

[0293] The control mode switching control module is used to switch from the current mode to the high-performance degradation mode in response to the server's real-time load index for processing the protocol messages meeting the mode switching conditions or in response to the trigger operation of the mode switching switch by a user with specified permissions.

[0294] The protocol fingerprint extraction module, the templated mapping module, and the asynchronous fallback verification module obtain target vehicle network data that matches the target structure in the protocol message under the high-performance degradation mode;

[0295] The determination that the real-time load indicators of the protocol message processing meet the mode switching conditions includes: real-time monitoring of the server's throughput, CPU utilization, memory usage, and queue backlog for protocol messages; when at least one of the protocol message throughput, CPU utilization, memory usage, and queue backlog is detected to meet the corresponding threshold conditions within a unit time, and the current business context does not belong to a non-critical data scenario, it is determined that the real-time load indicators of the protocol message processing meet the mode switching conditions.

[0296] The protocol fingerprint extraction module uses a pre-trained lightweight model to extract the message header and key fields to generate a protocol fingerprint. The key fields include: device ID, message type, and timestamp. The templated mapping module uses an offline-trained time-series prediction model to fill in the missing data of the key fields and matches a predefined unified model template according to the protocol fingerprint, outputting the processing result through the unified model template. The asynchronous fallback verification module puts the processing result into a low-priority queue, which is then verified and corrected by a background task to obtain the target vehicle network data.

[0297] The semantic mapping engine includes a mapping configuration loader, an expression executor, a unit converter, an enumeration normalizer, a conditional filter, and a hot update listener, and executes the corresponding core content based on these execution units.

[0298] As shown in Figure 6, an electronic device 600 provided in this application embodiment includes: a processor 601, a memory 602, and a bus. The memory 602 stores machine-readable instructions that can be executed by the processor 601. When the electronic device is running, the processor 601 communicates with the memory 602 through the bus, and the processor 601 executes the machine-readable instructions to perform the steps of the above-described vehicle network data processing method.

[0299] Specifically, the aforementioned memory 602 and processor 601 can be general-purpose memory and processor, without any specific limitations. When the processor 601 runs the computer program stored in the memory 602, it can execute the aforementioned method for processing vehicle network data.

[0300] Corresponding to the above-described method for processing vehicle network data, this application embodiment also provides a computer-readable storage medium storing a computer program, which, when run by a processor, executes the steps of the above-described method for processing vehicle network data.

[0301] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system described above can be referred to the corresponding process in the method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed system and method can be implemented in other ways. The system embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection can be an indirect coupling or communication connection through some communication interfaces, devices, or modules, and can be electrical, mechanical, or other forms.

[0302] The modules described as separate components may or may not be physically separate. The components shown as modules 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 units can be selected to achieve the purpose of this embodiment according to actual needs.

[0303] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0304] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0305] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for processing vehicle network data, characterized in that, This method is applied to a unified data model, which includes a target interface, a protocol parser, a semantic mapping engine, and an object generator. The method includes: receiving protocol messages from different vehicle terminals based on the target interface; determining the protocol type of the protocol message using the protocol parser; and parsing the protocol message using a parsing rule matching the protocol type to obtain first key field data. The protocol message includes vehicle-to-everything (V2X) data. The semantic mapping engine determines whether target processing logic rules exist for each original protocol and target structure in the combined protocol information based on the combined protocol information. If not, it queries and reads a first mapping configuration file matching the combined protocol information from a configuration file library, constructs the target processing logic rules based on the configuration data in the first mapping configuration file, and processes the first key field data into target V2X data matching the target structure according to the target processing logic rules. If it exists, it directly processes the first key field data into target V2X data matching the target structure according to the target processing logic rules. The object generator generates a unified V2X data model object based on the target structure and the target V2X data and applies the unified data model to the target structure. The data model object is sent to the business system; the step of constructing the target processing logic rule based on the configuration data in the first mapping configuration file, and processing the first key field data into target vehicle network data matching the target structure according to the target processing logic rule, includes: constructing a rule execution network in memory, the rule execution network including at least: a rule hash table: its key is a composite key generated by concatenating the protocol identifier and the original field name of the original protocol, and its value is the corresponding target mapping rule and the pre-compiled executable unit; a condition judgment tree: used to organize and manage mapping rules containing conditional expressions, the nodes of the tree are conditional judgment logic, and the leaf nodes are the corresponding mapping rule sets; the first key field data is used as the input raw data, and the semantic mapping engine performs matching and retrieval in the rule hash table based on the composite key generated by its protocol identifier and the original field name; if the match is successful, the semantic mapping engine executes a predefined programmable data transformation process to generate standard data of the target structure, the programmable data transformation process includes at least numerical calculation based on the configuration expression; if the match fails, the condition judgment tree is traversed to find the matching conditional rule, the pre-compiled executable unit corresponding to the matching rule is executed, and the standard data of the target structure is generated.

2. The method for processing vehicle network data according to claim 1, characterized in that, The first mapping configuration file is determined by the following method: based on the combined protocol information corresponding to the vehicle network data, a storage address matching the combined protocol information is queried from a pre-configured file lookup manual, and a second mapping configuration file is obtained from the storage address; based on the attribute information and operation behavior information of the second mapping configuration file, a target verification method is determined for the second mapping configuration file; the second mapping configuration file is verified according to the target verification method, and a verification pass identifier is added to the second mapping configuration file that passes the verification, thereby obtaining the first mapping configuration file.

3. The method for processing vehicle network data according to claim 2, characterized in that, The second mapping configuration file is dynamically loaded in the following ways to ensure uninterrupted service updates and data consistency: Loading timing control: Based on real-time query per second (QPS), CPU utilization, and queue backlog, configuration loading is triggered when the system load is below a preset threshold; it also supports batch loading of new configurations by device type, tenant ID, or protocol type, including applying it to a preset proportion of non-core devices, and then fully rolling it out after observing for a preset period without any anomalies; Atomicity and version management: New configurations are loaded into an independent memory area, and after successful verification, the pointer is atomically switched to point to the new version; the old configuration is asynchronously released after it is no longer referenced; and a unique version ID is generated for each load. The configuration error rate increases, and a rollback to the previous stable version is possible. Loading scheduling is optimized: configuration loading is handled by an independent thread pool, without blocking I / O threads; only modified mapping rule fragments are reloaded, rather than the entire configuration; configuration is preferentially read from the local disk / memory cache, and the latest remote version is asynchronously pulled in the background to achieve fast startup and eventual consistency; observability and circuit breaker fallback: the loading time, number of successes / failures, trigger source, and affected protocol type are recorded for each load, generating observability metrics; if three consecutive load failures occur, automatic updates are automatically paused and an alarm is issued to prevent erroneous configurations from repeatedly impacting the system; and when loading fails, the currently effective configuration continues to be used and error logs are recorded to ensure business continuity.

4. The method for processing vehicle network data according to claim 2, characterized in that, The step of determining the target verification method for the second mapping configuration file based on its attribute information and operation behavior information includes: determining whether the second mapping configuration file meets the scene verification conditions based on the operation behavior information of the second mapping configuration file; if it does, obtaining the first verification method matching the scene verification conditions; if it does not, not obtaining the first verification method; wherein, the second mapping configuration file meeting the scene verification conditions includes reading the second mapping configuration file for the first time or the duration since the last scene verification being greater than a preset duration; determining the second verification method matching the attribute information based on the attribute information of the second mapping configuration file; determining the first verification method and the second verification method as the target verification method; or, determining the second verification method as the target verification method.

5. The method for processing vehicle network data according to claim 4, characterized in that, The second mapping configuration file includes configuration data; when validating the second mapping configuration file, the second mapping configuration file is parsed into structured data in computer memory; The first verification method includes: verifying the correctness of the physical characteristics of the vehicle network data, the feasibility of the vehicle network data business logic, and the security of the vehicle network data in the structured data in the second mapping configuration file; the second verification method includes: pre-processing of syntax and semantic verification and sandbox simulation operation verification: wherein, the pre-processing of syntax and semantic verification includes: performing JSON / YAML format legality checks, field mapping path existence checks, and circular dependency detection before loading; the sandbox simulation operation verification includes: using historical message samples to test the new configuration in an isolated environment to verify whether the output model meets expectations.

6. The method for processing vehicle network data according to claim 3, characterized in that, in, Verification of vehicle-to-everything (V2X) data security is performed on the structured data in the second mapping configuration file, including: defining security compliance metadata for the target indicator in the unified data model registry center, the security compliance metadata containing the data classification label of the target indicator and the identifier of the data processing component that must be associated; after loading the semantic mapping rules in the second mapping configuration file, obtaining the policy metadata corresponding to the target indicator from the registry center, and determining whether the data classification label of the target indicator belongs to the predefined controlled data category; if it belongs, further verifying whether the configuration of the semantic mapping rule has correctly associated the data processing component that must be associated as specified in the policy metadata; if it is not correctly associated, the verification is deemed to have failed, and the semantic mapping rule is prevented from taking effect or a security alarm is issued; wherein, the semantic mapping rule defines the mapping relationship from the data source to the target indicator and contains reference information to the data processing component.

7. The method for processing vehicle network data according to claim 1, characterized in that, The pre-compiled executable unit includes: an expression executor, a unit converter, an enumeration normalizer, a conditional filter, and a hot update listener. The execution of the pre-compiled executable unit corresponding to the matching rule generates standard data for the target structure, including: executing user-defined expressions through the expression executor to dynamically calculate, transform, or logically process the original field values ​​to generate the values ​​of the target VUDM fields; providing standardized unit conversion capabilities through the unit converter to automatically convert non-standard units in the original data to unified units defined in the VUDM model; mapping enumeration values ​​from different protocols to unified semantic enumeration values ​​defined in the VUDM model through the enumeration normalizer; the enumeration values ​​include at least: status codes, text descriptions, and Boolean values; determining whether to map or filter a piece of data based on user-defined conditional expressions through the conditional filter, supporting complex multi-condition combinations; and monitoring changes to the semantic mapping configuration file through the hot update listener, automatically reloading the mapping rules when a change is detected.

8. The method for processing vehicle network data according to claim 1, characterized in that, The unified data model further includes a protocol fingerprint extraction module, a templated mapping module, and a mode switching control module; the method further includes: responding to the server's real-time load indicators for processing the protocol messages meeting the mode switching conditions or responding to a trigger operation by a user with specified permissions for a mode switching switch, controlling the mode switching control module to switch from the current mode to a high-performance degradation mode; in the high-performance degradation mode, the target vehicle network data matching the target structure in the protocol messages is obtained through the protocol fingerprint extraction module, the templated mapping module, and the asynchronous fallback verification module; wherein, determining that the real-time load indicators for processing the protocol messages meet the mode switching conditions includes: real-time monitoring of the server's throughput, CPU utilization, memory usage, and queue backlog for protocol messages; when the protocol messages are detected within a unit of time... When at least one of the following—message throughput, CPU utilization, memory usage, and queue backlog—meets the corresponding threshold condition, and the current business context does not belong to a non-critical data scenario, the real-time load indicator of the protocol message processing is determined to meet the mode switching condition. The protocol fingerprint extraction module extracts the message header and key fields to generate a protocol fingerprint using a pre-trained lightweight model. The key fields include: device ID, message type, and timestamp. The templated mapping module fills in the missing data of the key fields using an offline-trained time-series prediction model, and matches a predefined unified model template according to the protocol fingerprint, outputting the processing result through the unified model template. The asynchronous fallback verification module places the processing result into a low-priority queue, which is then verified and corrected by a background task to obtain the target vehicle network data.

9. A vehicle networking data processing system, characterized in that, include: The system comprises a target interface, a protocol parser, a semantic mapping engine, and an object generator. The target interface receives protocol messages from different vehicle terminals. The protocol parser determines the protocol type of the message and uses a parsing rule matching the protocol type to parse the message, obtaining first key field data. The protocol message includes vehicle-to-everything (V2X) data. The semantic mapping engine determines whether target processing logic rules exist for each original protocol and target structure within the combined protocol information based on the combined protocol information. If not, it queries and reads a first mapping configuration file matching the combined protocol information from a configuration file library, constructs the target processing logic rules based on the configuration data in the first mapping configuration file, and processes the first key field data into target V2X data matching the target structure according to the target processing logic rules. If the target structure exists, it directly processes the first key field data into target V2X data matching the target structure according to the target processing logic rules. The object generator generates a unified V2X data model object based on the target structure and the target V2X data and processes the unified data model... The first key field data is sent to the business system. The process of constructing the target processing logic rules based on the configuration data in the first mapping configuration file, and processing the first key field data into target vehicle network data matching the target structure according to the target processing logic rules, includes: constructing a rule execution network in memory, the rule execution network including at least: a rule hash table: its key is a composite key generated by concatenating the protocol identifier and the original field name of the original protocol, and its value is the corresponding target mapping rule and a pre-compiled executable unit; a condition judgment tree: used to organize and manage mapping rules containing conditional expressions, the nodes of the tree are conditional judgment logic, and the leaf nodes are the corresponding mapping rule sets; the first key field data is used as the input raw data, and the semantic mapping engine performs matching retrieval in the rule hash table based on the composite key generated by its protocol identifier and the original field name; if the match is successful, the semantic mapping engine executes a predefined programmable data transformation process to generate standard data of the target structure, the programmable data transformation process including at least numerical calculation based on the configuration expression; if the match fails, the condition judgment tree is traversed to find the matching conditional rule, and the pre-compiled executable unit corresponding to the matching rule is executed to generate standard data of the target structure.

Images