Automatic FBL testing method based on CAPL script

Abstract

The invention belongs to the technical field of FBL flash test, and particularly relates to a CAPL script-based FBL automatic test method, which comprises the following steps of: S1, acquiring a communication parameter and an expected response parameter of a target ECU (Electronic Control Unit); establishing diagnostic communication with the target ECU based on the communication parameters; the expected response parameter is set as a first global variable; s2, a multi-step test process is automatically executed on the target ECU through the CAPL script; s3, through an event processing mechanism of the CAPL script, performing adaptive analysis and processing on a response message returned by the target ECU in the execution process of the S2; s4, comparing the expected response parameter with the actual response data, and automatically judging whether the current test step is passed or failed according to a comparison result; and S5, after the test process is executed, automatically generating a structured test report. According to the method, the communication characteristics of different ECUs can be dynamically adapted on the premise that manual intervention is not needed, the flow control and suspension states are processed in real time, and the flashing result is accurately verified.

Description

Technical Field

[0001] This invention belongs to the field of FBL flashing and testing technology, and particularly relates to an automated FBL testing method based on CAPL scripts. Background Technology

[0002] In the development and production of automotive electronic control units (ECUs), firmware updates based on the Flash Bootloader (FBL) are a crucial step in ensuring ECU functional iteration, defect repair, and security upgrades. FBL flashing tests typically involve complex diagnostic communication processes, including session control, secure access, data transmission, and verification, requiring strict adherence to diagnostic protocol specifications such as ISO 14229 (UDS) or KWP2000. Currently, this type of testing is widely used in OEMs, Tier 1 suppliers for R&D verification, final production line inspection, and after-sales maintenance.

[0003] However, existing FBL testing methods suffer from significant technical bottlenecks. First, traditional testing heavily relies on manual operation of general diagnostic tools (such as Zhou Ligong equipment and CANoe's built-in diagnostic functions). Testers must manually trigger each diagnostic request and verify the response one by one, which is not only inefficient but also highly susceptible to misjudgments or missed tests due to human error. Second, while some semi-automated scripts can execute the basic process, their hard-coded logic severely lacks flexibility, making it difficult to adapt to different ECU models, bootloader versions, or communication protocols (such as the differences between UDS and KWP2000), resulting in low script reusability and high maintenance costs. More critically, existing solutions generally lack dynamic monitoring capabilities for the entire flashing process—they cannot parse the flow control frames returned by the ECU in real time to adaptively adjust the data transmission rhythm, nor can they identify intermediate states such as "RequestPending" to maintain process continuity. Furthermore, under abnormal operating conditions (such as voltage fluctuations or communication interruptions), the lack of automatic rollback mechanisms and structured log recording makes fault location difficult, severely impacting the reliability and traceability of the test.

[0004] Therefore, how to dynamically adapt to the communication characteristics of different ECUs, handle flow control and suspend status in real time, and accurately verify the flashing results without human intervention has become an urgent problem to be solved. Summary of the Invention

[0005] To address the shortcomings of the existing technologies, this invention provides an automated FBL testing method based on CAPL scripts, which can dynamically adapt to the communication characteristics of different ECUs, handle flow control and suspend states in real time, and accurately verify flashing results without manual intervention.

[0006] To solve the above-mentioned technical problems, the present invention adopts the following technical solution:

[0007] An automated FBL testing method based on CAPL scripts includes the following steps:

[0008] S1. Read the external configuration file to obtain the communication parameters and expected response parameters of the target ECU; establish diagnostic communication with the target ECU based on the communication parameters; the expected response parameters are set as the first global variable;

[0009] S2. Based on the communication established in S1, a multi-step test process is automatically executed to the target ECU via a CAPL script; the test process includes a firmware data download stage and a diagnostic request interaction stage; during the execution of the test process, the test process is controlled according to preset conditions;

[0010] S3. Through the event handling mechanism of the CAPL script, adaptively parse and process the response messages returned by the target ECU during the execution of S2, including:

[0011] Identify and skip specific responses that indicate the request is pending in order to maintain the continuity of the testing process;

[0012] During the firmware data download phase, the flow control frame returned by the target ECU is identified, and the data block sending rhythm is dynamically adjusted according to the control parameters in the flow control frame to achieve synchronization with the ECU's transmission rate.

[0013] During the diagnostic request interaction phase, the response message returned by the target ECU indicating the result of a single test step is identified, and the actual response data carried in the response message is stored in a second global variable;

[0014] S4. Compare the expected response parameters in the first global variable in S1 with the actual response data in the second global variable in S3, and automatically determine whether the current test step passes or fails based on the comparison results.

[0015] S5. After the test process is completed, a structured test report is automatically generated. The report includes test environment information, an overall overview of the test execution, and the execution results of each test step.

[0016] Compared with existing technologies, this technical solution achieves efficient, reliable, and universal testing of the FBL (Flash Bootloader) flashing process by building structured, event-driven automated test logic in the CAPL script. The specific effects are as follows:

[0017] 1. Externalizing the configuration of communication parameters and expected responses significantly improves the versatility and maintainability of test scripts. By reading the target ECU's communication parameters (such as CAN ID, baud rate, diagnostic session address, etc.) and expected response parameters from an external configuration file and loading them as global variables, hardcoding ECU-specific information into the script is avoided. Compared to traditional semi-automated scripts that require rewriting or modifying code for each ECU, this solution supports "develop once, reuse across multiple vehicle models," greatly reducing the cost of adapting to different ECU models or Bootloader versions.

[0018] 2. Adaptive parsing and flow control of ECU responses based on the CAPL event mechanism enhances test robustness. Utilizing CAPL's message reception event processing capabilities, various response types returned by the ECU are dynamically identified: "RequestPending" responses are automatically skipped and await the final result, preventing process interruptions due to misjudgment; during the firmware download phase, flow control frames are parsed in real time, dynamically adjusting the data block sending rhythm based on parameters such as block size and interval time to ensure synchronization with the ECU's transmission capacity. Compared to traditional methods relying on fixed delays or manual intervention, this mechanism significantly improves the stability and continuity of testing in complex communication environments.

[0019] 3. A dual global variable mechanism is introduced to achieve accurate comparison and automatic judgment between expected and actual responses. Expected response parameters and the actual received ECU response are stored in first and second global variables, respectively. Consistency checks are automatically performed after each test step, thus objectively and accurately determining whether the test passed or failed. This mechanism replaces manual verification of response content, eliminating subjective judgment errors and providing a structured data foundation for subsequent automated report generation.

[0020] 4. Fully automated execution and structured report generation enhance testing efficiency and traceability. From establishing communication and executing multi-stage flushing processes to result verification and report output, the entire testing process requires no manual intervention. After testing, a structured report containing test environment information, an execution overview, and results for each step is automatically generated, facilitating issue backtracking and quality auditing. Compared to traditional methods relying on manual recording or scattered logs, this solution significantly improves the standardization of the testing process and the reliability of the results.

[0021] In summary, this invention, through an event-driven architecture and a dual global variable mechanism, achieves state awareness and adaptive control of the entire FBL process within the CAPL script, realizing a fully automated FBL testing capability of "one-time development, multi-model reuse". This method can dynamically adapt to the communication characteristics of different ECUs, handle flow control and suspension states in real time, and accurately verify flashing results without manual intervention.

[0022] Preferably, in S1, the external configuration file is a .cin file, in which the defined parameters include the communication parameters, firmware block size parameters, and strategy parameters for controlling the execution strategy of the test process.

[0023] This setup offers several advantages: 1. Improved standardization of configuration management and enhanced toolchain integration. Utilizing the .cin file, natively supported by CANoe, as the external configuration carrier ensures natural compatibility with the Vector tool ecosystem. This allows key configuration items such as communication parameters (e.g., CAN ID, UDS SID), firmware block size, and process control strategies to be directly loaded and managed within the CANoe project. Compared to using custom text or Excel configurations, .cin files offer advantages such as structured format, type safety, and version control, effectively reducing the risk of configuration errors.

[0024] 2. Enables flexible control and scenario adaptation of test behavior. Firmware block size and test process strategies (such as aborting or continuing after failure) are incorporated into a unified configuration, allowing the same CAPL script to dynamically adjust its execution logic based on different ECU performance or test objectives (such as R&D verification vs. production line final inspection). Test granularity and fault tolerance strategies can be switched without modifying the code, significantly enhancing the adaptability and reusability of automated testing across multiple scenarios.

[0025] Preferably, in S2, controlling the test process according to preset conditions includes: when a test step is determined to be a failure, selecting to terminate the current test case or record the failure and continue to execute subsequent test steps according to the strategy parameters in the external configuration file.

[0026] This setup allows for: 1) flexible configuration of test execution strategies to adapt to diverse verification needs. Failure handling strategies (abort or continue) can be defined through external configuration files, enabling the same CAPL test script to be flexibly applied to different testing scenarios: for example, strictly aborting during final production line inspection to ensure quality consistency, while allowing continued execution during R&D verification to comprehensively collect fault information. This configurability avoids the need for repeated script development or modification for different scenarios, improving the reusability of test assets.

[0027] 2. In "Record Failure and Continue" mode, the system can execute all test steps completely, exposing multiple potential problems rather than just the first failure point. Compared to the traditional "stop upon encountering an error" approach, this mechanism significantly improves the amount of information in the test results and the efficiency of problem localization, making it particularly suitable for fault analysis in complex FBL processes with multiple coupled stages.

[0028] Preferably, the diagnostic requests sent during the diagnostic request interaction phase include an extended session entry request, a secure access request, and a routine control request.

[0029] This setup, through the structured integration of the core diagnostic requests necessary for FBL flashing, constructs a secure, standardized, and automatically executable test loop, significantly enhancing the depth, reliability, and engineering applicability of the tests.

[0030] Preferably, in S1, the communication parameters include a physical addressing CAN identifier for sending a diagnostic request to the target ECU, and a UDS service identifier for constructing the diagnostic request.

[0031] This setup, through explicit configuration of physical addressing and UDS service identifiers, ensures the accuracy and reliability of diagnostic communication and provides key support for achieving the goal of "one-time development, multi-ECU adaptation" in automated testing.

[0032] Preferably, in S3, the specific response indicating that the request is suspended is a response message that conforms to the UDS protocol and has a UDS service identifier equal to 0x78; the flow control frame is a response message that conforms to the UDS protocol and has a first byte of 0x30 or 0x32, and the control parameters it contains include block size and minimum interval time.

[0033] This setup ensures: 1. Accurate identification of intermediate states and flow control commands in the UDS standard, guaranteeing the continuity and stability of the testing process. By explicitly using the "request suspension" response (service identifier 0x78) and flow control frames (first byte 0x30 or 0x32) defined in the UDS protocol as the parsing criteria, the CAPL script can accurately distinguish between the ECU's temporary waiting state and valid control commands, avoiding misjudgments as communication failures or timeouts. Compared to methods relying on fixed delays or fuzzy matching, this approach is more in line with protocol specifications, significantly improving the robustness of testing in complex interaction scenarios.

[0034] 2. Achieve dynamic transmission control based on standard parameters to optimize flashing efficiency and compatibility. The block size and separation time contained in the flow control frame are the core control parameters for UDS multi-frame transmission. The script dynamically adjusts the sending rhythm of subsequent data blocks based on these parameters, which can avoid ECU buffer overflow due to excessively fast transmission and prevent excessively slow transmission from affecting test efficiency. This mechanism enables the test system to adapt to the receiving capabilities of different ECUs without the need for manually preset conservative parameters, improving the versatility and execution efficiency of automated flashing.

[0035] Preferably, in S3, during the firmware data download stage, the transmission interval between adjacent data blocks is dynamically set according to the minimum interval time in the flow control frame.

[0036] This setup achieves two key advantages: 1. Precise synchronization with the ECU's receiving capabilities, preventing communication overload or timeouts. By parsing the minimum interval time (Separation Time) in the flow control frame and dynamically setting the data block transmission interval accordingly, the CAPL script strictly adheres to the ECU's current processing rhythm. Compared to traditional methods using fixed or empirical delays, this mechanism effectively prevents ECU buffer overflows due to excessively rapid transmission or diagnostic timeouts caused by excessively long intervals, significantly improving the stability and success rate of the flashing process.

[0037] 2. Enhance the adaptability of test scripts to different ECU platforms. ECUs from different manufacturers or models often have differences in flow control parameters, making it difficult to ensure compatibility with hard-coded transmission intervals. This solution automatically adjusts the transmission rhythm based on the minimum interval time fed back by the ECU in real time, allowing the same test script to adapt to multiple ECUs without modification, thus enhancing the versatility and deployment efficiency of FBL automated testing in heterogeneous environments.

[0038] Preferably, the comparison in S4 specifically includes:

[0039] If the actual response is positive and its response code matches the expected response parameters, then it is considered passed;

[0040] If the actual response is a negative response with the UDS service identifier equal to 0x7F, and the error code it contains is consistent with the expected response parameters, then it is considered successful.

[0041] This setup offers several advantages: 1. It supports dual verification of both positive and negative responses, enhancing the completeness of test criteria. This solution not only verifies whether the positive response returned by the ECU meets expectations, but also explicitly considers negative responses (UDS 0x7F + a specific error code) that meet expectations as "passes," thus covering legitimate exception scenarios such as security access denial and unsupported routines. Compared to traditional methods that only judge successful responses, this mechanism better aligns with actual diagnostic logic, avoiding misjudging compliant negative responses as test failures.

[0042] 2. Enhance the expressiveness and verification depth of test cases. By pre-setting specific error codes in the expected response parameters, testers can proactively verify whether the ECU's behavior under abnormal input or restricted conditions conforms to specifications (e.g., refusing to write when unlocked). This enables automated testing not only to verify "normal functionality" but also "correct error handling," significantly improving the coverage and quality assurance capabilities of FBL testing.

[0043] Preferably, before executing S1, the method further includes step S0: loading a graphical test execution interface built on XML language, and receiving input for selecting test cases through the interface to determine the test process to be executed.

[0044] This setup, by introducing a lightweight, configurable graphical testing interface, effectively bridges the gap between automated scripts and actual operations. While ensuring technical rigor, it significantly improves the ease of use, flexibility, and engineering implementation efficiency of FBL testing.

[0045] Preferably, in S5, the test environment information includes the tool version, configuration file path, script execution path, and log file path; the overall test execution overview includes the execution start time, total number of test cases, number of passed test cases, number of failed test cases, and pass rate; the execution results of each test step include step description, expected response, actual response, and judgment status.

[0046] This setup, by generating comprehensive and clearly structured test reports, not only meets the basic criteria for automated verification but also builds a one-stop data foundation for quality analysis, issue backtracking, and compliance auditing, effectively strengthening the quality assurance capabilities of the FBL testing loop. Attached Figure Description

[0047] To make the objectives, technical solutions, and advantages of the invention clearer, the invention will now be described in further detail with reference to the accompanying drawings, wherein:

[0048] Figure 1 This is a flowchart of the method. Detailed Implementation

[0049] The following detailed explanation illustrates the specific implementation methods:

[0050] Example

[0051] like Figure 1 As shown, this embodiment discloses an automated FBL testing method based on CAPL scripts, including the following steps:

[0052] S1. Read the external configuration file to obtain the communication parameters and expected response parameters of the target ECU; establish diagnostic communication with the target ECU based on the communication parameters; the expected response parameters are set as the first global variable.

[0053] The communication parameters include a physical addressing CAN identifier for sending diagnostic requests to the target ECU, and a UDS service identifier for constructing the diagnostic request. By explicitly configuring the physical addressing and UDS service identifier, the accuracy and reliability of diagnostic communication are ensured, and key support is provided for achieving the goal of automated testing that allows for "one-time development and multi-ECU adaptation."

[0054] In practice, the external configuration file is a .cin file, which defines parameters including communication parameters, firmware block size parameters, and strategy parameters for controlling the execution strategy of the test process.

[0055] The .cin file is a configuration file format supported by the Vector CANoe platform. It uses ASCII text and contains sections and key-value pairs. This is common knowledge in the field and will not be elaborated further.

[0056] For ease of understanding, the following example illustrates the parameter organization:

[0057] [Communication]

[0058] CAN_ID_Physical = 0x7E0

[0059] UDS_Service_SID = 0x34

[0060] [FBL]

[0061] Block_Size = 0x800

[0062] Strategy_On_Failure = continue; Optional values: abort / continue

[0063] [ExpectedResponse]

[0064] Step_01_Positive = 0x74

[0065] Step_02_Negative = 0x22

[0066] The strategy parameter 'Strategy_On_Failure' controls the behavior after a test fails: if the value is 'abort', the current test case is aborted; if the value is 'continue', the failure is recorded and execution continues.

[0067] By using CANoe's natively supported .cin files as the external configuration carrier, it is naturally compatible with the Vector tool ecosystem, allowing key configuration items such as communication parameters (e.g., CAN ID, UDS SID), firmware block size, and process control strategies to be directly loaded and managed within the CANoe project. Compared to using custom text or Excel configurations, .cin files offer advantages such as structured format, type safety, and version control, effectively reducing the risk of configuration errors. Furthermore, by incorporating firmware block size and test process strategies (e.g., aborting or continuing after failure) into a unified configuration, the same CAPL script can dynamically adjust its execution logic based on different ECU performance or test objectives (e.g., R&D verification vs. production line final inspection). Switching between test granularity and fault tolerance strategies without code modification significantly enhances the adaptability and reusability of automated testing across multiple scenarios.

[0068] S2. Based on the communication established in S1, a multi-step test process is automatically executed to the target ECU via a CAPL script; the test process includes a firmware data download stage and a diagnostic request interaction stage; during the execution of the test process, the test process is controlled according to preset conditions.

[0069] The diagnostic requests sent during the diagnostic request interaction phase include requests to enter an extended session, secure access requests, and routine control requests. By structurally integrating the core diagnostic requests necessary for FBL flashing, a secure, standardized, and automatically executable test loop is constructed, significantly enhancing the depth, reliability, and engineering applicability of the tests.

[0070] In specific implementation, controlling the test process according to preset conditions includes: when a test step is determined to be a failure, according to the strategy parameters in the external configuration file, either suspending the current test case or recording the failure and continuing to execute subsequent test steps.

[0071] By defining failure handling strategies (abort or continue) through external configuration files, the same CAPL test script can be flexibly applied to different testing scenarios: for example, it can be strictly aborted during final inspection on the production line to ensure quality consistency, while allowing execution to continue during R&D verification to comprehensively collect fault information. This configurable strategy avoids the repeated development or modification of scripts for different scenarios, improving the reusability of test assets. Furthermore, in the "record failure and continue" mode, the system can execute all test steps completely, exposing multiple potential problems rather than just the first failure point. Compared to the traditional "stop upon encountering an error" approach, this mechanism significantly improves the information content of test results and the efficiency of problem localization, especially suitable for fault analysis in complex FBL processes with multiple coupled stages.

[0072] S3. Through the event handling mechanism of the CAPL script, adaptively parse and process the response messages returned by the target ECU during the execution of S2, including:

[0073] Identify and skip specific responses that indicate the request is pending in order to maintain the continuity of the testing process;

[0074] During the firmware data download phase, the flow control frame returned by the target ECU is identified, and the data block sending rhythm is dynamically adjusted according to the control parameters in the flow control frame to achieve synchronization with the ECU's transmission rate.

[0075] During the diagnostic request interaction phase, the response message returned by the target ECU indicating the result of a single test step is identified, and the actual response data carried in the response message is stored in a second global variable.

[0076] In specific implementation, the specific response indicating that the request is suspended is a response message that conforms to the UDS protocol and has a UDS service identifier equal to 0x78; the flow control frame is a response message that conforms to the UDS protocol and has a first byte of 0x30 or 0x32, and the control parameters it contains include block size and minimum interval time.

[0077] If the 0x78 response is not skipped, the test process will be blocked while waiting for the final response; if the flow control frame is not processed, high-speed writing will cause the ECU buffer to overflow. Therefore, response classification processing in S3 is a necessary technical means to achieve reliable FBL automation.

[0078] By explicitly using the "request suspension" response (service identifier 0x78) and flow control frames (first byte 0x30 or 0x32) defined in the UDS protocol as the parsing basis, the CAPL script can accurately distinguish between the ECU's temporary waiting state and valid control commands, avoiding misjudgments as communication failures or timeouts. Compared to processing methods relying on fixed delays or fuzzy matching, this approach is more in line with protocol specifications and significantly improves the robustness of testing in complex interaction scenarios. Furthermore, the block size and separation time contained in the flow control frame are core control parameters for UDS multi-frame transmission. The script dynamically adjusts the sending rhythm of subsequent data blocks based on these parameters, preventing ECU buffer overflow due to excessively fast transmission and avoiding impacting testing efficiency due to excessively slow transmission. This mechanism allows the testing system to adapt to the receiving capabilities of different ECUs without requiring manual preset of conservative parameters, improving the versatility and execution efficiency of automated flashing.

[0079] In practice, during the firmware data download phase, the transmission interval between adjacent data blocks is dynamically set based on the minimum interval time in the flow control frame. This ensures that the CAPL script strictly follows the ECU's current processing rhythm by parsing the minimum interval time (SeparationTime) in the flow control frame and dynamically setting the data block transmission interval accordingly. Compared to traditional methods using fixed or empirical delays, this mechanism effectively prevents ECU buffer overflow due to excessively fast transmission or diagnostic timeouts due to excessively long intervals, significantly improving the stability and success rate of the flashing process. Furthermore, different manufacturers or models of ECUs often have different flow control parameters, making it difficult to ensure compatibility with hard-coded transmission intervals. This solution automatically adjusts the transmission rhythm based on the minimum interval time fed back by the ECU in real time, allowing the same test script to adapt to multiple ECUs without modification, enhancing the versatility and deployment efficiency of FBL automated testing in heterogeneous environments.

[0080] To facilitate understanding of "how the event handling mechanism identifies 0x78, flow control frames, and result responses," the following CAPL event function example is provided:

[0081] on diagResponse

[0082] {

[0083] if (this.SID == 0x78) {

[0084] / / Skip, do not trigger timeout, wait for the next response

[0085] return;

[0086] }

[0087] else if (this.Data[0] == 0x30 || this.Data[0] == 0x32) {

[0088] / / Flow control frame: Extract Block Size (Data[1]) and STmin (Data[2])

[0089] g_BlockSize = this.Data[1];

[0090] g_STmin = parseSTmin(this.Data[2]); / / Explain the STmin encoding rules (e.g., 0x00–0x7F=ms, 0xF1–0xF9=100–900us)

[0091] setTimer(sendTimer, g_STmin);

[0092] }

[0093] else {

[0094] / / Normal diagnostic response, stored in the second global variable

[0095] copyRespToGlobal(this);

[0096] }

[0097] }

[0098] STmin parsing rules: The minimum interval time (STmin) is encoded according to the ISO 15765-2 standard: 0x00–0x7F represents 0–127 milliseconds; 0xF1–0xF9 represents 100–900 microseconds; other values ​​are reserved.

[0099] S4. Compare the expected response parameters in the first global variable in S1 with the actual response data in the second global variable in S3, and automatically determine whether the current test step passes or fails based on the comparison results.

[0100] In specific implementation, the comparison includes:

[0101] If the actual response is positive and its response code matches the expected response parameters, then it is considered passed;

[0102] If the actual response is a negative response with the UDS service identifier equal to 0x7F, and the error code it contains is consistent with the expected response parameters, then it is considered successful.

[0103] The response code for a positive response is equal to the request SID + 0x40, which is common knowledge in this field and will not be elaborated further here.

[0104] For ease of understanding, the following is an example of declaring global variables in CAPL during specific implementation:

[0105] / / First global variable: Expected response

[0106] message ExpectedResp {

[0107] byte respCode;

[0108] byte errorCode;

[0109] }

[0110] / / Second global variable: actual response

[0111] message ActualResp {

[0112] byte sid;

[0113] byte data[8];

[0114] }

[0115] In S1, after parsing the .cin file, the expected response code is written to ExpectedResp.respCode; in S3, when the ECU response is received, the actual SID and data are extracted in the on diagResponse event and stored in ActualResp; in S4, a comparison is performed using if (ActualResp.sid == ExpectedResp.respCode).

[0116] For ease of understanding, the relationship between "positive response code" and "UDS service identifier" is explained as follows.

[0117] "Response code" refers to "UDS service identifier for a positive response".

[0118] Positive response SID generation rules:

[0119] According to the UDS protocol, the service identifier for a positive response is equal to the request SID + 0x40. For example, if the request SID = 0x34 (request to download), then a positive response SID = 0x74 is expected.

[0120] Comparison logic explanation:

[0121] In S4, if the actual response SID is 0x74 and the expected response parameter Step_X_Positive=0x74, then it is considered to pass.

[0122] The relationship between the aforementioned "positive response code" and "UDS service identifier" is common knowledge in this field and will not be elaborated further here.

[0123] This solution not only verifies whether the positive response returned by the ECU meets expectations, but also explicitly considers negative responses (UDS 0x7F + specific error code) that meet expectations as "passes," thus covering legitimate exception scenarios such as security access denial and routine incompatibility. Compared to traditional methods that only judge successful responses, this mechanism is more in line with actual diagnostic logic and avoids misjudging compliant negative responses as test failures. In addition, by pre-setting specific error codes in the expected response parameters, testers can proactively verify whether the ECU's behavior under abnormal input or restricted conditions conforms to specifications (such as refusing to write when unlocked). This allows automated testing to not only verify "normal functionality" but also "correct error handling," significantly improving the coverage and quality assurance capabilities of FBL testing.

[0124] S5. After the test process is completed, a structured test report is automatically generated. The report includes test environment information, an overall overview of the test execution, and the execution results of each test step.

[0125] In specific implementation, the test environment information includes tool version, configuration file path, script execution path, and log file path; the overall test execution overview includes execution start time, total number of test cases, number of passed test cases, number of failed test cases, and pass rate; the execution results of each test step include step description, expected response, actual response, and judgment status.

[0126] By generating comprehensive and well-structured test reports, not only are the basic criteria for automated verification met, but a one-stop data foundation is also built for quality analysis, issue backtracking, and compliance auditing, effectively strengthening the quality assurance capabilities of the FBL test loop.

[0127] To better understand how structured test reports are generated, the following example illustrates the process.

[0128] In practice, the report generation code logic can be as follows:

[0129] void generateReport()

[0130] {

[0131] writeToFile("Tool Version: " + getCanoeVersion());

[0132] writeToFile("Config Path: " + g_ConfigPath);

[0133] writeToFile("Start Time: " + getCurrentTime());

[0134] writeToFile("Total Cases: " + g_TotalCases);

[0135] / / ... other fields

[0136] }

[0137] Field source explanation: Tool version is obtained through CANoe API; configuration file path is passed by S0; pass rate = number of passed test cases / total number of test cases.

[0138] In specific implementation, before executing S1, step S0 is also included: loading a graphical test execution interface built based on XML language, and receiving selection input for test cases through the interface to determine the test process to be executed.

[0139] To facilitate understanding, the following example illustrates the mapping relationship between the XML graphical interface and test cases.

[0140] Interface structure example:

[0141] The XML interface defines a tree structure of test cases, with each node containing [a specific element]. After the user selects a node, the system loads the corresponding .cin file path.

[0142] Startup process description:

[0143] "When the CANoe project starts, S0 is executed first: loading the XML interface; after the user selects a use case, the system passes the path of the selected .cin file to S1 as the basis for reading the configuration."

[0144] In this way, by introducing a lightweight, configurable graphical testing interface, the gap between automated scripts and actual operations is effectively bridged. While ensuring technical rigor, the ease of use, flexibility, and engineering implementation efficiency of FBL testing are greatly improved.

[0145] Compared with existing technologies, this technical solution achieves efficient, reliable and universal testing of the FBL (Flash Bootloader) flashing process by building structured, event-driven automated test logic in the CAPL script.

[0146] By reading the target ECU's communication parameters (such as CAN ID, baud rate, diagnostic session address, etc.) and expected response parameters from an external configuration file and loading them as global variables, this avoids hard-coding ECU-specific information into the script. Compared to traditional semi-automated scripts that require rewriting or modifying code for each ECU, this solution supports "develop once, reuse across multiple vehicle models," significantly reducing the cost of adapting to different ECU models or bootloader versions. Furthermore, leveraging CAPL's message reception event processing capabilities, it dynamically identifies various response types returned by the ECU: automatically skipping "RequestPending" responses and waiting for the final result to avoid process interruptions due to misjudgment; and parsing flow control frames in real time during the firmware download phase, dynamically adjusting the data block sending rhythm based on parameters such as block size and interval time to ensure synchronization with the ECU's transmission capabilities. Compared to traditional methods that rely on fixed delays or manual intervention, this mechanism significantly improves the stability and continuity of testing in complex communication environments.

[0147] This method stores the expected response parameters and the actual received ECU response in first and second global variables, respectively. After each test step, a consistency check is automatically performed to objectively and accurately determine whether the test passed or failed. This mechanism replaces manual verification of the response content, eliminating subjective judgment errors and providing a structured data foundation for subsequent automated report generation. Furthermore, from establishing communication and executing the multi-stage flashing process to result verification and report output, the entire testing process requires no manual intervention. After the test, a structured report containing test environment information, an execution overview, and the results of each step is automatically generated, facilitating problem backtracking and quality auditing. Compared to traditional methods relying on manual recording or scattered logs, this solution significantly improves the standardization of the testing process and the reliability of the results.

[0148] This invention utilizes an event-driven architecture and a dual global variable mechanism to achieve state awareness and adaptive control of the entire FBL process within the CAPL script, enabling fully automated FBL testing capabilities with "one-time development, multi-model reuse." This method can dynamically adapt to the communication characteristics of different ECUs, handle flow control and suspension states in real time, and accurately verify flashing results without manual intervention.

[0149] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit the technical solutions. Those skilled in the art should understand that any modifications or equivalent substitutions to the technical solutions of the present invention without departing from the spirit and scope of the present invention should be covered within the scope of the claims of the present invention.

Claims

1. An automated FBL testing method based on CAPL scripts, characterized in that, Includes the following steps: S1. Read the external configuration file to obtain the communication parameters and expected response parameters of the target ECU; establish diagnostic communication with the target ECU based on the communication parameters; the expected response parameters are set as the first global variable; S2. Based on the communication established in S1, a multi-step test process is automatically executed to the target ECU via a CAPL script; the test process includes a firmware data download stage and a diagnostic request interaction stage. During the execution of the test process, the test process is controlled according to preset conditions; S3. Through the event handling mechanism of the CAPL script, adaptively parse and process the response messages returned by the target ECU during the execution of S2, including: Identify and skip specific responses that indicate the request is pending in order to maintain the continuity of the testing process; During the firmware data download phase, the flow control frame returned by the target ECU is identified, and the data block sending rhythm is dynamically adjusted according to the control parameters in the flow control frame to achieve synchronization with the ECU's transmission rate. During the diagnostic request interaction phase, the response message returned by the target ECU indicating the result of a single test step is identified, and the actual response data carried in the response message is stored in a second global variable; S4. Compare the expected response parameters in the first global variable in S1 with the actual response data in the second global variable in S3, and automatically determine whether the current test step passes or fails based on the comparison results. S5. After the test process is completed, a structured test report is automatically generated. The report includes test environment information, an overall overview of the test execution, and the execution results of each test step.

2. The FBL automated testing method based on CAPL scripts according to claim 1, characterized in that: In S1, the external configuration file is a .cin file, which defines parameters including the communication parameters, firmware block size parameters, and strategy parameters used to control the execution strategy of the test process.

3. The FBL automated testing method based on CAPL script according to claim 2, characterized in that: In S2, controlling the test process according to preset conditions includes: when a test step is determined to be a failure, according to the strategy parameters in the external configuration file, either suspending the current test case or recording the failure and continuing to execute subsequent test steps.

4. The FBL automated testing method based on CAPL script according to claim 1, characterized in that: The diagnostic requests sent during the diagnostic request interaction phase include requests to enter an extended session, secure access requests, and routine control requests.

5. The FBL automated testing method based on CAPL script according to claim 1, characterized in that: In S1, the communication parameters include a physical addressing CAN identifier for sending a diagnostic request to the target ECU, and a UDS service identifier for constructing the diagnostic request.

6. The FBL automated testing method based on CAPL script according to claim 5, characterized in that: In S3, the specific response indicating that the request is suspended is a response message that conforms to the UDS protocol and whose UDS service identifier is equal to 0x78; the flow control frame is a response message that conforms to the UDS protocol and whose first byte is 0x30 or 0x32, and the control parameters it contains include block size and minimum interval time.

7. The FBL automated testing method based on CAPL script according to claim 6, characterized in that: In S3, during the firmware data download phase, the transmission interval between adjacent data blocks is dynamically set based on the minimum interval time in the flow control frame.

8. The FBL automated testing method based on CAPL script according to claim 6, characterized in that: The comparison described in S4 specifically includes: If the actual response is positive and its response code matches the expected response parameters, then it is considered passed; If the actual response is a negative response with the UDS service identifier equal to 0x7F, and the error code it contains is consistent with the expected response parameters, then it is considered successful.

9. The FBL automated testing method based on CAPL script according to claim 1, characterized in that: Before executing S1, step S0 is also included: loading a graphical test execution interface built on XML language, and receiving selection input for test cases through the interface to determine the test process to be executed.

10. The FBL automated testing method based on CAPL script according to claim 1, characterized in that: In S5, the test environment information includes the tool version, configuration file path, script execution path, and log file path; the overall test execution overview includes the execution start time, total number of test cases, number of passed test cases, number of failed test cases, and pass rate; the execution results of each test step include step description, expected response, actual response, and judgment status.

Images