A multi-protocol intelligent alarm monitoring method and system for a vehicle networking multi-dimensional scene

Abstract

The application discloses a kind of multi-protocol's Internet of Vehicles multi-dimensional scene intelligent alarm monitoring method and system, the method includes: configuration multi-protocol special analysis logic;Based on the multi-protocol special analysis logic, obtain and preprocess multi-source heterogeneous data;Dynamic mapping rule base is built, based on the dynamic mapping rule base, the multi-source heterogeneous data after preprocessing is carried out semantic normalization processing, and output structured standard data;Based on the structured standard data, configure multi-dimensional scene alarm rule, based on the multi-dimensional scene alarm rule, fault identification is carried out, and fault identification result is obtained;Based on the fault identification result, hierarchical alarm is generated, and standardization alarm message is generated.The method and system provided by the application can accurately identify non-substantial fault and realize hierarchical alarm.

Description

Technical Field

[0001] This invention relates to the field of vehicle-to-everything (V2X) big data processing and intelligent monitoring technology, and in particular to a multi-protocol V2X multi-dimensional scene intelligent alarm monitoring method and system. Background Technology

[0002] Vehicle-to-everything (V2X) technology is the core means to realize remote vehicle monitoring, fault early warning and intelligent operation and maintenance. With the popularization of various types of vehicles such as new energy vehicles, heavy commercial vehicles and electric two-wheelers, the communication protocols of V2X terminals are showing a trend of diversification and standardization. For example, new energy vehicles need to comply with "GB / T 32960 Technical Requirements for Remote Monitoring Systems of New Energy Vehicles"; heavy commercial vehicles need to comply with "GB 17691 Emission Limits and Measurement Methods for Pollutants from Heavy-Duty Diesel Vehicles"; and electric two-wheelers need to comply with "GB 42295 Technical Specifications for Centralized Charging Facilities for Electric Bicycles".

[0003] Currently, vehicle network monitoring systems in the industry generally suffer from problems such as limited protocol adaptation capabilities and a lack of data standardization. For example, they may only support access to a single protocol and cannot be compatible with multiple national standard protocols at the same time; or even if they partially support access to multiple protocols, they have not built a unified heterogeneous data mapping system, resulting in semantic conflicts and inconsistent formats between heterogeneous data of different protocols. This makes it impossible to form a globally unified view of vehicle operation data, which seriously restricts the efficiency of cross-vehicle and cross-protocol vehicle network big data analysis and application.

[0004] Meanwhile, under mandatory national regulatory requirements, vehicle-to-everything (V2X) terminals are required to report vehicle malfunctions and operational status data in real time, resulting in a massive influx of alarm data into after-sales monitoring systems. However, existing monitoring systems lack effective operational condition identification and scenario discrimination mechanisms. For example, when a vehicle is in the manufacturing stage (such as factory off-line compliance testing), the terminal will proactively trigger a fault alarm to verify the alarm function; when a vehicle is in the after-sales maintenance stage (such as 4S store repair and diagnostic work), repair personnel will connect to the vehicle through a diagnostic tool for debugging, which will also generate non-substantive fault alarms. These non-substantive faults are not actual vehicle operational faults, but they are mixed with real operational faults in the same alarm stream. Existing technology cannot distinguish these scenarios, leading to after-sales departments facing the dilemma of massive invalid alarm interference and excessively high costs for tracking real faults. Summary of the Invention

[0005] In view of the above-mentioned shortcomings in the current field of vehicle network big data processing and intelligent monitoring technology, the present invention provides a multi-protocol vehicle network multi-dimensional scene intelligent alarm monitoring method and system, which can accurately identify non-substantive faults and realize hierarchical alarms.

[0006] To achieve the above objectives, the embodiments of the present invention adopt the following technical solutions:

[0007] A multi-protocol intelligent alarm monitoring method for multi-dimensional scenarios in vehicle networking, the method comprising:

[0008] Configure dedicated parsing logic for multiple protocols;

[0009] Multi-source heterogeneous data is acquired and preprocessed based on the multi-protocol-specific parsing logic;

[0010] A dynamic mapping rule base is constructed, and semantic normalization processing is performed on the preprocessed multi-source heterogeneous data based on the dynamic mapping rule base to output structured standard data.

[0011] Configure multi-dimensional scene alarm rules based on the structured standard data, perform fault identification based on the multi-dimensional scene alarm rules, and obtain fault identification results;

[0012] Based on the fault identification results, a graded alarm is generated, and a standardized alarm message is produced.

[0013] According to one aspect of the present invention, the configuration of multi-protocol dedicated parsing logic specifically involves: building a pluggable parsing architecture based on the Netty asynchronous IO framework to adapt to national standard protocols.

[0014] According to one aspect of the present invention, in the process of acquiring and preprocessing multi-source heterogeneous data based on the multi-protocol dedicated parsing logic, the modes of acquiring the multi-source heterogeneous data include direct connection to vehicle terminals and forwarding by enterprise platforms, and the preprocessing includes message integrity verification, data format normalization, timing consistency processing, and data splitting and storage.

[0015] According to one aspect of the present invention, the construction of a dynamic mapping rule base, and the semantic normalization processing of preprocessed multi-source heterogeneous data based on the dynamic mapping rule base to output structured standard data, specifically includes:

[0016] A dynamic mapping rule base is built based on Nacos;

[0017] Based on the dynamic mapping rule base, semantic normalization processing is performed on the preprocessed multi-source heterogeneous data;

[0018] Perform time synchronization correction on the semantically normalized data to output structured standard data.

[0019] According to one aspect of the present invention, configuring multi-dimensional scene alarm rules based on the structured standard data, and performing fault identification based on the multi-dimensional scene alarm rules to obtain fault identification results, specifically includes:

[0020] Based on the structured standard data, configure a visual orchestration engine and reusable atomic conditional components;

[0021] Based on the aforementioned visual orchestration engine and reusable atomic condition components, multi-dimensional scene alarm rules are pre-set;

[0022] Based on the aforementioned multi-dimensional scenario alarm rules, real operational faults and non-substantive faults are distinguished to obtain fault identification results.

[0023] According to one aspect of the present invention, the preset multi-dimensional scene alarm rules include factory compliance sampling identification rules and after-sales maintenance diagnosis identification rules.

[0024] According to one aspect of the present invention, the step of distinguishing between real operational faults and non-substantive faults based on the multi-dimensional scenario alarm rules to obtain fault identification results specifically involves: constructing a distributed stream computing architecture based on Flink; and executing fault identification algorithms such as geofence matching, sliding window condition analysis, and suspected non-operational data identification based on the distributed stream computing architecture to obtain fault identification results.

[0025] According to one aspect of the present invention, the suspected non-operational data identification algorithm specifically comprises: reading the vehicle context state based on Flink, combining the multi-dimensional scene alarm rules to perform feature determination, and obtaining scene labels and confidence scores.

[0026] According to one aspect of the present invention, in the graded alarm based on the fault identification result, the graded alarm specifically includes L1 interference items, L2 items to be verified items, and L3 actual faults.

[0027] A multi-protocol vehicle-to-everything (V2X) multi-dimensional scene intelligent alarm monitoring system, the system comprising:

[0028] The protocol configuration module configures dedicated parsing logic for multiple protocols;

[0029] The data acquisition and preprocessing module acquires and preprocesses multi-source heterogeneous data based on the multi-protocol-specific parsing logic.

[0030] The data processing module constructs a dynamic mapping rule base, performs semantic normalization processing on the preprocessed multi-source heterogeneous data based on the dynamic mapping rule base, and outputs structured standard data.

[0031] The fault identification module configures multi-dimensional scene alarm rules based on the structured standard data, performs fault identification based on the multi-dimensional scene alarm rules, and obtains fault identification results.

[0032] The result generation module performs graded alarms based on the fault identification results and generates standardized alarm messages.

[0033] The advantages of this invention are as follows: by constructing a pluggable multi-protocol parsing architecture and combining it with a dynamic mapping rule base to achieve the standardization and normalization of heterogeneous data, the problem of data incompatibility between different national standard protocols is solved; through fault identification algorithms, non-operational scenarios such as factory spot checks and 4S maintenance are accurately identified; at the same time, alarm data is traceable throughout the entire chain, providing accurate big data support for the optimization of vehicle manufacturers' operation and maintenance strategies, and significantly improving the efficiency and management quality of vehicle network operation and maintenance. Attached Figure Description

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

[0035] Figure 1 This is a schematic flowchart of a multi-protocol vehicle-to-everything (V2X) multi-scenario intelligent alarm monitoring method according to the present invention.

[0036] Figure 2 This is a schematic diagram of the structure of a multi-protocol vehicle-to-everything (V2X) multi-scenario intelligent alarm monitoring system according to the present invention. Detailed Implementation

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

[0038] Example 1

[0039] like Figure 1 As shown, a multi-protocol vehicle-to-everything (V2X) multi-scenario intelligent alarm monitoring method is provided, which specifically includes the following steps:

[0040] Step S1: Configure multi-protocol dedicated parsing logic;

[0041] The specific steps for configuring multi-protocol dedicated parsing logic in step S1 are as follows:

[0042] (1) Constructing a plug-in parsing architecture

[0043] An asynchronous I / O access engine is built based on Netty, featuring a pluggable protocol parsing architecture. It enables dual-port listening for TCP / UDP, and configures parameters for I / O thread pools, business thread pools, and memory pools. A single node can meet the requirement of ≥100,000 TPS packet access. It also includes a built-in protocol recognition gateway that automatically identifies routes based on packet header characteristics.

[0044] For the GB / T 32960 (New Energy Vehicles) protocol, configure an identification rule using 0x23 as the message start character; for the GB 17691 (Heavy Commercial Vehicles) protocol, configure an identification rule based on the J1939 protocol-specific CAN extended frame ID; for the GB42295 (Electric Two-Wheeled Vehicles) protocol, configure an identification rule for lightweight messages with a fixed message header. After identification, the message is automatically routed to the corresponding protocol's dedicated parsing plugin, and a corresponding enumeration value (protocol_type) identifier is generated to avoid cross-protocol parsing errors.

[0045] Furthermore, a consistent hashing algorithm is introduced into the access engine to directly bind different vehicle VIN codes (Vehicle Identification Numbers) to processing nodes, ensuring the temporal consistency of all data for the same vehicle. A unified ProtocolParser standard Java interface is defined at the protocol adaptation layer. This interface includes pre-defined core abstract methods: parse (message parsing), verify (integrity verification), and getProtocolType (protocol type retrieval). All protocol-specific parsing plugins must implement this interface to ensure standardized parsing logic.

[0046] (2) Configure dedicated parsing logic for mainstream national standard protocols

[0047] For the three core national standard protocols—GB / T 32960, GB 17691, and GB 42295—dedicated parsing logic is configured for mainstream national standard protocols, specifically including:

[0048] 1. GB / T 32960 Protocol Dedicated Parsing Logic

[0049] For fixed-length binary messages reported by T-Boxes of new energy vehicles that comply with the "Technical Requirements for Remote Monitoring Systems of New Energy Vehicles" (GB / T 32960), a CRC16 integrity check is first performed. After the check passes, according to the pre-defined field offset, data type, and length definition table in the protocol specification, the original data in the message is extracted segment by segment according to the offset using a dedicated parsing plugin, completing the binary to decimal value conversion. The final standardized output fields include: VIN code, drive motor status parameters (speed, torque, temperature), fuel cell parameters (hydrogen pressure, temperature), remaining SOC battery charge, vehicle speed, terminal timestamp, original latitude and longitude of positioning, ignition status, diagnostic tool connection status, and other core fields.

[0050] 2. GB 17691 Protocol Dedicated Parsing Logic

[0051] For the J1939 derived protocol messages reported by the T-Box of heavy-duty commercial vehicles that comply with "GB 17691 Emission Limits and Measurement Methods for Pollutants from Heavy-Duty Diesel Vehicles", a BCC integrity check is first performed. After the check passes, the CAN data frame parsing rules are configured according to the J1939 protocol specification. The PGN parameter group number in the protocol frame is parsed using a dedicated parsing plugin to extract the original operating data of core controllers such as the engine ECU and transmission, and complete the basic data format conversion. Finally, standardized output fields are obtained, including core fields such as VIN code, engine ECU operating parameters (speed, fuel consumption), fuel level, vehicle speed, terminal timestamp, original latitude and longitude of positioning, ignition status, and diagnostic tool connection status.

[0052] 3. GB 42295 protocol-specific parsing logic

[0053] For lightweight binary / text messages reported by on-board terminals of electric two-wheeled vehicles that comply with the "GB 42295 Technical Specification for Centralized Charging Facilities for Electric Bicycles", the following steps are taken: First, configure the BCC integrity verification rules according to the protocol specification, extract the message check bits, and recalculate the message body check value to complete the integrity verification. After the verification is successful, configure the extraction rules for the core fields of the lightweight message according to the protocol specification, and extract core fields such as battery BMS data and positioning data through a dedicated parsing plugin to complete the basic data type conversion. Finally, standardized output fields are obtained, including core fields such as VIN code, battery BMS parameters (voltage, current, remaining power percentage), original positioning latitude and longitude, vehicle speed, and terminal timestamp.

[0054] All the protocol parsing metadata arrays (i.e., the output standardized fields) mentioned above are stored in JSON format in the Nacos 2.2.3 configuration center, supporting visual configuration and version management. Configuration changes are supported with hot reloading without service restart. For newly added non-standard protocols, simply implement the ProtocolParser interface and configure the metadata in Nacos to quickly complete the adaptation.

[0055] Step S2: Obtain and preprocess multi-source heterogeneous data based on the multi-protocol-specific parsing logic;

[0056] Step S2 involves acquiring multi-source heterogeneous data based on the multi-protocol-specific parsing logic; specifically, it includes:

[0057] To address the varying IT infrastructure needs of different automakers, two data acquisition modes are configured: direct connection to in-vehicle terminals and forwarding to the enterprise platform. Specifically:

[0058] 1. Direct connection mode of vehicle terminal (T-Box)

[0059] The original T-Box encapsulates messages according to national standard protocols through its built-in 4G / 5G wireless communication module. Under normal working conditions, it reports data every 10 seconds, and under fault conditions (when the T-Box detects fault codes, sensor abnormalities, etc. in the vehicle), it reports data every 1 second. The message is routed to the corresponding protocol-specific parsing plugin configured in step S1 by the protocol identification gateway of the access engine according to the identification result. The parsing plugin completes the initial parsing of the message and extracts standardized raw data.

[0060] 2. Enterprise Platform Forwarding Model

[0061] Automakers use their own vehicle networking monitoring platforms to perform initial data collection, cleaning, and structuring of vehicle data, including standardized fault codes, vehicle speed, location, VIN codes, and other structured core data. The platform connects the structured vehicle data to the access engine at a preset frequency via standardized MQTT and HTTP interfaces. The access engine verifies the VIN code validity and field integrity of the received structured data. If the verification passes, it skips the protocol parsing step and directly proceeds to the preprocessing stage.

[0062] The preprocessing of the acquired multi-source heterogeneous data in step S2 specifically includes:

[0063] For the multi-source heterogeneous data acquired in the above two modes, standardized preprocessing is performed, including message integrity verification, data format normalization, timing consistency processing, and data splitting and storage. Specifically:

[0064] 1. Message integrity verification pre-

[0065] For messages obtained in the direct connection mode of the vehicle terminal, the verification rules configured in the corresponding protocol parsing plugin in step S1 are called to perform integrity verification: GB / T 32960 protocol messages are checked with CRC16, and GB 17691 and GB 42295 protocol messages are checked with BCC; if the verification fails, the message is directly discarded and a discard log is generated. The log contains the VIN code, message reception time, reason for discard, etc., and the log is synchronously written to the MySQL audit database.

[0066] For structured data obtained from the enterprise platform forwarding mode, perform field integrity verification, check whether core fields (VIN code, timestamp, vehicle speed, fault code) are missing, and directly mark the message with missing core fields as invalid data and archive it into the MySQL audit database.

[0067] 2. Data format normalization

[0068] All numerical fields are converted from binary to decimal. Vehicle speed is standardized to the integer unit km / h, and remaining energy fields are standardized to the floating-point unit %, with timestamps standardized to the millisecond-level Unix timestamp format. For VIN codes, it is verified whether they are in the 17-bit standard format, and messages with non-compliant VIN codes are marked as invalid data.

[0069] 3. Timing consistency

[0070] By using the consistent hashing algorithm of the access engine, all messages with the same VIN code are routed to the same processing node for processing. Specifically, for each received message, a server receiving timestamp (timestamp_server) is assigned and bound to the terminal local timestamp (timestamp_terminal) carried in the message for storage. Messages from the same vehicle are grouped by VIN code, and are initially sorted by terminal timestamp, out-of-order messages are marked and out-of-order deviations are recorded.

[0071] 4. Data offloading and storage

[0072] For preprocessed valid data, a dual-path split storage is implemented: For structured preprocessed data, it is written to the Redis Cluster distributed cache for temporary storage, with the cache key prefixed with the VIN code and the cache expiration time set to 24 hours; For raw binary messages / raw structured data, a 32-bit raw message fingerprint (raw_signature) is generated using the MD5 encryption algorithm, and after being bound to the message data, VIN code, and receiving timestamp, it is asynchronously written to the ClickHouse raw message library in batches of 1 second each, for subsequent end-to-end data traceability, auditing, and anti-tampering verification.

[0073] Step S3: Construct a dynamic mapping rule base, and perform semantic normalization processing on the preprocessed multi-source heterogeneous data based on the dynamic mapping rule base to output structured standard data;

[0074] In step S3, a dynamic mapping rule base is constructed. Based on the dynamic mapping rule base, semantic normalization processing is performed on the preprocessed multi-source heterogeneous data to output structured standard data; specifically:

[0075] Step S31: Construct a dynamic mapping rule base based on Nacos; specifically:

[0076] A visual dynamic mapping rule library is built in the Nacos configuration center. All rules are stored in a standardized JSON format, specifically including:

[0077] Protocol base mapping: Configure basic attributes such as unique identifiers, message characteristics, and verification methods for GB / T 32960, GB 17691, and GB 42295 protocols, establish the association between protocol types and subsequent field mapping rules, and achieve automatic matching of corresponding conversion rules according to protocols. The protocol enumeration value generated by the protocol identification gateway in step S1 is directly assigned to the `protocol_type` field of the structured standard data.

[0078] Same semantic field mapping: Configures a one-to-one mapping relationship between fields with the same meaning but different names and formats in different protocols, including:

[0079] Energy-related field mapping: The SOC of GB / T 32960, FuelLevel of GB 17691, and BatteryPercent (remaining battery percentage) of GB 42295 are uniformly mapped to the standard field energy_level;

[0080] Location field mapping: Map latitude and longitude fields with different names from various protocols to the standard fields location.lat and location.lon;

[0081] Basic status field mapping: Map the vehicle speed, ignition status, gear, and total mileage fields of each protocol to the standard fields status.speed, status.ignition_status, status.gear, and total_mileage, respectively.

[0082] Data type and unit conversion rules: Configure conversion rules for physical quantities to percentages (such as fuel liters to fuel level percentage, battery ampere-hours to remaining charge percentage).

[0083] Fault code-specific mapping rules: Configure format conversion rules for fault codes of different protocols, including: GB / T 32960 and GB 42295 protocols extract fault codes of the whole vehicle, drive motor, battery, fuel cell, etc. according to the specifications, and initially integrate them into a fault code array (fault_codes); GB 17691 protocol converts the suspicious parameter number SPN and fault mode identifier FMI in the message into a general string format of "SPN-XXX-FMI-XXX" according to the "SAE J1939-73" standard, and initially integrates them into fault_codes.

[0084] Adding a new non-national standard protocol requires adding the corresponding basic mapping and field conversion rules to the dynamic mapping rule base.

[0085] Step S32: Perform semantic normalization on the preprocessed multi-source heterogeneous data based on the dynamic mapping rule base; specifically:

[0086] Load the dynamic mapping rule library from the Nacos configuration center, automatically match corresponding rules to the preprocessed multi-source heterogeneous data according to protocol type, and perform semantic normalization on a field-by-field basis, specifically including:

[0087] Energy field normalization: Call the energy field mapping in the dynamic mapping rule library to uniformly convert the remaining energy data of vehicles with different power types into the energy_level field; if the original data is a physical quantity, it is first converted into a percentage by the vehicle rated parameters preset in the dynamic mapping rule library, and then assigned after 3-Sigma outlier cleaning, and finally output as 0-100 floating-point data, retaining 1 decimal place.

[0088] Location field normalization: Call the location class field mapping in the dynamic mapping rule library to uniformly convert the original latitude and longitude of each protocol into WGS84 decimal system format; after 3-Sigma outlier cleaning and coordinate calibration, output latitude and longitude with 4 decimal places and encapsulate them into a location standard object.

[0089] Fault code field normalization: Call the fault code-specific mapping rules in the dynamic mapping rule library to convert the original fault codes of each protocol into a unified string format, filter the temporary test fault codes marked in the dynamic mapping rule library, and integrate them into a unified fault_codes string array, which is an empty array when there is no fault.

[0090] Basic status field normalization: Call the basic status class field mapping rules in the dynamic mapping rule library to unify the data type and value format of fields such as vehicle speed, ignition status, gear, and cumulative mileage.

[0091] Step S33: Perform time synchronization correction on the semantically normalized data and output structured standard data.

[0092] Time synchronization correction: Calculate the deviation between timestamp_terminal and timestamp_server. ,like (5 minutes), directly use timestamp_terminal as the standardized timestamp, and set time_sync_flag (time synchronization flag) to false; if Use timestamp_server as the standardized timestamp and set time_sync_flag to true.

[0093] The normalized and filtered standard data is encapsulated into StandardVehicleEvent according to the structured standard data defined by the dynamic mapping rule base. This includes VIN, protocol_type, timestamp, time_sync_flag, location (including lat and lon), and status (including core fields such as speed, energy_level, gear, fault_codes, ignition_status, total_mileage, and raw_signature). Data is then asynchronously written to ClickHouse in batches of 1 second each.

[0094] Step S4: Configure multi-dimensional scene alarm rules based on the structured standard data, perform fault identification based on the multi-dimensional scene alarm rules, and obtain fault identification results;

[0095] Step S4 configures multi-dimensional scene alarm rules based on the structured standard data, and performs fault identification based on the multi-dimensional scene alarm rules to obtain fault identification results; specifically:

[0096] Step S41: Configure a visualization orchestration engine and reusable atomic conditional components based on the structured standard data; specifically:

[0097] The front-end drag-and-drop visual operation interface is developed based on Drools. All fields of the StandardVehicleEvent output in step S33 are encapsulated into reusable atomic condition components in the format of "parameter + operator + threshold". The core components include fault_codes non-empty judgment, energy_level threshold judgment, speed threshold judgment, geofence matching, Duration time window statistics, and total_mileage threshold judgment. The front-end drag-and-drop enables the nesting of AND, OR, and NOT logic and the combination of sequence patterns of atomic components. The combined rules are automatically compiled into Drools scriptable rules.

[0098] Step S42: Based on the orchestration engine and reusable atomic condition components, pre-set multi-dimensional scene alarm rules; specifically:

[0099] The multi-dimensional scenario alarm rules are composite rules for non-substantive fault scenarios, specifically including:

[0100] (1) Rules for identifying compliance during factory inspection

[0101] Combine the four atomic conditions and use AND logic: Location IN Factory_Zone (geofence matching); (Low mileage determination); (Fault code is not empty). This is used to identify test faults triggered when the vehicle is inside the factory fence and has a very short mileage (before leaving the factory).

[0102] (2) After-sales maintenance diagnosis and identification rules

[0103] Combine 5 atomic conditions using AND logic: Location IN 4S_Dealer_List (geofence matching); (Ignition status judgment); (Static condition determination); (Diagnostic instrument connection status determination) (Fault code non-empty determination). Used to identify maintenance and debugging faults triggered when the vehicle is within the 4S store enclosure, stationary and not being driven, and connected to a diagnostic tool.

[0104] Once configured, non-substantive fault composite rules are compiled into binary decision tables (simple rules) or CEP pattern description files (complex sequence rules), uploaded to the Nacos configuration center, and pushed in shards according to Flink cluster nodes; the Flink compute cluster monitors configuration changes in real time, pulls the latest rules, and loads them into memory.

[0105] Step S43: Based on the multi-dimensional scenario alarm rules, distinguish between real operational faults and non-substantive faults to obtain fault identification results; specifically:

[0106] A distributed stream computing architecture based on Apache Flink is built, integrating algorithms such as real-time geofencing matching, sliding window condition analysis, and identification of suspected non-operational data to accurately distinguish between real operational faults and non-substantive faults. Specifically:

[0107] Step S431: Build a distributed stream computing architecture based on Flink

[0108] A distributed stream computing architecture is built on Flink, integrating Redis Cluster as auxiliary storage, ClickHouse as big data storage, and MySQL as relational storage to achieve high throughput of ≥100,000 TPS and low latency of ≤100ms. All data in the chain uses VIN as the unique association key, and StandardVehicleEvent is written to both the Flink data source and ClickHouse. The Redis Cluster stores geofence-based GeoHash-encoded indexes for the factory and the 4S store.

[0109] Step S432: Based on the distributed stream computing architecture, execute fault identification algorithms such as geofence matching, sliding window condition analysis, and suspected non-operational data identification to obtain fault identification results, specifically including:

[0110] (1) Execute the geofence real-time matching algorithm

[0111] The vehicle's standardized location is geohash encoded with 12-bit precision and matched with the geofence geofence geohash index of the factory and 4S store stored in Redis Cluster to determine whether the vehicle is within the geofence, thus meeting the real-time computing requirements.

[0112] (2) Execute the sliding window working condition analysis algorithm

[0113] Based on the event time, each vehicle is divided into a 5-minute window and a 1-minute step sliding window according to the VIN. The average vehicle speed, maximum vehicle speed, position displacement, and fault code duration within the window are counted. The average vehicle speed and position displacement are used to determine whether the vehicle is stationary, low speed, or high speed, and the results are stored in Flink.

[0114] (3) Execute the algorithm for identifying suspected non-operational data.

[0115] Based on Flink's reading of vehicle context state, feature determination is performed using a composite rule template for non-substantive fault scenarios; if the factory compliance spot check identification rule is matched, the output is... (Suspected factory test data) If the after-sales service diagnosis and identification rules are matched, output the results. (Suspected 4S store repair data) If no rule is hit, output: (Real operational failure) ,in, For scene tags, Calculate the confidence level.

[0116] The fault recognition results are encapsulated into FaultRecognitionResult, which includes core fields such as VIN, fault_codes, sceneTag, confidenceScore, and recognition time, and written to ClickHouse and MySQL in real time.

[0117] Step S5: Based on the fault identification results, implement hierarchical alarm and generate standardized alarm messages.

[0118] Based on the fault identification results generated in step S4, a tiered alarm system is implemented, specifically as follows:

[0119] Level 1 (Interference): Automatic archiving does not generate maintenance work orders; it is only used for test statistics.

[0120] Level 2 (Item to be verified): The message was sent to the after-sales work group for manual verification.

[0121] Level 3 (real fault): Immediately generate a repair work order and trigger a strong reminder; in addition, results with a confidence level of less than 60% are marked as invalid and the identification process is repeated.

[0122] Generate standardized alarm messages:

[0123] Extract the core fields (including VIN, fault_codes, sceneTag, confidenceScore, etc.) from FaultRecognitionResult from MySQL and the core fields (including VIN, timestamp, time_sync_flag, raw_signature, etc.) from StandardVehicleEvent from ClickHouse, generate a unique alarm identifier (alarm_id) and a source tracing link, encapsulate them into a standardized JSON message, and write them to both MySQL and ClickHouse.

[0124] Furthermore, the aforementioned intelligent alarm monitoring method for multi-dimensional scenarios in the Internet of Vehicles also includes the deployment of a visual monitoring and auxiliary decision-making interface, specifically: pulling real-time alarm messages from MySQL and displaying them visually in a differentiated manner according to their level (e.g., L1 gray folding, L2 yellow highlighting, L3 red flashing); and supporting clicking on alarms to view the rule hit chain and full-link data traceability, providing one-click verification, one-click dispatch, one-click archiving and other operations.

[0125] Example 2

[0126] like Figure 2 As shown, a multi-protocol vehicle-to-everything (V2X) multi-scenario intelligent alarm monitoring method and system is described in this embodiment, which applies the method described in Embodiment 1. The system includes:

[0127] Protocol configuration module M1 configures dedicated parsing logic for multiple protocols;

[0128] The data acquisition and preprocessing module M2 acquires and preprocesses multi-source heterogeneous data based on the multi-protocol-specific parsing logic.

[0129] Data processing module M3 constructs a dynamic mapping rule base, performs semantic normalization processing on preprocessed multi-source heterogeneous data based on the dynamic mapping rule base, and outputs structured standard data.

[0130] The fault identification module M4 configures multi-dimensional scene alarm rules based on the structured standard data, performs fault identification based on the multi-dimensional scene alarm rules, and obtains fault identification results.

[0131] The result generation module M5 performs graded alarms based on the fault identification results and generates standardized alarm messages.

[0132] The advantages of this invention are as follows: by constructing a pluggable multi-protocol parsing architecture and combining it with a dynamic mapping rule base to achieve the standardization and normalization of heterogeneous data, the problem of data incompatibility between different national standard protocols is solved; through fault identification algorithms, non-operational scenarios such as factory spot checks and 4S maintenance are accurately identified; at the same time, alarm data is traceable throughout the entire chain, providing accurate big data support for the optimization of vehicle manufacturers' operation and maintenance strategies, and significantly improving the efficiency and management quality of vehicle network operation and maintenance.

[0133] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention 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 the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A multi-protocol, multi-dimensional intelligent alarm monitoring method for vehicle-to-everything (V2X) scenarios, characterized in that, The method includes: Configure dedicated parsing logic for multiple protocols; Multi-source heterogeneous data is acquired and preprocessed based on the multi-protocol-specific parsing logic; A dynamic mapping rule base is constructed, and semantic normalization processing is performed on the preprocessed multi-source heterogeneous data based on the dynamic mapping rule base to output structured standard data. Based on the structured standard data, multi-dimensional scenario alarm rules are configured, and fault identification is performed based on these rules to obtain fault identification results. Specifically, this involves: configuring a visual orchestration engine and reusable atomic condition components based on the structured standard data; pre-setting multi-dimensional scenario alarm rules based on the visual orchestration engine and reusable atomic condition components; the pre-set multi-dimensional scenario alarm rules include factory compliance sampling identification rules and after-sales maintenance diagnosis identification rules; and distinguishing between real operational faults and non-substantive faults based on these multi-dimensional scenario alarm rules to obtain fault identification results. Specifically, this involves: constructing a distributed stream computing architecture based on Flink; and executing geofence matching, sliding window condition analysis, and suspected non-operational data identification fault identification algorithms based on the distributed stream computing architecture to obtain fault identification results. The suspected non-operational data identification algorithm specifically involves: reading the vehicle context state based on Flink, combining it with the multi-dimensional scenario alarm rules to perform feature determination, and obtaining scenario labels and confidence scores. Based on the fault identification results, a graded alarm is generated, and a standardized alarm message is produced; the graded alarm specifically includes L1 interference items, L2 items to be verified items, and L3 real faults.

2. The intelligent alarm monitoring method for multi-dimensional scenarios in the Internet of Vehicles according to claim 1, characterized in that, The specific configuration of multi-protocol dedicated parsing logic is as follows: a plug-in parsing architecture is built based on the Netty asynchronous IO framework to adapt to national standard protocols.

3. The intelligent alarm monitoring method for multi-dimensional scenarios in the Internet of Vehicles according to claim 1, characterized in that, In the process of acquiring and preprocessing multi-source heterogeneous data based on the multi-protocol dedicated parsing logic, the modes of acquiring the multi-source heterogeneous data include direct connection to vehicle terminals and forwarding by enterprise platforms. The preprocessing includes message integrity verification, data format normalization, timing consistency processing, and data splitting and storage.

4. The intelligent alarm monitoring method for multi-dimensional scenarios in the Internet of Vehicles according to claim 1, characterized in that, The construction of a dynamic mapping rule base, and the semantic normalization processing of the preprocessed multi-source heterogeneous data based on the dynamic mapping rule base to output structured standard data specifically include: A dynamic mapping rule base is built based on Nacos; Based on the dynamic mapping rule base, semantic normalization processing is performed on the preprocessed multi-source heterogeneous data; Perform time synchronization correction on the semantically normalized data to output structured standard data.

5. A multi-protocol vehicle-to-everything (V2X) multi-dimensional scene intelligent alarm monitoring system, characterized in that, The system is applied to the vehicle-to-everything (V2X) multi-dimensional scene intelligent alarm monitoring method according to any one of claims 1 to 4, and the system includes: The protocol configuration module configures dedicated parsing logic for multiple protocols; The data acquisition and preprocessing module acquires and preprocesses multi-source heterogeneous data based on the multi-protocol-specific parsing logic. The data processing module constructs a dynamic mapping rule base, performs semantic normalization processing on the preprocessed multi-source heterogeneous data based on the dynamic mapping rule base, and outputs structured standard data. The fault identification module configures multi-dimensional scene alarm rules based on the structured standard data, performs fault identification based on the multi-dimensional scene alarm rules, and obtains fault identification results. The result generation module performs graded alarms based on the fault identification results and generates standardized alarm messages.

Images