Ecus upgrade test method, device and equipment

Abstract

Embodiments of the present disclosure disclose an ECU upgrade test method, device and equipment, the method comprising: in response to a firmware upgrade test instruction of a target ECU, obtaining a test case; wherein the test case at least includes a state sequence passed by a firmware upgrade task and an ECU expected response corresponding to each state; determining a current state based on the state sequence, and calling a target API encapsulating various standard UDS to convert the standard UDS corresponding to the current state into a driving instruction corresponding to a current active communication tool through a preconfigured UDS mapping table, and driving the target ECU to execute the firmware upgrade task based on the driving instruction; wherein the UDS mapping table stores a corresponding relationship between the standard UDS and the communication tool driving instruction; obtaining an actual response fed back by the target ECU, and comparing the actual response under each state with the corresponding ECU expected response to generate a firmware upgrade test result of the target ECU.

Description

Technical Field

[0001] This disclosure relates to the field of automotive electronic diagnostic technology, and more specifically, to an ECU upgrade testing method, apparatus, and equipment. Background Technology

[0002] Electronic Control Units (ECUs) are widely used in automotive electronics, and firmware upgrades and diagnostic verification are frequently required during development and testing. Currently, ECU firmware upgrade testing largely relies on a single diagnostic communication tool (such as CANoe or Zhouligong CAN analyzers), resulting in low testing efficiency. Furthermore, the data formats and interaction protocols of different communication tools are incompatible, test cases are tightly coupled with the underlying communication tools, and changing tools requires simultaneous modifications to the test logic, leading to poor scalability. In addition, existing tools lack unified state management for the ECU upgrade process, failing to automatically drive upgrade tasks according to preset state sequences, resulting in low levels of test automation. Summary of the Invention

[0003] The purpose of this disclosure is to provide a new technical solution for ECU upgrade testing.

[0004] According to a first aspect of the present disclosure, an ECU upgrade testing method is provided, the method comprising: In response to a firmware upgrade test command for the target ECU, test cases are obtained; wherein, the test cases include at least the state sequence traversed by the firmware upgrade task and the expected ECU response for each state; The current state is determined based on the state sequence, and the target API encapsulating various standard UDSs is called to convert the standard UDS corresponding to the current state into the driving instructions corresponding to the currently active communication tool through a pre-configured UDS mapping table, and to drive the target ECU to perform a firmware upgrade task based on the driving instructions; wherein, the UDS mapping table stores the correspondence between the standard UDS and the driving instructions of each communication tool; The actual response from the target ECU is obtained, and the actual response in each state is compared with the expected response of the corresponding ECU to generate the firmware upgrade test result of the target ECU.

[0005] Optionally, the method further includes: Obtain the metrics that characterize the communication quality of currently active communication tools; Determine whether the indicator value meets the preset switching conditions; If the indicator value meets the preset switching conditions, the currently active communication tool will be switched from the first communication tool to the second communication tool.

[0006] Optionally, the indicator value includes at least one of message delay and negative response code returned by the target ECU; The preset switching conditions include at least one of the following: the message delay exceeds the message delay threshold, or the number of consecutively received negative response codes exceeding the set negative response code threshold.

[0007] Optionally, switching the currently active communication tool from the first communication tool to the second communication tool includes: During the process of switching the currently active communication tool from the first communication tool to the second communication tool, the session context of the firmware upgrade task is transferred from the first communication tool to the second communication tool; The session context includes the execution status information of the firmware upgrade task before the switch, and the session context is used for the second communication tool to continue executing the firmware upgrade task.

[0008] Optionally, the method further includes: Obtain multi-source execution logs generated during the execution of the firmware upgrade task; wherein, the multi-source execution logs include script execution logs generated by executing the test cases, first communication logs output by the first communication tool, and second communication logs output by the second communication tool; The multi-source execution logs are timestamped to generate multi-source fused logs.

[0009] Optionally, the method further includes: When the firmware upgrade task is restarted after being interrupted, the most recently saved context snapshot is loaded; wherein, the context snapshot includes the execution state information before the firmware upgrade task was interrupted; Verify whether the memory data of the target ECU is consistent with the execution status information recorded in the context snapshot; If the verification is successful, the firmware upgrade task continues to be executed based on the context snapshot.

[0010] Optionally, the state sequence includes standby state, programming session state, secure access state, data transmission state, verification state, activation state, and rollback state; The test cases include forward test cases and reverse test cases. The reverse test cases include fault configuration information, which is used to inject faults into the set states in the state sequence.

[0011] Optionally, the step of obtaining test cases in response to a firmware upgrade test command for the target ECU includes: In response to a firmware upgrade test command for the target ECU, a test scenario selection interface is displayed; wherein, the test scenario selection interface includes forward test controls and reverse test controls; In response to the user's selection operation on the positive test control, the positive test cases are obtained; In response to the user's selection of the reverse test control, the reverse test cases are obtained.

[0012] According to a second aspect of the present disclosure, an ECU upgrade testing apparatus is provided, the apparatus comprising: The acquisition module is used to acquire test cases in response to a firmware upgrade test command for the target ECU; wherein, the test cases include at least the state sequence that the firmware upgrade task goes through and the expected response of the ECU for each state; The driver module is used to determine the current state based on the state sequence, and call the target API which encapsulates various standard UDSs, so as to convert the standard UDS corresponding to the current state into the driver instructions corresponding to the currently active communication tool through a pre-configured UDS mapping table, and drive the target ECU to perform firmware upgrade tasks based on the driver instructions; wherein, the UDS mapping table stores the correspondence between the standard UDS and the driver instructions of each communication tool; The generation module is used to obtain the actual response from the target ECU, compare the actual response in each state with the expected response of the corresponding ECU, and generate the firmware upgrade test result of the target ECU.

[0013] According to a third aspect of the present disclosure, an electronic device is provided, comprising: a memory for storing executable computer instructions; and a processor for executing the ECU upgrade test method according to the first aspect above, under the control of the executable computer instructions.

[0014] One beneficial effect of this disclosure is that by providing a target API that integrates unified diagnostic services, the upgrade test process can be automatically executed in response to the user's initiation operation for ECU firmware upgrade testing. This eliminates the need for manual issuance of diagnostic commands or switching of communication tools, significantly simplifying the operation process, reducing operational complexity, and improving the efficiency of ECU upgrade testing. Simultaneously, this method uses a pre-configured UDS mapping table to convert standard UDS into drive commands corresponding to the currently active communication tool in real time, decoupling test cases from the underlying communication tool. This eliminates the need to modify test logic due to tool switching. Furthermore, it drives the ECU to automatically execute upgrade tasks through state sequences and generates test results based on the automatic comparison between actual and expected responses, eliminating the need for manual observation and judgment, effectively improving the automation level of ECU upgrade testing.

[0015] Other features and advantages of this specification will become clear from the following detailed description of exemplary embodiments with reference to the accompanying drawings. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments of this specification and, together with their description, serve to explain the principles of this specification.

[0017] Figure 1 This is a block diagram of the hardware configuration of the electronic device for implementing the ECU upgrade testing method provided in the embodiments of this disclosure; Figure 2 This is a flowchart illustrating an embodiment of the ECU upgrade testing method provided in this disclosure; Figure 3 A flowchart illustrating an example ECU upgrade testing method is shown. Figure 4 This is a schematic block diagram of the ECU upgrade testing device provided in the embodiments of this disclosure; Figure 5 This is a schematic block diagram of the electronic device provided in the embodiments of this disclosure. Detailed Implementation

[0018] Various exemplary embodiments of the present disclosure will now be described in detail with reference to the accompanying drawings. It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps set forth in these embodiments do not limit the scope of the embodiments of the present disclosure.

[0019] The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit this disclosure or its application or use.

[0020] Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and equipment should be considered part of the specification.

[0021] In all the examples shown and discussed herein, any specific values ​​should be interpreted as merely exemplary and not as limitations. Therefore, other examples of exemplary embodiments may have different values.

[0022] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

[0023] <Hardware Configuration> Figure 1 This is a block diagram of the hardware configuration of the electronic device 1000 for implementing the ECU upgrade testing method provided in this embodiment of the disclosure.

[0024] Electronic device 1000 can be a portable computer, desktop computer, mobile phone, tablet computer, etc. For example... Figure 1 As shown, the electronic device 1000 may include a processor 1100, a memory 1200, an interface device 1300, a communication device 1400, a display device 1500, an input device 1600, a speaker 1700, a microphone 1800, etc. The processor 1100 may be a central processing unit (CPU), a microprocessor (MCU), etc. The memory 1200 may include, for example, ROM (Read-Only Memory), RAM (Random Access Memory), or non-volatile memory such as a hard disk. The interface device 1300 may include, for example, a USB interface, a headphone jack, etc. The communication device 1400 may be capable of wired or wireless communication, specifically including Wi-Fi communication, Bluetooth communication, 2G / 3G / 4G / 5G communication, etc. The display device 1500 may be, for example, an LCD screen, a touch screen, etc. The input device 1600 may include, for example, a touch screen, a keyboard, etc. Users can input / output voice information through the speaker 1700 and the microphone 1800.

[0025] Figure 1 The electronic devices shown are merely illustrative and in no way intended to limit this disclosure, its application, or use. In embodiments applied to this disclosure, the memory 1200 of the electronic device 1000 is used to store instructions for controlling the processor 1100 to operate and execute any of the ECU upgrade test methods provided in embodiments of this disclosure. Those skilled in the art will understand that, although... Figure 1 The electronic device 1000 is shown with multiple devices shown; however, this disclosure may relate only to some of these devices. For example, electronic device 1000 may only relate to processor 1100 and storage device 1200. Those skilled in the art can design instructions based on the schemes disclosed herein. How the instructions control the processor to operate is well known in the art and will not be described in detail here.

[0026] <Method Implementation> Figure 2 This is a flowchart illustrating an embodiment of an ECU upgrade testing method provided in this disclosure. This ECU upgrade testing method can be executed by an electronic device, which may be... Figure 1 The electronic device 1000 shown is, for example Figure 2 As shown, the ECU upgrade testing method of this embodiment may include the following steps S210 to S230: Step S210: In response to the firmware upgrade test command for the target ECU, obtain test cases.

[0027] The test cases should include at least the sequence of states the firmware upgrade task will go through and the expected ECU response for each state. Test cases can be stored and managed using a standardized JSON (JavaScript Object Notation) template.

[0028] In this embodiment, after the electronic device receives the firmware upgrade test command for the target ECU, it loads the corresponding test cases from the test case library of the test execution layer and parses the state sequence and the expected ECU response corresponding to each state.

[0029] The state sequence defines the execution path of the ECU upgrade task. The state sequence can include standby state (S0 state), programming session state (S1 state), secure access state (S2 state), data transmission state (S3 state), verification state (S4 state), activation state (S5 state), and rollback state (S6 state). The state machine engine can drive the firmware upgrade task to execute sequentially according to this state sequence. During a normal upgrade, the state transition path is S0→S1→S2→S3→S4→S5; in case of an anomaly, the current state jumps to the S6 rollback state.

[0030] Step S220: Determine the current state based on the state sequence, and call the target application programming interface (API) that encapsulates various standard unified diagnostic services (UDS) to convert the standard UDS corresponding to the current state into the driving instructions corresponding to the currently active communication tool through the pre-configured UDS mapping table, and drive the target ECU to perform firmware upgrade tasks based on the driving instructions.

[0031] The current state can be any one of S0, S1, S2, S3, S4, or S5, depending on the current stage of the upgrade task. The state machine engine can determine the current state node that the target ECU should execute based on the state sequence defined in the acquired test cases. Once the state machine engine determines the current state, the electronic device can obtain the standard UDS corresponding to that current state and issue the service through the target API.

[0032] In this embodiment, the unified diagnostic service abstraction layer includes the target API and the UDS mapping table, which serves as a bridge between the state machine engine and the underlying communication tools.

[0033] The target API encapsulates various standard UDSs (such as Session Control Service 0x10, Secure Access Service 0x27, Download Request Service 0x34, Data Transmission Service 0x36, Exit Transmission Request Service 0x37, Routine Control Service 0x31, ECU Reset Service 0x11, etc.), providing a unified entry point for external calls. The state machine engine issues the standard UDS corresponding to the current state by calling this target API, without needing to concern itself with the specific implementation of the underlying communication tools.

[0034] The UDS mapping table stores the correspondence between standard UDSs and the driver instructions of various communication tools. Specifically, the UDS mapping table uses the standard UDS identifier as the key and the set of underlying driver instructions corresponding to each communication tool as the value to construct the mapping relationship between the standard UDS and the tool implementation. For example, the UDS mapping table stores the correspondence between the request download service 0x34 (request download) and the COM interface call method of the first communication tool (such as CANoe), and the CAN frame format of the second communication tool (such as the Zhouligong CAN analyzer). Similarly, other standard UDSs (such as 0x10 session control, 0x36 data transmission, etc.) also store their respective correspondences with the driver instruction formats of various communication tools in the UDS mapping table in the same way as described above, and will not be listed here.

[0035] In this embodiment, the state machine engine determines the current state and the required standard UDS based on the state sequence in the test case, and then calls the target API. The target API reads the identifier of the currently active communication tool, uses the standard UDS identifier and the currently active communication tool identifier as indexes to obtain the corresponding drive instruction format from the UDS mapping table, fills in the call parameters, and outputs the complete drive instruction, which is then sent to the target ECU by the currently active communication tool.

[0036] For example, the UDS mapping table stores the correspondence between 0x34 (request download) and the COM interface call method of the first communication tool (such as CANoe), and the CAN frame format of the second communication tool (such as the Zhou Ligong CAN analyzer). When the currently active communication tool is the first communication tool, the target API translates the 0x34 service into a COM interface call of the first communication tool, encapsulates it via the protocol adapter of the first communication tool's sublayer, and sends it to the target ECU via the Controller Area Network (CAN) bus. When the currently active communication tool is the second communication tool, the target API translates the 0x34 service into a CAN message frame with a specific identifier, encapsulates it via the protocol adapter of the second communication tool's sublayer, and sends it to the target ECU. In this way, it is unnecessary to know which communication tool is executing the underlying code, and the test logic does not need to be modified when changing the communication tool, achieving transparent routing between the standard UDS and the underlying communication tool driver instructions.

[0037] After the drive command is sent to the target ECU, the electronic device listens for the target ECU's response messages in real time using the currently active communication tool. If the target ECU returns a positive response, the state machine engine marks the current state as passed and advances to the next state according to the state sequence until all state sequences have been traversed. If the target ECU returns a negative response code (NRC), the state machine engine will execute the corresponding operation according to the pre-configured exception handling strategy.

[0038] By adopting the above approach, test cases are decoupled from the underlying communication hardware. The writing of test cases only needs to focus on the semantics and state transition logic of the standard UDS, without needing to be modified as the communication tools change, which effectively improves the portability and automation of the test solution.

[0039] Step S230: Obtain the actual response from the target ECU, compare the actual response in each state with the expected response of the corresponding ECU, and generate the firmware upgrade test results for the target ECU.

[0040] In this embodiment, during the firmware upgrade task, the electronic device receives the actual response from the target ECU via the CAN bus through the currently active communication tool. The state machine engine then compares the actual response with the expected ECU response preset in the test case, state by state. If the actual response matches the expected response, the state is considered successfully executed, and the state machine engine proceeds to the next state. If the actual response does not match the expected response, the state is considered unsuccessful.

[0041] After the state machine engine has traversed all states in the state sequence, the electronic device summarizes the execution results of each state and generates the firmware upgrade test results for the target ECU. The firmware upgrade test results can be output in the form of structured data tables or displayed in the form of visual charts, making it easy for users to intuitively understand the entire upgrade test process.

[0042] The method disclosed herein provides a unified diagnostic service API that automatically executes the upgrade test process in response to user initiation of ECU firmware upgrade testing. This eliminates the need for manual issuance of diagnostic commands or switching of communication tools, significantly simplifying the operation process, reducing operational complexity, and improving the efficiency of ECU upgrade testing. Furthermore, this method uses a pre-configured UDS mapping table to convert standard UDS into drive commands corresponding to the currently active communication tool in real time, decoupling test cases from the underlying communication tool. This eliminates the need to modify test logic due to tool switching. Moreover, it drives the ECU to automatically execute upgrade tasks through state sequences and generates test results based on automatic comparison of actual and expected responses, eliminating the need for manual observation and judgment, thus effectively improving the automation level of ECU upgrade testing.

[0043] In some embodiments, the above-described ECU upgrade testing method further includes a dynamic switching mechanism for communication tools.

[0044] In this embodiment, the electronic device acquires an index value that characterizes the communication quality of the currently active communication tool in real time, determines whether the index value meets the preset switching conditions, and switches the currently active communication tool from the first communication tool to the second communication tool if the index value meets the preset switching conditions.

[0045] The indicator value includes at least one of message delay and a negative response code from the target ECU. Correspondingly, the preset switching conditions include at least one of the following: the message delay exceeds a message delay threshold, or the number of consecutively received negative response codes exceeding a set threshold. For example, the message delay threshold can be set to 50ms, and the set negative response code can be set to 0x78 (ECU is busy). When the message delay exceeds 50ms, or the number of consecutively received negative response codes of 0x78 exceeds the threshold, the communication tool switching is automatically triggered.

[0046] The first communication tool can be the CANoe tool, and the second communication tool can be the Zhou Ligong tool. Alternatively, the first communication tool can be the Zhou Ligong tool, and the second communication tool can be the CANoe tool.

[0047] In some examples, during the process of switching the currently active communication tool from the first communication tool to the second communication tool, the session context of the firmware upgrade task is transferred from the first communication tool to the second communication tool. This session context includes execution status information of the firmware upgrade task before the switch, such as the current state of the ECU, the index of data blocks that have been confirmed as completed, and the list of services that have been sent but for which responses have not yet been received. Based on this session context, the second communication tool can continue executing the firmware upgrade task from where it was interrupted, without having to start from scratch.

[0048] For example, the currently active communication tool is CANoe. When it is transmitting data to the 45th data block, the communication quality degrades, triggering a switchover. The electronic device transmits the session context, including the current state (S3 state), the index of the confirmed completed data block (block_idx=45), and the list of pending services (pending_services=[0x36, 0x37]), to the Zhou Ligong tool. After receiving the session context, the Zhou Ligong tool continues transmitting from the 46th data block. The target ECU is unaware of the communication tool switchover, and the upgrade task remains continuous before and after the switchover.

[0049] In this embodiment, during the tool switching process, the session context is completely transferred from the first communication tool to the second communication tool, and the firmware upgrade task remains continuous before and after the switch, without the need for manual restart or reconfiguration.

[0050] In some embodiments, the above-described ECU upgrade testing method further includes timestamp alignment processing of multi-source execution logs.

[0051] In this embodiment, the electronic device acquires multi-source execution logs generated during the firmware upgrade task execution process, and performs timestamp alignment processing on the multi-source execution logs to generate multi-source fused logs.

[0052] The multi-source execution log includes script execution logs generated from executing test cases and communication logs output by the currently active communication tool. The communication logs output by the currently active communication tool may include a first communication log output by a first communication tool and a second communication log output by a second communication tool.

[0053] In some examples, electronic devices can use hardware clock synchronization and software interpolation algorithms to align multi-source execution logs along a unified timeline to generate multi-source fused logs.

[0054] This embodiment enables logs from different sources to be correlated and analyzed on the same timeline, effectively solving the problem of difficulty in fault location caused by inconsistent log timelines in related technologies.

[0055] In some embodiments, the above-described ECU upgrade testing method further includes a breakpoint resumption testing mechanism.

[0056] In this embodiment, when the electronic device restarts after the firmware upgrade task is interrupted, it loads the most recently saved context snapshot and verifies whether the memory data of the target ECU is consistent with the execution status information recorded in the context snapshot. If the verification is consistent, the firmware upgrade task continues to be executed according to the context snapshot.

[0057] In some examples, electronic devices save a context snapshot of the firmware upgrade task at preset intervals during the execution of the firmware upgrade task. The context snapshot includes execution state information before the firmware upgrade task is interrupted, such as the current state of the target ECU, the index of data blocks that have been confirmed to be completed, and the list of services to be processed. The context snapshot is persistent storage data formed by serializing the above session context at preset intervals.

[0058] In some examples, when a firmware upgrade task is interrupted and restarted due to power failure, tool crash, or other reasons, the electronic device loads the most recently saved context snapshot and verifies whether the memory data of the target ECU is consistent with the execution status information recorded in the context snapshot. If the verification is consistent, the electronic device skips the verified data blocks based on the transmitted data block index recorded in the context snapshot and continues the firmware upgrade task from the interrupted position, without having to start from the beginning. If the verification is inconsistent, a rollback process is triggered to ensure the data integrity of the target ECU.

[0059] Through this embodiment, the electronic device can automatically resume execution from the most recently saved breakpoint after the upgrade task is interrupted due to power failure, tool failure, or other reasons, without having to start from scratch, thus saving testing time and reducing the risk of ECU data corruption.

[0060] In some embodiments, test cases include forward test cases and reverse test cases. The reverse test cases include fault configuration information, which is used to inject faults into the set states in the state sequence.

[0061] In this embodiment, the forward test cases drive the target ECU to complete the firmware upgrade according to the complete state transition path, verifying the correctness of the normal upgrade process. The reverse test cases, on the other hand, trigger a fault in a specified state using fault configuration information, verifying the effectiveness of the exception handling and rollback mechanisms.

[0062] In this embodiment, step S210, which responds to the firmware upgrade test command for the target ECU, may further include: displaying a test scenario selection interface in response to the firmware upgrade test command for the target ECU; wherein the test scenario selection interface includes a forward test control and a reverse test control; obtaining forward test cases in response to the user's selection operation of the forward test control; and obtaining reverse test cases in response to the user's selection operation of the reverse test control.

[0063] This embodiment supports injecting reverse test cases of faults in specified states, realizing forward and reverse test coverage of the entire state path of ECU firmware upgrade, significantly improving the test coverage capability of abnormal scenarios, and allowing users to flexibly select test types through the test scenario selection interface, further improving the flexibility and ease of use of testing.

[0064] <Example> Figure 3 A flowchart illustrating an example ECU upgrade testing method is shown below. Figure 3 As shown, the ECU upgrade test method in this example includes the following steps S301 to S309: Step S301, tool initialization operation.

[0065] In step S301, the electronic device initializes the first communication tool CANoe, the second communication tool Zhou Ligong, and peripheral functional components to establish a communication connection with the target ECU.

[0066] Step S302: Check if the device connection is normal. If yes, proceed to step S303; otherwise, proceed to step S309.

[0067] In step S302, the electronic device detects whether the communication link between the first communication tool CANoe and the target ECU and the communication link between the second communication tool Zhou Ligong and the target ECU are established. If yes, step S303 is executed; otherwise, step S309 is executed.

[0068] Step S303: Configure interface parameters and load test cases.

[0069] In step S303, the electronic device responds to the user's configuration operation on the interactive interface, configures communication parameters (such as CAN channel number, baud rate, etc.), and determines the selected test scenario. In this example, if the user selects a forward test scenario to verify the firmware upgrade capability of the target ECU under normal conditions, the electronic device loads the corresponding forward test case template from the test case library according to the user's selected test scenario. This forward test case defines a complete upgrade state sequence: S0 (standby state) → S1 (programming session state) → S2 (secure access state) → S3 (data transmission state) → S4 (verification state) → S5 (activation state), and the expected ECU response for each state. The electronic device parses the test case to obtain the state sequence and the expected ECU response for each state.

[0070] Step S304: Execute the test process based on the test cases.

[0071] In step S304, the electronic device sequentially drives the target ECU to perform the upgrade task according to the state sequence, and obtains the actual response from the target ECU in each state. For the specific execution process, please refer to the relevant description in the above method embodiment.

[0072] Step S305: Check whether the actual response and the expected response of each state are consistent. If yes, proceed to step S306; otherwise, proceed to step S307.

[0073] Step S306: Confirm that the firmware upgrade test has passed, and proceed to step S308.

[0074] Step S307: Determine if the firmware upgrade test failed, locate the cause of the failure, record detailed logs, and proceed to step S308.

[0075] Step S308: Generate a test report; process ends.

[0076] Step S309: Display the device error log, prompting you to check the hardware / driver, and the process ends.

[0077] In step S309, if the electronic device detects an abnormal device connection, it displays a device error log, prompting the user to troubleshoot hardware or driver issues, and the process ends.

[0078] <Device Embodiment> Figure 4 This is a schematic block diagram of the ECU upgrade testing device provided in the embodiments of this disclosure, as follows: Figure 4 As shown, the ECU upgrade testing device 400 includes an acquisition module 410, a drive module 420, and a generation module 430.

[0079] The acquisition module 410 is used to acquire test cases in response to a firmware upgrade test command for the target ECU; wherein, the test cases include at least the state sequence that the firmware upgrade task goes through and the expected response of the ECU for each state; The driver module 420 is used to determine the current state based on the state sequence, and call the target API encapsulated with various standard UDSs, so as to convert the standard UDS corresponding to the current state into the driver instructions corresponding to the currently active communication tool through a pre-configured UDS mapping table, and drive the target ECU to perform a firmware upgrade task based on the driver instructions; wherein, the UDS mapping table stores the correspondence between the standard UDS and the driver instructions of each communication tool; The generation module 430 is used to obtain the actual response fed back by the target ECU, compare the actual response in each state with the corresponding expected response of the ECU, and generate the firmware upgrade test result of the target ECU.

[0080] In one embodiment, the device 400 further includes a switching module (not shown).

[0081] The acquisition module 410 is used to acquire index values ​​that characterize the communication quality of currently active communication tools; The switching module is used to determine whether the indicator value meets the preset switching conditions; if the indicator value meets the preset switching conditions, the currently active communication tool is switched from the first communication tool to the second communication tool.

[0082] In one embodiment, the indicator value includes at least one of message delay and negative response code returned by the target ECU; The preset switching conditions include at least one of the following: the message delay exceeds the message delay threshold, or the number of consecutively received negative response codes exceeding the set negative response code threshold.

[0083] In one embodiment, the switching module is used to transfer the session context of the firmware upgrade task from the first communication tool to the second communication tool during the process of switching the currently active communication tool from the first communication tool to the second communication tool; The session context includes the execution status information of the firmware upgrade task before the switch, and the session context is used for the second communication tool to continue executing the firmware upgrade task.

[0084] In one embodiment, the acquisition module 410 is used to acquire multi-source execution logs generated during the execution of the firmware upgrade task; wherein, the multi-source execution logs include script execution logs generated by executing the test cases, first communication logs output by the first communication tool, and second communication logs output by the second communication tool; The generation module 430 is used to perform timestamp alignment processing on the multi-source execution logs to generate multi-source fused logs.

[0085] In one embodiment, the device 400 further includes a loading module and a verification module (both not shown in the figure).

[0086] A loading module is used to load the most recently saved context snapshot when the firmware upgrade task is restarted after being interrupted; wherein, the context snapshot includes execution state information before the firmware upgrade task was interrupted; The verification module is used to verify whether the memory data of the target ECU is consistent with the execution status information recorded in the context snapshot; if the verification is consistent, the firmware upgrade task continues to be executed according to the context snapshot.

[0087] In one embodiment, the state sequence includes a standby state, a programming session state, a secure access state, a data transmission state, a verification state, an activation state, and a rollback state. The test cases include forward test cases and reverse test cases. The reverse test cases include fault configuration information, which is used to inject faults into the set states in the state sequence.

[0088] According to embodiments of this disclosure, by providing a target API that integrates unified diagnostic services, the upgrade test process can be automatically executed in response to the user's initiation operation for ECU firmware upgrade testing. This eliminates the need for manual issuance of diagnostic commands or switching of communication tools, significantly simplifying the operation process, reducing operational complexity, and improving the efficiency of ECU upgrade testing. Simultaneously, this method uses a pre-configured UDS mapping table to convert standard UDS into drive commands corresponding to the currently active communication tool in real time, decoupling test cases from the underlying communication tool. This eliminates the need to modify test logic due to tool switching. Furthermore, by driving the ECU to automatically execute upgrade tasks through state sequences, and automatically comparing the actual response with the expected response to generate test results, no manual observation or judgment is required, effectively improving the automation level of ECU upgrade testing.

[0089] <Equipment Example> Figure 5 This is a schematic block diagram of an electronic device provided in one embodiment of this disclosure. Figure 5 As shown, the electronic device 1000 includes a processor 1100 and a memory 1200.

[0090] The memory 1200 can be used to store executable computer instructions.

[0091] The processor 1100 can be used to execute the ECU upgrade test method according to the method embodiments of this disclosure, under the control of the executable computer instructions.

[0092] The electronic device 1000 may include the above-mentioned ECU upgrade test device 400.

[0093] In one embodiment, each module of the above ECU upgrade testing device 400 can be implemented by the processor 1100 running computer instructions stored in the memory 1200.

[0094] Computer-readable storage media This disclosure also provides a computer-readable storage medium storing computer instructions thereon, which, when executed by a processor, perform the ECU upgrade testing method provided in this disclosure.

[0095] This disclosure can be a system, method, and / or computer program product. A computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for causing a processor to implement various aspects of this disclosure.

[0096] Computer-readable storage media can be tangible devices capable of holding and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example—but not limited to—electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination of the foregoing. The computer-readable storage media used herein are not to be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0097] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0098] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.

[0099] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0100] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0101] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0102] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions. It will be known to those skilled in the art that implementation in hardware, implementation in software, and implementation in a combination of software and hardware are equivalent.

[0103] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, and are not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or technical improvements to the embodiments in the market, or to enable others skilled in the art to understand the embodiments disclosed herein. The scope of this disclosure is defined by the appended claims.

Claims

1. An ECU upgrade testing method, characterized in that, The method includes: In response to a firmware upgrade test command for the target ECU, test cases are obtained; wherein, the test cases include at least the state sequence traversed by the firmware upgrade task and the expected ECU response for each state; The current state is determined based on the state sequence, and the target API encapsulating various standard UDSs is called to convert the standard UDS corresponding to the current state into the driving instructions corresponding to the currently active communication tool through a pre-configured UDS mapping table, and to drive the target ECU to perform a firmware upgrade task based on the driving instructions; wherein, the UDS mapping table stores the correspondence between the standard UDS and the driving instructions of each communication tool; The actual response from the target ECU is obtained, and the actual response in each state is compared with the expected response of the corresponding ECU to generate the firmware upgrade test result of the target ECU.

2. The method according to claim 1, characterized in that, The method further includes: Obtain the metrics that characterize the communication quality of currently active communication tools; Determine whether the indicator value meets the preset switching conditions; If the indicator value meets the preset switching conditions, the currently active communication tool will be switched from the first communication tool to the second communication tool.

3. The method according to claim 2, characterized in that, The indicator value includes at least one of message delay and negative response code returned by the target ECU; The preset switching conditions include at least one of the following: the message delay exceeds the message delay threshold, or the number of consecutively received negative response codes exceeding the set negative response code threshold.

4. The method according to claim 2, characterized in that, The step of switching the currently active communication tool from the first communication tool to the second communication tool includes: During the process of switching the currently active communication tool from the first communication tool to the second communication tool, the session context of the firmware upgrade task is transferred from the first communication tool to the second communication tool; The session context includes the execution status information of the firmware upgrade task before the switch, and the session context is used for the second communication tool to continue executing the firmware upgrade task.

5. The method according to claim 1, characterized in that, The method further includes: Obtain multi-source execution logs generated during the execution of the firmware upgrade task; wherein, the multi-source execution logs include script execution logs generated by executing the test cases, first communication logs output by the first communication tool, and second communication logs output by the second communication tool; The multi-source execution logs are timestamped to generate multi-source fused logs.

6. The method according to claim 1, characterized in that, The method further includes: When the firmware upgrade task is restarted after being interrupted, the most recently saved context snapshot is loaded; wherein, the context snapshot includes the execution state information before the firmware upgrade task was interrupted; Verify whether the memory data of the target ECU is consistent with the execution status information recorded in the context snapshot; If the verification is successful, the firmware upgrade task continues to be executed based on the context snapshot.

7. The method according to claim 1, characterized in that, The state sequence includes standby state, programming session state, secure access state, data transmission state, verification state, activation state, and rollback state. The test cases include forward test cases and reverse test cases. The reverse test cases include fault configuration information, which is used to inject faults into the set states in the state sequence.

8. The method according to claim 7, characterized in that, The process of obtaining test cases in response to a firmware upgrade test command for the target ECU includes: In response to a firmware upgrade test command for the target ECU, a test scenario selection interface is displayed; wherein, the test scenario selection interface includes forward test controls and reverse test controls; In response to the user's selection operation on the positive test control, the positive test cases are obtained; In response to the user's selection of the reverse test control, the reverse test case is obtained.

9. An ECU upgrade testing device, characterized in that, The device includes: The acquisition module is used to acquire test cases in response to a firmware upgrade test command for the target ECU; wherein, the test cases include at least the state sequence that the firmware upgrade task goes through and the expected response of the ECU for each state; The driver module is used to determine the current state based on the state sequence, and call the target API which encapsulates various standard UDSs, so as to convert the standard UDS corresponding to the current state into the driver instructions corresponding to the currently active communication tool through a pre-configured UDS mapping table, and drive the target ECU to perform firmware upgrade tasks based on the driver instructions; wherein, the UDS mapping table stores the correspondence between the standard UDS and the driver instructions of each communication tool; The generation module is used to obtain the actual response from the target ECU, compare the actual response in each state with the expected response of the corresponding ECU, and generate the firmware upgrade test result of the target ECU.

10. An electronic device, characterized in that, include: Memory is used to store executable computer instructions; A processor, configured to execute the ECU upgrade test method according to any one of claims 1-7, under the control of the executable computer instructions.

Images