A full function continuous testing system and method for a retarder

Abstract

The application relates to the field of retarder testing, in particular to a retarder full-function continuous testing system and method; a signal simulation module is used for constructing a digital sample vehicle model, simulating and providing various types of input signals to a retarder controller; a protocol test case management module is used for constructing a protocol test case library, and test cases in the protocol test case library are designed based on protocol parameter groups including all parameter combinations of the retarder; wherein the test cases adopt a modular structure, and the modular structure is composed of function blocks corresponding to different test functions; the test cases are associated with the function blocks according to preset matching logic to form test cases for testing different working states of the retarder. The application can satisfy all protocol parameter combinations, does not need to modify a script program, achieves the effect of multiplexing in all test cases, realizes a fully-automated process of test case generation, and improves test efficiency.

Description

Technical Field

[0001] This invention relates to the field of retarder testing, and more specifically to a system and method for continuous testing of the full functionality of a retarder. Background Technology

[0002] Currently, retarder controller software testing primarily employs hardware-in-the-loop (HIL) testing, requiring pre-configuration of the test environment, including building simulation models and configuring relevant software test files. To fully test the retarder's response under various operating conditions, multiple scenarios need to be simulated during testing, and the results observed. These operations are typically performed manually on a human-machine interface platform, resulting in low reusability. To accelerate testing and shorten the overall controller development cycle, testers utilize automated testing software for test case writing. Compared to HIL testing, this approach provides more accurate test data, particularly in fault reproduction, meeting testing requirements and allowing for test case reuse across multiple testing rounds.

[0003] The above testing methods can quickly complete testing when there is a single requirement parameter or the requirement parameter changes little. However, a large number of test cases still need to be manually written in the early stage of testing, and the testing process largely depends on the testing efficiency of the testers. Chinese Patent Publication No. CN103064403A discloses an automated testing method and system for ECU hardware-in-the-loop simulation. It discloses that the test requirement parameters are tabulated, and the table content is converted into test cases using scripts to conduct tests and obtain test reports. However, this solution still requires manual design and filling in of the test case table after converting the requirement parameters.

[0004] Chinese Patent Publication No. CN112526966A discloses an automated testing method and system for controller HIL (Hardware Instruction). It discloses that the process of tabulating manually designed requirement parameters is implemented through scripts, automatically generating test case tables and completing a fully automated process of test case design. However, as the test product is iterated and updated, the basic functional logic corresponding to the test program of different versions of the product is updated. It is not only the value of the requirement parameters that changes, but also the parameter combination. The script program in the proposed solution needs to be updated along with the basic functional logic, resulting in high maintenance costs. Summary of the Invention To address the problems mentioned in the prior art, this invention proposes a full-function continuous testing system and method for retarders. The test case library designed with protocol parameter groups covers the retarder program and can calibrate all parameters, satisfying all protocol parameter combinations without modifying the script program. The protocol test cases in this test case library are modularly designed, achieving the effect of reuse in all test cases and realizing a fully automated process of test case generation.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: This invention discloses a continuous full-function testing system for retarders, comprising: The signal simulation module is used to build a digital prototype vehicle model and simulate and provide various types of input signals to the retarder controller. The protocol test case management module is used to build a protocol test case library. The test cases in the protocol test case library are designed based on a protocol parameter group that includes all parameter combinations of the retarder. The test cases adopt a modular structure, which consists of functional blocks corresponding to different test functions. The test cases associate the parameters in the protocol parameter group with the functional blocks according to the preset matching logic to form test cases for testing different working states of the retarder.

[0006] As a further improvement of the present invention, the digital prototype model includes at least one of the following: a handle gear position source model, a foot control gear position source model, an ABS signal source model, a vehicle speed signal source model, an output shaft speed signal source model, and an external device prohibition signal source model.

[0007] As a further improvement of the present invention, the input signal includes a message signal, a hard-wired signal, a hard-wired pulse signal, and an encoded signal.

[0008] As a further improvement of the present invention, the functional block includes at least one of a test scenario block, a gear trigger block, a restricted entry block, a test point block, a gear judgment block, and a state reset block.

[0009] As a further improvement of the present invention, the test point block includes multiple sub-blocks corresponding to a single message signal.

[0010] As a further improvement of the present invention, the protocol test case library includes test cases for each gear, cruise test cases, and request negative torque test cases.

[0011] This invention proposes a method for continuous full-function testing of a retarder, comprising the retarder continuous full-function testing system as described above, and including the following steps: S1. Obtain the integrated program of the retarder controller to be tested, at least one set of protocol parameters, and a protocol test case library; S2. In response to the test trigger command, parse the protocol parameter group to be used; S3. Based on the parsed protocol parameter group, select the corresponding functional block from the protocol test case library according to the preset matching logic and dynamically assemble it into the current test case to form a test project; Write the integration program and current protocol parameter set to the retarder controller; run the test program to test the retarder controller.

[0012] As a further improvement of the present invention, for each of at least one set of protocol parameter groups, the process of S3 is executed cyclically.

[0013] As a further improvement of the present invention, S4 is included after S3, including: Generate a test report; evaluate the test results based on the pass rate of the test report. If the pass rate is 100%, it is considered a pass; otherwise, further evaluation is conducted to determine whether it is a concession pass or a failure.

[0014] As a further improvement of the present invention, before performing S1, the test task is registered on the task management platform and the test number is obtained; the test triggering instruction in S2 is generated based on the test number and related test parameters.

[0015] Compared with the prior art, the present invention achieves the following technical effects: The system of this invention uses a test case library designed with protocol parameter groups to cover the retarder program. All parameters can be calibrated, satisfying all combinations of protocol parameters without modifying the script program. The protocol test cases in this test case library are modularly designed, achieving the effect of reuse in all test cases. This realizes a fully automated process of test case generation, greatly reducing manual operations between the release of the controller program and the execution of test cases, and improving testing efficiency. The method of this invention is based on the above-mentioned system. It schedules all the software and hardware platforms required for testing in a unified manner through an automated pipeline task, realizing automated execution from the release of the retarder controller program to the return of the report. No operation by test personnel is required throughout the process. It can continuously refresh the protocol parameter group in a loop, fully test the full functionality of the retarder product controller program, expand the testing coverage, improve the ability to detect program faults, effectively shorten the entire product program development cycle, and provide assistance for the product to be applied to the market. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the functional blocks of the present invention; Figure 2 This is a schematic diagram of the method flow of the present invention. Detailed Implementation

[0017] In the following description, only certain exemplary embodiments are briefly described. As those skilled in the art will recognize, the described embodiments can be modified in various ways without departing from the spirit or scope of the invention. Therefore, the drawings and description are considered to be exemplary in nature and not restrictive.

[0018] In the description of this invention, it should be understood that the terms "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," "outer," "clockwise," "counterclockwise," "axial," "radial," and "circumferential" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.

[0019] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0020] In this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," "linking," and "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection, an electrical connection, or a communication connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0021] In this invention, unless otherwise explicitly specified and limited, "above" or "below" the second feature can include direct contact between the first and second features, or contact between the first and second features through another feature between them. Furthermore, "above," "over," and "on top" of the second feature includes the first feature being directly above or diagonally above the second feature, or simply indicates that the first feature is at a higher horizontal level than the second feature. "Below," "below," and "under" the second feature includes the first feature being directly above or diagonally above the second feature, or simply indicates that the first feature is at a lower horizontal level than the second feature.

[0022] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0023] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0024] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0025] The accompanying drawings illustrate various structural schematic diagrams according to embodiments disclosed in this invention. These drawings are not to scale, and some details have been enlarged for clarity, and some details may have been omitted. The shapes of the various regions and layers shown in the drawings, as well as their relative sizes and positional relationships, are merely exemplary and may deviate from reality due to manufacturing tolerances or technical limitations. Furthermore, those skilled in the art can design regions / layers with different shapes, sizes, and relative positions as needed.

[0026] See Figure 1 This embodiment proposes a full-function continuous testing system for retarders, including: The signal simulation module is used to build a digital prototype vehicle model and simulate and provide various types of input signals to the retarder controller. The protocol test case management module is used to build a protocol test case library. The test cases in the protocol test case library are designed based on a protocol parameter group that includes all parameter combinations of the retarder. The test cases adopt a modular structure, which consists of functional blocks corresponding to different test functions. The test cases associate the parameters in the protocol parameter group with the functional blocks according to the preset matching logic to form test cases for testing different working states of the retarder.

[0027] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0028] It should be noted that the protocol in the protocol parameter group in this embodiment is the communication and data rules agreed upon between the retarder controller and other systems of the vehicle or the test system; while the protocol parameter group is a set of parameters that can cover all calibrable parameters of the retarder controller.

[0029] Secondly, this embodiment modularizes the test logic, breaking down complex test scenarios into functional blocks with independent functions. Each functional block encapsulates specific test actions or judgment logic, but the specific parameter values ​​or triggering conditions for its execution are not fixed.

[0030] Finally, by introducing matching logic, the protocol parameter groups are dynamically associated with the functional blocks. When testing a specific protocol parameter group, the matching logic will decide based on the specific values ​​of the parameters in that group: under the current test objective, which functional blocks need to be enabled, and the parameters for the execution of the functional blocks should be set, etc. Through this dynamic association and assembly, the system can generate corresponding test cases in real time for each different set of protocol parameters.

[0031] Based on the system in this embodiment, when the retarder product is upgraded or the parameter combination changes, testers do not need to worry about the test script code; they only need to update the protocol parameter group. The system will automatically re-associate existing functional blocks according to the new protocol parameter group through matching logic to form new test cases. This achieves complete automation and reuse of test case design, fundamentally solving the problem of test scripts needing to be maintained synchronously with product iterations.

[0032] The system in this embodiment mainly includes a signal simulation module and a protocol test case management module. The signal simulation module constructs a high-fidelity digital prototype vehicle model to replace the real vehicle environment and provides all the necessary input signals for the retarder controller under test.

[0033] In this embodiment, the digital prototype vehicle model is a collection of multiple signal source sub-models. These sub-models simulate all signal sources on the vehicle that interact with the retarder controller, and mainly include: The lever shift source model is used to simulate the driver's operation of requesting the brake shift through the retarder lever, which typically generates coded signals or specific messages.

[0034] The foot-controlled gear shifting source model is used to simulate the signal that requests the retarder to operate via the brake pedal, and may be linked to the ABS system.

[0035] The ABS signal source model is used to simulate the working status signals of the anti-lock braking system, and is used to prohibit or intervene in the operation of the retarder under specific conditions.

[0036] The vehicle speed signal source model simulates the vehicle speed sensor signal, which is one of the key inputs for the retarder to determine intervention conditions and operating modes. This signal is usually represented in the form of pulse frequency or specific messages.

[0037] The output shaft speed signal source model is used to simulate the speed signal of the transmission output shaft. It should be noted that in actual vehicles, there is a definite transmission ratio relationship between vehicle speed and output shaft speed. Therefore, in the digital prototype model, the two have a fixed protocol parameter matching relationship. The system automatically calculates the corresponding output shaft speed value based on the vehicle speed value set in the current test scenario, combined with protocol parameters such as transmission ratio, thereby ensuring the logical consistency of the two key signals.

[0038] The external device prohibition signal source model is used to simulate other vehicle signals that may require the retarder to stop working, such as air conditioning high load requests, generator fault signals, etc.

[0039] The signals in this embodiment are generated by the aforementioned sub-models and cover all the main signals that the retarder controller would receive in a real vehicle, including: Message signals: Digital signals based on vehicle network protocols such as CAN and LIN, used to transmit complex information, such as vehicle speed, gear requests, system status, etc.

[0040] Hard-wired signals: Direct voltage or level signals used to indicate switch states.

[0041] Hard-wire pulse signal: A pulse signal with varying frequency or duty cycle, often used to simulate the output of a speed sensor.

[0042] Encoded signal: A signal with specific encoding rules, such as certain lever gear signals.

[0043] The signal simulation module continuously generates dynamically changing signal streams that conform to the protocol specifications by running these digital prototype vehicle models in real time, and applies them to the corresponding communication interface of the retarder controller, thereby creating a near-realistic operating environment for the retarder controller.

[0044] In this embodiment, the protocol test case management module is responsible for storing, managing, and dynamically generating test logic.

[0045] The protocol test case management module is used to build a protocol test case library. Each test case in the protocol test case library is a logical framework designed to test the working state represented by a certain type of function or a specific combination of parameters.

[0046] The protocol test case library contains different categories of test cases, such as test cases for each gear (verifying torque response under each braking gear), cruise test cases (verifying the control capability of the retarder under constant speed), and request negative torque test cases (verifying the ability to work in coordination with the vehicle drive system).

[0047] like Figure 1 As shown, each protocol test case consists of multiple reusable functional blocks, which are constructed based on the general logic of the test project, including: The test scenario block is responsible for configuring the basic state of the digital prototype vehicle model, such as setting the initial vehicle speed, road gradient, vehicle load, and other vehicle and road scenario data.

[0048] The gear trigger block is used to send a specific gear request signal to the retarder controller according to test requirements, such as simulating a driver pushing the lever to a certain braking gear.

[0049] The limit entry block is used to simulate the activation and deactivation of external limiting conditions during testing, such as suddenly simulating the activation of the ABS signal during the operation of the retarder, to verify whether the controller can respond correctly and disengage the brakes.

[0050] Test point blocks are used to check the control commands or status messages issued by the controller at specific times to determine whether they meet expectations. In this embodiment, to improve reusability, a test point block can be further divided into multiple sub-blocks based on a single message signal, with each sub-block specifically monitoring a particular signal. After initialization, the sub-blocks can be repeatedly called in different use cases.

[0051] The gear position determination block is used to determine whether the actual braking gear calculated or fed back by the controller matches the expected gear during or at the end of the test.

[0052] The state reset block is used to restore all signals to their initial state at the end of a test case or after a test cycle, ensuring that the next test case can begin.

[0053] In the embodiment, the matching logic built into the protocol test case management module establishes a mapping relationship between protocol parameter groups and function blocks, associating the parameters in the protocol parameter group with specific test targets. For example, when the maximum braking torque limit in the protocol parameters is set to a certain value, it is necessary to test the working state of the retarder under that torque limit.

[0054] Once the system loads a set of protocol parameters, the matching logic begins to work. By parsing the parameters, it determines which functions need to be verified in this test (such as constant speed control, hill braking, etc.) based on the mapping relationship. Then, it selects the required combination of function blocks for each function (for example, testing braking with ABS limitation requires the function blocks of test scenario block, gear trigger block, limit entry block, test point block, and state reset block).

[0055] In addition, the matching logic dynamically assigns specific values ​​from the protocol parameters to the function blocks, such as assigning the vehicle speed threshold in the current parameter group to the test scenario block as the initial vehicle speed; finally, it outputs a complete test sequence consisting of function blocks arranged in the correct timing order and with parameters initialized.

[0056] The development tool for protocol test cases in this embodiment is a testing tool based on the ECU-TEST platform, including Global-constant and user-defined functions. Global-constant directly calls the triggering conditions and the parts associated with test points and parameters from the API. Global-constant is a GCD file independent of the test cases; only the first GCD file is valid in the test case project environment, and it is stored in a fixed path. User-defined functions combine parameters from the TPT and select corresponding parameters based on the current test environment and constraints, using them in various loops. This embodiment proposes a method for continuous testing of the full functionality of a retarder, the specific steps of which are as follows: First, after the developers complete the software integration, they upload the generated retarder controller integration program and its corresponding protocol parameter group file to the cloud server.

[0057] Testers create and register a test task for the software version to be tested on the task management platform. The platform generates a unique test number for the task and associates it with the program and parameter group stored in the cloud.

[0058] On the automated scheduling platform, operators select the automated test pipeline task corresponding to the current product; on the task configuration interface, they fill in the necessary parameters and the test number obtained from the task management platform, as well as information such as the test product model.

[0059] Select the steps you want to perform, confirm, and click "Execute." This action will trigger the automated test pipeline script.

[0060] like Figure 2 As shown, the pipeline executes the following sub-steps in sequence: Step 1: The pipeline script locates the corresponding storage location on the cloud server based on the test number passed in at the time of triggering. Then, it downloads the three core files required for the test to the local industrial control computer or server where the test will be executed. The three core files are the protocol test case library, the retarder product integration program, and the retarder protocol parameter group.

[0061] Step 2: First, read the first group of protocol parameters in order from the drop-down protocol parameter group file and convert it from the flash format into a readable text file; then, use the preset parsing script to extract the key related parameters from the readable text.

[0062] Step 3: Use the parsed parameters to calibrate the digital prototype model. Using the readable text file generated from the parsing, generate a GCD file readable by the test platform API. Based on the matching logic of the current protocol parameters and predefined protocol test cases, the system automatically selects the functional blocks corresponding to the functions to be tested from the locally retrieved protocol test case library.

[0063] Finally, the selected function blocks whose parameters have been assigned by the GCD file are automatically assembled into a complete test project according to the test logic order.

[0064] Step 4: After the test environment is ready, the controller under test needs to be placed in the same software state. The pipeline calls the controller flashing service tool to flash the integrated program file corresponding to this cycle and the set of protocol parameter files currently being processed into the retarder controller.

[0065] Step 5: After the controller flashing is complete, the pipeline will start the test platform and run the built test case project. The test platform will control the automatic control signal simulation module to stimulate the controller and collect the controller's response through test point blocks, compare it with the expected value, and execute all test cases in batches without manual monitoring.

[0066] Step Six: After the test run is completed, the test platform will automatically generate a test report. The test report records the execution result (pass / fail) of each test case, the specific reason for the failure, key signal waveforms during the test, and other information. The test report will be automatically uploaded back to the cloud server or the designated report management system and stored in association with this test task.

[0067] Performing the above steps constitutes a complete test of a set of protocol parameters, while a product's protocol parameter set typically contains multiple sets of parameters. Therefore, to achieve full-function testing, this embodiment is configured such that after testing a set of parameters, the system automatically determines whether there is another set of parameters in the parameter set file; if so, the process jumps back to step two to parse the next set of parameters, and so on, until all protocol parameter sets have been tested.

[0068] Step 7: After all parameter groups have been tested in a loop, proceed to the evaluation phase; The system checks all generated test reports. If the test pass rate is 100%, the system automatically determines that the task has passed the test.

[0069] If there are failed test cases (the pass rate is not 100%), further analysis is required. A preliminary judgment can be made based on preset rules. For example, if there are only minor deviations in a few non-critical functional points, the test cases can be automatically or manually judged as allowing for concessions.

[0070] If a major functional failure or key performance indicator (KPI) is found, the system is deemed unqualified. When an evaluation is deemed unqualified, the system design can trigger an alert and initiate a new round of testing automatically or manually. The foregoing has shown and described the basic principles, main features, and advantages of the present invention. It will be apparent to those skilled in the art that the invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered illustrative and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the scope of the invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

[0071] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can be appropriately combined to form other embodiments that can be understood by those skilled in the art. The above content is only for illustrating the technical concept of the present invention and should not be construed as limiting the scope of protection of the present invention. Any modifications made based on the technical concept proposed in this invention shall fall within the scope of protection of the claims of this invention.

Claims

1. A retarder full-function continuous testing system, characterized in that, include: The signal simulation module is used to build a digital prototype vehicle model and simulate and provide various types of input signals to the retarder controller. The protocol test case management module is used to build a protocol test case library. The test cases in the protocol test case library are designed based on a protocol parameter group that includes all parameter combinations of the retarder. The test cases adopt a modular structure, which consists of functional blocks corresponding to different test functions. The test cases associate the parameters in the protocol parameter group with the functional blocks according to the preset matching logic to form test cases for testing different working states of the retarder.

2. The retarder full-function continuous testing system according to claim 1, characterized in that, The digital prototype model includes at least one of the following: a handle gear position source model, a foot control gear position source model, an ABS signal source model, a vehicle speed signal source model, an output shaft speed signal source model, and an external device prohibition signal source model.

3. The retarder full-function continuous testing system according to claim 1, characterized in that, The input signals include message signals, hard-wire signals, hard-wire pulse signals, and encoded signals.

4. The retarder full-function continuous testing system according to claim 1, characterized in that, The functional block includes at least one of the following: test scenario block, gear trigger block, restricted entry block, test point block, gear judgment block, and status reset block.

5. The retarder full-function continuous testing system according to claim 4, characterized in that, The test point block includes multiple sub-blocks corresponding to a single message signal.

6. The retarder full-function continuous testing system according to claim 1, characterized in that, The protocol test case library includes test cases for each gear, cruise test cases, and request negative torque test cases.

7. A method for continuous full-function testing of a retarder, characterized in that, The retarder full-function continuous testing system as described in any one of claims 1 to 6 includes the following steps: S1. Obtain the integrated program of the retarder controller to be tested, at least one set of protocol parameters, and a protocol test case library; S2. In response to the test trigger command, parse the protocol parameter group to be used; S3. Based on the parsed protocol parameter group, select the corresponding functional block from the protocol test case library according to the preset matching logic and dynamically assemble it into the current test case to form a test project; Write the integration program and current protocol parameter set to the retarder controller; run the test program to test the retarder controller.

8. The method for continuous full-function testing of a retarder according to claim 7, characterized in that, For each of at least one set of protocol parameters, the process of S3 is executed cyclically.

9. The method for continuous full-function testing of a retarder according to claim 7, characterized in that, S4 follows S3, including: Generate a test report; evaluate the test results based on the pass rate of the test report. If the pass rate is 100%, it is considered a pass; otherwise, further evaluation is conducted to determine whether it is a concession pass or a failure.

10. The method for continuous full-function testing of a retarder according to claim 7, characterized in that, Before S1, the test task is registered on the task management platform and the test number is obtained; the test trigger instruction in S2 is generated based on the test number and related test parameters.

Images