Test method, test bench and electronic equipment for multi-ECU system

Abstract

The present disclosure provides a test method, test bench and electronic device for a multi-ECU system. The test method includes: based on a number of pre-configured test items, creating a Docker container that matches each test item; obtaining the frame data of the test task in each Docker container, and converting the frame data into a CAN signal; performing data processing on the CAN signal to obtain a target CAN signal, and transmitting the target CAN signal to the corresponding ECU system to be tested; wherein different target CAN signals are sent to the corresponding ECU system to be tested using a parallel signal processing mechanism; receiving the response data of each ECU system to be tested, adding the device identification of the test ECU system to the response data, and transmitting it to the corresponding Docker container to test the ECU system to be tested. The present disclosure realizes the dynamic management of the test environment, reduces the test cost and improves the test efficiency.

Description

Technical Field

[0001] The present disclosure relates to the field of intelligent driving technology, and in particular to a test method, a test bench and an electronic device for a multi-ECU system. Background Art

[0002] CAN (Controller Area Network) communication technology is the foundation of modern automotive electronic systems and is widely used for communication between vehicle ECUs (Electronic Control Units). As a communication signal, CAN is also widely used in diagnostic tests and bench function stress tests. As the complexity of vehicle electronic systems increases, multi-ECU systems are becoming more and more common in modern vehicles, and the corresponding ECU-based CAN communication stress test solutions have also put forward higher requirements.

[0003] However, existing vehicle CAN communication stress tests usually use commercial testers, which greatly increases the financial investment cost for test scenarios with multiple projects coexisting, and it is difficult to achieve multiple ECUs receiving and sending data at the same time, resulting in low test efficiency. At the same time, the existing stress test bench environment mostly uses fixed software and hardware configurations, which cannot be applied to different test projects, resulting in low resource utilization.

[0004] It can be seen that although the existing vehicle-mounted CAN communication stress test method has been widely used in the field of automotive electronics, it still has significant shortcomings in terms of parallel test efficiency of multi-ECU systems, test cost optimization, test environment flexibility, resource utilization, etc., and a more efficient, flexible and economical solution is urgently needed. Summary of the invention

[0005] The technical problem to be solved by the present disclosure is to overcome the defects in the prior art that multiple ECUs cannot be tested in parallel, and the testing cost is high and the resource utilization rate is low, and to provide a testing method, a test bench and an electronic device for a multi-ECU system.

[0006] The present invention solves the above technical problems through the following technical solutions:

[0007] According to a first aspect of the present disclosure, a test method for a multi-ECU system is provided, the test method comprising:

[0008] Based on a plurality of pre-configured test projects, a Docker (an open source project for building, publishing and running applications) container matching each of the test projects is created; the test project includes a test task and a device identifier of at least one ECU system to be tested;

[0009] Obtain frame data of the test task in each of the Docker containers, and convert the frame data into a CAN signal;

[0010] Processing the CAN signal to obtain a target CAN signal, and transmitting the target CAN signal to the corresponding ECU system to be tested;

[0011] Wherein, different target CAN signals are sent to the corresponding ECU system to be tested using a parallel signal processing mechanism;

[0012] Receive response data of each of the ECU systems to be tested, add the device identification of the test ECU system to the response data, and transmit it to the corresponding Docker container to test the ECU system to be tested and obtain the test result of the ECU system to be tested.

[0013] Preferably, the step of performing data processing on the CAN signal to obtain a target CAN signal comprises:

[0014] Filtering the CAN signals based on preset filtering conditions, and packaging the filtered CAN signals to generate the target CAN signals;

[0015] The preset filtering condition includes at least one of a MAC (Media Access Control) address range filtering condition, a frame type filtering condition, and a data length filtering condition.

[0016] Preferably, the step of filtering the CAN signal based on a preset filtering condition comprises:

[0017] Monitor the CAN bus load and / or CAN signal delay to obtain monitoring data;

[0018] According to the monitoring data, the preset filtering condition is updated;

[0019] The CAN signal is filtered based on the updated preset filtering condition.

[0020] Preferably, the step of transmitting the target CAN signal to the corresponding ECU system to be tested includes:

[0021] Create a thread pool;

[0022] Allocate a thread to each of the ECU systems to be tested according to the device identification;

[0023] The target CAN signal is transmitted to the ECU system to be tested based on the thread.

[0024] Preferably, the step of transmitting the target CAN signal to the corresponding ECU system to be tested includes:

[0025] Monitor the signal queue of CAN bus;

[0026] In response to the signal queue reaching a first threshold, determining at least one target ECU system to be tested according to the number of target CAN signals corresponding to each of the ECU systems to be tested in the signal queue;

[0027] Adding the thread to the target ECU system to be tested;

[0028] and / or,

[0029] The step of transmitting the target CAN signal to the corresponding ECU system to be tested also includes:

[0030] Allocate each thread of the same test item to a preset CAN channel for transmission;

[0031] In response to the load rate of the preset CAN channel reaching a second threshold, at least one of the threads is switched to a standby CAN channel for transmission based on a preset adjustment rule.

[0032] Preferably, after the step of transmitting the target CAN signal to the corresponding ECU system to be tested, the testing method further comprises:

[0033] Monitoring the transmission status of the target CAN signal;

[0034] In response to the transmission state being an abnormal state, re-executing the transmission operation of the target CAN signal and recording the abnormal state.

[0035] Preferably, the step of transmitting the target CAN signal to the corresponding ECU system to be tested includes:

[0036] Transmitting the target CAN signal to the ECU system to be tested at a preconfigured transmission rate;

[0037] Among them, the transmission rate of the CAN FD (upgraded version of the CAN communication protocol) network is greater than that of the standard CAN network.

[0038] Preferably, the testing method further comprises:

[0039] The device identification of each ECU system to be tested is generated by using a timestamp or a hash algorithm.

[0040] According to a second aspect of the present disclosure, a test bench for a multi-ECU system is provided, the test bench comprising an actuator, a plurality of PEAK (devices for converting CAN signals) devices and a plurality of signal processors; each of the signal processors is communicatively connected to the actuator via one of the PEAK devices; each of the signal processors is provided with a plurality of interfaces for respectively connecting to a plurality of ECU systems to be tested;

[0041] The execution machine is used to create a Docker container matching each of the pre-configured test items based on a plurality of pre-configured test items; the test items include a test task and a device identifier of at least one ECU system to be tested;

[0042] The PEAK device is used to obtain the frame data of the test task in each of the Docker containers and convert the frame data into a CAN signal;

[0043] The signal processor is used to perform data processing on the CAN signal to obtain a target CAN signal, and transmit the target CAN signal to the corresponding ECU system to be tested;

[0044] Wherein, different target CAN signals are sent to the corresponding ECU system to be tested using a parallel signal processing mechanism;

[0045] The signal processor is also used to receive response data of each of the ECU systems to be tested, add the device identification of the test ECU system to the response data, and transmit it to the corresponding Docker container to test the ECU system to be tested and obtain the test result of the ECU system to be tested.

[0046] According to a third aspect of the present disclosure, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and used to run on the processor, wherein when the processor executes the computer program, the test method of the multi-ECU system described in the first aspect of the present disclosure is implemented.

[0047] On the basis of being in accordance with the common sense in the art, the above-mentioned preferred conditions can be arbitrarily combined to obtain the preferred embodiments of the present disclosure.

[0048] The positive progress of the present disclosure is that: through containerized deployment technology, dynamic management of the test environment is realized, and the test environment configuration can be quickly adjusted according to actual needs, which not only simplifies the test preparation process, but also enables the system to have stronger scalability and can easily adapt to test tasks of different scales and complexities; and through a parallel signal processing mechanism, signals are sent and backchecked to multiple ECUs at the same time, which significantly improves the test efficiency of the multi-ECU system while reducing the test cost, and reduces the interference and delay problems in signal transmission, and improves the accuracy and consistency of the test results. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] Figure 1 A flow chart of a method for testing a multi-ECU system disclosed herein;

[0050] Figure 2 A first schematic diagram of a test bench for a multi-ECU system disclosed herein;

[0051] Figure 3 A second schematic diagram of a test bench for a multi-ECU system disclosed herein;

[0052] Figure 4 is a flowchart of step S31 in the test method of the multi-ECU system disclosed in the present invention;

[0053] Figure 5 A third schematic diagram of a test bench for a multi-ECU system disclosed herein;

[0054] Figure 6 The figure is a schematic diagram of the structure of an electronic device disclosed in the present invention. DETAILED DESCRIPTION

[0055] The present disclosure is further described below by way of examples, but the present disclosure is not limited to the scope of the examples.

[0056] Prefixes such as "first" and "second" are used in the embodiments of the present disclosure only to distinguish different description objects, and have no limiting effect on the position, order, priority, quantity or content of the described objects. The use of prefixes such as ordinal numbers to distinguish description objects in the embodiments of the present disclosure does not constitute a limitation on the described objects. For the statement of the described objects, please refer to the description in the context of the claims or embodiments, and no unnecessary limitation should be constituted due to the use of such prefixes. In addition, in the description of the present embodiment, unless otherwise specified, the meaning of "plurality" is two or more.

[0057] In the embodiments of the present disclosure, the collection, storage, use, processing, transmission, provision and disclosure of user personal information involved are in compliance with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0058] Traditional testing methods often use serial communication mode, which cannot support data exchange between multiple ECUs at the same time, which makes the testing process lengthy and inefficient. In addition, in a complex multi-ECU system environment, signal interference and transmission delay are more significant. The existing CAN communication method is difficult to maintain communication stability and real-time performance in a large-scale ECU stress test environment.

[0059] Secondly, traditional vehicle-mounted CAN communication bench stress testing usually relies on a single ECU controller solution, and the commercial test equipment commonly used, such as vector (a CAN tool) (CANoe.Ethernet (Ethernet hardware configuration)), Zhou Ligong (ZTIE1000), etc., is relatively expensive. Since these devices require a license to send CAN test signals at the same time, a specific license is required to send CAN test signals. When faced with multiple parallel projects and the need to perform diagnostic tests on a large number of ECUs, the test cost increases significantly, which puts great pressure on the financial budget.

[0060] Third, the existing test environment deployment process is cumbersome and lacks flexibility. Traditional test systems usually use fixed hardware and software configurations. The test scripts required by different projects, the test command execution machine (host computer), ECU equipment, and test diagnostic instruments are all fixed, which makes it difficult to effectively share test resources between different projects. The same model of ECU hardware under test needs to be tested under a fixed configuration, resulting in lengthy test preparation time and limiting the scalability of the test and the adaptability of hardware resources. In addition, this fixed configuration also causes a waste of existing test resources, resulting in low resource utilization, and it is difficult to achieve efficient use of test resources in multi-task parallel testing.

[0061] In view of this, the present disclosure provides a test method, a test bench and an electronic device for a multi-ECU system to solve the problems in the prior art that multiple ECUs cannot be tested in parallel, and the test cost is high and the resource utilization is low.

[0062] Example 1

[0063] In a specific embodiment of the present disclosure, a test method for a multi-ECU system is provided, such as Figure 1 As shown, the test methods include:

[0064] S1. Based on several pre-configured test projects, create a Docker container matching each test project; the test project includes a test task and a device identifier of at least one ECU system to be tested;

[0065] S2, obtain the frame data of the test task in each Docker container and convert the frame data into CAN signals;

[0066] S3, performing data processing on the CAN signal to obtain a target CAN signal, and transmitting the target CAN signal to the corresponding ECU system to be tested;

[0067] Among them, different target CAN signals are sent to the corresponding ECU system to be tested using a parallel signal processing mechanism;

[0068] S4. Receive response data from each ECU system to be tested, add the device identifier of the test ECU system to the response data, and transmit it to the corresponding Docker container to test the ECU system to be tested and obtain the test result of the ECU system to be tested.

[0069] Specifically, in order to achieve parallel signal processing of multi-ECU systems, a parallel signal processing mechanism is introduced on the execution end. For example, a signal processor for multi-channel signal processing is used to support simultaneous data transmission on multiple communication channels. At the same time, in order to improve the flexibility and scalability of the test environment, automated test cases of different projects are stored on the execution end, and Docker container technology is introduced to achieve dynamic deployment of the test environment.

[0070] like Figure 2 As shown, the lower-cost PEAK equipment (thousand-yuan level) is selected to replace the commercial Vector / Zhou Ligong equipment (more than one hundred thousand yuan level). By connecting the actuator to several PEAK devices, each PEAK is communicated with a signal processor to form a test bench for multiple ECU systems, wherein each signal processor is provided with multiple interfaces to connect with multiple ECU systems to be tested respectively.

[0071] It should be noted that in order to enable more PEAK devices to be connected to the actuator to achieve parallel testing of more ECU systems to be tested, such as Figure 3 As shown, a Usb-Hub (Universal Serial Bus Hub) can also be added to the test bench of the multi-ECU system.

[0072] When one or more test projects execute automated test cases at the same time, step S1 creates different Docker containers according to the template image through the execution machine. Different Docker containers are dynamically bound to different PEAK devices. Different PEAK devices are connected to the fixed ECU system to be tested through the corresponding signal processor, and the automated test cases corresponding to different test projects are passed into the corresponding Docker containers, and the automated commands are executed in the containers.

[0073] Among them, the environment configuration table can be queried through the script to assign the PEAK device number and the address of the ECU system to be tested to each project. Under the startup instruction, the execution machine starts a new container by calling the Docker API (Docker's application program interface), and passes the device identification and test task of the ECU system to be tested through parameters. At the same time, the range of CAN ID (identifier of CAN signal) is modified to bind the signal of the automation use case, so as to create different Docker containers according to different test projects, and use the CAN-USB (a technology that connects the CAN bus to the USB (Universal Serial Bus) interface) provided by PEAK to be recognized by the execution machine, thereby realizing the forwarding and reception of CAN signals in the entire link.

[0074] The automated test cases in each Docker container transmit frame data to the bound PEAK device according to the test task. The PEAK device converts the received frame data into CAN signals through step S2 and transmits the CAN signals to the corresponding signal processor.

[0075] After receiving the CAN signal, the signal processor processes the CAN signal according to a preset script through step S3, for example, performs a validity check on the identifier of the CAN signal, performs a protocol specification check on the content of the CAN signal, etc., to obtain the target CAN signal, and transmits the target CAN signal to the corresponding ECU system to be tested through a parallel signal processing mechanism, so that the ECU system to be tested can respond.

[0076] Since different ECU systems to be tested may send the same response data, resulting in signal conflicts and processing confusion, the signal processor will add the device identification of the ECU system to the corresponding response data after receiving the response data of each ECU system to be tested, generate a unique identifier, and transmit it to the corresponding Docker container, so that even if different ECU systems to be tested send the same response data, the signal processor can accurately distinguish and process each response data. The Docker container will test the ECU system to be tested based on the received response data according to the automated command, obtain the test results of the ECU system to be tested, and transmit the test results to the execution machine. When the automated operation of a project is completed, the PEAK and ECU system resources to be tested are released and can continue to be used by other projects, thereby improving resource utilization and automated testing efficiency.

[0077] Among them, the device identification of the ECU system to be tested is generated by using a timestamp or a hash algorithm, so that each ECU system to be tested has a unique device identification number DevicesSN. For example, when the device identification is generated by using a timestamp, a combination of a UNIX (an operating system) timestamp and a device number can be used to generate a device identification of "timestamp-device number"; when a hash algorithm is used to generate a unique device identification, the physical address of the ECU system to be tested (such as the hardware number of the CAN module) can be calculated by SHA-256 (a hash algorithm) or MD5 (an information digest algorithm) to generate a unique device identification.

[0078] This specific implementation method realizes dynamic management of the test environment through containerized deployment technology, and can quickly adjust the test environment configuration according to actual needs, which not only simplifies the test preparation process, but also enables the system to have stronger scalability and can easily adapt to test tasks of different scales and complexities; and through a parallel signal processing mechanism, signals are sent and backchecked to multiple ECUs at the same time, which significantly improves the test efficiency of the multi-ECU system while reducing the test cost, and reduces interference and delay problems in signal transmission, thereby improving the accuracy and consistency of the test results.

[0079] In a specific implementation, step S3 includes:

[0080] S31, filtering the CAN signals based on preset filtering conditions, and packaging the filtered CAN signals to generate target CAN signals;

[0081] The preset filtering condition includes at least one of a MAC address range filtering condition, a frame type filtering condition, and a data length filtering condition.

[0082] Specifically, the network filter can be configured in advance to filter the valid frame data according to the set communication protocol and the specific test requirements of each ECU system to be tested. The network filter has a multi-level filtering mechanism, which can be configured to filter according to the MAC address, frame type, data length and other attributes of the frame data, and the filtered CAN signal is packaged according to the communication protocol to generate the target CAN signal. Through the refined filtering strategy, it is ensured that only CAN signals that meet the preset filtering conditions can be received and processed by the signal processor, and irrelevant or conflicting signals are directly discarded, thereby shielding irrelevant or signal interference that may cause errors.

[0083] In a specific example, the identifier (ID) of the CAN signal can be matched and screened with a predefined whitelist or blacklist, and the content of the CAN signal can also be checked to see if it complies with the protocol specifications, such as the correctness of the CRC (cyclic redundancy check) check code and the rolling count value. In the CAN protocol, the priority is determined by the size of the identifier ID, and the network filter can be set to receive high-priority signals; for the CAN FD protocol, the network filter supports independent settings for the extended frame format (Extended Frame) and the standard frame format (Standard Frame).

[0084] For example, in the ECU test of ADAS (Advanced Driver Assistance System), only periodic signals with ID range of 0x100 to 0x1FF are received, while abnormal signals that fail CRC check are discarded.

[0085] In a specific embodiment, Figure 4 As shown, step S31 specifically includes:

[0086] S311, monitoring the CAN bus load and / or CAN signal delay to obtain monitoring data;

[0087] S312, updating the preset filtering conditions according to the monitoring data;

[0088] S313: Filter the CAN signal based on the updated preset filtering condition.

[0089] Specifically, the signal processor can also dynamically adjust the filtering conditions of the network filter according to the actual communication environment and needs. For example, in scenarios with a large amount of signals, the filtering conditions only allow the reception of high-priority control signals to reduce the CAN bus load. During the debugging phase, the filtering conditions will be relaxed to allow the reception of all signals in order to record complete logs, thereby ensuring that the signal processor can cope with different test scenarios and complex multi-ECU system environments.

[0090] In a specific example, the real-time load rate of the CAN bus can be monitored to analyze the real-time load rate of the CAN bus (e.g., whether the number of frames per second exceeds a threshold), and the delay of the CAN signal can be monitored to detect whether the reception time of the signal exceeds the expected range. When the load rate of the CAN bus exceeds the set threshold (e.g., 80%) or the signal reception time exceeds the expected range, the filter condition is automatically updated, for example, only the key signals in the ID range of 0x100 to 0x200 are received.

[0091] In a specific implementation, step S3 further includes:

[0092] S32, creating a thread pool, allocating a thread to each ECU system to be tested according to the device identification, and transmitting the target CAN signal to the ECU system to be tested based on the thread.

[0093] Specifically, the parallel signal processing mechanism of the signal processor is implemented through a task scheduler, and a thread pool is created using the task scheduler to process the target CAN signal assigned to each ECU system to be tested, wherein each thread corresponds to a signal sending task of the ECU system to be tested, and contains the device identification corresponding to the ECU system to be tested to avoid task conflicts. In each thread, the target CAN signal is implemented through a non-blocking I / O (input / output) mechanism, and the signal packets are sorted according to timestamps and prioritized. At the same time, the transmission of the response data of each ECU system to be tested adopts a timer trigger mechanism to ensure that each thread stably sends signals according to a predetermined transmission interval (for example, an interval of 10ms (milliseconds)), avoiding the impact of signal congestion on the CAN bus. Mutex lock mechanisms can also be used to protect shared resources (for example, signal queues) to avoid thread competition, thereby ensuring the transmission stability of the CAN bus.

[0094] In a specific implementation, step S3 further includes:

[0095] S33, monitoring the signal queue of the CAN bus; in response to the signal queue reaching a first threshold, determining at least one target ECU system to be tested according to the number of target CAN signals corresponding to each ECU system to be tested in the signal queue; adding a thread to the target ECU system to be tested;

[0096] Specifically, in order to further improve the transmission efficiency of the CAN bus, the signal queue in the CAN bus can be monitored, and the task scheduler can be used to dynamically allocate threads according to the number of tasks in the CAN bus signal queue. Whenever the signal queue reaches the set first threshold, the task scheduler will trigger the multi-threaded signal processing process, determine the target ECU system to be tested that needs to increase thread transmission according to the number of target CAN signals corresponding to each ECU system to be tested in the signal queue, and add threads to the determined target ECU system to be tested, thereby improving the test efficiency.

[0097] For example, if the test project needs to test three ECU systems to be tested, A, B, and C, the task scheduler will assign a thread to each of the three ECU systems to be tested, to send the corresponding test signals, and monitor the signal queue of the CAN bus. When the signal queue reaches the first threshold, the number of target CAN signals to be sent to the three ECU systems to be tested, A, B, and C, in the signal queue is detected. The number of CAN signals to be sent to ECU A is the largest, so a thread can be added to ECU A to improve the transmission efficiency of the target CAN signal to ECU A and avoid congestion.

[0098] In a specific implementation, step S3 further includes:

[0099] S34, allocating each thread of the same test item to a preset CAN channel for transmission; in response to the load rate of the preset CAN channel reaching a second threshold, switching at least one thread to a spare CAN channel for transmission based on a preset adjustment rule.

[0100] Specifically, the signal processor also has an intelligent signal routing management function, which can dynamically select the optimal signal transmission path according to the actual needs of the ECU system to be tested, so as to further improve the efficiency and reliability of signal transmission. Among them, the signal processor can regularly obtain the real-time load information of the CAN bus to evaluate the occupancy of each channel, dynamically adjust the signal sending order according to the occupancy, schedule high-priority signals to channels with low loads, and distribute signals in real time according to the occupancy of the channels to achieve load balancing of multi-channel CAN devices.

[0101] In a specific example, suppose that in a certain autonomous driving test scenario, there are 3 ECU systems to be tested (A, B, C) and 2 CAN channels (Channel 1 and Channel 2), among which: the signal sent by ECU A includes braking control, which is a high priority signal; the signal sent by ECU B is environmental monitoring data, which is a medium priority signal; the signal sent by ECU C is log recording information, which is a low priority signal.

[0102] In the initial state, the load rate of channel 1 is 40%, the load rate of channel 2 is 20%, and all signals are assigned to channel 1 by default. During the test, the load of channel 1 gradually increased to 70%, exceeding the set threshold (for example, 60%). The signal processor monitors this change in real time and switches the medium and low priority signals to channel 2 to ensure that channel 1 is mainly used for high priority signal transmission. In other words, the brake control signal of ECU A continues to be sent through channel 1 to avoid delays, and the signals of ECU B and ECU C are changed to channel 2 for transmission. At the same time, the load of channel 2 is maintained at about 50%, ensuring the stable transmission of log records and environmental data. Through this dynamic selection, the real-time performance of high priority signals is guaranteed, and the overload of a single channel is avoided, thereby improving the overall network communication efficiency and reliability.

[0103] In a specific implementation, after step S3, the testing method further includes:

[0104] Monitor the transmission status of the target CAN signal;

[0105] In response to the transmission status being an abnormal state, a transmission operation of the target CAN signal is re-executed, and the abnormal state is recorded.

[0106] Specifically, when sending the target CAN signal to multiple ECUs, the signal processor will send the target CAN signal to be sent to the buffer through the vehicle Ethernet or CAN bus, and will also monitor the transmission status of the target CAN signal to ensure that each target CAN signal can be reliably transmitted to the corresponding ECU system to be tested. If a target CAN signal transmission error or signal loss is detected during the transmission process, the transmission status is determined to be an abnormal state, and the signal processor will automatically retransmit the target CAN signal and record the abnormal situation for subsequent test analysis.

[0107] In a specific implementation, step S3 further includes:

[0108] Transmit the target CAN signal to the ECU system under test at a pre-configured transmission rate;

[0109] Among them, the transmission rate of the CANFD network is greater than that of the standard CAN network.

[0110] Specifically, according to the test requirements of different ECU systems to be tested, the appropriate transmission rate can be set (transmission rate = frame data size ÷ transmission time, frame data size includes ID, data bytes and check bits) to ensure that CAN signals can be transmitted quickly and accurately in different environments. Among them, the transmission rate can be specifically set according to the hardware configuration of the ECU system to be tested (for example: processor main frequency, memory size, etc.), network bandwidth (for example: CAN / CANFD bus rate limit), signal priority (for example: real-time distinction between control signals and normal status signals), network topology (for example: whether there are multi-level gateways or multiple nodes), etc.

[0111] For the standard CAN network, the transmission rate is usually set to 250Kbps (kilobits per second) or 500Kbps for conventional ECU system communication under test; for the CANFD network, the transmission rate in the high-speed data transmission stage can be set to 1Mbps (megabits per second) or higher for signal transmission with higher real-time requirements.

[0112] In a specific implementation, step S4 further includes: filtering the response data based on preset filtering conditions, parsing and extracting valid response data, and transmitting them to the corresponding Docker container.

[0113] Specifically, the signal processor monitors the response data sent by all ECU systems to be tested through the CAN bus, and uses preset filtering conditions to filter the received response data. For example, the data to be processed is filtered out according to filtering conditions such as MAC address, frame type, data length, etc., so as to reduce unnecessary processing burden. At the same time, the filtered data is parsed, for example, using a protocol parsing tool (such as DBC (a file format describing CAN bus communication information) file) to parse the CAN / CANFD signal, or according to the signal mapping table in the ID and DBC file, determine the meaning and physical value of the data parameters to extract the necessary control instructions (such as start / stop signals, mode switching commands, etc.) or data parameters (such as vehicle speed, steering wheel angle, motor status, etc.) to form effective response data, which is stored in the buffer for further processing. Among them, physical value = original value * parsing factor + offset.

[0114] In a specific example, a signal with ID 0x120 is received, and the data field indicates that the current speed is 80 km / h (kilometers per hour), which is stored as a speed parameter for subsequent analysis.

[0115] In one embodiment, when the signal processor detects a specific signal, it triggers an LED (light emitting diode) indicator or other physical device to confirm that the signal is received and processed successfully. At the same time, key signal data and processing results are recorded in a database for subsequent analysis and report generation.

[0116] In some cases, the signal processor converts the identifier of the received response data, modifies the identifier, and forwards the response data to other network ports or system modules for further processing or verification. This can achieve data synchronization and sharing between different ECUs to ensure the coordination and consistency of the system. For example: In an automatic parking test scenario, the signal processor forwards the obstacle detection signal (ID is 0x180) from the sensor ECU to the main control ECU for trajectory planning verification. Among them, the signal processor updates the CRC field and frame counter when forwarding to ensure compatibility.

[0117] by Figure 5 For example, when a new test project project1 needs to be stress tested, the execution machine is triggered to automatically create docker1. During the creation process, the environment configuration table is checked. When creating the container, the required automation use cases, automation result storage path, etc. are configured at the same time. The command is executed to bind the required PEAK device (such as PEAK1).

[0118] In the docker1 container, the automated command is executed, and the frame data corresponding to the test task is sent to the bound PEAK device and converted into a CAN signal. The CAN signal is distributed to multiple ECU systems to be tested (for example, ECU1, ECU2, and ECU3) through the signal processor. Each ECU system to be tested responds differently after receiving the CAN signal. After receiving the response data, the signal processor converts and processes the CAN signals from different ECU systems to be tested, and then returns the converted response data to the docker1 container for automated information verification. The entire process ensures that each ECU system to be tested receives and processes the signal synchronously.

[0119] After receiving the response data from different ECU systems to be tested under PEAK1, the automated test cases in docker1 perform verification and generate verification information. The verification information includes: cockpit CAN information, fault code diagnosis, sleep and wake-up information, etc. After the stress test is completed, a test report is automatically generated. The report includes the test results of all ECU systems to be tested under the bound PEAK1, and the report is directly mapped to the external execution machine.

[0120] After docker1 is executed, it sends a message to the execution machine to destroy the container and automatically releases the hardware resources of the project.

[0121] When multiple projects are running at the same time, you can use the above test process to create a container and execute the stress test solution.

[0122] When not all projects are running at the same time in a certain period of time, for example, when the test project project2 (corresponding to docker2, the ECU systems to be tested include ECU4, ECU5, and ECU6) is finished, the hardware resources (same hardware model) of project2 can be dynamically added to the hardware environment of project1, and the execution machine updates the loop. Environment configuration table. When the test project project1 is started When docker1 is created, it will automatically bind to PEAK 1 and PEAK2, the automated test case in docker1 will send frame data to PEAK1 and PEAK2 at the same time, so that ECU1-6 can be tested at the same time; when project2 ends after project1 is started, docker1 will automatically identify PEAK2 and send different frame data to PEAK2. Then, after the data is processed by the signal processors of PEAK1 and PEAK2, they interact with their respective ECU systems to be tested, complete the verification of the automated test case, analyze and summarize the data, and output the test report. After the execution is completed, the container is released for use in new test projects.

[0123] This embodiment realizes dynamic management of the test environment through containerized deployment technology, and can quickly adjust the test environment configuration according to actual needs, which not only simplifies the test preparation process, but also enables the system to have stronger scalability and can easily adapt to test tasks of different scales and complexities; and through a parallel signal processing mechanism, signals are sent and backchecked to multiple ECUs at the same time, which significantly improves the test efficiency of the multi-ECU system while reducing the test cost, and reduces interference and delay problems in signal transmission, thereby improving the accuracy and consistency of the test results.

[0124] Example 2

[0125] According to a second aspect of the present disclosure, a test bench for a multi-ECU system is provided, such as Figure 2 As shown, the test bench includes an actuator, several PEAK devices and several signal processors; each signal processor is connected to the actuator through a PEAK device; each signal processor is provided with multiple interfaces to be connected to multiple ECU systems to be tested;

[0126] The execution machine is used to create a Docker container matching each test project based on a number of pre-configured test projects; the test project includes a test task and a device identifier of at least one ECU system to be tested;

[0127] The PEAK device is used to obtain the frame data of the test task in each Docker container and convert the frame data into CAN signals;

[0128] The signal processor is used to process the CAN signal to obtain a target CAN signal including a device identifier, and transmit the target CAN signal to the ECU system to be tested according to the device identifier;

[0129] Among them, different target CAN signals are sent to the corresponding ECU system to be tested using a parallel signal processing mechanism;

[0130] The signal processor is also used to receive response data from each ECU system to be tested, and transmit the response data to the corresponding Docker container, so as to test the ECU system to be tested and obtain the test result of the ECU system to be tested.

[0131] Specifically, a docker image template (docker_temple) can be created on the execution machine. The image integrates the basic configuration for test automation (for example, an automation framework for executing CAN message stress test cases, USB drivers, python (a computer programming language) third-party basic modules, etc.). When multiple projects are stress tested at the same time, the test cases of different projects are stored in different paths of the execution machine. For example, the automation cases of project 1 are stored in the directory / home / dell / test / project1. Multiple ECU systems to be tested are connected to different PEAK devices. The PEAK devices are indirectly connected to the execution machine through the USB interface protocol. By running lsusb (a Linux (operating system) command line) on the execution machine, the unique identification of all PEAK devices on the execution machine can be viewed. For example, lsusb identifies a PEAK device with a unique number of Bus001Device 002:ID 0c72:0012PEAK System (identifying bus 001 with a device numbered 002).

[0132] When you need to run a test case for a project for stress testing, start a container based on the image version. When starting, you can bind multiple PEAK devices according to their numbers (identified by bus and device numbers), and specify the automated commands to be executed and the location where the data is stored on the execution machine after the execution is completed.

[0133] When the executor creates a container, the configuration information includes the following:

[0134] docker run-it--rm\#Automatically delete after exiting the container

[0135] --name container_project1\#Container command is project1

[0136] --device / dev / bus / usb / 001 / 002\#PEAK bound to the container (the execution machine number is 001 / 002)

[0137] --volume / home / dell / test / project1: / docker / testcase\#Execute the test case of project 1 passed into the container on the execution machine and map it to the container

[0138] --volume / home / dell / result / project1 / container_project1: / docker / result\#Automation results are saved to the execution machine

[0139] my_docker_image\#Create a template for the container

[0140] / bin / bash-c "cd / docker / testcase&&. / run_tests.sh> / docker / result / test_results.txt"#Execute the automated test case and save the automated data results

[0141] There is a core configuration command scheduling module in the execution machine, which maintains an environment configuration table of test projects, automation cases, PEAK devices, and automation commands. When two test projects are running at the same time, a PEAK device can be assigned to each test project. When only one test project is running, both PEAK devices can be assigned to the test project, and all ECU devices to be tested under the two PEAK devices can be used by the project. When creating a container, the execution machine creates different containers according to the information in the environment configuration table, thereby realizing dynamic customizable environment resources, high availability of ecu resources, and high availability of execution environment resources.

[0142] Since each container is a stress testing environment for a test project, it can be quickly deployed and destroyed in different test environments according to actual needs. Through concurrent control commands, multiple containers can be run in parallel, allowing multiple test projects to be tested at the same time. The container is automatically closed after the stress test is completed, further improving the overall test execution efficiency.

[0143] The functional implementation principles of each device in the test bench have been described in detail in the method embodiment. Please refer to the partial description of the method embodiment, and this embodiment will not be repeated here.

[0144] This embodiment realizes dynamic management of the test environment through containerized deployment technology, and can quickly adjust the test environment configuration according to actual needs, which not only simplifies the test preparation process, but also enables the system to have stronger scalability and can easily adapt to test tasks of different scales and complexities; and through a parallel signal processing mechanism, signals are sent and backchecked to multiple ECUs at the same time, which significantly improves the test efficiency of the multi-ECU system while reducing the test cost, and reduces interference and delay problems in signal transmission, thereby improving the accuracy and consistency of the test results.

[0145] Example 3

[0146] According to a third aspect of the present disclosure, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and used to run on the processor, wherein when the processor executes the computer program, the test method of the multi-ECU system described in the first aspect of the present disclosure is implemented.

[0147] Figure 6 This is a structural schematic diagram of an electronic device shown in an example embodiment of the present disclosure, the electronic device includes a memory, a processor, and a computer program stored in the memory and used to run on the processor, and when the processor executes the computer program, the test method of the multi-ECU system described in any of the above embodiments is implemented. Figure 6 The electronic device 30 shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0148] like Figure 6 As shown, the electronic device 30 may be in the form of a general-purpose computing device, for example, it may be a server device. The components of the electronic device 30 may include, but are not limited to: at least one processor 31, at least one memory 32, and a bus 33 connecting different system components (including the memory 32 and the processor 31).

[0149] The bus 33 includes a data bus, an address bus, and a control bus.

[0150] The memory 32 may include a volatile memory, such as a random access memory (RAM) 321 and / or a cache memory 322 , and may further include a read-only memory (ROM) 323 .

[0151] The memory 32 may also include a program tool 325 (or utility) having a set (at least one) of program modules 324, such program modules 324 including but not limited to: an operating system, one or more application programs, other program modules and program data, each of which or some combination may include an implementation of a network environment.

[0152] The processor 31 executes various functional applications and data processing by running the computer program stored in the memory 32, such as the test method of the multi-ECU system provided by any of the above embodiments.

[0153] The electronic device 30 may also communicate with one or more external devices 34 (e.g., keyboards, pointing devices, etc.). Such communication may be performed via an input / output (I / O) interface 35. Furthermore, the electronic device 30 may also communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via a network adapter 36. As shown, the network adapter 36 communicates with other modules of the electronic device 30 via a bus 33. It should be understood that, although not shown in the figure, other hardware and / or software modules may be used in conjunction with the electronic device 30, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID (disk array) systems, tape drives, and data backup storage systems, etc.

[0154] It should be noted that although several units / modules or sub-units / modules of the electronic device are mentioned in the above detailed description, this division is merely exemplary and not mandatory. In fact, according to the embodiments of the present disclosure, the features and functions of two or more units / modules described above can be embodied in one unit / module. Conversely, the features and functions of one unit / module described above can be further divided into multiple units / modules to be embodied.

[0155] Although the specific embodiments of the present disclosure are described above, those skilled in the art should understand that this is only an example, and the protection scope of the present disclosure is defined by the appended claims. Those skilled in the art may make various changes or modifications to these embodiments without departing from the principles and essence of the present disclosure, but these changes and modifications all fall within the protection scope of the present disclosure.

Claims

1. A method for testing a multi-ECU system, characterized in that: The test method includes: Based on a plurality of pre-configured test items, a Docker container matching each of the test items is created; the test items include a test task and a device identifier of at least one ECU system to be tested; Obtain frame data of the test task in each of the Docker containers, and convert the frame data into a CAN signal; Performing data processing on the CAN signal to obtain a target CAN signal, and transmitting the target CAN signal to the corresponding ECU system to be tested; Wherein, different target CAN signals are sent to the corresponding ECU system to be tested using a parallel signal processing mechanism; Receive response data of each of the ECU systems to be tested, add the device identification of the test ECU system to the response data, and transmit it to the corresponding Docker container to test the ECU system to be tested and obtain the test result of the ECU system to be tested.

2. The testing method according to claim 1, characterized in that: The step of performing data processing on the CAN signal to obtain a target CAN signal comprises: Filtering the CAN signal based on a preset filtering condition, and packaging the filtered CAN signal to generate the target CAN signal; The preset filtering condition includes at least one of a MAC address range filtering condition, a frame type filtering condition, and a data length filtering condition.

3. The testing method according to claim 2, characterized in that: The step of screening the CAN signal based on the preset filtering condition comprises: Monitor the CAN bus load and / or CAN signal delay to obtain monitoring data; According to the monitoring data, the preset filtering condition is updated; The CAN signal is filtered based on the updated preset filtering condition.

4. The testing method according to claim 1, characterized in that: The step of transmitting the target CAN signal to the corresponding ECU system to be tested comprises: Create a thread pool; Allocate a thread to each of the ECU systems to be tested according to the device identification; The target CAN signal is transmitted to the ECU system to be tested based on the thread.

5. The testing method according to claim 4, characterized in that: The step of transmitting the target CAN signal to the corresponding ECU system to be tested also includes: Monitor the signal queue of CAN bus; In response to the signal queue reaching a first threshold, determining at least one target ECU system to be tested according to the number of target CAN signals corresponding to each of the ECU systems to be tested in the signal queue; Adding the thread to the target ECU system to be tested; and / or, The step of transmitting the target CAN signal to the corresponding ECU system to be tested also includes: Allocate each thread of the same test item to a preset CAN channel for transmission; In response to the load rate of the preset CAN channel reaching a second threshold, at least one of the threads is switched to a standby CAN channel for transmission based on a preset adjustment rule.

6. The testing method according to claim 1, characterized in that: After the step of transmitting the target CAN signal to the corresponding ECU system to be tested, the testing method further includes: Monitoring the transmission status of the target CAN signal; In response to the transmission state being an abnormal state, re-executing the transmission operation of the target CAN signal and recording the abnormal state.

7. The testing method according to claim 1, characterized in that: The step of transmitting the target CAN signal to the corresponding ECU system to be tested comprises: Transmitting the target CAN signal to the ECU system to be tested at a preconfigured transmission rate; Wherein, the transmission rate of the CANFD network is greater than that of the standard CAN network.

8. The testing method according to any one of claims 1 to 7, characterized in that: The test method also includes: The device identification of each ECU system to be tested is generated by using a timestamp or a hash algorithm.

9. A test bench for a multi-ECU system, characterized in that: The test bench includes an actuator, a plurality of PEAK devices and a plurality of signal processors; each of the signal processors is communicatively connected to the actuator via one of the PEAK devices; each of the signal processors is provided with a plurality of interfaces to be respectively connected to a plurality of ECU systems to be tested; The execution machine is used to create a Docker container matching each of the pre-configured test items based on a plurality of pre-configured test items; the test items include a test task and a device identifier of at least one ECU system to be tested; The PEAK device is used to obtain the frame data of the test task in each of the Docker containers and convert the frame data into a CAN signal; The signal processor is used to perform data processing on the CAN signal to obtain a target CAN signal, and transmit the target CAN signal to the corresponding ECU system to be tested; Wherein, different target CAN signals are sent to the corresponding ECU system to be tested using a parallel signal processing mechanism; The signal processor is also used to receive response data of each of the ECU systems to be tested, add the device identification of the test ECU system to the response data, and transmit it to the corresponding Docker container to test the ECU system to be tested and obtain the test result of the ECU system to be tested.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and used to run on the processor, characterized in that: When the processor executes the computer program, the method for testing the multi-ECU system according to any one of claims 1 to 8 is implemented.

Images