A test system and test method based on Ethernet

Abstract

The present application provides a test system and test method based on Ethernet, including a test terminal and an Ethernet interface card, wherein a first USB interface of the test terminal is connected to a USB interface of the Ethernet interface card, an Ethernet twisted pair interface of the Ethernet interface card is connected to an Ethernet twisted pair interface of a vehicle computer under test, a serial communication interface of the vehicle computer under test is connected to a second USB interface of the test terminal, the Ethernet interface card receives a test instruction issued by the test terminal, and forwards the test instruction to the vehicle computer under test; the vehicle computer under test receives the test instruction forwarded by the Ethernet interface card, generates test data, and sends the test data to the test terminal; the test terminal sends the test instruction to the Ethernet interface card, receives the test data returned by the vehicle computer under test, compares the test data with preset data, and determines the detection result of the vehicle computer under test. In the present application, the test instruction is transmitted through the Ethernet interface card to improve the test efficiency.

Description

Technical Field

[0001] The present application relates to the technical field of Ethernet, and in particular to a test system and a test method based on Ethernet. Background Art

[0002] At present, the Ethernet ECU software in automobiles is becoming more and more complex, and the data interaction between them is becoming more and more close. How to ensure the reliability of high-speed data transmitted between these Ethernet ECUs is the focus of current in-vehicle Ethernet real-vehicle testing.

[0003] However, the existing technology uses highly professional test tools for vehicle-mounted ECU functions and troubleshooting, such as CANOE (Controller Area Network), which is mainly used for testing and analyzing the CAN bus between the vehicle-mounted network and the ECU. This type of test equipment is expensive, large in size, and has low portability. It is also highly complex and requires operators to have experience in Ethernet knowledge.

[0004] As mentioned above, existing testing equipment has many limitations. First, it is expensive. Second, it is large in size and has low portability. Third, it is highly complex and requires operators to have professional knowledge and experience. The labor cost is high and the testing efficiency is relatively low. Summary of the invention

[0005] In view of this, the purpose of the present application is to provide an Ethernet-based test system and test method to overcome at least one of the above-mentioned defects.

[0006] In a first aspect, an embodiment of the present application provides an Ethernet-based test system, comprising a test terminal and an Ethernet interface card, wherein a first USB interface of the test terminal is connected to a USB interface of the Ethernet interface card, an Ethernet twisted pair interface of the Ethernet interface card is connected to an Ethernet twisted pair interface of a vehicle computer under test, and a serial communication interface of the vehicle computer under test is connected to a second USB interface of the test terminal, wherein the Ethernet interface card is used to receive a test instruction issued by the test terminal and forward the test instruction to the vehicle computer under test; the vehicle computer under test is used to receive the test instruction forwarded by the Ethernet interface card, parse the test instruction, generate test data, and send the test data to the test terminal; the test terminal is used to send a test instruction to the Ethernet interface card, and to receive the test data returned by the vehicle computer under test, and compare the test data with preset data to determine the detection result of the vehicle computer under test.

[0007] In an optional embodiment of the present application, the system also includes: a programmable power supply, the power supply interface of the programmable power supply is connected to the power supply interface of the vehicle computer under test; wherein the test terminal is configured to: send a power supply start instruction to the programmable power supply to control the programmable power supply to power the vehicle computer under test; receive the current and voltage of the vehicle computer under test sent by the programmable power supply to perform data collection.

[0008] In an optional embodiment of the present application, the test terminal is further configured to: obtain a CAN requirement matrix, the CAN requirement matrix including multiple requirement fields; extract the target field in the CAN requirement matrix, and generate a data routing table for the target field; divide the test items according to the data routing table, and determine the test cases under each test item, each test case including multiple test instructions.

[0009] In an optional embodiment of the present application, the test terminal is further configured to: in response to a start test instruction, send a port status detection signal to the vehicle computer under test; receive a first port status signal returned by the vehicle computer under test; determine whether the first port status signal indicates that the datagram protocol port is in an open state; if the first port status signal indicates that the datagram protocol port is in an open state, send the test instruction to the Ethernet interface card for testing; if the first port status signal indicates that the datagram protocol port is in a non-open state, send a port connection signal to the vehicle computer under test.

[0010] In an optional embodiment of the present application, the test terminal is further configured to: receive a second port status signal returned by the vehicle computer under test, the second port status signal being a signal returned to the test terminal by the vehicle computer under test after receiving the port connection signal; determine whether the second port status signal indicates that the datagram protocol port is in an open state; if the second port status signal indicates that the datagram protocol port is in an open state, send the test instruction to the Ethernet interface card for testing; if the second port status signal indicates that the datagram protocol port is not in an open state, display a connection failure when the preset conditions are met.

[0011] In an optional embodiment of the present application, the test terminal is further configured to: record the number of returns of the second port status signal indicating that the datagram protocol port is in an open state; determine whether the number of returns is greater than a preset number; if the number of returns is not greater than a preset number, it is considered that the preset condition is not met, and the port connection signal continues to be sent to the vehicle computer under test, and the second port status signal returned by the vehicle computer under test is received.

[0012] In an optional embodiment of the present application, the start test instruction includes a project identifier, the project identifier corresponds to the test item one-to-one, each test item includes multiple test cases, and each test case includes multiple test instructions, wherein the test terminal is further configured to: respond to the start test instruction, determine the target test item according to the function identifier; determine the test case from the target test item, and determine the test instructions to be issued according to the preset period of the test case.

[0013] In an optional embodiment of the present application, the test data includes a data sequence and a sequence identifier, wherein the test terminal is further configured to: locate the target data at a target position in the data sequence according to the sequence identifier; compare the target data with preset data, and output a comparison result.

[0014] In an optional embodiment of the present application, the test terminal is further configured to: determine whether the target data is consistent with the preset data; if the target data is consistent with the preset data, it indicates that the test result of the test item corresponding to the target data is successful, and the comparison result is determined to be a successful test; if the target data is inconsistent with the preset data, it indicates that the test result of the test item corresponding to the target data is unsuccessful, and the comparison result is determined to be an unsuccessful test.

[0015] In a second aspect, an embodiment of the present application also provides an Ethernet-based testing method, which is applied to an Ethernet-based testing system, wherein the Ethernet-based testing system includes a test terminal and an Ethernet interface card, wherein the first USB interface of the test terminal is connected to the USB interface of the Ethernet interface card, the Ethernet twisted pair interface of the Ethernet interface card is connected to the Ethernet twisted pair interface of the vehicle computer under test, and the serial communication interface of the vehicle computer under test is connected to the second USB interface of the test terminal, and the method includes: the Ethernet interface card is used to receive a test instruction issued by the test terminal, and forward the test instruction to the vehicle computer under test; the vehicle computer under test is used to receive the test instruction forwarded by the Ethernet interface card, parse the test instruction, generate test data, and send the test data to the test terminal; the test terminal is used to send the test instruction to the Ethernet interface card, and to receive the test data returned by the vehicle computer under test, and compare the test data with preset data to determine the detection result of the vehicle computer under test.

[0016] The embodiment of the present application provides a test system and test method based on Ethernet. The test system based on Ethernet includes a test terminal and an Ethernet interface card. The first USB interface of the test terminal is connected to the USB interface of the Ethernet interface card. The Ethernet twisted pair interface of the Ethernet interface card is connected to the Ethernet twisted pair interface of the tested vehicle computer. The serial communication interface of the tested vehicle computer is connected to the second USB interface of the test terminal. The Ethernet interface card is used to receive the test instructions issued by the test terminal and forward the test instructions to the tested vehicle computer; the tested vehicle computer is used to receive the test instructions forwarded by the Ethernet interface card, generate test data, and send the test data to the test terminal; the test terminal is used to send the test instructions to the Ethernet interface card, and to receive the test data returned by the tested vehicle computer, and compare the test data with the preset data to determine the detection result of the tested vehicle computer. In the present application, the test instructions are transmitted through the Ethernet interface card, and the test efficiency is improved and the labor cost is reduced through the automated test process.

[0017] In order to make the above-mentioned objects, features and advantages of the present application more obvious and easy to understand, preferred embodiments are specifically cited below and described in detail with reference to the attached drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0019] Figure 1 One of the structural schematic diagrams of the Ethernet-based test system provided in the embodiment of the present application;

[0020] Figure 2 The second structural diagram of the Ethernet-based test system provided in the embodiment of the present application;

[0021] Figure 3 A flow chart of testing a test terminal provided in an embodiment of the present application;

[0022] Figure 4 A flowchart of an Ethernet-based testing method provided in an embodiment of the present application. DETAILED DESCRIPTION

[0023] To make the purpose, technical scheme and advantages of the embodiments of the present application clearer, the technical scheme in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments. The components of the embodiments of the present application usually described and shown in the drawings here can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the application claimed for protection, but merely represents the selected embodiments of the present application. Based on the embodiments of the present application, each other embodiment obtained by those skilled in the art without making creative work belongs to the scope of protection of the present application.

[0024] First, the application scenarios to which the present application is applicable are introduced. The present application can be applied in the field of Ethernet.

[0025] Research has found that the functions and troubleshooting of automotive Ethernet in existing technologies all use highly professional Ethernet testing tools, such as CANOE (Controller Area Network), which is mainly used for testing and analyzing the CAN bus between the vehicle network and the ECU. This type of testing equipment is expensive, large in size, and has low portability. It is also highly complex and requires operators to have experience in Ethernet knowledge.

[0026] However, as mentioned above, existing testing equipment has many limitations. First, it is expensive. Second, it is large in size and low in portability. Third, it is highly complex and requires operators to have professional knowledge and experience.

[0027] Based on this, an embodiment of the present application provides an Ethernet-based test system, including a test terminal and an Ethernet interface card, wherein the Ethernet interface card is used to receive a test instruction issued by the test terminal and forward the test instruction to the vehicle computer under test; the vehicle computer under test is used to receive the test instruction forwarded by the Ethernet interface card, generate test data, and send the test data to the test terminal; the test terminal is used to send the test instruction to the Ethernet interface card, and to receive the test data returned by the vehicle computer under test, and compare the test data with the preset data to determine the detection result of the vehicle computer under test. In the present application, the test instruction is transmitted through the Ethernet interface card, and the test data is sent to the test terminal through the serial communication interface. Through the automated test process, the test efficiency is improved and the labor cost is reduced.

[0028] See also Figure 1 , Figure 1 This is one of the structural diagrams of the Ethernet-based test system provided in the embodiment of the present application. Figure 1As shown in , the Ethernet-based test system 10 provided in the embodiment of the present application includes: a test terminal 11 and an Ethernet interface card 12.

[0029] like Figure 1 As shown, the first USB interface of the test terminal 11 is connected to the USB interface of the Ethernet interface card 12, the Ethernet twisted pair interface of the Ethernet interface card 12 is connected to the Ethernet twisted pair interface of the tested vehicle computer 13, and the serial communication interface of the tested vehicle computer 13 is connected to the second USB interface of the test terminal 11.

[0030] Here, the Ethernet interface card 12 is used to receive the test instructions sent by the test terminal 11 and forward the test instructions to the vehicle computer 13 under test; the vehicle computer 13 under test is used to receive the test instructions forwarded by the Ethernet interface card 12, parse the test instructions, generate test data, and send the test data to the test terminal 11; the test terminal 11 is used to send the test instructions to the Ethernet interface card 12, and to receive the test data returned by the vehicle computer 13 under test, and compare the test data with the preset data to determine the detection result of the vehicle computer 13 under test.

[0031] The ECU (Electronic Control Unit) is one of the core components of the car, also known as the "brain" of the car. It is responsible for receiving data from various sensors, processing the data, and issuing instructions to the car's actuators based on the processing results to control the operation of the car. During the test, the ECU will undergo a series of rigorous inspections and evaluations to ensure that its performance and quality meet the design requirements.

[0032] In an optional embodiment, the test terminal 11 is the control center of the entire test system, which is responsible for generating test instructions, receiving test data, and analyzing and processing these data. In this system, the test terminal 11 communicates with external devices in two ways: the first USB interface: this interface is connected to the USB interface of the Ethernet interface card 12, and is used to send test instructions to the Ethernet interface card 12. The test instructions are generated by the test terminal 11 according to the test requirements and are used to instruct the on-board computer 13 to perform specific test operations; the second USB interface: this interface is connected to the serial communication interface of the on-board computer 13 under test, and this connection is used to receive the test data generated by the on-board computer 13 during the test process.

[0033] The vehicle Ethernet uses a 1000base-T1 interface, the test terminal 11 uses a 2345 crystal head interface, and the Ethernet interface card 12 ensures the conversion between the vehicle Ethernet and the traditional Ethernet. The Ethernet interface card 12 is a bridge device, which is responsible for transmitting test instructions and test data between the test terminal 11 and the vehicle computer 13 under test. Specifically: receiving test instructions: the Ethernet interface card 12 receives test instructions from the test terminal 11 through its USB interface, forwarding test instructions: the received test instructions are forwarded to the vehicle computer 13 under test through the Ethernet twisted pair interface of the Ethernet interface card 12. Ethernet is used as the communication protocol here to ensure high-speed and stable data transmission.

[0034] The tested on-board computer 13 is the object of the test, and it performs corresponding test operations according to the received test instructions and generates test data. Specifically: receiving test instructions: the tested on-board computer 13 receives the test instructions forwarded by the Ethernet interface card 12 through its Ethernet twisted pair interface; parsing test instructions: the received test instructions are parsed by the on-board computer 13 to determine the test operations that need to be performed; generating test data: according to the parsed test instructions, the on-board computer 13 performs corresponding test operations and generates test data; sending test data: the generated test data is sent back to the test terminal 11 through the serial communication interface of the on-board computer 13 (here connected to the second USB interface of the test terminal 11 through the USB interface).

[0035] In addition to sending test instructions and receiving test data, the test terminal 11 is also responsible for comparing the received test data with preset data. The preset data is set according to the test requirements and the normal working parameters of the on-board computer 13, and is used to evaluate the performance of the on-board computer 13 during the test. By comparing the test data with the preset data, the test terminal 11 can determine the detection result of the on-board computer 13 under test, that is, determine whether the on-board computer 13 has passed the test.

[0036] In summary, the Ethernet-based test system 10 achieves efficient and accurate testing of the on-board computer 13 through the collaborative work of the test terminal 11 , the Ethernet interface card 12 and the on-board computer 13 under test.

[0037] Here, the test data not only includes the data sequence actually used for testing, but also includes sequence identifiers used to identify and locate these data. The test terminal is configured to use these identifiers and data to execute specific test logic and output test results.

[0038] Data sequence: This is the data set actually used for testing, which can be a series of numerical values, strings, or other types of data. These data are organized into a sequence so that the test terminal can access and process them in sequence.

[0039] Sequence ID: This is an identifier used to uniquely identify a data sequence. It can be a number, a string, or any other type of unique value that is used to accurately locate a specific data sequence within the test terminal or when interacting with other system components.

[0040] When the test terminal 11 receives the test data, it will search and locate the corresponding data sequence in the test data according to the sequence identifier provided in the test data. Then, it will further extract the target data from the data sequence according to the specified target position (i.e. the position of the data in the sequence).

[0041] Once the target data is extracted, the test terminal 11 will compare it with a preset data set (i.e., expected results or standard values). This preset data set is defined before the test begins and is used to compare with the data under test (i.e., target data) to determine whether the test is successful.

[0042] Here, the test terminal 11 compares the target data with the preset data to determine whether they are completely consistent. This process may involve data type conversion, precision adjustment or other types of processing to ensure the accuracy of the comparison.

[0043] Then, according to the result of the data consistency judgment, the test terminal 11 will output a comparison result. This result is usually a simple success / failure indication, which is used to inform the tester or the automated test system of the status of the current test item.

[0044] If the target data is completely consistent with the preset data, the test terminal 11 will determine that the test result of the test item corresponding to the target data is successful, which means that the tested vehicle computer 13 performs normally and as expected in the current test scenario.

[0045] If the target data is inconsistent with the preset data, the test terminal 11 will determine that the test result of the test item corresponding to the target data is unsuccessful, which usually means that there is some problem or abnormality in the tested vehicle computer 13, which needs further investigation and resolution.

[0046] After determining the test results, the test terminal 11 performs a series of subsequent processing operations, such as recording the test results, generating a test report, sending a notification or triggering other related test processes, saving the test log, bus data log, and generating a test report.

[0047] These operations help testers or developers understand the status of the current test project and take appropriate measures to improve the quality of the product or system.

[0048] Through such a mechanism, the test terminal 11 can accurately locate specific test data and compare it with preset data, thereby accurately judging the success or failure of the test project. This helps to ensure the quality and stability of the product or system and reduce potential risks and problems.

[0049] See also Figure 2 , Figure 2 This is a second structural diagram of an Ethernet-based test system provided in an embodiment of the present application. Figure 2 As shown in , the Ethernet-based test system 10 provided in the embodiment of the present application includes: a test terminal 11, an Ethernet interface card 12 and a programmable power supply 14.

[0050] Here, the programmable power supply 21, as a high-precision, programmable power supply device, can output stable voltage and current according to preset parameters or external instructions. In this test system, the programmable power supply 21 is connected to the power supply interface of the vehicle computer 13 under test through its power supply interface, thereby ensuring that the vehicle computer 13 under test can obtain a stable and reliable power supply during the test process.

[0051] With the addition of the program-controlled power supply 21, the test terminal 11 is also given new tasks and functions. The test terminal is configured as follows:

[0052] The power supply start instruction is sent to the program-controlled power supply to control the program-controlled power supply 21 to supply power to the vehicle computer under test.

[0053] Here, before the test starts, the test terminal 11 will send a power supply start instruction to the programmable power supply 21. This instruction contains the power parameters such as voltage and current required by the vehicle computer 13 under test. After receiving the instruction, the programmable power supply 21 will provide a stable power supply for the vehicle computer under test according to the preset parameters.

[0054] Receive the current and voltage of the vehicle computer 13 under test sent by the programmable power supply 21 to collect data.

[0055] Specifically, during the test, the programmable power supply 21 will monitor and record the current and voltage data of the on-board computer under test in real time. These data are of great significance for evaluating the power consumption, power management efficiency and potential power failure of the on-board computer.

[0056] The test terminal 11 receives the current and voltage data sent by the programmable power supply 21 through some communication method (such as serial port, Ethernet, etc.). The received data will be collected, stored and analyzed by the test terminal 11 to facilitate the subsequent evaluation of the power performance of the tested vehicle computer 13.

[0057] Here, the programmable power supply 21 sends KL15 and KL30 signals to the vehicle computer 12 under test. KL30 is a signal related to the ECU power supply switch. When the KL30 signal is activated, it usually means that the main power supply circuit of the ECU is connected, so that the ECU can start working. This signal is the basis for the normal operation of the ECU; KL15 is a signal related to the key ignition (ACC). In the electrical system of the car, KL15 is usually associated with the position of the ignition switch. When the key is turned to this position, the KL15 signal is activated to provide power to the car's ECU. The activation of the KL15 signal ensures that the ECU is in the power supply level required for normal working state before the test starts.

[0058] In an optional embodiment, the overall workflow of the test system is:

[0059] Test preparation stage: the test terminal 11 is configured with test instructions and preset data, and the test terminal 11 is connected to the Ethernet interface card 12, the vehicle computer 13 under test, and the programmable power supply 21.

[0060] At the beginning of the test: the test terminal 11 sends a power supply start instruction to the program-controlled power supply; the program-controlled power supply supplies power to the vehicle computer 13 under test according to the instruction; the test terminal 11 sends a test instruction to the vehicle computer 13 under test via the Ethernet interface card 12.

[0061] Test execution phase: the vehicle computer 13 under test receives and parses the test instructions and executes the corresponding test operations; during the test, the programmable power supply 21 monitors and records the current and voltage data of the vehicle computer 13 under test in real time; the vehicle computer 13 under test sends the generated test data back to the test terminal 11 through the serial communication interface.

[0062] End of test phase: the test terminal 11 receives and collects all test data and power data; the test terminal 11 compares the test data with the preset data to determine the test result of the tested on-board computer 13; the test terminal 11 can also analyze the collected power data to evaluate the power performance of the tested on-board computer.

[0063] Specifically, the test terminal 11 determines the test case in the following manner:

[0064] Obtain a CAN requirement matrix, which includes multiple requirement fields;

[0065] Extract the target field in the CAN demand matrix and generate a data routing table from the target field;

[0066] According to the data routing table, the test items are divided, and the test cases under each test item are determined, and each test case includes multiple test instructions.

[0067] Here, the CAN requirement matrix is ​​a structured document or database that contains all the requirement information related to the vehicle controller area network (CAN), which may come from vehicle manufacturers, regulatory requirements, design specifications, etc.

[0068] Among them, the test instructions are transmitted through the UDP communication protocol. UDP is a protocol working in the transport layer of the OSI (Open Systems Interconnection) model. It uses IP as the underlying protocol and provides a way for applications to send messages to other programs with minimal protocol mechanisms.

[0069] UDP is a message-oriented protocol. Message is the smallest unit of UDP datagram processing. Each UDP datagram is an independent message, and there is no association between them. This enables UDP to flexibly handle data packets of different sizes and types.

[0070] The test terminal 11 obtains the CAN requirement matrix from an external data source (such as a server, a database, etc.) through a communication interface (such as Ethernet, USB, etc.), or reads these requirements from a locally stored file.

[0071] Furthermore, in the CAN requirement matrix, the test terminal 11 needs to identify and extract fields that are directly related to the test. These fields are usually related to vehicle functions, signal transmission, error handling, etc. The test terminal 11 may use some parsing algorithm or regular expression to extract the target fields from the CAN requirement matrix.

[0072] The data routing table can be a PDU (Protocol Data Unit) data routing table, which is a table generated based on the target field and used to describe the path and rules of signal transmission on the CAN network. It may include information such as signal name, sending node, receiving node, signal type, signal range, etc. The test terminal 11 may use some data processing tools or algorithms to generate a data routing table based on the extracted target field.

[0073] Here, the PDU data routing table is identified as a system variable, a key medium connecting the test framework and the user interface, and is used to store data extracted from the CAN demand matrix and the PDU data routing table, as well as other key information generated during the test process. System variables can be dynamically updated and accessed, thereby achieving real-time processing and display of data.

[0074] System variables are not only used for internal data processing, but also used to connect with the user interface. The system can display the value of system variables in real time on the user interface so that users can understand the status and results of the test in real time. At the same time, users can also modify the value of certain system variables through the interface, thereby realizing dynamic control and adjustment of the test process.

[0075] In an optional embodiment, the system's workflow may be: the user configures test parameters through the interface, such as selecting test items, setting test conditions, etc.; the system generates corresponding test data based on the parameters input by the user and the predefined test framework; the test data is sent to the vehicle computer under test through the test terminal 11 via the Ethernet interface card; the test terminal 11 receives the test data of the vehicle computer under test; the test terminal 11 processes and analyzes these data to determine whether the test is successful; the test results are displayed to the user through the user interface.

[0076] Through such a system architecture and workflow, testers can easily build and execute tests based on the CAN requirement matrix and PDU data routing table, while monitoring and analyzing test results in real time. This helps improve test efficiency and accuracy and reduce test costs.

[0077] According to the data routing table, the test terminal 11 can divide the test task into multiple test items. Each test item usually corresponds to a specific vehicle function or CAN network behavior. The test terminal 11 may use a certain classification algorithm or logic to divide the information in the data routing table into different test items. Each test item includes multiple test cases, and each test case includes multiple test instructions.

[0078] Test case: Under each test item, the test terminal 11 needs to determine a specific test case. The test case is an instantiation of the test item and describes a specific test scenario, input conditions, and expected results.

[0079] Test instructions: Each test case includes multiple test instructions, which are used to guide the test terminal 11 or the test device to perform specific test operations. The test instructions may include sending specific CAN messages, monitoring specific CAN signals, checking error codes, etc.

[0080] Determination method: The test terminal 11 may use a test case generation tool or algorithm to generate test cases and test instructions according to the requirements of the test items and the information of the data routing table.

[0081] In summary, the test terminal 11 determines the final test instructions through a series of steps including obtaining the CAN requirement matrix, extracting the target field, generating a data routing table, dividing the test items, and determining the test cases and test instructions. These steps ensure that the test terminal can accurately and comprehensively perform the test tasks and verify the functions and performance of the vehicle controller Ethernet.

[0082] Specifically, see Figure 3 , Figure 3 This is a flow chart of testing a test terminal provided in an embodiment of the present application. Figure 3 As shown in the figure, the test terminal is also configured as:

[0083] S301, in response to a start test instruction, sending a port status detection signal to the vehicle computer under test;

[0084] Here, when the test system or tester issues a command to the test terminal to start the test, the test terminal will immediately enter the test preparation phase. This command triggers the start of the entire test process.

[0085] During the test preparation phase, the test terminal will first send a port status detection signal to the vehicle computer under test. The purpose of this signal is to inquire whether the current datagram protocol port of the vehicle computer under test is in an open state. For example, the datagram protocol port can be a UDP port. This signal is a specific data packet or message that contains the port information that the test terminal wants to query.

[0086] S302, receiving a first port status signal returned by the vehicle computer under test;

[0087] Here, after receiving the port status detection signal, the tested vehicle computer will check the status of the specified datagram protocol port and return a first port status signal to the test terminal. This signal contains the current status information of the port, that is, whether the port is open or closed.

[0088] S303, determining whether the first port status signal indicates that the datagram protocol port is in an open state;

[0089] In this step, after receiving the first port status signal, the test terminal will parse the signal and determine whether the datagram protocol port is in an open state. This judgment is based on the status information contained in the signal. For example, if the status information contained in the signal is 1, it indicates an open state, and if it is 0, it indicates a closed state.

[0090] S304, if the first port status signal indicates that the datagram protocol port is in an open state, sending a test instruction to the Ethernet interface card for testing;

[0091] Here, if the port is in open state: it means that the vehicle computer under test is ready to receive test data or instructions, so the test terminal will continue to execute the test process and send the test instructions to the Ethernet interface card to send test data or perform test operations to the vehicle computer under test through the interface.

[0092] The start test instruction includes a project identifier, which corresponds to a test item one by one. Each test item includes multiple test cases, and each test case includes multiple test instructions.

[0093] Specifically, the test terminal determines the test instruction in the following manner:

[0094] In response to a start test instruction, determining a target test item according to the function identifier;

[0095] Determine the test cases from the target test project and determine the test instructions to be issued according to the preset cycle of the test cases.

[0096] Among them, the start test instruction is the starting point of the test process. It contains the key information of the project identification. The project identification is a unique identifier that corresponds one-to-one to a specific test item, which means that each test item has a unique project identification for distinguishing and identifying it in the test system.

[0097] When the test terminal receives a start test instruction, it will first parse the project identifier in the instruction. Then, the test terminal will consult its internal test project database or configuration file to find the target test project that matches the project identifier. This process ensures that the test terminal can accurately locate the test project to be executed.

[0098] Once the target test project is determined, the test terminal will further review the test cases of the project. Each test project usually contains multiple test cases, which cover different functions and scenarios of the project. The test terminal will select appropriate test cases to execute based on the requirements and test strategies of the test project.

[0099] Each test case usually consists of multiple test instructions, which are sent to the device under test (such as a vehicle computer) in a specific order and cycle. The cycle of the test instructions can be fixed (such as once per second) or triggered based on a specific event (such as after receiving a specific signal). The test terminal will determine when to send which test instructions based on the preset cycle defined in the test case.

[0100] After determining the test cases and the issuing cycle of test instructions, the test terminal will start issuing test instructions according to the predetermined plan. These instructions are transmitted through the communication interface (such as Ethernet interface card) between the test terminal and the device under test to trigger the device under test to perform corresponding test actions or responses.

[0101] While issuing test instructions, the test terminal will also monitor the response of the device under test, that is, receive test data and record test results. These results can be used for subsequent analysis and evaluation to determine whether the device under test meets the test requirements.

[0102] Through this mechanism, the test terminal can accurately locate the test items to be executed and issue test instructions according to the preset cycle of the test case, thereby ensuring the accuracy and reliability of the test. At the same time, this test process also supports flexible configuration and expansion to meet the needs of different test items.

[0103] Here, the test instructions can be sent manually or automatically.

[0104] In an optional embodiment, in the manual test mode, the tester needs to personally operate the test system and send the signal required for the test by clicking a specific signal. The tester first determines the type and parameters of the signal to be sent according to the test case or test requirement. Then, on the user interface of the test system, the tester finds a button or option corresponding to the required signal and clicks it to send the signal.

[0105] The manual test mode is flexible and immediate. Testers can adjust test parameters and signal types at any time according to actual conditions to meet different test requirements. At the same time, since testers are directly involved in the test process, problems can be discovered and solved in a timely manner.

[0106] In another optional embodiment, in the automatic test mode, the test system will automatically send signals according to the pre-written test case (CASE) and automatically compare the results. The tester first writes the test case, including test steps, signal type, parameter settings, expected results, etc. Then, on the user interface of the test system, select the corresponding test case and click the "Start" button to start the automatic test process; the test system will automatically send signals according to the steps and parameter settings in the test case, and obtain the response data of the device or system under test through the serial port; finally, the test system will automatically compare the actual results with the expected results and output the test results.

[0107] The automatic test mode is characterized by high efficiency and accuracy. Since the test process is automatically completed by the test system, it can greatly improve the test efficiency and reduce the test errors caused by human factors. At the same time, automatic testing can also realize the automatic recording and preservation of test data, which is convenient for subsequent analysis and evaluation.

[0108] S305: If the first port status signal indicates that the datagram protocol port is in an unopened state, a port connection signal is sent to the vehicle computer under test.

[0109] If the port is not open: this means that the vehicle computer under test is not ready to receive test data or instructions, which may be due to configuration errors, software not started, connection line disconnection or other reasons. In this case, the test terminal will send a port connection signal to the vehicle computer under test to try to establish or re-establish the port connection.

[0110] This port connection signal may be a UDP Socket. UDP Socket is a communication method based on UDP (User Datagram Protocol). UDP is a connectionless, unreliable transport layer protocol. Compared with TCP (Transmission Control Protocol), it provides lower overhead and faster transmission speed.

[0111] Through the above steps, the test terminal can ensure that the communication port between the test computer and the vehicle under test is in the correct state before starting the test, thereby avoiding test failure or data loss due to the port not being opened. This is an important part of the test process, ensuring the accuracy and reliability of the test.

[0112] When the test terminal detects that the datagram protocol port (such as TCP / UDP port) is not in an open state, it will try to establish or re-establish a connection with the vehicle computer under test by sending a port connection signal.

[0113] Specifically, the test terminal is further configured as follows:

[0114] Receiving a second port status signal returned by the vehicle computer under test, the second port status signal being a signal returned by the vehicle computer under test to the test terminal after receiving the port connection signal;

[0115] Here, after the tested vehicle computer receives the port connection signal sent by the test terminal, it will check the status of the specified datagram protocol port and return a second port status signal to the test terminal. This signal also contains the current status information of the port, that is, whether the port has been successfully opened.

[0116] Determine whether the second port status signal indicates that the datagram protocol port is in an open state; if the second port status signal indicates that the datagram protocol port is in an open state, send a test instruction to the Ethernet interface card for testing; if the second port status signal indicates that the datagram protocol port is not in an open state, then when the preset conditions are met, display a connection failure.

[0117] After receiving the second port status signal, the test terminal will parse the signal and determine again whether the datagram protocol port is in an open state. This determination is based on the status information contained in the signal, usually by checking a specific field or flag bit in the signal.

[0118] If the port is in open state: this means that after the test terminal's attempt, the datagram protocol port of the tested vehicle computer has been successfully opened and is ready to receive test data or instructions. Therefore, the test terminal will continue to execute the test process and send the test instructions to the Ethernet interface card to send test data or perform test operations to the tested vehicle computer through the interface.

[0119] If the port is still not open: This means that although the test terminal has tried to establish or re-establish a connection, the datagram protocol port of the vehicle computer under test is still not open. This may be due to a configuration error, software failure, network problem or other reasons. In this case, the test terminal will not immediately display a connection failure, but will check whether the preset conditions are met to decide whether to display the connection failure information.

[0120] Preconditions may include:

[0121] Retry count: The test terminal may have set a maximum retry count, which is the number of attempts to establish a connection before displaying a connection failure. If the test terminal still cannot open the port before reaching the maximum retry count, it will display a connection failure.

[0122] Time interval: The test terminal may set a time interval between each attempt to establish a connection to avoid sending connection requests too frequently. If the port is still not open within this time interval, the test terminal may continue to try until the maximum number of retries is reached.

[0123] Other conditions: In addition to the number of retries and the time interval, the preset conditions may also include other factors, such as network status, response time of the tested vehicle computer, etc.

[0124] If the test terminal still cannot open the datagram protocol port after the preset conditions are met, it will display a connection failure message, which may include an error code, error description, or suggested solution steps to help testers or maintenance personnel diagnose the problem and take appropriate measures.

[0125] Through such steps, the test terminal can ensure that the communication port between the vehicle computer under test is in the correct state before starting the test, or provide useful error information when the connection cannot be established. This helps to improve the accuracy and reliability of the test and reduce test failures caused by configuration errors or network problems.

[0126] Specifically, the test terminal is not only responsible for sending test instructions and receiving port status signals, but also for recording and judging the number of times the datagram protocol port open status is returned. This mechanism ensures that when the test terminal attempts to establish a connection with the vehicle computer under test, it can intelligently handle the situation where the port is not open, and continue to try if necessary until the preset conditions are met or the maximum number of attempts is reached.

[0127] In an optional embodiment, the test terminal is further configured to:

[0128] Record the number of times the second port status signal indicates that the datagram protocol port is in an open state;

[0129] Here, each time the test terminal receives the second port status signal returned by the vehicle computer under test, it will check whether the signal indicates that the datagram protocol port is in the open state. If the port is already open, the test terminal will record this successful return, that is, the number of times the port is in the open state. This record is cumulative, and the count will increase each time the port is successfully opened.

[0130] Determine whether the number of returns is greater than the preset number; if the number of returns is not greater than the preset number, it is considered that the preset condition is not met, and the port connection signal continues to be sent to the vehicle computer under test, and the second port status signal returned by the vehicle computer under test is received.

[0131] Specifically, the test terminal periodically or each time after receiving the second port status signal, determines whether the number of returns currently recorded has exceeded a preset threshold or number of times. The preset number of times is a parameter defined in the test process, which is used to determine how many times the test terminal should try to open the port before displaying a connection failure.

[0132] If the number of returned times is not greater than the preset number: this means that although the test terminal has tried many times, the datagram protocol port has not been stably opened to the preset number of times. In this case, the test terminal believes that the preset condition has not been met, that is, the threshold for considering the port to be stably opened or giving up the attempt has not been reached.

[0133] Therefore, the test terminal will continue to send port connection signals to the vehicle computer under test and wait to receive new second port status signals. This process is cyclic until the number of returns exceeds the preset number, or the test terminal decides to stop trying (the maximum number of attempts or other stop conditions are reached).

[0134] Here, the preset number of times is set based on a variety of factors, including:

[0135] Response time of the tested onboard computer: If the onboard computer responds slowly, it may take multiple attempts to successfully open the port;

[0136] Network stability: Network fluctuations may cause the port status to be unstable. Multiple attempts can increase the chances of successfully establishing a connection.

[0137] Test efficiency: Too many attempts may waste time and resources, so it is necessary to maximize test efficiency while ensuring reliability.

[0138] Once the number of returns exceeds the preset number, the test terminal may take one of the following steps:

[0139] Send test command: If the port has been stably opened, the test terminal will send a test command to the Ethernet interface card for testing;

[0140] Displays a connection failure: If the port cannot be opened despite multiple attempts, the test terminal will display a connection failure message and may provide an error code or suggested resolution steps.

[0141] Through such a mechanism, the test terminal can intelligently handle issues related to the status of the communication port of the vehicle computer under test, thereby improving the reliability and efficiency of the test.

[0142] For example, you can also test the battery power signal of the ECU. First, fill in the relevant ECU test parameters, and then connect to the test environment, such as the connection of the test terminal, Ethernet interface card, the vehicle computer under test, and the programmable power supply. The test terminal selects the test case to be executed, starts the test, establishes a UDP connection, and sends the PDU datagram of the battery power signal according to the filled test parameters. Collect related test data, serial port data, Ethernet data packets, etc. Finally, according to the collected data, parse the corresponding data bits of the serial port collected data to see if they are consistent with the expected values, output the test results, and automatically save the bus log, ECU system log, test debug log, etc. according to the test date and test case name to generate an analyzable report.

[0143] This application improves the feasibility of the test environment requirements by using advanced data analysis algorithms, generates test cases based on the UDP data routing table, automates the testing, and eliminates the need for testers to manually assemble packages for sending. It provides a user-friendly operation interface so that non-professionals can easily perform test operations.

[0144] Based on the same inventive concept, an Ethernet-based testing method corresponding to an Ethernet-based testing system is also provided in the embodiments of the present application. Since the principle of solving the problem by the method in the embodiments of the present application is similar to that of the above-mentioned Ethernet-based testing system in the embodiments of the present application, the implementation of the method can refer to the implementation of the device, and the repeated parts will not be repeated.

[0145] See also Figure 4 , Figure 4 The following is a flow chart of the Ethernet-based testing method provided in the embodiment of the present application. Figure 4 As shown in, the test method is applied to an Ethernet-based test system, the Ethernet-based test system includes a test terminal and an Ethernet interface card, the first USB interface of the test terminal is connected to the USB interface of the Ethernet interface card, the Ethernet twisted pair interface of the Ethernet interface card is connected to the Ethernet twisted pair interface of the tested vehicle computer, the serial communication interface of the tested vehicle computer is connected to the second USB interface of the test terminal, and the test method includes:

[0146] S401, the Ethernet interface card is used to receive a test instruction issued by the test terminal, and forward the test instruction to the vehicle computer under test;

[0147] S402, the vehicle computer under test is used to receive the test instruction forwarded by the Ethernet interface card, parse the test instruction, generate test data, and send the test data to the test terminal;

[0148] S403, the test terminal is used to send the test instruction to the Ethernet interface card, and to receive the test data returned by the tested vehicle computer, and compare the test data with the preset data to determine the detection result of the tested vehicle computer.

[0149] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0150] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some communication interfaces, and the indirect coupling or communication connection of devices or units can be electrical, mechanical or other forms.

[0151] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0152] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0153] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a non-volatile computer-readable storage medium that is executable by a processor. Based on this understanding, the technical solution of the present application can essentially be embodied in the form of a software product, or in other words, the part that contributes to the prior art or the part of the technical solution. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0154] Finally, it should be noted that the above-described embodiments are only specific implementation methods of the present application, which are used to illustrate the technical solutions of the present application, rather than to limit them. The protection scope of the present application is not limited thereto. Although the present application is described in detail with reference to the above-mentioned embodiments, ordinary technicians in the field should understand that any technician familiar with the technical field can still modify the technical solutions recorded in the above-mentioned embodiments within the technical scope disclosed in the present application, or can easily think of changes, or make equivalent replacements for some of the technical features therein; and these modifications, changes or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be based on the protection scope of the claims.

Claims

1. A test system based on Ethernet, characterized in that: The device comprises a test terminal and an Ethernet interface card, wherein a first USB interface of the test terminal is connected to a USB interface of the Ethernet interface card, an Ethernet twisted pair interface of the Ethernet interface card is connected to an Ethernet twisted pair interface of a vehicle computer under test, and a serial communication interface of the vehicle computer under test is connected to a second USB interface of the test terminal. Wherein, the Ethernet interface card is used to receive the test instruction issued by the test terminal and forward the test instruction to the vehicle computer under test; The tested vehicle computer is used to receive the test instruction forwarded by the Ethernet interface card, parse the test instruction, generate test data, and send the test data to the test terminal; The test terminal is used to send test instructions to the Ethernet interface card, and to receive test data returned by the tested vehicle computer, and to compare the test data with preset data to determine the detection result of the tested vehicle computer.

2. The system according to claim 1, characterized in that The system further comprises: a program-controlled power supply, wherein a power supply interface of the program-controlled power supply is connected to a power supply interface of the vehicle computer under test; Wherein, the test terminal is configured as follows: Sending a power supply start instruction to the programmable power supply to control the programmable power supply to supply power to the vehicle computer under test; The current and voltage of the vehicle computer under test sent by the programmable power supply are received to collect data.

3. The system according to claim 2, characterized in that The test terminal is further configured as: Obtaining a CAN requirement matrix, wherein the CAN requirement matrix includes a plurality of requirement fields; Extracting the target field in the CAN demand matrix, and generating a data routing table for the target field; According to the data routing table, the test items are divided, and the test cases under each test item are determined, and each test case includes a plurality of test instructions.

4. The system according to claim 1, characterized in that The test terminal is further configured as: In response to a start test instruction, sending a port status detection signal to the vehicle computer under test; Receiving a first port status signal returned by the vehicle computer under test; Determining whether the first port status signal indicates that the datagram protocol port is in an open state; If the first port status signal indicates that the datagram protocol port is in an open state, sending the test instruction to the Ethernet interface card for testing; If the first port status signal indicates that the datagram protocol port is in an unopened state, a port connection signal is sent to the vehicle computer under test.

5. The system according to claim 4, characterized in that The test terminal is further configured as: Receiving a second port status signal returned by the vehicle computer under test, wherein the second port status signal is a signal returned by the vehicle computer under test to the test terminal after receiving the port connection signal; Determining whether the second port status signal indicates that the datagram protocol port is in an open state; If the second port status signal indicates that the datagram protocol port is in an open state, sending the test instruction to the Ethernet interface card for testing; If the second port status signal indicates that the datagram protocol port is not open, then when a preset condition is met, a connection failure is displayed.

6. The system according to claim 5, characterized in that The test terminal is further configured as: Recording the number of times the second port status signal indicates that the datagram protocol port is in an open state; Determine whether the number of returns is greater than a preset number; If the number of returns is not greater than the preset number of times, it is considered that the preset condition is not met, and the port connection signal continues to be sent to the vehicle computer under test, and the second port status signal returned by the vehicle computer under test is received.

7. The system according to claim 4, characterized in that The start test instruction includes a project identifier, the project identifier corresponds to the test project one by one, each test project includes multiple test cases, each test case includes multiple test instructions, Wherein, the test terminal is further configured as: In response to a start test instruction, determining a target test item according to the function identifier; A test case is determined from the target test project, and a test instruction to be issued is determined according to a preset period of the test case.

8. The system according to claim 1, characterized in that The test data includes a data sequence and a sequence identifier. Wherein, the test terminal is further configured as: Locating target data at a target position in a data sequence according to the sequence identifier; The target data is compared with the preset data, and a comparison result is output.

9. The system according to claim 8, characterized in that The test terminal is further configured as: Determining whether the target data is consistent with the preset data; If the target data is consistent with the preset data, it means that the test result of the test item corresponding to the target data is successful, and the comparison result is determined to be a successful test; If the target data and the preset data are inconsistent, it means that the test result of the test item corresponding to the target data is unsuccessful, and the comparison result is determined to be that the test is unsuccessful.

10. A testing method based on Ethernet, characterized in that: The invention is applied to an Ethernet-based test system, wherein the Ethernet-based test system comprises a test terminal and an Ethernet interface card, wherein a first USB interface of the test terminal is connected to a USB interface of the Ethernet interface card, an Ethernet twisted pair interface of the Ethernet interface card is connected to an Ethernet twisted pair interface of a vehicle computer under test, and a serial communication interface of the vehicle computer under test is connected to a second USB interface of the test terminal, and the method comprises: The Ethernet interface card is used to receive the test instruction sent by the test terminal and forward the test instruction to the vehicle computer under test; The tested vehicle computer is used to receive the test instruction forwarded by the Ethernet interface card, parse the test instruction, generate test data, and send the test data to the test terminal; The test terminal is used to send test instructions to the Ethernet interface card, and to receive test data returned by the tested on-board computer, and to compare the test data with preset data to determine the detection result of the tested on-board computer.

Images