A vehicle Ethernet monitoring system and a monitoring method

Abstract

The embodiment of the present application is to provide a vehicle-mounted Ethernet monitoring system and a monitoring method, which belongs to the technical field of automotive Ethernet testing. The monitoring system includes a test equipment module and a communication module; the test equipment module is used to communicate with the communication module in a two-way manner, and the test equipment module is used to run the test program stored in the test equipment module; the communication module is used to connect the device under test through Ethernet and CAN bus, to receive instructions from the test equipment module and send them to the device under test, and to receive test feedback information from the device under test and synchronize it to the test equipment module. The present application is intended to facilitate the monitoring of vehicle-mounted Ethernet.

Description

Technical Field

[0001] The embodiments of the present application relate to the technical field of automotive Ethernet testing, and in particular, to a vehicle Ethernet monitoring system and a monitoring method. Background Art

[0002] With the development of social technology, the development speed of automobiles is also getting faster and faster, including automobile communication technology. As a widely used new generation of communication technology, in-vehicle Ethernet is widely used in infotainment systems and smart cockpit systems.

[0003] However, since the DUT (Device Under Test) at both ends of the Ethernet often has connection interruptions or cannot establish connections during the communication process, in order to analyze the problems of the Ethernet, it is necessary to monitor the in-vehicle Ethernet. Summary of the invention

[0004] The embodiments of the present application provide a vehicle-mounted Ethernet monitoring system and a monitoring method, which are intended to facilitate monitoring of the vehicle-mounted Ethernet.

[0005] In a first aspect, an embodiment of the present application provides a vehicle Ethernet monitoring system, including a test device module and a communication module;

[0006] The test equipment module is used for bidirectional communication connection with the communication module, and the test equipment module is used for running the test program stored in the test equipment module;

[0007] The communication module is used to connect to the device under test via Ethernet and CAN bus, to receive instructions from the test device module and send them to the device under test, and to receive test feedback information from the device under test and synchronize it to the test device module.

[0008] Optionally, the test equipment module includes a test program storage unit and the test program running unit;

[0009] The test program storage unit is used to store a test program for testing the device under test;

[0010] The test program running unit is used to run the test program based on the user's operation.

[0011] Optionally, the system also includes a relay module, an input end of the relay module is communicatively connected to the test equipment module, and an output end of the relay module is used to connect to the device under test to simulate a vehicle environment to power on and off the device under test under the control of the test equipment module.

[0012] Optionally, the system further comprises a power supply module, and the power supply module is used to provide a working voltage to the device under test and the relay module.

[0013] Optionally, the system further comprises a remote monitoring module, which is wirelessly connected to the test equipment module for remotely displaying test results.

[0014] Optionally, the remote monitoring module includes a target application configured on the mobile terminal or the remote monitoring module is configured on the mobile terminal.

[0015] In a second aspect, an embodiment of the present application provides a vehicle Ethernet monitoring method, which is applied to a vehicle Ethernet detection system, and the method includes:

[0016] Running the test program stored on the test device module, establishing Ethernet and CAN communications with the device under test, and testing the network communication of the device under test;

[0017] Receive test feedback information of the device under test.

[0018] Optionally, running a test program stored on a test device to test network communication of the device under test includes:

[0019] Receive test operations performed by users on the test;

[0020] In response to the test operation, a test program stored in the test device is run to test the network communication of the device under test.

[0021] Optionally, the vehicle Ethernet monitoring system includes a relay module, and the method further includes:

[0022] During the test, the relay module is controlled to simulate a vehicle-mounted environment to power on and off the device under test.

[0023] Optionally, the method further comprises:

[0024] Determine the test result according to the test feedback information;

[0025] The test result is sent to a remote display terminal.

[0026] Beneficial effects:

[0027] The device under test on the vehicle is connected to the communication module via Ethernet and CAN bus, and then the test program stored in the test device module is run through the test device module. The communication module receives the instructions of the test device module and sends them to the device under test. The device under test sends the test feedback information to the communication module, and the communication module sends the test feedback information to the test device module. In this way, the vehicle-mounted Ethernet can be monitored conveniently, and the problems that often occur in the vehicle-mounted Ethernet can be analyzed through the test feedback information. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the description of the embodiments of the present application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0029] Figure 1 It is a functional module diagram of a vehicle Ethernet monitoring system proposed in one embodiment of the present application;

[0030] Figure 2 It is a functional module diagram of a vehicle Ethernet monitoring system proposed in one embodiment of the present application;

[0031] Figure 3 It is a flowchart of the steps of the vehicle Ethernet monitoring method proposed in one embodiment of the present application.

[0032] Description of the drawings: 1. Test equipment module; 2. Communication module; 3. Relay module; 4. Power module; 5. Remote monitoring module. DETAILED DESCRIPTION

[0033] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. The described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0034] Embodiment 1

[0035] Reference Figure 1 , showing a functional module diagram of a vehicle Ethernet monitoring system in an embodiment of the present invention, referring to Figure 1 , the vehicle Ethernet detection system specifically includes a test equipment module 1 and a communication module 2;

[0036] The test equipment module 1 is used for bidirectional communication connection with the communication module 2, and the test equipment module 1 is used for running the test program stored in the test equipment module 1;

[0037] The communication module 2 is used to connect to the device under test via Ethernet and CAN bus, to receive instructions from the test device module 1 and send them to the device under test, and to receive test feedback information from the device under test and synchronize it to the test device module 1.

[0038] Among them, the device under test can be a car Tbox or other ECU used in the vehicle that supports vehicle Ethernet communication. When testing the vehicle Ethernet, the device under test can be connected inside the vehicle for testing. When testing inside the vehicle, it needs to be parked. It can also be tested outside the vehicle, and the components of the vehicle need to be disassembled and moved outside the vehicle for testing.

[0039] The test device module 1 is specifically a hardware device that can run software programs. The test device module 1 in this embodiment can be a PC computer. The developed test code is stored in the PC computer in advance, and the test code is converted into a test program that can be run on the hardware, such as .exe. The test program contains a variety of test cases for testing Ethernet.

[0040] The test equipment module 1 and the communication module 2 are connected in a two-way communication manner, so that the test equipment module 1 can send instructions to the communication module 2, and the communication module 2 can synchronize the test feedback information to the test equipment module 1.

[0041] The communication module 2 is a hardware with Ethernet communication function and CAN communication function, which can perform Ethernet SOMEIP communication and CAN communication with the device under test. During the test, the device under test can be awakened and dormant periodically, and CAN communication is mainly used to wake up the device under test.

[0042] The communication module 2 in this embodiment can be VN5620, which is connected to the USB interface of the PC. VN5620 is equivalent to the interaction between the vehicle-mounted host and the device under test; VN5620 receives instructions from the test equipment module 1, and receives test feedback information from the device under test, and then synchronizes the test feedback information to the test equipment module 1 via the USB line.

[0043] In a feasible implementation, the test device module 1 includes two test programs, including a Python main program and a ".cfg" project file; wherein the ".cfg" project file will determine whether an abnormality has occurred in the Ethernet through the received test feedback information, wherein the test feedback information includes CAN feedback information and Ethernet feedback information.

[0044] If an Ethernet exception occurs, the value of the intermediate variable will be set. The initial value of the intermediate variable is 0. During the running process of the Python main program, the value of the intermediate variable generated by the ".cfg" project file is read in real time. If the value of this variable is not 0, the type of Ethernet exception is determined and the detection result is returned to the user.

[0045] The device under test on the vehicle is connected to the communication module 2 via Ethernet and CAN bus, and then the test program stored in the test device module 1 is run through the test device module 1. After the communication module 2 receives the instruction of the test device module 1, Ethernet and CAN communication are established between the communication module 2 and the device under test, and then the test program contains test cases that can detect the device under test.

[0046] The device under test sends the test feedback information to the communication module 2. Since Ethernet and CAN communications are established between the communication module 2 and the device under test, the test feedback information can include Ethernet feedback information and CAN feedback information, and the communication module 2 synchronizes the test feedback information to the test device module 1 via USB. The test device module 1 can obtain the final test result based on the test feedback information. In this way, it is convenient to monitor the vehicle-mounted Ethernet, and problems with the vehicle-mounted Ethernet can also be analyzed through the test feedback information.

[0047] Specifically, the test device module 1 includes a test program storage unit and a test program running unit; wherein the test program storage unit is used to store a test program for testing the device under test; and the test program running unit is used to run the test program based on user operations.

[0048] Based on the problem test that the user needs to perform on the Ethernet, a test program corresponding to the problem test is pre-stored in a test program storage unit, and the pre-stored test program is run in a test program running unit to obtain a test result, which reflects various problems of the Ethernet during the communication process.

[0049] In practical applications, the test program in the vehicle storage unit can be updated and replaced. Depending on the test problems and test objects that the user wants to test, the test program stored in the storage unit can be updated, thereby improving the adaptability of the monitoring system.

[0050] In actual application, if the test device module 1 is a PC, the user can click on the test program to run through input devices such as a mouse or keyboard;

[0051] If the test device module 1 is a tablet computer with a touch screen, the user can directly click to run the test program through the interactive interface; the user can even send a voice command to execute the test program to the test device module 1 through a voice assistant.

[0052] Specifically, refer to Figure 2 The system also includes a relay module 3, the input end of the relay module 3 is connected to the test equipment module 1 via RS232 communication of USB, and the output end of the relay module 3 is used to connect to the device under test to simulate the vehicle environment under the control of the test equipment module 1 to power on and off the device under test.

[0053] When the test equipment module 1 runs the test program, it controls the relay module 3 to power on and off KL15 of the device under test. KL15 of the device under test (when the vehicle power is in ON mode, it is the low-voltage battery voltage of the whole vehicle, and when it is in OFF mode, the voltage is 0) refers to the pin of the control unit under test that receives the ignition signal; in the actual vehicle, the device under test is generally awakened by both CAN and engine ignition signals at the same time. Therefore, by setting the relay module 3, a simulated vehicle environment that is closer to the actual vehicle can be created for the device under test.

[0054] Specifically, refer to Figure 2 The system also includes a power supply module 4, which is used to provide a working voltage to the device under test and the relay module 3.

[0055] When the test environment is outside the vehicle, a working voltage can be provided to the relay module 3 and the device under test through the power module 4; further, the power module 4 can also include a power conversion unit that can convert 220V AC power into 12V DC power, thereby providing a vehicle-mounted working voltage to the relay module 3 and the device under test.

[0056] Specifically, refer to Figure 2 The system further comprises a remote monitoring module 5, which is wirelessly connected to the test equipment module 1 for remotely displaying the test results.

[0057] After the test device module 1 runs the test program, it will obtain the test result. The test device module 1 sends the test result to the remote monitoring module 5 through wireless communication, so that the user can obtain the test result remotely.

[0058] The remote monitoring module 5 may be a mobile terminal, such as a mobile phone and a mobile PC. The test results may be sent by remote wireless communication via a local area network or by connecting to a server.

[0059] In one embodiment, the remote monitoring module 5 includes a target application configured on the mobile terminal or the remote monitoring module 5 is configured on the mobile terminal, such as the DingTalk APP. By creating a custom robot in the DingTalk APP, the robot's API is obtained, and then the test results can be output to the DingTalk APP through programming, so that the test results can be obtained remotely through the DingTalk APP on the mobile phone.

[0060] The following is a detailed description of the vehicle Ethernet detection system of the present application in combination with examples in specific practical applications:

[0061] Among them, the test equipment module 1 is a PC computer, and the communication module 2 can be VN5620; wherein, the PC computer can both store and run the test program. The test program is divided into two parts, namely the main program developed based on Python, and the ".cfg" project file developed based on CANoe software. The ".cfg" project file contains CAPL program files for Ethernet communication and CAN communication.

[0062] The Python program is used to control the operation of the ".cfg" project file. The ".cfg" project file is made using CANoe software, and the ".cfg" project file also contains Ethernet and CAN communication program files written by CAPL; when running the Python program on the PC, the Python program will call the COM port of the CANoe api, open and run the ".cfg" project file, and control the relay program to run; when running the ".cfg" project file, control the Ethernet someip communication and CAN communication between VN5620 and the device under test, and determine whether an abnormality has occurred based on the Ethernet feedback information and CAN feedback information returned by the device under test; running the control relay program controls the relay module 3 to power on and off KL15 of the device under test.

[0063] If an exception occurs, the ".cfg" project file will change the value of an intermediate variable (the initial value can be set to 0), and the main program written in Python will read the value of this intermediate variable in the ".cfg" project file in real time and make a judgment. Depending on the value of the intermediate variable, the corresponding test problem result information will be sent to DingTalk through the DingTalk API.

[0064] The ".cfg" project file includes test cases for testing the Ethernet frequent linkdown bug, the SOMEIP establishment bug, the device under test not sleeping bug, the device under test not waking up after sleeping bug, and the bus off bug.

[0065] The bug test method for Ethernet frequent linkdown is as follows: through the Ethernet status monitoring function of CANoe's CAPL library, determine whether the device under test has linkdown; if the device under test has linkdown, the function return value is 0, if the device under test has linkup, this function returns 1; when the number of times the return value 0 is greater than 2 or other calibration values ​​within a sleep cycle time, it is considered that Ethernet has frequent linkdown.

[0066] The bug test method for SOMEIP failure to establish is: when the device under test communicates with CANoe, SOMEIP interaction will be established between the device under test and CANoe. If the device under test does not send a SOMEIP subscription ACK message within a sleep cycle, it means that SOMEIP has not been established successfully.

[0067] The bug test method for the device under test not sleeping is: according to the AUTOSAR network specification, after being awakened, the device under test sends network management frame CAN messages in a 500ms period. Assuming that a sleep cycle is 17 minutes, the wake-up time is 5 minutes, and the sleep time is 12 minutes, the number of network management frames during the wake-up period of the device under test should be 300s / 500ms=600 frames. If the device under test does not sleep all the time, then 17*60 / 500ms=2040 frames. If the number of network management frame transmissions is monitored by CANoe and CAPL and its value is much greater than 600, for example, the device under test sends 1500 frames, it is considered that the device under test does not sleep.

[0068] The bug testing method for the device under test that cannot be woken up after sleep is the same as the detection method for the Ethernet frequent linkdown bug. If the number of linkups is less than 1 within a sleep cycle, it is considered that the Ethernet of the device under test does not work after waking up.

[0069] A bus off bug has occurred: Use the on busOff function of the CAPL library of CANoe to detect whether the CAN bus has experienced a busoff phenomenon.

[0070] Embodiment 2

[0071] Based on the same inventive concept, Figure 3 A flowchart of a vehicle Ethernet monitoring method is shown, and the monitoring method is applied to a vehicle Ethernet detection system. The method may specifically include:

[0072] S101, running the test program stored in the test device module 1, establishing Ethernet and CAN communications with the device under test, and testing the network communication of the device under test;

[0073] In this step, after detecting the hardware connection with the device under test, based on the user's instructions, the test device module 1 runs the test program and sends instructions to the communication module 2; taking the test device module 1 as a PC as an example, the developed test code is stored in the PC in advance, and the test code is converted into a test program that can be run on the hardware, such as .exe; when testing is required, the test device module 1 runs the test program based on the user's operation.

[0074] The test program may include a program written in Python language and a ".cfg" project file produced by CANoe software, and the ".cfg" project file includes Ethernet and CAN communication program files written in CAPL, and Ethernet and CAN communication program files written in CAPL.

[0075] The communication module 2 receives the instruction of the test device module 1, and the communication module 2 starts to establish Ethernet and CAN communication with the device under test. For example, when the ".cfg" project file is running, the communication module 2 is controlled to establish Ethernet someip communication and CAN communication with the device under test.

[0076] The ".cfg" project file includes test cases for testing the Ethernet frequent linkdown bug, the SOMEIP establishment bug, the device under test not sleeping bug, the device under test not waking up after sleeping bug, and the bus off bug, so that various tests can be performed on the test equipment.

[0077] S102: Receive test feedback information of the device under test.

[0078] In this step, the communication module 2 receives Ethernet feedback information and CAN feedback information. When an exception occurs, the value of the intermediate variable in the ".cfg" project file will change; the communication module 2 receives the test feedback information of the device under test and synchronizes it to the test device module 1.

[0079] For example, the Python program reads the values ​​of intermediate variables in the ".cfg" project file in real time and makes judgments to obtain detection results, which can facilitate the monitoring of the vehicle Ethernet. Problems with the vehicle Ethernet can also be analyzed through test feedback information.

[0080] Specifically, step S101, running the test program stored in the test device module 1, establishing Ethernet and CAN communication with the device under test, and testing the network communication of the device under test, including:

[0081] S1011, receiving a test operation performed by a user on a test;

[0082] In this step, if the test device module 1 is a PC computer, the user can click on the test program to run through input devices such as a mouse or keyboard; if the test device module 1 is a tablet computer with a touch screen, the user can directly click on the test program to run through the interactive interface; and even through a voice assistant, a voice command to execute the test program can be sent to the test device module 1.

[0083] S1012. In response to the test operation, run the test program stored on the test device, establish Ethernet and CAN communications with the device under test, and test the network communication of the device under test.

[0084] In this step, based on the test operation corresponding to the user running the test program, the test program stored on the test device is run, Ethernet and CAN communications are established with the device under test, and the network communication of the device under test is tested.

[0085] Specifically, the vehicle Ethernet monitoring system includes a relay module 3, and the method further includes:

[0086] During the test, the relay module 3 is controlled to simulate a vehicle-mounted environment to power on and off the device under test.

[0087] When the test equipment module 1 runs the test program, it controls the relay module 3 to power on and off the KL15 of the device under test. The KL15 of the device under test refers to the pin of the control unit under test that receives the ignition signal. By setting the relay module 3, a simulated vehicle environment that is closer to the real vehicle can be created for the device under test.

[0088] Specifically, the method further includes:

[0089] S103, determining a test result according to the test feedback information;

[0090] In this step, for example, the Python program reads the values ​​of the intermediate variables in the ".cfg" project file in real time and makes judgments to obtain the detection results, so that the vehicle Ethernet can be monitored easily, and the problems of the vehicle Ethernet can also be analyzed through the test feedback information.

[0091] S104: Send the test result to a remote display terminal.

[0092] In this step, after the Python program reads the value of the intermediate variable in the ".cfg" project file and makes a judgment to obtain the test result, the test result can be sent to the remote display terminal. For example, the test result can be sent to the user's mobile phone, or by creating a custom robot in the DingTalk APP, the robot's API can be obtained, and then the test result can be output to the DingTalk APP through programming, so that the test result can be obtained remotely through the DingTalk APP on the mobile phone.

[0093] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0094] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, devices, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0095] The embodiments of the present application are described with reference to the flowcharts and / or block diagrams of the methods, terminal devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminal device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0096] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing terminal device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0097] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device so that a series of operating steps are executed on the computer or other programmable terminal device to produce a computer-implemented process, thereby providing instructions for implementing the process in the computer or other programmable terminal device. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0098] Although the preferred embodiments of the present application have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present application.

[0099] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or terminal device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or terminal device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or terminal device including the elements.

[0100] Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea. At the same time, for those skilled in the art, according to the idea of ​​the present application, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A vehicle Ethernet monitoring system, characterized in that: Including test equipment module and communication module; The test equipment module is used for bidirectional communication connection with the communication module, and the test equipment module is used for running the test program stored in the test equipment module; The communication module is used to connect the device under test through Ethernet and CAN bus, to receive instructions from the test device module and send them to the device under test, and to receive test feedback information from the device under test and synchronize it to the test device module; the test feedback information includes Ethernet feedback information and CAN feedback information; the device under test is a Tbox or other ECU on the vehicle that supports vehicle Ethernet communication; the communication module and the device under test communicate through Ethernet and CAN, and during the test, CAN communication is used to wake up the device under test; The test program includes a Python main program and a .cfg project file, wherein the Python main program is used to control the operation of the .cfg project file, and the .cfg project file is used to determine the abnormality of the Ethernet through the test feedback information, including: when an abnormality occurs in the Ethernet, the .cfg project file changes an intermediate variable, the intermediate variable is used to be read by the Python main program during operation, the initial value of the intermediate variable is 0, and when the intermediate variable is not 0, the type of abnormality of the Ethernet is determined; The .cfg project file includes test cases for testing the bug of frequent Ethernet linkdown, the bug of SOMEIP being unable to establish, the bug of the device under test not sleeping, the bug of the device under test not waking up after sleeping, and the bug of bus off.

2. The monitoring system according to claim 1, characterized in that: The test equipment module includes a test program storage unit and a test program running unit; The test program storage unit is used to store a test program for testing the device under test; The test program running unit is used to run the test program based on the user's operation.

3. The monitoring system according to claim 1, characterized in that: The system also includes a relay module, an input end of the relay module is communicatively connected to the test equipment module, and an output end of the relay module is used to connect to the device under test to simulate a vehicle environment to power on and off the device under test under the control of the test equipment module.

4. The monitoring system according to claim 3, characterized in that: The system further comprises a power supply module, and the power supply module is used to provide working voltage to the device under test and the relay module.

5. The monitoring system according to claim 1, characterized in that: The system further comprises a remote monitoring module, which is wirelessly connected to the test equipment module for remotely displaying the test results.

6. The monitoring system according to claim 5, characterized in that: The remote monitoring module is configured on the mobile terminal or on a target application of the mobile terminal.

7. A vehicle Ethernet monitoring method, characterized in that: Applied to a vehicle Ethernet monitoring system, the method comprises: Run the test program stored on the test device module, establish Ethernet and CAN communications with the device under test, and test the network communication of the device under test. During the test, the CAN communication is used to wake up the device under test; Receive test feedback information of the device under test; the test feedback information includes Ethernet feedback information and CAN feedback information; the device under test is a Tbox or other ECU on the vehicle that supports vehicle Ethernet communication; The test program includes a Python main program and a .cfg project file, wherein the Python main program is used to control the operation of the .cfg project file, and the .cfg project file is used to determine the abnormality of the Ethernet through the test feedback information, including: when an abnormality occurs in the Ethernet, the .cfg project file changes an intermediate variable, the intermediate variable is used to be read by the Python main program during operation, the initial value of the intermediate variable is 0, and when the intermediate variable is not 0, the type of abnormality of the Ethernet is determined; The .cfg project file includes test cases for testing the bug of frequent Ethernet linkdown, the bug of SOMEIP being unable to establish, the bug of the device under test not sleeping, the bug of the device under test not waking up after sleeping, and the bug of bus off.

8. The monitoring method according to claim 7, characterized in that: The running of the test program stored on the test device to test the network communication of the device under test includes: Receive test operations performed by users on the test; In response to the test operation, a test program stored in the test device is run to test the network communication of the device under test.

9. The monitoring method according to claim 7, characterized in that: The vehicle Ethernet monitoring system includes a relay module, and the method further includes: During the test, the relay module is controlled to simulate a vehicle-mounted environment to power on and off the device under test.

10. The monitoring method according to claim 7, characterized in that: The method further comprises: Determine the test result according to the test feedback information; The test result is sent to a remote display terminal.

Images