Remote upgrade test system and test method

Abstract

The invention provides a remote upgrade test system and a test method, the system comprises a test terminal and an Ethernet interface card, the Ethernet interface card is used for receiving package compression parameters sent by the test terminal and required for upgrade, and forwarding the package compression parameters required for upgrade to a tested ECU; the tested ECU is used for receiving the package compression parameters required by upgrading and forwarded by the Ethernet interface card, downloading a remote upgrading data packet from the remote upgrading server according to the package compression parameters required by upgrading, carrying out upgrading operation on the remote upgrading data packet, and sending upgrading data during upgrading to the test terminal; and the test terminal is used for sending package compression parameters required by upgrading to the Ethernet interface card, receiving upgrading feedback data returned by the tested ECU, comparing the upgrading feedback data with preset data, and determining a detection result for remote upgrading of the tested ECU. According to the method and the device, the test efficiency of remote upgrade of the tested ECU is improved.

Description

Technical Field

[0001] The present application relates to the field of vehicle engineering technology, and in particular to a remote upgrade test system and a test method. Background Art

[0002] At present, the shortcomings of the ECU upgrade in the existing technology can be summarized as follows:

[0003] Dependence on the car manufacturer platform: The existing ECU upgrade process is highly dependent on the platform provided by the car manufacturer. This means that if the car manufacturer platform fails, is maintained or adjusted, the upgrade process may be affected, resulting in interruption or delay of the upgrade operation.

[0004] Login account restrictions: Car company platforms usually require users to log in to download and upgrade the upgrade package. However, if the car company does not provide a login account, or there are problems with account management (such as forgotten passwords, account locks, etc.), it will cause inconvenience to the upgrade test, or even make it impossible to carry out.

[0005] Fixed and inconvenient process: The existing upgrade process is usually fixed and cannot be changed, which limits the flexibility of testing and the possibility of simulation. Fixed processes may not be suitable for all situations, especially when testing under specific conditions, which may encounter problems that are difficult to solve.

[0006] Lack of flexibility: As existing technologies are highly dependent on the car company platform, it is difficult to customize or optimize the upgrade process. This limits the room for innovation and improvement of car companies and test teams during the upgrade process.

[0007] Inefficient download and upgrade: Downloading upgrade packages through the car company platform may be affected by factors such as network speed and platform server performance, resulting in inefficient download and upgrade. This not only increases the time required for the upgrade, but may also affect the normal use of the ECU under test. Summary of the invention

[0008] In view of this, the purpose of the present application is to provide a remote upgrade test system and a test method to overcome at least one of the above-mentioned defects.

[0009] In a first aspect, an embodiment of the present application provides a remote upgrade test system, the system comprising a test terminal and an Ethernet interface card, the test terminal being communicatively connected to the ECU under test via the Ethernet interface card, wherein the Ethernet interface card is used to receive compressed package parameters required for the upgrade sent by the test terminal, and forward the compressed package parameters required for the upgrade to the ECU under test; the ECU under test is used to receive the compressed package parameters required for the upgrade forwarded by the Ethernet interface card, download a remote upgrade data packet from a remote upgrade server according to the compressed package parameters required for the upgrade, perform an upgrade operation on the remote upgrade data packet, and send the upgrade data during the upgrade to the test terminal; the test terminal is used to send the compressed package parameters required for the upgrade to the Ethernet interface card, and to receive upgrade feedback data returned by the ECU under test, and compare the upgrade feedback data with preset data to determine the detection result of the remote upgrade of the ECU under test.

[0010] In an optional embodiment of the present application, the test terminal is configured to: obtain an upgrade file, which includes multiple sub-files required for the upgrade; for each sub-file, extract the target parameters in the sub-file; based on the target parameters, determine the test case corresponding to the remote upgrade of the ECU under test, each test case includes multiple compressed package parameters required for the upgrade.

[0011] In an optional embodiment of the present application, the test terminal is further configured to: in response to a start test instruction, detect all messages sent by the ECU under test within a preset time period; determine whether there is a preset protocol message in all messages sent by the ECU under test received within the preset time period; if there is a preset protocol message in all messages sent by the ECU under test received within the preset time period, send a handshake request data frame to the ECU under test, and obtain a response data frame replied by the ECU under test, and determine whether the handshake request data frame matches the response data frame; if the handshake request data frame matches the response data frame, it is considered that the initialization is successful and the handshake is successful, and an upgrade download instruction is issued to the ECU under test; if the handshake request data frame does not match the response data frame, it is considered that the initialization is successful and the handshake fails, and the signal transmitted between the test terminal and the ECU under test is detected to perform handshake failure diagnosis; if the preset protocol message does not exist in all messages sent by the ECU under test received within the preset time period, it is considered that the initialization fails, and the connection between the test terminal and the ECU under test is detected to perform initialization failure diagnosis.

[0012] In an optional embodiment of the present application, the test terminal is further configured to: in response to successful initialization and successful handshake, send an upgrade parameter structure to the ECU under test, the upgrade parameter structure including a remote upgrade server download path and verification parameters, and the ECU under test is used to download a remote upgrade data packet from the remote upgrade server according to the remote upgrade server download path and the verification parameters; receive a compressed signal returned by the ECU under test; determine whether the compressed signal indicates that the remote upgrade data packet is in a decompressed state; if the compressed signal indicates that the remote upgrade data packet is in a decompressed state, send a status detection signal to the ECU under test; receive a status signal returned by the ECU under test; determine whether the status signal returned by the ECU under test indicates a successful decryption; if the status signal returned by the ECU under test indicates a successful decryption, continue with the subsequent judgment process; if the status signal returned by the ECU under test indicates a decryption failure, output a decryption failure, record the error cause, and end the test; if the compressed signal indicates that the remote upgrade data packet is not in a decompressed state, output a decompression failure, record the error cause, and end the test.

[0013] In an optional embodiment of the present application, the test terminal is further configured to: after detecting that the ECU under test has successfully decompressed and decrypted the remote upgrade data packet, send a verification signal to the ECU under test; receive a verification feedback signal returned by the ECU under test; determine whether the verification feedback signal is consistent with a preset verification signal; if the verification feedback signal is consistent with the preset verification signal, it indicates that the version upgrade file after decompression and decryption of the remote upgrade data packet is complete, and send a signature verification signal to the ECU under test; receive a signature verification feedback signal returned by the ECU under test; determine whether the signature verification feedback signal indicates that the file certificate corresponding to the version upgrade file is consistent with the preset certificate; if the signature verification feedback signal indicates that the file certificate corresponding to the version upgrade file is consistent with the preset certificate, the verification is completed, and a remote upgrade instruction is issued to the ECU under test; if the signature verification feedback signal indicates that the file certificate corresponding to the version upgrade file is inconsistent with the preset certificate, the signature verification fails, the error cause is recorded, and the test ends; if the verification feedback signal is inconsistent with the preset verification signal, it indicates that the version upgrade file is incomplete, the verification fails, the error cause is recorded, and the test ends.

[0014] In an optional embodiment of the present application, the test terminal is further configured to: in response to the issuance of the remote upgrade instruction, close the recording of diagnostic fault codes and the network communication of CAN signals; send installation instructions, and receive the installation progress signal of the ECU under test for the version upgrade file; determine whether the installation progress signal meets the preset installation requirements; if the installation progress signal meets the preset installation requirements, the verification is successful, the upgrade mode is terminated, and the recording of diagnostic fault codes and the network communication of CAN signals continues; if the installation progress signal does not meet the preset installation requirements, it is determined that the progress verification has failed and the test ends.

[0015] In an optional embodiment of the present application, the test terminal is further configured to: perform data analysis and resolve corresponding data bit parameters based on the log data returned by the ECU under test; determine whether the corresponding data bit parameters are equal to expected values; if the corresponding data bit parameters are equal to the expected values, the test is successful, the test log is saved, and a test report is generated; if the corresponding data bit parameters are not equal to the expected values, it indicates that the upgraded version number is abnormal and the test fails.

[0016] In an optional embodiment of the present application, the upgrade feedback 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 the preset data, and determine the detection result of the remote upgrade of the ECU under test based on the comparison result.

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

[0018] In a second aspect, an embodiment of the present application also provides a remote upgrade test method, which is applied to a remote upgrade test system, wherein the remote upgrade test system includes a test terminal and an Ethernet interface card, wherein the test terminal is communicatively connected to the ECU under test via the Ethernet interface card, and the method includes: wherein the Ethernet interface card is used to receive compressed package parameters required for the upgrade sent by the test terminal, and forward the compressed package parameters required for the upgrade to the ECU under test; the ECU under test is used to receive the compressed package parameters required for the upgrade forwarded by the Ethernet interface card, download a remote upgrade data packet from a remote upgrade server according to the compressed package parameters required for the upgrade, perform an upgrade operation on the remote upgrade data packet, and send the upgrade data during the upgrade to the test terminal; the test terminal is used to send the compressed package parameters required for the upgrade to the Ethernet interface card, and to receive the upgrade data returned by the ECU under test, and compare the upgrade data with preset data to determine the detection result of the remote upgrade of the ECU under test.

[0019] The remote upgrade test system and test method provided by the embodiment of the present application are as follows: the Ethernet interface card is used to receive the compressed package parameters required for the upgrade sent by the test terminal, and forward the compressed package parameters required for the upgrade to the ECU under test; the ECU under test is used to receive the compressed package parameters required for the upgrade forwarded by the Ethernet interface card, download the remote upgrade data packet from the remote upgrade server according to the compressed package parameters required for the upgrade, perform the upgrade operation on the remote upgrade data packet, and send the upgrade data during the upgrade to the test terminal; the test terminal is used to send the compressed package parameters required for the upgrade to the Ethernet interface card, and to receive the upgrade feedback data returned by the ECU under test, and compare the upgrade feedback data with the preset data to determine the detection result of the remote upgrade of the ECU under test. The automated and remote ECU upgrade test process is realized by the present application, which not only improves the test efficiency and accuracy, but also reduces the test cost and improves the reliability and safety of the ECU upgrade.

[0020] 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

[0021] 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.

[0022] Figure 1A schematic diagram of the structure of the remote upgrade test system provided in the embodiment of the present application;

[0023] Figure 2 One of the flow charts for testing the test terminal provided in the embodiment of the present application;

[0024] Figure 3 Flow chart 2 of testing the test terminal provided in the embodiment of the present application;

[0025] Figure 4 Flow chart 3 of testing the test terminal provided in the embodiment of the present application;

[0026] Figure 5 A flowchart of the remote upgrade test method provided in an embodiment of the present application. DETAILED DESCRIPTION

[0027] 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.

[0028] First, the application scenarios to which the present application is applicable are introduced. The present application can be applied in the field of vehicle engineering technology.

[0029] Research has found that the existing ECU upgrade process is highly dependent on the platform provided by the car company. This means that if the car company platform fails, is maintained or adjusted, the upgrade process may be affected, resulting in interruption or delay of the upgrade operation; the car company platform usually requires users to log in to download and upgrade the upgrade package. However, if the car company does not provide a login account, or there are problems with account management (such as forgotten passwords, account locks, etc.), it will cause inconvenience to the upgrade test or even make it impossible to carry out; downloading the upgrade package through the car company platform may be affected by factors such as network speed and platform server performance, resulting in low download and upgrade efficiency. This not only increases the time required for the upgrade, but may also affect the normal use of the ECU under test.

[0030] Based on this, the embodiment of the present application provides a remote upgrade test system and test method, the system includes an Ethernet interface card and a test terminal, the Ethernet interface card is used to receive the compressed package parameters required for the upgrade sent by the test terminal, and forward the compressed package parameters required for the upgrade to the ECU under test; the ECU under test is used to receive the compressed package parameters required for the upgrade forwarded by the Ethernet interface card, download the remote upgrade data packet from the remote upgrade server according to the compressed package parameters required for the upgrade, perform the upgrade operation on the remote upgrade data packet, and send the upgrade data during the upgrade to the test terminal; the test terminal is used to send the compressed package parameters required for the upgrade to the Ethernet interface card, and to receive the upgrade feedback data returned by the ECU under test, and compare the upgrade feedback data with the preset data to determine the detection result of the remote upgrade of the ECU under test. The automated and remote ECU upgrade test process is realized through the present application, which not only improves the test efficiency and accuracy, but also reduces the test cost and improves the reliability and safety of the ECU upgrade.

[0031] See also Figure 1 , Figure 1 This is a schematic diagram of the structure of the remote upgrade test system provided in the embodiment of the present application. Figure 1 As shown in , the remote upgrade test system 10 provided in the embodiment of the present application includes: a test terminal 11, an Ethernet interface card 12 and a power supply 14.

[0032] 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 ECU 13 under test, the serial communication interface of the ECU 13 under test is connected to the second USB interface of the test terminal 11, and the test terminal 11 is connected to the ECU 13 under test through the Ethernet interface card 12.

[0033] The Ethernet interface card 12 is used to receive the compressed package parameters required for the upgrade sent by the test terminal 11, and forward the compressed package parameters required for the upgrade to the ECU under test;

[0034] Here, the Ethernet interface card 12 is responsible for receiving the compressed package parameters required for the upgrade from the test terminal 11. These parameters may include the version number, size, checksum and other information of the upgrade package, which are used to guide the subsequent download and upgrade process. After receiving these parameters, the Ethernet interface card 12 will forward this information to the ECU 13 under test.

[0035] The ECU under test 13 is used to receive the compressed package parameters required for the upgrade forwarded by the Ethernet interface card 12, download the remote upgrade data packet from the remote upgrade server according to the compressed package parameters required for the upgrade, perform an upgrade operation on the remote upgrade data packet, and send the upgrade data during the upgrade to the test terminal 11;

[0036] Among them, when the ECU13 under test receives the compressed package parameters required for the upgrade forwarded by the Ethernet interface card 12, it will download the corresponding remote upgrade data packet from the remote upgrade server according to these parameters. After the download is completed, the ECU13 under test will verify and decompress the remote upgrade data packet, and then execute the upgrade program. During the upgrade process, the ECU13 under test will record the upgrade data and send this data back to the test terminal 11 so that the test terminal can monitor and evaluate the upgrade process.

[0037] The test terminal 11 is used to send the compressed package parameters required for the upgrade to the Ethernet interface card 12, and to receive the upgrade feedback data returned by the ECU 13 under test, and compare the upgrade feedback data with the preset data to determine the detection result of the remote upgrade of the ECU 13 under test.

[0038] Here, the test terminal 11 is responsible for generating and sending the compressed package parameters required for the upgrade to the Ethernet interface card 12. During the upgrade process, the test terminal 11 will receive the upgrade feedback data returned by the ECU 13 under test. These data may include upgrade progress, error information, upgrade results, etc. The test terminal 11 will compare the received upgrade feedback data with the preset data. The preset data may include information such as the expected upgrade results and the allowable error range. Through comparison, the test terminal 11 can determine whether the remote upgrade of the ECU 13 under test is successful and whether there are any abnormal conditions.

[0039] This application realizes the remote upgrade test of ECU through the collaborative work between the test terminal, Ethernet interface card and the ECU under test. This test method not only improves the upgrade efficiency, but also reduces the test cost and ensures the reliability and security of ECU upgrade.

[0040] The system further includes a power supply 14 , wherein a power supply interface of the power supply 14 is connected to a power supply interface of the ECU 13 under test.

[0041] The power supply start instruction is sent to the power supply 14 to control the power supply 14 to supply power to the ECU 13 under test; the current and voltage of the ECU under test sent by the power supply 14 are received to collect data.

[0042] Among them, the power supply 14 can be a programmable power supply, which is responsible for providing stable and compliant power to the ECU 13 under test. This ensures that the ECU can operate normally during the upgrade test process and will not fail due to insufficient or unstable power. The power supply interface of the power supply is directly connected to the power interface of the ECU 13 under test. This connection method ensures that power can be directly and effectively transmitted to the ECU, and it is also convenient for monitoring and managing the power usage of the ECU. The system controls the power supply 14 to start powering the ECU 13 under test by issuing a start power supply instruction. This instruction is usually issued by the test terminal or the system control center to ensure the controllability and accuracy of the power supply process.

[0043] During the power supply process, the power supply 14 will send the current and voltage data of the ECU under test to the system in real time. These data are essential for evaluating the power consumption of the ECU, monitoring its operating status, and timely discovering potential problems. By receiving these data, the system can perform further data analysis and processing to support subsequent test decisions and result evaluation.

[0044] Here, the power supply 14 sends KL15 and KL30 signals to the ECU 12 under test. KL30 is a signal related to the ECU power 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; KL15 is a signal related to the key ignition (ACC). 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.

[0045] Specifically, see Figure 2 , Figure 2 This is one of the flow charts for testing the test terminal provided in the embodiment of the present application. Figure 2 As shown in , the test terminal 11 is also configured as:

[0046] S101, obtaining an upgrade file;

[0047] The upgrade file includes multiple sub-files required for the upgrade.

[0048] First, obtain an upgrade file that contains multiple sub-files required for the upgrade. This upgrade file is usually a compressed package or packaged file, which contains all sub-files required in the upgrade process, such as software update packages, configuration files, verification files, etc. The purpose is to ensure that all necessary upgrade components are ready for subsequent upgrade operations.

[0049] For example, the upgrade file may include the following sub-files:

[0050] Ethernet upgrade process file: This file describes the complete process of ECU upgrade via Ethernet, including data communication, file transfer, verification, decompression, installation and other steps.

[0051] ARXML data file produced by Autosar: ARXML is an XML format file used in the Autosar standard to describe software components, interfaces, and data types. It provides detailed information about the ECU software architecture and helps determine what needs to be modified or remains unchanged during the upgrade process.

[0052] Diagnostic CDD file: CDD (Diagnostic Communication Master Data) file defines the structure and behavior of diagnostic services to support the diagnostic functions of ECU. During upgrade testing, it may be necessary to use diagnostic services to verify the status of the upgraded ECU.

[0053] Unlock DLL files: In some cases, specific DLL files may be required to unlock upgraded features of the ECU or to access protected areas.

[0054] URL information provided by OEM: The URL information provided by the original equipment manufacturer (OEM) may point to the storage location of the upgrade file or be used to obtain additional information required for the upgrade.

[0055] Set the upgrade file package data content: According to the extracted target parameters and other related documents, set the specific content of the upgrade file package, including data length, SHA256 checksum, decompression password, device ID, etc.

[0056] S102, for each sub-file, extracting the target parameters in the sub-file;

[0057] After obtaining the upgrade file, you need to check the sub-files one by one and extract key target parameters from them. These target parameters may include sub-file type, version, dependency, checksum and other information. The purpose is to understand the specific content and requirements of each sub-file by extracting the target parameters, and provide a basis for determining subsequent test cases.

[0058] S103. Determine test cases corresponding to the remote upgrade of the ECU under test according to the target parameters, each test case including a plurality of compressed package parameters required for the upgrade.

[0059] Based on the extracted target parameters, one or more test cases are determined for each subfile or a group of related subfiles. Each test case includes multiple compressed package parameters required for the upgrade, which are used to guide the remote upgrade process of the ECU under test. The purpose is to ensure that each step in the upgrade process is fully verified by formulating detailed test cases, thereby improving the success rate and reliability of the upgrade.

[0060] Specifically, see Figure 3 , Figure 3 The second flowchart of the test terminal provided in the embodiment of the present application for testing. Figure 3 As shown in , the test terminal 11 is also configured as:

[0061] S201, in response to a start test instruction, detecting all messages sent by the ECU under test within a preset time period;

[0062] In response to the start test instruction, the test terminal will monitor and record all messages sent by the ECU under test within a preset time period.

[0063] S202, determining whether there is a preset protocol message among all messages sent by the tested ECU received within a preset time period;

[0064] The test terminal checks whether these messages contain preset protocol messages. These preset protocol messages are usually used to initialize communication and verify the identity of the ECU.

[0065] Here, the preset protocol may be the SOMEIP / SD protocol, which is an important part of the SOME / IP protocol for service discovery. It implements bidirectional communication between the test terminal and the ECU under test through an Ethernet interface card, thereby achieving flexible communication and data exchange.

[0066] S203, if the preset protocol message exists in all the messages sent by the tested ECU received within the preset time period, a handshake request data frame is sent to the tested ECU, and a response data frame replied by the tested ECU is obtained to determine whether the handshake request data frame matches the response data frame;

[0067] If there is a preset protocol message, the test terminal will send a handshake request data frame to the ECU under test. Subsequently, the test terminal will receive the response data frame replied by the ECU under test and determine whether the handshake request data frame matches the response data frame. The matching criteria may include the format, content, checksum, etc. of the data frame.

[0068] S204, if the handshake request data frame matches the response data frame, it is considered that the initialization is successful and the handshake is successful, and an upgrade download instruction is sent to the ECU under test;

[0069] If the handshake request data frame matches the response data frame, the test terminal will consider that the initialization is successful and the handshake is successful. Next, the test terminal 11 will send an upgrade download instruction to the ECU under test to start the upgrade process.

[0070] S205, if the handshake request data frame does not match the response data frame, it is considered that the initialization is successful and the handshake fails, and the signal transmitted between the test terminal and the ECU under test is detected to perform handshake failure diagnosis;

[0071] If the handshake request data frame does not match the response data frame, the test terminal 11 will consider that the initialization is successful but the handshake fails. At this time, the test terminal 11 will detect the signal transmitted between the test terminal and the ECU under test to diagnose the handshake failure. The diagnosis may include checking the communication line, communication protocol, ECU status, etc.

[0072] S206. If the preset protocol message does not exist in all the messages sent by the ECU under test received within the preset time period, it is considered that the initialization has failed, and the connection between the test terminal and the ECU under test is detected to perform initialization failure diagnosis.

[0073] If the preset protocol message sent by the ECU 13 under test is not received within the preset time period, the test terminal 11 will consider that the initialization has failed. Subsequently, the test terminal 11 will detect the connection between the test terminal and the ECU 13 under test to diagnose the initialization failure. The diagnosis may include checking the connection line, ECU power supply, ECU status, etc.

[0074] Here, the test terminal 11 is further configured as:

[0075] In response to successful initialization and handshake, an upgrade parameter structure is sent to the ECU under test.

[0076] Before starting the upgrade process, first ensure that the communication link with the ECU under test has been successfully initialized and both parties have completed the handshake protocol to confirm that the communication link is normal.

[0077] The upgrade parameter structure includes a remote upgrade server download path and verification parameters, and the ECU under test is used to download a remote upgrade data packet from the remote upgrade server according to the remote upgrade server download path and verification parameters;

[0078] Here, in response to successful initialization and handshake, an upgrade parameter structure is sent to the ECU under test, which contains two key information: the download path of the remote upgrade server: this is the server address that the ECU under test needs to access to download the upgrade data package; verification parameters: used to verify the authenticity and integrity of the downloaded data package, which may include hash values, digital signatures, etc.

[0079] Receive the compressed signal returned by the ECU under test, and determine whether the compressed signal indicates that the remote upgrade data packet is in a decompressed state;

[0080] Here, after the ECU under test downloads the upgrade data package from the remote upgrade server according to the provided download path, the decompression process begins, and a compression signal returned by the ECU under test is received, which is used to indicate whether a decompression operation is currently being performed.

[0081] If the compression signal indicates that the remote upgrade data packet is in a decompressed state, a status detection signal is sent to the ECU under test; and a status signal returned by the ECU under test is received;

[0082] Among them, according to the received compression signal, it is determined whether the remote upgrade data packet is in a decompressed state. If the compression signal indicates that the data packet is being decompressed, proceed to the next step. If the compression signal indicates that the data packet is not in a decompressed state (it may be a decompression failure), the "decompression failure" message is output, the cause of the error is recorded, and the test process ends.

[0083] Furthermore, if the decompression is successful, a status detection signal is sent to the ECU under test to request it to return the current status information, and a status signal returned by the ECU under test is received, which is used to indicate the result of the decryption operation.

[0084] Determine whether the status signal returned by the ECU under test indicates that the decryption is successful; if the status signal returned by the ECU under test indicates that the decryption is successful, continue with the subsequent judgment process; if the status signal returned by the ECU under test indicates that the decryption fails, output the decryption failure, record the error cause, and end the test;

[0085] Here, based on the received status signal, it is determined whether the ECU under test has successfully decrypted the upgrade data packet. If the status signal indicates that the decryption is successful, the subsequent upgrade process (such as installing updates, restarting the ECU, etc.) will continue. If the status signal indicates that the decryption fails, the "decryption failed" message is output, the cause of the error is recorded, and the test process ends.

[0086] If the compression signal indicates that the remote upgrade data packet is not in a decompressed state, the decompression failure is output, the error cause is recorded, and the test ends.

[0087] If the decryption is successful, depending on the specific upgrade process, more steps may be required to verify and install the upgrade data package. These steps may include verifying the installed software version, performing some tests to ensure that the upgraded ECU functions normally, etc.

[0088] Throughout the process, record the operations and results of each step in detail for subsequent analysis and troubleshooting. If the test fails, make sure to record the specific reasons and steps for the failure so that the problem can be quickly located and repaired.

[0089] Through the above steps, it can be ensured that the ECU under test can correctly download, decompress, decrypt and process the upgrade data packet from the remote upgrade server, thereby realizing the remote upgrade of the software.

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

[0091] After detecting that the ECU under test has successfully decompressed and decrypted the remote upgrade data packet, a verification signal is sent to the ECU under test;

[0092] In this step, after detecting that the ECU under test has successfully decompressed and decrypted the remote upgrade data packet, the test terminal 11 sends a verification signal to the ECU under test. The verification signal may include a checksum (such as a SHA256 checksum) or other verification information for verifying the integrity of the upgrade data packet.

[0093] Receive the verification feedback signal returned by the ECU under test; determine whether the verification feedback signal is consistent with the preset verification signal;

[0094] The test terminal 11 receives the verification feedback signal returned by the tested ECU, and determines whether the verification feedback signal is consistent with a preset verification signal (such as an expected SHA256 checksum).

[0095] If the verification feedback signal is consistent with the preset verification signal, it indicates that the version upgrade file after decompression and decryption of the remote upgrade data packet is complete, and a signature verification signal is sent to the ECU under test; the signature verification feedback signal returned by the ECU under test is received; and it is determined whether the signature verification feedback signal indicates that the file certificate corresponding to the version upgrade file is consistent with the preset certificate;

[0096] If the SHA256 verification is successful (i.e., the verification feedback signal is consistent with the preset verification signal), then continue to determine whether the success code replied by the controller is correct. If the SHA256 verification fails (i.e., the verification feedback signal is inconsistent with the preset verification signal), then record the cause of the error and end the test. In addition, after the SHA256 verification is successful, the test terminal 11 sends a signature verification signal to the ECU under test, requesting to verify the file certificate of the version upgrade file.

[0097] If the verification feedback signal indicates that the file certificate corresponding to the version upgrade file is consistent with the preset certificate, the verification is completed and the remote upgrade command is issued to the ECU under test; if the verification feedback signal indicates that the file certificate corresponding to the version upgrade file is inconsistent with the preset certificate, the verification fails, the error cause is recorded, and the test ends;

[0098] Among them, the test terminal 11 receives the signature verification feedback signal returned by the ECU under test, and determines whether the signature verification feedback signal indicates that the file certificate corresponding to the version upgrade file is consistent with the preset certificate. If the signature verification is successful (that is, the file certificate is consistent with the preset certificate), and the success code replied by the controller is correct, the verification is completed and the remote upgrade instruction is prepared to be issued. If the signature verification fails (that is, the file certificate is inconsistent with the preset certificate), the cause of the error is recorded and the test is terminated. After the signature verification is successful, the test terminal 11 sends a remote upgrade instruction to the ECU under test, instructing it to perform a software upgrade.

[0099] If the verification feedback signal is inconsistent with the preset verification signal, it indicates that the version upgrade file is incomplete, the verification fails, the error cause is recorded, and the test ends.

[0100] In the whole process, if any step fails (such as decompression failure, decryption failure, verification failure, signature verification failure, etc.), the test terminal 11 should record the detailed cause of the error and end the test process. These error records are crucial for subsequent problem analysis and repair.

[0101] The test terminal 11 is responsible for communicating with the ECU 13 under test and verifying the integrity, authenticity and correctness of the upgrade data packet. By sending a verification signal and a signature verification signal and receiving a corresponding feedback signal for judgment, the test terminal 11 can ensure that only complete and verified upgrade data packets are applied to the ECU 13 under test.

[0102] Specifically, see Figure 4 , Figure 4 The third flowchart of the test terminal provided in the embodiment of the present application for testing. Figure 4 As shown in , the test terminal 11 is also configured as:

[0103] S301, in response to the issuance of the remote upgrade instruction, closing the recording of the diagnostic trouble code and the network communication of the CAN signal;

[0104] Before starting the formal upgrade, the test terminal 11 first executes the pre-upgrade mode. In this mode, the test terminal 11 turns off the recording function of the diagnostic fault code and turns off the network communication of the CAN signal. The purpose is to reduce the load rate of the vehicle's CPU and ensure higher efficiency and faster speed during the upgrade to ensure the smooth progress of the upgrade process and avoid unnecessary interference.

[0105] In response to the remote upgrade instruction being issued, the test terminal 11 maintains the setting of the pre-upgrade mode, that is, the diagnostic trouble code recording and CAN communication are turned off.

[0106] S302, sending an installation instruction, and receiving an installation progress signal of the ECU under test for the version upgrade file;

[0107] The test terminal 11 sends an installation instruction to the ECU under test, instructing it to start installing the version upgrade file. At the same time, the test terminal 11 is ready to receive an installation progress signal sent by the ECU under test.

[0108] S303, determining whether the installation progress signal meets the preset installation requirements;

[0109] The test terminal 11 receives the installation progress signal returned by the tested ECU and determines whether the installation progress signal meets the preset installation requirements, which may include checking whether the installation steps are executed in sequence and whether each step is successfully completed.

[0110] S304: If the installation progress signal meets the preset installation requirements, the verification is successful, the upgrade mode is terminated, and the diagnostic fault code and the network communication of the CAN signal are continuously recorded;

[0111] In an optional embodiment, the progress verification is successful: if the installation progress signal meets the preset installation requirements, that is, the progress verification is successful, the test terminal 11 considers that the upgrade installation process is successful. At this time, the test terminal 11 ends the upgrade mode, restores the recording function of the diagnostic fault code, and reopens the network communication of the CAN signal.

[0112] S305: If the installation progress signal does not meet the preset installation requirements, it is determined that the progress verification has failed and the test ends.

[0113] In another optional embodiment, the progress verification fails: if the installation progress signal does not meet the preset installation requirements, that is, the progress verification fails, or the ECU under test does not respond to the progress signal according to the process, the test terminal 11 believes that a problem occurred during the upgrade installation process. At this time, the test terminal 11 records the cause of the error and ends the entire test process.

[0114] During the remote upgrade process, the test terminal 11 is responsible for communicating with the ECU under test and monitoring the upgrade installation process. By turning off the diagnostic trouble code record and CAN communication, the test terminal 11 can ensure that the upgrade process is not interfered with by external factors. Progress verification is a key step to ensure the smooth progress of the upgrade installation process. The test terminal 11 needs to carefully determine whether the installation progress signal meets the preset requirements. If a problem occurs during the upgrade installation process, the test terminal 11 should record the detailed cause of the error and end the test process for subsequent analysis and repair. After ending the upgrade mode, the test terminal 11 needs to restore the diagnostic trouble code record and CAN communication to ensure that the system can operate normally.

[0115] In an optional embodiment, the progress test can be performed during the installation process. The installation progress stipulates that it cannot be 0-100%, and must be upgraded from 1-100%. When it is upgraded to 25%, the tested ECU must be internally restarted. A flag bit must be fed back during the upgrade process. An error in any item indicates a problem with the upgrade process.

[0116] The test terminal 11 of the present application is also configured as follows:

[0117] According to the log data returned by the ECU under test, perform data analysis and resolve the corresponding data bit parameters;

[0118] After the upgrade installation is completed, the test terminal 11 receives the log data returned by the ECU under test. These log data usually contain various parameters and status information during the upgrade process. The test terminal 11 conducts in-depth analysis on the received log data and parses out the corresponding data bit parameters. These data bit parameters may include key information such as version number, checksum, and timestamp.

[0119] Determine whether the corresponding data bit parameter is equal to the expected value; if the corresponding data bit parameter is equal to the expected value, the test is successful, the test log is saved, and a test report is generated; if the corresponding data bit parameter is not equal to the expected value, it means that the upgraded version number is abnormal and the test fails.

[0120] Here, the test terminal 11 compares the parsed data bit parameters with the expected values ​​one by one. The expected values ​​are set according to the test plan and requirements before the upgrade, and are used to verify whether the upgraded ECU has achieved the expected performance and status.

[0121] Test success: If all key data bit parameters are equal to expected values, the test terminal 11 considers that the upgrade installation is successful and the performance and status of the ECU under test meet expectations. At this time, the test terminal 11 saves the test logs, which record the key information and data of the entire upgrade test process.

[0122] Next, the test terminal 11 generates a test report, which summarizes the test results, test steps, test time, test personnel and other information in detail for subsequent analysis and archiving.

[0123] Test failure: If any key data bit parameter is not equal to the expected value, especially if key information such as the version number is abnormal, the test terminal 11 considers that the upgrade installation has failed. At this time, the test terminal 11 will also save the test log, but the log will record the reason for the test failure and the specific abnormal data.

[0124] The test terminal 11 also generates a test report including failure information so that developers and testers can quickly locate the problem and take corresponding repair measures.

[0125] The upgrade feedback data includes a data sequence and a sequence identifier, wherein the test terminal 11 is further configured as follows:

[0126] The target data at the target position in the data sequence is located according to the sequence identifier; the target data is compared with the preset data, and the detection result of the remote upgrade of the ECU under test is determined according to the comparison result.

[0127] In this step, after the upgrade installation is completed, the test terminal 11 receives the upgrade feedback data returned by the ECU under test. These data usually include a data sequence and a sequence identifier associated therewith.

[0128] The test terminal 11 first parses the upgrade feedback data, identifies the data sequence and sequence identifier, and locates the target data at the target position in the data sequence according to the sequence identifier. The "target position" here refers to the data item at a specific position in the data sequence, which may represent a key parameter or state in the upgrade process.

[0129] The test terminal 11 compares the located target data with the preset data. The preset data is set according to the test plan and requirements before the upgrade, and is used to verify whether the upgraded ECU has achieved the expected performance and status. The comparison process may involve multiple data items, and each data item needs to be compared one by one with the corresponding preset data.

[0130] Based on the comparison results, the test terminal 11 determines the detection result of the remote upgrade of the ECU under test. If all the target data match the preset data, the test terminal 11 considers that the upgrade is successful and the performance and status of the ECU under test meet expectations. If any target data does not match the preset data, the test terminal 11 considers that the upgrade has failed and needs to record specific abnormal data for subsequent analysis.

[0131] Regardless of whether the upgrade succeeds or fails, the test terminal 11 will generate a detailed test report. The report content should include the test time, tester, specific content of the upgrade feedback data, comparison results, and final test results. In the case of upgrade failure, the test report should also include a detailed description of the abnormal data and possible repair suggestions.

[0132] The test terminal 11's processing function for the upgrade feedback data ensures that the ECU under test can work as expected after the upgrade is installed, and provides detailed test results and test reports. By locating the target data and comparing it with the preset data, the test terminal 11 can accurately determine whether the upgrade is successful. The test report is an important basis for subsequent analysis and archiving. It provides key information and data in the test process. During the entire test process, the test terminal 11 needs to ensure unimpeded communication with the ECU under test in order to receive and process the upgrade feedback data in a timely manner. In addition, the test terminal 11 also has powerful data processing and analysis capabilities to extract key information from a large amount of upgrade feedback data and perform accurate comparison and verification.

[0133] This application can perform forward process testing and reverse error testing (information error, process error, power failure during upgrade, etc.) based on selected test cases, and can implement multiple independent download tests of upgrade pressure, obtain data through Ethernet, compare results, and judge whether the upgrade of the ECU under test is successful by reading version information. The above judgment processes are all forward process tests.

[0134] This application also includes reverse error testing. During the reverse error testing process, if any process, process test sequence or data is different from the process test, an error should be reported, which means that the reverse error test is successful.

[0135] For example, the test flow of reverse error testing can be:

[0136] First, start the test execution related procedures, power on both KL30 and KL15 to ensure that the ECU works normally;

[0137] Then, determine whether SOMEIP initialization is completed and whether the SD handshake function can be performed. If the initialization and handshake are successful, send the upgrade download instruction. If the initialization and handshake fail, check whether the input information is correct.

[0138] Next, send the upgrade parameter structure set by the error URL information (key information error) to determine whether the decryption is successful. If the decryption fails, the controller will reply with an error code and the test case will be executed correctly. If the decryption is successful, the test fails and the test ends.

[0139] Finally, data analysis is performed based on the data from Ethernet and system logs to parse out the parameters of the corresponding data bits to see if they are equal to the expected values. If the test is successful, the test log and bus data log are saved and a test report is generated. If the test fails, the test log and bus data log are saved and a test report is generated.

[0140] In an optional embodiment, the remote upgrade test can be performed in the following manner:

[0141] 1) ECU independent download forward process test:

[0142] Fill in relevant ECU test parameters and URL information; connect to the test environment; select the test case to be executed on the host computer; run the automated test program; send URL structure information; perform verification and judgment operations; execute the ECU upgrade process; based on the collected data, the program parses the Ethernet data flow and is consistent with expectations; determine whether the major version number, SOC, MCU, NAD and other minor version numbers have changed; output the test results; automatically save the bus log, ECU system log, and test debug log according to the test date and test case name; and automatically generate an analyzable report.

[0143] 2) ECU independent download reverse process test

[0144] Fill in relevant ECU test parameters and URL information; connect to the test environment; select the test case to be executed on the host computer; run the automated test program; send the error URL structure information; perform verification and judgment operations; execute the ECU upgrade process; upgrade interruption, error URL information, test case passed; determine the major version number, SOC, MCU, NAD and other minor version numbers have not changed; output test results; automatically save bus log, ECU system log, test debug log according to test date and test case name; automatically generate analyzable reports.

[0145] Whether it is a forward process test or a reverse error test, test data comparison will be performed, that is, data is collected for protocol analysis, the data field corresponding to the input signal value is parsed, and judgment and comparison are performed, and the upgrade process is judged and compared with the test standard.

[0146] The technical solution proposed in this application has higher flexibility and efficiency. By directly transmitting the compressed package download path (URL) in the cloud to the ECU under test, the ECU can download the upgrade package and perform the upgrade operation independently without relying on the car company platform. This solution not only simplifies the upgrade process, but also improves the convenience of testing and the possibility of simulation.

[0147] The remote upgrade test system and test method provided by the embodiment of the present application include an Ethernet interface card and a test terminal, wherein the Ethernet interface card is used to receive the compressed package parameters required for the upgrade sent by the test terminal, and forward the compressed package parameters required for the upgrade to the ECU under test; the ECU under test is used to receive the compressed package parameters required for the upgrade forwarded by the Ethernet interface card, download the remote upgrade data packet from the remote upgrade server according to the compressed package parameters required for the upgrade, perform the upgrade operation on the remote upgrade data packet, and send the upgrade data during the upgrade to the test terminal; the test terminal is used to send the compressed package parameters required for the upgrade to the Ethernet interface card, and to receive the upgrade feedback data returned by the ECU under test, and compare the upgrade feedback data with the preset data to determine the detection result of the remote upgrade of the ECU under test. The automated and remote ECU upgrade test process is realized by the present application, which not only improves the test efficiency and accuracy, but also reduces the test cost and improves the reliability and safety of the ECU upgrade.

[0148] This application uses advanced data analysis algorithms to improve the feasibility of test environment requirements, and implements the encapsulation of custom independent download processes through programs, eliminating the need for testers to manually send upgrade processes. It provides a variety of reverse upgrade test processes, and simulates tests of abnormal environments such as error messages, error processes, and fault interruptions to achieve automated testing, improve test efficiency, and increase stress testing, which can realize multiple upgrade stress independent download tests.

[0149] See also Figure 5 , Figure 5 This is a flow chart of the remote upgrade test method provided by the embodiment of the present application. Figure 5 As shown in , the method is applied to a remote upgrade test system, the remote upgrade test system includes a test terminal and an Ethernet interface card, the test terminal is connected to the ECU under test through the Ethernet interface card, and the method includes:

[0150] S501, the Ethernet interface card is used to receive the compressed package parameters required for upgrading sent by the test terminal, and forward the compressed package parameters required for upgrading to the ECU under test;

[0151] S502, the ECU under test is used to receive the compressed package parameters required for upgrading forwarded by the Ethernet interface card, download the remote upgrading data packet from the remote upgrading server according to the compressed package parameters required for upgrading, perform upgrading operation on the remote upgrading data packet, and send the upgrading data during upgrading to the test terminal;

[0152] S503, the test terminal is used to send the compressed package parameters required for the upgrade to the Ethernet interface card, and to receive the upgrade data returned by the ECU under test, and compare the upgrade data with preset data to determine the detection result of the remote upgrade of the ECU under test.

[0153] 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.

[0154] 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.

[0155] 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.

[0156] 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.

[0157] 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.

[0158] 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 remote upgrade test system, characterized in that: The test terminal includes a test terminal and an Ethernet interface card, wherein the test terminal is connected to the ECU under test through the Ethernet interface card. The Ethernet interface card is used to receive the compressed package parameters required for the upgrade sent by the test terminal, and forward the compressed package parameters required for the upgrade to the ECU under test; The ECU under test is used to receive the compressed package parameters required for the upgrade forwarded by the Ethernet interface card, download the remote upgrade data packet from the remote upgrade server according to the compressed package parameters required for the upgrade, perform an upgrade operation on the remote upgrade data packet, and send the upgrade data during the upgrade to the test terminal; The test terminal is used to send the compressed package parameters required for the upgrade to the Ethernet interface card, and to receive the upgrade feedback data returned by the ECU under test, and compare the upgrade feedback data with preset data to determine the detection result of the remote upgrade of the ECU under test.

2. The system according to claim 1, characterized in that The test terminal is configured as follows: Obtain an upgrade file, wherein the upgrade file includes multiple sub-files required for the upgrade; For each sub-file, extract the target parameter in the sub-file; According to the target parameters, the test cases corresponding to the remote upgrade of the ECU under test are determined, and each test case includes a plurality of compressed package parameters required for the upgrade.

3. The system according to claim 1, characterized in that The test terminal is further configured as: In response to a start test instruction, detecting all messages sent by the ECU under test within a preset time period; Determine whether there is a preset protocol message in all messages sent by the ECU under test received within a preset time period; If a preset protocol message exists in all messages sent by the ECU under test received within a preset time period, a handshake request data frame is sent to the ECU under test, and a response data frame replied by the ECU under test is obtained to determine whether the handshake request data frame matches the response data frame; If the handshake request data frame matches the response data frame, it is considered that the initialization is successful and the handshake is successful, and an upgrade download instruction is sent to the ECU under test; If the handshake request data frame does not match the response data frame, it is considered that the initialization is successful and the handshake fails, and the signal transmitted between the test terminal and the ECU under test is detected to perform handshake failure diagnosis; If the preset protocol message does not exist in all the messages sent by the ECU under test received within the preset time period, it is considered that the initialization has failed, and the connection between the test terminal and the ECU under test is detected to perform initialization failure diagnosis.

4. The system according to claim 3, characterized in that The test terminal is further configured as: In response to successful initialization and successful handshake, an upgrade parameter structure is sent to the ECU under test, wherein the upgrade parameter structure includes a remote upgrade server download path and verification parameters, and the ECU under test is used to download a remote upgrade data packet from the remote upgrade server according to the remote upgrade server download path and the verification parameters; Receiving a compression signal returned by the ECU under test; Determining whether the compression signal indicates that the remote upgrade data packet is in a decompressed state; If the compression signal indicates that the remote upgrade data packet is in a decompressed state, sending a state detection signal to the ECU under test; Receiving a status signal returned by the ECU under test; Determine whether the status signal returned by the ECU under test indicates that the decryption is successful; If the status signal returned by the tested ECU indicates that the decryption is successful, the subsequent judgment process continues; If the status signal returned by the ECU under test indicates that the decryption fails, the decryption failure is output, the error cause is recorded, and the test ends; If the compression signal indicates that the remote upgrade data packet is not in a decompressed state, the decompression failure is output, the error cause is recorded, and the test ends.

5. The system according to claim 4, characterized in that The test terminal is further configured as: After detecting that the ECU under test successfully decompresses and decrypts the remote upgrade data packet, sending a verification signal to the ECU under test; Receiving a verification feedback signal returned by the ECU under test; Determining whether the verification feedback signal is consistent with a preset verification signal; If the verification feedback signal is consistent with the preset verification signal, it indicates that the version upgrade file after decompression and decryption of the remote upgrade data packet is complete, and a signature verification signal is sent to the ECU under test; Receiving a signature verification feedback signal returned by the ECU under test; Determining whether the signature verification feedback signal indicates that the file certificate corresponding to the version upgrade file is consistent with the preset certificate; If the signature verification feedback signal indicates that the file certificate corresponding to the version upgrade file is consistent with the preset certificate, the verification is completed and a remote upgrade instruction is issued to the ECU under test; If the signature verification feedback signal indicates that the file certificate corresponding to the version upgrade file is inconsistent with the preset certificate, the signature verification fails, the error reason is recorded, and the test ends; If the verification feedback signal is inconsistent with the preset verification signal, it indicates that the version upgrade file is incomplete, the verification fails, the error cause is recorded, and the test ends.

6. The system according to claim 5, characterized in that The test terminal is further configured as: In response to the remote upgrade instruction being issued, closing the recording of diagnostic trouble codes and the network communication of CAN signals; Sending an installation instruction and receiving an installation progress signal of the ECU under test for the version upgrade file; Determining whether the installation progress signal meets preset installation requirements; If the installation progress signal meets the preset installation requirements, the verification is successful, the upgrade mode is terminated, and the diagnostic trouble code and the network communication of the CAN signal are continuously recorded; If the installation progress signal does not meet the preset installation requirements, it is determined that the progress verification has failed and the test ends.

7. The system according to claim 6, characterized in that The test terminal is further configured as: According to the log data returned by the ECU under test, perform data analysis and resolve the corresponding data bit parameters; Determining whether the corresponding data bit parameter is equal to an expected value; If the corresponding data bit parameter is equal to the expected value, the test is successful, the test log is saved, and a test report is generated; If the corresponding data bit parameter is not equal to the expected value, it means that the upgraded version number is abnormal and the test fails.

8. The system according to claim 1, characterized in that The upgrade feedback 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 detection result for the remote upgrade of the tested ECU is determined according to the comparison result.

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

10. A remote upgrade test method, characterized in that: The method is applied to a remote upgrade test system, wherein the remote upgrade test system comprises a test terminal and an Ethernet interface card, wherein the test terminal is connected to the ECU under test through the Ethernet interface card. include: The Ethernet interface card is used to receive the compressed package parameters required for the upgrade sent by the test terminal, and forward the compressed package parameters required for the upgrade to the ECU under test; The ECU under test is used to receive the compressed package parameters required for the upgrade forwarded by the Ethernet interface card, download the remote upgrade data packet from the remote upgrade server according to the compressed package parameters required for the upgrade, perform an upgrade operation on the remote upgrade data packet, and send the upgrade data during the upgrade to the test terminal; The test terminal is used to send the compressed package parameters required for the upgrade to the Ethernet interface card, and to receive the upgrade data returned by the ECU under test, and compare the upgrade data with preset data to determine the detection result of the remote upgrade of the ECU under test.

Images