Vehicle light control protocol automatic analysis method and device

Abstract

The invention belongs to the technical field of data analysis, and particularly relates to a vehicle light control protocol automatic analysis method and device, and the method comprises the steps: S1, collecting and synchronizing data; s2, extracting and quantifying signal behavior characteristics; s3, performing feature analysis and determining target data; s4, segmenting the data; s5, solving a CRC algorithm; s6, constructing a signal visual incidence matrix; s7, concluding a control rule; and S8, integrating the protocol DBC file. According to the method, protocol structure inversion and control logic decryption are efficiently completed by analyzing internal association of CAN data and visual information, finally, a standardized protocol description file is output, and dependence on specific tools and artificial experience is reduced to the maximum extent in the whole process.

Description

Technical Field

[0001] This invention belongs to the field of data parsing technology, specifically relating to an automatic parsing method and device for vehicle lighting control protocols. Background Technology

[0002] With the upgrading of vehicle intelligence, intelligent lighting systems such as matrix headlights and dynamic sequential taillights have become standard equipment on mid-to-high-end models. Current intelligent lighting systems like matrix headlights and dynamic taillights transmit control commands via the CAN bus, employing a complex CAN bus communication protocol to form a proprietary protocol system that includes private CRC check algorithms, dynamic data frame structures, and complex LED mapping logic. Because different automakers use different protocol standards, competitive analysis necessitates reverse engineering these protocols to obtain the lighting control logic of different manufacturers, providing support for headlight control performance comparisons and new product development.

[0003] Traditional analytical methods have three major bottlenecks:

[0004] (1) The signals are mixed and the key targets are difficult to locate: The CAN bus data is massive and mixed, and signals from multiple systems such as power, chassis and body are transmitted at the same time. The lighting control signal is intertwined with the vehicle power, chassis and other signals. Locating the key signal is like finding a needle in a haystack. It relies heavily on manual experience and repeated testing, which is extremely inefficient and easy to miss low-frequency signals such as turn signal flashing. There is a lack of an effective method to automatically identify the lighting control signal from the massive ID.

[0005] (2) Protocol encryption and dynamic verification mechanism: The lighting protocol generally adopts the CRC verification mechanism with dynamic hidden parameter DataID. DataID changes dynamically with the counter (0-F cycle). Traditional methods rely on enumeration of limited standard algorithms and manual comparison. For non-standard or deeply customized algorithms, the parsing efficiency is low or even impossible.

[0006] (3) Obscure logic and unclear control semantic mapping: The mapping relationship between data fields and LED status includes complex logic such as gradient brightness (0-255 levels) and dynamic scanning (such as water flow turning). Traditional methods rely on manually modifying a single field and observing the changes in light. A large number of tests are required to summarize simple rules, which cannot cover the scenario of multi-field collaborative control.

[0007] In summary, traditional parsing methods rely on manual reverse engineering and brute-force parsing, which suffer from low efficiency, poor versatility, and incomplete coverage. There is an urgent need for an intelligent parsing method that can automate the entire process from signal selection to protocol generation. Summary of the Invention

[0008] This invention addresses the technical problems of traditional parsing methods, which rely on manual reverse engineering and brute-force parsing, resulting in low efficiency, poor versatility, and incomplete coverage. The aim is to provide an automatic parsing method and device for vehicle lighting control protocols.

[0009] To address the aforementioned technical problems, a first aspect of the present invention provides an automatic parsing method for a vehicle lighting control protocol, the automatic parsing method for a vehicle lighting control protocol comprising:

[0010] S1, execute one or more light events, collect CAN communication data on the CAN bus and the corresponding light change video. The CAN communication data includes a timestamp and its corresponding CAN identifier and CAN data. The light change video includes a frame timestamp and its corresponding video frame. The CAN communication data and the light change video are associated and synchronized through the timestamp alignment condition to obtain synchronized data.

[0011] S2, acquire the synchronization data corresponding to a single light event, and calculate one or more behavioral feature vectors for the CAN data corresponding to each CAN identifier to obtain a behavioral feature matrix;

[0012] S3, identify the behavioral feature matrix to obtain the target CAN identifier and target CAN data corresponding to the light event;

[0013] S4, perform statistical analysis on all data frame sequences in the target CAN data to obtain the communication structure of the light event, and divide the target CAN data into a verification area, a counter area, a payload area, and a fill area according to the communication structure;

[0014] S5. Based on the actual verification value of the verification area, the counter of the counter area, and the data field of the load area, the CRC check algorithm and its algorithm parameters are obtained.

[0015] S6, extract the signal time series of each signal to be parsed in the target CAN data, quantize the brightness of each LED in the video frame associated with the target CAN identifier into a visual time series, calculate the similarity of each pair of signal time series and visual time series, and form a signal visual association matrix;

[0016] S7, perform control semantic parsing on the signal visual association matrix to obtain the control rule set for signal-controlled LED beads;

[0017] S8, integrate the target CAN identifier, the target CAN data, the communication structure, the target parameters and target dynamic function, and the control rules to obtain a standardized vehicle lighting control protocol DBC file.

[0018] Optionally, in the vehicle lighting control protocol automatic parsing method described above, in step S2, the behavior feature vector includes at least one of transient matching degree vector, steady-state consistency vector, and periodic similarity vector;

[0019] The transient matching degree vector is used to quantify the amplitude and synchronicity of the signal value at the moment of light event triggering. The calculation formula is as follows:

[0020] Represents the transient matching degree vector. ; Indicates the moment of abrupt change in the CAN data field; Indicates the time when the light event is triggered. Indicates a time window;

[0021] The steady-state consistency vector is used to evaluate the variance level of the signal value during the steady-state phase when the light is continuously on or off, and the calculation formula is as follows:

[0022] in, Represents the steady-state consistency vector. ; The average value of the CAN data field representing the period during which the light is constantly on; This represents the theoretical data value corresponding to a constantly lit light; Represents the steady-state sample size. Indicates the maximum value that a CAN data field can take;

[0023] The periodic similarity vector is used to evaluate the degree of matching between the signal's own period and the visual flicker period, and the calculation formula is as follows:

[0024] in, Represents a periodic similarity vector. ; Indicates the CAN signal period; This indicates the flashing cycle of the light.

[0025] Optionally, in the vehicle lighting control protocol automatic parsing method described above, in step S2, when a single lighting event corresponds to several identical or different CAN identifiers, the identical CAN identifiers are retained, the different CAN identifiers are removed, and the CAN data corresponding to each of the filtered CAN identifiers is used to calculate a behavior feature vector.

[0026] Optionally, in the vehicle lighting control protocol automatic parsing method described above, in step S2, after acquiring the synchronization data corresponding to a single lighting event and before calculating one or more behavioral feature vectors for the CAN data corresponding to each CAN identifier, the method further includes:

[0027] The video of the light change is located after the vehicle lights are turned on or after a change, or a video frame before or after the change, and a new video of the light change is obtained. Corresponding new CAN communication data is obtained, and a behavioral feature vector is calculated on the new CAN communication data.

[0028] Optionally, in the vehicle lighting control protocol automatic parsing method described above, step S3 includes:

[0029] S31, The behavior feature matrix is ​​grouped using an unsupervised clustering algorithm to divide it into several feature clusters. The Euclidean distance between the cluster center of each feature cluster and the feature vector of the preset ideal lighting controller is calculated. All CAN identifiers in the feature cluster with the smallest Euclidean distance are extracted to obtain the candidate list of target lighting control CAN identifiers.

[0030] S32, input the CAN data corresponding to each CAN identifier in the candidate list of target light control CAN identifiers into a preset CAN analysis tool, observe whether the light in the video frame responds as expected, and calculate the accuracy:

[0031] when When the accuracy exceeds a preset threshold, the corresponding CAN identifier is determined to be the target CAN identifier, and the corresponding CAN data is determined to be the target CAN data.

[0032] Optionally, if the accuracy of each of the CAN identifiers in the target lighting control CAN identifier candidate list is... When all values ​​are less than or equal to a preset accuracy threshold, all CAN data corresponding to all CAN identifiers in the target lighting control CAN identifier candidate list are input into the CAN analysis tool at once. The lighting response is then observed, and the accuracy is calculated a second time. ;

[0033] If the second calculation If the similarity is greater than the preset accuracy threshold, then all CAN data in the candidate list of the target lighting control CAN identifier will be tested in pairs from high to low similarity, and the accuracy will be calculated a third time. When the third calculation When the accuracy exceeds the preset threshold, the corresponding CAN identifier is determined as the target CAN identifier, and the corresponding CAN data is determined as the target CAN data.

[0034] If the second or third calculation If the accuracy is less than or equal to the preset accuracy threshold, it is considered that there is no target data for the light event in the candidate list of the target light control CAN identifier, and the process returns to step S1 to re-parse.

[0035] Optionally, in the vehicle lighting control protocol automatic parsing method described above, step S5 includes:

[0036] S51, Obtain a pre-constructed joint parameter space, which contains several standard parameters for CRC check and a dynamic function associated with the counter value of the counter area;

[0037] S52, under the constraint condition, the joint parameter space is solved to obtain the target parameters and target dynamic function for CRC verification. The constraint condition is that for any frame data under the target CAN identifier, the calculated verification value of the payload area is equal to the actual verification value of the verification area.

[0038] Optionally, in the vehicle lighting control protocol automatic parsing method described above, in step S51, the standard parameters containing CRC check include at least one of polynomial, initial value, result XOR value, input reflection, and output reflection.

[0039] Optionally, in the vehicle lighting control protocol automatic parsing method described above, in step S51, the dynamic function is a linear function or a nonlinear function.

[0040] Optionally, in the vehicle lighting control protocol automatic parsing method described above, the dynamic function DataID is defined as:

[0041] Here, Counter represents the counter value, and a and b represent custom coefficients.

[0042] Optionally, in the vehicle lighting control protocol automatic parsing method described above, in step S7, a preset rule induction algorithm or sparse coding model is used to perform control semantic parsing on the signal visual association matrix.

[0043] Optionally, in the vehicle lighting control protocol automatic parsing method described above, the preset rule induction algorithm adopts the decision tree algorithm.

[0044] Optionally, in the vehicle lighting control protocol automatic parsing method described above, the vehicle lighting control protocol automatic parsing method further includes:

[0045] S9. Import the vehicle lighting control protocol DBC file into a preset general bus analysis tool, and observe whether the lights respond as expected by simulating the sending of CAN messages constructed from the vehicle lighting control protocol DBC file, thereby verifying the correctness of the parsing results.

[0046] To address the aforementioned technical problems, a second aspect of the present invention provides an automatic vehicle lighting control protocol parsing device, the automatic vehicle lighting control protocol parsing device comprising:

[0047] The data acquisition and synchronization module is used to execute one or more lighting events, acquire CAN communication data on the CAN bus and the corresponding lighting change video. The CAN communication data includes a timestamp and its corresponding CAN identifier and CAN data. The lighting change video includes a frame timestamp and its corresponding video frame. The CAN communication data and the lighting change video are associated and synchronized through timestamp alignment conditions to obtain synchronized data.

[0048] The signal behavior feature extraction and quantization module is used to acquire the synchronization data corresponding to a single light event, and to calculate one or more behavior feature vectors for the CAN data corresponding to each CAN identifier to obtain a behavior feature matrix.

[0049] The feature analysis and target data determination module is used to identify the target CAN identifier and target CAN data corresponding to the light event by analyzing the behavior feature matrix.

[0050] The data segmentation module is used to perform statistical analysis on all data frame sequences in the target CAN data to obtain the communication structure of the light event, and to segment the target CAN data into a verification area, a counter area, a payload area, and a fill area according to the communication structure.

[0051] The CRC algorithm solving module is used to obtain the CRC check algorithm and its algorithm parameters based on the actual check value of the check area, the counter of the counter area, and the data field of the payload area.

[0052] The signal visual association matrix construction module is used to extract the signal time series of each signal to be parsed in the target CAN data, quantize the brightness of each LED in the video frame associated with the target CAN identifier into a visual time series, calculate the similarity of each pair of signal time series and visual time series, and construct a signal visual association matrix.

[0053] The control rule summarization module is used to perform control semantic parsing on the signal visual association matrix to obtain the control rule set for signal-controlled LED beads.

[0054] The protocol integration module is used to integrate the target CAN identifier, the target CAN data, the communication structure, the target parameters and target dynamic functions, and the control rules to obtain a standardized vehicle lighting control protocol DBC file.

[0055] The simulation verification module is used to import the vehicle lighting control protocol DBC file into a preset general bus analysis tool, and to observe whether the lights respond as expected by simulating the sending of CAN messages constructed from the vehicle lighting control protocol DBC file, thereby verifying the correctness of the parsing results.

[0056] The positive and progressive effects of this invention are as follows:

[0057] 1. This invention analyzes the inherent relationship between CAN data and visual information, efficiently completes protocol structure inversion and control logic decryption, and finally outputs a standardized protocol description file, minimizing reliance on specific tools and human experience throughout the process.

[0058] 2. This invention proposes a signal analysis framework based on supervised clustering of multimodal behavioral features, addressing the core pain point of traditional analysis methods that rely excessively on empirical knowledge and suffer from low efficiency. Firstly, it proposes a rapid identification technique for key signals based on unsupervised clustering of multimodal behavioral features. This technique abandons the traditional model that relies on prior knowledge or manual screening. By defining and calculating the behavioral feature vector of CAN signals relative to visual events, and employing an unsupervised clustering method, it achieves rapid identification of key lighting control signals in a massive bus environment with high accuracy and no need for manual intervention, thus improving the efficiency and accuracy of key signal screening.

[0059] 3. This invention innovatively constructs a CRC-DataID joint parameter space, unifying CRC checksum parsing and signal structure parsing into a single constraint satisfaction problem. By constructing the CRC-DataID joint parameter space and utilizing the inherent constraints of the protocol itself for collaborative solving, the computational load is significantly reduced. It can efficiently and accurately parse complex checksum mechanisms containing dynamically hidden parameters, while also improving the success rate of parsing different customized algorithms. It supports mainstream proprietary protocols such as AutoSAR E2E Profile2 variants and SAE-J1850 variants, significantly enhancing its versatility.

[0060] 4. This invention constructs a control semantic decryption model based on signal visual correlation matrices and rule induction, overcoming the limitation of relying on manual induction for "data-state" mapping. By establishing a signal visual correlation matrix, it quantifies the correlation between data and physical effects, achieving automated parsing of complex control logic. This method can automatically discover complex logic such as gradient brightness and scanning mode, realizing intelligent and scalable control logic parsing. Finally, it automatically generates standardized DBC files, eliminating the need for manual signal definition writing, and can be directly used for compatibility testing and secondary development of vehicle lighting systems. Attached Figure Description

[0061] The disclosure of this invention will become more apparent from the accompanying drawings. It should be understood that these drawings are for illustrative purposes only and are not intended to limit the scope of protection of this invention. In the drawings:

[0062] Figure 1 This is a schematic diagram of an invention process according to the present invention. Detailed Implementation

[0063] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention.

[0064] It should be noted that, unless otherwise specified, the following embodiments and features can be combined with each other.

[0065] In the description of this invention, it should be noted that the directional terms such as "outer side", "middle section", "inner", "outer" indicate the orientation and positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. They should not be construed as limiting the specific protection scope of this invention.

[0066] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features. Thus, the use of "first" and "second" to define a feature may explicitly or implicitly include one or more of that feature. In the description of this invention, "several" or "a number" means two or more, unless otherwise explicitly specified.

[0067] Reference Figure 1 This invention provides an automatic parsing method for vehicle lighting control protocols, which includes the following specific steps:

[0068] S1, Data Acquisition and Synchronization: Execute one or more lighting events, acquire CAN communication data on the CAN bus and corresponding lighting change videos. The CAN communication data includes timestamps and their corresponding CAN identifiers and CAN data. The lighting change videos include frame timestamps and their corresponding video frames. The CAN communication data and lighting change videos are associated and synchronized through timestamp alignment conditions to obtain synchronization data.

[0069] This step aims to construct a spatiotemporally strictly aligned multimodal dataset for protocol parsing. In practice, the vehicle must be operated in a controlled environment (such as a quiet, undisturbed road at night) to systematically execute a series of standardized lighting operations, including but not limited to switching on and off the parking lights, low beam headlights, and high beam headlights, activating the turn signals, and dynamic light sequences when the vehicle is unlocked / locked. During this process, all CAN communication data on the CAN bus must be recorded synchronously, and corresponding light change videos must be recorded using a dashcam or multi-angle camera.

[0070] The CAN dataset and the video dataset can be defined as follows: ,

[0071] in, Represents a timestamp; Indicates the CAN identifier; Represents CAN data fields; Indicates the frame timestamp; This represents a video frame.

[0072] All data files can be defined and named with timestamps and descriptions of the light operations, such as TurnLight_20240501.csv and TurnLight_20240501.mp4.

[0073] The timestamp alignment condition can be defined as:

[0074] in, This indicates the preset allowable time difference.

[0075] By using timestamp alignment, we can ensure that the CAN message output and the light changes are synchronized in time and space during subsequent analysis. This lays the foundation for building "excitation-response" data pairs, making it easier to filter and parse the light signals of this vehicle model based on the file name.

[0076] S2, Extract and Quantize Signal Behavior Features: Obtain the synchronization data corresponding to a single light event, calculate one or more behavior feature vectors for the CAN data corresponding to each CAN identifier, and obtain the behavior feature matrix.

[0077] After obtaining the synchronization data, behavioral feature analysis needs to be performed on each CAN ID (CAN identifier), associate it with the light change events obtained from visual analysis, and quantify and calculate its behavioral feature vector.

[0078] In some embodiments, in step S2, the behavioral feature vector includes at least one of a transient matching degree vector, a steady-state consistency vector, and a periodic similarity vector. That is, the behavioral feature vector may include one or more core components depending on the actual scenario.

[0079] (1) Transient matching degree vector This is used to quantify the amplitude and synchronicity of the signal value at the moment of light event triggering. The calculation formula is:

[0080] in, Represents the transient matching degree vector. ; Indicates the moment of abrupt change in the CAN data field; Indicates the time when the light event is triggered. Indicates a time window;

[0081] Transient matching degree vector The closer the value is to 1, the stronger the synchronization.

[0082] (2) Steady-state consistency vector This is used to assess the variance level of the signal value during the stable phase of a light's continuous illumination or de-illumination. The calculation formula is:

[0083] in, Represents the steady-state consistency vector. ; The average value of the CAN data field representing the period during which the light is constantly on; This represents the theoretical data value corresponding to a constantly lit light; Represents the steady-state sample size. Indicates the maximum value that a CAN data field can take;

[0084] In the above calculation formula, the theoretical data value when the light is constantly on is the default state of the CAN ID. This default state is a fixed value, and different CAN IDs have different default states. The default state is the behavior when the light is constantly on, and its theoretical data value will be fixed in a data field. For example, the data field of a certain CAN ID's default state is **(checksum)** (counter) 00 62 1c d1 61 00, and this data field is used as the theoretical data value.

[0085] In the above calculation formula, the steady-state sample count refers to the amount of CAN data corresponding to a single CAN ID in the default state when the light is always on.

[0086] Steady-state consistent vector The closer the value is to 1, the stronger the consistency.

[0087] (3) Periodic similarity vectors This is used to evaluate the degree of matching between the signal's own period and the visual flicker period. The calculation formula is as follows:

[0088] in, Represents a periodic similarity vector. ; The CAN signal period can be calculated using an autocorrelation function, such as the turn signal period. ; This indicates the flashing cycle of the light.

[0089] Periodic similarity vectors The closer the value is to 1, the stronger the match.

[0090] Step S2 of this invention, through the quantization of the aforementioned features, transforms each CAN ID from a raw data sequence into a computable and comparable behavioral feature vector. This forms a feature matrix, where K is the number of CAN IDs.

[0091] In practice, for headlights, generally... and Two-dimensional feature analysis; for turn signals with periodic responses, then... Feature analysis in three dimensions.

[0092] In some embodiments, in step S2, when a single light event corresponds to several identical or different CAN identifiers, the identical CAN identifiers are retained, the different CAN identifiers are removed, and the behavior feature vectors are calculated for the CAN data corresponding to each filtered CAN identifier.

[0093] Typically, for a lighting event, there are several CAN IDs and their corresponding CAN data. Each CAN ID can be compared, and identical CAN IDs can be retained. It is assumed that the target signal for controlling the lights exists in the CAN data corresponding to each retained CAN ID, which can reduce the amount of data required to calculate the behavior feature vector.

[0094] In some embodiments, in step S2, after acquiring the synchronization data corresponding to a single light event and before calculating one or more behavioral feature vectors for the CAN data corresponding to each CAN identifier, the method further includes: capturing a new light change video after the vehicle lights are turned on or after a change in the light change video, obtaining the corresponding new CAN communication data, and calculating a behavioral feature vector for the new CAN communication data.

[0095] When the data collection time is long, it is necessary to quickly locate the corresponding data of vehicle light changes. In this case, the data can be reduced in order to accurately locate the target signal data range of the light change.

[0096] S3, Feature Analysis and Target Data Determination: Identify the behavioral feature matrix to obtain the target CAN identifier and target CAN data corresponding to the light event.

[0097] The selection of target data can be done using supervised learning methods or unsupervised clustering algorithms.

[0098] When using a supervised learning-based method, the method first needs to collect lighting control ID annotation data from multiple vehicle models to form a training set, then use the random forest algorithm to train a "feature-ID type" classification model, input the CAN signal features of the new vehicle model, and directly predict whether it is a lighting control ID.

[0099] When using unsupervised clustering algorithms, algorithms such as K-means can be used to group and process the behavioral feature matrix to obtain the target CAN identifier and target CAN data.

[0100] In some embodiments, step S3 includes:

[0101] S31. An unsupervised clustering algorithm is used to group the behavioral feature matrix into several feature clusters. The Euclidean distance between the cluster center of each feature cluster and the feature vector of the preset ideal lighting controller is calculated. All CAN identifiers in the feature cluster with the smallest Euclidean distance are extracted to obtain the candidate list of CAN identifiers for the target lighting control.

[0102] In this step, the clustering objective function of the unsupervised clustering algorithm can be:

[0103] in, Indicates the first A feature cluster; Indicates the cluster center; This represents the number of clusters, which can be a preset value, preferably determined by the elbow method. That is, the number of clusters ranges from 5 to 8.

[0104] In this step, the feature vector of the ideal lighting controller is preset as follows: , representing the optimal transient matching degree, steady-state consistency, and periodic similarity, respectively. Calculate the cluster center. and The formula for calculating the Euclidean distance is:

[0105] in, , and Indicates cluster center The three behavioral feature vectors are the transient matching degree vector, the steady-state consistency vector, and the periodic similarity vector.

[0106] according to All candidate signals are sorted in ascending order to obtain cluster priorities. All CAN IDs in the feature cluster with the highest priority are extracted to form a candidate list of target lighting control CAN identifiers arranged by correlation, providing a precise target range for subsequent in-depth analysis.

[0107] S32, input the CAN data corresponding to each CAN identifier in the candidate list of target light control CAN identifiers into the preset CAN analysis tool, observe whether the lights in the video frames respond as expected, and calculate the accuracy:

[0108] when When the accuracy exceeds the preset threshold, the corresponding CAN identifier is determined to be the target CAN identifier, and the corresponding CAN data is determined to be the target CAN data.

[0109] In this step, a traversal method is used, and the above method is verified through playback testing to achieve accurate positioning and identification of specific lighting control CAN ID signals.

[0110] In some embodiments, in step S32, if the accuracy of each CAN identifier in the target lighting control CAN identifier candidate list is... If all values ​​are less than or equal to the preset accuracy threshold, meaning there is no expected response, or even if there is an expected response but the number of responses is low or unstable, then it is considered that the accurate target CAN ID has not been obtained, and the light event has not obtained target CAN data. In this case, light control with multiple CAN IDs needs to be considered:

[0111] Input all CAN data corresponding to all CAN identifiers in the candidate list of target lighting control CAN identifiers into the CAN analysis tool at once, observe whether the lights respond as expected, and then calculate the accuracy a second time. .

[0112] If the second calculation If the accuracy exceeds the preset accuracy threshold, it means the target CAN ID for the lighting event is still in the list. Therefore, all CAN data in the target lighting control CAN identifier candidate list are tested in pairs, ranked from highest to lowest similarity, and the accuracy is calculated a third time. When the third calculation When the accuracy exceeds the preset threshold, the corresponding CAN identifier is determined to be the target CAN identifier, and the corresponding CAN data is determined to be the target CAN data.

[0113] If the second or third calculation If the target data is less than or equal to the preset accuracy threshold, it is considered that there is no target data for the light event in the candidate list of the target light control CAN identifier, and the process returns to step S1 to re-parse.

[0114] In this embodiment, the reason why the target data is not obtained and it is necessary to return to step S1 may be that the alignment accuracy between the video frame and the data frame of the light event is not high enough, and there is data disturbance. It is necessary to investigate in order to improve the success rate of re-parsing.

[0115] This embodiment proposes a target signal screening method based on unsupervised clustering of multimodal behavioral features. This embodiment abandons the traditional mode of relying on prior knowledge or manual screening, and innovatively uses behavioral feature vectors to transform the association between CAN signals and light events from "qualitative observation" to "quantitative calculation", providing standardized features for unsupervised clustering, with high accuracy and no need for manual intervention.

[0116] S4, Data Segmentation: Perform statistical analysis on all data frame sequences in the target CAN data to obtain the communication structure of the light event. Based on the communication structure, segment the target CAN data into a verification area, a counter area, a payload area, and a fill area.

[0117] For a given target CAN ID, this step requires further analysis of the internal structure of its data frames. This step, based on statistical analysis of a large number of data frame sequences, can automatically assume its communication structure template. The statistical analysis can employ principles of statistical analysis from existing technologies.

[0118] A communication structure template, such as [CRC] + [Counter] + [Payload] or a variant thereof.

[0119] By identifying constant bytes, cyclically incrementing bytes, and bytes that change in sync with the light status, the data frame can be separated into a check area, a counter area, a payload area, and a possible padding area (00 or other fixed values). This step lays the structural foundation for subsequent CRC algorithm parsing by segmenting the data.

[0120] S5, Solve the CRC algorithm: Based on the actual check value in the check area, the counter in the counter area, and the data field in the payload area, obtain the CRC check algorithm and its algorithm parameters.

[0121] In this step, the CRC algorithm can be solved using a deep learning-based CRC parameter prediction method. This method models CRC parameter prediction as a regression problem, taking the Data field (CAN data field) and CRC check value as inputs, and using a neural network (such as CNN+LSTM) to directly output CRC parameters such as POLY and INIT.

[0122] This step preferably uses the following method to obtain the CRC check algorithm and its parameters:

[0123] S51, obtain the pre-constructed joint parameter space, which contains several standard parameters for CRC check and dynamic functions associated with the counter values ​​in the counter area.

[0124] The standard parameters for CRC checksum verification preferably include at least one of a polynomial, an initial value, a result XOR value, an input reflection, and an output reflection. The dynamic function is either a linear function or a nonlinear function, preferably a linear function.

[0125] This step, based on the E2E Profile2 verification method of AutoSAR (Automotive Open System Architecture, a standardized automotive electronic software architecture, whose E2E Profile2 is a commonly used CAN message verification specification), defines a high-dimensional joint parameter space to efficiently parse the dynamic verification mechanism often included in lighting protocols. This space is a set of all possible CRC algorithms (5 standard + variants) and all possible DataID generation rules (linear, lookup table, etc.). This space not only includes standard CRC check parameters, such as at least one of polynomial, initial value, result XOROUT, input reflection (REFIN), and output reflection (REFOUT), but more importantly, it incorporates manufacturer-defined dynamic DataIDs as core variables. DataID is a key piece of information in the CAN communication protocol data; it is manufacturer-defined data. For the communication protocol of the vehicle lighting control board, different manufacturers use different protocol algorithms (CRC algorithms) and corresponding DataID data. For example, other data recorded on the CAN bus (vehicle speed, distance) also have corresponding DataIDs. Compared to the lighting signal, the DataIDs corresponding to the counter sequence values ​​of the above parameter signals are the same; that is, the same parameter signal corresponds to the same DataID, while different parameter signals have different DataIDs. Similarly, the CAN message data generated by radars from different manufacturers is also different. Therefore, DataID is manufacturer-defined CAN message identification data, associated with a counter, used to dynamically adjust the CRC check logic, and is a proprietary parameter of the vehicle lighting control protocol.

[0126] For the light signal, different counter values ​​in the 0-F cycle use different DataID values. Considering that DataID is often associated with counter (c), this step models DataID as a function of the counter, i.e., DataID = f(c). This function can be linear or non-linear, thus transforming the CRC parsing problem into a problem in joint parameter space. The problem of finding the optimal solution in the middle.

[0127] The following table lists the standard parameters for CRC checksums and their value ranges:

[0128]

[0129] Therefore, the joint parameter space is defined as:

[0130] Where f represents the function expression for DataID, and dynamic DataID can be linear, lookup-based, or any other form. Define it as a function of a counter:

[0131] Here, Counter represents the counter value, and a and b represent manufacturer-defined coefficients, such as a=1 and b=0x10.

[0132] The value range of this function is {0x00−0xFF}, which changes dynamically with the counter (0-F). For example, when Counter=0x05, DataID=0x15; when Counter=0x06, DataID=0x16.

[0133] By analyzing the DataID patterns of other signals of the same vehicle model (such as vehicle speed signal IDx5), the range of values ​​for a and b can be initially constrained (e.g., a∈{1,2}, b∈{0x10−0x20}), reducing the parameter space size from 2^30 to within 2^16, significantly reducing the difficulty of subsequent solutions.

[0134] S52, under the constraint conditions, solve the joint parameter space to obtain the target parameters and target dynamic function for CRC verification. The constraint condition is: for any frame data under the target CAN identifier, the calculated check value of the payload area is equal to the actual check value of the verification area.

[0135] This step is the core of parsing the CRC checksum and DataID mapping rules, aiming to solve for the CRC parameters by analyzing the CAN data frame. The rules for matching counters with DataIDs This step requires defining the valid data payload for each signal ID to be parsed, which will then be used for verification. , This refers to the portion of the ID data frame that, excluding the checksum byte, actually participates in the CRC calculation. Its length and structure vary depending on the signal function. This step utilizes the inherent rigid constraint of the protocol—that "the same signal ID corresponds to different counter values ​​with different CRC checksums"—to model the problem as a constraint satisfaction problem. The algorithm searches in the joint parameter space for a unique set of CRC algorithm parameters and a global DataID generation rule that simultaneously satisfies all constraints. Its mathematical model can be expressed as: finding a set of parameters... This ensures that for any frame containing the target CAN ID in the set of all acquired data frames D, its calculated checksum is... Compared with the actual verification value They are equal, meaning the constraint conditions are met: ,

[0136] in, This represents the data payload (i.e., the data to be transmitted). The data payload used for verification will vary depending on the signal. This represents the counter value; for any two frames of data under the same signal ID, the initial conditions of the solution algorithm must be met:

[0137] By designing and optimizing the search algorithm under this constraint, the joint parameter space is optimized. By solving the problem, a unique set of CRC algorithm parameters can ultimately be derived. Mapping function with DataID .

[0138] The proposed CRC-DataID joint parameter space construction method in this embodiment incorporates the dynamic DataID (which changes with the counter) into the parameter space of CRC parsing. Based on the constraint satisfaction problem, it solves the optimal combination of CRC parameters, which greatly reduces the solution space and effectively improves the calculation process of traditional methods that traverse to find the DataID corresponding to the counter, thereby improving the efficiency of signal parsing and the standardization process.

[0139] S6, Construct a signal visual association matrix: Extract the signal time series of each signal to be parsed in the target CAN data, quantize the brightness of each LED in the video frame associated with the target CAN identifier into a visual time series, calculate the similarity between each pair of signal time series and visual time series, and construct a signal visual association matrix.

[0140] CAN data fields typically have 8 bytes. The first 2 bytes are the checksum and counter, and the last 6 bytes control the brightness of the LEDs. This step requires determining which of the last 6 bytes(s) controls the brightness of the LEDs.

[0141] During the control logic parsing stage, it is first necessary to extract each byte or bit to be parsed from the target CAN data corresponding to the target CAN ID. signal time series ,in The first CAN data corresponding to the target CAN ID Each byte or bit needs to be parsed. Simultaneously, automated processing of the synchronized video stream is required. Computer vision algorithms can be applied to locate and track each LED, and quantify its brightness into a visual time series. ,in Index the LED beads. Then, calculate each pair. Time series similarity This similarity can be calculated using existing methods such as dynamic time-warped distance or Pearson correlation coefficient. Ultimately, all these similarity values ​​constitute a signal visual association matrix. This matrix quantitatively reveals the potential correlation between data fields and physical LED status.

[0142] S7, Summarize control rules: Perform control semantic analysis on the signal visual association matrix to obtain the control rule set for signal-controlled LED beads.

[0143] After obtaining the signal visual correlation matrix, a preset rule-based inductive algorithm or sparse coding model is preferably used for control semantic parsing to automatically extract the control semantics of the data fields regarding the LED state. The aforementioned algorithm or model uses the data fields... The input feature is the value of the LED, and the output label is the brightness state or mode of the LED. The system learns from the data and generates a set of human-readable control rules. .

[0144] For example, when the fifth byte (data[5]) of signal IDx1 is in the range of 0xC0 to 0xdf, its lower 6 bits control the sequential lighting logic of the first row of LED beads from left to right. Based on the correlation analysis results, using interpretable machine learning models such as decision trees, specific control rules such as "when the lower 6 bits of data[5] are in the range [0xc0, 0xdf], the LED beads are controlled to move and light up from left to right" can be quickly summarized. When using a decision tree, a rule that the decision tree may generate is: "IF B_5 ∈ [0xc0, 0xdf] THEN Light_Pattern = 'Left-to-Right Sweep'", thereby automatically discovering and describing the specific logic of the data[5] byte controlling the LED bead scanning mode.

[0145] The vehicle LED control logic parsing method based on the signal visual correlation matrix proposed in step S6 of this invention breaks through the limitation of "data-state" mapping relying on manual induction. It quantifies the correlation between data and physical effects by establishing a signal visual correlation matrix, and automatically decrypts its control semantics by using rule induction algorithms in step S7. This method can automatically discover complex logic such as gradient brightness and scanning mode, realizing the intelligent and automated parsing of control logic.

[0146] S8, Integrated Protocol DBC File: Integrates the target CAN identifier, target CAN data, communication structure, target parameters, target dynamic function, and control rules to obtain a standardized vehicle lighting control protocol DBC file.

[0147] In this step, DBC refers to Database CAN, also known as the CAN database file, which describes the mapping relationship between signals and messages in the CAN network and is the core file for CAN protocol parsing. This step integrates all the information parsed in the previous steps to automatically generate a standardized vehicle lighting control protocol DBC file.

[0148] S9, Simulation Verification: Import the vehicle lighting control protocol DBC file into a preset general bus analysis tool, simulate sending CAN messages constructed from the vehicle lighting control protocol DBC file, and observe whether the lights respond as expected to verify the correctness of the parsing results.

[0149] Among them, there are pre-set general-purpose bus analysis tools such as ZCANPRO software.

[0150] This invention also provides an automatic vehicle lighting control protocol parsing device, which includes:

[0151] The data acquisition and synchronization module is used to execute one or more lighting events, acquire CAN communication data on the CAN bus and the corresponding lighting change video. The CAN communication data includes timestamps and their corresponding CAN identifiers and CAN data, and the lighting change video includes frame timestamps and their corresponding video frames. The CAN communication data and the lighting change video are associated and synchronized through timestamp alignment conditions to obtain synchronized data.

[0152] The signal behavior feature extraction and quantization module is used to acquire the synchronization data corresponding to a single light event, calculate one or more behavior feature vectors for the CAN data corresponding to each CAN identifier, and obtain the behavior feature matrix.

[0153] The feature analysis and target data determination module is used to identify the target CAN identifier and target CAN data corresponding to the light event by analyzing the behavior feature matrix.

[0154] The data segmentation module is used to perform statistical analysis on all data frame sequences in the target CAN data to obtain the communication structure of the light event. Based on the communication structure, the target CAN data is segmented into a verification area, a counter area, a payload area, and a fill area.

[0155] The CRC algorithm solving module is used to obtain the CRC check algorithm and its algorithm parameters based on the actual check value in the check area, the counter in the counter area, and the data field in the payload area.

[0156] The signal visual association matrix construction module is used to extract the signal time series of each signal to be parsed in the target CAN data, quantize the brightness of each LED in the video frame associated with the target CAN identifier into a visual time series, calculate the similarity of each pair of signal time series and visual time series, and construct the signal visual association matrix.

[0157] The control rule summarization module is used to perform control semantic parsing on the signal visual association matrix to obtain the control rule set for signal-controlled LED beads.

[0158] The protocol integration module is used to integrate the target CAN identifier, target CAN data, communication structure, target parameters, target dynamic functions, and control rules to obtain a standardized vehicle lighting control protocol DBC file.

[0159] The simulation verification module is used to import the vehicle lighting control protocol DBC file into a preset general bus analysis tool. By simulating the sending of CAN messages constructed from the vehicle lighting control protocol DBC file, it observes whether the lights respond as expected, thus verifying the correctness of the parsing results.

[0160] Example 1:

[0161] This embodiment takes a matrix headlight system of a passenger vehicle as the analysis object to verify the effectiveness of the methods in each embodiment of steps S1 to S9 of the present invention.

[0162] First, a section of highway without streetlights was selected for a 3-hour (19:00-22:00) road test data collection. A CAN card (1MHz sampling rate, 1ms timestamp accuracy) was used to collect CAN communication data on the CAN bus. Simultaneously, a dashcam (30fps frame rate, GPS synchronized timestamp) recorded lighting videos to obtain corresponding lighting change videos. Various lighting operations were performed, including vehicle unlocking, vehicle locking, turning on parking lights, turning on low beams, switching high beams, activating left turn signals, activating right turn signals, activating hazard lights, switching daytime running lights, and automatic headlight adjustment. The corresponding CAN communication data and lighting change videos were recorded. A total of CAN communication data (saved as "XXX_Operation.asc") and lighting change video data (saved as "XXX_Operation.mp4") were collected and analyzed using timestamp alignment conditions. The two types of data are correlated, and the sample size for each operation is greater than 5,000 frames to ensure data validity.

[0163] For any given lighting event, several associated CAN IDs are initially identified, and three-dimensional behavioral feature vectors are calculated for each. Due to the long road sampling time, it is necessary to quickly locate the corresponding data where vehicle lighting changes occur. A data file is randomly selected for playback. In the video data of lighting changes, lighting changes occur at two time frames: 20:09:40 and 20:09:46, representing the lights turning on and partially turning off, respectively. A total of 3 seconds of CAN communication data before and after these two moments are extracted for subsequent analysis, specifically the CAN communication data from 20:09:38 to 20:09:41 and from 20:09:44 to 20:09:47. In other words, by locating the segment where the headlights turn on and change, and reducing the 3 hours of data to the 3 seconds of CAN communication data showing the change in LED brightness, the target signal data range of the lighting change has been accurately located. Taking one segment of video data as an example, the table below shows a statistical comparison of the reduction in the amount of CAN communication data corresponding to this segment of video data:

[0164]

[0165] The table below shows the CAN IDs of two video data segments. The first video data segment contains CAN IDs from 82 different frames, for a total of 5248 frames:

[0166]

[0167] The second video segment collected CAN IDs from 84 different frames, totaling 5709 frames.

[0168]

[0169] Comparing the CAD IDs of the two segments revealed 62 identical CAD ID signals. After initial screening, the total number of CAD ID signals was reduced from 82 to 62, indicating that a target signal for controlling the lights was found among these signals.

[0170] For each CAN ID in the new dataset, the transient matching vector, steady-state consistency vector, and periodic similarity vector of each ID were automatically calculated. These vectors were then sorted using K-means clustering and Euclidean distance to obtain a candidate list of CAN identifiers for target lighting control. This list accurately includes target control signals confirmed through traditional manual playback and experience, such as IDx1, IDx2, IDx3 (LED control), and IDx4 (high / low beam control), demonstrating the effectiveness and efficiency of this method in automatic target signal selection.

[0171] Based on the above screening process, IDx1 is the target CAN ID for controlling the LED. It is necessary to observe the changing pattern of the corresponding target CAN data and apply the collaborative inversion algorithm of the protocol structure proposed in this invention. First, its data frame structure is automatically parsed as [CRC check bit] + [Counter bit] + [Payload data segment]: the CRC check bit is the first byte, located in data[0]; the counter bit is counted cyclically from 0 to F, generally the second byte, located in data[1], and the rest are data segments, and a CRC-DataID joint parameter space is constructed. Based on the aforementioned work, the communication data and the DataID defined by each lighting control board manufacturer are constructed into a combined data segment through the CRC check process. This combined data segment is set as a parameter in the CRC function. The parameter list of the CRC function includes the combined data segment of DataID, polynomial, initial value, XOR value, input / output flip reflection, etc.

[0172] There are many known common CRC algorithms (such as AUTOSAR, SAE-J1850, etc.). If brute-force parsing is used, a preliminary estimate suggests that parsing one ID would require at least (a total of 2...) 26This algorithm involves 67,108,864 operations (in various combinations), and inevitably outputs multiple results. Therefore, the efficiency of the traditional traversal algorithm and the cooperative inversion algorithm of this invention are compared in the following table:

[0173]

[0174] Clearly, the collaborative inversion algorithm of this invention can greatly reduce computation time.

[0175] Therefore, based on experience, we will only consider a few common combinations in the current standard:

[0176] AUTOSAR: POLY-2F INIT-FF XOROUT-FF REFIN-False REFOUT-False

[0177] SAE-J1850: POLY-1D INIT-FF XOROUT-FF REFIN-False REFOUT-False

[0178] MAXIM: POLY-31 INIT-00 XOROUT-00 REFIN-True REFOUT-True

[0179] CRC-8: POLY-07 INIT-00 XOROUT-00 REFIN-False REFOUT-False

[0180] ROHC: POLY-07 INIT-FF XOROUT-00 REFIN-True REFOUT-True

[0181] Based on only 5 algorithms, a CRC algorithm library is constructed. This invention inputs the communication data of IDx1, the known data and check value, and puts the check value in the last position, in the form of aa bb cc dd …… kk, CRC. The kk is traversed and the value of kk is determined, which is the DataID corresponding to different counters of the light signal. Multiple lines of data are input and multiple results are obtained. Through multiple experiments and manual investigation, the example is the decryption of the CRC check of a single signal of a passenger car headlight. Conclusion: data[1]-data[6] plus 0f data, and check according to the CRC parameters specified by SAE-J1850.

[0182] The verification results of key signals of a passenger vehicle's headlights recorded in this embodiment are as follows:

[0183] IDx1: The original 7 bits of data (data[1]-data[7]) + the DataID related to the counter are subjected to CRC verification;

[0184] IDx2: The original 7 bits of data (data[1]-data[7]) + the DataID related to the counter are checked for CRC;

[0185] IDx3: The original 7 bits of data (data[1]-data[7]) + the DataID related to the counter are subjected to CRC verification;

[0186] IDx4: The original 3 bits (data[1]-data[3]) + the DataID related to the counter are used for CRC verification.

[0187] Bytes suspected to be CRC checksums are extracted from CAN data packets and matched using a known CRC algorithm library. Once the pattern is found, the CRC parameters and algorithm used for the lighting control signal are determined, successfully parsing the lighting signal control protocol. By solving the constraint problem of "different counters for the same data correspond to different CRCs," the AUTOSAR standard CRC parameters (POLY=0x2F, INIT=0xFF, XOROUT=0xFF, REFIN=False, REFOUT=False) used by the check mechanism are successfully deduced, and the dynamic DataID corresponding to the counter is parsed.

[0188] This process and its conclusions are completely consistent with the results obtained by using existing tools for finite algorithm enumeration and manual comparison, but the method in this embodiment is more systematic and universal at the theoretical and algorithmic levels.

[0189] For example, the solution process for one of the signals is shown in the table below:

[0190]

[0191] After parsing the control protocol for the light signals (IDx1-IDx4), for each target CAN ID, the correlation between its data fields and the LED status is further analyzed to determine which bytes control which LEDs. Based on the protocol parsing, the signal visual correlation matrix construction method of step S6 of this invention is applied to automatically process the synchronous video stream, quantify the visual time series of each LED, and calculate the similarity between it and the time series of each data byte in the IDx1 signal to form the associated signal visual correlation matrix A.

[0192] Subsequently, the control rule induction algorithm of step S7 of this invention is applied to analyze the visual correlation matrix A of the associated signal using a decision tree model. A series of highly readable control rules are automatically learned and output, such as: "When the fifth byte (data[4]) of signal IDx1 is in the range of 0xc0 to 0xdf, its lower 6 binary bits control the first row of LED beads to light up sequentially from left to right." The discovery of this complex control rule is completely consistent with the rule summarized by manually modifying the data[5] value 256 times using the zcanpro tool and manually observing and recording the changes of the LED beads in the traditional method. The method of this embodiment realizes the complete automation of this process, and all mapping rules can be obtained with only one analysis, which greatly improves the parsing efficiency and completeness.

[0193] The table below summarizes the control rules of the fifth byte of the target signal IDx1.

[0194]

[0195] The data, including the target CAN identifier, target CAN data, communication structure, target parameters, target dynamic function, and control rules, are integrated to obtain a standardized vehicle lighting control protocol (DBC) file.

[0196] Finally, the parsed protocol is used to generate a corresponding vehicle lighting control protocol DBC file for simulation verification. The parsed CRC algorithm, target signal, data field meanings, and LED control logic are integrated into the vehicle's lighting control protocol. In the zcanpro software, based on the provided interface, an E2E algorithm script is programmed and added in the advanced settings. Then, zcanpro is used to send lighting control data with CRC and counters to control individual component lights. By simulating the transmission of the parsed control signals, the actual changes in the LEDs are observed to verify the correctness of the protocol.

[0197] The present invention has been described in detail above with reference to the accompanying drawings and embodiments. Those skilled in the art can make various modifications to the present invention based on the above description. Therefore, certain details in the embodiments should not be construed as limiting the present invention, and the scope of protection of the present invention shall be defined by the appended claims.

Claims

1. A vehicle light control protocol automatic parsing method, characterized by, The vehicle light control protocol automatic parsing method comprises: S1, performing one or several light events, collecting CAN communication data on the CAN bus and corresponding light change videos, the CAN communication data comprising a timestamp and corresponding CAN identifiers and CAN data, the light change videos comprising a frame timestamp and corresponding video frames, the CAN communication data and the light change videos being associated and synchronized through a timestamp alignment condition to obtain synchronized data; S2, obtaining the synchronized data corresponding to a single light event, calculating one or several behavior feature vectors for the CAN data corresponding to each CAN identifier to obtain a behavior feature matrix; S3, identifying the behavior feature matrix to obtain a target CAN identifier and target CAN data corresponding to the light event; S4, statistically analyzing all data frame sequences in the target CAN data to obtain a communication structure of the light event, and dividing the target CAN data into a check area, a counter area, a payload area, and a padding area according to the communication structure; S5, obtaining a CRC check algorithm and algorithm parameters according to the actual check value of the check area, the counter of the counter area, and the data field of the payload area; S6, extracting a signal time sequence of each to-be-parsed signal in the target CAN data, quantifying the brightness of each lamp bead in the video frame associated and synchronized with the target CAN identifier into a visual time sequence, calculating the similarity of each pair of signal time sequences and visual time sequences to form a signal-visual association matrix; S7, performing control semantic parsing on the signal-visual association matrix to obtain a control rule set of signal control lamp beads; S8, integrating the target CAN identifier, the target CAN data, the communication structure, the target parameters and target dynamic functions, and the control rules to obtain a standardized vehicle light control protocol DBC file.

2. The vehicle light control protocol automatic parsing method of claim 1, wherein, In step S2, the behavior feature vector comprises at least one of a transient matching degree vector, a steady-state consistency vector, and a periodic similarity vector; The transient matching degree vector is used to quantify the mutation amplitude and synchronization of signal values at the moment of light event triggering, and the calculation formula is: wherein, denotes the transient matching degree vector, ; denotes the CAN data field mutation time; denotes the light event trigger time, denotes the time window; The steady-state consistency vector is used to evaluate the variance level of signal values in the stable stage of light duration lighting or extinguishing, and the calculation formula is: wherein, represents a steady-state consistent vector, ; represents the CAN data field mean of the light constant period; represents the theoretical data value corresponding to the light constant; represents the number of steady-state samples, represents the maximum value of the CAN data field; The periodic similarity vector is used to evaluate the matching degree of the signal itself cycle and the visual flicker cycle, and the calculation formula is: wherein, denotes a periodic similarity vector, ; denotes a CAN signal period; denotes a light blink period.

3. The vehicle light control protocol automatic parsing method of claim 1, wherein, In step S2, when a single light event corresponds to several same or different CAN identifiers, the same CAN identifiers are retained and the different CAN identifiers are removed, and the behavior feature vectors of the CAN data corresponding to the screened CAN identifiers are calculated; And / or, in step S2, after obtaining the synchronized data corresponding to a single light event, before calculating one or several behavior feature vectors for the CAN data corresponding to each CAN identifier, it further comprises: The new light change video is obtained by capturing a video frame after or before the light change of the vehicle light in the light change video, and the new CAN communication data corresponding to the new light change video is obtained.

4. The vehicle light control protocol automatic parsing method of claim 1, wherein, Step S3 includes: S31, using an unsupervised clustering algorithm to group the behavior feature matrix, dividing a plurality of feature clusters, calculating the Euclidean distance between the cluster center of each group of feature clusters and the feature vector of the preset ideal light controller, and extracting all CAN identifiers in the feature cluster with the smallest Euclidean distance to obtain a target light control CAN identifier candidate list; S32, inputting the CAN data corresponding to each CAN identifier in the target light control CAN identifier candidate list into a preset CAN analysis tool, observing whether the light in the video frame responds as expected, and calculating the accuracy rate: ,when When the accuracy exceeds a preset threshold, the corresponding CAN identifier is determined to be the target CAN identifier, and the corresponding CAN data is determined to be the target CAN data. Preferably, if the accuracy of each of the CAN identifiers in the target light control CAN identifier candidate list is less than or equal to a preset accuracy threshold, all the CAN data corresponding to all the CAN identifiers in the target light control CAN identifier candidate list are input into the CAN analysis tool at one time, whether the light responds as expected is observed, and the accuracy is calculated for the second time. Preferably, if the accuracy of each of the CAN identifiers in the target light control CAN identifier candidate list is less than or equal to a preset accuracy threshold, all the CAN data corresponding to all the CAN identifiers in the target light control CAN identifier candidate list are input into the CAN analysis tool at one time, whether the light responds as expected is observed, and the accuracy is calculated for the second time. Preferably, if the accuracy of each of the CAN identifiers in the target light control CAN identifier candidate list is less than or equal to a preset accuracy threshold, all the CAN data corresponding to all the CAN identifiers in the target light control CAN identifier candidate list If the second calculation If the similarity is greater than the preset accuracy threshold, then all CAN data in the candidate list of the target lighting control CAN identifier will be tested in pairs from high to low similarity, and the accuracy will be calculated a third time. When the third calculation When the accuracy exceeds the preset threshold, the corresponding CAN identifier is determined as the target CAN identifier, and the corresponding CAN data is determined as the target CAN data. If the second or third calculation is If the accuracy is less than or equal to the preset accuracy threshold, it is considered that the target data of the light event does not exist in the target light control CAN identifier candidate list, and the analysis is restarted at step S1.

5. The vehicle light control protocol automatic parsing method of claim 1, wherein, Step S5 includes: S51, obtaining a joint parameter space constructed in advance, the joint parameter space containing a plurality of standard parameters for CRC checking and a dynamic function associated with the counter value of the counter area; S52, solving the joint parameter space under the constraint condition to obtain the target parameter for CRC checking and the target dynamic function, the constraint condition being that the calculated check value of the payload area is equal to the actual check value of the check area for any frame data under the target CAN identifier.

6. The vehicle light control protocol automatic parsing method of claim 5, wherein, In step S51, the plurality of standard parameters for CRC checking include at least one of a polynomial, an initial value, a result XOR value, an input reflection, and an output reflection.

7. The vehicle light control protocol automatic parsing method of claim 5, wherein, In step S51, the dynamic function is a linear function or a nonlinear function. Preferably, the dynamic function DataID is defined as: where Counter denotes a counter value, and a and b denote custom coefficients.

8. The vehicle light control protocol automatic parsing method of claim 1, wherein, In step S7, a preset rule induction algorithm or a sparse coding model is used to analyze the control semantics of the signal visual association matrix. Preferably, the preset rule induction algorithm uses a decision tree algorithm.

9. The vehicle light control protocol automatic resolution method according to any one of claims 1 to 9, characterized in that, The vehicle light control protocol automatic analysis method further includes: S9, importing the vehicle light control protocol DBC file into a preset universal bus analysis tool, observing whether the light responds as expected by simulating the sending of the CAN message constructed by the vehicle light control protocol DBC file, and verifying the correctness of the analysis result.

10. A vehicle light control protocol automatic parsing device, characterized by, The vehicle light control protocol automatic analysis device includes: A data acquisition and synchronization module is configured to execute one or a plurality of light events, acquire CAN communication data on a CAN bus and corresponding light change videos, the CAN communication data including a timestamp, a corresponding CAN identifier, and CAN data, the light change videos including a frame timestamp and a corresponding video frame, the CAN communication data and the light change videos being associated and synchronized by a timestamp alignment condition to obtain synchronized data; A signal behavior feature extraction and quantization module is configured to obtain synchronized data corresponding to a single light event, calculate one or a plurality of behavior feature vectors for CAN data corresponding to each CAN identifier, and obtain a behavior feature matrix. A signal behavior feature extraction and quantization module is configured to obtain synchronized data corresponding to a single light event, calculate one or a plurality of behavior feature vectors for CAN data corresponding to each CAN identifier, and obtain a behavior feature matrix. The feature analysis and target data determination module is configured to identify the behavior feature matrix to obtain a target CAN identifier and target CAN data corresponding to the light event; The data segmentation module is configured to statistically analyze all data frame sequences in the target CAN data to obtain a communication structure of the light event, and segment the target CAN data into a check area, a counter area, a payload area, and a padding area according to the communication structure; The CRC algorithm solving module is configured to obtain a CRC check algorithm and algorithm parameters thereof according to an actual check value of the check area, a counter of the counter area, and a data field of the payload area; The signal-visual correlation matrix construction module is configured to extract a signal time sequence of each to-be-analyzed signal in the target CAN data, quantize a brightness of each lamp bead in a video frame associated with the target CAN identifier synchronously into a visual time sequence, calculate a similarity of each pair of the signal time sequence and the visual time sequence to construct a signal-visual correlation matrix; The control rule induction module is configured to perform control semantic analysis on the signal-visual correlation matrix to obtain a control rule set of signal control lamp beads; The protocol integration module is configured to integrate the target CAN identifier, the target CAN data, the communication structure, the target parameters and target dynamic functions, and the control rule to obtain a standardized vehicle light control protocol DBC file; The simulation verification module is configured to import the vehicle light control protocol DBC file into a preset universal bus analysis tool, simulate sending a CAN message constructed by the vehicle light control protocol DBC file, and observe whether the light responds as expected to verify correctness of the analysis result.

Images