A vehicle controller testing method and related apparatus

Abstract

The application discloses a vehicle controller testing method and related device, and relates to the field of vehicle testing, which writes the interface code program in the software program of the obtained to-be-tested controller into the code calibration area of the to-be-tested controller. The debugging interface tool can monitor the sending message and the receiving message of the to-be-tested controller through the code calibration area, and obtain the signal value of the sending message and the signal value of the receiving message of the to-be-tested controller when running the software program. On the basis, the signal value in the message received by the receiver when the to-be-tested controller is the sender and the signal value in the message sent by the sender when the to-be-tested controller is the receiver are combined to verify whether there is an error when the to-be-tested controller sends the message and receives the message, so that the developer can find the problems of the controller in time and repair the problems, and the accuracy and reliability of the message transmission are ensured.

Description

Technical Field

[0001] This application relates to the field of vehicle testing technology, and in particular to a vehicle controller testing method and related apparatus. Background Technology

[0002] As vehicles integrate increasingly sophisticated functions, the number of messages transmitted through the vehicle's CAN network is also growing rapidly. Ensuring the integrity and accuracy of these messages during transmission is therefore crucial. This requires ensuring that each electronic control unit (ECU) operates correctly during message sending and receiving, thus preventing disruptions to message generation and parsing.

[0003] Therefore, how to test each electronic control unit to ensure the reliability of message transmission in the CAN network has become an urgent technical problem to be solved. Summary of the Invention

[0004] In view of the above problems, this application provides a vehicle controller testing method and related apparatus to improve the stability and reliability of message transmission. The specific solution is as follows:

[0005] The first aspect of this application provides a vehicle controller testing method, including:

[0006] Obtain the interface code program from the software program of the controller under test;

[0007] Write the interface code program into the code calibration area of ​​the controller under test;

[0008] The debugging interface tool is invoked to obtain the first signal value and / or the second signal value of the controller under test when running the software program from the code calibration area. The first signal value is the signal value carried in the message sent by the controller under test as the sender, and the second signal value is the signal value carried in the message received by the controller under test as the receiver.

[0009] The controller under test is verified based on the first judgment result and / or the second judgment result. The first judgment result is the judgment result of whether the first signal value and the third signal value are consistent. The second judgment result is the judgment result of whether the second signal value and the fourth signal value are consistent. The third signal value is the signal value in the message received by the message receiver when the controller under test is the sender. The fourth signal value is the signal value in the message sent by the message sender when the controller under test is the receiver.

[0010] In one possible implementation, when the controller under test sends a message as a sender, it further includes:

[0011] The debugging interface tool is invoked to adjust the signal values ​​in the current message according to the signal adjustment strategy before sending it.

[0012] The first judgment result also includes: a judgment result on whether the adjusted signal value is consistent with the third signal value.

[0013] In one possible implementation, when the controller under test receives the message as a receiver, it further includes:

[0014] When the debugging interface tool is invoked to carry a verification message in the received message, the corresponding signal value in the received message is obtained.

[0015] In one possible implementation, verifying the controller under test based on the first judgment result and the second judgment result includes:

[0016] When the first signal value and the second signal value are obtained, if the first signal value and the third signal value are consistent, and the second signal value and the fourth signal value are consistent, then the verification is determined to be successful.

[0017] If the first signal value and the third signal value are consistent when only the first signal value is obtained, the verification is deemed successful.

[0018] If the second signal value and the fourth signal value are consistent when only the second signal value is obtained, the verification is deemed successful.

[0019] In one possible implementation, before writing the interface code program into the code calibration area of ​​the controller under test, the method further includes:

[0020] Determine whether the message information in the interface code program is consistent with the target message information, wherein the target message information is the message information contained in the requirement file of the controller under test in the controller local area network;

[0021] If so, the interface code program is written into the code calibration area of ​​the controller under test.

[0022] In one possible implementation, determining whether the message information in the interface code program matches the target message information includes:

[0023] After converting the message information obtained by traversing the interface code program into a format consistent with the target message information, a consistency comparison is performed.

[0024] A second aspect of this application provides a vehicle controller testing apparatus, comprising:

[0025] The interface code acquisition module is used to acquire the interface code program in the software program of the controller under test;

[0026] An interface code writing module is used to write the interface code program into the code calibration area of ​​the controller under test;

[0027] The interface signal acquisition module is used to invoke a debugging interface tool to acquire, from the code calibration area, a first signal value and / or a second signal value of the controller under test (DUT) when running the software program. The first signal value is a signal value carried in a message sent by the DUT as a sender, and the second signal value is a signal value carried in a message received by the DUT as a receiver.

[0028] The interface signal verification module is used to verify the controller under test based on a first judgment result and / or a second judgment result. The first judgment result is the judgment result of whether the first signal value and the third signal value are consistent. The second judgment result is the judgment result of whether the second signal value and the fourth signal value are consistent. The third signal value is the signal value in the message received by the message receiver when the controller under test is the sender. The fourth signal value is the signal value in the message sent by the message sender when the controller under test is the receiver.

[0029] A third aspect of this application provides a computer program product including computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the vehicle controller testing method of the first aspect or any implementation thereof.

[0030] A fourth aspect of this application provides an electronic device, including at least one processor and a memory connected to the processor, wherein:

[0031] The memory is used to store computer programs;

[0032] The processor is used to execute the computer program so that the electronic device can implement the vehicle controller testing method of the first aspect or any implementation thereof.

[0033] The fifth aspect of this application provides a computer storage medium carrying one or more computer programs, which, when executed by an electronic device, enable the electronic device to implement the vehicle controller testing method of the first aspect or any implementation thereof.

[0034] By employing the above technical solution, the vehicle controller testing method provided in this application writes the interface code program from the software program of the controller under test (DUT) into the code calibration area of ​​the DUT. This allows the debugging interface tool to monitor the transmitted and received messages of the DUT through the code calibration area, and obtain the signal values ​​of the DUT when sending and receiving messages while running the software program. Based on this, by combining the signal values ​​in the messages received by the receiver when the DUT is the sender, and the signal values ​​in the messages sent by the sender when the DUT is the receiver, the method verifies whether there are errors in the DUT when sending and receiving messages, assisting developers in timely identifying and fixing problems in the controller, and ensuring the accuracy and reliability of message transmission. Attached Figure Description

[0035] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0036] Figure 1 This application provides a structural diagram of a vehicle controller testing system.

[0037] Figure 2 A structural diagram of a terminal provided in this application;

[0038] Figure 3 A structural diagram of a server provided in this application;

[0039] Figure 4 A flowchart of a vehicle controller testing method provided in this application;

[0040] Figure 5 A flowchart illustrating the application of the vehicle controller testing method provided in this application;

[0041] Figure 6 This application provides a structural diagram of a vehicle controller testing device.

[0042] Figure 7 A structural diagram of the electronic device provided in this application. Detailed Implementation

[0043] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.

[0044] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0045] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0046] See Figure 1 , Figure 1 A schematic diagram of the architecture of a vehicle controller testing system is shown. The system may include a terminal 100 and / or a server 200, a debugging interface tool, and a bus development platform. The debugging interface tool can monitor the interface program in the code calibration area of ​​the controller under test (DUT) and obtain signal values ​​from the message signals sent and received by the DUT. The bus development platform can send messages to and receive messages sent by the DUT. The vehicle controller testing method provided in this application can be executed through the terminal 100 or the server 200.

[0047] Alternatively, the vehicle controller testing method of this application can be provided to the terminal 100 through the server 200, and the terminal 100 can control the debugging interface tool and bus development platform to perform the test.

[0048] Server 200 may include one or more servers ( Figure 1 (The example includes a server). The server 200 can provide the vehicle controller testing method provided in the embodiments of this application to one or more terminals.

[0049] The terminal 100 may be equipped with an application for vehicle controller testing methods. The application and webpage can provide an interface. The terminal 100 can receive relevant parameters input by the user on the operation interface of the vehicle controller testing methods, and perform tests based on the parameters to obtain the corresponding test result data.

[0050] It should be understood that in some optional implementations, the terminal 100 can also complete the action of obtaining the processing result based on the received parameters on its own, without the need for the server to cooperate. This application embodiment is not limited to this.

[0051] The following description Figure 1 The product form of the mid-terminal 100;

[0052] The terminal 100 in this application embodiment can be a mobile phone, tablet computer, wearable device, vehicle device, augmented reality (AR) / virtual reality (VR) device, laptop computer, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), etc., and this application embodiment does not impose any restrictions on it.

[0053] Figure 2 A schematic diagram of an optional hardware structure for terminal 100 is shown.

[0054] refer to Figure 2 As shown, the terminal 100 may include a radio frequency unit 110, a memory 120, an input unit 130, a display unit 140, a camera 150 (optional), an audio circuit 160 (optional), a speaker 161 (optional), a microphone 162 (optional), a headphone jack 163 (optional), a processor 170, an external interface 180, a power supply 190, and other components. Those skilled in the art will understand that... Figure 2 These are merely examples of terminals or multi-functional devices and do not constitute a limitation on terminals or multi-functional devices. They may include more or fewer components than shown in the illustration, or combine certain components, or use different components.

[0055] The input unit 130 can be used to receive input numerical or character information, and to generate key signal inputs related to user settings and function control of the portable multi-functional device. Specifically, the input unit 130 may include a touchscreen 131 (optional) and / or other input devices 132. The touchscreen 131 can collect touch operations performed by the user on or near it (such as operations performed by the user using fingers, knuckles, styluses, or any suitable object on or near the touchscreen), and drive the corresponding connection devices according to a pre-set program. The touchscreen can detect the user's touch actions, convert the touch actions into touch signals and send them to the processor 170, and can receive and execute commands sent by the processor 170; the touch signal includes at least touch point coordinate information. The touchscreen 131 can provide an input interface and an output interface between the terminal 100 and the user. In addition, various types of touchscreens, such as resistive, capacitive, infrared, and surface acoustic wave, can be used to implement the touchscreen. Besides the touchscreen 131, the input unit 130 may also include other input devices. Specifically, other input devices 132 may include, but are not limited to, one or more of the following: physical keyboard, function keys (such as volume control buttons, power buttons, etc.), trackball, mouse, joystick, etc.

[0056] Among them, the input device 132 can receive input data, etc.

[0057] The display unit 140 can be used to display information input by the user or information provided to the user, various menus of the terminal 100, interactive interfaces, file display, and / or playback of any multimedia file. In this embodiment, the display unit 140 can be used to display the interface of the vehicle controller test method, processing results, etc.

[0058] The memory 120 can be used to store instructions and data. The memory 120 may primarily include an instruction storage area and a data storage area. The data storage area can store various types of data, such as multimedia files and text. The instruction storage area can store software units such as operating systems, applications, and instructions required for at least one function, or subsets or extended sets thereof. It may also include non-volatile random access memory. It provides the processor 170 with hardware, software, and data resources for managing the computing device, supporting control software and applications. It is also used for storing multimedia files, as well as storing running programs and applications.

[0059] The processor 170 is the control center of the terminal 100. It connects various parts of the terminal 100 via various interfaces and lines. By running or executing instructions stored in the memory 120 and calling data stored in the memory 120, it performs various functions and processes data of the terminal 100, thereby controlling the terminal device as a whole. Optionally, the processor 170 may include one or more processing units; preferably, the processor 170 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 170. In some embodiments, the processor and memory can be implemented on a single chip; in some embodiments, they can also be implemented separately on independent chips. The processor 170 can also be used to generate corresponding operation control signals, send them to the corresponding components of the computing processing device, read and process data in the software, especially read and process data and programs in the memory 120, so that the various functional modules therein perform corresponding functions, thereby controlling the corresponding components to act according to the instructions.

[0060] The memory 120 can be used to store software code related to the vehicle controller test method, and the processor 170 can execute the steps of the vehicle controller test method, and can also schedule other units (such as the above-mentioned input unit 130 and display unit 140) to achieve the corresponding functions.

[0061] The radio frequency unit 110 (optional) can be used for receiving and transmitting signals during information transmission or calls. For example, it can receive downlink information from the base station and process it for the processor 170; additionally, it can transmit uplink data to the base station. Typically, the RF circuit includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low-noise amplifier (LNA), a duplexer, etc. Furthermore, the radio frequency unit 110 can also communicate wirelessly with network devices and other devices. This wireless communication can use any communication standard or protocol, including but not limited to Global System for Mobile communication (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE), email, Short Messaging Service (SMS), etc.

[0062] In this embodiment of the application, the radio frequency unit 110 can send test result data to the server 200.

[0063] It should be understood that the radio frequency unit 110 is optional and can be replaced with other communication interfaces, such as a network port.

[0064] The terminal 100 also includes a power supply 190 (such as a battery) that supplies power to various components. Preferably, the power supply can be logically connected to the processor 170 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system.

[0065] Terminal 100 also includes an external interface 180, which can be a standard Micro USB interface or a multi-pin connector, which can be used to connect terminal 100 to other devices for communication or to connect a charger to charge terminal 100.

[0066] Although not shown, terminal 100 may also include a flash, a wireless fidelity (WiFi) module, a Bluetooth module, sensors with various functions, etc., which will not be described in detail here. Some or all of the methods described below can be applied to, for example... Figure 2 In the terminal 100 shown.

[0067] The following description Figure 1 The product form of the mid-range server 200;

[0068] Figure 3 A structural diagram of a server 200 is provided, as follows: Figure 3 As shown, server 200 includes bus 201, processor 202, communication interface 203, and memory 204. Processor 202, memory 204, and communication interface 203 communicate with each other via bus 201.

[0069] Bus 201 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 3 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0070] The processor 202 can be any one or more of the following processors: central processing unit (CPU), graphics processing unit (GPU), microprocessor (MP), or digital signal processor (DSP).

[0071] Memory 204 may include volatile memory, such as random access memory (RAM). Memory 204 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0072] The memory 204 can be used to store software code related to the vehicle controller test method, and the processor 202 can execute the steps of the vehicle controller test method of the chip, and can also schedule other units to achieve corresponding functions.

[0073] It should be understood that the aforementioned terminal 100 and server 200 can be centralized or distributed devices. The processors (e.g., processor 170 and processor 202) in the aforementioned terminal 100 and server 200 can be hardware circuits (such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), general-purpose processors, digital signal processors (DSPs), microprocessors or microcontrollers, etc.) or combinations of these hardware circuits. For example, the processor can be a hardware system with instruction execution capabilities, such as a CPU or DSP, or a hardware system without instruction execution capabilities, such as an ASIC or FPGA, or a combination of the aforementioned hardware systems without instruction execution capabilities and hardware systems with instruction execution capabilities.

[0074] Reference Figure 4 , Figure 4 This is a flowchart illustrating a vehicle controller testing method provided in an embodiment of this application, as shown below. Figure 4 As shown in the embodiment of this application, a vehicle controller testing method may include steps 401 to 404, which are described in detail below.

[0075] 401. Obtain the interface code program in the software program of the controller under test.

[0076] Specifically, the controller under test (DUT) is the ECU (Electronic Control Unit) in the vehicle that needs to be tested. The software program running within it is generally the program that processes data for the ECU during vehicle operation. Since each software program involves sending and receiving messages, the format of the message signal interface functions (message sending interface functions and message receiving interface functions) used in the software program is consistent. The message sending interface functions and message receiving interface functions can be determined by running a script to traverse the software program.

[0077] It is understood that those skilled in the art can also use other well-known methods to obtain the interface code program in the software program, and no restrictions are imposed here.

[0078] 402. Write the interface code program into the code calibration area of ​​the controller under test.

[0079] Specifically, the code calibration area can be a pre-allocated memory region within the controller under test (DUT) for storing interface code programs. This allows debugging tools to monitor these interface code programs and obtain signal values ​​from messages sent and received by the DUT through the interface code programs. These signal values ​​are the data content carried in the messages, such as cruising speed, engine speed, and motor torque.

[0080] To facilitate monitoring of signal values ​​in sent and received messages, the Laudbach interface tool can be used as the debugging interface tool. Through the Laudbach debugging port, the running status of the program's interface code can be observed in real time, thereby obtaining the signal values ​​in the messages.

[0081] It should be noted that those skilled in the art can also use other debugging interface tools to obtain signal values ​​in messages, which will not be elaborated here.

[0082] 403. Call the debugging interface tool to obtain the first signal value and / or the second signal value of the controller under test when running the software program from the code calibration area. The first signal value is the signal value carried in the message sent by the controller under test as the sender, and the second signal value is the signal value carried in the message received by the controller under test as the receiver.

[0083] Specifically, considering that the controller under test will send messages after power-on, the Laudbach debug port can be called to obtain the signal values ​​in the messages sent by the controller under test in real time after the controller under test is powered on. The message values ​​in the messages received by the receiver (i.e., the bus development platform) can also be obtained through the script.

[0084] When the controller under test (DUT) acts as a signal receiver, a message sending script can be run on the bus development platform. For example, a script written in CAPL (Communication Access Programming Language) for the CAN bus can be used to send messages to the DUT. The Laudbach debug port can then be called to obtain the signal values ​​in the received messages from the DUT.

[0085] In practical implementation, users can select and adjust the number of signal values ​​to be acquired as needed. This allows them to acquire the appropriate signal values ​​based on the actual testing requirements. For example, when only the sender's transmitted message needs verification, only the first signal value needs to be acquired. When only the receiver's transmitted message needs verification, only the second signal value needs to be acquired. When both the sender's and receiver's messages need verification, both the first and second signal values ​​can be acquired. Those skilled in the art can select and adjust the number and types of signal values ​​to be acquired as needed, which will not be elaborated upon here.

[0086] The bus development platform can be built using CANoe (CAN open environment, bus development environment).

[0087] 404. Based on the first judgment result and / or the second judgment result, verify the controller under test. The first judgment result is the judgment result of whether the first signal value and the third signal value are consistent. The second judgment result is the judgment result of whether the second signal value and the fourth signal value are consistent. The third signal value is the signal value in the message received by the message receiver when the controller under test is the sender. The fourth signal value is the signal value in the message sent by the message sender when the controller under test is the receiver.

[0088] Specifically, when the controller under test sends a message, the script is run to call the Laudbach debug port to obtain the signal value in the sent message, and at the same time obtains the signal value in the message received by the bus development platform. The two are compared to see if they are consistent, and the first judgment result is obtained.

[0089] When the controller under test receives a message, the script calls the Laudbach debug port to obtain the signal value in the received message, and the script also obtains the signal value in the message sent by the bus development platform. The two are compared to determine whether they are consistent, and a second judgment result is obtained.

[0090] To ensure the accuracy of the verification results, when verifying the controller under test based on the first judgment result and / or the second judgment result, if it is necessary to verify both the messages of the sender and the receiver, then if the first signal value and the third signal value are consistent, and the second signal value and the fourth signal value are consistent, then the verification is deemed to have passed.

[0091] When only the sender's message is verified, if the first signal value and the third signal value are consistent, the verification is considered successful.

[0092] When only the receiver's message is verified, if the second signal value and the fourth signal value are consistent, the verification is considered successful.

[0093] As can be seen from the above, this vehicle controller testing method enables the entire testing process to be fully automated, reducing labor costs and improving testing efficiency. Furthermore, it assists developers in promptly identifying and fixing controller problems, ensuring the accuracy and reliability of message transmission.

[0094] In one possible implementation, to further improve the comprehensiveness and reliability of the test, when the controller under test (DUT) sends messages as the sender, the following is also included:

[0095] The debugging interface tool is invoked to adjust the signal values ​​in the current message according to the signal adjustment strategy before sending.

[0096] The corresponding first judgment result also includes the judgment result of whether the adjusted signal value is consistent with the third signal value.

[0097] Specifically, the script can be run to call the Laudbach debug port, change the signal values ​​sent by the controller under test in sequence, send the message, and obtain the signal values ​​in the message received by the bus development platform through the script, and compare whether the two are consistent.

[0098] For example, if the software program of the controller under test sends a signal value of the maximum vehicle speed of 120 km / h by default, then after the test starts, the signal value can be reduced by 10 km each time to obtain a new signal value before sending a message, thereby verifying the accuracy of the transmission of each signal value.

[0099] Considering that received messages in actual use may carry checksum messages, to improve the accuracy of identifying various received messages, when the controller under test (DUT) acts as the receiver, the following is also included:

[0100] When the debugging interface tool is called to receive a message that carries a verification message, the corresponding signal value in the received message is obtained.

[0101] Specifically, with the controller under test acting as the message receiver, the CAPL script sequentially simulates sending non-E2E (End-to-End) messages and message signals with E2E verification. The script then checks whether the signal value received by the Laudbach debug port is consistent with the value simulated by CANoe.

[0102] To further ensure the accuracy of test results and eliminate the possibility of errors in the software program of the controller under test leading to misjudgments, the following steps are included before writing the interface code program into the code calibration area of ​​the controller under test:

[0103] Step 11: Determine whether the message information in the interface code program is consistent with the target message information. The target message information is the message information contained in the requirement file of the controller under test in the controller local area network.

[0104] Step 12: If yes, write the interface code program into the code calibration area of ​​the controller under test.

[0105] Specifically, while using scripts to traverse the interface program code in the software program, the message information contained in the interface code program can also be traversed and stored in the data dictionary. Then, by using the requirement files in the CAN network, such as DBC files (Database for CAN) and LDF files (LIN Description File), which predefine the contents of the messages sent and received by each electronic control unit in the CAN or LIN network, such as: message identifier, message transmission channel, message name, message transmission period, maximum and minimum signal values ​​in the message, and E2E and non-E2E messages in the received messages.

[0106] By comparing the message information in these requirement documents with the message information obtained by traversing the interface code program, it can be determined whether there are any missing messages in the interface program.

[0107] To facilitate comparison, the message information obtained by the interface code program can be converted into a format consistent with the target message information before a consistency comparison is performed. For example, after arranging various information in a preset order, they can be stored as a file or table in a uniform format for comparison.

[0108] It is understood that those skilled in the art can use other methods to compare message information, which will not be elaborated here.

[0109] As a specific application of the above embodiments, refer to Figure 5 The vehicle control test method shown may specifically include the following processes:

[0110] After the test begins, the message signal interface functions in the controller under test (DUT) code are traversed, the DBC and LDF requirement files are parsed, and then the message signals in the DUT code are compared with those in the requirement files. If they match, the interface code program is generated into test code and written to the code calibration area. At the same time, the software code containing the interface code program is compiled and then written to the DUT for execution.

[0111] After the operation starts, when the controller under test sends a message, the script calls the Laudbach debug port to obtain the signal value in the sent message, and at the same time obtains the signal value in the message received by the bus development platform (CANoe), compares whether the two are consistent, and obtains the first judgment result.

[0112] When the controller under test receives a message, a script is run to call the Laudbach debug port to obtain the signal value in the received message. The script also obtains the signal value in the message sent by the bus development platform. The two are compared to determine if they are consistent, thus obtaining a second judgment result. The test is considered successful only when both the first and second judgment results are consistent.

[0113] This vehicle controller testing method automates the testing of a large number of signals, ensuring both testing efficiency and quality. Furthermore, the scripts are requirements-based, allowing for quick adaptation to other projects simply by changing the requirements document. After software flashing, it can complete nearly 5000 signal tests per minute. It can also test CAN, LIN, and messages with and without E2E, increasing test coverage.

[0114] The above describes a vehicle controller testing method provided by the embodiments of this application. The following describes the apparatus for performing the above vehicle controller testing method.

[0115] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of a vehicle controller testing device provided in an embodiment of this application. Figure 6 As shown, the vehicle controller testing device includes:

[0116] The interface code acquisition module 601 is used to acquire the interface code program in the software program of the controller under test;

[0117] The interface code writing module 602 is used to write the interface code program into the code calibration area of ​​the controller under test.

[0118] The interface signal acquisition module 603 is used to call the debugging interface tool to acquire, from the code calibration area, a first signal value and / or a second signal value of the controller under test (DUT) when running the software program. The first signal value is the signal value carried in the message sent by the DUT as the sender, and the second signal value is the signal value carried in the message received by the DUT as the receiver.

[0119] The interface signal verification module 604 is used to verify the controller under test based on the first judgment result and / or the second judgment result. The first judgment result is the judgment result of whether the first signal value and the third signal value are consistent. The second judgment result is the judgment result of whether the second signal value and the fourth signal value are consistent. The third signal value is the signal value in the message received by the message receiver when the controller under test is the sender. The fourth signal value is the signal value in the message sent by the message sender when the controller under test is the receiver.

[0120] In one possible implementation, the interface signal acquisition module 603, when the controller under test (DUT) sends a message as the sender, is also used for:

[0121] The debugging interface tool is invoked to adjust the signal values ​​in the current message according to the signal adjustment strategy before sending.

[0122] The first judgment result also includes the judgment result of whether the adjusted signal value is consistent with the third signal value.

[0123] In one possible implementation, the interface signal acquisition module 603, when the controller under test (DUT) receives messages as a receiver, is also used for:

[0124] The debugging interface tool is invoked to obtain the signal value in the received message based on whether the received message carries a check message.

[0125] In one possible implementation, the interface signal verification module 604 verifies the controller under test based on the first judgment result and the second judgment result, including:

[0126] When the first signal value and the second signal value are obtained, if the first signal value and the third signal value are consistent, and the second signal value and the fourth signal value are consistent, then the verification is considered successful.

[0127] If the first signal value and the third signal value are consistent when only the first signal value is obtained, the verification is considered successful.

[0128] If the second signal value and the fourth signal value are consistent when only the second signal value is obtained, the verification is considered successful.

[0129] In one possible implementation, it also includes: a program verification module, used to verify the interface code program before writing it into the code calibration area of ​​the controller under test.

[0130] Determine whether the message information in the interface code program is consistent with the target message information. The target message information is the message information contained in the requirement file of the controller under test in the controller's local area network.

[0131] If so, the interface code program is written into the code calibration area of ​​the controller under test.

[0132] In one possible implementation, the process by which the program verification module determines whether the message information in the interface code program matches the target message information includes:

[0133] After converting the message information obtained by traversing the interface code program into a format consistent with the target message information, a consistency comparison is performed.

[0134] This application also provides an electronic device in its embodiments. (See reference...) Figure 7The diagram illustrates a structural schematic suitable for implementing the electronic device in the embodiments of this application. The electronic device in the embodiments of this application may include, but is not limited to, fixed terminals such as mobile phones, laptops, PDAs (personal digital assistants), PADs (tablet computers), desktop computers, etc. Figure 7 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0135] like Figure 7 As shown, the electronic device may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 701, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 702 or a program loaded from a storage device 708 into a random access memory (RAM) 703. When the electronic device is powered on, the RAM 703 also stores various programs and data required for the operation of the electronic device. The processing unit 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0136] Typically, the following devices can be connected to I / O interface 705: input devices 706 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 707 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 708 including, for example, memory cards, hard drives, etc.; and communication devices 709. Communication device 709 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 7 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have alternatively.

[0137] This application also provides a computer program product including computer-readable instructions, which, when executed on an electronic device, cause the electronic device to implement any of the vehicle controller testing methods provided in this application.

[0138] This application also provides a computer-readable storage medium carrying one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any of the vehicle controller testing methods provided in this application.

[0139] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0140] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0141] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0142] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

Claims

1. A vehicle controller testing method, characterized in that, include: Obtain the interface code program from the software program of the controller under test; Write the interface code program into the code calibration area of ​​the controller under test; The debugging interface tool is invoked to obtain the first signal value and / or the second signal value of the controller under test when running the software program from the code calibration area. The first signal value is the signal value carried in the message sent by the controller under test as the sender, and the second signal value is the signal value carried in the message received by the controller under test as the receiver. The controller under test is verified based on the first judgment result and / or the second judgment result. The first judgment result is the judgment result of whether the first signal value and the third signal value are consistent. The second judgment result is the judgment result of whether the second signal value and the fourth signal value are consistent. The third signal value is the signal value in the message received by the message receiver when the controller under test is the sender. The fourth signal value is the signal value in the message sent by the message sender when the controller under test is the receiver.

2. The vehicle controller testing method according to claim 1, characterized in that, When the controller under test sends a message as the sender, it also includes: The debugging interface tool is invoked to adjust the signal values ​​in the current message according to the signal adjustment strategy before sending it. The first judgment result also includes: a judgment result on whether the adjusted signal value is consistent with the third signal value.

3. The vehicle controller testing method according to claim 1 or 2, characterized in that, When the controller under test receives messages as a receiver, it also includes: When the debugging interface tool is invoked to carry a verification message in the received message, the corresponding signal value in the received message is obtained.

4. The vehicle controller testing method according to any one of claims 1 to 3, characterized in that, The step of verifying the controller under test based on the first judgment result and the second judgment result includes: When the first signal value and the second signal value are obtained, if the first signal value and the third signal value are consistent, and the second signal value and the fourth signal value are consistent, then the verification is determined to be successful. If the first signal value and the third signal value are consistent when only the first signal value is obtained, the verification is deemed successful. If the second signal value and the fourth signal value are consistent when only the second signal value is obtained, the verification is deemed successful.

5. The vehicle controller testing method according to any one of claims 1 to 4, characterized in that, Before writing the interface code program into the code calibration area of ​​the controller under test, the method further includes: Determine whether the message information in the interface code program is consistent with the target message information, wherein the target message information is the message information contained in the requirement file of the controller under test in the controller local area network; If so, the interface code program is written into the code calibration area of ​​the controller under test.

6. The vehicle controller testing method according to claim 5, characterized in that, The step of determining whether the message information in the interface code program matches the target message information includes: After converting the message information obtained by traversing the interface code program into a format consistent with the target message information, a consistency comparison is performed.

7. A vehicle controller testing device, characterized in that, include: The interface code acquisition module is used to acquire the interface code program in the software program of the controller under test; An interface code writing module is used to write the interface code program into the code calibration area of ​​the controller under test; The interface signal acquisition module is used to call the debugging interface tool to obtain the first signal value and / or the second signal value of the controller under test when running the software program from the code calibration area. The first signal value is the signal value carried in the message sent by the controller under test as the sender, and the second signal value is the signal value carried in the message received by the controller under test as the receiver. as well as, The interface signal verification module is used to verify the controller under test based on a first judgment result and / or a second judgment result. The first judgment result is the judgment result of whether the first signal value and the third signal value are consistent. The second judgment result is the judgment result of whether the second signal value and the fourth signal value are consistent. The third signal value is the signal value in the message received by the message receiver when the controller under test is the sender. The fourth signal value is the signal value in the message sent by the message sender when the controller under test is the receiver.

8. A computer program product, characterized in that, It includes computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the vehicle controller testing method as described in any one of claims 1 to 6.

9. An electronic device, characterized in that, It includes at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program to enable the electronic device to implement the vehicle controller testing method as described in any one of claims 1 to 6.

10. A computer storage medium, characterized in that, The storage medium carries one or more computer programs that, when executed by an electronic device, enable the electronic device to implement the vehicle controller testing method as described in any one of claims 1 to 6.

Images