Controller fault diagnosis test method, device and electronic equipment

Abstract

The application relates to a controller fault diagnosis test method, device and electronic equipment. The method comprises the following steps: obtaining a test case and converting the test case into an automatic test script; wherein the test case comprises a fault injection type; injecting a fault corresponding to the fault injection type into a controller through the automatic test script; obtaining fault information stored by the controller through the automatic test script; the fault information is used for representing abnormal conditions of the controller after being injected with the fault; and analyzing the fault information through the automatic test script to obtain a fault diagnosis test result. The scheme provided in the application can automatically complete controller fault diagnosis test, does not require manual operation, can improve the efficiency and accuracy of fault diagnosis test, and greatly reduces the labor cost and time cost.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of fault diagnosis, in particular to a controller fault diagnosis test method and device and electronic equipment. BACKGROUND

[0002] The fault diagnosis test of the software level of the vehicle controller can help the tester to find and solve potential problems in the software in the simulation of the actual scene, which can effectively reduce the failure rate of the controller in the subsequent use process, thereby improving the reliability of the controller and the user satisfaction.

[0003] In the fault diagnosis test of the software level of the vehicle controller of the related technology, at the software operation level, most of them are still based on the way of manually sending fault data by the tester; at the hardware level, the tester also needs to manually pull out the wiring harness and other operations to complete the fault injection, which undoubtedly greatly consumes the labor cost and time cost. SUMMARY

[0004] To solve or partially solve the problems in the related technology, the present application provides a controller fault diagnosis test method, device and electronic equipment, which can automatically complete the controller fault diagnosis test without manual operation, can improve the efficiency and accuracy of the fault diagnosis test, and greatly reduce the labor cost and time cost.

[0005] The first aspect of the present application provides a controller fault diagnosis test method, comprising:

[0006] Obtaining a test case and converting the test case into an automatic test script; wherein the test case comprises a fault injection type;

[0007] Injecting a fault corresponding to the fault injection type into the controller through the automatic test script;

[0008] Obtaining fault information stored by the controller through the automatic test script; the fault information is used to represent abnormal conditions of the controller after being injected with the fault;

[0009] Analyzing the fault information through the automatic test script to obtain a fault diagnosis test result.

[0010] In an embodiment, the controller comprises a primary controller and a secondary controller; and the injecting a fault corresponding to the fault injection type into the controller through the automatic test script comprises:

[0011] The automated test script injects faults of the specified fault injection type into the primary controller and the secondary controller respectively; wherein, the fault injection type includes any one of the following: model fault injection type, electrical fault injection type, and message fault injection type.

[0012] In one embodiment, obtaining the fault information stored in the controller through the automated test script includes:

[0013] After waiting for the preset fault trigger time, a diagnostic request instruction is sent to the primary controller through the automated test script;

[0014] The automated test script receives diagnostic response data returned by the primary controller in response to the diagnostic request instruction; wherein the diagnostic response data includes fault information stored by the primary controller itself and / or fault information of the secondary controller stored by the primary controller.

[0015] In one embodiment, obtaining test cases and converting the test cases into automated test scripts includes:

[0016] Obtain the diagnostic table; the diagnostic table includes multiple fault injection types; wherein, the multiple fault injection types are the model fault injection type, the electrical fault injection type, and the message fault injection type;

[0017] Build test case rules;

[0018] The diagnostic table is parsed according to the test case rules to obtain multiple test cases; each of the multiple test cases includes one of the fault injection types.

[0019] The test cases are converted into automated test scripts.

[0020] In one embodiment, injecting the fault corresponding to the fault injection type into the primary controller and the secondary controller respectively through the automated test script includes:

[0021] The automated test script is used to initialize the primary controller and the secondary controller respectively.

[0022] The automated test script injects faults corresponding to the fault injection types in the test cases of the current sequence into the primary controller and the secondary controller, respectively.

[0023] In one embodiment, injecting faults of the fault injection type corresponding to the current sequence of test cases into the primary controller and the secondary controller respectively via the automated test script includes:

[0024] determine a corresponding fault injection mode according to a fault injection type in the test case in the current sequence through the automation test script;

[0025] send corresponding set signals to the primary controller and the secondary controller respectively according to the fault injection mode through the automation test script; wherein the set signals are used to inject corresponding faults to the primary controller and the secondary controller.

[0026] In an embodiment, the determination of the corresponding fault injection mode according to the fault injection type in the test case in the current sequence through the automation test script comprises:

[0027] If the fault injection type in the test case in the current sequence is the model fault injection type, the corresponding fault injection mode is determined as the model fault injection mode;

[0028] The sending of the corresponding set signals to the primary controller and the secondary controller respectively according to the fault injection mode through the automation test script comprises:

[0029] invoking a controller model control through the automation test script according to the model fault injection mode;

[0030] The sending of the corresponding set signals to the primary controller and the secondary controller respectively through the automation test script comprises:

[0031] In another embodiment, the determination of the corresponding fault injection mode according to the fault injection type in the test case in the current sequence through the automation test script comprises:

[0032] If the fault injection type in the test case in the current sequence is the electrical fault injection type, the corresponding fault injection mode is determined as the electrical fault injection mode;

[0033] The sending of the corresponding set signals to the primary controller and the secondary controller respectively according to the fault injection mode through the automation test script comprises:

[0034] invoking an electrical fault injection (EFI) fault injection board card through the automation test script according to the electrical fault injection mode; the EFI fault injection board card is connected to the primary controller and the secondary controller respectively through a wire harness;

[0035] The automated test script controls the on / off state of the interface of the EFI fault injection board to generate a corresponding set signal, and sends the corresponding set signal to the primary controller and the secondary controller respectively through the wiring harness.

[0036] In another embodiment, determining the corresponding fault injection method based on the fault injection type in the currently ordered test cases using the automated test script includes:

[0037] If the fault injection type in the test cases in the current sequence is the message fault injection type, then the corresponding fault injection method is determined to be the message fault injection method.

[0038] The step of sending corresponding set signals to the primary controller and the secondary controller respectively through the automated test script according to the fault injection method includes:

[0039] The automated test script generates a fault message signal according to the message fault injection method, and uses the fault message signal as the corresponding set signal, and sends the corresponding set signal to the first-level controller and the second-level controller respectively.

[0040] In one embodiment, the method further includes:

[0041] Based on the diagnostic response data, the target controller that exhibits abnormal behavior after the fault is injected is determined from the primary controller and the secondary controller;

[0042] The automated test script sends a reset message to the target controller to perform fault recovery on the target controller.

[0043] In one embodiment, the method further includes:

[0044] After waiting for the preset fault recovery time, determine the completion of the fault diagnosis test process for the test cases in the current sequence;

[0045] The automated test script re-initializes the primary controller and the secondary controller, and executes the fault diagnosis test process for the next sequence of test cases until the fault diagnosis test process for the last sequence of test cases is completed.

[0046] A second aspect of this application provides a controller fault diagnosis and testing apparatus, comprising:

[0047] A test case acquisition module is used to acquire test cases and convert them into automated test scripts; wherein, the test cases include fault injection types;

[0048] The fault injection module is used to inject the fault corresponding to the fault injection type into the controller through the automated test script;

[0049] The fault information acquisition module is used to acquire the fault information stored in the controller through the automated test script; the fault information is used to characterize the abnormal situation that occurs in the controller after the fault is injected.

[0050] The fault information parsing module is used to parse the fault information through the automated test script to obtain fault diagnosis test results.

[0051] A third aspect of this application provides an electronic device, comprising:

[0052] Processor; and

[0053] A memory that stores executable code, which, when executed by the processor, causes the processor to perform the method described above.

[0054] The technical solution provided in this application may include the following beneficial effects:

[0055] The solution provided in this application involves acquiring test cases and converting them into automated test scripts. The test cases include fault injection types. The automated test scripts inject the corresponding faults into the controller. The automated test scripts then retrieve the fault information stored in the controller. This fault information characterizes the abnormal behavior that occurs in the controller after the fault is injected. Finally, the automated test scripts parse the fault information to obtain the fault diagnosis test results. By converting test cases into automated test scripts, this application allows the automated test scripts to execute the entire controller fault diagnosis test process without manual intervention, thereby improving the efficiency and accuracy of fault diagnosis testing and significantly reducing labor and time costs.

[0056] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0057] The above and other objects, features and advantages of this application will become more apparent from the following description of exemplary embodiments of this application in conjunction with the accompanying drawings, wherein the same reference numerals generally represent the same components in the exemplary embodiments of this application.

[0058] Figure 1 This is a schematic flowchart illustrating the controller fault diagnosis test method shown in the embodiments of this application;

[0059] Figure 2This is another schematic flowchart of the controller fault diagnosis test method shown in the embodiments of this application;

[0060] Figure 3 This is a complete flowchart of controller fault diagnosis testing shown in the embodiments of this application;

[0061] Figure 4 This is a flowchart illustrating the fault diagnosis test process for multiple controllers using model fault injection methods as shown in the embodiments of this application;

[0062] Figure 5 This is a fault diagnosis test flowchart illustrating the electrical fault injection methods of multiple controllers in the embodiments of this application;

[0063] Figure 6 This is a flowchart illustrating the fault diagnosis test process for message fault injection methods of multiple controllers as shown in the embodiments of this application;

[0064] Figure 7 This is a schematic diagram of the controller fault diagnosis and testing device shown in the embodiments of this application;

[0065] Figure 8 This is a schematic diagram of the structure of an electronic device shown in an embodiment of this application. Detailed Implementation

[0066] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While embodiments of this application are shown in the drawings, it should be understood that this application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to make this application more thorough and complete, and to fully convey the scope of this application to those skilled in the art.

[0067] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0068] It should be understood that although the terms "first," "second," "third," etc., may be used in this application to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0069] In the software-level fault diagnosis testing of vehicle controllers in related technologies, at the software operation level, most of the testing is still based on the method of testers manually sending fault data; at the hardware level, testers also need to manually unplug and plug in wiring harnesses to complete fault injection, which undoubtedly consumes a lot of labor and time costs.

[0070] To address the aforementioned issues, this application provides a controller fault diagnosis testing method. By converting test cases into automated test scripts, the automated test scripts execute the entire controller fault diagnosis testing process without manual intervention, thereby improving the efficiency and accuracy of fault diagnosis testing and significantly reducing labor and time costs.

[0071] The technical solutions of the embodiments of this application are described in detail below with reference to the accompanying drawings.

[0072] Figure 1 This is a schematic flowchart illustrating the controller fault diagnosis test method shown in the embodiments of this application.

[0073] See Figure 1 The controller fault diagnosis test method of this application includes:

[0074] S110: Obtain test cases and convert them into automated test scripts; among them, test cases include fault injection types.

[0075] In the embodiments of this application, it can be applied to HIL (Hardware-in-the-Loop) simulation test system, specifically it can be applied to automated diagnostic software in the HIL simulation test system.

[0076] It should be noted that the automated diagnostic software is used in the HIL testing phase; therefore, the embodiments of this application do not involve vehicle diagnostic functions. In other words, during the HIL testing phase, the HIL simulation test system does not need to communicate with the vehicle. Instead, it uses the automated diagnostic software to directly perform fault diagnosis tests on the independent controller. Once the controller passes the fault diagnosis test, if all other functions of the controller are normal except for the diagnostic function, the controller can be delivered downstream. For example, the controller can be installed on a bare vehicle, a LabCAR (experimental vehicle), another test bench, or a complete vehicle.

[0077] The HIL simulation test system is equipped with a HIL simulation test environment, which supports the joint invocation of multiple controllers. Steps S110 to S140 are mainly explained using a single controller as an example, while steps S210 to S250 are mainly explained using multiple controllers as an example.

[0078] The automated diagnostic software in the HIL simulation test system integrates various automated testing tools, including test case generation tools, test script generation tools, Veristand (prototype verification system software) control reading and writing tools, and EFI (Electric Failure Insert) fault injection tools. The HIL simulation test system can call these test case generation tools and test script generation tools. The test case generation tool can automatically generate test cases, and the test script generation tool can automatically convert these test cases into automated test scripts. A test case is a descriptive document describing the testing task for a corresponding fault, such as the test objective, test environment, and test steps. An automated test script is a computer program consisting of a series of automatically executable codes, thus enabling the automated execution of test cases.

[0079] Test cases can carry corresponding fault injection types, which can be used to indicate the type of fault injected into the controller.

[0080] S120 injects faults of the corresponding fault injection type into the controller through automated test scripts.

[0081] Fault injection is a crucial part of fault diagnosis testing. It simulates various fault scenarios that may occur in the controller during actual operation by injecting various faults into the controller. This allows for a comprehensive understanding of the controller's performance under various fault scenarios, verifies the effectiveness of the controller's fault tolerance and self-recovery mechanisms, and promptly identifies potential problems in the controller during the HIL testing phase, thereby evaluating the controller's stability and reliability.

[0082] In this embodiment, the fault injection type may include at least one of model fault injection type, electrical fault injection type, and message fault injection type. Each test case carries only one fault injection type; therefore, the test cases obtained by the HIL simulation test system may include at least one. The HIL simulation test system can execute at least one test case sequentially using automated test scripts. Specifically, the HIL simulation test system can first extract the fault injection type from the currently ordered test cases, and then inject the fault corresponding to that fault injection type into the controller using automated test scripts.

[0083] S130: Obtain fault information stored in the controller through automated test scripts; the fault information is used to characterize the abnormal situation that occurs in the controller after a fault is injected.

[0084] After a fault is injected into the controller, abnormal situations may occur. That is, the controller may experience a fault corresponding to the fault injection type. When the controller recognizes the fault, it can store the corresponding fault information. The HIL simulation test system can automatically obtain the fault information stored by the controller through automated test scripts. Through the fault information, we can understand the abnormal situations that occur in the controller after the fault is injected.

[0085] Furthermore, after a fault is injected into the controller, the controller may not experience any abnormal situations due to its fault tolerance mechanism or self-recovery mechanism. That is, the controller may not experience the fault corresponding to the fault injection type, and therefore the controller may not have any fault information.

[0086] S140 uses automated test scripts to analyze fault information and obtain fault diagnosis test results.

[0087] The fault information can include fault codes and snapshot information. Fault codes, also known as Diagnostic Trouble Codes (DTCs), help users quickly locate and resolve controller malfunctions. Snapshot information records the controller's state at the time of the fault; similar to taking a photograph, it preserves the controller's state at the time of the fault, helping users analyze the cause and reproduce the fault. Therefore, the HIL simulation test system uses automated test scripts to parse the fault information, quickly obtaining the controller's fault diagnosis test results.

[0088] As this example demonstrates, the solution provided in this application involves acquiring test cases and converting them into automated test scripts. The test cases include fault injection types. The automated test scripts inject the corresponding faults into the controller. The automated test scripts then retrieve the fault information stored in the controller. This fault information characterizes the abnormal conditions that occur in the controller after the fault is injected. Finally, the automated test scripts parse the fault information to obtain the fault diagnosis test results. By converting test cases into automated test scripts, which then execute the entire controller fault diagnosis test process, this application eliminates the need for manual operation, thereby improving the efficiency and accuracy of fault diagnosis testing and significantly reducing labor and time costs.

[0089] Figure 2 This is another schematic flowchart of the controller fault diagnosis test method shown in the embodiments of this application.

[0090] See Figure 2 The controller fault diagnosis test method of this application includes:

[0091] S210: Obtain test cases and convert them into automated test scripts; among them, test cases include fault injection types.

[0092] This step can be found in the description in S110, and will not be repeated here.

[0093] It should be noted that steps S110 to S140 are mainly explained using a single controller as an example, while steps S210 to S250 are mainly explained using multiple controllers as an example.

[0094] In one implementation, obtaining test cases and converting them into automated test scripts may include:

[0095] Obtain the diagnostic table; the diagnostic table includes multiple fault injection types; among which, the multiple fault injection types are model fault injection type, electrical fault injection type, and message fault injection type; construct test case rules; parse the diagnostic table according to the test case rules to obtain multiple test cases; each of the multiple test cases includes one fault injection type; convert the multiple test cases into automated test scripts.

[0096] Testers can fill in the fault signals for each diagnostic function in the diagnostic table. The fault signals come from Veristand signals, programmable EFI interface signals, and fault message signals, etc. Testers can input the diagnostic table into the HIL simulation test system, which will parse the diagnostic table to obtain multiple test cases.

[0097] In its implementation, the HIL simulation test system, after obtaining the diagnostic table, can read the test information within it. This test information can include at least one of the following: fault type, object under test, preset fault trigger time, and preset fault recovery time. The fault type can include at least one of model faults, electrical faults, and message faults. The object under test can include at least one controller (e.g., a primary controller and a secondary controller). The preset fault trigger time is the estimated time it takes for the controller to set the fault code after a fault is injected. The preset fault recovery time is the estimated time it takes for the controller to reset the fault code after fault recovery. The HIL simulation test system can call a test case generation tool to construct test case rules based on the fault type, object under test, preset fault trigger time, and preset fault recovery time. Then, it parses and fills in the diagnostic table of the fault signal according to the test case rules, thereby automatically generating multiple test cases. Each of these test cases includes a fault injection type. Therefore, if the diagnostic table includes model fault injection type, electrical fault injection type and message fault injection type, the diagnostic table can be parsed into three test cases, namely test case 1, test case 2 and test case 3. Test case 1 can carry model fault injection type, test case 2 can carry electrical fault injection type and test case 3 can carry message fault injection type.

[0098] After obtaining multiple test cases, the HIL simulation test system can call the test script generation tool to automatically convert all test cases into an automated test script. The HIL simulation test system can then execute multiple test cases sequentially through the automated test script. The execution order can be arbitrary, for example, it can be: test case 1 → test case 2 → test case 3, or it can be: test case 3 → test case 2 → test case 1. This application embodiment does not limit this.

[0099] S220 injects faults of the corresponding fault injection types into the primary controller and the secondary controller respectively through automated test scripts; wherein, the fault injection type includes any one of the model fault injection type, electrical fault injection type and message fault injection type.

[0100] This step can be found in the description in S120, and will not be repeated here.

[0101] In one implementation, injecting faults of the corresponding fault injection type into the primary controller and the secondary controller respectively using automated test scripts may include:

[0102] The primary and secondary controllers are initialized using automated test scripts; the faults corresponding to the fault injection types in the test cases of the current sequence are injected into the primary and secondary controllers using automated test scripts.

[0103] In addition to the aforementioned problems at the software and hardware levels, related technologies also include problems at the controller level. For example, at the controller level, only one controller can be diagnosed at a time. However, there are many controllers to be diagnosed. If fault diagnosis can only be performed on each controller one by one, it will undoubtedly consume a lot of time and resources.

[0104] To address this, this application's embodiments leverage existing hardware and software principles to construct an automated fault diagnosis testing framework. By integrating faulty operational objects, automated program control of these objects can be achieved. Specifically, the HIL simulation testing system is configured with a HIL simulation testing environment that supports the joint invocation of multiple controllers. Therefore, the HIL simulation testing system can jointly invoke primary and secondary controllers. A primary controller can be one, and multiple secondary controllers can be present. The primary controller can centrally store fault information from all controllers, and each secondary controller can send its own fault information to the primary controller for storage.

[0105] Since each test case contains multiple test steps, it belongs to the previous sequence of test cases until all test steps of the previous sequence of test cases have been executed. After all test steps of the previous sequence of test cases have been executed, the HIL simulation test system can initialize the first-level controller and the second-level controller separately through automated test scripts. This is to avoid some operations of the previous sequence of test cases affecting the fault diagnosis test results of the current sequence of test cases. Therefore, after the first-level controller and the second-level controller are initialized separately, the HIL simulation test system will inject the faults corresponding to the fault injection types in the current sequence of test cases into the first-level controller and the second-level controller respectively through automated test scripts.

[0106] In one implementation, injecting faults of the fault injection type corresponding to the current sequence of test cases into the primary controller and secondary controller respectively using automated test scripts may include:

[0107] The automated test script determines the corresponding fault injection method based on the fault injection type in the test cases of the current sequence; according to the fault injection method, the automated test script sends the corresponding set signal to the primary controller and the secondary controller respectively; the set signal is used to inject the corresponding fault into the primary controller and the secondary controller.

[0108] Different fault injection types have different fault injection methods. Therefore, the HIL simulation test system can determine the corresponding fault injection method based on the fault injection type carried by the test cases in the current sequence through automated test scripts. In this way, the automated test scripts can send the corresponding set signals to the primary controller and the secondary controller according to the currently determined fault injection method. The set signals can be used to inject the fault corresponding to the current fault injection type into the primary controller and the secondary controller.

[0109] In one implementation, determining the corresponding fault injection method based on the fault injection type in the current sequence of test cases using an automated test script may include:

[0110] If the fault injection type in the current sequence of test cases is the model fault injection type, then the corresponding fault injection method is determined to be the model fault injection method.

[0111] In a HIL simulation test environment that supports joint calls from multiple controllers, three fault injection methods can be included: model fault injection, electrical fault injection, and message fault injection.

[0112] If the fault injection type carried by the test cases in the current sequence is the model fault injection type, then the corresponding fault injection method can be determined to be the model fault injection method. The model fault injection method can be to simulate the fault by sending the physical values ​​of the Veristand control model simulation to the controller itself.

[0113] In one embodiment, the automated test script sends corresponding set signals to the primary controller and the secondary controller respectively according to the fault injection method, which may include:

[0114] The automated test script calls the controller model control according to the model fault injection method; the automated test script uses the simulated physical values ​​of the controller model control as the corresponding set signals, and sends the corresponding set signals to the first-level controller and the second-level controller respectively.

[0115] The automated test script can execute fault diagnosis test procedures for multiple controllers according to the currently determined model fault injection method. In specific implementation, the automated diagnostic software in the HIL simulation test system integrates a Veristand control read / write tool. The HIL simulation test system can first establish communication with Veristand so that the automated test script can call the Veristand control read / write tool. The Veristand control read / write tool can specifically be a controller model control. The automated test script can obtain the simulated physical values ​​of the controller model control, and use these simulated physical values ​​as the set signals corresponding to the model fault injection type. Then, it sends the corresponding set signals to the primary controller and the secondary controller respectively, thereby completing the model fault injection.

[0116] In another implementation, determining the corresponding fault injection method using an automated test script based on the fault injection types in the currently ordered test cases may include:

[0117] If the fault injection type in the current sequence of test cases is electrical fault injection, then the corresponding fault injection method is determined to be electrical fault injection method.

[0118] If the fault injection type carried by the test cases in the current sequence is electrical fault injection, then the corresponding fault injection method can be determined to be electrical fault injection. Electrical fault injection can be implemented by using an EFI fault injection board to inject faults into the hard wires connected to the controller.

[0119] In another embodiment, sending corresponding set signals to the primary controller and the secondary controller respectively through an automated test script according to the fault injection method may include:

[0120] The EFI fault injection board is invoked according to the electrical fault injection method using an automated test script. The EFI fault injection board is connected to the primary controller and the secondary controller via wiring harnesses. The automated test script controls the on / off state of the interface of the EFI fault injection board to generate corresponding set signals, and sends the corresponding set signals to the primary controller and the secondary controller via wiring harnesses.

[0121] The automated test script can execute fault diagnosis test procedures for multiple controllers according to the currently determined electrical fault injection method. In specific implementation, the automated diagnostic software in the HIL simulation test system integrates an EFI fault injection tool. The HIL simulation test system can call the EFI fault injection tool through the automated test script. The EFI fault injection tool can specifically be an EFI fault injection board. The EFI fault injection board is physically connected to the primary controller and the secondary controller via hardwires (e.g., wiring harnesses). The automated test script can control the on / off state of the interface of the EFI fault injection board to generate a set signal corresponding to the electrical fault injection type, and then send the corresponding set signal to the primary controller and the secondary controller respectively through the wiring harness, thereby completing the electrical fault injection.

[0122] In another implementation, the corresponding fault injection method is determined by an automated test script based on the fault injection types in the current sequence of test cases. This may include:

[0123] If the fault injection type in the current sequence of test cases is a message fault injection type, then the corresponding fault injection method is determined to be a message fault injection method.

[0124] If the fault injection type carried by the test cases in the current sequence is message fault injection, then the corresponding fault injection method can be determined to be message fault injection. The message fault injection method can be to simulate a secondary controller fault and send it to the primary controller through a message, or to simulate a message fault of the primary controller through a message.

[0125] In another embodiment, sending corresponding set signals to the primary controller and the secondary controller respectively through an automated test script according to the fault injection method may include:

[0126] The automated test script generates fault message signals according to the message fault injection method, and uses the fault message signals as corresponding set signals to send the corresponding set signals to the primary controller and the secondary controller respectively.

[0127] The automated test script can execute fault diagnosis test procedures for multiple controllers according to the currently determined message fault injection method. In the specific implementation, the HIL simulation test system communicates with both the primary and secondary controllers. Therefore, the HIL simulation test system can send fault message signals through communication to achieve message fault injection. For example, the HIL simulation test system can generate fault message signals through the automated test script, so that the fault message signals can be used as the set signals corresponding to the message fault injection type. Then, the corresponding set signals can be sent to the primary and secondary controllers respectively, thereby completing the message fault injection.

[0128] After waiting for a preset fault trigger time, S230 sends a diagnostic request command to the primary controller via an automated test script.

[0129] The test cases in the current sequence also carry a preset fault trigger time. After sending the corresponding set signals to the primary controller and the secondary controller respectively, the HIL simulation test system can wait for the primary controller and / or the secondary controller to complete the fault code setting according to the preset fault trigger time. In order to ensure that the primary controller and / or the secondary controller completes the fault code setting, the HIL simulation test system can wait for a signal routing time on the basis of the preset fault trigger time. The signal routing time can be calculated in the HIL simulation test system.

[0130] After a fault is injected into the primary controller, an abnormal situation may occur. That is, the primary controller may experience a fault corresponding to the current fault injection type. When the primary controller recognizes the fault, it can set the fault code corresponding to the fault, that is, change the status of the fault code corresponding to the fault from 0 (inactive state) to 1 (active state), and then record the snapshot information corresponding to the fault. The primary controller can store the set fault code and snapshot information as fault information.

[0131] After a fault is injected into the secondary controller, an abnormal situation may occur. That is, the secondary controller may experience a fault corresponding to the current fault injection type. When the secondary controller recognizes the fault, it can set the fault code corresponding to the fault, that is, change the status of the fault code corresponding to the fault from 0 (inactive state) to 1 (active state), and then record the snapshot information corresponding to the fault. The secondary controller can use the set fault code and snapshot information as fault information and send it to the primary controller in the form of a fault message. After the primary controller recognizes the fault message from the secondary controller, it can store the fault information of the secondary controller.

[0132] After waiting for the preset fault trigger time and signal routing time, the HIL simulation test system can confirm that the primary controller and / or secondary controller have completed the fault code setting. Then, it can send a diagnostic request command to the primary controller through an automated test script. The diagnostic request command is used to request fault information.

[0133] S240 receives diagnostic response data returned by the primary controller in response to the diagnostic request command via an automated test script; wherein, the diagnostic response data includes fault information stored by the primary controller itself and / or fault information of the secondary controller stored by the primary controller.

[0134] After receiving a diagnostic request command, the primary controller can respond by returning diagnostic response data to the HIL simulation test system. The diagnostic response data may include fault information of the primary controller, or it may include fault information of the secondary controller, or it may include fault information of both the primary and secondary controllers.

[0135] Furthermore, after a fault is injected into the primary and secondary controllers, the fault tolerance mechanism or self-recovery mechanism may prevent abnormal situations from occurring. That is, the primary and secondary controllers may not experience the fault corresponding to the current fault injection type, and therefore the primary and secondary controllers may not have fault information.

[0136] To address this, the embodiments of this application can first determine whether a fault has occurred in the primary controller and the secondary controller after they have been injected with faults, i.e., whether a fault code has been read. Once a fault code is confirmed to have been read, the corresponding snapshot information is then read. Specifically, the diagnostic request instruction can include a fault code request instruction and a snapshot information request instruction. The HIL simulation test system can first send a fault code request instruction to the primary controller. If the primary controller stores its own fault code and / or stores the fault code of the secondary controller, the primary controller can respond to the fault code request instruction by returning fault code response data to the HIL simulation test system. The fault code response data can include the fault codes of the primary controller and / or the secondary controller, enabling the HIL simulation test system to read the fault codes. If the primary controller does not store its own fault code or the fault code of the secondary controller, the primary controller can respond to the fault code request instruction by returning a response message to the HIL simulation test system. The response message does not include the fault codes of either the primary or secondary controller, preventing the HIL simulation test system from reading the fault codes. Therefore, the automated test script does not need to send a snapshot information request instruction.

[0137] After reading the fault code, the HIL simulation test system sends a snapshot information request command to the primary controller. Since only one fault code's snapshot information is read at a time for the same test case, the HIL simulation test system can first determine the number of fault codes reported by the primary controller, and then generate a corresponding number of snapshot information request commands based on the number of fault codes.

[0138] If the Level 1 controller only reports a fault code (i.e., the fault code response data includes only the Level 1 controller's fault code or only the Level 2 controller's fault code), indicating that only the Level 1 controller or only the Level 2 controller has failed, the HIL simulation test system can generate a snapshot information request command. This command carries the fault code from the fault code response data and is then sent to the Level 1 controller. Upon receiving the snapshot information request command, the Level 1 controller can extract the fault code from it, search for the matching snapshot information in its stored fault information, and then return snapshot information response data to the HIL simulation test system. This snapshot information response data may include the snapshot information matching the fault code in the snapshot information request command.

[0139] If the primary controller reports two fault codes (i.e., the fault code response data includes both the primary and secondary controller fault codes), it indicates that both the primary and secondary controllers have failed. The HIL simulation test system can then generate two snapshot information request commands, such as Snapshot Information Request Command A and Snapshot Information Request Command B. Snapshot Information Request Command A can carry the primary controller's fault code, and Snapshot Information Request Command B can carry the secondary controller's fault code. The HIL simulation test system first sends Snapshot Information Request Command A to the primary controller. Upon receiving Snapshot Information Request Command A, the primary controller can extract the fault code from it, then search for the snapshot information matching the fault code in its stored fault information. It then returns Snapshot Information Response Data A to the HIL simulation test system. Snapshot Information Response Data A can include the snapshot information matching the fault code in Snapshot Information Request Command A; this snapshot information represents the snapshot information of the primary controller at the time of the fault. After receiving Snapshot Information Response Data A, the HIL simulation test system then sends Snapshot Information Request Command B to the primary controller. After receiving the snapshot information request instruction B, the primary controller can extract the fault code from the snapshot information request instruction B, then search for the snapshot information that matches the fault code from the stored fault information, and then return the snapshot information response data B to the HIL simulation test system. The snapshot information response data B may include the snapshot information that matches the fault code in the snapshot information request instruction B. This snapshot information is the snapshot information of the secondary controller when a fault occurs.

[0140] The S250 uses automated test scripts to parse diagnostic response data and obtain fault diagnosis test results.

[0141] In one example, when the diagnostic response data only includes fault information of the primary controller, the HIL simulation test system can parse the fault information of the primary controller through automated test scripts to obtain the fault diagnosis test results of the primary controller.

[0142] In another example, when the diagnostic response data only includes fault information of the secondary controller, the HIL simulation test system can parse the fault information of the secondary controller through automated test scripts to obtain the fault diagnosis test results of the secondary controller.

[0143] In another example, when the diagnostic response data includes fault information from both the primary controller and the secondary controller, the HIL simulation test system can use automated test scripts to parse the fault information from the primary controller and the secondary controller separately, thereby obtaining the fault diagnosis test results for both the primary and secondary controllers.

[0144] Furthermore, if no diagnostic response data is obtained, it indicates that neither the primary nor secondary controllers have malfunctioned, and this step is unnecessary.

[0145] In one embodiment, the method may further include:

[0146] Based on the diagnostic response data, the target controller that experienced an abnormal situation after being injected with a fault is identified from the primary and secondary controllers; a reset message is sent to the target controller via an automated test script to perform fault recovery on the target controller.

[0147] Fault recovery is an indispensable part of fault diagnosis and testing. It can ensure that the controller can quickly return to normal operation when abnormal conditions occur, thus ensuring the stability and reliability of the controller.

[0148] In response, if diagnostic response data is obtained, the HIL simulation test system can determine the target controller that sent the fault from the primary and secondary controllers based on the diagnostic response data. That is, it can determine the target controller that has an abnormal situation after the fault is injected, so that a reset message can be sent to the target controller through an automated test script. The reset message can be used to restore the target controller from the fault.

[0149] The reset information may include a reset signal and a clear operation command. The reset signal can be used to reset fault codes, and the clear operation command can be used to clear snapshot information.

[0150] In one example, when the diagnostic response data only includes fault information from the primary controller, it indicates that the primary controller has experienced an abnormal situation after being injected with a fault. In this case, the HIL simulation test system can identify the primary controller as the target controller and then send reset information to the primary controller through an automated test script. The reset information can include a reset signal and a clear operation command. In response to the reset signal, the target controller (i.e., the primary controller) can reset its own fault codes, that is, change the status of its own fault codes from 1 (active state) to 0 (inactive state). At the same time, in response to the clear operation command, it performs an aging operation or a $14 service clear operation. The aging operation is a specified number of power cycles, thereby clearing its own snapshot information.

[0151] In another example, when the diagnostic response data only includes fault information from the secondary controller, it indicates that the secondary controller has experienced an abnormal situation after being injected with a fault. The HIL simulation test system can then identify the secondary controller as the target controller and send reset information to it via an automated test script. This reset information can include a reset signal and a clear operation command. In response to the reset signal, the target controller (i.e., the secondary controller) can reset its own fault codes, changing their state from 1 (active) to 0 (inactive). Simultaneously, in response to the clear operation command, it performs an aging operation or a $14 service clear operation, thereby clearing its own snapshot information. After the primary controller recognizes the secondary controller's fault code reset, it can also reset the stored secondary controller fault codes. Similarly, if the primary controller recognizes the secondary controller's snapshot information being cleared, it can also clear the stored secondary controller snapshot information by performing an aging operation or a $14 service clear operation.

[0152] In another example, when the diagnostic response data includes fault information from both the primary and secondary controllers, it indicates that both the primary and secondary controllers are experiencing abnormal conditions simultaneously after being injected with faults. In this case, the HIL simulation test system can identify both the primary and secondary controllers as target controllers and then send reset information to both controllers separately via automated test scripts. This example is a comprehensive summary of the two examples above; the specific process can be found in the descriptions of the two examples above and will not be repeated here.

[0153] It should be noted that the embodiments of this application mainly target the first two bits of the fault code. After the reset signal is sent, the fault code will not immediately change from 1 to 0. The fault code still exists in the current ignition cycle and will only change from 1 to 0 in the next ignition cycle.

[0154] In one embodiment, the method may further include:

[0155] After waiting for the preset fault recovery time, determine the fault diagnosis test process for the test cases in the current sequence; use automated test scripts to re-initialize the first-level controller and the second-level controller, and execute the fault diagnosis test process for the next sequence of test cases until the fault diagnosis test process for the last sequence of test cases is completed.

[0156] The test cases in the current sequence also carry a preset fault recovery time. After sending reset information to the primary controller and / or secondary controller, the HIL simulation test system can wait for the primary controller and / or secondary controller to complete the fault code reset and snapshot information clearing according to the preset fault recovery time. In order to ensure that the primary controller and / or secondary controller complete the fault code setting and snapshot information clearing, the HIL simulation test system can wait for a signal routing time in addition to the preset fault recovery time.

[0157] After waiting for the preset fault recovery time and signal routing time, the HIL simulation test system confirms that the primary controller and / or secondary controller have completed the fault code reset and snapshot information clearing. At this point, it can be determined that the fault diagnosis test process of the current sequence of test cases has been completed, thus ending the fault diagnosis test process of the current sequence of test cases. Then, it returns to step S220 so that the primary controller and secondary controller can be initialized again by the automated test script, and then the fault diagnosis test process of the next sequence of test cases is executed until the fault diagnosis test process of the last sequence of test cases is completed.

[0158] In addition, to ensure that both the primary and secondary controllers can recover from faults, the HIL simulation test system can send a diagnostic request command to the primary controller again after waiting for the preset fault recovery time and signal routing time. Then, it can receive the diagnostic response data returned by the primary controller in response to the diagnostic request command again. If the fault code in the received diagnostic response data is 0 and does not contain snapshot information, it can be confirmed that the primary controller and / or the secondary controller have completed the fault code reset and snapshot information clearing.

[0159] As can be seen from this example, the solution provided in this application, by converting test cases into automated test scripts, executes the controller fault diagnosis test process entirely through automated test scripts, eliminating the need for manual operation. This improves the efficiency and accuracy of fault diagnosis testing, thereby greatly reducing labor and time costs.

[0160] Furthermore, the solution provided in this application can perform fault diagnosis operations on multiple controllers (e.g., primary controllers and secondary controllers) simultaneously, which can further improve the efficiency of fault diagnosis testing and thus greatly reduce time costs.

[0161] Furthermore, the solution provided in this application covers model fault injection types, electrical fault injection types, and message fault injection types, thereby improving the test coverage of fault diagnosis functions.

[0162] To enable those skilled in the art to better understand the embodiments of this application, the embodiments of this application are illustrated below through the following four examples.

[0163] Example 1: Figure 3 This is a complete flowchart of controller fault diagnosis testing, which can be executed by the HIL simulation test system, specifically by the automated diagnostic software within the HIL simulation test system. The complete process is as follows:

[0164] S1, Initialization, which is to initialize the automated diagnostic software; the automated diagnostic software integrates automated testing tools such as test case generation tools, test script generation tools, Veristand control reading and writing tools, and EFI fault injection tools.

[0165] S2, obtain the diagnostic table; the diagnostic table includes various fault injection types and test information; among them, the various fault injection types are model fault injection type, electrical fault injection type and message fault injection type, and the test information includes fault type, tested object, preset fault trigger time and preset fault recovery time.

[0166] S3 invokes the test case generation tool.

[0167] S4. Using a test case generation tool, construct test case rules based on the fault type, the object under test, the preset fault trigger time, and the preset fault recovery time; parse the diagnostic table according to the test case rules to obtain multiple test cases; each of the multiple test cases includes a fault injection type.

[0168] S5 calls the test script generation tool.

[0169] S6 uses a test script generation tool to convert multiple test cases into test scripts (i.e., automated test scripts).

[0170] S7 executes multiple test cases sequentially using a test script. See the following steps for details:

[0171] S8, Initialize the controller; the controller includes a primary controller and a secondary controller.

[0172] S9. Determine whether it is the current diagnostic function, that is, whether it is the test case in the current sequence; if yes, proceed to step S10; if no, return to step S8.

[0173] S10, if it is determined to be the current diagnostic function, then determine the fault action of the current diagnostic function; the fault action includes setting and resetting. The same test case needs to execute the two fault actions of setting and resetting in sequence. Therefore, when it is determined that the fault action of the current diagnostic function is setting, then proceed to step S11; when it is determined that the fault action of the current diagnostic function is resetting, then proceed to step S18.

[0174] S11, when it is determined that the fault action of the current diagnostic function is set, the fault type of the current diagnostic function is determined, that is, the fault injection type carried by the test cases in the current sequence is determined.

[0175] S12, if the fault type of the current diagnostic function is the model fault injection type, then call the Veristand control read / write tool, which can be the controller model control, and proceed to step S15.

[0176] S13. If the fault type of the current diagnostic function is electrical fault injection type, then call the EFI fault injection tool, which can be an EFI fault injection board, and proceed to step S15.

[0177] S14. If the fault type of the current diagnostic function is message fault injection, proceed directly to step S15.

[0178] S15, execute fault setting, the specific steps are S16.

[0179] S16. The corresponding fault signals are injected into the primary controller and the secondary controller through model fault injection, electrical fault injection, or message fault injection, respectively. The fault signals are the set signals.

[0180] S17, wait for the controller fault to be set. During this period, if the primary controller recognizes the fault after being injected with a fault, it will complete the fault code setting. If the secondary controller recognizes the fault after being injected with a fault, it will complete the fault code setting. After waiting for the primary controller and / or the secondary controller to complete the fault code setting, proceed to step S25.

[0181] S18, when it is determined that the fault action of the current diagnostic function is reset, the fault type of the current diagnostic function is determined, that is, the fault injection type carried by the test cases in the current sequence is determined.

[0182] S19, if the fault type of the current diagnostic function is the model fault injection type, then call the Veristand control read / write tool, which can be the controller model control, and proceed to step S21.

[0183] S20. If the fault type of the current diagnostic function is electrical fault injection type, then call the EFI fault injection tool, which can be an EFI fault injection board, and proceed to step S21.

[0184] S21. If the fault type of the current diagnostic function is message fault injection, then proceed directly to step S21.

[0185] S22, perform fault recovery, the specific steps are S23.

[0186] S23, inject reset information into the primary controller and / or secondary controller through model fault injection, electrical fault injection, or message fault injection. The reset information includes a reset signal and a clear operation command. The reset signal is used to reset the fault code, and the clear operation command is used to instruct the primary controller and / or secondary controller to clear the snapshot information through aging operation or $14 service clear operation.

[0187] S24, wait for the controller to reset. During this period, if the primary controller has a fault, the fault code will be reset and the snapshot information will be cleared. If the secondary controller has a fault, the fault code will be reset and the snapshot information will be cleared. After waiting for the primary controller and / or the secondary controller to complete the fault code reset and snapshot information clearing, proceed to step S25.

[0188] S25 sends a diagnostic request command to the primary controller.

[0189] S26, receive diagnostic response data returned by the primary controller in response to the diagnostic request command; wherein, the diagnostic response data includes fault information stored by the primary controller itself and / or fault information of the secondary controller stored by the primary controller.

[0190] S27, determine the fault information.

[0191] S28, Output the results, specifically the fault diagnosis test results of the controller (primary controller and / or secondary controller). The fault diagnosis test results corresponding to setting can include fault codes of 1 and snapshot information, and the fault diagnosis test results corresponding to resetting can include fault codes of 0. End the fault diagnosis test process of the current sequence of test cases to start the fault diagnosis test process of the next sequence of test cases, and then return to step S9.

[0192] S29. Once all test cases have been executed, the test is considered complete.

[0193] Example 2: Figure 4 This is a flowchart of the fault diagnosis test for multiple controllers using a model fault injection method. The specific process is as follows:

[0194] After parsing test cases, the automated diagnostic software injects faults into both the primary and secondary controllers using a model fault injection method. Specifically, it uses the simulated physical values ​​of the controller model controls as corresponding set signals, which are then sent to both the primary and secondary controllers to complete the model fault injection. Upon detecting a fault, the primary controller sets the corresponding fault code and records a snapshot of the fault, storing both the fault code and snapshot information as fault information. Similarly, the secondary controller sets the corresponding fault code and records a snapshot of the fault, also storing both as fault information. This fault information is then communicated to the primary sensor via a fault message. The primary sensor, upon receiving the secondary controller's fault message, stores the secondary controller's fault information. After both the primary and secondary controllers have completed setting the fault codes, the automated diagnostic software sends a diagnostic request command to the primary controller, requesting the fault code and snapshot information. Upon receiving the diagnostic request command, the primary controller responds with diagnostic response data. The automated diagnostic software then analyzes this data to determine the fault diagnosis test results.

[0195] Example 3: Figure 5 This is a fault diagnosis test flowchart for multiple controllers' electrical fault injection methods. The specific process is as follows:

[0196] After parsing test cases, the automated diagnostic software injects faults into both the primary and secondary controllers via electrical fault injection. Specifically, this is achieved by controlling the on / off state of the EFI fault injection board's interface, generating corresponding set signals, which are then sent to both the primary and secondary controllers to complete the electrical fault injection. Upon detecting a fault, the primary controller sets the corresponding fault code and records a snapshot of the fault, storing both the fault code and snapshot information as fault information. Similarly, the secondary controller sets the corresponding fault code and records the snapshot information, also storing both as fault information. This fault information is then communicated to the primary sensor via a fault message. The primary sensor, upon receiving the secondary controller's fault message, stores the secondary controller's fault information. Once both the primary and secondary controllers have set their fault codes, the automated diagnostic software sends a diagnostic request command to the primary controller, requesting the fault code and snapshot information. Upon receiving the diagnostic request command, the primary controller responds with diagnostic response data. The automated diagnostic software then analyzes this data to determine the fault diagnosis test results.

[0197] Example 4: Figure 6 This is a flowchart of the fault diagnosis test for multiple controllers using message fault injection methods. The specific process is as follows:

[0198] After parsing test cases, the automated diagnostic software injects faults into both the primary and secondary controllers via message-based fault injection. Specifically, it generates a fault message signal, uses this signal as a corresponding set signal, and sends it to both controllers. Upon detecting a fault, the primary controller sets the corresponding fault code and records a snapshot of the fault, storing both the fault code and snapshot information as fault information. Similarly, the secondary controller sets the corresponding fault code and records a snapshot of the fault, then notifies the primary sensor of the fault information via a fault message. The primary sensor, upon receiving the secondary controller's fault message, stores the secondary controller's fault information. Once both controllers have set their fault codes, the automated diagnostic software sends a diagnostic request command to the primary controller, requesting the fault code and snapshot information. The primary controller responds with diagnostic response data, which the automated diagnostic software then analyzes to determine the fault diagnosis test results.

[0199] Corresponding to the aforementioned application function implementation method embodiments, this application also provides a controller fault diagnosis test device and electronic device, and corresponding embodiments thereof.

[0200] Figure 7 This is a schematic diagram of the controller fault diagnosis and testing device shown in the embodiments of this application.

[0201] See Figure 7 This application provides a controller fault diagnosis and testing device, which may include:

[0202] The test case acquisition module 710 is used to acquire test cases and convert them into automated test scripts; among them, the test cases include fault injection types;

[0203] The fault injection module 720 is used to inject faults of the corresponding fault injection type into the controller through automated test scripts.

[0204] The fault information acquisition module 730 is used to acquire fault information stored in the controller through automated test scripts; the fault information is used to characterize the abnormal situation that occurs in the controller after a fault is injected.

[0205] The fault information parsing module 740 is used to parse fault information through automated test scripts to obtain fault diagnosis test results.

[0206] In one embodiment, the controller includes a primary controller and a secondary controller; the fault injection module 720 may include:

[0207] The fault injection submodule is used to inject faults of the corresponding fault injection types into the primary controller and the secondary controller respectively through automated test scripts; wherein, the fault injection type includes any one of the model fault injection type, electrical fault injection type and message fault injection type.

[0208] In one embodiment, the fault information acquisition module 830 may include:

[0209] The diagnostic request instruction sending submodule is used to send a diagnostic request instruction to the primary controller via an automated test script after waiting for a preset fault trigger time.

[0210] The diagnostic response data receiving submodule is used to receive diagnostic response data returned by the primary controller in response to diagnostic request instructions through an automated test script; wherein, the diagnostic response data includes fault information stored by the primary controller itself and / or fault information of the secondary controller stored by the primary controller.

[0211] In one embodiment, the test case acquisition module 710 may include:

[0212] The diagnostic table acquisition submodule is used to acquire diagnostic tables; the diagnostic tables include various fault injection types; among them, the various fault injection types are model fault injection type, electrical fault injection type and message fault injection type;

[0213] The rule building submodule is used to build test case rules;

[0214] The diagnostic table parsing submodule is used to parse the diagnostic table according to the test case rules to obtain multiple test cases; wherein each of the multiple test cases includes a fault injection type;

[0215] The test case conversion submodule is used to convert multiple test cases into automated test scripts.

[0216] In one embodiment, the fault injection submodule may include:

[0217] The initialization unit is used to initialize the primary controller and the secondary controller respectively using automated test scripts;

[0218] The fault injection unit is used to inject faults corresponding to the fault injection type in the test cases of the current sequence into the primary controller and the secondary controller respectively through automated test scripts.

[0219] In one embodiment, the fault injection unit may include:

[0220] The fault injection method determination subunit is used to determine the corresponding fault injection method based on the fault injection type in the test cases in the current sequence through automated test scripts;

[0221] The set signal sending subunit is used to send corresponding set signals to the primary controller and the secondary controller respectively according to the fault injection method through the automated test script; wherein, the set signal is used to inject the corresponding fault into the primary controller and the secondary controller.

[0222] In one embodiment, the fault injection method determination subunit can be specifically used for:

[0223] If the fault injection type in the current sequence of test cases is the model fault injection type, then the corresponding fault injection method is determined to be the model fault injection method.

[0224] In one embodiment, the set signal transmitting subunit may be specifically used for:

[0225] The controller model controls are invoked using automated test scripts according to the model fault injection method;

[0226] The automated test script uses the physical values ​​of the controller model control simulation as the corresponding set signals and sends the corresponding set signals to the primary controller and the secondary controller respectively.

[0227] In another embodiment, the fault injection method determination subunit can be specifically used for:

[0228] If the fault injection type in the current sequence of test cases is electrical fault injection, then the corresponding fault injection method is determined to be electrical fault injection method.

[0229] In another embodiment, the set signal transmitting subunit can be specifically used for:

[0230] The EFI fault injection board is invoked using an automated test script according to the electrical fault injection method; the EFI fault injection board is connected to the primary controller and the secondary controller respectively via wiring harnesses.

[0231] The automated test script controls the on / off state of the interface of the EFI fault injection board to generate corresponding set signals, which are then sent to the primary controller and the secondary controller via wiring harnesses.

[0232] In yet another embodiment, the fault injection method determination subunit can be specifically used for:

[0233] If the fault injection type in the current sequence of test cases is a message fault injection type, then the corresponding fault injection method is determined to be a message fault injection method.

[0234] In yet another embodiment, the set signal transmitting subunit can be specifically used for:

[0235] The automated test script generates fault message signals according to the message fault injection method, and uses the fault message signals as corresponding set signals to send the corresponding set signals to the primary controller and the secondary controller respectively.

[0236] In one embodiment, the device may further include:

[0237] The target controller determination module is used to determine the target controller that has experienced an abnormal situation after being injected with a fault from the primary controller and the secondary controller based on the diagnostic response data.

[0238] The fault recovery module is used to send reset information to the target controller via automated test scripts in order to recover the target controller from faults.

[0239] In one embodiment, the device may further include:

[0240] The current fault diagnosis test process end module is used to determine the fault diagnosis test process to complete the test cases in the current sequence after waiting for the preset fault recovery time.

[0241] The next fault diagnosis test process initiation module is used to re-initialize the primary controller and the secondary controller through automated test scripts, and execute the fault diagnosis test process of the next sequence of test cases until the fault diagnosis test process of the last sequence of test cases is completed.

[0242] As this example demonstrates, the solution provided in this application involves acquiring test cases and converting them into automated test scripts. The test cases include fault injection types. The automated test scripts inject the corresponding faults into the controller. The automated test scripts then retrieve the fault information stored in the controller. This fault information characterizes the abnormal conditions that occur in the controller after the fault is injected. Finally, the automated test scripts parse the fault information to obtain the fault diagnosis test results. By converting test cases into automated test scripts, which then execute the entire controller fault diagnosis test process, this application eliminates the need for manual operation, thereby improving the efficiency and accuracy of fault diagnosis testing and significantly reducing labor and time costs.

[0243] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated further here.

[0244] Figure 8 This is a schematic diagram of the structure of an electronic device shown in an embodiment of this application.

[0245] See Figure 8 The electronic device 800 includes a memory 810 and a processor 820.

[0246] The processor 820 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0247] Memory 810 may include various types of storage units, such as system memory, read-only memory (ROM), and permanent storage devices. ROM may store static data or instructions required by the processor 820 or other modules of the computer. Permanent storage devices may be read-write storage devices. Permanent storage devices may be non-volatile storage devices that retain stored instructions and data even when the computer is powered off. In some embodiments, permanent storage devices use mass storage devices (e.g., magnetic or optical disks, flash memory) as permanent storage devices. In other embodiments, permanent storage devices may be removable storage devices (e.g., floppy disks, optical drives). System memory may be a read-write storage device or a volatile read-write storage device, such as dynamic random access memory. System memory may store some or all of the instructions and data required by the processor during operation. Furthermore, memory 810 may include any combination of computer-readable storage media, including various types of semiconductor memory chips (e.g., DRAM, SRAM, SDRAM, flash memory, programmable read-only memory), and disks and / or optical disks may also be used. In some embodiments, memory 810 may include a removable storage device that is readable and / or writable, such as a laser disc (CD), a read-only digital multifunction optical disc (e.g., DVD-ROM, dual-layer DVD-ROM), a read-only Blu-ray disc, a high-density optical disc, a flash memory card (e.g., SD card, mini SD card, Micro-SD card, etc.), a magnetic floppy disk, etc. Computer-readable storage media do not contain carrier waves or transient electronic signals transmitted wirelessly or via wired connections.

[0248] The memory 810 stores executable code, which, when processed by the processor 820, can cause the processor 820 to execute part or all of the methods described above.

[0249] In addition, the method according to this application can also be implemented as a computer program or computer program product, which includes computer program code instructions for performing some or all of the steps in the method described above.

[0250] Alternatively, this application may also be implemented as a computer-readable storage medium (or a non-transitory machine-readable storage medium or a machine-readable storage medium) storing executable code (or computer program or computer instruction code) thereon, which, when executed by a processor of an electronic device, causes the processor to perform part or all of the steps of the methods described above according to this application.

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

Claims

1. A controller fault diagnosis and testing method, characterized in that, include: Obtain test cases and convert them into automated test scripts; wherein, the test cases include fault injection types; The automated test script injects the fault corresponding to the fault injection type into the controller. The automated test script obtains the fault information stored in the controller; the fault information is used to characterize the abnormal situation that occurs in the controller after the fault is injected. The fault information is parsed using the automated test script to obtain fault diagnosis test results; The controller includes a primary controller and a secondary controller; the process of injecting the fault corresponding to the fault injection type into the controller via the automated test script includes: The automated test script injects faults of the specified fault injection type into the primary controller and the secondary controller respectively; wherein, the fault injection type includes any one of the following: model fault injection type, electrical fault injection type, and message fault injection type. The step of obtaining the fault information stored in the controller through the automated test script includes: After waiting for the preset fault trigger time, a diagnostic request instruction is sent to the primary controller through the automated test script; The automated test script receives diagnostic response data returned by the primary controller in response to the diagnostic request instruction; wherein the diagnostic response data includes fault information stored by the primary controller itself and / or fault information of the secondary controller stored by the primary controller.

2. The method according to claim 1, characterized in that, The process of obtaining test cases and converting them into automated test scripts includes: Obtain the diagnostic table; the diagnostic table includes multiple fault injection types; wherein, the multiple fault injection types are the model fault injection type, the electrical fault injection type, and the message fault injection type; Build test case rules; The diagnostic table is parsed according to the test case rules to obtain multiple test cases; each of the multiple test cases includes one of the fault injection types. The test cases are converted into automated test scripts.

3. The method according to claim 2, characterized in that, The step of injecting faults of the fault injection type into the primary controller and the secondary controller respectively through the automated test script includes: The automated test script is used to initialize the primary controller and the secondary controller respectively. The automated test script injects faults corresponding to the fault injection types in the test cases of the current sequence into the primary controller and the secondary controller, respectively.

4. The method according to claim 3, characterized in that, The step of injecting faults of the fault injection type corresponding to the current sequence of test cases into the primary controller and the secondary controller respectively through the automated test script includes: The automated test script determines the corresponding fault injection method based on the fault injection type in the test cases in the current order. The automated test script sends corresponding set signals to the primary controller and the secondary controller according to the fault injection method; wherein the set signals are used to inject corresponding faults into the primary controller and the secondary controller.

5. The method according to claim 4, characterized in that, The step of determining the corresponding fault injection method based on the fault injection type in the current sequence of test cases using the automated test script includes: If the fault injection type in the test cases in the current sequence is the model fault injection type, then the corresponding fault injection method is determined to be the model fault injection method. The step of sending corresponding set signals to the primary controller and the secondary controller respectively through the automated test script according to the fault injection method includes: The automated test script calls the controller model controls according to the model fault injection method. The automated test script uses the physical values ​​simulated by the controller model controls as corresponding set signals and sends these set signals to the primary controller and the secondary controller, respectively.

6. The method according to claim 4, characterized in that, The step of determining the corresponding fault injection method based on the fault injection type in the current sequence of test cases using the automated test script includes: If the fault injection type in the current sequence of test cases is the electrical fault injection type, then the corresponding fault injection method is determined to be the electrical fault injection method. The step of sending corresponding set signals to the primary controller and the secondary controller respectively through the automated test script according to the fault injection method includes: The automated test script calls the electrical fault injection EFI fault injection board according to the electrical fault injection method; the EFI fault injection board is connected to the primary controller and the secondary controller respectively via wiring harnesses; The automated test script controls the on / off state of the interface of the EFI fault injection board to generate a corresponding set signal, and sends the corresponding set signal to the primary controller and the secondary controller respectively through the wiring harness.

7. The method according to claim 4, characterized in that, The step of determining the corresponding fault injection method based on the fault injection type in the current sequence of test cases using the automated test script includes: If the fault injection type in the test cases in the current sequence is the message fault injection type, then the corresponding fault injection method is determined to be the message fault injection method. The step of sending corresponding set signals to the primary controller and the secondary controller respectively through the automated test script according to the fault injection method includes: The automated test script generates a fault message signal according to the message fault injection method, and uses the fault message signal as the corresponding set signal, and sends the corresponding set signal to the first-level controller and the second-level controller respectively.

8. The method according to claim 4, characterized in that, The method further includes: Based on the diagnostic response data, the target controller that exhibits abnormal behavior after the fault is injected is determined from the primary controller and the secondary controller; The automated test script sends a reset message to the target controller to perform fault recovery on the target controller.

9. The method according to claim 8, characterized in that, The method further includes: After waiting for the preset fault recovery time, determine the completion of the fault diagnosis test process for the test cases in the current sequence; The automated test script re-initializes the primary controller and the secondary controller, and executes the fault diagnosis test process for the next sequence of test cases until the fault diagnosis test process for the last sequence of test cases is completed.

10. A controller fault diagnosis and testing device, characterized in that, include: A test case acquisition module is used to acquire test cases and convert them into automated test scripts; wherein, the test cases include fault injection types; The fault injection module is used to inject the fault corresponding to the fault injection type into the controller through the automated test script; The fault information acquisition module is used to acquire the fault information stored in the controller through the automated test script; the fault information is used to characterize the abnormal situation that occurs in the controller after the fault is injected. The fault information parsing module is used to parse the fault information through the automated test script to obtain fault diagnosis test results; The controller includes a primary controller and a secondary controller; the fault injection module includes: The fault injection submodule is used to inject faults corresponding to the fault injection type into the primary controller and the secondary controller respectively through the automated test script; wherein, the fault injection type includes any one of the model fault injection type, electrical fault injection type and message fault injection type; The fault information acquisition module includes: The diagnostic request instruction sending submodule is used to send a diagnostic request instruction to the first-level controller through the automated test script after waiting for a preset fault trigger time. The diagnostic response data receiving submodule is used to receive diagnostic response data returned by the primary controller in response to the diagnostic request instruction through the automated test script; wherein, the diagnostic response data includes the primary controller's own fault information and / or the primary controller's fault information of the secondary controller.

11. An electronic device, characterized in that, include: processor; as well as A memory having executable code stored thereon, which, when executed by the processor, causes the processor to perform the method as described in any one of claims 1-9.

Images