A brake system functional safety test method, device, equipment and medium

Abstract

The application discloses a brake system function safety test method, device, equipment and medium, and relates to the technical field of function safety test.The method comprises the following steps: converting each requirement in a TSR file into a standard function safety case semantic format, breaking the sentence, obtaining a specific fault description, matching the specific fault description with a fault variable corresponding to a test program, converting the requirement into a plurality of function safety test cases; matching the fault description with a diagnosis specification to generate an expected fault code, and determining whether the fault code performance of the measured controller conforms to the expectation; obtaining a specific execution description, matching the specific execution description with an expected value of the test program, and determining whether the function and performance performance of the measured controller conforms to the expectation; executing all function safety test cases of the requirement, and calculating and evaluating the requirement.The application can make the function safety test scene coverage wider and the test execution efficiency higher.

Description

Technical Field

[0001] This invention relates to the technical field of functional safety testing, and in particular to a method, apparatus, equipment, and medium for functional safety testing of braking systems. Background Technology

[0002] With the development of electronic braking control systems, more and more vehicles are using EPB (Electronic Parking Brake), IBC (Integrated Brake Control), and RBU (Redundant Brake Unit). As a result, the functions of braking systems are becoming more and more complex, thus requiring functional safety testing of the brake controller.

[0003] In related technologies, the current method for functional safety testing of brake controllers is to write functional safety test cases based on the TSR (Technical Safety Requirements) document and the technical experience of the testers.

[0004] However, existing testing methods have low coverage of functional safety testing scenarios, making it difficult to comprehensively and systematically test various functional safety scenarios of complex braking systems. This may result in the omission of some important test situations, thus affecting the comprehensiveness and effectiveness of the tests. Summary of the Invention

[0005] This invention aims to address at least one of the technical problems existing in the prior art. To this end, this invention proposes a method, apparatus, equipment, and medium for functional safety testing of braking systems. It can automatically create typical fault types and fault scenarios from TSR files through a series of transformation and decomposition steps, realizing the entire automated conversion process from TSR files to functional safety test cases. This results in broader coverage of functional safety test scenarios, higher test execution efficiency, and comprehensive and systematic testing of various functional safety scenarios in complex braking systems, avoiding the omission of important test conditions and ensuring the comprehensiveness and effectiveness of the tests.

[0006] The present invention also proposes a functional safety testing device for braking systems.

[0007] The present invention also proposes an electronic device.

[0008] The present invention also proposes a computer-readable storage medium.

[0009] A method for testing the functional safety of a braking system according to a first aspect of the present invention includes the following steps:

[0010] Each requirement in the TSR file is converted into a standard functional safety use case semantic format. The standard functional safety use case is then segmented into sentences, and the segmented standard functional safety use case includes fault occurrence, fault description, and handling method.

[0011] Based on the occurrence of the fault, a specific fault description is obtained, and the specific fault description is matched with the corresponding fault variables in the test program. Based on the security level of the requirement, the requirement is transformed into several functional safety test cases.

[0012] The fault description is matched with the diagnostic specifications to generate the expected fault code, and it is determined whether the fault code performance of the controller under test meets the expectations.

[0013] Based on the processing method, a specific execution description is obtained, and the specific execution description is matched with the expected value of the test program to determine whether the function and performance of the controller under test meet the expectations.

[0014] Perform all the functional safety test cases of the requirements, calculate and evaluate the compliance rate of the fault codes and the functions and performance of all the functional safety test cases of the requirements.

[0015] According to some embodiments of the present invention, obtaining a specific fault description based on the occurrence of the fault and matching the specific fault description with the corresponding fault variables in the test program includes the following steps:

[0016] The occurrence of the fault is decomposed layer by layer according to the fault-causing system, the trend of fault parameter changes, and the specific fault description.

[0017] The specific fault description is matched with the corresponding fault variables in the test program to complete the fault injection.

[0018] According to some embodiments of the present invention, the step of converting the requirement into several functional safety test cases based on the security level of the requirement includes the following steps:

[0019] Based on the security level required, the range of values ​​for the fault variables is set;

[0020] Based on the range of values ​​for the fault variables, the requirements are transformed into several functional safety test cases.

[0021] According to some embodiments of the present invention, the step of matching the fault description with diagnostic specifications to generate expected fault codes and determining whether the fault code performance of the controller under test meets expectations includes the following steps:

[0022] Input the fault description into the diagnostic specification and filter out the expected fault codes corresponding to the fault description;

[0023] Read the actual fault code issued by the controller under test for the corresponding fault;

[0024] The expected fault code is compared with the actual fault code. If they match, the fault code is determined to be performing as expected. If they do not match, the fault code is determined to be performing as expected.

[0025] According to some embodiments of the present invention, obtaining the specific execution description based on the processing method includes the following steps:

[0026] The processing method is decomposed layer by layer according to security functions, execution units, and specific execution descriptions to obtain the specific execution descriptions.

[0027] According to some embodiments of the present invention, the step of matching the specific execution description with the expected value of the test program to determine whether the function and performance of the controller under test meet the expectations includes the following steps:

[0028] Based on the specific execution description, find the corresponding working state and running performance variables in the test program, and set the expected values ​​of the corresponding working state and running performance variables.

[0029] Read the actual values ​​of the variables corresponding to the working status and operating performance issued by the controller under test;

[0030] The actual values ​​of the variables corresponding to the working status and running performance are compared with the expected values. If the comparison results show that the actual value of the working status is consistent with the expected value and the actual value of the running performance is greater than the expected value, then the function and performance are determined to meet the expectations. If the comparison results show that the actual value of the working status is inconsistent with the expected value or the actual value of the running performance is less than the expected value, then the function and performance are not in line with the expectations.

[0031] According to some embodiments of the present invention, the process of testing all functional safety test cases for executing the requirement, calculating and evaluating the compliance rate of the fault codes and functional and performance performance of all functional safety test cases for the requirement, includes the following steps:

[0032] Execute all the functional safety test cases of the requirements and obtain the fault code manifestation and the functional and performance performance of each functional safety test case;

[0033] Calculate the ratio of the number of functional safety test cases in the requirement that meet the expected performance of the fault codes to the total number of functional safety test cases included in the requirement;

[0034] Calculate the ratio of the number of functional safety test cases in the requirement that meet the expected performance of the function to the total number of functional safety test cases included in the requirement;

[0035] Based on the security level of the requirement, the activation success rate of the security mechanism for the requirement is defined. If both ratios are not less than the activation success rate of the security mechanism, the functional security test of the requirement is evaluated as qualified. If at least one of the two ratios is less than the activation success rate of the security mechanism, the functional security test of the requirement is evaluated as unqualified.

[0036] A braking system functional safety testing apparatus according to a second aspect of the present invention includes:

[0037] The fault injection module is used to convert each requirement in the TSR file into a standard functional safety test case semantic format, segment the standard functional safety test case into sentences, and the segmented standard functional safety test case includes fault occurrence, fault description and handling method. Based on the fault occurrence, a specific fault description is obtained, the specific fault description is matched with the test program, and based on the safety level of the requirement, the requirement is converted into several functional safety test cases.

[0038] The fault code reading and evaluation module is used to match the fault description with the diagnostic specifications to generate the expected fault code and determine whether the fault code performance of the controller under test meets expectations.

[0039] The functional and performance evaluation module is used to obtain a specific execution description based on the processing method, match the specific execution description with the expected value of the test program, and determine whether the functional and performance performance of the controller under test meets the expectations.

[0040] The requirement test evaluation module is used to execute all the functional safety test cases of the requirement, calculate and evaluate the compliance rate of the fault codes and the functional and performance performance of all the functional safety test cases of the requirement.

[0041] An electronic device according to a third aspect of the present invention includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement a braking system functional safety testing method according to a first aspect of the present invention.

[0042] According to a fourth aspect of the present invention, a computer-readable storage medium stores a computer program that, when executed by a processor, implements a braking system functional safety testing method according to a first aspect of the present invention.

[0043] The embodiments of this invention include at least the following beneficial effects: This invention provides a method, apparatus, equipment, and medium for functional safety testing of braking systems. Based on functional safety concepts, diagnostic specifications, and TSR files, it transforms each requirement in the TSR file into standardized, structured functional safety test cases by performing standard functional safety test case semantic conversion and automated sentence segmentation, thereby improving the consistency and repeatability of testing. By matching specific fault descriptions with corresponding fault variables in the test program, it achieves precise fault injection, enhancing the targeting of testing. By transforming each requirement into several functional safety test cases based on safety levels, it ensures that the testing intensity of each requirement matches the safety level of that requirement. By matching fault descriptions with diagnostic specifications to generate expected fault codes and testing the fault code performance of the controller under test, the accuracy and reliability of fault detection are ensured. By obtaining specific execution descriptions based on processing methods and matching them with expected values ​​in the test program, the functionality and performance are tested, and the controller's responsiveness is comprehensively evaluated, improving the comprehensiveness of the test. By calculating the compliance rate of fault code performance and functional and performance performance of all functional safety test cases for each requirement, quantitative test indicators are provided. This embodiment forms an automated conversion process from TSR files to functional safety test cases through the above series of operations, significantly improving test scenario coverage, reducing the risk of omissions, and improving the efficiency of functional safety test execution.

[0044] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0045] To more clearly illustrate the technical solutions of the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0046] Figure 1 This is a flowchart of a braking system functional safety testing method according to an embodiment of the present invention;

[0047] Figure 2 for Figure 1 The first flowchart of step S100 is shown;

[0048] Figure 3 for Figure 1 The diagram shown illustrates the semantic transformation and sentence segmentation of the TSR file in step S100.

[0049] Figure 4 for Figure 1 The second flowchart of step S100 is shown;

[0050] Figure 5 for Figure 1 The first flowchart of step S200 is shown;

[0051] Figure 6 for Figure 5 The diagram shown illustrates the fault decomposition in step S210.

[0052] Figure 7 for Figure 1 The second flowchart of step S200 is shown;

[0053] Figure 8 for Figure 1 The flowchart of step S300 is shown;

[0054] Figure 9 for Figure 1 The first flowchart of step S400 is shown;

[0055] Figure 10 for Figure 9 The diagram shown illustrates the decomposition of the processing method in step S410;

[0056] Figure 11 for Figure 1 The second flowchart of step S400 is shown;

[0057] Figure 12 for Figure 1 The flowchart for step S500 is shown. Detailed Implementation

[0058] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0059] In the description of this invention, it should be understood that the orientation descriptions, such as up, down, front, back, left, right, etc., indicating the orientation or positional relationship, are based on the orientation or positional relationship shown in the accompanying drawings, and are only for the convenience of describing this invention and simplifying the description, and are not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this invention.

[0060] In the description of this invention, "several" means one or more, "more than" means two or more, "greater than," "less than," and "exceeding" are understood to exclude the stated number, while "above," "below," and "within" are understood to include the stated number. If "first" and "second" are mentioned, this is only for the purpose of distinguishing technical features and should not be construed as indicating or implying relative importance, or implicitly indicating the number of indicated technical features, or implicitly indicating the order of the indicated technical features.

[0061] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation, connection, and linkage" should be interpreted broadly. For example, they can refer to fixed connections, detachable connections, or integral connections; they can refer to mechanical connections or electrical connections; they can refer to direct connections or indirect connections through an intermediate medium; and they can refer to the internal communication between two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0062] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent is obtained first. Furthermore, the collection, use, and processing of this data comply with relevant laws, regulations, and standards of the relevant countries and regions. In addition, when embodiments of this application require access to sensitive personal information of users, separate permission or consent from the user is obtained through pop-ups or redirects to confirmation pages. Only after obtaining the user's separate permission or consent is the necessary user-related data for the proper functioning of the embodiments of this application obtained.

[0063] The following description, in conjunction with the accompanying drawings, describes a method, apparatus, device, and medium for testing the functional safety of a braking system according to an embodiment of the present invention.

[0064] In related technologies, functional safety testing of brake controllers is required. Currently, the method for functional safety testing of brake controllers is to write functional safety test cases based on the technical safety requirements (TSR) document and the technical experience of the testers. However, the existing testing method has low coverage of functional safety test scenarios, making it difficult to comprehensively and systematically test various functional safety scenarios of complex braking systems. It may miss some important test situations, thus affecting the comprehensiveness and effectiveness of the test.

[0065] Reference Figure 1 The braking system functional safety test method provided in this embodiment of the invention may include, but is not limited to, steps S100 to S500.

[0066] Step S100: Convert each requirement in the TSR file into a standard functional safety use case semantic format, and break the standard functional safety use case into sentences. The broken standard functional safety use case includes the occurrence of the fault, the fault description, and the handling method.

[0067] Step S200: Obtain a specific fault description based on the occurrence of the fault, match the specific fault description with the corresponding fault variables in the test program, and transform the requirements into several functional safety test cases based on the safety level of the requirements.

[0068] Step S300: Match the fault description with the diagnostic specifications to generate the expected fault code, and determine whether the fault code performance of the controller under test meets expectations.

[0069] Step S400: Obtain the specific execution description based on the processing method, match the specific execution description with the expected value of the test program, and determine whether the function and performance of the controller under test meet the expectations.

[0070] Step S500: Execute all functional safety test cases of the requirements, calculate and evaluate the fault code performance and the compliance rate of the functional and performance performance of all functional safety test cases of the requirements.

[0071] It is understood that steps S100 to S500 of the embodiments of the present invention, based on functional safety concepts, diagnostic specifications, and TSR files, transform each requirement in the TSR file into standardized, structured functional safety test cases by performing standard functional safety test case semantic conversion and automated sentence segmentation. This improves the consistency and repeatability of testing. By matching specific fault descriptions with corresponding fault variables in the test program, precise fault injection is achieved, enhancing the targeting of testing. By transforming each requirement into several functional safety test cases based on safety levels, the testing intensity of each requirement is matched with its safety level. The system generates expected fault codes by matching fault codes to specifications and tests the fault code behavior of the controller under test, ensuring the accuracy and reliability of fault detection. By obtaining specific execution descriptions based on processing methods and matching them with expected values ​​in the test program, the system tests functional and performance performance, comprehensively evaluating the controller's responsiveness and improving the comprehensiveness of the test. The system evaluates the performance by calculating the compliance rate of fault codes and functional and performance performance of all functional safety test cases for each requirement, providing quantitative test indicators. Through the above series of operations, this embodiment forms an automated conversion process from TSR files to functional safety test cases, significantly improving test scenario coverage, reducing the risk of omissions, and improving the efficiency of functional safety test execution.

[0072] Reference Figure 2In some embodiments, step S100 involves converting each requirement in the TSR file into a standard functional safety use case semantic format, which may include, but is not limited to, step S110.

[0073] Step S110: Convert each requirement in the TSR file into the standard functional safety use case semantic format.

[0074] Reference Figure 3 Specifically, the standard functional safety use case semantic format can be, but is not limited to, set as "When a fault occurs, after a continuous FDTI (Fault Detection Time Interval), the tested electronic control system reports a fault, and after waiting for the FRTI (Fault Reaction Time Interval), ... performs ... operation to ensure safety." Specific conversion rules may include, but are not limited to, the following: when expressions such as "fault," "failure," or "degradation" are detected in the TSR file requirements, the entire sentence is converted to "when a...fault occurs"; when expressions such as "report fault" or "fault code" are detected in the TSR file requirements, the entire sentence is converted to "the tested electronic control system reports a...fault"; when expressions such as "enable," "disable," "activate," "cut off," "boost," "depressurize," "clamp," or "release" are detected in the TSR file requirements, the entire sentence is converted to "...perform...operation to ensure safety"; if the TSR file contains a single set of characteristics FDTI and FRTI, the FDTI value (e.g., 100ms) and the FRTI value (e.g., 400ms) are extracted and written into the "after continuous FDTI" and "after continuous FRTI" statements, respectively; if there is no single set of characteristics FDTI and FRTI, the time interval between "when a...fault occurs" and "the tested electronic control system reports a...fault" is the FDTI, and the time interval between "the tested electronic control system reports a...fault" and "...perform...operation to ensure safety" is the FRTI.

[0075] Reference Figure 4 In step S100 of some embodiments, the standard functional safety use case is segmented. The segmented standard functional safety use case includes fault occurrence, fault description, and handling method, and may include, but is not limited to, step S120.

[0076] Step S120: Segment the standard functional safety use case. The segmented standard functional safety use case includes fault occurrence, fault detection time interval, fault description, fault handling time interval, and handling method.

[0077] Refer again Figure 3Specifically, the statement corresponding to the fault occurrence is "when a... fault occurs", the statement corresponding to the fault detection time interval is "after continuous FDTI", the statement corresponding to the fault description is "the tested electrical control system reports a... fault", the statement corresponding to the fault handling time interval is "after continuous FRTI", and the statement corresponding to the handling method is "...take... operation to ensure safety".

[0078] Reference Figure 5 In some embodiments, step S200 involves obtaining a specific fault description based on the occurrence of the fault and matching the specific fault description with the corresponding fault variables in the test program. This may include, but is not limited to, steps S210 to S220.

[0079] Step S210: Decompose the fault occurrence layer by layer according to the fault occurrence system, the trend of fault parameter changes, and the specific fault description.

[0080] Step S220: Match the specific fault description with the corresponding fault variables in the test program to complete the fault injection.

[0081] It is understood that steps S210 to S220 of the embodiments of the present invention decompose the fault occurrence layer by layer according to the fault occurrence system, the trend of fault parameter changes and the specific fault description, so as to make the fault description more specific and detailed, which facilitates accurate matching of fault variables in the test program; by matching the specific fault description with the corresponding fault variables in the test program, accurate fault injection is achieved, improving the refinement and controllability of the test, thereby enhancing the accuracy and efficiency of the test.

[0082] Reference Figure 6 In step S210 of some embodiments, the fault occurrence is decomposed into a fault occurrence system according to the system in which it occurs. The fault occurrence system includes four parts: power supply system, load system, sensing system, and communication system.

[0083] Furthermore, the fault-causing system is decomposed into fault parameter change trends according to the change trends. Specifically, the power supply system is decomposed into voltage increase and voltage decrease, the load system is decomposed into load increase and load decrease, the sensing system is decomposed into internal sensor faults and external sensor faults of the tested system, and the communication system is decomposed into communication system underlying faults and communication system signal errors.

[0084] Furthermore, the trend of fault parameter changes is decomposed into specific fault descriptions based on the specific content of the TSR file. Specifically, voltage increase is decomposed into voltage increase, voltage decrease into open circuit, short circuit to power supply, short circuit to ground, positive and negative short circuit, loose connection, and voltage drop, and load increase into motor jamming, transmission mechanism jamming, and oil circuit blockage, and load decrease into oil circuit leakage and piston suspension. Internal sensor faults of the tested system are decomposed into push rod stroke sensor fault, pressure sensor fault, liquid level sensor fault, and temperature sensor fault, and external sensor faults of the tested system are decomposed into longitudinal acceleration signal fault, lateral acceleration signal fault, yaw rate signal fault, and steering wheel angle signal fault, and communication system low-level faults are decomposed into message transmission stoppage, communication disconnection, and message transmission cycle error, and communication system signal errors are decomposed into check error and a certain signal of a certain message being out of range.

[0085] In step S220 of some embodiments, the specific fault description is automatically matched with the test program to the corresponding fault variable, that is, a fault injection operation step is generated. For example, if the voltage drops to 7V, the test program finds a fault variable representing the voltage value, such as "U_ref", and sets the value of U_ref to 7.

[0086] Reference Figure 7 In step S200 of some embodiments, the requirements are converted into several functional safety test cases based on the required safety level, which may include, but is not limited to, steps S230 to S240.

[0087] Step S230: Based on the required safety level, set the value range of the fault variable.

[0088] Step S240: Based on the range of values ​​for the fault variables, the requirements are transformed into several functional safety test cases.

[0089] It is understood that steps S230 to S240 of the embodiments of the present invention, by setting the value range of fault variables based on the safety level and converting the requirements into several functional safety test cases, realize the generation of a number of functional safety test cases corresponding to each requirement based on the safety level, covering functional safety test cases with different values ​​of fault variables for each requirement, and significantly improving test coverage and accuracy.

[0090] In step S230 of some embodiments, each requirement in the TSR file includes a security level, which is divided into ASIL A, B, C and D levels, with D being the highest and A being the lowest. For example, in the specific fault description, among the three quantizable values ​​of voltage rise, voltage drop, and a certain signal in a certain message exceeding the range, for ASIL C and D levels, the fault variable is set to take three values ​​with a certain gradient above and below the boundary value. For example, in voltage rise, if the upper limit of voltage is 16V, then U_ref is set to 13V, 14V, 15V, 17V, 18V, and 19V. For ASIL B level, the fault variable is set to take two values ​​with a certain gradient above and below the boundary value. For example, in voltage rise, if the upper limit of voltage is 16V, then U_ref is set to 13V, 15V, 17V, and 19V. For ASIL A level, the fault variable is set to take one value with a certain gradient above and below the boundary value. For example, in voltage rise, if the upper limit of voltage is 16V, then U_ref is set to 15V and 17V.

[0091] Reference Figure 8 In some embodiments, step S300 involves matching the fault description with diagnostic specifications to generate a desired fault code and testing whether the fault code performance of the controller under test meets expectations. This step may include, but is not limited to, steps S310 to S330.

[0092] Step S310: Input the fault description into the diagnostic specification and filter out the expected fault codes of the fault description.

[0093] Step S320: Read the actual fault code issued by the controller under test for the corresponding fault.

[0094] Step S330: Compare the expected fault code with the actual fault code. If they match, the fault code behavior is determined to be as expected. If they do not match, the fault code behavior is determined to be as expected.

[0095] It is understood that steps S310 to S330 of the embodiments of the present invention, by inputting the fault description into the diagnostic specification to filter out the expected fault code and reading the actual fault code of the controller under test for comparison, realize the automation of fault code testing and reduce human error; by comparing the expected fault code and the actual fault code, the fault detection capability is objectively evaluated, ensuring the objectivity and reliability of the test results and improving the coverage of fault diagnosis.

[0096] In step S310 of some embodiments, the fault description is matched with the diagnostic specification to generate the expected fault code. That is, the fault description is input into the diagnostic specification, and the expected fault code of the specific fault description can be automatically filtered out (such as C1 4002).

[0097] In step S320 of some embodiments, the diagnostic function in the test program automatically reads the actual fault code issued by the controller under test at the corresponding fault at the FDTI time after the fault injection operation step is completed.

[0098] Reference Figure 9 In some embodiments, step S400 involves obtaining a specific execution description based on the processing method, which may include, but is not limited to, step S410.

[0099] Step S410: Decompose the processing method layer by layer according to security function, execution unit and specific execution description to obtain the specific execution description.

[0100] It is understood that step S410 of the present invention decomposes the processing method layer by layer according to security function, execution unit and specific execution description, making the execution description clearer and more structured, which facilitates accurate matching of test programs; by obtaining the specific execution description, it provides clear objectives for functional and performance testing, and improves the pertinence and comprehensiveness of testing.

[0101] Reference Figure 10 In step S410 of some embodiments, the processing method is decomposed into safety functions according to the functions that are intervened to ensure safety. The safety functions include two parts: redundant function startup and shutdown.

[0102] Furthermore, the safety functions are decomposed into execution units according to the system intervention. Specifically, the redundancy function activation is decomposed into dual-sided EPB intervention, single-sided EPB intervention, and RBU intervention, and the shutdown operation is decomposed into the tested controller stopping power supply and stopping assistance or clamping.

[0103] Furthermore, the execution unit is decomposed into specific execution descriptions based on the specific content descriptions in the TSR file. Specifically, the intervention of both sides of EPB is decomposed into EPB performing mechanical clamping, the intervention of one side of EPB is decomposed into the left side of EPB performing mechanical clamping as usual and the right side of EPB performing mechanical clamping as usual, the intervention of RBU is decomposed into RBU providing assistance, the power supply of the controller under test is decomposed into the controller that has a fault and the controller that has not a fault stop supplying power, and the power supply stop or clamping stop is decomposed into IBC assistance degradation, IBC no assistance, RBU assistance degradation, RBU no assistance, EPB clamping degradation, and EPB no clamping.

[0104] Reference Figure 11 In some embodiments, step S400 involves matching the specific execution description with the expected value of the test program to determine whether the function and performance of the controller under test meet expectations. This may include, but is not limited to, steps S420 to S440.

[0105] Step S420: Based on the specific execution description, find the corresponding working state and running performance variables in the test program, and set the expected values ​​of the corresponding working state and running performance variables.

[0106] Step S430: Read the actual values ​​of the variables corresponding to the working status and operating performance issued by the controller under test.

[0107] Step S440: Compare the actual values ​​of the variables corresponding to the working state and the running performance with the expected values ​​respectively. If the comparison results are that the actual value of the working state is consistent with the expected value and the actual value of the running performance is greater than the expected value, then it is determined that the function and performance meet the expectations. If the comparison results are that the actual value of the working state is inconsistent with the expected value or the actual value of the running performance is less than the expected value, then it is determined that the function and performance do not meet the expectations.

[0108] It is understood that steps S420 to S440 of the embodiments of the present invention quantify the functional and performance test standards by setting the expected values ​​of variables of working state and running performance in the test program based on the specific execution description and reading the actual values ​​for comparison, making the test results more objective; by comparing the actual values ​​of working state and running performance with the expected values, it is ensured that the behavior of the controller after fault handling meets the safety requirements, and the comprehensiveness and effectiveness of the test are improved.

[0109] In step S420 of some embodiments, based on the specific execution description, variables representing the corresponding working state and operating performance are found in the test program, and the expected values ​​of the variables representing the corresponding working state and operating performance are set. For example, if the specific execution description is that the EPB performs mechanical clamping, then variables representing the working state of both EPBs, such as “WorkingSt_EPBL” and “WorkingSt_EPBR”, are found in the test program, and variables representing the clamping force of both EPBs, such as “ClampingForce_EPBL” and “ClampingForce_EPBR”, are found. In the test program, at the FRTI time after reading the fault code and completing the evaluation, the expected values ​​of WorkingSt_EPBL and WorkingSt_EPBR are both set to 2 (indicating that both EPBs are in the clamping state), and the expected values ​​of ClampingForce_EPBL and ClampingForce_EPBR are both set to 7000 (indicating that the clamping force of both EPBs prevents the vehicle from slipping).

[0110] In step S430 of some embodiments, the actual values ​​of the variables corresponding to the working state and operating performance issued by the controller under test are read. For example, the test program reads the actual values ​​of “WorkingSt_EPBL” and “WorkingSt_EPBR” issued by the controller under test, and reads the actual values ​​of “ClampingForce_EPBL” and “ClampingForce_EPBR” collected by the clamping force sensor.

[0111] In step S440 of some embodiments, the actual values ​​of the variables corresponding to the working state and operating performance are compared with the expected values. For example, the actual values ​​of “WorkingSt_EPBL” and “WorkingSt_EPBR” sent by the controller under test are compared with the expected values ​​by the test program, and the actual values ​​of “ClampingForce_EPBL” and “ClampingForce_EPBR” collected by the clamping force sensor are compared with the expected values.

[0112] Reference Figure 12 In some embodiments, step S500 involves performing tests on all required functional safety test cases, calculating and evaluating the compliance rate of fault codes and functional and performance performance of all required functional safety test cases, which may include, but is not limited to, steps S510 to S540.

[0113] Step S510: Execute all functional safety test cases required and obtain the fault code manifestations and functional and performance characteristics of each functional safety test case.

[0114] Step S520: Calculate the ratio of the number of functional safety test cases in the requirement whose fault codes meet expectations to the total number of functional safety test cases included in that requirement.

[0115] Step S530: Calculate the ratio of the number of functional safety test cases in the requirement whose functionality and performance meet expectations to the total number of functional safety test cases included in that requirement.

[0116] Step S540: Based on the security level of the requirement, define the activation success rate of the security mechanism of the requirement. If both ratios are not less than the corresponding activation success rate of the security mechanism, the functional safety test of the requirement is evaluated as qualified. If at least one of the two ratios is less than the corresponding activation success rate of the security mechanism, the functional safety test of the requirement is evaluated as unqualified.

[0117] It is important to understand that the two ratios are, respectively, the ratio of the number of functional safety test cases in the requirement whose fault codes behave as expected to the total number of functional safety test cases included in that requirement, and the ratio of the number of functional safety test cases in the requirement whose functions and performance behave as expected to the total number of functional safety test cases included in that requirement.

[0118] It is understood that steps S510 to S540 of the embodiments of the present invention, by executing all functional safety test cases and obtaining fault code manifestations and functional and performance performance, ensure that each requirement is fully tested, reduce test omissions, and enhance the systematic nature of the test; by calculating the compliance rate of fault code manifestations and functional and performance performance, and evaluating the success rate of security mechanism activation based on the security level definition, quantitative test evaluation indicators are provided, making the test results more scientific and rigorous; by comprehensively evaluating fault codes and functional performance, the safety performance of the controller is fully reflected, ensuring that the test standards match the safety requirements, and improving the reliability of the evaluation and decision support capabilities.

[0119] In steps S510 to S540 of some embodiments, the activation success rate of the security mechanism can be defined as 90%, 95%, 100%, and 100% respectively, depending on the security level ASIL A, B, C, and D.

[0120] Furthermore, in real time, fault code performance is obtained for each functional safety test case included in each requirement, and the ratio of the number of functional safety test cases whose fault code performance meets expectations to the total number of functional safety test cases included in that requirement is calculated. Functional and performance evaluations are also obtained for each functional safety test case included in each requirement in real time, and the ratio of the number of functional safety test cases whose functional and performance performance meets expectations to the total number of functional safety test cases included in that requirement is calculated. Based on the activation success rate of the security mechanism corresponding to the security level, if both ratios are not less than the corresponding security mechanism activation success rate, the functional safety test evaluation of that TSR requirement is qualified; if at least one of the two ratios is less than the corresponding security mechanism activation success rate, the functional safety test evaluation of that TSR requirement is unqualified.

[0121] As can be seen from the above embodiments, this application's embodiments are based on functional safety concepts, diagnostic specifications, and TSR files. By performing standard functional safety test case semantic conversion and automated sentence segmentation on each requirement in the TSR file, the requirements in the TSR file are transformed into standardized, structured functional safety test cases, improving the consistency and repeatability of testing. By matching specific fault descriptions with corresponding fault variables in the test program, precise fault injection is achieved, enhancing the targeting of testing. By converting each requirement into several functional safety test cases based on safety levels, the testing intensity of each requirement is matched with its safety level. By matching fault descriptions with diagnostic specifications, the generation period is... By reviewing fault codes and testing the fault code behavior of the controller under test, the accuracy and reliability of fault detection are ensured. Specific execution descriptions are obtained based on processing methods and matched with expected values ​​in the test program to test functionality and performance, comprehensively evaluating the controller's responsiveness and improving the comprehensiveness of the test. Evaluation is provided by calculating the compliance rate of fault code behavior and functional and performance behavior for all functional safety test cases for each requirement, offering quantifiable test metrics. This embodiment, through the above series of operations, forms an automated conversion process from TSR files to functional safety test cases, significantly improving test scenario coverage, reducing the risk of omissions, and simultaneously improving the efficiency of functional safety test execution.

[0122] This invention also provides a braking system functional safety testing device, which can implement the above-described braking system functional safety testing method. The braking system functional safety testing device includes:

[0123] The fault injection module is used to convert each requirement in the TSR file into a standard functional safety test case semantic format, segment the standard functional safety test case into sentences, and the segmented standard functional safety test case includes fault occurrence, fault description and handling method. Based on the fault occurrence, a specific fault description is obtained, the specific fault description is matched with the test program, and based on the safety level of the requirement, the requirement is converted into several functional safety test cases.

[0124] The fault code reading and evaluation module is used to match the specific fault description with the diagnostic specifications to generate the expected fault code and determine whether the fault code performance of the controller under test meets expectations.

[0125] The functional and performance evaluation module is used to obtain a specific execution description based on the processing method, match the specific execution description with the expected value of the test program, and determine whether the function and performance of the controller under test meet the expectations.

[0126] The requirement test evaluation module is used to execute all the functional safety test cases of the requirement, calculate and evaluate the compliance rate of the fault codes and the functional and performance performance of all the functional safety test cases of the requirement.

[0127] It is understood that the content of the above method embodiments is applicable to the present device embodiments. The specific functions implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0128] This invention also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described braking system functional safety test method.

[0129] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0130] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described braking system functional safety testing method.

[0131] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0132] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0133] The braking system functional safety testing method, apparatus, electronic device, and storage medium provided in this invention convert each requirement in the TSR file into a standard functional safety test case semantic format. The standard functional safety test case is segmented into five parts: fault occurrence, fault detection time interval, fault description, fault handling time interval, and handling method. Based on the fault occurrence, a specific fault description is obtained. The specific fault description is matched with the corresponding fault variables in the test program. Based on the safety level of each requirement in the TSR file, each requirement in the TSR file is converted into several functional safety test cases. The fault description is matched with diagnostic specifications to generate expected fault codes, and the fault code performance of the controller under test is tested to see if it meets expectations. Based on the handling method, a specific execution description is obtained. The specific execution description is matched with the expected value in the test program, and the functional and performance performance of the controller under test is tested to see if it meets expectations. All functional safety test cases for each requirement in the TSR file are executed for testing. The compliance rate of the fault code performance and functional and performance performance of all functional safety test cases for each requirement is calculated and evaluated. This solution, based on functional safety principles, diagnostic specifications, and TSR (Test Response System) documents, transforms each requirement in the TSR document into standardized, structured functional safety test cases by performing standard functional safety test case semantic conversion and automated sentence segmentation. This improves test consistency and repeatability. By matching specific fault descriptions with corresponding fault variables in the test program, precise fault injection is achieved, enhancing test targeting. Each requirement is transformed into several functional safety test cases based on safety levels, ensuring the test intensity of each requirement matches its safety level. Finally, expected fault codes are generated by matching specific fault descriptions with diagnostic specifications. The test also examines the fault code behavior of the controller under test, ensuring the accuracy and reliability of fault detection. By obtaining specific execution descriptions based on processing methods and matching them with expected values ​​in the test program, the test functions and performance are evaluated, comprehensively assessing the controller's responsiveness and improving the comprehensiveness of the test. The test provides quantitative test indicators by calculating the compliance rate of fault code behavior and functional and performance behavior of all functional safety test cases for each requirement. Through the above series of operations, this embodiment forms an automated conversion process from TSR files to functional safety test cases, significantly improving test scenario coverage, reducing the risk of omissions, and improving the efficiency of functional safety test execution.

[0134] It will be understood by those skilled in the art that all or some of the steps and systems in the methods disclosed above can be implemented as software, firmware, hardware, and suitable combinations thereof. Some or all of the physical components can be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, which can include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, as is known to those skilled in the art, communication media typically include computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0135] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0136] In the description of this specification, the references to terms such as "an embodiment, some embodiments, illustrative embodiments, example, specific example, or examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0137] The terms "first," "second," "third," "fourth," etc. (if applicable) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein.

[0138] It should also be noted that, in the description of this specification, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations.

[0139] Furthermore, the terms “comprising” and “having”, and any variations thereof, are intended to cover non-exclusive inclusion, such that a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may also include other steps or units that are not explicitly listed or that are inherent to such processes, methods, products, or apparatus.

[0140] Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0141] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the present invention is not limited to the above embodiments. Within the scope of knowledge possessed by those skilled in the art, various changes can be made without departing from the spirit of the present invention.

Claims

1. A method for testing the functional safety of a braking system, characterized in that, Includes the following steps: Each requirement in the TSR file is converted into a standard functional safety use case semantic format. The standard functional safety use case is then segmented into sentences, and the segmented standard functional safety use case includes fault occurrence, fault description, and handling method. Based on the occurrence of the fault, a specific fault description is obtained, and the specific fault description is matched with the corresponding fault variables in the test program. Based on the security level of the requirement, the requirement is transformed into several functional safety test cases. The fault description is matched with the diagnostic specifications to generate the expected fault code, and it is determined whether the fault code performance of the controller under test meets the expectations. Based on the processing method, a specific execution description is obtained, and the specific execution description is matched with the expected value of the test program to determine whether the function and performance of the controller under test meet the expectations. Perform all the functional safety test cases of the requirements, calculate and evaluate the compliance rate of the fault codes and the functions and performance of all the functional safety test cases of the requirements.

2. The method for functional safety testing of a braking system according to claim 1, characterized in that, The step of obtaining a specific fault description based on the occurrence of the fault and matching the specific fault description with the corresponding fault variables in the test program includes the following steps: The occurrence of the fault is decomposed layer by layer according to the fault-causing system, the trend of fault parameter changes, and the specific fault description. The specific fault description is matched with the corresponding fault variables in the test program to complete the fault injection.

3. The method for functional safety testing of a braking system according to claim 1, characterized in that, Based on the security level of the requirements, the requirements are transformed into several functional safety test cases, including the following steps: Based on the security level required, the range of values ​​for the fault variables is set; Based on the range of values ​​for the fault variables, the requirements are transformed into several functional safety test cases.

4. The method for functional safety testing of a braking system according to claim 1, characterized in that, The step of matching the fault description with the diagnostic specifications to generate the expected fault code and determining whether the fault code performance of the controller under test meets expectations includes the following steps: Input the fault description into the diagnostic specification and filter out the expected fault codes corresponding to the fault description; Read the actual fault code issued by the controller under test for the corresponding fault; The expected fault code is compared with the actual fault code. If they match, the fault code is determined to be performing as expected. If they do not match, the fault code is determined to be performing as expected.

5. The method for functional safety testing of a braking system according to claim 1, characterized in that, The step of obtaining a specific execution description based on the processing method includes the following steps: The processing method is decomposed layer by layer according to security functions, execution units, and specific execution descriptions to obtain the specific execution descriptions.

6. The method for testing the functional safety of a braking system according to claim 1, characterized in that, The step of matching the specific execution description with the expected value of the test program to determine whether the function and performance of the controller under test meet the expectations includes the following steps: Based on the specific execution description, find the corresponding working state and running performance variables in the test program, and set the expected values ​​of the corresponding working state and running performance variables. Read the actual values ​​of the variables corresponding to the working status and operating performance issued by the controller under test; The actual values ​​of the variables corresponding to the working status and running performance are compared with the expected values. If the comparison results show that the actual value of the working status is consistent with the expected value and the actual value of the running performance is greater than the expected value, then the function and performance are determined to meet the expectations. If the comparison results show that the actual value of the working status is inconsistent with the expected value or the actual value of the running performance is less than the expected value, then the function and performance are not in line with the expectations.

7. The method for functional safety testing of a braking system according to claim 1, characterized in that, The process involves testing all functional safety test cases that fulfill the requirements, calculating and evaluating the compliance rate of the fault codes and functional and performance performance of all functional safety test cases for the requirements, including the following steps: Execute all the functional safety test cases of the requirements and obtain the fault code manifestation and the functional and performance performance of each functional safety test case; Calculate the ratio of the number of functional safety test cases in the requirement that meet the expected performance of the fault codes to the total number of functional safety test cases included in the requirement; Calculate the ratio of the number of functional safety test cases in the requirement that meet the expected performance of the function to the total number of functional safety test cases included in the requirement; Based on the security level of the requirement, the activation success rate of the security mechanism for the requirement is defined. If both ratios are not less than the activation success rate of the security mechanism, the functional security test of the requirement is evaluated as qualified. If at least one of the two ratios is less than the activation success rate of the security mechanism, the functional security test of the requirement is evaluated as unqualified.

8. A functional safety testing device for a braking system, characterized in that, include: The fault injection module is used to convert each requirement in the TSR file into a standard functional safety test case semantic format, segment the standard functional safety test case into sentences, and the segmented standard functional safety test case includes fault occurrence, fault description and handling method. Based on the fault occurrence, a specific fault description is obtained, the specific fault description is matched with the test program, and based on the safety level of the requirement, the requirement is converted into several functional safety test cases. The fault code reading and evaluation module is used to match the fault description with the diagnostic specifications to generate the expected fault code and determine whether the fault code performance of the controller under test meets expectations. The functional and performance evaluation module is used to obtain a specific execution description based on the processing method, match the specific execution description with the expected value of the test program, and determine whether the functional and performance performance of the controller under test meets the expectations. The requirement test evaluation module is used to execute all the functional safety test cases of the requirement, calculate and evaluate the compliance rate of the fault codes and the functional and performance performance of all the functional safety test cases of the requirement.

9. An electronic device, characterized in that, The method includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

Images