A method, system and product for testing the bus-off feature of a CAN bus based on a single-chip microcomputer
A lightweight CAN bus busoff characteristic testing system was built using a microcontroller. By injecting error signals into the first CAN bus and listening to messages on the second CAN bus, the system solves the problems of high cost and complexity of existing equipment and achieves efficient and flexible busoff characteristic testing of ECUs.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHANGHAI TURING ELECTRONIC & SCI TECH CO LTD
- Filing Date
- 2026-03-13
- Publication Date
- 2026-06-12
AI Technical Summary
Existing CAN bus node busoff characteristic testing equipment is expensive, complex to configure, and unsuitable for small and medium-sized enterprises, making it difficult to perform efficient diagnostics on individual ECUs.
A microcontroller-based CAN bus bus off characteristic testing method is adopted. The test control MCU is connected to the ECU under test. Error signals are injected through the first CAN bus and messages are listened to through the second CAN bus to build a lightweight test environment and realize flexible bus off characteristic testing.
It enables efficient, flexible, and low-cost Busoff characteristic testing for specific ECUs, obtains clear Busoff status data, and supports robustness analysis of ECUs.
Smart Images
Figure CN122195745A_ABST
Abstract
Description
Technical Field
[0001] This application relates to a microcontroller-based CAN bus busoff characteristic testing method, system, and product for the field of vehicle-mounted equipment testing. Background Technology
[0002] For each onboard ECU node connected to the CAN bus, bus off is a crucial error management mechanism. It disconnects the ECU from the CAN bus once its error counter reaches a threshold, stopping data transmission and reception and preventing the continuous sending of error frames that could paralyze the entire CAN network. Therefore, testing the bus off characteristics of the ECU is an important test for the robustness and reliability of the CAN network system.
[0003] Currently, testing the busoff characteristics of CAN bus nodes relies on specialized hardware-in-the-loop (HIL) testing equipment such as the Vector VNH6501 and CANoe VT system. The testing strategy involves connecting the real controller with a simulated controlled object to build a virtual closed-loop test environment. When performing tests, the aforementioned testing system uses the entire vehicle's CAN bus environment as the testing dimension and can simulate error signals to test the busoff characteristics of ECU devices.
[0004] However, the aforementioned testing equipment also has significant drawbacks.
[0005] 1. A complete HIL system is expensive, which greatly increases the research and development cost and is not suitable for small and medium-sized enterprises, educational institutions or small-batch testing and verification applications.
[0006] 2. The HIL system has a complex configuration, and the construction and changes of test scenarios often depend on specific software environments and hardware configurations, lacking flexibility.
[0007] 3. The HIL system is mainly aimed at the integration testing of vehicle-level or large component suppliers. For the verification of the underlying BusOff diagnostic algorithm of a single ECU, the test scale is too large, the amount of information obtained is huge, the analysis is difficult and time-consuming, and it is difficult to focus on a specific ECU. Summary of the Invention
[0008] The purpose of this application is to overcome the shortcomings of the prior art and provide a CAN bus bus off characteristic testing method, system and product based on a microcontroller, which can perform lightweight bus off characteristic testing on a specific ECU under test with high testing efficiency.
[0009] Firstly, this application provides a CAN bus bus off characteristic testing method based on a microcontroller. The method uses a test control MCU to inject error signals and perform bus off characteristic testing on the ECU under test. The technical solution includes the following steps: S1, the first CAN bus is led out from the error signal output terminal of the test control MCU and connected to the ECU under test. The second CAN bus is led out from the data input terminal of the test control MCU and connected to the connection part between the first CAN bus and the ECU under test. The host computer is connected to the communication interface of the test control MCU. S2, reset and configure the test control MCU to complete the test preparation; S3 resets the ECU under test, bringing it back to normal operating condition. S4, the test process is started through the host computer. The host computer sends control commands to the test control MCU. The test control MCU injects error signals into the first CAN bus based on the control commands. S5, the tested ECU enters Busoff state based on the injected error signal; S6, the test control MCU listens to the messages sent by the ECU under test through the second CAN bus, obtains the message disappearance status and message reset status of the ECU under test, and records the test log. S7, the host computer obtains the message disappearance status and message reset status of the ECU under test and the test log, and analyzes the Busoff characteristics of the ECU under test.
[0010] By adopting the above technical solution, a Busoff test environment for a specific target ECU under test was constructed. The test control MCU was controlled by the pre-programmed control instructions of the host computer, realizing flexible control of error injection, thereby enabling convenient, efficient and lightweight Busoff characteristic testing.
[0011] Preferably, in S1, the specific method for connecting the ECU under test to the first CAN bus and the second CAN bus of the test control MCU is as follows: the end of the first CAN bus led out from the test control MCU is connected to the input terminal of the first T-type connector; one output terminal of the first T-type connector is extended backward; the other output terminal of the first T-type connector is connected to the input terminal of the second T-type connector; one output terminal of the second T-type connector is connected to the ECU under test; the other output terminal of the second T-type connector is connected to the second CAN bus; and the second CAN bus is connected to the data input terminal of the test control MCU.
[0012] By adopting the above technical solution, a CAN bus network was built in the test environment, which enables error signal injection through the first CAN bus and message monitoring of the ECU under test through the second CAN bus. The two CAN buses do not interfere with each other, improving the controllability of signal injection and the reliability of message monitoring.
[0013] Preferably, several ECUs under test are sequentially connected to the first CAN bus and the second CAN bus of the test control MCU. All ECUs under test are sequentially connected to the same first CAN bus, and each ECU under test is connected to a second CAN bus. Each second CAN bus is connected to a different data input terminal of the test control MCU.
[0014] By adopting the above technical solution, it is possible to deploy multiple ECUs under test, thereby testing the Busoff characteristics of multiple ECUs under test and their mutual influence.
[0015] Preferably, in S2, the reset and configuration of the test control MCU specifically includes: S201 Tests the power-on reset of the control MCU, restoring the registers to their default state. S202, Initialize the CAN controller of the test control MCU, configure the nominal baud rate of the CAN controller of the first CAN bus to be consistent with the nominal baud rate of the ECU under test, and configure the CAN controller of the second CAN bus to listen-only mode. S203, based on the connection method between the host computer and the test control MCU, configures the communication interface of the test control MCU; S204 loads the test control program, receives and parses the control commands from the host computer into control signals for the CAN controller, and performs timing control on the injected error signals.
[0016] Preferably, in S3, the reset of the tested ECU specifically includes: S301, the tested ECU restarts, executes the ECU initialization process, and enters the working state; S302, the tested ECU performs an error counter reset and verification; S303, the ECU under test sends a network management message. The test control MCU confirms that the ECU under test is in normal working condition by acquiring the network management message, and sends a test ready signal to the host computer.
[0017] By adopting the above technical solution, resetting and configuring the test control MCU before performing the Busoff characteristic test can ensure that the configuration of the test control MCU matches the current ECU under test and the test task, so as to prepare for the injection of error signals. Resetting the ECU under test can ensure that the ECU under test enters the initial normal working state before executing a new round of Busoff test, ensuring the reliability of the test, and avoiding the impact of other prior tests on the current test.
[0018] As a preferred embodiment, in S4, the control instructions sent by the host computer to the test control MCU consist of several types of control codes, and each type of control code corresponds to a type of error signal. The host computer sends control commands to the test control MCU segment by segment according to the type of control code. After sending a type of control code, the test control MCU stops sending when it hears the disappearance of the message from the ECU under test in S6. When the test control MCU hears the reset status of the message from the ECU under test in S6, it re-executes S3 to reset the ECU under test, and then sends the next segment of control code.
[0019] The above technical solution enables the host computer to send different control commands to the test control MCU based on different error signal modes. After the ECU under test implements Busoff based on one type of error signal, it waits for the ECU under test to reset in order to prepare for the test of the next type of error signal mode.
[0020] Preferably, in S6, the information monitored by the test control MCU includes the moment when the test control MCU receives the control command from the host computer and begins to inject the error signal, the moment when the tested ECU enters the Busoff state and the content of the last message sent before entering the Busoff state, the moment when the tested ECU recovers from the Busoff state and the content of the first message sent after recovery, and the network management messages continuously sent by the tested ECU.
[0021] Through the above technical solution, the test control MCU can obtain information about each node of the ECU under test from normal working state to Busoff state, and from Busoff state to normal working state, thereby realizing comprehensive status monitoring of the Busoff characteristics of the ECU under test and verifying the Busoff recovery strategy of the ECU under test.
[0022] Secondly, this application provides a CAN bus busoff characteristic testing system based on a microcontroller, which adopts the following technical solution: This includes the host computer, the test control MCU, and the ECU under test; The host computer is connected to the test control MCU; The test control MCU leads out a first CAN bus to connect to the ECU under test, and the test control MCU leads out a second CAN bus and connects to the connection point between the first CAN bus and the ECU under test.
[0023] Preferably, the test control MCU includes a communication module, a parsing module, a CAN controller, and a data buffer module; The communication module is used to establish a communication connection with the host computer, obtain control commands sent by the host computer, and send the test signals and test logs of the ECU under test to the host computer. The parsing module parses the control commands from the host computer into control signals from the CAN controller. The CAN controller includes a first CAN controller and a second CAN controller. The first CAN controller is connected to the ECU under test through a first CAN bus and injects an error signal through the first CAN bus. The second CAN controller is connected to the ECU under test through a second CAN bus, controls the second CAN bus to maintain a listen-only mode, and acquires the messages from the ECU under test that are being listened to by the second CAN bus. The data caching module caches the acquired test data, forms test logs, and sends them to the host computer through the communication module.
[0024] Thirdly, the computer program product provided in this application adopts a technical solution including a computer program or instructions, which enables the computer program or instructions to implement the steps in the above-mentioned CAN bus busoff characteristic test method based on a microcontroller.
[0025] In summary, this application includes at least one of the following beneficial technical effects: 1. This application does not require the construction of a complex whole vehicle testing environment. Instead, it uses a microcontroller platform to build an error signal injection network and a message monitoring network for one or more ECUs under test based on the CAN bus. This enables lightweight testing of the ECU's busoff characteristics. The system has a compact structure, flexible configuration, convenient and efficient testing, and low cost.
[0026] 2. In this application, the first CAN bus is used for error signal injection, and the second CAN bus is used for message monitoring of the ECU under test. The two buses are isolated from each other, thereby avoiding mutual interference between error signal injection and message monitoring, and enabling the acquisition of clean and reliable message data from the ECU under test.
[0027] 3. This application performs busoff characteristic testing on a specific ECU, which is highly targeted. All the data obtained is the busoff state change data of the target ECU under test. The data structure is clear and explicit, which is conducive to the analysis of the ECU's busoff characteristics.
[0028] 4. This application controls the MCU by using programmable control instructions from the host computer to control the signal, thereby controlling the injected error signal. It has a strong error simulation capability and can simulate various error signal types and BusOff causes according to requirements. It has high testing flexibility and can achieve in-depth testing of the robustness of the ECU under test. Attached Figure Description
[0029] Figure 1 This is a flowchart illustrating a method for testing the Busoff characteristics of a CAN bus based on a microcontroller, as described in an embodiment of this application. Figure 2 This is a schematic diagram of a control scheme for a CAN bus busoff characteristic testing method based on a microcontroller, as described in an embodiment of this application. Figure 3 This is a schematic diagram of the wiring topology of a CAN bus busoff characteristic testing method based on a microcontroller in an embodiment of this application; Figure 4 This is a schematic diagram of the wiring topology connecting multiple ECUs under test in a CAN bus bus off characteristic test method based on a microcontroller according to an embodiment of this application; Figure 5 This is a flowchart illustrating step S2 of a microcontroller-based CAN bus bus off characteristic testing method in an embodiment of this application. Figure 6 This is a flowchart illustrating step S3 of a microcontroller-based CAN bus bus off characteristic testing method in an embodiment of this application. Figure 7 This is a schematic diagram of the architecture of a CAN bus busoff characteristic testing system based on a microcontroller, as described in an embodiment of this application. Figure 8 This is a schematic diagram of the architecture of an exemplary computer device in an embodiment of this application. Detailed Implementation
[0030] This specific embodiment is merely an explanation of this application and is not intended to limit it. After reading this specification, those skilled in the art can make modifications to this embodiment without contributing any inventive step, but such modifications are protected by patent law as long as they are within the scope of this application.
[0031] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. It should be noted that in the optional embodiments of this application, the object information and other related data involved require the permission or consent of the object when the embodiments of this application are applied to specific products or technologies, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. That is to say, if the embodiments of this application involve data related to the object, it needs to be obtained with the authorization and consent of the object, the authorization and consent of the relevant departments, and in compliance with the relevant laws, regulations, and standards of the country and region. If personal information is involved in the embodiments, the acquisition of all personal information requires the consent of the individual. If sensitive information is involved, the separate consent of the information subject is required, and the embodiments also need to be implemented with the authorization and consent of the object.
[0032] The embodiments of this application will now be described in further detail with reference to the accompanying drawings.
[0033] The technical solution of this application eliminates the need to build a full-vehicle simulation test environment when testing the target ECU. Instead, it achieves error signal injection by connecting the test control MCU with the ECU under test, simulating the ECU receiving or sending error signals on the CAN bus. Furthermore, it monitors the busoff characteristics when the ECU initiates busoff after the accumulated errors exceed a threshold, ensuring compliance with design specifications. This application is particularly suitable for the early development stages of automotive ECUs, enabling rapid setup of a test environment for quick verification testing, and allowing for adjustments to the busoff control design of the automotive ECU based on the test results.
[0034] Please see Figure 1 The present application provides a method for testing the busoff characteristics of a CAN bus based on a microcontroller, which specifically includes the following steps.
[0035] S1 sets up the test environment for the ECU under test, including connecting the ECU under test to the test control MCU and connecting the test control MCU to the host computer.
[0036] For details, please refer to Figure 2The ECU under test is connected to the test control MCU via a first CAN bus and a second CAN bus. The first CAN bus is used to inject error signals, and the second CAN bus is used to monitor messages from the ECU under test. The test control MCU controls the signals and transmissions of the first and second CAN buses through the first and second CAN controllers, respectively. The first and second CAN buses use conventional twisted-pair cables with CAN_H and CAN_L branches, designated as CAN1_H, CAN1_L, CAN2_H, and CAN2_L, respectively.
[0037] Injecting erroneous signals or disruptive levels into the first CAN bus can degrade its communication quality. In particular, some erroneous signals require simulating bus occupancy, leading to a "signal flooding" state on the first CAN bus. If the test ECU is simultaneously monitoring messages on the first CAN bus, the test control MCU may be unable to correctly parse the ECU's messages due to its own injected errors, resulting in misjudgments of the Busoff characteristic. Therefore, in the embodiments of this application, a second CAN bus is used as an independent monitoring channel, used only for passive monitoring, without actively emitting signals and unaffected by erroneous signal injection, thus enabling the true and complete capture of the communication behavior of the test ECU.
[0038] For more details, please see Figure 3In the embodiments of this application, the specific wiring method for connecting the test control MCU to the ECU under test via the first CAN bus and the second CAN bus is as follows: The first CAN controller of the test control MCU leads out the first CAN bus, which is the error signal output terminal of the test control MCU. The second CAN controller of the test control MCU leads out the second CAN bus, which is the data input terminal for the test control MCU to obtain messages from the ECU under test. When wiring a target ECU under test is required, the end of the first CAN bus is connected to the input terminal of the first T-connector. One output terminal of the first T-connector is extended backward, and a terminating resistor is connected to the end of the extended terminal. The terminating resistor is used to achieve impedance matching with the terminating resistor built into the first CAN controller. The terminating resistor is typically 120Ω. The other output terminal of the first T-connector is connected to the input terminal of the second T-connector. One output terminal of the second T-connector is connected to the ECU under test, and the other output terminal of the second T-connector is connected to the second CAN bus. In another embodiment, a first T-type connector designed to adapt to the scheme of this application can also be used. Two parallel contacts are provided at the other output end of the first T-type connector, leading out two interfaces for wiring, eliminating the need for a second T-type connector. It should be noted that since the first CAN bus and the second CAN bus are twisted-pair cables including CAN_H and CAN_L branches, any interface leading out from the two parallel contacts includes both a CAN_H interface and a CAN_L interface.
[0039] The above connection method achieves complete isolation between error signal injection and the status monitoring of the ECU under test. The test control MCU listens to the messages from the ECU under test via the second CAN bus, ensuring their authenticity and reliability. Simultaneously, the T-connector makes the connection of the ECU under test more flexible; simply disconnect the current ECU from the T-connector and replace it with the next ECU under test without modifying the main wiring, thus improving testing efficiency.
[0040] In another embodiment of this application, please refer to Figure 4 The test control MCU includes several second CAN controllers and several second CAN buses. Several corresponding numbers of ECUs under test are sequentially connected to the first CAN bus and the second CAN bus of the test control MCU. All ECUs under test are sequentially connected to the same first CAN bus. Each ECU under test is connected to a second CAN bus. Each second CAN bus is connected to a different data input terminal of the test control MCU.
[0041] By deploying several ECUs under test simultaneously in the established test environment, on the one hand, the test efficiency can be improved by using scripts to control the control commands and adding the ID serial number of the ECU under test to the control commands, thus automatically executing the test task sequence in sequence; on the other hand, when testing single-point busoff and recovery behavior, the interlocking reactions that other nodes in the CAN bus network may produce can be tested, thereby effectively evaluating the consistency and robustness of the CAN drive design of each ECU.
[0042] S2 performs a reset and configuration of the test control MCU, enabling it to complete test preparation. A proper reset and configuration of the test control MCU ensures it enters a stable initial state, serving as the starting point for testing and guaranteeing the accuracy and reliability of the test results. Please refer to [link / reference]. Figure 5 Specifically, it includes the following steps.
[0043] S201 tests the power-on reset of the MCU, restoring the registers to their default state and clearing any random or erroneous states that may have existed previously.
[0044] S202, Initialize the CAN controller of the test control MCU, configure the nominal baud rate of the first CAN controller to be consistent with the nominal baud rate of the ECU under test, and configure the second CAN controller to listen-only mode.
[0045] The fundamental requirement for CAN bus communication is that all nodes use the same baud rate. For signals on the CAN bus to be transmitted and received correctly, the first CAN controller must be configured to be compatible with the target ECU under test, for example, configured at 1Mbps, 500kbps, or 125kbps. Configuring the second CAN controller to listen-only mode (silent mode) ensures that the second CAN bus only receives pure messages without sending any signal frames, eliminating interference from erroneous signal injection, and thus accurately monitoring and reflecting the true message behavior of the ECU under test.
[0046] S203 configures the communication interface of the test control MCU based on the connection method between the host computer and the MCU. Optional communication interfaces include USB, USB-to-TTL serial, and RS-232 serial. Regardless of the physical interface selected, it will be mapped to a serial communication COM port at the software layer. Appropriate parameter configuration of this COM port is required to enable normal communication between the host computer and the test control MCU.
[0047] S204, Load the test control program. The test control program is used to receive and parse the control commands from the host computer, translate the control commands into control signals that the CAN controller can recognize, thereby realizing the control of the first CAN controller and the second CAN controller, enabling the first CAN controller to inject timing control error signals into the first CAN bus.
[0048] S3 resets the ECU under test, bringing it back to normal operating condition. Please refer to [link / reference]. Figure 6 The specific steps for resetting the tested ECU are as follows.
[0049] S301, the tested ECU restarts. A control command triggers a reset of the tested ECU, which then executes the ECU initialization process and enters the working state.
[0050] S302, the ECU under test performs an error counter reset and verification. During normal operation, the error counters of the ECU's CAN controller, including the transmit error counter (TEC) and receive error counter (REC), accumulate due to various interferences on the bus. If the ECU under test is not reset before testing, the residual count will affect the Busoff characteristic test, causing the test results to deviate. Therefore, the error counters need to be reset before the Busoff characteristic test is officially started.
[0051] S303, the ECU under test sends a network management message. The test control MCU confirms that the ECU under test is in normal working condition by acquiring the network management message, and sends a test ready signal to the host computer.
[0052] When the ECU under test is in normal operating condition, it continuously sends messages via the CAN bus. The second CAN bus listens for these messages and transmits them to the test control MCU to confirm the ECU's online status. Once the ECU is confirmed to be in normal operating condition, the control MCU sends a test-ready signal to the host computer. Furthermore, the continuous listening of the second CAN bus to the ECU's messages is also an objective requirement for detecting when the ECU enters a busoff state and stops sending messages, and for recording this busoff state.
[0053] S4. After confirming test readiness, the test process is initiated via the host computer. The host computer sends control commands to the test control MCU, which then injects error signals into the first CAN bus via the CAN controller based on the control commands. The host computer can display the test status in real time on the display device, including "Test Ready," "Error Injection in Progress," "Waiting for BusOff," "Monitoring Recovery Process," and "Test Complete."
[0054] More specifically, the logic for injecting error signals into the tested ECU in this embodiment is described in detail. For a CAN bus composed of CAN_H and CAN_L branches, there are two basic states: dominant and recessive. If the differential voltage between the two branches is greater than a threshold, the logic value is 0, indicating a dominant state with strong coverage, capable of covering the bus level. If the differential voltage between the two branches is close to 0, the logic value is 1, indicating a recessive state with weak coverage, unable to resist dominant bits. Since the physical priority of dominant bits (logic 0) is higher than that of recessive bits (logic 1), as long as any node sends a dominant bit on the CAN bus, the bus will exhibit a dominant state. If a node attempts to send a recessive bit but detects that the bus is in a dominant state, it will detect a bit error, causing its transmission error counter to increase.
[0055] Based on this, signals corresponding to various scenarios that may lead to ECU communication failures in a real environment can be continuously injected into the first CAN bus to trigger the technical accumulation of the error counter of the ECU under test, thereby inducing the ECU under test to enter the Busoff state. The main error types include: bit errors (the test control MCU sends a level opposite to a specific bit); stuffing errors (the test control MCU sends a long dominant bit that destroys the arbitration or ACK field); CRC errors (the test control MCU sends a modified CRC sequence that does not match the true value); and saturation errors (the test control MCU sends signals for an extended period, occupying the bus and simulating bus saturation). The error signals corresponding to each error type are pre-programmed by the host computer using separate control instructions. These instructions control the first CAN controller of the test control MCU to inject the error signals.
[0056] S5: The error counter of the ECU under test accumulates error signals. When the error exceeds the threshold, the ECU under test enters the Busoff state. The ECU under test in the Busoff state is isolated from the CAN bus, which means it enters a silent state and does not send messages.
[0057] S6, the test control MCU listens to the messages sent by the ECU under test through the second CAN bus, obtains the message disappearance status and message reset signal status of the ECU under test, and records the test log.
[0058] More specifically, the information monitored by the test control MCU includes the following: the moment the test control MCU receives the host computer control command and begins injecting error signals, serving as the baseline time starting point for the test, which is the reference point for all time nodes; the moment the tested ECU enters the Bus-Off state, verifying whether the threshold for entering Bus-Off meets the standard, calculating the error accumulation rate, and evaluating the error detection sensitivity; the content of the last message sent before entering the Bus-Off state, determining whether the ECU was in a normal communication state before the crash, and eliminating other interference; the moment the tested ECU recovers from the Bus-Off state, calculating the Bus-Off duration, verifying the recovery strategy, including fast recovery and slow recovery, and whether it meets the design requirements; the content of the first message sent after recovery, confirming whether the ECU's application layer functions have recovered normally, and checking whether the message data (such as node status) is accurate; and the network management messages continuously sent by the tested ECU, evaluating the long-term communication stability and functional consistency of the tested ECU after recovery. Through the above information, it is possible to comprehensively and accurately determine whether the Bus-Off characteristics of the tested ECU meet the design requirements.
[0059] S7 obtains the message disappearance and reset status and test logs of the ECU under test from the host computer, and analyzes the busoff characteristics of the ECU under test. If the busoff characteristics of the ECU under test do not meet the design requirements, further optimization and adjustment are required.
[0060] In one embodiment of this application, the control commands sent from the host computer to the test control MCU consist of several types of control codes, each corresponding to a type of error signal. A reset command for the ECU under test is inserted between any two control codes of different error signal types.
[0061] According to the test task requirements, the host computer sends control commands to the test control MCU segment by segment based on the type of control code. For any type of control code, if the message from the ECU under test (DUT) detected by the test control MCU in S6 disappears, it indicates that the DUT has entered the Busoff state. Therefore, the host computer stops sending control codes and waits for the DUT to recover from Busoff. After the test control MCU detects the message from the DUT, it continuously monitors the message from the DUT based on the monitoring strategy to ensure that the DUT is in normal working condition and that the communication and function of the recovered DUT are stable. Then, it sends a test-ready signal.
[0062] Based on the test-ready signal, the host computer re-executes S3 to reset the ECU under test, preparing for the output of the next control code segment and executing the Busoff characteristic test for the next type of error signal. It's important to note that the ECU reset in the middle of the Busoff characteristic test differs from the ECU reset at the start of the Busoff characteristic test. It does not require a full cold start reset and reloading of the startup process for the ECU under test. Only the CAN controller module of the ECU under test needs to be reset without resetting the CPU core. The purpose is to clear the state machine and related registers of the CAN controller, thereby resetting the error counter. This objective can be achieved by setting the CAN control register reset in the reset instruction of the ECU under test.
[0063] After the ECU under test is reset, the test process for the next error type control code output can be executed manually or automatically by the host computer until all tests are completed.
[0064] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.
[0065] Please see Figure 7 This application discloses a CAN bus busoff characteristic testing system based on a single-chip microcomputer, which includes a host computer 1, a test control MCU 2, and an ECU under test 3.
[0066] The host computer 1 is connected to the test control MCU 2.
[0067] The test control MCU 2 includes a communication module 21, a parsing module 22, a first CAN controller 23, a second CAN controller 24, and a data buffer module 25.
[0068] The communication module 21 is used to establish a communication connection with the host computer, obtain the control commands sent by the host computer, and send the test signals and test logs of the tested ECU 3 to the host computer 1.
[0069] The parsing module 22 parses the control commands from the host computer 1 into control signals from the first CAN controller 23 and the second CAN controller 24.
[0070] The first CAN controller 23 is connected to the ECU under test 3 via the first CAN bus and injects error signals via the first CAN bus.
[0071] The second CAN controller 24 is connected to the connection between the first CAN bus and the ECU under test 3 via the second CAN bus, controls the second CAN bus to maintain a listen-only mode, and acquires the messages of the ECU under test 3 monitored by the second CAN bus.
[0072] The data caching module 25 caches the acquired test data, forms a test log, and sends it to the host computer 1 through the communication module 21.
[0073] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the microcontroller-based CAN bus bus off characteristic testing system described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.
[0074] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.
[0075] In one embodiment of this application, a computer device is provided, which may be a server, and its internal structure diagram may be as follows. Figure 8 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides the environment for the operating system and computer programs in the non-volatile storage media to run. The database stores control instructions from the test control MCU and busoff characteristic test data of the ECU under test sent by the test control MCU. The network interface is used for communication with the test control MCU. When executed by the processor, the computer program can implement a microcontroller-based CAN bus busoff characteristic testing method.
[0076] Unless otherwise defined, the technical or scientific terms used in this application shall have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms "first," "second," "third," and similar terms used in this application specification and claims do not indicate any order, quantity, or importance, but are merely used to distinguish different components. The terms "an" or "a" and similar terms do not indicate a quantity limitation, but rather indicate the presence of at least one. The terms "comprising" or "including" and similar terms mean that the elements or objects preceding "comprising" or "including" encompass the elements or objects listed following "comprising" or "including" and their equivalents, and do not exclude other elements or objects. "Above," "below," "left," "right," etc., are used only to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.
[0077] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.
Claims
1. A method for testing the bus off characteristics of a CAN bus based on a microcontroller, wherein a test control MCU is used to inject error signals and perform bus off characteristic tests on the ECU under test, characterized in that, Includes the following steps: S1, the first CAN bus is led out from the error signal output terminal of the test control MCU and connected to the ECU under test. The second CAN bus is led out from the data input terminal of the test control MCU and connected to the connection part between the first CAN bus and the ECU under test. The host computer is connected to the communication interface of the test control MCU. S2, reset and configure the test control MCU to complete the test preparation; S3 resets the ECU under test, bringing it back to normal operating condition. S4, the test process is started through the host computer. The host computer sends control commands to the test control MCU. The test control MCU injects error signals into the first CAN bus based on the control commands. S5, the tested ECU enters Busoff state based on the injected error signal; S6, the test control MCU listens to the messages sent by the ECU under test through the second CAN bus, obtains the message disappearance status and message reset status of the ECU under test, and records the test log; S7, the host computer obtains the message disappearance status and message reset status of the ECU under test and the test log, and analyzes the Busoff characteristics of the ECU under test.
2. The method for testing the Busoff characteristics of a CAN bus based on a microcontroller according to claim 1, characterized in that, In S1, the specific method for the ECU under test to connect to the first CAN bus and the second CAN bus of the test control MCU is as follows: the end of the first CAN bus led out from the test control MCU is connected to the input terminal of the first T-type connector, one output terminal of the first T-type connector is extended backward, the other output terminal of the first T-type connector is connected to the input terminal of the second T-type connector, one output terminal of the second T-type connector is connected to the ECU under test, the other output terminal of the second T-type connector is connected to the second CAN bus, and the second CAN bus is connected to the data input terminal of the test control MCU.
3. The method for testing the Busoff characteristics of a CAN bus based on a microcontroller according to claim 2, characterized in that, Several ECUs under test are sequentially connected to the first CAN bus and the second CAN bus of the test control MCU. All ECUs under test are sequentially connected to the same first CAN bus, and each ECU under test is connected to a second CAN bus. Each second CAN bus is connected to a different data input terminal of the test control MCU.
4. The method for testing the Busoff characteristics of a CAN bus based on a microcontroller according to claim 1, characterized in that, In S2, the reset and configuration of the test control MCU specifically include: S201 Tests the power-on reset of the control MCU, restoring the registers to their default state. S202, Initialize the CAN controller of the test control MCU, configure the nominal baud rate of the CAN controller of the first CAN bus to be consistent with the nominal baud rate of the ECU under test, and configure the CAN controller of the second CAN bus to listen-only mode. S203, based on the connection method between the host computer and the test control MCU, configures the communication interface of the test control MCU; S204 loads the test control program, receives and parses the control commands from the host computer into control signals for the CAN controller, and performs timing control on the injected error signals.
5. The method for testing the busoff characteristics of a CAN bus based on a microcontroller according to claim 1, characterized in that, In S3, the reset of the tested ECU specifically includes: S301, the tested ECU restarts, executes the ECU initialization process, and enters the working state; S302, the tested ECU performs an error counter reset and verification; S303, the ECU under test sends a network management message. The test control MCU confirms that the ECU under test is in normal working condition by acquiring the network management message, and sends a test ready signal to the host computer.
6. The method for testing the busoff characteristics of a CAN bus based on a microcontroller according to claim 5, characterized in that, In S4, the control commands sent by the host computer to the test control MCU consist of several types of control codes, and each type of control code corresponds to a type of error signal. The host computer sends control commands to the test control MCU segment by segment according to the type of control code. After sending a type of control code, the test control MCU stops sending when it hears the disappearance of the message from the ECU under test in S6. When the test control MCU hears the reset status of the message from the ECU under test in S6, it re-executes S3 to reset the ECU under test, and then sends the next segment of control code.
7. The method for testing the Busoff characteristics of a CAN bus based on a microcontroller according to claim 1, characterized in that, In S6, the information monitored by the test control MCU includes the moment when the test control MCU receives the control command from the host computer and starts injecting error signals, the moment when the tested ECU enters the Busoff state and the content of the last message sent before entering the Busoff state, the moment when the tested ECU recovers from the Busoff state and the content of the first message sent after recovery, and the network management messages continuously sent by the tested ECU.
8. A CAN bus busoff characteristic testing system based on a microcontroller, characterized in that, This includes the host computer, the test control MCU, and the ECU under test; The host computer is connected to the test control MCU; The test control MCU leads out a first CAN bus to connect to the ECU under test, and the test control MCU leads out a second CAN bus and connects to the connection point between the first CAN bus and the ECU under test.
9. A CAN bus busoff characteristic testing system based on a microcontroller according to claim 8, characterized in that, The test control MCU includes a communication module, a parsing module, a CAN controller, and a data buffer module; The communication module is used to establish a communication connection with the host computer, obtain control commands sent by the host computer, and send the test signals and test logs of the ECU under test to the host computer. The parsing module parses the control commands from the host computer into control signals from the CAN controller. The CAN controller includes a first CAN controller and a second CAN controller. The first CAN controller is connected to the ECU under test through a first CAN bus and injects an error signal through the first CAN bus. The second CAN controller is connected to the ECU under test through a second CAN bus, controls the second CAN bus to maintain a listen-only mode, and acquires the messages from the ECU under test that are being listened to by the second CAN bus. The data caching module caches the acquired ECU messages, generates test logs, and sends them to the host computer via the communication module.
10. A computer program product, characterized in that, The computer program product includes a computer program or instructions that enable the computer program or instructions to perform the steps in the single-chip microcomputer-based CAN bus busoff characteristic testing method according to any one of claims 1 to 7.