Test method and device, storage medium and equipment

Abstract

The invention provides a test method and device, a storage medium and equipment, relates to the technical field of automobiles, and can realize automatic and full-scene test of a vehicle-mounted controller, cover complete test requirements by simulating normal and fault working conditions, improve test efficiency and reliability and reduce manual intervention cost. The method comprises the steps that test software is obtained, the test software is written into a first vehicle-mounted controller for testing, the vehicle-mounted controller is an electronic control unit which is integrated on a vehicle and has a control function, and after the first vehicle-mounted controller completes testing on the test software, the test software is written into the first vehicle-mounted controller. And automatically switching and writing the test software into a second vehicle-mounted controller for testing.

Description

Technical Field

[0001] This application relates to the field of automotive technology, and in particular to testing methods, apparatus, storage media and devices. Background Technology

[0002] With the rapid development of automotive electronics technology, the on-board controller, as the core control unit of the vehicle, has increasingly higher requirements for functional complexity and operational stability. It is necessary to conduct comprehensive testing to verify its functional effectiveness and fault tolerance in a simulated real vehicle network environment.

[0003] However, traditional vehicle controller testing methods rely heavily on manual operation for software flashing and test condition switching, which is not only inefficient but also prone to errors due to human intervention. Furthermore, fault simulation is often achieved by manually plugging and unplugging wires, covering only simple open-circuit and short-circuit scenarios. In addition, traditional testing methods lack the accuracy to simulate the vehicle network environment, making it difficult to match the communication scenarios of multiple controllers working collaboratively in a real vehicle. This results in discrepancies between test results and actual applications, failing to meet the current testing requirements for efficient, full-scenario, and high-reliability vehicle controllers. Summary of the Invention

[0004] This application provides testing methods, apparatus, storage media, and equipment that enable automated, full-scenario testing of vehicle controllers. By simulating normal and fault conditions, it covers complete testing requirements, improves testing efficiency and reliability, and reduces the cost of manual intervention.

[0005] To achieve the above objectives, this application adopts the following technical solution: In a first aspect, this application provides a testing method, which includes: acquiring test software, flashing the test software into a first vehicle controller for testing, the vehicle controller being an electronic control unit integrated into a vehicle and having control functions, and automatically switching and flashing the test software into a second vehicle controller for testing after the first vehicle controller has completed testing the test software.

[0006] Based on the above technical means, by automatically switching the test software from the first vehicle controller to the second vehicle controller for continuous testing, the automated switching of multi-vehicle controller testing is realized, reducing efficiency loss and operational errors caused by manual intervention, improving testing efficiency, and quickly covering multi-controller scenarios to meet the batch testing needs of vehicle controllers.

[0007] One possible approach is to automatically switch and flash the test software onto the second vehicle controller for testing. Specifically, this can be achieved by using a programmable relay to automatically switch and flash the test software onto the second vehicle controller for testing.

[0008] Based on the above technical means, the test software can be automatically switched and flashed between vehicle controllers through programmable relays, eliminating the need for manual plugging and unplugging of wires, reducing operation time and human error, ensuring the accuracy and stability of the switching process, supporting the automation of continuous testing processes for multiple controllers, and improving batch testing efficiency and result consistency.

[0009] Another possible approach is to automatically switch and flash the test software to the second vehicle controller based on a programmable relay. Specifically, this can be achieved by automatically switching and flashing the test software to the second vehicle controller based on the switching command received by the programmable relay.

[0010] Based on the above technical means, the switching command is received by the programmable relay, and the test software is automatically switched and flashed to the second vehicle controller. The command-based control ensures that the switching action is accurately triggered, avoids delays and misoperations caused by manual operation, realizes seamless connection of multi-vehicle controller testing, and improves the automation level of the test process and the efficiency of batch testing.

[0011] Another possible approach is to flash the test software into the first vehicle controller for testing. Specifically, this can be achieved by testing the test software flashed into the first vehicle controller based on the test instructions received by the programmable relay.

[0012] Based on the above technical means, test instructions are received and executed by the test software in the first vehicle controller through a programmable relay, thereby driving the automated test process with instructions and reducing errors and time consumption caused by manual operation.

[0013] Another possible approach is to test the test software flashed into the first vehicle controller based on the test command received by the programmable relay. Specifically, this can be achieved by performing a functional stability test on the test software flashed into the first vehicle controller under a power interruption condition based on the first power-off command received by the programmable relay.

[0014] Based on the above technical means, the first power failure command is received through a programmable relay to simulate the instantaneous power failure and test the stability of the software function. This avoids timing errors and inconsistencies with operation caused by manual simulation, ensures accurate reproduction of the instantaneous power failure scenario, and effectively verifies the software's ability to maintain its function during a sudden power failure.

[0015] Another possible implementation method is to test the test software flashed into the first vehicle controller based on the test command received by the programmable relay. Specifically, this can be implemented by: testing the restart and recovery performance of the test software flashed into the first vehicle controller after a continuous power interruption based on the second power-off command received by the programmable relay.

[0016] Based on the above technical means, a second power-off command is received through a programmable relay to simulate a continuous power interruption and test the software restart and recovery performance. This avoids timing deviations and operational inconsistencies caused by manually simulating power outages, effectively verifies the software's ability to recover its functions after a power outage, and improves the accuracy of test scenario reproduction and the reliability of results.

[0017] Another possible implementation method is to test the test software flashed into the first vehicle controller based on the test command received by the programmable relay. Specifically, this can be implemented by: testing the fault response under information line short circuit fault in the test software flashed into the first vehicle controller based on the information line short circuit command received by the programmable relay.

[0018] Based on the above technical means, a short-circuit command is received by a programmable relay to simulate a short-circuit fault and test the software fault response, effectively verifying the software's ability to detect, report, and tolerate short-circuit faults.

[0019] Another possible implementation method is to test the test software flashed into the first vehicle controller based on the test instructions received by the programmable relay. Specifically, this can be implemented by: based on the information line disconnection instruction received by the programmable relay, performing function maintenance test under information line disconnection fault and communication recovery test after information line disconnection fault on the test software flashed into the first vehicle controller.

[0020] Based on the above technical means, the programmable relay receives the information line disconnection command, accurately simulates the disconnection fault, and tests the software function maintenance and communication recovery capabilities. This effectively verifies the functional stability of the software when disconnected and the communication reliability after recovery, improves the accuracy of test scenario reproduction and the credibility of results, and ensures the robustness of the vehicle controller in dealing with line disconnection.

[0021] Another possible way to obtain the test software is to either read the test software from a pre-set local software repository or download the test software from a remote test management server.

[0022] Based on the above technical means, test software can be obtained through two channels: reading from the local software repository or downloading from the remote test management server. This avoids the risk of relying on a single channel, improves acquisition efficiency by reading locally, and adapts to the collaborative needs of multiple racks by downloading remotely, reducing manual transmission operations.

[0023] Secondly, this application provides a testing device, specifically including: an acquisition module, a communication module, and a testing module; the acquisition module is used to acquire test software; the communication module is used to flash the test software into a first vehicle controller for testing, the vehicle controller being an electronic control unit integrated into a vehicle and having control functions; the testing module is used to automatically switch and flash the test software into a second vehicle controller for testing after the first vehicle controller has completed testing the test software.

[0024] Thirdly, this application provides a computer-readable storage medium storing at least one computer program, which is loaded and executed by a processor to implement the above-mentioned test method.

[0025] Fourthly, this application provides an electronic device, comprising: a processor and a memory storing at least one computer program, wherein the at least one computer program is loaded and executed by the processor to implement the test method of the first aspect described above.

[0026] The solutions provided in the second to fourth aspects above are used to implement the method provided in the first aspect above, and their specific implementations will not be described in detail here. The technical effects corresponding to any implementation method of the solutions provided in the second to fourth aspects above can be found in the technical effects corresponding to any implementation method in the first aspect above, and will not be described in detail here.

[0027] It should be noted that any of the possible implementations of any of the above aspects can be combined, provided that the solutions do not contradict each other. Attached Figure Description

[0028] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0029] Figure 1 A schematic diagram of the architecture of a testing system provided in an embodiment of this application; Figure 2 A flowchart illustrating a testing method provided in an embodiment of this application; Figure 3 Hardware electrical schematic diagrams provided for embodiments of this application; Figure 4 Programmable relay programming logic diagram provided in the embodiments of this application; Figure 5 A test timing diagram provided for an embodiment of this application; Figure 6 This is a schematic diagram of the cloud software link provided in the embodiments of this application; Figure 7 This is a schematic diagram of a testing device structure provided in an embodiment of this application; Figure 8 This is a block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0030] In the embodiments of this application, in order to clearly describe the technical solutions of the embodiments of this application, the terms "first" and "second" are used to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and the terms "first" and "second" are not necessarily different. The technical features described by "first" and "second" have no sequential or size order.

[0031] In the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner to facilitate understanding.

[0032] In the embodiments of this application, at least one can also be described as one or more, and multiple can be two, three, four or more, and this application does not impose any restrictions.

[0033] It should be noted that the information (including but not limited to device information, personal information of the subject, etc.), data (including but not limited to data used for analysis, data stored, data displayed, etc.) and signals involved in this application are all authorized by the subject or fully authorized by all parties, and the collection, use and processing of related data must comply with relevant laws, regulations and standards.

[0034] For example, with the rapid development of automotive electronics technology, the on-board controller, as the core control unit of the vehicle, has increasingly higher requirements for functional complexity and operational stability. It is necessary to conduct comprehensive testing to verify its functional effectiveness and fault tolerance in a simulated real vehicle network environment.

[0035] In the current testing process for vehicle controllers, it is usually necessary to manually flash the test software to a single vehicle controller under test. After the test of that controller is completed, the process is manually switched to the next controller and the flashing test is repeated. This requires a lot of manual intervention, which is not only prone to errors due to differences in operation and poor test consistency, but also makes the process cumbersome and inefficient. It is difficult to quickly cover multi-controller test scenarios and cannot meet the actual needs of batch testing of vehicle controllers.

[0036] Based on this, this application provides a testing method that automatically switches the test software from the first vehicle controller to the second vehicle controller for continuous testing via a programmable relay. This achieves automated switching of testing multiple vehicle controllers, reduces efficiency loss and operational errors caused by manual intervention, improves testing efficiency, and can quickly cover multi-controller scenarios to meet the needs of batch testing of vehicle controllers.

[0037] The solutions provided by the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0038] The solution provided in this application can be applied to Figure 1 In the test system shown, such as Figure 1 The diagram shows the architecture of a test system, which includes a test bench controller 101, a programmable relay 102, and an on-board controller 103.

[0039] For example, Figure 1 The test bench controller 101 shown can be an industrial-grade embedded controller or an integrated test control unit. Its hardware configuration can support multi-protocol communication and multi-module collaboration, and can meet the needs of test program operation, data storage and rapid instruction processing.

[0040] The test bench controller 101 can store preset test plans, parse external test commands, and send control signals to the programmable relay 102. At the same time, it establishes a communication link with the vehicle controller 103 to complete the flashing of test software and the reception and analysis of test data.

[0041] The test bench controller 101 can run the test methods provided in this application independently, or it can be linked with an external human-computer interaction terminal or a cloud-based test management platform to realize visual monitoring of test progress, automatic generation of test reports, and traceability of historical data.

[0042] Optionally, the test bench controller 101 can integrate a data acquisition submodule to directly collect fault codes and operating status parameters fed back by the vehicle controller 103, without relying on external monitoring equipment, thus simplifying the system architecture.

[0043] Programmable relay 102 refers to an electrical control element that can control the on / off state of contacts through electrical signal commands and supports preset action logic. Its core characteristics are "command triggerable and action programmable". Unlike traditional manually operated programmable relays, it can accurately respond to the timing control requirements of test bench controller 101.

[0044] The programmable relay 102 can be a multi-channel vehicle-specific programmable relay module, such as having 8 independent control channels, corresponding to the power supply lines and information lines of the vehicle controller 103 respectively, and can simultaneously realize power on / off and line fault simulation.

[0045] Specifically, after receiving the instruction from the test bench controller 101, the programmable relay 102 will switch the contact state according to a preset timing sequence.

[0046] Optionally, the programmable relay 102 may have a status feedback function, which transmits the actual on / off status of the contacts back to the test bench controller 101 to ensure that the test bench controller can monitor the execution status in real time and avoid instruction execution deviation.

[0047] The vehicle controller 103 refers to an electronic control unit integrated into the vehicle and undertaking specific control functions, such as a body controller, power domain controller, and vehicle infotainment controller. It has a built-in processor, memory, and communication interface, and can receive and run the test software written by the test bench controller 101, and output operating data under simulated working conditions.

[0048] Specifically, the vehicle controller 103, as the object under test, receives test software (such as through CAN bus or Ethernet) issued by the test bench controller 101 during the test process, runs the software under the working conditions simulated by the programmable relay 102, and feeds back its own functional status to the test bench controller 101 through the communication link.

[0049] Optionally, the vehicle controller 103 can support a unified diagnostic service protocol, which facilitates the test bench controller 101 to read its internal fault information and control software operating mode through diagnostic commands, thereby improving the integrity of test data and the controllability of the test process.

[0050] Specifically, the test bench controller 101 is connected to the programmable relay 102 via a DC power supply harness to provide operating power to the programmable relay. The programmable relay 102 is connected to the vehicle controller 103 via a dedicated vehicle wiring harness to control its power input and information line connection. The test bench controller 101 and the programmable relay 102 establish a control command transmission link via a bus. The test bench controller 101 and the vehicle controller 103 are connected via a bus or vehicle Ethernet to realize the flashing of test software.

[0051] Figure 2This is a flowchart illustrating a testing method provided in an embodiment of this application. The method can be executed by a test bench controller, which can be... Figure 1 The test bench controller 101 in this application. The test method provided in this embodiment can be applied to batch functional testing of vehicle controllers before mass production and delivery, multi-model compatibility testing of vehicle controllers during the R&D stage, and reliability verification of vehicle software under complex working conditions. It is especially suitable for scenarios that require unified standard testing of multiple vehicle controllers of the same or different types.

[0052] like Figure 2 As shown, the testing method provided in this application embodiment may include: S201: Test bench controller acquires test software.

[0053] In some embodiments, the test software is read from a preset local software repository, or the test software is downloaded from a remote test management server.

[0054] Specifically, if the test software is read from a preset local software repository, which can be integrated into the built-in storage unit of the test bench controller or an external industrial-grade storage device, the test bench controller will first match the model of the vehicle controller under test through a preset path, call the corresponding version of the test software, and at the same time verify the integrity of the software to avoid test abnormalities due to software corruption. If the test software is downloaded from a remote test management server, the test bench controller will establish an encrypted communication link with the server via Ethernet, and automatically pull the test software to the local temporary storage area according to the software download instruction issued by the server. After the download is completed, the integrity verification is also performed to ensure that the software can be flashed normally.

[0055] The preset path refers to the predefined structured directory rules or index path in the test bench controller, which is used to accurately associate the vehicle controller model with the corresponding test software storage location. It is usually constructed according to the hierarchical logic of controller type-hardware model-software version.

[0056] For example, the path format for local storage might be " / local_repo / controller_type / [model identifier] / software_version / [software file name]", where "controller_type" distinguishes the type of vehicle controller, "model identifier" corresponds to the specific hardware model, and "software_version" indicates the software version number.

[0057] The test bench controller can read the hardware identifier of the vehicle controller under test, and directly traverse the directory according to this preset path to quickly locate and call the matching test software without manual intervention in path finding, ensuring the accuracy and efficiency of software calling.

[0058] Optionally, operators can manually specify the test software version that matches the model of the vehicle controller under test from the software list in the local warehouse or remote server through the human-machine interface terminal. Alternatively, the test bench controller can read the hardware identifier of the vehicle controller, automatically associate and obtain the corresponding test software, thereby reducing errors in manual selection.

[0059] Optionally, remote downloads can also support resuming interrupted downloads. If the download is interrupted due to network fluctuations, it can resume from the point of interruption after the connection is restored, avoiding repeated transmissions and wasting time.

[0060] Test software refers to the core software to be tested, namely the running program of the vehicle controller, which contains the logic code that implements its specific functions and is the core object of testing and verification.

[0061] Specifically, the test software includes a functional execution layer and a test adaptation layer.

[0062] The functional execution layer contains the core logic code of the vehicle controller. For example, the test software for the body controller includes the headlight PWM adjustment algorithm, the door locking logic judgment code, and the wiper speed adjustment program. The test software for the intelligent driving domain controller includes the sensor data fusion algorithm, the path planning decision logic, and the emergency braking trigger code, which directly determine the functional implementation of the vehicle controller.

[0063] The test adaptation layer has a built-in test case set, which includes response judgment criteria for scenarios such as power interruption and line fault. It also includes a communication interface adaptation layer that supports multiple protocols such as Ethernet and can convert the running state of the function execution layer into a format that the test bench controller can parse. The third is the flashing boot program, which is responsible for establishing an initial connection with the test bench controller and completing pre-flashing operations such as software partition erasure and verification value comparison to ensure that the firmware can be safely written to the storage unit of the vehicle controller.

[0064] Optionally, the test software can support dynamic test logic loading. That is, when the core function firmware is fixed, the test adaptation layer can dynamically pull new test cases from the SVN repository without recompiling the entire software package, thus improving the efficiency of test scenario expansion. S202: The test bench controller flashes the test software into the first vehicle controller for testing.

[0065] Among them, the vehicle controller refers to the electronic control unit integrated into the vehicle and having control functions.

[0066] Specifically, the test bench controller establishes a flashing connection with the first vehicle controller via the vehicle bus. It first sends an erase command to clear its original storage partition, then transmits the test software in blocks and writes it into the storage unit according to a preset protocol. After the flashing is completed, a verification command is sent to confirm the integrity of the software, start the test process, collect the operating data of the first vehicle controller in real time, and simulate various working conditions through programmable relays to verify the performance of the test software.

[0067] The preset protocol refers to the standardized software flashing communication protocol in the automotive field, which is used to standardize the flashing command interaction, data transmission format and verification rules between the test bench controller and the vehicle controller.

[0068] The first vehicle controller refers to the first vehicle controller currently being tested. It can be the first unit under test in the batch test queue. It may be the same model or a different model as the subsequent second and third vehicle controllers. It is the starting node of the multi-controller automated testing process.

[0069] The test commands include: first power-off command, second power-off command, information line short circuit command, information line open circuit command, etc., which are generated by the test bench controller according to the preset test plan and sent to the programmable relay.

[0070] The first power-off command is a control command issued by the test bench controller to the programmable relay to simulate a brief power interruption. It contains a clear power-off duration parameter and triggers the programmable relay to disconnect the power input of the first vehicle controller within a specified duration.

[0071] Functional stability testing under power interruption conditions refers to the test to verify whether the flashed test software can maintain stable operation of its core functions after a brief power interruption. That is, after the power is restored, whether the vehicle controller can start normally, whether the key functions are normal, and whether unexpected fault codes are generated.

[0072] Specifically, after receiving the first power-off command, the programmable relay disconnects the power circuit of the first vehicle controller for the duration set by the command. After the duration ends, the power supply is restored immediately. The test bench controller synchronously records the controller status at the time of power-off and the time of power restoration, collects the communication messages, function execution results and internal fault codes after restoration, and compares them with the preset pass standard to determine the software stability.

[0073] Among them, the internal fault code refers to the digital code generated and stored according to industry standards when the first vehicle controller detects a functional abnormality through its own diagnostic module during the operation of the test software.

[0074] For example, "P0607" represents a performance failure of the internal control module, and "U0100" represents an interruption in communication with the engine control module. These codes can be read by the test bench controller through diagnostic commands and serve as a key basis for determining software stability.

[0075] Preset pass criteria refer to a set of quantitative indicators and rules that are pre-set before testing to determine the stability of software under power interruption conditions.

[0076] For example: "CAN bus communication is re-established within ≤200ms after power is restored", "No new U-type fault codes", "Core function trigger response time ≤500ms", "The above conditions are met in 3 consecutive transient interruption tests", etc.

[0077] Optionally, the test can support multiple settings for transient interruption duration. The test bench controller can automatically execute transient interruption tests of different durations in a preset sequence to fully verify the stability of the software under different levels of power disturbance.

[0078] Optionally, the test can be set to repeat the test a certain number of times to investigate occasional functional abnormalities.

[0079] In some embodiments, based on a second power-off command received by a programmable relay, the test software written to the first vehicle controller is subjected to a restart and recovery performance test under a continuous power interruption condition.

[0080] The second power-off command is a control command issued by the test bench controller to the programmable relay to simulate a longer power interruption. Unlike the brief interruption of the first power-off command, it contains a clear parameter for the duration of the continuous power-off, such as 1 minute, 5 minutes, 30 minutes, etc., which triggers the programmable relay to continuously disconnect the power input of the first vehicle controller within the specified duration, simulating the scenario of the vehicle being turned off for a long time or the power being completely interrupted.

[0081] The restart and recovery performance test after a continuous power outage refers to the test that verifies whether the flashed test software can restart normally and fully restore all functions after a long period of power outage and power restoration. This includes: the integrity of the restart process, data consistency, functional reproducibility, and fault self-healing ability.

[0082] Specifically, after receiving the second power-off command, the programmable relay keeps the power circuit of the first vehicle controller disconnected for the duration set by the command. After the duration ends, the power supply is restored. The test bench controller immediately records the restart start time, tracks the controller initialization process, collects the system status, stored data and function execution results after restart, compares them with the preset pass standard, and determines the restart and recovery performance of the software.

[0083] Optionally, the second power-off command can be to disconnect the constant power of KL30 separately, disconnect the ignition power of KL15 separately, or disconnect both simultaneously, to verify the impact of different power interruption modes on restart and recovery.

[0084] For example, when KL15 is disconnected alone, the controller only loses its operating power, while KL30 remains in standby mode, testing the recovery logic from hibernation to wake-up; when KL30 and KL15 are disconnected at the same time, the controller is completely powered off, testing the cold start recovery capability.

[0085] Optionally, the second power-off command can be a "power-off-restart" loop test, such as three consecutive "power off for 5 minutes, restart, run for 10 minutes".

[0086] For example, the test bench controller can read data from environmental sensors. If the ambient temperature is detected to exceed a threshold, a second power-off command, such as KL30 & KL15, 5min, is sent to the programmable relay to test the controller's cold-start recovery performance after a prolonged power outage in a high-temperature environment.

[0087] Optionally, gradient duration testing can be supported, i.e., execution is performed in increments, such as from 1 minute to 5 minutes to 30 minutes, to verify the differences in the software's recovery capabilities under different durations of continuous power outage.

[0088] In some embodiments, based on the information line short-circuit command received by the programmable relay, the test software written into the first vehicle controller is subjected to a fault response test under an information line short-circuit fault.

[0089] For example, based on the information line disconnection command received by the programmable relay, the test software flashed into the first vehicle controller is subjected to function maintenance test under information line disconnection fault and communication recovery test after information line disconnection fault.

[0090] Among them, the information line short circuit command refers to the control command issued by the test bench controller to the programmable relay to simulate a short circuit fault in the vehicle information transmission line.

[0091] The information line short circuit command contains explicit short circuit parameters, such as the target line identifier and the duration of the short circuit. It triggers a programmable relay to close the short circuit contact of the corresponding line, simulating a short circuit scenario caused by damage to the line insulation layer during vehicle operation.

[0092] Specifically, the fault response test under short circuit fault of information line refers to the test to verify whether the flashed test software can quickly detect the fault, generate the correct fault code, execute the protection logic and maintain the normal operation of non-associated functions when a short circuit occurs in the information line.

[0093] During the test, the programmable relay short-circuits the target circuit according to the instruction. The test bench controller synchronously monitors the fault detection timeliness, fault code generation accuracy, protection measures effectiveness, and whether functions independent of the circuit are normal. Finally, the results are compared with preset standards to determine the software's fault response capability.

[0094] Optionally, the test can support multi-line composite short-circuit scenarios to verify the software's response logic under complex faults.

[0095] Optionally, a short-circuit recovery loop can be set to test the software's fault handling stability and avoid the randomness of a single test.

[0096] The information line disconnection command refers to the control command issued by the test bench controller to the programmable relay to simulate an open circuit fault in the vehicle information transmission line.

[0097] The information line disconnection command includes the target line identifier and the duration of the disconnection, triggering a programmable relay to disconnect the corresponding line's connection contacts, simulating scenarios such as loose line joints and broken wires.

[0098] The function maintenance test under information line open circuit fault verifies whether the test software can maintain normal local function operation without relying on the line when the line is open.

[0099] Communication recovery testing verifies whether the software can automatically re-establish the communication connection and restore data transmission capability after a line break is restored.

[0100] Specifically, the programmable relay disconnects the target information line according to the instruction. During the circuit break, the test bench controller collects the execution results of non-associated functions and fault diagnosis behavior. After the circuit break ends, the programmable relay restores the line connection, and the test bench continues to monitor the communication recovery time and data consistency.

[0101] S203: After the test software is tested by the first vehicle controller, the test bench controller will automatically switch and flash the test software to the second vehicle controller for testing.

[0102] In some embodiments, test software is automatically switched and flashed onto a second vehicle controller for testing, based on a programmable relay.

[0103] For example, based on the switching command received by the programmable relay, the test software is automatically switched and flashed into the second vehicle controller for testing.

[0104] Specifically, after the first vehicle controller completes its test, the test bench controller automatically generates a switching command and sends it to the programmable relay. The programmable relay parses the command and executes it step-by-step according to preset logic: first, it disconnects all lines connected to the first vehicle controller; after a 500ms delay, it closes the power and communication lines corresponding to the second vehicle controller, establishing a physical connection. The test bench controller automatically completes a communication handshake with the second vehicle controller, reuses the flashing logic, and after flashing, directly starts the same test plan as the first vehicle controller, achieving a seamless transition from the first to the second controller without manual intervention.

[0105] The second vehicle controller refers to the next test object that enters the testing phase according to the preset test sequence after the first vehicle controller test process is completed.

[0106] The second vehicle controller can be a batch product of the same model as the first vehicle controller, or it can be a controller with different functions. It is a subsequent node in the multi-controller automated testing chain, supporting batch testing or multi-category testing needs.

[0107] Automatic switching and flashing refers to the fully automated operation from the end of the first vehicle controller test to the start of the second vehicle controller test, without the need for manual plugging and unplugging of wiring harnesses, manual triggering of flashing, or configuration of test parameters. This process is led by the test bench controller, which works in conjunction with programmable relays to complete the physical link switching and simultaneously execute the test software flashing and test process initiation.

[0108] The switching command is a control signal issued by the test bench controller to the programmable relay to trigger the physical link switching from the first vehicle controller to the second vehicle controller.

[0109] The switching instruction includes the line identifier of the first controller, the line identifier of the second controller, the switching interval duration, and the check code, which is used to guide the programmable relay to accurately execute the line switching action.

[0110] Specifically, the switching instruction adopts a binary frame format, and its structure includes: 1 byte "instruction type", 2 bytes "first controller line mask", 2 bytes "second controller line mask", 1 byte "switching delay", and 1 byte "CRC check".

[0111] Optionally, after receiving the instruction, the programmable relay first checks the CRC to ensure the instruction is complete, then disconnects the power and communication lines of the first controller by pressing the mask, waits for the delay time, closes the corresponding line of the second controller by pressing the mask, and informs the test bench controller through a feedback frame. After receiving the feedback, the test bench controller immediately starts communication and flashing with the second vehicle controller to ensure seamless connection between switching and testing.

[0112] Figure 3This is a hardware electrical schematic diagram provided in the embodiments of this application.

[0113] like Figure 3 As shown, the hardware electrical schematic test bench is an architecture that uses programmable relays to automatically control the power and communication lines of multiple vehicle controllers.

[0114] Specifically, the left side is the control and signal output terminal of the test bench, which is connected to the programmable relay module through an interface to send control commands such as power on / off and line switching to the programmable relay; The programmable relay module contains multiple output channels, each corresponding to a different type of line: power lines, such as KL30 and KL15, are used to control the power input of each ECU; communication lines, such as CAN_H and CAN_L lines of the CAN bus, are used to establish a communication link between the test bench and the ECU for flashing and diagnosis; ECU1, ECU2, and ECU3 on the right are the vehicle controllers to be tested, which can correspond to the first, second, and third vehicle controllers. Each ECU obtains power through the power lines allocated by the programmable relays and interacts with the test bench through the communication lines.

[0115] Specifically, the architecture allows the test bench to automatically switch which ECU to establish a power and communication connection with by sending commands to programmable relays, thereby realizing automated flashing and testing process switching between multiple ECUs.

[0116] KL30 refers to the constant power supply in the vehicle's electrical system, which is a line that continuously provides power to the vehicle without being controlled by the ignition switch, and is used to provide basic standby power for equipment such as vehicle controllers.

[0117] KL15 refers to the power supply in the vehicle's electrical system controlled by the ignition switch. This line only supplies power when the ignition switch is in the "ON" or "START" position, and mainly provides working power for the vehicle's controllers, instruments, and other equipment that need to be activated during vehicle operation.

[0118] Specifically, as shown in the figure, the line continuity status corresponding to different test commands is as follows: First power-off command: The programmable relay disconnects the KL30 or KL15 line of ECU1, while other power lines remain closed; after a short period, the disconnected power line is immediately closed to restore power supply, while the CAN_H and CAN_L lines of ECU1 remain closed, and all power and communication lines of other ECUs (ECU2 and ECU3) remain disconnected.

[0119] The CAN_H line refers to the high-level differential signal line in the CAN bus. It is one of the core lines used to transmit differential signals in the vehicle communication system. Its voltage range is typically from 2.5V when the bus is idle to 3.5V when the signal is dominant. Its main function is to work with the CAN_L line. Through the voltage difference between the two, in the dominant state, CAN_H is about 2V higher than CAN_L to transmit diagnostic commands, flashing data, function control signals, and operating status messages such as fault codes and parameter feedback between the vehicle controller, such as ECU1, and the test bench. In the test scenario of the first power-off command, the CAN_H line remains closed to ensure that after the power interruption is restored, the test bench can receive the communication data fed back by ECU1 in real time, verifying the communication recovery capability of the software.

[0120] The CAN_L line refers to the low-level differential signal line in the CAN bus. Together with the CAN_H line, it forms a complementary differential signal transmission pair. Its voltage range is typically 2.5V to 1.5V. During operation, it exhibits an inverse voltage change compared to the CAN_H line; when CAN_H is high, CAN_L is low. This differential signal transmission method effectively resists electromagnetic interference in the vehicle environment, ensuring stable data transmission. In the first power-off command test, CAN_L and CAN_H remain synchronously closed, providing a complete communication link between the test bench and ECU1, ensuring uninterrupted data exchange during the test.

[0121] Second power-off command: The programmable relay simultaneously disconnects the KL30 and KL15 lines of ECU1 and remains disconnected for a set time. After the time expires, the line closes to restore power. The CAN_H and CAN_L lines of ECU1 can remain closed or disconnect synchronously with the power supply. All lines of other ECUs: ECU2 and ECU3 remain disconnected.

[0122] Information line short circuit command: KL30 and KL15 lines of ECU1 remain closed to ensure that ECU1 is in working state to respond to short circuit faults. The programmable relay closes the short circuit contacts of CAN_H and CAN_L lines of ECU1, causing a short circuit in the communication line; the short circuit duration is specified. After the short circuit ends, the short circuit contacts are opened to restore normal communication. All lines of other ECUs: ECU2 and ECU3 remain open.

[0123] Information line disconnection command: KL30 and KL15 lines of ECU1 remain closed, and the programmable relay disconnects CAN_H or CAN_L lines of ECU1 (or both simultaneously), causing the communication link to be interrupted. After the disconnection period (e.g., 10 seconds), the closed line restores communication. All lines of other ECUs: ECU2 and ECU3 remain disconnected.

[0124] Switching command: The programmable relay disconnects all power and communication lines of ECU1, completely isolating it from the test bench. After ECU1 is disconnected, the programmable relay closes the KL30 and KL15 power lines and CAN_H and CAN_L communication lines of ECU2, establishing a physical connection between the test bench and ECU2. All lines of other ECUs, including ECU3, remain disconnected.

[0125] Figure 4 This is a programming logic diagram of a programmable relay provided in an embodiment of this application. The programming logic of the programmable relay can be executed by a programmable relay, which can be... Figure 1 The programmable relay 102 in the middle.

[0126] like Figure 4 As shown, Figure 4 As shown, the execution flow of the programmable relay programming logic is as follows: S401: The VT2516A module first sends a high-level signal.

[0127] The VT2516A is a multi-functional digital I / O module designed specifically for testing vehicle controllers. It can connect to up to 16 digital signals and uses built-in relays to achieve functions such as circuit on / off control, short circuit / open circuit simulation, and PWM signal generation.

[0128] exist Figure 4 In the programming logic, the VT2516A module drives the programmable relay to engage / disengage by outputting high / low level signals, thereby controlling the ground connection status between the test bench and the vehicle controller. It is one of the core control modules for realizing "automatic switching of vehicle controller and simulation of working condition faults".

[0129] A high-level signal provides driving power to the electromagnetic coil of the programmable relay, enabling the programmable relay to enter a ready-to-engage state.

[0130] S402: Triggers the programmable relay to perform an engaging action, causing the programmable relay contacts to close.

[0131] Triggering the programmable relay to perform an engaging action closes the target contact of the programmable relay, thereby initially establishing a physical circuit path between the test bench and the vehicle controller.

[0132] S403: The ground wire of the test bench is connected to the ground wire of the vehicle controller and enters the connection state.

[0133] At this point, the system enters a stable electrical connection state.

[0134] S404: Determine if the switching conditions are met.

[0135] If the switching conditions are not met, continue to maintain the current connection state; if the switching conditions are met, execute S405.

[0136] S405: The VT2516A module sends a low-level signal.

[0137] S406: Programmable relay disconnected.

[0138] Disconnecting the programmable relay separates the programmable relay contacts, restoring the isolation between the test bench ground wire and the vehicle controller ground wire.

[0139] Figure 5 This is a test timing diagram provided in an embodiment of this application.

[0140] like Figure 5 As shown in the diagram, this test timing diagram presents a 24-hour automated continuous test process for multiple vehicle controllers. The specific process is as follows: hardware connection 501, test 502 on the vehicle controller.

[0141] Hardware connection 501 establishes a physical link between the test bench and the on-board controller under test.

[0142] The 502 test on the vehicle controller is performed through queue scheduling, sequentially testing the 1st, 2nd, 3rd, and 4th vehicle controllers. It supports 24-hour uninterrupted operation to maximize testing efficiency. The 1st, 2nd, 3rd, and 4th controllers here are for illustrative purposes and do not represent the actual number.

[0143] Specifically, when the "first vehicle controller is being tested", the second, third and fourth vehicle controllers are in the "test pending" state, forming a "serial + queue" scheduling mechanism. After the previous controller is tested, it automatically flows to the next controller to be tested, ensuring that the testing process of multiple devices is continuous and uninterrupted.

[0144] For each vehicle controller, the testing process includes the following key steps: local test configuration 503, cloud test configuration 504, obtaining and automatically flashing the software 505, configuring software parameters 506, executing the test 507, uploading test results and data to the cloud 508, and pushing test results 509.

[0145] Specifically, the local test configuration 503 involves setting basic test parameters locally on the test bench.

[0146] A 504 error in cloud-based test configuration refers to the cloud-based test management system uniformly configuring and setting parameters for the current vehicle controller's test process based on a global test strategy, and coordinating and verifying with the local test configuration.

[0147] The "Get and Automatically Flash Software 505" option involves flashing the test software into the current vehicle controller.

[0148] Configuring software parameter 506 involves setting the functional logic, operating condition thresholds, etc., required for testing.

[0149] The 507 test simulates various operating conditions and collects operational data according to a preset plan.

[0150] Uploading test results and data to the cloud (508) means synchronizing test data and results to cloud storage.

[0151] Pushing test results 509 means pushing the final results to the target system or personnel.

[0152] Figure 6 This is a schematic diagram of the cloud software link provided in the embodiments of this application.

[0153] like Figure 6 As shown, the vehicle controller software to be tested is released on the cloud platform. After the cloud detects the new software, the software is automatically upgraded, and the test bench or vehicle controller is automatically triggered. The system automatically starts the full-process test task of the vehicle controller. During the test, the data such as the vehicle controller's operating parameters, fault response, and function execution results are collected and uploaded to the cloud for centralized storage and management. After the cloud analyzes and integrates the data, the results are pushed to the target system or relevant personnel.

[0154] This application also provides a testing apparatus for implementing the above-described method embodiments.

[0155] like Figure 7 The schematic diagram of the testing device shown indicates that the testing device may include: an acquisition module 701, a communication module 702, and a testing module 703. The acquisition module 701 is used to perform... Figure 2 In the illustrated method, the operation of S201 is executed by the communication module 702. Figure 2 In S202, test module 703 is used to execute Figure 2 S203.

[0156] This application embodiment can divide the testing device into functional modules according to the above method embodiment. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0157] Figure 8 This is a block diagram of an electronic device provided in an embodiment of this application. (For example...) Figure 8 As shown, the electronic device includes, but is not limited to, a processor 801 and a memory 802.

[0158] The memory 802 described above is used to store the executable instructions of the processor 801. It is understood that the processor 801 is configured to execute instructions to implement the testing method in the above embodiments.

[0159] It should be noted that those skilled in the art will understand that Figure 8 The electronic device structure shown does not constitute a limitation on the electronic device; the electronic device may include, but is not limited to, other electronic devices. Figure 8 This may indicate more or fewer components, or combinations of certain components, or different component arrangements.

[0160] The processor 801 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs and / or modules stored in the memory 802, and by calling data stored in the memory 802, it performs various functions and processes data, thereby providing overall monitoring of the electronic device. The processor 801 may include one or more processing units. Optionally, the processor 801 may integrate an application processor and a modem processor. The application processor mainly handles the operating system, user interface, and applications, while the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 801.

[0161] The memory 802 can be used to store software programs and various data. The memory 802 may primarily include a program storage area and a data storage area. The program storage area may store the operating system, application programs required by at least one functional module (such as a determination unit, processing unit, etc.), etc. Furthermore, the memory 802 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0162] This application also provides a computer-readable storage medium storing at least one computer program, which is loaded and executed by a processor to implement the test methods provided in the above-described method embodiments.

[0163] Through the above description of the implementation methods, those skilled in the art will clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the module can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, modules, and units described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0164] The method steps in this embodiment can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary embodiment couples a storage medium to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Additionally, the ASIC can reside in a network device. Alternatively, the processor and storage medium can exist as discrete components in the network device. In the above embodiments, implementation can be entirely or partially achieved through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented entirely or partially as a computer program product. A computer program product includes one or more computer programs or instructions. When a computer program or instruction is loaded and executed on a computer, all or part of the processes or functions of the embodiments of this application are performed. The computer may be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, or other programmable module. The computer program or instructions may be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, a computer program or instructions may be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium may be any available medium that a computer can access, or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; or an optical medium, such as a digital video disc (DVD); or a semiconductor medium, such as a solid-state drive (SSD). The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0165] Since the testing device, computer-readable storage medium, and computer program product in the embodiments of the present invention can be applied to the above methods, the technical effects obtained can also be referred to the above method embodiments. The embodiments of the present invention will not be repeated here. The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims. The method steps in this embodiment can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Additionally, the ASIC can reside in a network device. Alternatively, the processor and storage medium can exist as discrete components in the network device. In the above embodiments, implementation can be entirely or partially achieved through software, hardware, firmware, or any combination thereof. When implemented in software, it can be entirely or partially implemented as a computer program product. A computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, all or part of the processes or functions of the embodiments of this application are performed. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, or other programmable module. The computer program or instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another; for example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. Computer-readable storage media can be any available medium that a computer can access, or a data storage device such as a server or data center that integrates one or more available media.The usable medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; it can also be an optical medium, such as a digital video disc (DVD); or it can be a semiconductor medium, such as a solid-state drive (SSD). The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the scope of the technology disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A test method characterized by, The method comprises: acquiring test software; writing the test software into a first vehicle-mounted controller for testing, the vehicle-mounted controller being an electronic control unit integrated in a vehicle and having a control function; after the first vehicle-mounted controller completes testing of the test software, automatically switching the test software to be written into a second vehicle-mounted controller for testing.

2. The method of claim 1, wherein, The automatically switching the test software to be written into a second vehicle-mounted controller for testing based on a programmable relay comprises:

3. The method of claim 2, wherein, based on a switching instruction received by the programmable relay, automatically switching the test software to be written into a second vehicle-mounted controller for testing.

4. The method of claim 1, wherein, The writing the test software into a first vehicle-mounted controller for testing comprises: based on a test instruction received by a programmable relay, testing the test software written into the first vehicle-mounted controller.

5. The method of claim 4, wherein, The testing the test software written into the first vehicle-mounted controller based on a test instruction received by a programmable relay comprises: based on a first power-off instruction received by the programmable relay, testing the test software written into the first vehicle-mounted controller for function stability in a power instantaneous-off condition.

6. The method of claim 4, wherein, The testing the test software written into the first vehicle-mounted controller based on a test instruction received by a programmable relay comprises: based on a second power-off instruction received by the programmable relay, testing the test software written into the first vehicle-mounted controller for restart recovery performance after a power continuous-off condition.

7. The method of claim 4, wherein, The testing the test software written into the first vehicle-mounted controller based on a test instruction received by a programmable relay comprises: based on an information line short-circuit instruction received by the programmable relay, testing the test software written into the first vehicle-mounted controller for fault response in an information line short-circuit fault.

8. The method of claim 4, wherein, The testing the test software written into the first vehicle-mounted controller based on a test instruction received by a programmable relay comprises: based on an information line open-circuit instruction received by the programmable relay, testing the test software written into the first vehicle-mounted controller for function maintenance in an information line open-circuit fault and communication recovery after the information line open-circuit fault.

9. The method of claim 1, wherein, The acquiring test software comprises: reading the test software from a preset local software warehouse; or, downloading the test software from a remote test management server.

10. A test device, characterized by The device comprises an acquisition module, a communication module and a test module; the acquisition module is configured to acquire test software; the communication module is configured to write the test software into a first vehicle-mounted controller for testing, the vehicle-mounted controller being an electronic control unit integrated in a vehicle and having a control function; the test module is configured to, after the first vehicle-mounted controller completes testing of the test software, automatically switch the test software to be written into a second vehicle-mounted controller for testing.

11. A computer readable storage medium, characterized in that, The storage medium stores a computer program, and the computer program is executed by a processor to implement the method in any one of claims 1-9.

12. An electronic device, comprising: Comprising: a processor; a memory storing a computer program; when the computer program is executed by the processor, the method in any one of claims 1-9 is implemented.

Images