A CAN bus test experimental system

Abstract

The present invention discloses a CAN bus test experimental system, which relates to the field of data processing technology and comprises: a data acquisition and processing module: used for acquiring data frames from the CAN bus, adding time stamps, and performing tasks such as data parsing, synchronization, filtering, and caching; a control and display module: used for generating and sending control instructions according to vehicle status data, and obtaining and updating vehicle status information; an experimental report generation unit: used for collating experimental data such as bit error rate, timing analysis, and waveform detection into an experimental report; and by integrating multiple test functions and experimental modules, comprehensive support is provided for the teaching and research of the CAN bus.

Description

Technical Field

[0001] The present invention relates to the technical field of data processing, in particular to a CAN bus test experimental system. Background Art

[0002] The CAN (Controller Area Network) bus is an efficient and reliable serial communication bus protocol widely used in automotive electronics, industrial automation, medical equipment, aerospace, and other fields for real-time data transmission and control signal exchange between devices. The main features of the CAN bus include: High reliability: Differential signal transmission and error detection mechanisms ensure stable communication. Strong real-time performance: Supports priority scheduling to ensure the timely transmission of high-priority data frames. Strong scalability: Supports multi-node communication and can connect up to 110 nodes. The CAN bus supports multiple frame types (standard frames, extended frames, and remote frames) and achieves efficient data exchange between multiple nodes through a distributed control architecture. Due to its high reliability and low cost, the CAN bus is particularly widely used in modern vehicles, covering multiple aspects from powertrain control to in-vehicle infotainment systems.

[0003] Although the CAN bus protocol design is mature, in the CAN bus teaching, students need to master technical details such as frame structure, arbitration mechanism and error handling. It is difficult to achieve a comprehensive understanding by relying solely on theoretical explanations. Currently, CAN bus testing and teaching mostly rely on hardware tools and simple software simulation platforms, but these methods have the following shortcomings:

[0004] Lack of intuitive experimental platform:

[0005] It is difficult for students to observe the data frame transmission process on actual equipment, especially key mechanisms such as frame arbitration, scheduling, and error detection.

[0006] Insufficient data analysis capabilities:

[0007] Traditional testing tools make it difficult to conduct in-depth analysis of communication quality. For example, observations of the scheduling effect of frame priorities or error rate trends are not detailed enough.

[0008] Unable to simulate complex scenarios:

[0009] The lack of an experimental environment that supports high-load, multi-node communication scenarios makes it difficult to verify the performance of the system under real conditions.

[0010] Low teaching efficiency:

[0011] Manual operations take up a lot of time, and the process of collating experimental data and generating reports is cumbersome. Summary of the Invention

[0012] To overcome the above technical deficiencies, this application designs a CAN bus test experimental system that integrates multiple test functions and experimental modules to provide comprehensive support for CAN bus teaching and research. The specific solution is as follows:

[0013] In a first aspect of the present application, a CAN bus test experimental system is provided, wherein the method comprises:

[0014] Data acquisition and processing module: used to collect data frames from the CAN bus, add time stamps, and perform tasks such as data parsing, synchronization, filtering, and caching to ensure efficient and accurate data transmission;

[0015] Data forwarding module: used to forward data frames between different channels according to experimental requirements;

[0016] Control and display module: used to generate and send control instructions based on vehicle status data, and obtain and update vehicle status information;

[0017] Experimental report generation unit: used to organize experimental data such as bit error rate, timing analysis, waveform detection, etc. into experimental reports;

[0018] Wherein, the data acquisition and processing module includes:

[0019] Data acquisition unit: used to obtain data frames from the CAN bus in real time and add a timestamp to each data frame;

[0020] Data parsing unit: used to decode the collected raw CAN data frames into understandable vehicle status information;

[0021] Message filtering unit: Filters out required key data as high-priority data frames through preset rules and dynamic adjustments;

[0022] The data acquisition and processing module also includes a baud rate automatic identification unit and a CANopen management unit;

[0023] Among them: Baud rate automatic identification unit: used to collect CAN signals of target devices and determine whether the sampled frame signals are valid;

[0024] The system presets a set of common standard baud rates and tries to set these baud rates one by one and send standard data frames.

[0025] Verify the response data of the target device;

[0026] If a valid data frame is received, it is determined that the baud rate detection is successful.

[0027] If all baud rates are not detected successfully, communication failure is reported;

[0028] After the baud rate detection is successful, the system updates the baud rate configuration and passes the target baud rate to the data acquisition unit and data analysis unit to ensure the synchronization of subsequent data acquisition and analysis;

[0029] The CANopen management unit includes:

[0030] Obtain the response data of the slave node, including node ID, PDO mapping information, SDO read and write response, and node status information;

[0031] The system sends NMT management messages to poll all possible node addresses;

[0032] Detect which nodes have responded and record their IDs as valid nodes;

[0033] The system sets the mapping content of PDO according to the experimental requirements;

[0034] Update the mapping table of the slave station through the SDO write command;

[0035] Parse the heartbeat message of the slave station to monitor whether the node is online or in normal state;

[0036] Send SYNC messages regularly to synchronize data updates of each slave station;

[0037] Wherein, the control and display module includes:

[0038] Control instruction generation unit: generates control instructions based on the real-time status of the vehicle and sends the control instructions to the target node through the CAN bus;

[0039] Status monitoring unit: used to obtain real-time vehicle status data from the data analysis unit, and display and update the vehicle status data;

[0040] Data storage unit: used to store all data during the experiment in real time.

[0041] The analysis and reporting module includes:

[0042] Bit error rate statistics unit: used to detect and count errors in CAN bus communication in real time, calculate the bit error rate, and analyze different types of errors;

[0043] Timing Analysis Unit: Calculates and visualizes the communication delay between nodes, generates timing diagrams, and helps analyze the real-time performance of communications.

[0044] Waveform detection unit: detects anomalies in the CAN bus data waveform, analyzes waveform quality, and helps identify noise and signal interference.

[0045] Experimental report generation unit: Integrate all analysis data, generate detailed experimental reports, and support export for subsequent analysis and sharing.

[0046] Wherein, the bit error rate statistics unit includes:

[0047] Obtain the parsed data frame from the data parsing unit, which includes the frame ID, data field, verification result and timestamp;

[0048] According to the verification result, the error frame in the data frame and the error type of the error frame are obtained, and the bit error rate is calculated. The bit error rate includes the overall bit error rate and various error rates.

[0049] Wherein, the timing analysis unit includes:

[0050] Obtain the timestamp and node ID of the data frame from the data parsing unit and synchronize the timestamp;

[0051] When a data frame is transmitted from node A to node B, the timing analysis unit calculates the transmission delay by comparing the sending timestamp of each data frame at node A with the receiving timestamp at node B;

[0052] Wherein, the waveform detection unit includes:

[0053] Collecting data frames transmitted on the CAN bus, and obtaining the timestamp of the data frame and a waveform signal of level change, wherein the waveform signal of level change is the signal level on the CAN bus;

[0054] Analyze the waveform data collected on the CAN bus, compare and analyze the actual waveform collected with the standard waveform, detect and identify abnormal waveforms, and analyze the noise source in the signal;

[0055] Perform real-time detection on each sampled signal level to confirm whether the high level and low level are within the standard voltage range;

[0056] If the level is found to be outside the standard voltage range, the signal is marked as a level deviation abnormality and detailed information of the level deviation is recorded;

[0057] Obtain the time of the rising and falling edges in the waveform data to confirm whether the time of the change exceeds the predetermined time range; if it exceeds, mark the signal as a signal distortion anomaly and record the detailed information of the rising and falling edge change time;

[0058] Obtaining the pulse width of the signal in the waveform data, and if a change in the pulse width is found, marking the signal as having abnormal waveform distortion, and recording detailed information of the change in the pulse width;

[0059] Obtain the abnormal part of the detection waveform, mark the abnormal area in real time, and generate an analysis report;

[0060] Wherein, the experimental report generating unit includes:

[0061] Integrate the error data generated by the analysis and reporting module and verify the acquired data;

[0062] Time alignment of data obtained from different units to ensure that the timestamp base of all data is consistent;

[0063] Generate a complete experimental report according to the preset report structure.

[0064] One or more technical solutions provided in this application have at least the following technical effects or advantages:

[0065] 1. The system has a built-in baud rate automatic identification function, which can quickly detect the device baud rate and automatically adapt to it, and provide hardware connection status detection function, real-time detection of bus connection and node status, reducing the risk of communication failure, so as to achieve automatic baud rate identification and connection status monitoring;

[0066] 2. The system can simulate the transmission of standard frames, extended frames, and remote frames, and analyze the priority scheduling effects of different frame types. It can also provide dynamic screening and modification functions to flexibly respond to complex experimental requirements and support the transmission and analysis of multiple frame types.

[0067] 3. The system supports bit error rate statistics, timing analysis, and waveform detection to help users identify physical layer signal problems (such as level offset) and logical layer errors (such as data loss). It also simulates data transmission under high load conditions, detects system bottlenecks, and optimizes scheduling strategies, providing error detection and waveform diagnostic capabilities. BRIEF DESCRIPTION OF THE DRAWINGS

[0068] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0069] Figure 1 A schematic diagram of a CAN bus test experimental system flow provided in an embodiment of the present application;

[0070] Explanation of reference numerals: 11. Data acquisition and processing module, 12. Data forwarding module, 13. Control and display module, 14. Analysis and reporting module. DETAILED DESCRIPTION

[0071] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only some of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0072] It should be noted that the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or server that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or modules that are not clearly listed or are inherent to these processes, methods, products or devices.

[0073] Example 1, as Figure 1 As shown, the present application provides a CAN bus test experimental system, the method comprising:

[0074] Data acquisition and processing module 11: used to collect data frames from the CAN bus, add time stamps, and perform tasks such as data parsing, synchronization, filtering, and caching;

[0075] Data forwarding module 12: used to forward data frames between different channels according to experimental requirements;

[0076] Control and display module 13: used to generate and send control instructions based on vehicle status data, and obtain and update vehicle status information;

[0077] Experimental report generation unit 14: used to organize experimental data such as bit error rate, timing analysis, waveform detection, etc. into an experimental report;

[0078] Wherein, the data acquisition and processing module includes:

[0079] Data acquisition unit: used to obtain data frames from the CAN bus in real time and add a timestamp to each data frame;

[0080] Specifically, the system connects to the CAN bus via a CAN logic analyzer or CAN transceiver. As data flows from the CAN bus, the data acquisition unit monitors and receives all passing CAN data frames via the CAN controller. Each data frame includes a frame ID, data field, and control field. The CAN analyzer or transceiver connects the system to the CAN bus via a hardware interface (such as an NI CAN card or Kvaser CAN interface). The hardware device collects data frames from the bus in real time.

[0081] The system adds a timestamp to each received data frame, recording the exact time the data frame arrived at the system. The timestamp can be accurate to the microsecond or nanosecond level, ensuring high-precision timing analysis.

[0082] In addition, the data frame acquisition frequency can be dynamically adjusted according to the system configuration. When the bus load is high, the system automatically adjusts the acquisition frequency to ensure stable data acquisition;

[0083] Each data frame contains the following information:

[0084] Frame ID (such as standard frame, extended frame);

[0085] Data domain (such as vehicle status information such as speed, rotation speed, fuel level, etc.);

[0086] Control field (such as data frame type, remote frame flag, etc.);

[0087] Timestamp (accurate to microseconds or nanoseconds, for subsequent timing analysis);

[0088] The data acquisition unit stores the collected data frames into a buffer and marks them with timestamps, and then passes them to the next processing unit for parsing;

[0089] The buffer is a ring buffer or a double buffer, so that when one buffer is being processed, the other buffer can continue to receive new data.

[0090] In addition, the system can dynamically adjust the frequency of data acquisition based on bus load. When the bus is busy, the acquisition frequency may automatically decrease to avoid data loss or processing bottlenecks; when the bus is lightly loaded, the acquisition frequency may increase to capture more data.

[0091] Data parsing unit: used to decode the collected raw CAN data frames into understandable vehicle status information, such as vehicle speed, rotation speed, fuel level, etc.

[0092] Specifically, the system identifies the type of data frame, including standard frame, extended frame, remote frame, etc., and determines the frame priority and data content. The specific method is as follows:

[0093] The analysis unit obtains the original CAN data frame collected in real time from the data collection unit;

[0094] Each CAN data frame usually contains the following fields:

[0095] Frame ID: used to identify the content and priority of the data frame.

[0096] Control field: Indicates the type of frame (standard frame, extended frame, remote frame, etc.).

[0097] Data field: contains specific data content, with a length of 0 to 8 bytes.

[0098] CRC check field: used to check the integrity of the data frame.

[0099] Frame tail: indicates the end of the frame.

[0100] Determine the type of data frame based on the control field and frame ID:

[0101] Standard frame and extended frame:

[0102] Standard frame: The frame ID is 11 bits and is used to identify common data frames.

[0103] Extended frame: The frame ID is 29 bits and is applicable to more complex data frames.

[0104] Data frame and remote frame:

[0105] Data frame: contains actual data content.

[0106] Remote frame: does not contain data content and is only used to request data;

[0107] Select the appropriate parsing method based on the frame type. For example, for a data frame, parse its data field; for a remote frame, only record the request information without further parsing.

[0108] The system extracts valid binary data from the data field;

[0109] Based on the frame ID and the CAN signal database (DBC file), the meaning of each field in the data domain is determined and the binary data is converted into actual values accordingly. For example: the first two bytes represent vehicle speed. The third byte represents engine speed. The fourth byte represents fuel level.

[0110] During the decoding process, the data parsing unit performs a CRC check to verify the integrity of the data frame and determine if there are any bit errors or frame drops. If the check fails, the system marks the frame as an error frame and records it in the error log for subsequent analysis.

[0111] Frame error marking: If an error frame is detected, such as a format error or bit error, the system will generate an error log for the error frame for subsequent logging and report generation.

[0112] Convert the parsed raw data (such as raw byte values) into actual physical quantities (such as vehicle speed: km / h, speed: rpm, fuel level: %);

[0113] The parsed data undergoes a quality check. If the data meets the preset threshold or verification rules, it is passed to the downstream module. The parsed vehicle status data includes:

[0114] Vehicle speed (km / h);

[0115] Speed (rpm);

[0116] Oil content (%);

[0117] Temperature (℃);

[0118] Other sensor data such as water level and oil temperature;

[0119] Message filtering unit: Through preset rules and dynamic adjustments, it filters out the required key data as high-priority data frames, so that it can filter unnecessary CAN messages according to experimental requirements, reduce the data processing burden, and ensure that high-priority information is processed in a timely manner.

[0120] Specifically;

[0121] The system can preset filtering rules based on the ID, priority or frame type of the data frame to ignore irrelevant data. For example, the system only focuses on messages from a specific node or a specific ID;

[0122] During the experiment, users can dynamically adjust the filtering rules. For example, the system may only focus on real-time data frames or error frames, and discard or delay data frames with long transmission delays.

[0123] During the experiment, users can dynamically adjust the filter conditions as needed. For example, you can set the oil level frame to be displayed first when the oil level is lower than a certain value, while ignoring other frames.

[0124] Data frames are dynamically managed based on their priority and type. Critical data (such as control instructions) is prioritized in the data stream, while low-priority data (such as diagnostic information) can be delayed. Valid data frames, including key information such as vehicle speed and rotational speed, are filtered and passed to downstream control, monitoring, and analysis modules.

[0125] All collected and parsed data will be stored in the database, and the storage method supports fields such as timestamp, frame ID, and data value.

[0126] Data storage formats support CSV, Excel, SQL database, etc. for subsequent analysis and report generation;

[0127] The data acquisition and processing module also includes a baud rate automatic identification unit and a CANopen management unit;

[0128] Among them: the baud rate automatic identification unit includes:

[0129] Collect the CAN signal of the target device and determine whether the sampled frame signal is valid; it can capture the original signal on the bus through the hardware interface (such as CAN transceiver). When in use, the system tries different baud rate configurations to send or receive data and detect whether the communication is successful;

[0130] The system presets a set of common standard baud rates (such as 125kbps, 250kbps, 500kbps, 1000kbps, etc.), and tries to set these baud rates one by one and send standard data frames (such as remote frames).

[0131] Verify the response data of the target device (such as CRC check and frame ID matching);

[0132] If a valid data frame is received, it is determined that the baud rate detection is successful.

[0133] If all baud rates are not detected successfully, a communication failure is reported, that is, a baud rate mismatch or device no response is reported, and the user is prompted to check the hardware connection, target device status, or manually set the baud rate;

[0134] After the baud rate detection is successful, the system updates the baud rate configuration and passes the target baud rate to the data acquisition unit and data analysis unit to ensure the synchronization of subsequent data acquisition and analysis;

[0135] The CANopen management unit includes:

[0136] Obtain the response data of the slave node, including node ID, PDO mapping information, SDO read and write response, and node status information (such as NMT status and heartbeat message);

[0137] The system sends NMT management messages to poll all possible node addresses (e.g., 1 to 127);

[0138] Detect which nodes have responded and record their IDs as valid nodes;

[0139] The system sets the mapping content of PDO according to the experimental requirements;

[0140] Update the mapping table of the slave station through the SDO write command;

[0141] Parse the heartbeat message of the slave station to monitor whether the node is online or in normal state;

[0142] Send SYNC messages regularly to synchronize data updates of each slave station;

[0143] Based on this unit, it can obtain: the list of slave nodes and their status information; the read and write results of PDO and SDO; the real-time status of the node (such as whether it is online or error), and obtain: the valid node list: passed to the status monitoring unit to display the valid slaves in the system; abnormal node status: trigger an alarm or suggest reconfiguration, so as to ensure the smooth progress of the experiment.

[0144] The control and display module includes:

[0145] Control command generation unit: Generates control commands based on the real-time status of the vehicle and sends them to target nodes via the CAN bus, such as control nodes, vehicle models, lights, brakes, etc. These commands can be automatic or manual, depending on the needs of the experiment.

[0146] The specific operations are as follows:

[0147] The control instruction generation unit obtains real-time vehicle status data (such as vehicle speed, fuel level, rotation speed, etc.) from the data analysis unit or the status monitoring unit to determine the timing of generating the control instruction;

[0148] When the user manually controls the vehicle through the interface, the control instruction generation unit also receives input instructions from the user (such as acceleration, braking, light switch, etc.);

[0149] Due to experimental needs, the control instruction generation mode is as follows:

[0150] Automatic control mode: The system automatically generates control commands based on pre-set logic and rules. For example, if the fuel level falls below a certain threshold, the system automatically generates a low fuel level alarm command and sends it to the CAN bus.

[0151] Manual control mode: The user manually inputs instructions through the control interface (such as pressing the "brake" button), and the system generates corresponding control instructions in real time and sends them to the target node.

[0152] Complex control instructions: If the experimental scenario is complex, you may need to generate multiple control instructions, such as controlling acceleration, braking, and lighting simultaneously. The system will generate complex instructions based on the conditions.

[0153] The control command generation unit executes the control decision logic each time it receives vehicle status data or user input. For example, during an acceleration test, the control unit generates an appropriate acceleration command based on the difference between the current vehicle speed and the target speed.

[0154] Conditional judgment: Based on the current vehicle status, the system will determine whether a certain control command needs to be generated. For example, when the vehicle is driving at a low speed, the system may generate a "turn on the headlights" command; when the fuel level is too low, the system may generate an "alarm" or "remind to refuel" command.

[0155] After the control instruction is generated, the system will encapsulate the instruction data into a data frame that complies with the CAN protocol (for example, using specific ID and data fields to represent different types of instructions).

[0156] Frame ID and data field: The frame ID of the command data frame represents the target node, and the data field contains the specific content of the control command (such as throttle, brake force, light switch, etc.).

[0157] CAN bus transmission: The generated data frame is sent to the target node via the CAN bus. This process is achieved through a CAN interface card or a CAN transceiver.

[0158] Status Monitoring Unit: This unit is used to obtain real-time vehicle status data (such as speed, fuel level, temperature, etc.) from the data analysis unit and display and update the vehicle status data. This unit not only provides real-time feedback, but also allows users to manually adjust vehicle status and control.

[0159] The specific operations are as follows:

[0160] The status monitoring unit obtains real-time vehicle status data (such as vehicle speed, fuel level, temperature, etc.) from the data analysis unit. This data is usually obtained and decoded from the CAN bus by the data acquisition module and then transmitted to this module;

[0161] When the control command is executed, the system will feedback the execution status of the command (for example, whether the acceleration command is effective, whether the braking is successful). The status monitoring unit will pass the feedback information to the user;

[0162] The vehicle status can be displayed through a graphical interface, usually including a virtual instrument panel, charts or digital indicators. For example, the vehicle speed is displayed as a rotating needle on the virtual instrument panel, and the fuel level is displayed through a progress bar.

[0163] The status monitoring unit will refresh the display content in real time to ensure that the user can see the latest vehicle status data;

[0164] If the system detects an abnormality (such as low oil level, high temperature), the status monitoring unit can alert the user with different colors or prompts (such as flashing red lights, alarm sounds, etc.);

[0165] Users can perform manual operations through the interface, such as accelerating, braking, turning on and off lights, etc. The state monitoring unit will generate control instructions based on user input and pass them to the target node through the control instruction generation unit;

[0166] When the user operates (such as braking, accelerating), the state monitoring unit will immediately feedback the vehicle state changes based on the operation;

[0167] During the experiment, the status monitoring unit can display the vehicle status (speed, fuel level, rotation speed, etc.) and the control command execution results (such as "brake successful", "acceleration completed"). When the status changes, the graphical interface will be dynamically updated to ensure that users can view the experiment progress in real time.

[0168] Data storage unit: used to store and integrate all data during the experiment in real time, including vehicle status data, control instructions, error logs, etc. Through data storage, experimental data can be used for subsequent analysis, backtracking and report generation;

[0169] The data forwarding module includes:

[0170] Data receiving unit: used to receive original CAN data frames from the system's data acquisition unit. The original CAN data frames include frame ID, data field, timestamp, etc.

[0171] Forwarding rules management unit:

[0172] Used to store user-defined forwarding rules, which support dynamic addition, modification, and deletion; and can customize forwarding conditions (such as frame ID range, data field content) and modification logic;

[0173] The forwarding rules are rules entered by the user through an interactive interface or a configuration file;

[0174] Pass the current effective forwarding rule set to the data filtering unit;

[0175] Data screening unit: used to match data frames according to forwarding rules and filter out frames that do not need to be forwarded. Its specific operations are as follows;

[0176] By comparing the frame ID, data field, timestamp and other fields, it is determined whether the forwarding conditions are met;

[0177] Pass the frames that meet the conditions to the frame modification unit;

[0178] Record frames that do not meet the conditions into the log unit;

[0179] The frame modification unit is used to modify the frame ID or data field according to the rules. The specific operations are as follows:

[0180] Obtaining frames that meet the conditions passed by the data filtering unit and the modification logic defined in the forwarding rules;

[0181] Modify the frame ID and a field value of the data domain that meet the conditions and are transmitted by the data screening unit according to the modification logic defined in the forwarding rule;

[0182] Pass the modified frame to the forwarding execution unit;

[0183] Forwarding execution unit: used to send data frames that meet the rules and complete the modification to the target channel.

[0184] Forwarding log unit: used to record detailed information during the forwarding process, including frames that do not match the rules, frames before and after modification, frames that failed to be sent, etc.

[0185] Wherein, the analysis and reporting module includes:

[0186] Bit error rate statistics unit: used to detect and count errors in CAN bus communication in real time, calculate the bit error rate, and analyze different types of errors, such as data bit errors, frame format errors, CRC errors, etc.

[0187] Timing Analysis Unit: The system calculates and visualizes the communication delay between nodes through high-precision timestamps (especially in systems that support PTP), generates a timing diagram, and helps analyze the real-time performance of communications. The timing diagram is updated in real time with the arrival of each data frame to ensure the accuracy of node delay information.

[0188] Waveform detection unit: The system accurately samples the level changes of each data frame and uses algorithms to identify and detect anomalies in the CAN bus data waveform. By comparing it with the standard waveform, it analyzes the waveform quality, enabling it to effectively identify problems in the communication process, such as signal noise and voltage fluctuations, and help identify noise and signal interference;

[0189] Experimental report generation unit: used to format and integrate the data generated by each unit during the experiment (such as timing diagrams, bit error rates, waveform diagrams, etc.), and generate a complete experimental report that supports export, which is convenient for subsequent analysis and sharing;

[0190] The bit error rate statistics unit includes:

[0191] Obtain the parsed data frame from the data parsing unit, which includes the frame ID, data field, checksum result, and timestamp. Each data frame will undergo CRC check and format check. Any error found will be marked as an error frame with the error type (for example: CRC error, format error, etc.);

[0192] The error types and detection methods are as follows:

[0193] CRC error: By comparing the cyclic redundancy check (CRC) of the data frame content, it is detected whether the data has been tampered with or lost during transmission.

[0194] Bit error: refers to the error in the bits in the data frame, which may be caused by factors such as signal interference and electrical noise.

[0195] Format error: The format of the data frame does not match the CAN protocol. For example, the length and field order of the frame are incorrect.

[0196] Timeout error: The sending or receiving of a data frame exceeds the specified time window.

[0197] The bit error rate statistics unit records detailed information of all error frames, including frame ID, timestamp, error type, and data value, and stores them in the error log;

[0198] Whenever the system detects an error frame, the bit error rate statistics unit increases the error frame counter. Error frame counts include CRC errors, bit errors, format errors, and timeout errors.

[0199] Every time a data frame is collected and passes verification, the system increases the total frame count. Even if the frame has no errors, it will be counted in the total frame count.

[0200] The bit error rate is calculated by the total number of frames and the number of error frames. The bit error rate includes the total bit error rate and the bit error rate of each error type. The bit error rate is calculated by dividing the total number of frames by the number of error frames and multiplying by 100%. The bit error rate of each error type is calculated by dividing the total number of frames by the number of error frames of that type and multiplying by 100. Taking bit error statistics as an example, whenever an error occurs in a bit in a data frame, the bit error rate statistics unit will record the bit error and count the frequency of bit errors to help locate possible electrical noise or interference problems during the communication process.

[0201] After each error frame or data frame is collected, the bit error rate statistics unit calculates and updates the bit error rate in real time. The updated bit error rate will be used for subsequent data display and alarm judgment, so that the system will regularly refresh the bit error rate calculation results to ensure that users see the latest communication quality data;

[0202] Among them; the bit error rate can be displayed in real time in the form of a line graph or a bar graph;

[0203] Line chart: used to reflect the changes in bit error rate in different time periods or experimental stages;

[0204] Histogram: used to show the proportion of each error type (CRC error, bit error, format error, timeout error) in the total errors;

[0205] In addition, the system will issue real-time alarms based on the preset bit error rate threshold (for example, 5%). If the bit error rate exceeds the set threshold, the bit error rate statistics unit will trigger a warning to remind users that there is a problem with communication quality;

[0206] Wherein, the timing analysis unit includes:

[0207] The data frame timestamp and node ID are obtained from the data parsing unit, and the PTP protocol is used to synchronize the timestamp. By synchronizing the timestamps through the PTP protocol, the clocks of all nodes will be synchronized to the nanosecond level. This means that the timestamp of each data frame will remain highly consistent across all nodes, thus ensuring the accuracy of delay calculation.

[0208] If the system is equipped with a hardware-level timestamp function, each data frame can also be time-stamped at the hardware level to avoid delay errors caused by operating system scheduling;

[0209] When a data frame is transmitted from node A to node B, the timing analysis unit calculates the transmission delay by comparing the sending timestamp of each data frame at node A with the receiving timestamp at node B;

[0210] In the case of multiple nodes, the timing analysis unit will calculate the delay between all nodes and obtain the communication delay data between each node;

[0211] The specific method is as follows:

[0212] Whenever a data frame arrives, the timing analysis unit extracts the timestamp in the data frame. These timestamps are usually generated by the data acquisition unit or hardware clock and indicate the time when the data frame was sent by node A and received by node B.

[0213] By comparing the sending timestamp and receiving timestamp of each data frame, the system calculates the transmission delay of the data from node A to node B, where the delay is the receiving timestamp minus the sending timestamp;

[0214] The calculation method of each delay is as follows:

[0215] One-way delay: Calculates the one-way delay from one node to another, that is, the delay from the sending node to the receiving node.

[0216] Two-way latency: For some experiments, the system may need to calculate the two-way latency from the sending node to the receiving node and back to the sending node. The system analyzes the two-way communication latency by measuring the complete cycle from node A to node B and then from node B back to node A.

[0217] Multi-frame latency: If the data transmission process involves multiple data frames (for example, the transmission of a large data block in fragments), the timing analysis unit will calculate the latency of each data frame separately and combine them into the complete transmission latency.

[0218] The system takes into account the order of data frames and ensures that the latency calculation correctly reflects the transmission process of all frames.

[0219] The timing analysis unit calculates the average, maximum, and minimum delays between each node. These statistics help analyze bottlenecks in communication, such as whether the delay of certain nodes is too high.

[0220] As network load and the number of data frames increase, the Timing Analysis Unit records and displays latency trends. For example, as the number of nodes increases or the amount of communication increases, latency may gradually increase, and the Timing Analysis Unit helps track these changes.

[0221] Real-time detection of latency peaks and generation of latency-exceeding alerts to alert users of possible network bottlenecks.

[0222] The timing analysis unit generates a timing diagram based on the calculated delay data, helping users intuitively understand the communication delay between different nodes. A timing diagram is typically a chart with time on the horizontal axis and nodes or data frames on the vertical axis. The communication delay of each node is represented by a line, and the communication between nodes is connected by arrows.

[0223] The timing diagram can show the sending and receiving time of each data frame. The communication delay between nodes is marked on the diagram to show its size, trend and fluctuation.

[0224] The timing diagram is updated dynamically. Every time a new data frame is collected, the diagram is redrawn to show the new delay data.

[0225] The system will continuously compare the newly collected data with the previous data and automatically adjust the node positions in the timing diagram to ensure the real-time update of the delay information;

[0226] Based on real-time latency data, the timing analysis unit can automatically identify latency bottlenecks and generate optimization suggestions. For example, the system can recommend adjusting the data acquisition frequency, increasing the baud rate, or adjusting the data frame size to reduce latency.

[0227] Dynamic adjustment: The system dynamically adjusts data collection parameters or transmission frequency based on network load and latency analysis results to ensure low latency even under high load;

[0228] When communicating between multiple nodes, the timing analysis unit can automatically select a better transmission path based on the delay data to minimize the delay of data transmission.

[0229] The system can calculate the shortest path based on the network topology and adjust the routing of data frames to achieve optimal latency optimization.

[0230] Among them, the timing diagram generated by the timing analysis unit can be exported to image format (such as PNG, JPEG) or vector format (such as SVG) for user viewing and analysis.

[0231] Users can select data for a specific time period and generate a time series diagram for that period.

[0232] The system will generate a delay statistics report, showing data such as the maximum delay, minimum delay, and average delay between nodes.

[0233] Delay reports can be exported in PDF or Excel format for easy analysis and archiving.

[0234] When the delay of a node exceeds the set threshold, the system will trigger a delay alarm to remind the user to optimize.

[0235] Wherein, the waveform detection unit includes:

[0236] Collecting data frames transmitted on the CAN bus, and obtaining the timestamp of the data frame and a waveform signal of level change, wherein the waveform signal of level change is the signal level on the CAN bus;

[0237] Specifically: In the CAN protocol, the standard waveform should be a rectangular wave with a fixed rising edge, falling edge, and stable level. The standard waveform is specified by the CAN physical layer protocol. The waveform characteristics (such as rise time, fall time, signal width, etc.) are theoretically fixed, and the CAN bus voltage standard is usually 0V to 3.3V (or 0V to 5V, depending on the CAN interface used). The signal level should vary within this standard range, so the waveform detection unit compares and analyzes the actual waveform collected with the standard waveform. The level, time characteristics, etc. of the standard waveform and the actual waveform should be highly consistent;

[0238] By analyzing waveform data collected on the CAN bus and comparing the actual waveform with a standard waveform, the inventors detected and identified abnormal waveforms and analyzed the noise sources in the signal. They also analyzed that external or internal electromagnetic interference (EMI) can cause noise in the signal waveform. For example, near electrical equipment, the CAN bus signal may be affected by external noise, causing signal distortion.

[0239] Therefore, the waveform detection unit can be used to compare the signal's standard waveform to analyze the noise source in the signal. For example, if the rising edge of the signal is no longer smooth but becomes irregular, it may indicate that the signal is affected by high-frequency noise.

[0240] Perform real-time detection on each sampled signal level to confirm whether the high level and low level are within the standard voltage range;

[0241] Specifically, level offset refers to the high or low level of the CAN signal exceeding the specified voltage range. Level offset can lead to data parsing errors or reduced signal reliability.

[0242] The waveform detection unit will perform real-time detection on each sampled signal level to ensure that the high and low levels are within the standard voltage range.

[0243] If the level is found to be outside the standard range (e.g., the high level is greater than 3.3V or less than 0V), the signal is marked as abnormal level deviation and detailed information about the level deviation is recorded;

[0244] Obtain the time of the rising and falling edges in the waveform data to confirm whether the time of the change exceeds the predetermined time range; if it exceeds, mark the signal as a signal distortion anomaly and record the detailed information of the rising and falling edge change time;

[0245] Specifically, signal distortion refers to changes in the waveform's shape. Common distortions include: Long rise / fall times: Standard waveforms require rising and falling edges to occur within a certain timeframe. If the signal changes too slowly, the waveform may be distorted, possibly due to power supply noise or poor wiring.

[0246] Signal width variation: The pulse width of the signal should remain stable. If the pulse width changes, it means that the signal is distorted.

[0247] Obtaining the pulse width of the signal in the waveform data, and if a change in the pulse width is found, marking the signal as having abnormal waveform distortion, and recording detailed information of the change in the pulse width;

[0248] Obtain the abnormal part of the detection waveform, mark the abnormal area in real time, and generate an analysis report;

[0249] Specifically, common anomalies include:

[0250] The level is too high or too low (level offset).

[0251] Rise / fall times are too long (signal distortion).

[0252] Signal period or pulse width changes (waveform distortion).

[0253] Frequent noise disturbances.

[0254] Abnormal waveforms are usually highlighted with different colors or marks (such as red marks) to help users quickly identify them.

[0255] In addition, the waveform detection unit generates a waveform graph in real time to show how the collected signal level changes over time. The waveform graph will show the comparison between the actual waveform and the standard waveform, helping users to intuitively understand the signal quality;

[0256] The waveform will be updated in real time to show the level change process of each data frame;

[0257] The experimental report generation unit includes:

[0258] Integrate the error data generated by the analysis and reporting module and verify the acquired data; that is, integrate the data generated by the bit error rate statistics, timing analysis, waveform detection and other units;

[0259] The details are as follows:

[0260] The experimental report generation unit mainly obtains data from the following units:

[0261] Bit error rate statistics unit: overall bit error rate;

[0262] The number and distribution of various error types (e.g., CRC errors, format errors, bit errors, etc.);

[0263] A bar chart or pie chart showing the percentage of error types;

[0264] Timing Analysis Unit:

[0265] Statistics of inter-node communication delays (such as maximum delay, minimum delay, and average delay);

[0266] Line chart showing node latency change trends;

[0267] Multi-node timing diagram;

[0268] Waveform detection unit:

[0269] Comparison data between the actual waveform collected and the standard waveform;

[0270] Description of waveform anomalies (such as noise interference, level offset, signal distortion);

[0271] Waveform comparison chart, marking abnormal areas;

[0272] Other data:

[0273] Experiment configuration information (such as CAN baud rate, number of nodes);

[0274] Time information (experiment start time, end time);

[0275] The experimental report generation unit verifies the acquired data to ensure its integrity and consistency. For example, it checks whether the data from each analysis unit covers the entire time period. For duplicate or invalid data (such as data missing due to frame loss or timeout), the system will compensate or mark the data.

[0276] The system time-aligns the data obtained from different units to ensure that the timestamp reference of all data is consistent. For example, the timestamp of timing analysis and the time period of waveform detection need to be synchronized.

[0277] Generate a complete experimental report according to the preset report structure;

[0278] The following is the method of using this system; the following is the specific operation method for each experimental project using this system to carry out experiments, covering the operation steps and key results

[0279] 1. CAN bus hardware recognition experiment

[0280] Experimental Objectives

[0281] Familiar with CAN bus hardware architecture, including transceivers, main controllers, and node device connection methods.

[0282] Observe whether the CAN bus communication works normally after the hardware is connected.

[0283] Steps

[0284] Hardware connection: Use a CAN transceiver (such as a USB-CAN module) to connect the PC and the experimental platform. Correctly connect multiple CAN nodes (such as sensors and actuators) of the experimental platform to the bus through terminal resistors, and ensure that all nodes are powered on and operating normally.

[0285] System initialization: Start the baud rate automatic identification unit in the system to detect the baud rate of the current CAN bus. Based on the detection results, update the baud rate setting and synchronize it to the data acquisition unit.

[0286] Hardware testing: Use the status monitoring unit to observe the real-time status of the CAN bus, including the number of frames received and the distribution of frame types. Use the waveform detection unit to monitor the physical signal quality of the CAN bus to ensure that the signal level meets the standard.

[0287] Experimental records: Store the real-time collected hardware connection status and waveform data into the data storage unit for subsequent analysis.

[0288] This experiment can verify whether the hardware connection is correct and whether the CAN bus is working properly. It can also confirm whether the physical layer characteristics of the hardware signal comply with the CAN specification through waveform detection.

[0289] 2. CAN bus transmission protocol experiment (information transmission of different communication message frames)

[0290] Experimental objectives: Understand the CAN bus protocol, verify the transmission characteristics of standard frames, extended frames, and remote frames, and analyze the priorities of different frame types and their impact on communication efficiency.

[0291] Steps:

[0292] Frame type test: Use the experimental platform to generate various types of CAN messages (such as standard frames, extended frames, and remote frames).

[0293] The data acquisition unit captures the messages transmitted on the bus, and the frame ID and data field are decoded in the data parsing unit.

[0294] Priority Verification:

[0295] Use the message filtering unit to set frame ID filtering rules to give priority to receiving frames within a specific frame ID range.

[0296] Send messages of different priorities on the bus and observe the order in which they are received and processed by the system.

[0297] Experimental record: Use the bit error rate statistics unit to monitor error frames and retransmissions under high load conditions.

[0298] Use the experiment report generation unit to generate transmission efficiency reports for different frame types.

[0299] This experiment can be used to compare the transmission characteristics and priority impact of different frame types, and to analyze the communication performance bottlenecks under heavy load conditions through reports.

[0300] 3.CAN bus node communication experiment

[0301] Experimental objectives: Observe the data interaction between the master and slave nodes of the CAN bus and verify the real-time and reliability of communication in a multi-node environment.

[0302] Steps

[0303] Node scanning: Use the CANopen management unit to send NMT messages to scan slave nodes and record valid node IDs.

[0304] Configure PDO / SDO for slave nodes to ensure that each node can communicate normally.

[0305] Communication test: Send test data frames to the slave node and record the response time.

[0306] The communication delay between nodes is calculated by the timing analysis unit to generate a timing diagram.

[0307] Status monitoring: Use the status monitoring unit to observe the status of slave nodes in real time (such as online status and response time).

[0308] Mark and record abnormal node behaviors (such as frame loss and timeout).

[0309] Through this experiment, we can obtain the node scanning results to verify whether the node configuration is correct and the timing analysis results to evaluate the real-time and stability of communication between nodes.

[0310] 4. Control and data acquisition experiment based on CAN bus

[0311] Experimental objectives: Use the CAN bus to realize control command transmission and data acquisition between devices and verify the control accuracy and data acquisition rate of the system.

[0312] Steps

[0313] Control command testing: Use the experimental platform to send control commands to the actuator nodes (such as turning on / off devices and adjusting parameters).

[0314] Use the data forwarding module to forward control commands between different channels and verify the execution of cross-channel instructions.

[0315] Data acquisition verification: Use the data acquisition unit to obtain sensor data (such as temperature and pressure) in real time.

[0316] The data field is decoded in the data parsing unit, and the physical quantity is extracted and displayed in the status monitoring unit.

[0317] Result storage and analysis: The collected data is stored in the data storage unit, and the acquisition rate and control delay report is generated through the experiment report generation unit.

[0318] This experiment can evaluate the response performance of the equipment through the execution of control instructions, and obtain data acquisition rate and stability analysis to verify the real-time performance and reliability of the system.

[0319] 5. Data and waveform detection comparative analysis experiment

[0320] Experimental objectives: Analyze the relationship between physical signals and logical data through waveform detection, and verify the impact of signal interference on data transmission.

[0321] Steps

[0322] Synchronous capture of data and waveforms: Use the data acquisition unit to collect data frames.

[0323] At the same time, the waveform detection unit is used to capture the physical layer signal waveform and align the timestamps.

[0324] Waveform and data comparison: Compare the rising edge, falling edge, and stability of the waveform signal with the data frame content.

[0325] Identify the effects of noise or interference in the waveform on the data frame.

[0326] Interference analysis: artificially introduce noise into the experiment (such as increasing electromagnetic interference) and observe the changes in the waveform and the error rate of the data frame.

[0327] The bit error rate statistics unit is used to record the number of error frames under noise conditions.

[0328] Report Generation: Use the experimental report generation unit to generate waveform and data comparison analysis reports, including signal quality and data integrity assessment.

[0329] This experiment evaluates the impact of signal quality on data transmission reliability by comparing waveforms and data.

[0330] Analyze the bit error rate changes under noisy conditions to verify the system's anti-interference performance.

[0331] It should be noted that the order in which the embodiments of the present application are presented is for illustrative purposes only and does not necessarily represent the superiority or inferiority of the embodiments. Furthermore, the foregoing descriptions of specific embodiments of this specification are provided. The processes depicted in the accompanying drawings do not necessarily require the specific order or sequential sequence shown to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0332] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

[0333] This specification and drawings are merely illustrative of the present application and are intended to cover any and all modifications, variations, combinations, or equivalents within the scope of this application. Obviously, those skilled in the art may make various modifications and variations to this application without departing from the scope of this application. Thus, this application is intended to include such modifications and variations as fall within the scope of this application and its equivalents.

Claims

1. A CAN bus test experimental system, characterized in that: The system comprises: Data acquisition and processing module: used to collect data frames from the CAN bus, add time stamps, and perform data parsing, synchronization, filtering, and caching tasks; Data forwarding module: used to forward data frames between different channels according to experimental requirements; Control and display module: used to generate and send control instructions based on vehicle status data, and obtain and update vehicle status information; Analysis and reporting module: used to organize bit error rate, timing analysis, and waveform detection experimental data into experimental reports; Wherein: the data acquisition and processing module includes: Data acquisition unit: used to obtain data frames from the CAN bus in real time and add a timestamp to each data frame; Data parsing unit: used to decode the collected raw CAN data frames into understandable vehicle status information; Message filtering unit: Filters out required key data as high-priority data frames through preset rules and dynamic adjustments; Baud rate automatic identification unit: used to collect CAN signals from the target device and determine whether the sampled frame signal is valid; The system presets a set of common standard baud rates and tries to set these baud rates one by one and send standard data frames; Verify the response data of the target device; If a valid data frame is received, the baud rate detection is determined to be successful; If all baud rates are not detected successfully, communication failure is reported; After the baud rate detection is successful, the system updates the baud rate configuration and passes the target baud rate to the data acquisition unit and data analysis unit to ensure the synchronization of subsequent data acquisition and analysis; CANopen Management Unit: Obtain the response data of the slave node, including node ID, PDO mapping information, SDO read and write response, and node status information; The system sends NMT management messages to poll all possible node addresses; Detect which nodes have responded and record their IDs as valid nodes; The system sets the mapping content of PDO according to the experimental requirements; Update the mapping table of the slave station through the SDO write command; Parse the heartbeat message of the slave station to monitor whether the node is online or in normal state; Send SYNC messages regularly to synchronize data updates of each slave station.

2. A CAN bus test experimental system according to claim 1, characterized in that: The data forwarding module includes: Data receiving unit: used to receive original CAN data frames from the system's data acquisition unit; Forwarding rules management unit: Used to store user-defined forwarding rules and modification logic; Pass the current effective forwarding rule set to the data filtering unit; Data screening unit: used to match data frames according to forwarding rules, filter out frames that do not need to be forwarded, and pass frames that meet the conditions to the frame modification unit; Frame modification unit: The frame modification unit is used to modify the frame ID or data field according to the rules and pass the modified frame to the forwarding execution unit; Forwarding execution unit: used to send data frames that meet the rules and complete the modification to the target channel.

3. A CAN bus test experimental system as claimed in claim 1, characterized in that: The control and display module includes: Control instruction generation unit: generates control instructions based on the real-time status of the vehicle and sends the control instructions to the target node through the CAN bus; Status monitoring unit: used to obtain real-time vehicle status data from the data analysis unit, and display and update the vehicle status data; Data storage unit: used to store all data during the experiment in real time.

4. A CAN bus test experimental system as claimed in claim 1, characterized in that: The analysis and reporting module includes: Bit error rate statistics unit: used to detect and count errors in CAN bus communication in real time, calculate the bit error rate, and analyze different types of errors; Timing Analysis Unit: Calculates and visualizes the communication delay between nodes, generates timing diagrams, and helps analyze the real-time performance of communications; Waveform detection unit: detects anomalies in the CAN bus data waveform, analyzes waveform quality, and helps identify noise and signal interference; Experimental report generation unit: Integrate all analysis data, generate detailed experimental reports, and support export for subsequent analysis and sharing.

5. A CAN bus test experimental system as claimed in claim 4, characterized in that: The bit error rate statistics unit includes: Obtain the parsed data frame from the data parsing unit, which includes the frame ID, data field, verification result and timestamp; According to the verification result, the error frame in the data frame and the error type of the error frame are obtained, and the bit error rate is calculated. The bit error rate includes the overall bit error rate and various error rates.

6. A CAN bus test experimental system as claimed in claim 4, characterized in that: The timing analysis unit includes: Obtain the timestamp and node ID of the data frame from the data parsing unit and synchronize the timestamp; When a data frame is transmitted from node A to node B, the timing analysis unit calculates the transmission delay by comparing the sending timestamp of each data frame at node A with the receiving timestamp at node B.

7. A CAN bus test experimental system as claimed in claim 4, characterized in that: The waveform detection unit includes: Collecting data frames transmitted on the CAN bus, and obtaining the timestamp of the data frame and a waveform signal of level change, wherein the waveform signal of level change is the signal level on the CAN bus; Analyze the waveform data collected on the CAN bus, compare and analyze the actual waveform collected with the standard waveform, detect and identify abnormal waveforms, and analyze the noise source in the signal; Perform real-time detection on each sampled signal level to confirm whether the high level and low level are within the standard voltage range; If the level is found to be outside the standard voltage range, the signal is marked as a level deviation abnormality and detailed information of the level deviation is recorded; Obtain the time of the rising and falling edges in the waveform data to confirm whether the time of the change exceeds the predetermined time range; if it exceeds, mark the signal as a signal distortion anomaly and record the detailed information of the rising and falling edge change time; Obtaining the pulse width of the signal in the waveform data, and if a change in the pulse width is found, marking the signal as having abnormal waveform distortion, and recording detailed information of the change in the pulse width; Obtain the abnormal part in the detection waveform, mark the abnormal area in real time, and generate an analysis report.

8. A CAN bus test experimental system as claimed in claim 4, characterized in that: The experimental report generating unit includes: Integrate the error data generated by the analysis and reporting module and verify the acquired data; Time alignment of data obtained from different units to ensure that the timestamp base of all data is consistent; Generate a complete experimental report according to the preset report structure.

Images