Automotive ECU and CAN bus log frame loss analysis system

Abstract

This invention discloses a system for analyzing frame loss in automotive ECU and CAN bus logs. The system is developed based on Python and Qt, employing a layered architecture design. It includes: multi-task worker threads, a DBC parsing adapter based on can-tools, a BLF parsing adapter based on python-can, structured data storage design, configuration management, CAN channel parsing, CAN message decoding and processing, a log frame loss analysis engine, a report generation business module, encapsulated and reused UI components, a CAN bus log analysis panel with dual progress bars for main and sub-tasks, dual log tracking boxes for main and sub-tasks, and an automotive industrial-grade information security and authorization module. This invention is primarily applied to bus testing, fault analysis, and data verification work in OEMs, component suppliers, testing institutions, and other organizations.

Description

Technical Field

[0001] This invention relates to the field of automotive electronics and vehicle network testing technology, and in particular to a system for analyzing lost frames in automotive ECU and CAN bus logs. Background Technology

[0002] As automotive electronic and electrical architecture evolves towards domain controllers and central computing platforms, CAN / CAN-FD buses have become the core carrier of in-vehicle network communication. Functions such as signal interaction between ECUs, diagnostic services, and network management highly depend on the integrity and real-time performance of bus data. Furthermore, the widespread application of automotive Ethernet and CAN / CAN-FD buses in automotive electronic systems has led to a continuous increase in the number of ECUs and the volume of bus communication data. Bus log analysis has become a crucial aspect of vehicle testing, ECU development, and fault localization. In scenarios such as vehicle bench testing, real-vehicle road testing, and ECU off-line testing, issues such as lost bus messages, timing anomalies, periodic jitter, and signal parsing errors can directly lead to functional failures, false diagnostics, and control logic anomalies, severely impacting vehicle development quality and delivery efficiency.

[0003] Currently, the industry commonly uses tools such as CANoe and CANalyzer for bus data recording and basic analysis. Message diagnostic engineers open an interface like CANoe, manually configure the CAN digital channel number, then match the CAN logical channel name in the DBC file with the aforementioned CAN digital channel number, and finally load the relevant signals from the BLF file, observing the specific values ​​of different timestamps to determine, based on experience, which CAN channel is experiencing frame drops. However, this traditional analysis method relies on manual processing using general-purpose bus tools, which suffers from cumbersome operation, low processing efficiency, slow loading of large files, unintuitive frame drop statistics, and difficulty in batch analysis, severely impacting problem localization speed and test delivery efficiency. Especially when the BLF files collected from vehicles are large (e.g., hundreds of MB or even GB in size), it is virtually impossible for engineers to visually inspect and analyze CAN bus message frame drops, and it is highly prone to errors and misjudgments. Summary of the Invention

[0004] To address the problems existing in the prior art, the purpose of this invention is to provide an automotive ECU and CAN bus log frame loss analysis system. This invention is mainly applied to bus testing, fault analysis, and data verification work in vehicle manufacturers, component suppliers, testing institutions, and other organizations.

[0005] To achieve the above objectives, the technical solution adopted by this invention is: a vehicle ECU and CAN bus log frame loss analysis system. The system is developed based on Python+Qt and adopts a layered architecture design, including: multi-task worker threads, a DBC parsing adapter based on can-tools, a BLF parsing adapter based on python-can, structured data storage design, configuration management, CAN channel parsing, CAN message decoding and processing, a log frame loss analysis engine, a report generation business module, UI component encapsulation and reuse, a CAN bus log analysis panel with dual progress bars for main and sub-tasks, dual log tracking boxes for main and sub-tasks, and an automotive industrial-grade information security and authorization module.

[0006] As a further improvement of the present invention, it specifically includes: a basic tool layer, a data access layer, a business service layer, a UI component layer, a presentation layer, and a security and authorization module; wherein:

[0007] The basic tool layer includes: a thread-safe log tracker, a thread interruption exception handler, a configuration file parser, a resource path generator, a frame loss log timestamp optimizer, a CAN message ID validity checker, and a multi-task worker thread;

[0008] The data access layer includes: a DBC parsing adapter, a BLF parsing adapter, and structured data storage;

[0009] The business service layer includes: a configuration management module, a CAN channel parsing module, a CAN message processing module, an analysis engine module, and a report generation module;

[0010] The UI component layer includes: a CAN channel mapping component, a clearable row editor, a clearable list control, a copyable label control, and a multi-column list component;

[0011] The presentation layer includes: the main program entry point of the log frame loss analyzer, the GUI registration code verification window, the ECU category list panel, the CAN bus channel parsing panel, and the CAN bus log analysis panel.

[0012] The security and authorization module includes: a hardware-bound machine code generator, an RSA asymmetric key generator, a registration code generation and verification mechanism, and a registration code loading and saving mechanism.

[0013] As a further improvement of the present invention, the structured data storage includes the following key data structures:

[0014] The CAN channel list is an array, where each node is a tuple containing the full path to the DBC file, the CAN logical channel name, and the CAN data channel number.

[0015] The configuration file result dictionary is a two-level nested dictionary, where each paragraph name serves as the first-level key of cfg_result_dict, and its value is a second-level dictionary;

[0016] The DBC mapping table is a dictionary where the key is the CAN channel number and the value is the corresponding union. The union contains dbc_obj and dbc_config. The dbc configuration information dictionary includes a set[str] of ECU node names, a set[int] of network management message IDs, and a list[dict] of all messages under the CAN channel. Each message information dictionary includes the original message ID, the hexadecimal value of the message ID, the message name, the ECU name of the message sender, the message period, and the message transmission type.

[0017] The channel-message-timestamp mapping table is a dictionary. The key is the CAN channel number, and the value is a second-level dictionary. The key of the second-level dictionary is the original ID of the message, and the value is a third-level message dictionary. The third-level message dictionary includes the message period and the timestamp list of the message, list[float].

[0018] The decoded message list is an array list, where each element is a dictionary object, including the digital channel, the original message ID, the hexadecimal value of the message ID, the timestamp, the signal set, and the original data value.

[0019] As a further improvement of the present invention, the log frame loss analysis engine specifically performs the following workflow:

[0020] Initialize the final list of dropped frame structure dictionaries;

[0021] Iterate through each CAN digital channel in the DBC mapping table;

[0022] Determine if the CAN digital channel exists; if not, return to the list and the process ends.

[0023] If so, calculate the current vehicle sleep / wake-up status of the CAN digital channel and return the status code and status information;

[0024] Determine if the vehicle's sleep / wake-up status code is 1. If it is not 1, it means the vehicle is in sleep mode. There is no need to check for packet loss. Return to the list and end the process.

[0025] If it is 1, it means that the vehicle is in a wake-up state. Then continue to calculate the frame loss situation of the application message of the current CAN digital channel and return the frame loss result dictionary.

[0026] Determine if the dictionary content of application message frame loss results exists. If it does, calculate the ECU category to which each application message frame loss result belongs and populate the ECU category list (final, kl15, hvar). Here, final is the list of log message frame loss result dictionaries to be returned, kl15 is the list of log message frame loss result dictionaries for the kl15 low-voltage power system type according to the ECU category to which the message sending node belongs, and hvar is the list of log message frame loss result dictionaries for the HVAR high-voltage accessory relay according to the ECU category to which the message sending node belongs.

[0027] If not, continue calculating the frame loss situation of ICG network management messages and return the frame loss result dictionary;

[0028] Determine if the dictionary of ICG network management message frame loss results exists. If it does, append the ICG network management message frame loss results to the final list. If not, continue to analyze the power supply status of kl15 and hvar type messages.

[0029] Iterate through each lost frame message of the KL15 non-network management ECU, determine whether the KL15 lost frame message exists, and if it does, calculate the single-cycle power supply status of the current message frame, return the KL15 message lost frame result dictionary and append it to the final list.

[0030] Iterate through each lost frame message of the hvar non-network management ECU, check if the hvar lost frame message exists, and if it does, calculate the single-cycle power supply status of the current message frame, return the hvar message lost frame result dictionary and append it to the final list;

[0031] Update the subtask progress bar status information and the subtask log tracking box log information, and return the final result list to end.

[0032] As a further improvement of the present invention, the calculation of the current vehicle sleep / wake-up state of the CAN digital channel is as follows:

[0033] Read the numerical identifiers of the fixed message usr_mod_id and icg_nm_id from the result dictionary read from the configuration file, and perform a validity check to ensure that the message ID is not empty and can successfully convert the input hexadecimal string into an integer.

[0034] If invalid, construct a dictionary of vehicle sleep / wake-up status results with a status code of -2, indicating that the fixed message ID in the configuration file is set incorrectly;

[0035] If valid, continue to verify the legality of the current CAN digital channel; if invalid, construct a dictionary of vehicle sleep / wake-up status results with a status code of -1, indicating an unknown CAN digital channel.

[0036] If valid, then based on the CAN digital channel number and the usr_mod_id value identifier, retrieve the timestamp value list usr_mode_ts_list from the channel-message-timestamp mapping table, and retrieve the timestamp value list icg_nm_ts_list based on the CAN digital channel number and the icg_nm_id value identifier;

[0037] Check if the contents of usr_mode_ts_list and icg_nm_ts_list exist. If not, construct a dictionary of vehicle hibernation / wake-up status results. The status code is 0, which means there are no messages and the vehicle is in hibernation.

[0038] If so, calculate vehicle_t0 as the time the first frame was lost, and take the minimum value between the timestamp t1 of the first node in usr_mode_ts_list and the timestamp t2 of the first node in icg_nm_ts_list.

[0039] Calculate vehicle_t1 as the time the last frame was lost, take the timestamp of the last node in usr_mode_ts_list as t3, take the timestamp of the last node in icg_nm_ts_list as t4, and take the global end time of the entire BLF file blf_time_end; calculate the disappearance time of usr_mod message delta_usr_mod = blf_time_end - t3, and the disappearance time of icg_nm message delta_icg_nm = blf_time_end - t4; if both usr_mod and icg_nm messages exist and disappear simultaneously for ≥2 seconds, then take t3 and t4 as the timestamps. 4. The maximum value of both is vehicle_t1 = max(t3, t4); if neither message exists, then vehicle_t1 = blf_time_end; if the usr_mod message exists but the icg_nm message does not exist, then if delta_usr_mod ≥ 2 seconds, then vehicle_t1 = t3, otherwise vehicle_t1 = blf_time_end; if the icg_nm message exists but the usr_mod message does not exist, then if delta_icg_nm ≥ 2 seconds, then vehicle_t1 = t4, otherwise vehicle_t1 = blf_time_end;

[0040] Then, the frame loss analysis time period is calculated. The effective time period for application messages is [vehicle_t0+1, vehicle_t1], and the effective time period for ICG network management messages is [vehicle_t0, vehicle_t1-2].

[0041] If vehicle_t0 < vehicle_t1, set status_code = 1 to indicate that the whole vehicle is awakened; otherwise, set status_code = 0 to indicate that the whole vehicle is in sleep mode.

[0042] Construct a dictionary for the result of the sleep / wake-up status of the whole vehicle, with the status code being status_code, and the process ends.

[0043] As a further improvement of the present invention, the specific method for calculating the frame loss situation of the application messages on the current CAN digital channel is as follows:

[0044] Initialize a list of dictionaries for frame loss results loss_list;

[0045] Loop through all the message lists in the current CAN data channel in the DBC mapping table;

[0046] Check if the message object in the list exists. If not, return the list loss_list and end the process;

[0047] If it exists, continue to check if the message belongs to the network management type. If so, continue to check the next message;

[0048] If not, continue to check the sending type of the message. If the check result is event type, filter it out and continue to check the next message; if the check result is periodic type, obtain the relevant attribute values of the message, including the identification ID, name, ECU node, and period;

[0049] According to the CAN data channel number and the message numerical identification, obtain the list of timestamp values msg_ts from the channel-message-timestamp mapping table;

[0050] Check if the content of the message timestamp value list exists. If not, construct a dictionary for frame loss results and append it to loss_list, and continue to check the next message;

[0051] If it exists, extract the timestamp values and convert them into a floating-point numpy array, and filter out the timestamp values in the specified time range [vehicle_t0 + 1, vehicle_t1] as in_range;

[0052] Check if in_range is empty. If so, it proves that there is no frame loss for this message, and continue to check the next message;

[0053] If not, calculate the adjacent time intervals of the timestamps, supplement the time interval of the last segment to the cut-off time, and mark the abnormal time intervals that exceed twice the period as abnormal;

[0054] Loop through the abnormal list and check if there are any abnormal intervals. If not, it means that the abnormal list has been traversed and the next message is checked.

[0055] If so, calculate the start time and end time of the anomaly for the current anomaly interval node: if it is the first anomaly node, then start_time = vehicle_t0 + 1, otherwise start_time = the time of the current anomaly node; if it is the last anomaly node, then end_time = vehicle_t1, otherwise end_time = the time of the next node adjacent to the current anomaly node.

[0056] Construct a dictionary of frame loss results and append it to the loss_list, then proceed with the processing of the next abnormal node.

[0057] As a further improvement of the present invention, the calculation of the single-cycle power supply status of the current message frame is specifically as follows:

[0058] (1) Based on the current CAN digital channel and the frame loss message identifier ID, extract the timestamp and the corresponding ECU power supply status signal value within the frame loss period from the decoded message list, and generate a power supply status sequence. The power supply status signal includes the kl15 low-voltage power supply system status signal and the hvar high-voltage accessory relay status signal.

[0059] (2) The power supply state sequence is deduplicated, and only the state switching points when the state changes are retained to obtain the state jump sequence;

[0060] (3) Identify the time t4 when the power supply state changes from off to on and the time t5 when it changes from on to off from the state transition sequence;

[0061] (4) Determine the frame loss result during the frame loss period based on the ECU power supply status:

[0062] (a) If the power supply is always on during the frame loss period, then record the frame loss period as [t2, t3].

[0063] (b) If there is a switch from power on to power off during the frame loss period and the power is not turned on again afterward, then it is further determined whether the difference between t3 and t4 is greater than the threshold. If so, the frame loss period is recorded as [t4+1,t3].

[0064] (c) If there is a power supply state switch from off to on during the frame loss period, then record the frame loss period as [t2, t5].

[0065] (5) Add the frame loss results obtained from the determination to the frame loss result list.

[0066] As a further improvement of the present invention, in the security and authorization module, the hardware binding machine code generator performs the following steps: instantiating a hardware information class, obtaining the local CPU unique identifier ID, motherboard serial number, physical MAC address, and system disk serial number; concatenating the hardware information to generate raw machine code; encoding the raw machine code using UTF-8 format to generate bytecode; and irreversibly encrypting the generated bytecode using a SHA256 hash library to generate a 64-bit hexadecimal unique machine code.

[0067] The RSA asymmetric key generator performs the following steps: using the RSA public key to generate a private key with automotive commercial and industrial security levels; using the private key to further generate an associated RSA public key; converting the generated RSA private key and public key in memory into standard format text strings; and writing the converted RSA public key and private key strings into local files in binary format for permanent storage.

[0068] The registration code generation workflow includes: loading an RSA private key encoded in UTF-8; calculating the registration code expiration time; setting a plaintext structured dictionary of registration information, including product ID, unique machine code, and registration code expiration time; encoding the plaintext dictionary of registration information in UTF-8 format and dumping it to generate JSON format bytecode; performing irreversible encryption calculation on the generated bytecode using a SHA256 hash library to generate a 64-bit hash value; performing signature calculation on the hash value using the RSA private key to generate a binary signature for data anti-counterfeiting and anti-tampering; converting the binary signature into Base64 format byte data using Base64 encoding rules; decoding the Base64 byte data into a plain string signature using UTF-8 format; concatenating the plaintext dictionary of registration information and the signature to synthesize the final registration code dictionary; dumping the final registration code dictionary to generate standard JSON format bytecode; encoding the standard JSON bytecode into binary bytes using UTF-8 format; converting the binary bytes into Base64 format byte data using Base64 encoding rules; and decoding the Base64 format bytes using UTF-8 format to convert the Base64 format bytes into a plain text string registration code.

[0069] As a further improvement of the present invention, the basic tool layer includes a unified task processing thread, the workflow of which is as follows:

[0070] The base offset and single task weight of each task are automatically calculated based on the total number of serial tasks. The current total progress of the main progress bar is calculated as follows: Current total progress of the main progress bar = base offset of task + (single task weight × current step / total steps).

[0071] The specific calculation steps are as follows: Divide the total progress value by the number of subtasks and take the integer part as the base weight (base_weight), then take the remainder (remainder); perform a for loop on the number of tasks, distribute each base weight (base_weight) to the first N tasks according to the remainder (remainder), and generate a weight list (task_weights) for each task; perform a for loop on the weight list (task_weights), calculate the base offset (offset) for each task, accumulate the weights of all previous tasks, and generate a list of task tuples;

[0072] In actual use, you can calculate the current total progress of the main progress bar by passing in the current step (current_step) and the total number of steps (total_steps).

[0073] Then check if the unified task processing thread is running. If not, end the process. If it is, process in the following order: execute CAN bus DBC file loading and parsing, and update the progress bar status information and log tracking box log information after completion; execute CAN bus BLF file loading and parsing, and update after completion; execute CAN bus log frame loss analysis engine, and update after completion; execute log analysis report generation module, and update and end the process after completion.

[0074] As a further improvement to the present invention, the following main program workflow is also included:

[0075] At startup, a single instance check is performed. If an instance is already running, a prompt is displayed and the application is exited. Otherwise, the configuration file is released and the application is initialized. Then, the local registration code file is searched. If it does not exist or the verification fails, the registration window is opened. If the verification passes, the main interface is opened directly.

[0076] This invention enables rapid parsing, intelligent diagnosis, frame loss statistics, and visualization output of vehicle CAN bus logs, providing a lightweight and professional support tool for vehicle network testing, ECU software integration, fault location, and problem reproduction.

[0077] The beneficial effects of this invention are:

[0078] The system of this invention has the characteristics of fast parsing speed, low resource consumption, strong compatibility and simple use. It can significantly reduce the cost of vehicle bus data analysis, improve the efficiency of fault location, and provide reliable engineering tools for vehicle network development and testing. After being put into use, it can bring significant benefits to vehicle network development, testing, fault diagnosis and other aspects. Specifically, it is reflected in: (1) improving data analysis efficiency, replacing the traditional manual analysis method, shortening the analysis time of a single log file from hours to minutes, and improving batch processing efficiency by several times; (2) reducing the skill threshold of personnel, without needing to be proficient in professional bus tools to complete decoding, frame loss statistics and anomaly detection, reducing training costs; (3) improving the accuracy of problem location, the system automatically identifies frame loss, period deviation, and other issues. (3) Eliminate abnormalities such as interruption and avoid manual omission or misjudgment, thereby improving the accuracy of fault location; (4) Standardize the output of test results, automatically generate standardized Excel reports, unify the analysis result format, and facilitate team sharing, problem reproduction and report output; (5) Support large files and batch processing, support long-term and large-capacity BLF log parsing, and meet the data review needs of scenarios such as real vehicle road tests and long-term bench tests; (6) Strengthen the traceability of the test process, fully record message timing, signal values ​​and node sending behavior, and provide data support for network performance optimization and ECU software iteration; (7) Ensure the security of enterprise tool assets, realize authorization management through hardware binding and registration code mechanism, avoid unauthorized dissemination of tools, and meet the industrial-grade information security requirements of automotive enterprises. Attached Figure Description

[0079] Figure 1 This is a diagram illustrating the overall system architecture in an embodiment of the present invention.

[0080] Figure 2 This is a flowchart of the main program in an embodiment of the present invention;

[0081] Figure 3 This is a flowchart illustrating the registration code verification process on the registration interface in this embodiment of the invention.

[0082] Figure 4 This is a flowchart illustrating the workflow of the RSA asymmetric key generator in an embodiment of the present invention.

[0083] Figure 5 A flowchart illustrating the process of creating a registration code in this embodiment of the invention;

[0084] Figure 6 This is a flowchart illustrating the registration code verification process in an embodiment of the present invention.

[0085] Figure 7 This is a flowchart illustrating the unified task processing thread in this embodiment of the invention.

[0086] Figure 8This is a flowchart of the CAN bus log frame loss analysis engine in an embodiment of the present invention.

[0087] Figure 9 This is a flowchart illustrating the process of calculating the vehicle's sleep / wake-up state in an embodiment of the present invention.

[0088] Figure 10 This is a flowchart illustrating the process of calculating application message loss in an embodiment of the present invention;

[0089] Figure 11 This is a flowchart illustrating the workflow for calculating ICG network management message loss in an embodiment of the present invention.

[0090] Figure 12 This is a flowchart-1 illustrating the workflow for calculating single-cycle power supply status message loss in an embodiment of the present invention;

[0091] Figure 13 This is a flowchart-2 illustrating the workflow for calculating single-cycle power supply status message loss in an embodiment of the present invention;

[0092] Figure 14 This is a data structure diagram of the CAN channel list in an embodiment of the present invention;

[0093] Figure 15 This is a diagram of the dictionary data structure of the configuration file results in an embodiment of the present invention;

[0094] Figure 16 This is a data structure diagram of the DBC mapping table in an embodiment of the present invention;

[0095] Figure 17 This is a data structure diagram of the channel-message-timestamp mapping table in an embodiment of the present invention;

[0096] Figure 18 This is a data structure diagram of the decoded message list in an embodiment of the present invention. Detailed Implementation

[0097] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0098] Example

[0099] A system for analyzing lost frames in automotive ECU and CAN bus logs includes: multi-task worker threads, a DBC parsing adapter based on can-tools, a BLF parsing adapter based on python-can, structured data storage design (supporting efficient querying and statistics), business modules such as configuration management, CAN channel parsing, CAN message decoding and processing, a log frame loss analysis engine, and report generation, as well as UI component encapsulation and reuse, development of a dual progress bar for main and sub-tasks and a dual log tracking box for main and sub-tasks in the CAN bus log analysis panel, and an automotive industrial-grade information security and authorization module.

[0100] Specifically, such as Figure 1 As shown, the overall system architecture design scheme of this embodiment adopts a layered + modular design to ensure scalability, and consists of 6 parts: basic tool layer, data access layer, business service layer, UI component layer, presentation layer, and security and authorization module.

[0101] (1) Basic tool layer: thread-safe log tracker, thread interruption exception handler, configuration file parser, resource path generator, frame loss log timestamp optimizer, CAN message ID validity checker, multi-task worker thread.

[0102] (2) Data access layer: DBC parsing adapter, BLF parsing adapter, structured data storage.

[0103] (3) Business service layer: configuration management module, CAN channel parsing module, CAN message processing module, analysis engine module, report generation module.

[0104] (4) UI component layer: CAN channel mapping component, clearable row editor, clearable list control, copyable label control, multi-column list component.

[0105] (5) Presentation layer: Log frame loss analyzer main program entry point, GUI registration code verification window, ECU category list panel, CAN bus channel parsing panel, CAN bus log analysis panel.

[0106] (6) Security and Authorization Module: Hardware-bound machine code generator, RSA asymmetric key generator, registration code generation and verification, registration code loading and saving.

[0107] The core workflow of this embodiment is described below:

[0108] I. Main program workflow as follows Figure 2 As shown, it includes:

[0109] (1) When the main program starts, it first checks whether it is a single running instance. This step specifically includes:

[0110] a) Set a unique mutex name to avoid conflicts with other processes;

[0111] b) Call Windows kernel32 dynamic link library APIs and define Windows API types;

[0112] c) Create an object handle for the system mutex, mutex_handle;

[0113] d) Get the latest error code last_error and check if it is 183.

[0114] (2) If last_error = 183, it means that the mutex lock already exists. Then, a system prompt box will pop up: "This tool process is already running. Please do not start it again!" and the process will end.

[0115] (3) If last_error != 183, it indicates that the system is running normally on the first startup;

[0116] (4) Following step (3), execute the initialization configuration directory. That is: extract the config / ecu_info.conf configuration directory and configuration file (specific location: C:\Users\admin\AppData\Local\Temp\_MEI*) from inside the EXE to the same directory as the EXE so that the user can load the contents of the configuration file in the main interface;

[0117] (5) Instantiate the application object and set "Close the last window to exit";

[0118] (6) Instantiate the crypto class for RSA asymmetric encryption;

[0119] (7) Use crypto to load local registration information. That is, check if the local registration code file exists.

[0120] (8) If the registration code file does not exist, open the registration window, call back to create and hold the main window handle, and end the process;

[0121] (9) If the registration code file is found, verify the local registration code;

[0122] (10) If the verification passes, create and hold the main window handle, open the main interface directly, and end the process;

[0123] (11) If the verification fails, the registration window will be opened, the main window handle will be created and held by callback, and the process will end.

[0124] II. The registration interface verification process for the registration code is as follows: Figure 3 As shown, it includes:

[0125] (1) Load the registration window resources and visualize the registration interface;

[0126] (2) Instantiate the hardware information class and create a unique object hw (single instance);

[0127] (3) Use hw to obtain the unique identifier id of the local CPU;

[0128] (4) Use hw to obtain the motherboard serial number of this machine;

[0129] (5) Use hw to obtain the local physical MAC address (filter virtual network cards);

[0130] (6) Use hw to obtain the serial number of the local system disk (C drive);

[0131] (7) Use hw to concatenate various hardware information such as the local CPU unique identifier id, motherboard serial number, physical MAC address, and system disk serial number to generate the original machine code;

[0132] (8) Encode the raw machine code using UTF-8 format to generate bytecode;

[0133] (9) Use the SHA256 hash library to irreversibly encrypt the generated bytecode and generate a 64-bit hexadecimal unique machine code;

[0134] (10) The user sends the unique machine code of the device to the developer, and the developer generates the corresponding registration code based on the RSA private key, the unique machine code and the preset registration code validity period.

[0135] (11) Users fill in the registration code on the registration interface and verify it;

[0136] (12) If the verification is successful, save the registration code to your local computer and then a "Verification successful" prompt box will pop up;

[0137] (13) Call the callback function to open the main interface and end the process;

[0138] (14) In step (10), if the verification fails, a “Verification failed” prompt box will pop up and the process will end.

[0139] III. The workflow of an RSA asymmetric key generator is as follows: Figure 4 As shown, it includes:

[0140] (2) Using RSA global public key index 65537 and key security standard length 2048, generate a private key of automotive commercial and industrial security level;

[0141] (2) Use the private key to generate an RSA public key associated with the private key;

[0142] (3) Convert the already generated RSA private key and public key in memory into a standard format text string (PEM);

[0143] (4) Write the converted RSA public key and private key strings into local files in binary format for permanent storage.

[0144] IV. The workflow for creating a registration code is as follows: Figure 5 As shown, it includes:

[0145] (1) Load the RSA private key encoded in UTF-8;

[0146] (2) Calculate the expiration time of the registration code. The default validity period is 1 month.

[0147] (3) Set up a plaintext structured dictionary for registration information, including: product ID, unique machine code, and registration code expiration time. The generation rule for product ID is: "product name of this system_version number of this release";

[0148] (4) Encode the plaintext dictionary of registration information in UTF-8 format and dump it to generate JSON format bytecode;

[0149] (5) Using the SHA256 hash library, perform irreversible encryption calculations on the generated bytecode to generate a 64-bit hash value;

[0150] (6) Use the RSA private key to perform signature calculation on the hash value to generate a binary signature for data anti-counterfeiting and anti-tampering. The padding scheme here adopts the PSS probabilistic signature scheme, the internationally standard MGF1 masking algorithm, the SHA256 high-strength hash algorithm (irreversible and collision-proof), and the random salt value salt_length adopts the maximum length salt value;

[0151] (7) Use Base64 encoding rules to convert the binary signature into byte data in Base64 format;

[0152] (8) Decode the Base64 bytes of data into a plain string signature using UTF-8 format;

[0153] (9) Combine the plaintext dictionary of registration information and the signature to synthesize the final registration code dictionary;

[0154] (10) Dump the final registration code dictionary to generate standard JSON format bytecode;

[0155] (11) Encode the standard JSON bytecode into binary bytes using UTF-8 format;

[0156] (12) Use the Base64 encoding rule to convert binary bytes into Base64 format byte data;

[0157] (13) Use UTF-8 format decoding to convert the Base64 format bytes into a plain text string registration code.

[0158] V. The registration code verification process is as follows: Figure 6 As shown, it includes:

[0159] (1) Convert the ordinary, plain text registration code string into Base64 binary byte code using UTF-8 encoding;

[0160] (2) Using the Base64 encoding rules, decode the encoded Base64 binary byte code and restore it to the original binary data;

[0161] (3) Use the JSON library to load the raw binary data and convert it into the final registration code dictionary;

[0162] (4) From the final registration code dictionary, obtain the signature string and the registration data structure dictionary according to the key value;

[0163] (5) Using the Base64 encoding rules, decode the Base64 encoded signature string and convert it into a binary bytecode signature;

[0164] (6) Dump the registered data structured dictionary to generate standard JSON format bytecode;

[0165] (7) Encode the standard JSON bytecode into binary byte data using UTF-8 format;

[0166] (8) Use the RSA public key to verify the signature of the binary byte code and the binary byte data to prevent forgery. The padding scheme here adopts the PSS probabilistic signature scheme, the internationally standard MGF1 masking algorithm, the SHA256 high-strength hash algorithm (irreversible and collision-proof), and the random salt value salt_length adopts the maximum length salt value;

[0167] (9) Verify if the signature verification was successful? If not, return False, the signature verification failed, and the process ends;

[0168] (10) If so, continue to obtain the product identifier ID, unique machine code, and expiration time from the registered data structure dictionary according to the key value;

[0169] (11) Verify whether the product identifier ID matches the inherent product identifier ID of this system (the generation rule of the product identifier ID is: "product name of this system_version number of this release")? If not, return False, the registration code does not match the product, and the process ends;

[0170] (12) If yes, continue to check if the unique machine code and the locally generated machine code are consistent. If no, return False, the registration code does not match the current machine code, and the process ends;

[0171] (13) If not, continue to check if the registration code has expired. If not, return False, the registration code has expired, and the process ends.

[0172] (14) If so, return True, the registration code verification is successful, and the process ends.

[0173] VI. Unified task processing thread workflow as follows Figure 7 As shown, it includes:

[0174] (1) Based on the total number of serial tasks, automatically calculate the base offset + single task weight for each task. Then, the current total progress of the main progress bar is calculated as follows: Current total progress of the main progress bar = base offset of the task + (single task weight * current step / total steps), which is used when updating the progress status of the GUI progress bar;

[0175] a) The total progress value is calculated as 100 by default. Divide it by the number of subtasks, round it down to the nearest integer as the base weight, and then take the remainder.

[0176] b) Perform a for loop on the number of tasks, distribute each base weight (base_weight) to the first N tasks according to the remainder (remainder), ensuring that the total is 100, and finally generate a weight list (task_weightss) for each task.

[0177] c) Perform a for loop on the weight list task_weights, calculate the base offset for each task, accumulate the weights of all previous tasks offset += weight, and finally generate a list of task tuples: task_progress_list=[(offset1,weight1),(offset2,weight2),(offset3,weight3),(offset4,weight4),……];

[0178] d) In actual use, simply pass in the current step (current_step) and the total number of steps (total_steps) to calculate the current total progress of the main progress bar. For example:

[0179] When step 1 is completed, the current total progress of the main progress bar is:

[0180] main_progress=task_progress_list[0][0]+task_progress_list[0][1]*current_step / total_steps;

[0181] When step 2 is completed, the current total progress of the main progress bar is:

[0182] main_progress=task_progress_list[1][0]+task_progress_list[1][1]*current_step / total_steps;

[0183] (2) Check if the unified task processing thread is running. If not, terminate the process.

[0184] (3) If the judgment in step (2) is yes, then process step 1: execute the CAN bus DBC file loading and parsing;

[0185] (4) After step 1 is completed, update the status information of the progress bar and update the log information of the log tracking box;

[0186] (5) Check if the unified task processing thread is running. If not, terminate the process.

[0187] (6) If the judgment in step (5) is yes, then proceed to step 2: execute the CAN bus BLF file loading and parsing;

[0188] (7) After step 2 is completed, update the status information of the progress bar and update the log information of the log tracking box;

[0189] (8) Check if the unified task processing thread is running. If not, terminate the process.

[0190] (9) If the judgment in step (8) is yes, then process step 3: execute the CAN bus log frame loss analysis engine;

[0191] (10) After step 3 is completed, update the status information of the progress bar and update the log information of the log tracking box;

[0192] (11) Check if the unified task processing thread is running. If not, terminate the process.

[0193] (12) If the judgment in step (11) is yes, then proceed to step 4: execute the log analysis report generation module;

[0194] (13) After step 4 is completed, update the status information of the progress bar, update the log information of the log tracking box, and end the process.

[0195] VII. The workflow of the CAN bus log frame loss analysis engine is as follows: Figure 8 As shown, it includes:

[0196] (1) Initialize the final frame dropping structure dictionary list;

[0197] (2) Use a For loop to iterate through each CAN digital channel in the DBC mapping table;

[0198] (3) Determine if the CAN data channel exists. If not, return to list final and end;

[0199] (4) If step (3) is true, calculate the vehicle sleep wake-up status of the current CAN digital channel and return the status code and status information;

[0200] (5) Determine if the vehicle's sleep / wake-up status code is 1. If it is not 1, it means the vehicle is in sleep mode. There is no need to check for packet loss. Return to list final directly and end.

[0201] (6) If step (5) is 1, it means that the vehicle is in the wake-up state. Then continue to calculate the application message frame loss situation of the current CAN digital channel and return the frame loss result dictionary.

[0202] (7) Determine if the dictionary contents of the (application message) frame loss result exist.

[0203] (8) If so, calculate the ECU category to which each application message frame loss result belongs, and populate the ECU category list (final, kl15, hvar) accordingly. Here, final is the dictionary list of log message frame loss results to be returned; subsequent processing logic will continue to populate / expand the content of this list object. After all log frame loss analysis is completed, the data from this list object is used to generate a log frame loss analysis report Excel. kl15 is the dictionary list of log message frame loss results for the KL15 low-voltage power supply system type (responsible for ignition switch activation power) based on the ECU category to which the message sending node belongs; hvar is the dictionary list of log message frame loss results for the HVAR high-voltage accessory relay based on the ECU category to which the message sending node belongs. The contents of both the kl15 and hvar dictionary lists need to be further analyzed for power supply status.

[0204] (9) If not, skip step (8), continue to calculate the frame loss situation of ICG network management messages, and return the frame loss result dictionary;

[0205] (10) Determine if the dictionary contents of the (ICG network management message) frame loss result exist.

[0206] (11) If so, append the ICG network management message frame loss results to the final list;

[0207] (12) If not, skip step (11) and continue with the power supply status analysis of KL15 and HVAR type messages;

[0208] (13) Use a For loop to iterate through each lost frame message of the KL15 non-network management ECU;

[0209] (14) Determine if the KL15 frame loss message exists.

[0210] (15) If so, calculate the single-cycle power supply status of the current message frame, return the KL15 message frame loss result dictionary, and append it to the final list;

[0211] (16) If not, skip step (15) and continue processing the power supply status analysis of the HVAR message;

[0212] (17) Use a For loop to iterate through each lost frame message of the HVAR non-network management ECU;

[0213] (18) Determine if HVAR frame loss messages exist.

[0214] (19) If so, calculate the single-cycle power supply status of the current message frame, return the HVAR message frame loss result dictionary, and append it to the final list;

[0215] (20) If not, skip step (19), directly update the subtask progress bar status information, update the subtask log tracking box log information; then return to step (3) to check the next CAN data channel. Otherwise, does it exist? Continue until all CAN data channels have been traversed, return the final result list, and end.

[0216] 8. The workflow for calculating the vehicle's hibernation and wake-up state is as follows: Figure 9 As shown, it includes:

[0217] (1) Read the numerical identifiers of the fixed message usr_mod_id and icg_nm_id from the result dictionary read from the configuration file, and perform a validity check;

[0218] (2) Determine if usr_mod_id and icg_nm_id are valid? The specific logic is: check that the message ID is not empty and that the input hexadecimal string can be successfully converted into an integer (automatically handle the "0x" prefix);

[0219] (3) If step (2) is not correct, construct the whole vehicle sleep wake-up status result dictionary, status code = -2, indicating "configuration file fixed message ID setting error", and end;

[0220] (4) If step (2) is correct, then continue to verify the validity of the current CAN digital channel;

[0221] (5) If step (4) is not true, construct the vehicle sleep wake-up status result dictionary, status code = -1, indicating "unknown CAN digital channel", and end;

[0222] (6) If step (4) is correct, then continue to obtain the timestamp value list usr_mode_ts_list from the channel-message-timestamp mapping table according to the CAN digital channel number and usr_mod_id value identifier;

[0223] (7) Continue to obtain the timestamp list icg_nm_ts_list from the channel-message-timestamp mapping table based on the CAN digital channel number and icg_nm_id value identifier;

[0224] (8) Check if the contents of usr_mode_ts_list and icg_nm_ts_list exist?

[0225] (9) If step (8) is not true, construct the vehicle hibernation / wake-up status result dictionary, status code = 0, indicating "no message, vehicle hibernation", and end;

[0226] (10) If step (8) is true, then calculate vehicle_t0 as the time of loss of the first frame message. The processing logic is: take the minimum value of the timestamp t1 of the first node in usr_mode_ts_list and the timestamp t2 of the first node in icg_nm_ts_list, that is, vehicle_t0 = min(t1, t2);

[0227] (11) Calculate vehicle_t1 as the time of loss of the last frame, and process the logic as follows:

[0228] a) Take the timestamp of the last node in usr_mode_ts_list as t3, take the timestamp of the last node in icg_nm_ts_list as t4, and take the global end time of the entire blf file blf_time_end;

[0229] b) Calculate the disappearance time of usr_mod messages: delta_usr_mod = blf_time_end - t3, and the disappearance time of icg_nm messages: delta_icg_nm = blf_time_end - t4;

[0230] c) If both usr_mod and icg_nm messages exist and disappear simultaneously for ≥2 seconds, i.e. delta_usr_mod≥2s and delta_icg_nm≥2s, then take the maximum value of t3 and t4: vehicle_t1 = max(t3, t4).

[0231] d) If neither usr_mod nor icg_nm exists, then the global end time of the entire BLF file is used, i.e.: vehicle_t1 = blf_time_end

[0232] e) If the usr_mod message exists, but the icg_nm message does not exist: further, if the usr_mod message disappears for ≥2 seconds, i.e., delta_usr_mod ≥2s, then: vehicle_t1 = t3; otherwise: vehicle_t1 = blf_time_end;

[0233] f) If the icg_nm message exists, but the usr_mod message does not exist: further, if the icg_nm message disappears for ≥2 seconds, i.e., delta_icg_nm ≥ 2s, then vehicle_t1 = t4; otherwise, vehicle_t1 = blf_time_end.

[0234] (12) Calculate the frame loss analysis time period. The effective time period for application messages is [vehicle_t0 + 1, vehicle_t1], and the effective time period for ICG network management messages is [vehicle_t0, vehicle_t1 - 2]. Note: To prevent individual ECUs from starting slowly, application messages will stop being sent 2 seconds after network management messages are stopped.

[0235] (13) Final status_code determination check for vehicle hibernation and wake-up: If vehicle_t0 < vehicle_t1, set status_code = 1, indicating "vehicle wake-up"; otherwise, set status_code = 0, indicating "vehicle hibernation";

[0236] (14) Construct a dictionary of vehicle sleep and wake-up status results, status code = status_code, and end.

[0237] IX. Workflow for calculating application message loss as follows Figure 10 As shown, it includes:

[0238] (1) Initialize the dictionary list of frame loss results, loss_list;

[0239] (2) Use a For loop to iterate through the list of all messages in the current CAN data channel in the DBC mapping table;

[0240] (3) Does the Chinese character object in the list exist?

[0241] (4) If step (3) is not successful, return the list loss_list and end;

[0242] (5) If step (3) is yes, then continue to determine whether the message belongs to the network management type message.

[0243] (6) If step (5) is correct, then continue to check the next message, because it is necessary to calculate the application message loss and filter out network management messages.

[0244] (7) If step (5) is not correct, it proves that the message is not a network management message. Then continue to check the sending type of the message.

[0245] (8) If the result of step (7) is an event type (transmit_type = 3), it needs to be filtered out and the next message needs to be checked.

[0246] (9) If the check result in step (7) is periodic (transmit_type = 0), then obtain the relevant attribute values ​​of the message, including: ID, name, ECU node, and period;

[0247] (10) Obtain the timestamp list msg_ts from the channel-message-timestamp mapping table based on the CAN data channel number, message value identifier, and the channel-message-timestamp mapping table;

[0248] (11) Determine if the timestamp value list of the message exists.

[0249] (12) If step (10) is not correct, construct the lost frame result dictionary and append it to loss_list, return to step (3), and continue to check the next message;

[0250] (13) If step (10) is true, extract the timestamp values ​​and convert them into floating-point NumPy arrays, and filter out the timestamp values ​​in_range within the specified time range [vehicle_t0 + 1, vehicle_t1];

[0251] (14) Determine if in_range is empty?

[0252] (15) If step (13) is correct, it proves that the message has not lost any frames. Then return to step (3) and continue to check the next message.

[0253] (16) If not in step (13), calculate the adjacent time intervals of the timestamps and add the time interval from the last segment to the deadline;

[0254] (17) Mark abnormal time intervals that exceed twice the cycle;

[0255] (18) Use a For loop to iterate through the abnormal list;

[0256] (19) Determine if there is an abnormal interval in the task.

[0257] (20) If step (18) is not correct, it means that the abnormal list has been traversed. Then return to step (3) and continue to check the next message.

[0258] (21) If step (18) is correct, then for the current abnormal interval node, calculate the abnormal start time and abnormal end time. The specific logic is:

[0259] a) Calculate the start time: If it is the first abnormal node, then start_time = vehicle_t0 + 1; otherwise, start_time = the time of the current abnormal node;

[0260] b) Calculate the end time: If it is the last abnormal node, then ene_time = vehicle_t1; otherwise, end_time = the time of the next node adjacent to the current abnormal node;

[0261] (22) Construct a dictionary of frame loss results and append it to loss_list, and then process the next abnormal node.

[0262] 10. The workflow for calculating ICG network management message loss is as follows: Figure 11 As shown, it includes:

[0263] (1) Initialize the dictionary list of frame loss results, loss_list;

[0264] (2) Read the numerical identifier of the fixed message icg_nm_id from the result dictionary read from the configuration file and perform a validity check. The specific logic is as follows: check that the message ID is not empty and that the input hexadecimal string can be successfully converted into an integer (automatically handling the "0x" prefix).

[0265] (3) Determine if icg_nm_id is valid.

[0266] (4) If step (3) is not successful, return the list loss_list and end;

[0267] (5) If step (3) is correct, then continue to verify the validity of the current CAN data channel. The specific logic is: confirm that the current CAN digital channel is in the DBC mapping table and also in the channel-message-timestamp sequence mapping table;

[0268] (6) Determine if the CAN digital channel is valid.

[0269] (7) If step (6) is not successful, return the list loss_list and end;

[0270] (8) If step (6) is true, then find the message information dictionary in the DBC mapping table according to the network management message value identifier;

[0271] (9) Obtain the relevant attribute values ​​of the message from the message information dictionary, including: ID, name, ECU node, and period;

[0272] (10) Obtain the timestamp list msg_ts from the channel-message-timestamp mapping table based on the CAN digital channel number, message value identifier, and the channel-message-timestamp mapping table;

[0273] (11) Determine if the contents of the timestamp value list msg_ts of the message exist.

[0274] (12) If step (11) is not correct, construct the dictionary of lost frames and append it to loss_list, return the list loss_list, and end;

[0275] (13) If step (11) is correct, extract the timestamp values ​​and convert them into floating-point NumPy arrays, and filter out the timestamp values ​​in_range within the specified time range [vehicle_t0, vehicle_t1 - 2]. Note: To prevent individual ECUs from starting slowly, the application messages will stop being sent 2 seconds after the network management messages stop being sent.

[0276] (14) Determine if in_range is empty?

[0277] (15) If step (14) is not successful, return the list loss_list and end;

[0278] (16) If step (14) is true, calculate the adjacent time intervals of the timestamps and add the time interval from the last segment to the deadline.

[0279] (17) Mark abnormal time intervals that exceed twice the cycle;

[0280] (18) Use a For loop to iterate through the abnormal list;

[0281] (19) Determine if there are any abnormal intervals.

[0282] (20) If step (19) is not true, it means that the abnormal list has been traversed. Then return the list loss_list and end.

[0283] (21) If step (19) is correct, then for the current abnormal interval node, calculate the abnormal start time and abnormal end time. The specific logic is:

[0284] a) Calculate the start time: If it is the first abnormal node, then start_time = vehicle_t0; otherwise, start_time = the time of the current abnormal node;

[0285] b) Calculate the end time: If it is the last abnormal node, then ene_time = vehicle_t1 - 2; otherwise, end_time = the time of the next node adjacent to the current abnormal node;

[0286] (22) Construct a dictionary of frame loss results and append it to loss_list, and then process the next abnormal node.

[0287] XI. Workflow for Calculating Single-Cycle Power Supply Status Message Loss - 1 Figure 12 As shown, it includes:

[0288] (1) Based on the dual input conditions: the current CAN digital channel and the lost frame message identifier ID, extract the valid message from the message list after BLF decoding and add it to the filtered message list filtered_msg_list;

[0289] (2) Extract valid messages whose timestamp values ​​are within the range [t2, t3] from filtered_msg_list and add them to the message list filtered_msg_in_range. Where Tn = tn+1 - tn; Tn is the nth period of a message, and tn is the time of the nth frame of a message; if Tn > (2) times the period, then t2 is tn and t3 is tn+1;

[0290] (3) Sort the filtered_msg_in_range list in ascending order according to the timestamp value of the decoded message;

[0291] (4) Initialize the power state sequence tuple list power_states for lost frame messages;

[0292] (5) Use a For loop to iterate through the filtered_msg_in_range list;

[0293] (6) Determine if the message object in the list exists?

[0294] (7) If step (6) is not true, it means that the filtered_msg_in_range list has been traversed. Then return the power_states list and end.

[0295] (8) If step (6) is true, then for the current message object, obtain the decoded timestamp ts; and according to the input condition rly_sts_id (the actual input is: KL15RlySts and HVARRlySts strings), obtain the decoded signal value signal_value;

[0296] (9) Continue to check if signal_value exists?

[0297] (10) If step (9) is not successful, proceed to process the next message object;

[0298] (11) If step (9) is true, then set the bool variable is_on, and its value is: get the raw value raw_value=1 in signal_value, or the name value named_value=”ON” in signal_value;

[0299] (12) Add ts and is_on as tuples to the power_states list, and then process the next message object.

[0300] 12. Workflow for calculating single-cycle power supply status message loss - 2 Figure 13 As shown, it includes:

[0301] (1) Initialize the dictionary list of frame loss results, loss_list;

[0302] (2) Initialize the list of unique state tuples unique_states, and initialize the previous state bool type prev_state to be empty;

[0303] (3) Use a For loop to iterate through the list of power state sequence tuples, power_states;

[0304] (4) Determine if the list contains a (ts, is_on) tuple object?

[0305] (5) If step (4) is true, then continue to determine whether ts (current state) ≠ prev_state (previous state) ?

[0306] (6) If step (5) is true, then append ts and is_on as tuples to the unique_states list;

[0307] (7) Update the previous state to the current state: prev_state = is_on, and then continue to check the next tuple object;

[0308] (8) If step (5) is not correct, proceed to the next tuple object for inspection;

[0309] (9) If step (4) is not true, it means that the power_states list has been traversed. Then continue to iterate through the unique_states list in the for loop.

[0310] (10) Does the list contain a tuple object of type (ts, is_on)?

[0311] (11) If step (10) is true, then obtain the previous state prev_ts, prev_on, and obtain the current state curr_ts, curr_on;

[0312] (12) Determine if prev_on = False and curr_on = True.

[0313] (13) If step (12) is correct, then record the current time as t4, that is: t4 = curr_ts;

[0314] (14) Continue to check if prev_on = True and curr_on = False.

[0315] (15) If step (14) is correct, record the current time as t5, i.e.: t5 = curr_ts, and then continue to check the next tuple object;

[0316] (16) If step (12) is not correct, proceed directly to the judgment in step (14);

[0317] (17) If step (14) is not correct, proceed to the next tuple object for inspection;

[0318] (18) If step (10) is not true, it means that the unique_states list has been traversed. Then, record all nodes of the True state in power_states as all_on and all nodes of the False state in power_states as all_off.

[0319] (19) Determine if all_on = True?

[0320] (20) If step (19) is true, construct the dictionary of frame loss results and append it to loss_list. At this time, set the frame loss period (start_time = t2, end_time = t3);

[0321] (21) If step (19) is not correct, then continue to check if t4 exists, but t5 does not exist.

[0322] (22) If step (21) is correct, then continue to determine if t3 – t4 > 1?

[0323] (23) If step (22) is correct, construct the dictionary of frame loss results and append it to loss_list. At this time, set the frame loss period (start_time = t4 + 1, end_time = t3);

[0324] (24) Continue to determine if t5 exists.

[0325] (25) If step (24) is correct, construct the dictionary of frame loss results and append it to loss_list. At this time, set the frame loss period (start_time = t2, end_time = t5);

[0326] (26) Return the list loss_list, and the process ends;

[0327] (27) If step (21) is not correct, proceed directly to step (24);

[0328] (28) If step (22) is not correct, proceed directly to step (24);

[0329] (29) If step (24) is not correct, proceed directly to step (26);

[0330] Summary of this workflow:

[0331] The first part of the processing logic is to retain only the first one of the continuously repeating power states, filter out the repeated ones in the middle, and only extract the time when the state changes (i.e., the state switching point such as t4 and t5).

[0332] Example: Raw data (repeated many times consecutively):

[0333] 10:00 Power on → 10:01 Power on → 10:02 Power on → 10:03 Power off → 10:04 Power off

[0334] After deduplication (only the switching point is retained): Power on at 10:00, power off at 10:03.

[0335] The second part of the processing logic: Accurately locate the following power state transition points after deduplication:

[0336] t4 = the time when the power supply changes from off to on; t5 = the time when the power supply changes from on to off.

[0337] Example: Power supply status after deduplication:

[0338] 10:00 OFF, 10:05 ON (OFF → ON), 10:10 OFF (ON → OFF)

[0339] The results are: t4 = 10:05, t5 = 10:10

[0340] The third part of the processing logic is as follows: Based on the ECU power supply status (full name ON / OFF, t4 power on, t5 power off), determine the time interval of the lost frame, record the log and add the lost frame information to the analysis list. If the ECU is in the OFF state for the entire time, no processing is performed.

[0341] The key data structures in this embodiment include:

[0342] like Figure 14 As shown, the CAN channel list (can_channels_list) is an array. Each node in the array is a tuple, and each tuple contains: (full path to the DBC file, CAN logical channel name, CAN data channel number). For example:

[0343] D:\VehicleLogFrameAnalyzer\XEAZON_ALL_SDB2560_Body_Domain_CAN_Fix_20251230.dbc

[0344] Body_Domain_CAN

[0345] CAN1.

[0346] like Figure 15 As shown, the configuration file result dictionary: The configuration file result dictionary cfg_result_dict is a two-level nested dictionary. After the system reads the configuration file ecu_info.conf, it uses the name of each paragraph (e.g., NET_MGR_ECU) as the first-level key of cfg_result_dict, and its value is a second-level dictionary (e.g., the NET_MGR_ECU dictionary). The key and value of this second-level dictionary are configured with different content according to business requirements.

[0347] For example, the key of the NET_MGR_ECU dictionary is the English identifier ID of the network management ECU, and the value is the Chinese name of the ECU;

[0348] For example, the key of the MESSAGE_IDS dictionary is the message name identifier, and the value is the hexadecimal value of the message ID.

[0349] like Figure 16 As shown, the DBC mapping table:

[0350] (1) The DBC mapping table data structure is relatively complex. It is the basis for performing CAN bus log frame loss analysis and memory calculation.

[0351] (2) The DBC mapping table dbc_map is a dictionary, where the key is the CAN channel number and the value is the corresponding union.

[0352] (3) The Union object contains two contents: the value corresponding to key = dbc_obj is the cantools.database.Database object instance db under a certain CAN channel, which is responsible for decoding the message signals in the blf file; the value corresponding to key = dbc_config is the dbc configuration information dictionary;

[0353] (4) The DBC configuration information dictionary contains three parts:

[0354] a) The value corresponding to key = ecu_nodes is a set of ECU node names set[str]. The ECU name strings in this set do not contain duplicate data, such as: BDC, VCU, MCRT, etc.

[0355] b) The value corresponding to key = nm_msg_ids is a set[int] of network management message IDs. The message IDs in this set are all unique ID values ​​within the range [0x18FFA000, 0x18FFA0FF].

[0356] c) The value corresponding to key = msg_info_list is a list [dict] of all messages under the CAN channel. Each element in this list is a message information dictionary msg_info_dict, and the content of each msg_info_dict is a key-value pair, specifically including:

[0357] [key = raw_arbitration_id (original ID of the message), value (int)];

[0358] [key = hex_arbitration_id (hexadecimal value of message ID), value (str)];

[0359] [key = msg_name (message name), value (str)];

[0360] [key = transmitters (message sender ECU name), value (str)];

[0361] [key = cycle_time (message cycle), value (float)];

[0362] [key = transmit_type (message transmission type), value (int)] Note (0: periodic type, 3: event type).

[0363] like Figure 17 As shown, the channel-message-timestamp mapping table is as follows:

[0364] (1) The channel-message-timestamp mapping table data structure is designed to provide the CAN bus log frame loss analysis engine with the ability to quickly search for a series of timestamp information of a specified message in a certain CAN channel and compare and calculate with the sending period of the specified message.

[0365] (2) The channel-message-timestamp mapping table is a dictionary, where the key is the CAN channel number and the value is the corresponding second-level dictionary dict;

[0366] (3) Each dict object is also a dictionary, with key = arb_id (original message ID) and value is the corresponding third-level message dictionary msg_dict;

[0367] (4) Each message dictionary object msg_dict contains two key-value pairs:

[0368] a) key = cycle_time (the sending cycle of this message), value (float) is the specific numerical value;

[0369] b) key = timestamps (a list of timestamps for the message), value (list[float]) is the corresponding list of timestamps;

[0370] (5) The timestamp list stores a series of timestamp element values ​​for a message;

[0371] like Figure 18 As shown, the list of decoded messages is as follows:

[0372] (1) Decoded message list, used to store message information after decoding BLF files using DBC rules in memory;

[0373] (2) The decoded message list, decoded_msg_list, is an array list, where each element is a dict dictionary object;

[0374] (3) The contents of the decoded message dictionary `dict` are all key-value pairs, specifically including:

[0375] [key = digital_channel (digital channel), value (str)];

[0376] [key = raw_arb_id (original message ID), value (int)];

[0377] [key = hex_raw_id (hexadecimal value of message ID), value (str)];

[0378] [key = timestamp (timestamp), value (float)];

[0379] [key = signals (signal set), value (DecodeResultType)];

[0380] [key = raw_data (raw data value), value (byte array)];

[0381] (4) The DecodeResultType is a dictionary containing key-value pairs. The key is the signal name identifier string, and the value is the corresponding numerical value (types include int, float, str, etc.).

[0382] (5) Raw binary byte array: The type is bytearray, and the specific value is, for example: bytearray(b'\x00\x00\x00\x00\x00\x10\x00'), which needs to be decoded using the database object of DBC.

[0383] This embodiment has the following main functions:

[0384] (1) Multi-format log parsing: Supports reading of Vector BLF format bus logs, compatible with standard CAN frames, extended frames, data frames and remote frames, can efficiently parse massive bus data, supports low memory streaming reading, and avoids lag when loading large files;

[0385] (2) DBC signal decoding: Supports loading DBC database files, automatically completes message ID matching, signal physical value parsing, sending node identification, and sending period extraction, and supports multi-channel and multi-DBC parallel mapping and parsing;

[0386] (3) Frame loss anomaly analysis: Based on features such as message period, transmission timing, and continuous frame interval, it automatically identifies anomalies such as frame loss, period deviation, frame loss, and ECU transmission interruption, and supports multi-dimensional statistics by channel, ID, and ECU node;

[0387] (4) Visualization and progress management: Provides a graphical operation interface, supports file drag and drop, real-time progress display and log output, reduces the threshold for use and improves processing efficiency;

[0388] (5) Automatic report export: Supports exporting analysis results into standardized Excel reports, including frame loss type, start time, end time, duration, message period, network segment name, sending node, message name, message ID, etc., which facilitates problem archiving, test report output, and review and traceability.

[0389] (6) Software security and authorization management: Built-in hardware binding, asymmetric encryption, and machine code-registration code verification mechanism to ensure the security of software authorization and use, support enterprise internal deployment and permission control, and prevent unauthorized dissemination and use.

[0390] The embodiments described above are merely illustrative of specific implementations of the present invention, and while the descriptions are detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention.

Claims

1. A system for analyzing lost frames in automotive ECU and CAN bus logs, characterized in that, The system is developed based on Python and Qt, and adopts a layered architecture design, including: multi-task worker threads, a DBC parsing adapter based on can-tools, a BLF parsing adapter based on python-can, structured data storage design, configuration management, CAN channel parsing, CAN message decoding and processing, log frame loss analysis engine, report generation business module, UI component encapsulation and reuse, CAN bus log analysis panel with dual progress bars for main and sub-tasks, dual log tracking boxes for main and sub-tasks, and automotive industrial-grade information security and authorization module.

2. The automotive ECU and CAN bus log frame loss analysis system according to claim 1, characterized in that, Specifically, it includes: The system comprises the following layers: basic tools layer, data access layer, business service layer, UI component layer, presentation layer, and security and authorization module; among which: The basic tool layer includes: a thread-safe log tracker, a thread interruption exception handler, a configuration file parser, a resource path generator, a frame loss log timestamp optimizer, a CAN message ID validity checker, and a multi-task worker thread; The data access layer includes: a DBC parsing adapter, a BLF parsing adapter, and structured data storage; The business service layer includes: a configuration management module, a CAN channel parsing module, a CAN message processing module, an analysis engine module, and a report generation module; The UI component layer includes: a CAN channel mapping component, a clearable row editor, a clearable list control, a copyable label control, and a multi-column list component; The presentation layer includes: the main program entry point of the log frame loss analyzer, the GUI registration code verification window, the ECU category list panel, the CAN bus channel parsing panel, and the CAN bus log analysis panel. The security and authorization module includes: a hardware-bound machine code generator, an RSA asymmetric key generator, a registration code generation and verification mechanism, and a registration code loading and saving mechanism.

3. The automotive ECU and CAN bus log frame loss analysis system according to claim 1 or 2, characterized in that, The structured data storage includes the following key data structures: The CAN channel list is an array, where each node is a tuple containing the full path to the DBC file, the CAN logical channel name, and the CAN data channel number. The configuration file result dictionary is a two-level nested dictionary, where each paragraph name serves as the first-level key of cfg_result_dict, and its value is a second-level dictionary; The DBC mapping table is a dictionary where the key is the CAN channel number and the value is the corresponding union. The union contains dbc_obj and dbc_config. The dbc configuration information dictionary includes a set[str] of ECU node names, a set[int] of network management message IDs, and a list[dict] of all messages under the CAN channel. Each message information dictionary includes the original message ID, the hexadecimal value of the message ID, the message name, the ECU name of the message sender, the message period, and the message transmission type. The channel-message-timestamp mapping table is a dictionary. The key is the CAN channel number, and the value is a second-level dictionary. The key of the second-level dictionary is the original ID of the message, and the value is a third-level message dictionary. The third-level message dictionary includes the message period and the timestamp list of the message, list[float]. The decoded message list is an array list, where each element is a dictionary object, including the digital channel, the original message ID, the hexadecimal value of the message ID, the timestamp, the signal set, and the original data value.

4. The automotive ECU and CAN bus log frame loss analysis system according to claim 3, characterized in that, The log frame loss analysis engine specifically executes the following workflow: Initialize the final list of dropped frame structure dictionaries; Iterate through each CAN digital channel in the DBC mapping table; Determine if the CAN digital channel exists; if not, return to the list and the process ends. If so, calculate the current vehicle sleep / wake-up status of the CAN digital channel and return the status code and status information; Determine if the vehicle's sleep / wake-up status code is 1. If it is not 1, it means the vehicle is in sleep mode. There is no need to check for packet loss. Return to the list and end the process. If it is 1, it means that the vehicle is in a wake-up state. Then continue to calculate the frame loss situation of the application message of the current CAN digital channel and return the frame loss result dictionary. Determine if the dictionary content of application message frame loss results exists. If it does, calculate the ECU category to which each application message frame loss result belongs and populate the ECU category list (final, kl15, hvar). Here, final is the list of log message frame loss result dictionaries to be returned, kl15 is the list of log message frame loss result dictionaries for the kl15 low-voltage power system type according to the ECU category to which the message sending node belongs, and hvar is the list of log message frame loss result dictionaries for the HVAR high-voltage accessory relay according to the ECU category to which the message sending node belongs. If not, continue calculating the frame loss situation of ICG network management messages and return the frame loss result dictionary; Determine if the dictionary of ICG network management message frame loss results exists. If it does, append the ICG network management message frame loss results to the final list. If not, continue to analyze the power supply status of kl15 and hvar type messages. Iterate through each lost frame message of the KL15 non-network management ECU, determine whether the KL15 lost frame message exists, and if it does, calculate the single-cycle power supply status of the current message frame, return the KL15 message lost frame result dictionary and append it to the final list. Iterate through each lost frame message of the hvar non-network management ECU, check if the hvar lost frame message exists, and if it does, calculate the single-cycle power supply status of the current message frame, return the hvar message lost frame result dictionary and append it to the final list; Update the subtask progress bar status information and the subtask log tracking box log information, and return the final result list to end.

5. The automotive ECU and CAN bus log frame loss analysis system according to claim 4, characterized in that, The specific steps for calculating the current vehicle sleep / wake-up status of the CAN digital channel are as follows: Read the numerical identifiers of the fixed message usr_mod_id and icg_nm_id from the result dictionary read from the configuration file, and perform a validity check to ensure that the message ID is not empty and can successfully convert the input hexadecimal string into an integer. If invalid, construct a dictionary of vehicle sleep / wake-up status results with a status code of -2, indicating that the fixed message ID in the configuration file is set incorrectly; If valid, continue to verify the legality of the current CAN digital channel; if invalid, construct a dictionary of vehicle sleep / wake-up status results with a status code of -1, indicating an unknown CAN digital channel. If valid, then based on the CAN digital channel number and the usr_mod_id value identifier, retrieve the timestamp value list usr_mode_ts_list from the channel-message-timestamp mapping table, and retrieve the timestamp value list icg_nm_ts_list based on the CAN digital channel number and the icg_nm_id value identifier; Check if the contents of usr_mode_ts_list and icg_nm_ts_list exist. If not, construct a dictionary of vehicle hibernation / wake-up status results. The status code is 0, which means there are no messages and the vehicle is in hibernation. If so, calculate vehicle_t0 as the time the first frame was lost, and take the minimum value between the timestamp t1 of the first node in usr_mode_ts_list and the timestamp t2 of the first node in icg_nm_ts_list. Calculate vehicle_t1 as the time the last frame was lost, take the timestamp of the last node in usr_mode_ts_list as t3, take the timestamp of the last node in icg_nm_ts_list as t4, and take the global end time of the entire BLF file blf_time_end; calculate the disappearance time of usr_mod message delta_usr_mod = blf_time_end - t3, and the disappearance time of icg_nm message delta_icg_nm = blf_time_end - t4; if both usr_mod and icg_nm messages exist and disappear simultaneously for ≥2 seconds, then take t3 and t4 as the timestamps.

4. The maximum value of both is vehicle_t1 = max(t3, t4); if neither message exists, then vehicle_t1 = blf_time_end; if the usr_mod message exists but the icg_nm message does not exist, then if delta_usr_mod ≥ 2 seconds, then vehicle_t1 = t3, otherwise vehicle_t1 = blf_time_end; if the icg_nm message exists but the usr_mod message does not exist, then if delta_icg_nm ≥ 2 seconds, then vehicle_t1 = t4, otherwise vehicle_t1 = blf_time_end; Then calculate the dropped frame analysis time period. The valid time period of the application message is [vehicle_t0 + 1, vehicle_t1], and the valid time period of the ICG network management message is [vehicle_t0, vehicle_t1 - 2]; If vehicle_t0 < vehicle_t1, set status_code = 1 to indicate that the whole vehicle is awakened, otherwise set status_code = 0 to indicate that the whole vehicle is in sleep; Construct a dictionary for the sleep and wake-up status of the whole vehicle, with the status code being status_code, and end.

6. The automotive ECU and CAN bus log frame loss analysis system according to claim 5, characterized in that, The specific method for calculating the dropped frames of the application messages on the current CAN digital channel is as follows: Initialize the list of dropped frame result dictionaries loss_list; Loop through all the message lists in the current CAN data channel in the DBC mapping table; Check if the message object in the list exists. If not, return the list loss_list and end; If it exists, continue to check if the message belongs to a network management message. If so, continue to check the next message; If not, continue to check the sending type of the message. If the check result is event type, filter it out and continue to check the next message; if the check result is periodic type, obtain the relevant attribute values of the message, including the identification ID, name, ECU node, and period; According to the CAN data channel number and the message numerical identification, obtain the list of timestamp values msg_ts from the channel-message-timestamp mapping table; Check if the content of the message timestamp value list exists. If not, construct a dropped frame result dictionary and append it to loss_list, and continue to check the next message; If it exists, extract the timestamp values and convert them into a floating-point numpy array, and filter out the timestamp values in_range within the specified time range [vehicle_t0 + 1, vehicle_t1]; Check if in_range is empty. If so, it proves that there are no dropped frames for this message, and continue to check the next message; If not, calculate the adjacent time intervals of the timestamps, and supplement the time interval from the last segment to the cut-off time, and mark the abnormal time intervals abnormal that exceed twice the period; Loop through the abnormal list and check if there are any abnormal intervals. If not, it means that the abnormal list has been traversed, and continue to check the next message; If so, calculate the abnormal start time and abnormal end time for the current abnormal interval node: if it is the first abnormal node, start_time = vehicle_t0 + 1, otherwise start_time = the time of the current abnormal node; if it is the last abnormal node, end_time = vehicle_t1, otherwise end_time = the time of the next adjacent node of the current abnormal node; Construct a dropped frame result dictionary and append it to loss_list, and then process the next abnormal node.

7. The automotive ECU and CAN bus log frame loss analysis system according to claim 6, characterized in that, The calculation of the single-cycle power supply status of the current message frame is as follows: (1) Based on the current CAN digital channel and the frame loss message identifier ID, extract the timestamp and the corresponding ECU power supply status signal value within the frame loss period from the decoded message list, and generate a power supply status sequence. The power supply status signal includes the kl15 low-voltage power supply system status signal and the hvar high-voltage accessory relay status signal. (2) The power supply state sequence is deduplicated, and only the state switching points when the state changes are retained to obtain the state jump sequence; (3) Identify the time t4 when the power supply state changes from off to on and the time t5 when it changes from on to off from the state transition sequence; (4) Determine the frame loss result during the frame loss period based on the ECU power supply status: (a) If the power supply is always on during the frame loss period, then the frame loss period is recorded as [t2, t3]. (b) If there is a switch from power on to power off during the frame loss period and the power is not turned on again afterward, then it is further determined whether the difference between t3 and t4 is greater than the threshold. If so, the frame loss period is recorded as [t4+1,t3]. (c) If there is a power supply state switch from off to on during the frame loss period, then record the frame loss period as [t2, t5]. (5) Add the frame loss results obtained from the determination to the frame loss result list.

8. The automotive ECU and CAN bus log frame loss analysis system according to claim 2, characterized in that, In the security and authorization module, the hardware binding machine code generator performs the following steps: instantiate a hardware information class to obtain the local CPU unique identifier ID, motherboard serial number, physical MAC address, and system disk serial number; concatenate the hardware information to generate raw machine code; encode the raw machine code using UTF-8 format to generate bytecode; and use the SHA256 hash library to irreversibly encrypt the generated bytecode to generate a 64-bit hexadecimal unique machine code. The RSA asymmetric key generator performs the following steps: using the RSA public key to generate a private key with automotive commercial and industrial security levels; using the private key to further generate an associated RSA public key; and converting the generated RSA private and public keys in memory into standard format text strings. Write the converted RSA public and private key strings into local files in binary format for permanent storage; The registration code generation workflow includes: loading an RSA private key encoded in UTF-8; calculating the registration code expiration time; setting a plaintext structured dictionary of registration information, including product ID, unique machine code, and registration code expiration time; encoding the plaintext dictionary of registration information in UTF-8 format and dumping it to generate JSON format bytecode; performing irreversible encryption calculation on the generated bytecode using a SHA256 hash library to generate a 64-bit hash value; performing signature calculation on the hash value using the RSA private key to generate a binary signature for data anti-counterfeiting and anti-tampering; converting the binary signature into Base64 format byte data using Base64 encoding rules; decoding the Base64 byte data into a plain string signature using UTF-8 format; concatenating the plaintext dictionary of registration information and the signature to synthesize the final registration code dictionary; dumping the final registration code dictionary to generate standard JSON format bytecode; encoding the standard JSON bytecode into binary bytes using UTF-8 format; converting the binary bytes into Base64 format byte data using Base64 encoding rules; and decoding the Base64 format bytes using UTF-8 format to convert the Base64 format bytes into a plain text string registration code.

9. The automotive ECU and CAN bus log frame loss analysis system according to claim 2, characterized in that, The basic tool layer includes a unified task processing thread, whose workflow is as follows: The base offset and single task weight of each task are automatically calculated based on the total number of serial tasks. The current total progress of the main progress bar is calculated as follows: Current total progress of the main progress bar = base offset of task + (single task weight × current step / total steps). The specific calculation steps are as follows: Divide the total progress value by the number of subtasks and take the integer part as the base weight, then take the remainder; perform a for loop on the number of tasks, distribute each base weight to the first N tasks according to the remainder, and generate a weight list task_weights for each task. Perform a for loop on the weight list task_weights, calculate the base offset for each task, sum the weights of all previous tasks, and generate a list of task tuples. In actual use, you can calculate the current total progress of the main progress bar by passing in the current step (current_step) and the total number of steps (total_steps). Then check if the unified task processing thread is running. If not, end the process. If it is, process in the following order: execute CAN bus DBC file loading and parsing, and update the progress bar status information and log tracking box log information after completion; execute CAN bus BLF file loading and parsing, and update after completion; execute CAN bus log frame loss analysis engine, and update after completion; execute log analysis report generation module, and update and end the process after completion.

10. The automotive ECU and CAN bus log frame loss analysis system according to any one of claims 1-9, characterized in that, It also includes the following main program workflow: At startup, a single instance check is performed. If an instance is already running, a prompt is displayed and the application is exited. Otherwise, the configuration file is released and the application is initialized. Then, the local registration code file is searched. If it does not exist or the verification fails, the registration window is opened. If the verification passes, the main interface is opened directly.

Images