Controller fault diagnosis test method and device and electronic equipment

Abstract

The invention relates to a controller fault diagnosis test method and device and electronic equipment. The method comprises the following steps: acquiring 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 the 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 an abnormal condition of the controller after the fault is injected; and analyzing the fault information through the automatic test script to obtain a fault diagnosis test result. According to the scheme provided by the invention, the fault diagnosis test of the controller can be automatically completed without manual operation, and the efficiency and accuracy of the fault diagnosis test can be improved, so that the labor cost and the time cost are greatly reduced.

Description

Technical Field

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

[0002] Fault diagnosis testing at the vehicle controller software level can help testers discover and solve potential problems in the software in simulated actual scenarios, which can effectively reduce the failure rate of the controller during subsequent use, thereby improving controller reliability and enhancing user satisfaction.

[0003] In the fault diagnosis test of the vehicle controller software level of the related technology, at the software operation level, most of them are still based on the tester manually sending fault data; at the hardware level, the tester is also required to manually unplug and plug the wiring harness and other operations to complete the fault injection, which will undoubtedly greatly consume labor costs and time costs. Summary of the invention

[0004] In order to solve or partially solve the problems existing in the related art, 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, and can improve the efficiency and accuracy of the fault diagnosis test, thereby greatly reducing labor costs and time costs.

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

[0006] Acquire a test case and convert the test case into an automated test script; wherein the test case includes a fault injection type;

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

[0008] Acquiring fault information stored in the controller through the automated test script; the fault information is used to characterize an abnormal situation that occurs after the controller is injected with the fault;

[0009] The fault information is parsed through the automated test script to obtain a fault diagnosis test result.

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

[0011] The fault corresponding to the fault injection type is injected into the primary controller and the secondary controller respectively through the automated test script; wherein the fault injection type includes any one of a model fault injection type, an electrical fault injection type and a message fault injection type.

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

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

[0014] The diagnostic response data returned by the primary controller in response to the diagnostic request instruction is received through the automated test script; wherein the diagnostic response data includes the primary controller's own fault information stored therein and / or the secondary controller's fault information stored therein.

[0015] In one embodiment, obtaining a test case and converting the test case into an automated test script includes:

[0016] Obtain a 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] Parsing the diagnostic table according to the test case rules to obtain a plurality of test cases; wherein each of the plurality of test cases includes a type of fault injection;

[0019] Convert the plurality of test cases 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] Initialize the primary controller and the secondary controller respectively by using the automated test script;

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

[0023] In one embodiment, injecting the faults corresponding to the fault injection types in the test cases in the current order into the primary controller and the secondary controller respectively through the automated test script includes:

[0024] Determine the corresponding fault injection method according to the fault injection type in the test case in the current order through the automated test script;

[0025] The automated test script sends corresponding set signals to the primary controller and the secondary controller respectively according to the fault injection method; wherein the set signals are used to inject corresponding faults into the primary controller and the secondary controller.

[0026] In one embodiment, determining the corresponding fault injection method according to the fault injection type in the test case in the current order through the automated test script includes:

[0027] If the fault injection type in the test case in the current order is the model fault injection type, determining the corresponding fault injection method to be the model fault injection method;

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

[0029] Calling the controller model control according to the model fault injection method through the automated test script;

[0030] The physical value simulated by the controller model control is used as a corresponding set signal through the automated test script, and the corresponding set signal is sent to the primary controller and the secondary controller respectively.

[0031] In another embodiment, determining the corresponding fault injection method according to the fault injection type in the test case in the current order through the automated test script includes:

[0032] If the fault injection type in the test case in the current sequence is the electrical fault injection type, determining that the corresponding fault injection method is the electrical fault injection method;

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

[0034] Calling an electrical fault injection EFI fault injection board card according to the electrical fault injection method through the automated test script; the EFI fault injection board card is connected to the primary controller and the secondary controller respectively through a wiring harness;

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

[0036] In another embodiment, determining the corresponding fault injection method according to the fault injection type in the test case in the current order through the automated test script includes:

[0037] If the fault injection type in the test case in the current order is the message fault injection type, determining that the corresponding fault injection mode is the message fault injection mode;

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

[0039] A fault message signal is generated by the automated test script according to the message fault injection method, so that the fault message signal is used as a corresponding set signal, and the corresponding set signal is sent to the primary controller and the secondary controller respectively.

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

[0041] According to the diagnostic response data, determining a target controller from the primary controller and the secondary controller that has an abnormal condition after the fault is injected;

[0042] Reset information is sent to the target controller through the automated test script to perform fault recovery on the target controller.

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

[0044] After waiting for a preset fault recovery time, determining to complete the fault diagnosis test process of the test cases in the current order;

[0045] The primary controller and the secondary controller are respectively initialized again through the automated test script, and the fault diagnosis test process of the test case in the next sequence is executed until the fault diagnosis test process of the test case in the last sequence is completed.

[0046] A second aspect of the present application provides a controller fault diagnosis test device, comprising:

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

[0048] A fault injection module, used to inject a fault corresponding to the fault injection type into the controller through the automated test script;

[0049] A fault information acquisition module, 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 after the controller is injected with the fault;

[0050] The fault information analysis module is used to analyze the fault information through the automated test script to obtain a fault diagnosis test result.

[0051] A third aspect of the present application provides an electronic device, including:

[0052] Processor; and

[0053] The memory stores executable codes thereon, and when the executable codes are executed by the processor, the processor is caused to execute the method as described above.

[0054] The technical solution provided by this application may have the following beneficial effects:

[0055] The solution provided by the present application obtains test cases and converts the test cases into automated test scripts; wherein the test cases include fault injection types; the fault corresponding to the fault injection type is injected into the controller through the automated test script; the fault information stored in the controller is obtained through the automated test script; the fault information is used to characterize the abnormal situation that occurs after the controller is injected with the fault; the fault information is parsed through the automated test script to obtain the fault diagnosis test result. The present application converts the test cases into automated test scripts, and the automated test scripts execute the controller fault diagnosis test process throughout the process without manual operation, which can improve the efficiency and accuracy of the fault diagnosis test, thereby greatly reducing the labor cost and time cost.

[0056] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0058] Figure 1 It is a flowchart of a controller fault diagnosis test method shown in an embodiment of the present application;

[0059] Figure 2is another flow chart of a controller fault diagnosis test method shown in an embodiment of the present application;

[0060] Figure 3 is a full flow chart of the controller fault diagnosis test shown in the embodiment of the present application;

[0061] Figure 4 is a fault diagnosis test flow chart of a model fault injection method for multiple controllers shown in an embodiment of the present application;

[0062] Figure 5 is a fault diagnosis test flow chart of an electrical fault injection method for multiple controllers shown in an embodiment of the present application;

[0063] Figure 6 It is a fault diagnosis test flow chart of a message fault injection method of multiple controllers shown in an embodiment of the present application;

[0064] Figure 7 is a schematic diagram of the structure of a controller fault diagnosis and testing device shown in an embodiment of the present application;

[0065] Figure 8 It is a schematic diagram of the structure of an electronic device shown in an embodiment of the present application. DETAILED DESCRIPTION

[0066] The embodiments of the present application will be described in more detail below with reference to the accompanying drawings. Although the embodiments of the present application are shown in the accompanying drawings, it should be understood that the present application can be implemented in various forms and should not be limited by the embodiments described herein. On the contrary, these embodiments are provided to make the present application more thorough and complete, and to fully convey the scope of the present application to those skilled in the art.

[0067] The terms used in this application are for the purpose of describing specific embodiments only and are not intended to limit this application. The singular forms of "a", "said" and "the" used in this application and the appended claims are also intended to include plural forms unless the context clearly indicates other meanings. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more 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 the same type of information from each other. For example, without departing from the scope of this application, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Thus, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. In the description of this application, the meaning of "multiple" is two or more, unless otherwise clearly and specifically defined.

[0069] In the fault diagnosis test of the vehicle controller software level of the related technology, at the software operation level, most of them are still based on the tester manually sending fault data; at the hardware level, the tester is also required to manually unplug and plug the wiring harness and other operations to complete the fault injection, which will undoubtedly greatly consume labor costs and time costs.

[0070] In response to the above problems, an embodiment of the present application provides a controller fault diagnosis test method. By converting test cases into automated test scripts, the automated test scripts execute the entire controller fault diagnosis test process without the need for manual operation. This can improve the efficiency and accuracy of fault diagnosis testing, thereby greatly reducing labor costs and time costs.

[0071] The technical solution of the embodiments of the present application is described in detail below with reference to the accompanying drawings.

[0072] Figure 1 It is a flow chart of a controller fault diagnosis test method shown in an embodiment of the present application.

[0073] See also Figure 1 , the controller fault diagnosis test method of the present application comprises:

[0074] S110, obtaining a test case, and converting the test case into an automated test script; wherein the test case includes a fault injection type.

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

[0076] It should be noted that the automated diagnostic software is used in the HIL test phase, so the embodiment of the present application does not involve the vehicle diagnostic function. In other words, in the HIL test phase, the HIL simulation test system does not need to communicate with the vehicle, but uses the automated diagnostic software to directly perform fault diagnosis tests on independent controllers. When the controller passes the fault diagnosis test, if other functions of the controller are normal except for the diagnostic function, the controller can be delivered to the downstream, for example, the controller can be installed on a bare vehicle or LabCAR (experimental vehicle) or other test benches or a vehicle.

[0077] The HIL simulation test system is configured with a HIL simulation test environment. The HIL simulation test environment supports the joint calling of multiple controllers. Steps S110 to S140 are mainly described by taking a single controller as an example, and steps S210 to S250 are mainly described by taking multiple controllers as an example.

[0078] The automated diagnostic software in the HIL simulation test system integrates a variety of automated test tools, which may include test case generation tools, test script generation tools, Veristand (prototype verification system software) control reading and writing tools, EFI (Electric Failure Insert, electrical fault injection) fault injection tools, etc. The HIL simulation test system can call the test case generation tool and the test script generation tool, and the test case generation tool can be used to automatically generate test cases, and then the test script generation tool can be used to automatically convert the test cases into automated test scripts. Among them, the test case refers to a description document of the test task for the corresponding fault, such as the test target, test environment, test steps, etc. An automated test script is a computer program that consists of a series of codes that can be automatically executed, so it can realize the automated execution of test cases.

[0079] The test case may carry a corresponding fault injection type, and the fault injection type may be used to indicate the type of fault injected into the controller.

[0080] S120, injecting a fault corresponding to the fault injection type into the controller through an automated test script.

[0081] Fault injection is a crucial part of fault diagnosis testing. It simulates various fault scenarios that may occur in the actual operation of the controller by injecting various faults into the controller, so as to fully understand the performance of the controller under various fault scenarios, verify the effectiveness of the controller's fault tolerance mechanism and self-recovery mechanism, and promptly discover potential problems in the controller during the HIL testing phase, thereby evaluating the stability and reliability of the controller.

[0082] In an embodiment of the present application, the fault injection type may include at least one of a model fault injection type, an electrical fault injection type, and a message fault injection type, wherein a test case carries only one fault injection type, and therefore the test case acquired by the HIL simulation test system may include at least one, and the HIL simulation test system may execute at least one test case in sequence through an automated test script. Specifically, the HIL simulation test system may first extract the fault injection type from the test cases in the current sequence, and then inject the fault corresponding to the fault injection type into the controller through an automated test script.

[0083] S130, obtaining fault information stored in the controller through an automated test script; the fault information is used to characterize an abnormal situation that occurs after the controller is injected with a fault.

[0084] After a fault is injected into the controller, an abnormal situation may occur, that is, the controller may have a fault corresponding to the fault injection type. When the controller recognizes a fault, it can store the corresponding fault information. The HIL simulation test system can automatically obtain the fault information stored in the controller through an automated test script. The fault information can be used to understand the abnormal situation that occurs in the controller after the fault is injected.

[0085] In addition, after a fault is injected into the controller, the controller may not experience abnormal situations due to its fault tolerance mechanism or self-recovery mechanism, that is, the controller may not experience a fault corresponding to the fault injection type, so the controller may not have fault information.

[0086] S140, analyzing the fault information through an automated test script to obtain a fault diagnosis test result.

[0087] Among them, fault information can include fault codes and snapshot information. Fault codes are also called diagnostic trouble codes (DTCs), which can help users quickly locate and solve fault problems in the controller. Snapshot information is used to record the state information of the controller when a fault occurs. This information is similar to taking a photo, which can preserve the state of the controller when a fault occurs, helping users analyze the cause of the fault and reproduce the fault. Therefore, the HIL simulation test system can quickly obtain the fault diagnosis test results of the controller by parsing the fault information through automated test scripts.

[0088] As can be seen from this example, the solution provided by the present application obtains test cases and converts the test cases into automated test scripts; wherein the test cases include fault injection types; the fault corresponding to the fault injection type is injected into the controller through the automated test script; the fault information stored in the controller is obtained through the automated test script; the fault information is used to characterize the abnormal situation that occurs after the controller is injected with the fault; the fault information is parsed through the automated test script to obtain the fault diagnosis test result. The present application converts the test cases into automated test scripts, and the automated test scripts execute the controller fault diagnosis test process throughout the process without manual operation, which can improve the efficiency and accuracy of the fault diagnosis test, thereby greatly reducing the labor cost and time cost.

[0089] Figure 2 It is another flow chart of the controller fault diagnosis test method shown in the embodiment of the present application.

[0090] See also Figure 2 , the controller fault diagnosis test method of the present application comprises:

[0091] S210, obtaining a test case and converting the test case into an automated test script; wherein the test case includes a fault injection type.

[0092] For this step, please refer to the description in S110 and will not be repeated here.

[0093] It should be noted that steps S110 to S140 are mainly described by taking a single controller as an example, and steps S210 to S250 are mainly described by taking multiple controllers as an example.

[0094] In one embodiment, obtaining a test case and converting the test case into an automated test script may include:

[0095] Obtain a diagnostic table; the diagnostic table includes multiple fault injection types; wherein 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; wherein each of the multiple test cases includes a fault injection type; convert the multiple test cases into automated test scripts.

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

[0097] In a specific implementation, after obtaining the diagnostic table, the HIL simulation test system can read the test information in the diagnostic table, wherein the test information may include at least one of the fault type, the object under test, the preset fault trigger time and the preset fault recovery time, the fault type may include at least one of the model fault, the electrical fault and the message fault, the object under test may include at least one controller (such as a primary controller and a secondary controller), the preset fault trigger time may refer to the estimated time for the controller to complete the setting of the fault code after the fault is injected into the controller, and the preset fault recovery time may refer to the estimated time for the controller to complete the reset of the fault code after the fault is recovered from the controller. The HIL simulation test system can call the test case generation tool so as to use the test case generation tool to construct the test case rules according to the fault type, the object under test, the preset fault trigger time and the preset fault recovery time, and then parse the diagnostic table filled with the fault signal according to the test case rules, thereby automatically generating multiple test cases. Among them, each of these test cases includes a fault injection type. Therefore, if the diagnostic table includes a model fault injection type, an electrical fault injection type and a 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, among which test case 1 can carry a model fault injection type, test case 2 can carry an electrical fault injection type, and test case 3 can carry a message fault injection type.

[0098] After obtaining multiple test cases, the HIL simulation test system can call a test script generation tool to automatically convert all test cases into an automated test script using the test script generation tool. The HIL simulation test system can execute multiple test cases in sequence through the automated test script, where the execution order can be arbitrary, for example, the execution order can be: test case 1 → test case 2 → test case 3, or it can be: test case 3 → test case 2 → test case 1, and the embodiments of the present application do not limit this.

[0099] S220, injecting faults corresponding to the fault injection type into the primary controller and the secondary controller respectively through an automated test script; wherein the fault injection type includes any one of a model fault injection type, an electrical fault injection type, and a message fault injection type.

[0100] For this step, please refer to the description in S120 and will not be repeated here.

[0101] In one implementation, injecting faults corresponding to the fault injection type into the primary controller and the secondary controller respectively through an automated test script may include:

[0102] The primary controller and the secondary controller are respectively initialized through the automated test script; the faults corresponding to the fault injection types in the test cases in the current sequence are respectively injected into the primary controller and the secondary controller through the automated test script.

[0103] In addition to the above-mentioned problems at the software operation level and the hardware level, the related technology also includes problems at the controller level. For example, at the controller level in the related technology, fault diagnosis operations can only be performed on one controller at a time. However, there are many controllers to be diagnosed. If fault diagnosis operations can only be performed on each controller one by one, this will undoubtedly greatly consume time and cost.

[0104] In this regard, the embodiment of the present application uses existing hardware conditions and software thinking to build an automated test framework for fault diagnosis, integrates fault operation objects together, and can realize automated program control of fault operation objects. Specifically, the HIL simulation test system is configured with a HIL simulation test environment, and the HIL simulation test environment supports the joint call of multiple controllers. Therefore, the HIL simulation test system can jointly call the primary controller and the secondary controller, wherein the primary controller can include one, and the secondary controller can include multiple, the primary controller can be used to uniformly store the fault information of 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 test case of the previous order before all test steps of the test case of the previous order are executed. After all test steps of the test case of the previous order are executed, the HIL simulation test system can initialize the primary controller and the secondary controller respectively through the automated test script to avoid some operations of the test case of the previous order affecting the fault diagnosis test results of the test case of the current order. Therefore, after initializing the primary controller and the secondary controller respectively, the HIL simulation test system will inject the fault corresponding to the fault injection type in the test case of the current order into the primary controller and the secondary controller respectively through the automated test script.

[0106] In one implementation, injecting faults corresponding to the fault injection types in the test cases in the current sequence into the primary controller and the secondary controller respectively through an automated test script may include:

[0107] The corresponding fault injection method is determined according to the fault injection type in the test case in the current sequence through the automated test script; the corresponding set signals are sent to the primary controller and the secondary controller respectively according to the fault injection method through the automated test script; wherein the set signals are used to inject corresponding faults 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 through an automated test script according to the fault injection type carried by the test case in the current sequence, so that the corresponding set signals can be sent to the primary controller and the secondary controller respectively according to the currently determined fault injection method through the automated test script. The set signal 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 according to the fault injection type in the test case in the current order through the automated test script may include:

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

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

[0112] If the fault injection type carried by the test case in the current sequence is a model fault injection type, the corresponding fault injection method can be determined to be a model fault injection method. The model fault injection method can be to send the physical value simulated by the Veristand control model to the controller itself to simulate the fault.

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

[0114] The controller model control is called according to the model fault injection method through the automated test script; the physical value simulated by the controller model control is used as the corresponding set signal through the automated test script, and the corresponding set signals are sent to the primary controller and the secondary controller respectively.

[0115] The automated test script can execute the fault diagnosis test process of the model fault injection mode of multiple controllers according to the currently determined model fault injection mode. In the specific implementation, the automated diagnosis software in the HIL simulation test system is integrated with the Veristand control reading and writing tool. The HIL simulation test system can first establish communication with Veristand so that the Veristand control reading and writing tool can be called through the automated test script. The Veristand control reading and writing tool can specifically be a controller model control. The automated test script can obtain the physical value of the controller model control simulation so that the simulated physical value can be used as the set signal corresponding to the model fault injection type, and then send the corresponding set signal to the primary controller and the secondary controller respectively, thereby completing the model fault injection.

[0116] In another embodiment, determining the corresponding fault injection method according to the fault injection type in the test case in the current sequence through the automated test script may include:

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

[0118] If the fault injection type carried by the test case in the current sequence is an electrical fault injection type, it can be determined that the corresponding fault injection method is an electrical fault injection method. The electrical fault injection method can be to implement fault injection on the hard wire connected to the controller through an EFI fault injection board.

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

[0120] The EFI fault injection board is called according to the electrical fault injection method through the automated test script; the EFI fault injection board is connected to the primary controller and the secondary controller respectively through the wiring harness; the on and off of the interface of the EFI fault injection board is controlled through the automated test script to generate a corresponding set signal, and the corresponding set signal is sent to the primary controller and the secondary controller respectively through the wiring harness.

[0121] The automated test script can execute the fault diagnosis test process of the electrical fault injection mode of multiple controllers according to the currently determined electrical fault injection mode. In a specific implementation, the automated diagnosis software in the HIL simulation test system is integrated with an EFI fault injection tool, and 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, and the EFI fault injection board is physically connected to the primary controller and the secondary controller through hard wires (such as wiring harnesses), and the automated test script can generate a set signal corresponding to the electrical fault injection type by controlling the on and off of the interface of the EFI fault injection board, and then send the corresponding set signal to the primary controller and the secondary controller through the wiring harness, thereby completing the electrical fault injection.

[0122] In another embodiment, determining the corresponding fault injection method according to the fault injection type in the test case in the current sequence through the automated test script may include:

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

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

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

[0126] A fault message signal is generated according to the message fault injection method through an automated test script, so that the fault message signal is used as a corresponding set signal, and the corresponding set signal is sent to the primary controller and the secondary controller respectively.

[0127] The automated test script can execute the fault diagnosis test process of the message fault injection mode of multiple controllers according to the currently determined message fault injection mode. In the specific implementation, the HIL simulation test system is respectively connected to the primary controller and the secondary controller in communication, so the HIL simulation test system can send a fault message signal through the communication mode to realize the injection of the message fault. For example, the HIL simulation test system can generate a fault message signal through the automated test script so that the fault message signal can be used as a set signal corresponding to the message fault injection type, and then the corresponding set signal can be sent to the primary controller and the secondary controller respectively, thereby completing the message fault injection.

[0128] S230, after waiting for a preset fault trigger time, sending a diagnosis request instruction to the primary controller through an automated test script.

[0129] The test cases in the current sequence also carry a preset fault trigger time. After the HIL simulation test system sends the corresponding setting signals to the primary controller and the secondary controller respectively, it 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 based on 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 have a fault corresponding to the current fault injection type. When the primary controller identifies a fault, the primary controller can set the fault code corresponding to the fault, that is, change the state 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 have a fault corresponding to the current fault injection type. When the secondary controller recognizes the fault, the secondary controller can set the fault code corresponding to the fault, that is, change the state 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 then send it to the primary controller in the form of a fault message. After the primary controller recognizes the fault message of 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 completes the fault code setting, and then can send a diagnostic request instruction to the primary controller through an automated test script. The diagnostic request instruction is used to request fault information.

[0133] S240, receiving diagnostic response data returned by the primary controller in response to the diagnostic request instruction through an automated test script; wherein the diagnostic response data includes the primary controller's own fault information stored therein and / or the secondary controller's fault information stored therein.

[0134] After receiving the diagnostic request instruction, the primary controller can respond to the diagnostic request instruction and return diagnostic response data to the HIL simulation test system. The diagnostic response data may include fault information of the primary controller, or may include fault information of the secondary controller, or may include fault information of the primary controller and fault information of the secondary controller.

[0135] In addition, after a fault is injected into the primary controller and the secondary controller, no abnormal situation may occur due to their fault tolerance mechanism or self-recovery mechanism, that is, the primary controller and the secondary controller may not have the fault corresponding to the current fault injection type, so there may be no fault information for the primary controller and the secondary controller.

[0136] In this regard, the embodiment of the present application can first determine whether the primary controller and the secondary controller have failed after being injected with faults respectively, that is, whether the fault code is read, and after confirming that the fault code is read, the corresponding snapshot information is 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 and return fault code response data to the HIL simulation test system. The fault code response data may include the fault code of the primary controller and / or the fault code of the secondary controller, so that the HIL simulation test system can read the fault code. If the primary controller does not store its own fault code and does not store the fault code of the secondary controller, the primary controller can respond to the fault code request instruction and return a response message to the HIL simulation test system. The response message does not include the fault code of the primary controller or the fault code of the secondary controller, so that the HIL simulation test system cannot read the fault code, so 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 instruction to the primary controller. Since the same test case will only read the snapshot information of one fault code at a time, the HIL simulation test system can first determine the number of fault codes fed back by the primary controller, and then generate a corresponding number of snapshot information request instructions based on the number of fault codes.

[0138] If the primary controller only feeds back one fault code, that is, the fault code response data only includes the fault code of the primary controller or only includes the fault code of the secondary controller, indicating that only the primary controller has failed, or only the secondary controller has failed, then the HIL simulation test system can generate a snapshot information request instruction, which carries the fault code in the fault code response data, and then sends the snapshot information request instruction to the primary controller. After receiving the snapshot information request instruction, the primary controller can extract the fault code from the snapshot information request instruction, and then search for snapshot information matching the fault code from the stored fault information, and then return the snapshot information response data to the HIL simulation test system, and the snapshot information response data may include snapshot information matching the fault code in the snapshot information request instruction.

[0139] If the primary controller feeds back two fault codes, that is, the fault code response data includes the fault code of the primary controller and the fault code of the secondary controller, indicating that both the primary controller and the secondary controller have faults, then the HIL simulation test system can generate two snapshot information request instructions, for example, snapshot information request instruction A and snapshot information request instruction B, wherein snapshot information request instruction A can carry the fault code of the primary controller, and snapshot information request instruction B can carry the fault code of the secondary controller, and the HIL simulation test system first sends snapshot information request instruction A to the primary controller. After receiving snapshot information request instruction A, the primary controller can extract the fault code from the snapshot information request instruction A, and then search for snapshot information matching the fault code from the stored fault information, and then return snapshot information response data A to the HIL simulation test system, and the snapshot information response data A can include snapshot information matching the fault code in the snapshot information request instruction A, and the snapshot information is the snapshot information of the primary controller when the fault occurs. After receiving snapshot information response data A, the HIL simulation test system sends snapshot information request instruction B to the primary controller. After the primary controller receives the snapshot information request instruction B, it can extract the fault code from the snapshot information request instruction B, and then search for snapshot information matching the fault code from the stored fault information, and then return snapshot information response data B to the HIL simulation test system. The snapshot information response data B may include snapshot information matching the fault code in the snapshot information request instruction B, which is the snapshot information of the secondary controller when a fault occurs.

[0140] S250, parsing the diagnostic response data through an automated test script to obtain a fault diagnosis test result.

[0141] In one example, when the diagnostic response data only includes fault information of the primary controller, the HIL simulation test system parses the fault information of the primary controller through an automated test script to obtain a fault diagnosis test result of the primary controller.

[0142] In another example, when the diagnostic response data only includes the fault information of the secondary controller, the HIL simulation test system parses the fault information of the secondary controller through an automated test script to obtain the fault diagnosis test result of the secondary controller.

[0143] In another example, when the diagnostic response data includes fault information of the primary controller and fault information of the secondary controller, the HIL simulation test system can parse the fault information of the primary controller and the fault information of the secondary controller respectively through an automated test script, and can obtain the fault diagnosis test results of the primary controller and the fault diagnosis test results of the secondary controller.

[0144] In addition, if no diagnostic response data is obtained, it means that neither the primary controller nor the secondary controller has a fault, and there is no need to perform this step.

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

[0146] According to the diagnostic response data, the target controller that has an abnormal condition after the fault is injected is determined from the primary controller and the secondary controller; reset information is sent to the target controller through an automated test script to perform fault recovery on the target controller.

[0147] Fault recovery is an indispensable part of fault diagnosis testing. It can ensure that the controller can quickly resume normal operation when an abnormal situation occurs, thereby ensuring the stability and reliability of the controller.

[0148] In this regard, if the diagnostic response data is obtained, the HIL simulation test system can determine the target controller that sends the fault from the primary controller and the secondary controller based on the diagnostic response data, that is, determine the target controller that has an abnormal situation after the fault is injected, so as to send reset information to the target controller through the automated test script, and the reset information can be used to achieve fault recovery of the target controller.

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

[0150] In one example, when the diagnostic response data only includes the fault information of the primary controller, it means that an abnormal situation occurs after the primary controller is currently injected with a fault. The HIL simulation test system can determine the primary controller as the target controller, and then send reset information to the primary controller through an automated test script. The reset information may include a reset signal and a clear operation instruction. The target controller (i.e., the primary controller) can reset its own fault code in response to the reset signal, that is, change the state of its own fault code from 1 (activated state) to 0 (inactivated state), and at the same time respond to the clear operation instruction to perform an aging operation or a $14 service clear operation. The aging operation is a specified number of power on and off operations, thereby clearing its own snapshot information.

[0151] In another example, when the diagnostic response data only includes the fault information of the secondary controller, it means that the secondary controller has an abnormal situation after the fault is currently injected. Then the HIL simulation test system can determine the secondary controller as the target controller, and then send reset information to the secondary controller through the automated test script. The reset information can include a reset signal and a clear operation instruction. The target controller (i.e., the secondary controller) can reset its own fault code in response to the reset signal, that is, change the state of its own fault code from 1 (activated state) to 0 (inactivated state), and at the same time respond to the clear operation instruction to perform an aging operation or a $14 service clear operation, thereby clearing its own snapshot information. After the primary controller recognizes that the fault code of the secondary controller is reset, the stored fault code of the secondary controller can also be reset. If the primary controller recognizes that the snapshot information of the secondary controller is cleared, the stored snapshot information of the secondary controller can also be cleared by performing an aging operation or a $14 service clear operation.

[0152] In another example, when the diagnostic response data includes fault information of the primary controller and fault information of the secondary controller, it means that the primary controller and the secondary controller are currently injected with faults and abnormal conditions occur at the same time. Then, the HIL simulation test system can determine both the primary controller and the secondary controller as target controllers, and then send reset information to the primary controller and the secondary controller respectively through the automated test script. This example is a comprehensive example of the above two examples. The specific process can be found in the description of the above two examples, which will not be repeated here.

[0153] It should be noted that the embodiments of the present application mainly target the first two bits in the fault code. After sending the reset signal, the fault code does not immediately change from 1 to 0. The fault code still exists in the current ignition cycle, and the fault code will 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 that the fault diagnosis test process of the test cases in the current sequence is completed; initialize the first-level controller and the second-level controller again respectively through the automated test script, and execute the fault diagnosis test process of the test cases in the next sequence until the fault diagnosis test process of the test cases in the last sequence is completed.

[0156] The test case of the current sequence also carries a preset fault recovery time. After sending the reset information to the primary controller and / or the secondary controller, the HIL simulation test system can wait for the primary controller and / or the 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 the secondary controller complete the fault code setting and snapshot information clearing, the HIL simulation test system can wait for a signal routing time based on 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 completes the fault code reset and snapshot information clearing. At this time, it can be determined that the fault diagnosis test process of the test cases in the current sequence has been executed, thereby ending the fault diagnosis test process of the test cases in the current sequence, and then returns to step S220 to initialize the primary controller and the secondary controller again respectively through the automated test script, and then execute the fault diagnosis test process of the test cases in the next sequence, until the fault diagnosis test process of the test cases in the last sequence is completed.

[0158] In addition, in order to ensure that both the primary controller and the secondary controller can achieve fault recovery, the HIL simulation test system can send a diagnostic request instruction to the primary controller again after waiting for the preset fault recovery time and signal routing time, and then receive the diagnostic response data returned by the primary controller for the diagnostic request instruction again. If the fault code in the diagnostic response data received again 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] It can be seen from this example that the solution provided by the present application, by converting test cases into automated test scripts, which execute the entire controller fault diagnosis test process without manual operation, can improve the efficiency and accuracy of fault diagnosis testing, thereby greatly reducing labor costs and time costs.

[0160] Furthermore, the solution provided in the present application can perform fault diagnosis operations on multiple controllers (such as a primary controller and a secondary controller) at the same time, which can further improve the efficiency of fault diagnosis testing and thus greatly reduce time costs.

[0161] Furthermore, in the solution provided by the present application, the fault injection types include model fault injection type, electrical fault injection type and message fault injection type, thereby improving the test coverage of the fault diagnosis function.

[0162] In order to enable those skilled in the art to better understand the embodiments of the present application, the embodiments of the present application are described below through the following four examples.

[0163] Example 1: Figure 3 It is a full flow chart of the controller fault diagnosis test, which can be executed by the HIL simulation test system, specifically by the automated diagnosis software in the HIL simulation test system. The specific full process is as follows:

[0164] S1, initialization, i.e. initializing the automated diagnostic software; wherein the automated diagnostic software integrates automated testing tools such as test case generation tool, test script generation tool, Veristand control reading and writing tool, EFI fault injection tool, etc.

[0165] S2, obtain a diagnostic table; the diagnostic table includes multiple fault injection types and test information; wherein the multiple fault injection types are model fault injection type, electrical fault injection type and message fault injection type, and the test information includes fault type, object under test, preset fault trigger time and preset fault recovery time.

[0166] S3, call the test case generation tool.

[0167] S4, using a test case generation tool to construct test case rules according to the fault type, the object under test, the preset fault trigger time and the preset fault recovery time; parsing 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.

[0168] S5, calling the test script generation tool.

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

[0170] S7, execute multiple test cases in sequence through the test script. For details, see the following steps:

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

[0172] S9, determine whether it is the current diagnostic function, that is, determine whether it is a test case in the current sequence; if so, go to step S10; if not, 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, and 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, enter step S11; when it is determined that the fault action of the current diagnostic function is reset, enter 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 case in the current sequence is determined.

[0175] S12, if the fault type of the current diagnostic function is a model fault injection type, then call the Veristand control reading and writing tool, which may specifically be a controller model control, and enter step S15.

[0176] S13, if the fault type of the current diagnostic function is an electrical fault injection type, an EFI fault injection tool is called, the EFI fault injection tool may specifically be an EFI fault injection board, and the process proceeds to step S15.

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

[0178] S15, execute fault setting, the specific step is S16.

[0179] S16, injecting corresponding fault signals into the primary controller and the secondary controller respectively through a model fault injection method, an electrical fault injection method, or a message fault injection method, where the fault signal is a set signal.

[0180] S17, waiting for the controller fault to be set. During this period, if the primary controller recognizes the fault after being injected with the fault, it completes the fault code setting. If the secondary controller recognizes the fault after being injected with the fault, it completes the fault code setting. After waiting for the primary controller and / or the secondary controller to complete the fault code setting, enter 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 case in the current sequence is determined.

[0182] S19, if the fault type of the current diagnostic function is a model fault injection type, then call the Veristand control reading and writing tool, which may specifically be a controller model control, and enter step S21.

[0183] S20, if the fault type of the current diagnostic function is an electrical fault injection type, then call an EFI fault injection tool, which may specifically be an EFI fault injection board, and enter step S21.

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

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

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

[0187] S24, waiting for controller fault reset. During this period, if there is a fault in the primary controller, the fault code reset and snapshot information clearing are completed. If there is a fault in the secondary controller, the fault code reset and snapshot information clearing are completed. After waiting for the primary controller and / or the secondary controller to complete the fault code reset and snapshot information clearing, enter step S25.

[0188] S25, sending a diagnosis request instruction to the primary controller.

[0189] S26, receiving diagnostic response data returned by the primary controller in response to the diagnostic request instruction; wherein the diagnostic response data includes the primary controller's own fault information stored therein and / or the secondary controller's fault information stored therein.

[0190] S27, judging the fault information.

[0191] S28, output results, specifically the fault diagnosis test results of the output controller (primary controller and / or secondary controller), wherein the fault diagnosis test results corresponding to the setting may include a fault code of 1 and snapshot information, and the fault diagnosis test results corresponding to the reset may include a fault code of 0; end the fault diagnosis test process of the test case in the current sequence to start the fault diagnosis test process of the test case in the next sequence, and then return to step S9.

[0192] S29, when all test cases are executed, it is determined that the test is completed.

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

[0194] After analyzing the test case, the automated diagnosis software injects faults into the primary controller and the secondary controller respectively by means of model fault injection. Specifically, the physical value simulated by the controller model control is used as the corresponding set signal so that the corresponding set signal is sent to the primary controller and the secondary controller respectively to complete the model fault injection. After the primary controller identifies the fault, it sets the fault code corresponding to the fault and records the snapshot information corresponding to the fault so that the fault code and the snapshot information are stored as fault information; after the secondary controller identifies the fault, it sets the fault code corresponding to the fault and records the snapshot information corresponding to the fault so that the fault code and the snapshot information are stored as fault information, and then notifies the primary sensor of the fault information in the form of a fault message. After the primary sensor identifies the fault message of the secondary controller, it stores the fault information of the secondary controller. After waiting for both the primary controller and the secondary controller to complete the setting of the fault code, the automated diagnosis software sends a diagnosis request instruction to the primary controller to request the fault code and snapshot information. After receiving the diagnosis request instruction, the primary controller responds to the diagnosis and returns the diagnosis response data. The automated diagnosis software makes a judgment by parsing the diagnosis response data to obtain the fault diagnosis test result.

[0195] Example 3: Figure 5 This is a fault diagnosis test flow chart of the electrical fault injection method of multiple controllers. The specific process is as follows:

[0196] After analyzing the test case, the automated diagnostic software injects faults into the primary controller and the secondary controller respectively through electrical fault injection. Specifically, the corresponding setting signal is generated by controlling the on and off of the interface of the EFI fault injection board, so that the corresponding setting signal is sent to the primary controller and the secondary controller respectively to complete the electrical fault injection. After the primary controller recognizes the fault, it sets the fault code corresponding to the fault and records the snapshot information corresponding to the fault, so that the fault code and the snapshot information are stored as fault information; after the secondary controller recognizes the fault, it sets the fault code corresponding to the fault and records the snapshot information corresponding to the fault, so that the fault code and the snapshot information are stored as fault information, and then notifies the primary sensor of the fault information in the form of a fault message. After the primary sensor recognizes the fault message of the secondary controller, it stores the fault information of the secondary controller. After waiting for both the primary controller and the secondary controller to complete the setting of the fault code, the automated diagnostic software sends a diagnostic request instruction to the primary controller to request the fault code and snapshot information. After receiving the diagnostic request instruction, the primary controller responds to the diagnosis and returns the diagnostic response data. The automated diagnostic software makes a judgment by parsing the diagnostic response data to obtain the fault diagnosis test result.

[0197] Example 4: Figure 6 This is a fault diagnosis test flow chart of the message fault injection method of multiple controllers. The specific process is as follows:

[0198] After analyzing the test case, the automated diagnostic software injects faults into the primary controller and the secondary controller respectively through the message fault injection method, specifically by generating a fault message signal and using the fault message signal as the corresponding set signal so that the corresponding set signal can be sent to the primary controller and the secondary controller respectively to complete the message fault injection. After the primary controller identifies the fault, it sets the fault code corresponding to the fault and records the snapshot information corresponding to the fault so that the fault code and the snapshot information can be stored as fault information; after the secondary controller identifies the fault, it sets the fault code corresponding to the fault and records the snapshot information corresponding to the fault so that the fault code and the snapshot information can be used as fault information, and then notifies the primary sensor of the fault information in the form of a fault message. After the primary sensor identifies the fault message of the secondary controller, it stores the fault information of the secondary controller. After waiting for both the primary controller and the secondary controller to complete the setting of the fault code, the automated diagnostic software sends a diagnostic request instruction to the primary controller to request the fault code and snapshot information. After receiving the diagnostic request instruction, the primary controller responds to the diagnosis and returns the diagnostic response data. The automated diagnostic software makes a judgment by parsing the diagnostic response data to obtain the fault diagnosis test result.

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

[0200] Figure 7 It is a structural schematic diagram of a controller fault diagnosis test device shown in an embodiment of the present application.

[0201] See also Figure 7 The present application provides a controller fault diagnosis test device, which may include:

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

[0203] A fault injection module 720, used to inject a fault corresponding to the fault injection type into the controller through an automated test script;

[0204] The fault information acquisition module 730 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 after the controller is injected with a fault;

[0205] The fault information analysis module 740 is used to analyze the fault information through the automated test script to obtain the fault diagnosis test result.

[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 corresponding to the fault injection type into the primary controller and the secondary controller respectively through an automated test script; wherein the fault injection type includes any one of a model fault injection type, an electrical fault injection type and a message fault injection type.

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

[0209] A diagnosis request instruction sending submodule is used to send a diagnosis request instruction to the primary controller through an automated test script after waiting for a preset fault trigger time;

[0210] The diagnostic response data receiving submodule is used to receive the 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 stored therein and / or the secondary controller's fault information stored therein.

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

[0212] The diagnostic table acquisition submodule is used to acquire the diagnostic table; the diagnostic table includes multiple fault injection types; wherein the multiple 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] A diagnostic table parsing submodule, 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 implementation, the fault injection submodule may include:

[0217] An initialization unit, used to respectively initialize the primary controller and the secondary controller through an automated test script;

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

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

[0220] A fault injection mode determination subunit is used to determine a corresponding fault injection mode according to a fault injection type in a test case in a current sequence through an automated test script;

[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 corresponding faults into the primary controller and the secondary controller.

[0222] In one implementation, the fault injection mode determination subunit may be specifically used for:

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

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

[0225] Call the controller model control according to the model fault injection method through the automated test script;

[0226] The physical value simulated by the controller model control is used as the corresponding set signal through the automated test script, and the corresponding set signal is sent to the primary controller and the secondary controller respectively.

[0227] In another implementation manner, the fault injection mode determination subunit may be specifically used for:

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

[0229] In another implementation, the set signal sending subunit may be specifically used for:

[0230] The EFI fault injection board is called according to the electrical fault injection method through the automated test script; the EFI fault injection board is connected to the primary controller and the secondary controller respectively through the wiring harness;

[0231] The on / off of the interface of the EFI fault injection board is controlled by an automated test script to generate a corresponding set signal, and the corresponding set signal is sent to the primary controller and the secondary controller respectively through the wiring harness.

[0232] In yet another implementation manner, the fault injection mode determination subunit may be specifically configured to:

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

[0234] In yet another embodiment, the set signal sending subunit may be specifically configured to:

[0235] A fault message signal is generated according to the message fault injection method through an automated test script, so that the fault message signal is used as a corresponding set signal, and the corresponding set signal is sent to the primary controller and the secondary controller respectively.

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

[0237] A target controller determination module, used to determine, from the primary controller and the secondary controller, a target controller that has an abnormal condition after the fault is injected, according to the diagnostic response data;

[0238] The fault recovery module is used to send reset information to the target controller through an automated test script to perform fault recovery on the target controller.

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

[0240] The current fault diagnosis test process ending module is used to determine the completion of the fault diagnosis test process of the test cases in the current sequence after waiting for a preset fault recovery time;

[0241] The next fault diagnosis test process start module is used to initialize the primary controller and the secondary controller again respectively through the automated test script, 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 can be seen from this example, the solution provided by the present application obtains test cases and converts the test cases into automated test scripts; wherein the test cases include fault injection types; the fault corresponding to the fault injection type is injected into the controller through the automated test script; the fault information stored in the controller is obtained through the automated test script; the fault information is used to characterize the abnormal situation that occurs after the controller is injected with the fault; the fault information is parsed through the automated test script to obtain the fault diagnosis test result. The present application converts the test cases into automated test scripts, and the automated test scripts execute the controller fault diagnosis test process throughout the process without manual operation, which can improve the efficiency and accuracy of the fault diagnosis test, thereby greatly reducing the labor cost and time cost.

[0243] Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated again here.

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

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

[0246] The processor 820 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.

[0247] The memory 810 may include various types of storage units, such as system memory, read-only memory (ROM), and permanent storage. Among them, ROM can store static data or instructions required by the processor 820 or other modules of the computer. The permanent storage device may be a readable and writable storage device. The permanent storage device may be a non-volatile storage device that does not lose the stored instructions and data even after the computer is powered off. In some embodiments, the permanent storage device uses a large-capacity storage device (such as a magnetic or optical disk, flash memory) as a permanent storage device. In some other embodiments, the permanent storage device may be a removable storage device (such as a floppy disk, optical drive). The system memory may be a readable and writable storage device or a volatile readable and writable storage device, such as a dynamic random access memory. The system memory may store some or all instructions and data required by the processor at run time. In addition, the memory 810 may include any combination of computer-readable storage media, including various types of semiconductor storage chips (such as DRAM, SRAM, SDRAM, flash memory, programmable read-only memory), and disks and / or optical disks may also be used. In some embodiments, the memory 810 may include a readable and / or writable removable storage device, such as a laser disc (CD), a read-only digital versatile disc (e.g., DVD-ROM, double-layer DVD-ROM), a read-only Blu-ray disc, an ultra-density optical disc, a flash memory card (e.g., SD card, mini SD card, Micro-SD card, etc.), a magnetic floppy disk, etc. The computer-readable storage medium does not include carrier waves and transient electronic signals transmitted wirelessly or wired.

[0248] The memory 810 stores executable codes, and when the executable codes are processed by the processor 820 , the processor 820 can execute part or all of the methods described above.

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

[0250] Alternatively, the present application can also be implemented as a computer-readable storage medium (or non-temporary machine-readable storage medium or machine-readable storage medium) on which executable code (or computer program or computer instruction code) is stored. When the executable code (or computer program or computer instruction code) is executed by a processor of an electronic device, the processor executes part or all of the steps of the above-mentioned method according to the present application.

[0251] The embodiments of the present application have been described above, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and changes will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The selection of terms used herein is intended to best explain the principles of the embodiments, practical applications, or improvements to the technology in the market, or to enable other persons of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A controller fault diagnosis test method, characterized in that: include: Acquire a test case and convert the test case into an automated test script; wherein the test case includes a fault injection type; Injecting a fault corresponding to the fault injection type into the controller through the automated test script; Acquiring fault information stored in the controller through the automated test script; the fault information is used to characterize an abnormal situation that occurs after the controller is injected with the fault; The fault information is parsed through the automated test script to obtain a fault diagnosis test result.

2. The method according to claim 1, characterized in that The controller includes a primary controller and a secondary controller; The injecting a fault corresponding to the fault injection type into the controller through the automated test script includes: The fault corresponding to the fault injection type is injected into the primary controller and the secondary controller respectively through the automated test script; wherein the fault injection type includes any one of a model fault injection type, an electrical fault injection type and a message fault injection type.

3. The method according to claim 2, characterized in that The obtaining the fault information stored in the controller through the automated test script includes: After waiting for a preset fault trigger time, sending a diagnosis request instruction to the primary controller through the automated test script; The diagnostic response data returned by the primary controller in response to the diagnostic request instruction is received through the automated test script; wherein the diagnostic response data includes the primary controller's own fault information stored therein and / or the secondary controller's fault information stored therein.

4. The method according to claim 3, characterized in that The obtaining of test cases and converting the test cases into automated test scripts includes: Obtain a 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; Parsing the diagnostic table according to the test case rules to obtain a plurality of test cases; wherein each of the plurality of test cases includes a type of fault injection; Convert the plurality of test cases into automated test scripts.

5. The method according to claim 4, characterized in that The injecting the fault corresponding to the fault injection type into the primary controller and the secondary controller respectively through the automated test script includes: Initialize the primary controller and the secondary controller respectively by using the automated test script; The faults corresponding to the fault injection types in the test cases in the current sequence are injected into the primary controller and the secondary controller respectively through the automated test script.

6. The method according to claim 5, characterized in that The injecting of the faults corresponding to the fault injection types in the test cases in the current order into the primary controller and the secondary controller respectively through the automated test script comprises: Determine the corresponding fault injection method according to the fault injection type in the test case in the current order through the automated test script; The automated test script sends corresponding set signals to the primary controller and the secondary controller respectively according to the fault injection method; wherein the set signals are used to inject corresponding faults into the primary controller and the secondary controller.

7. The method according to claim 6, characterized in that The step of determining the corresponding fault injection method according to the fault injection type in the test case in the current order through the automated test script includes: If the fault injection type in the test case in the current order is the model fault injection type, determining the corresponding fault injection method to be the model fault injection method; The sending corresponding set signals to the primary controller and the secondary controller respectively according to the fault injection method through the automated test script includes: Calling the controller model control according to the model fault injection method through the automated test script; The physical value simulated by the controller model control is used as a corresponding set signal through the automated test script, and the corresponding set signal is sent to the primary controller and the secondary controller respectively.

8. The method according to claim 6, characterized in that The step of determining the corresponding fault injection method according to the fault injection type in the test case in the current order through the automated test script includes: If the fault injection type in the test case in the current sequence is the electrical fault injection type, determining that the corresponding fault injection method is the electrical fault injection method; The sending corresponding set signals to the primary controller and the secondary controller respectively according to the fault injection method through the automated test script includes: Calling an electrical fault injection EFI fault injection board card according to the electrical fault injection method through the automated test script; the EFI fault injection board card is connected to the primary controller and the secondary controller respectively through a wiring harness; The on and off of the interface of the EFI fault injection board is controlled by the automated test script to generate a corresponding set signal, and the corresponding set signal is sent to the primary controller and the secondary controller respectively through the wiring harness.

9. The method according to claim 6, characterized in that The step of determining the corresponding fault injection method according to the fault injection type in the test case in the current order through the automated test script includes: If the fault injection type in the test case in the current order is the message fault injection type, determining that the corresponding fault injection mode is the message fault injection mode; The sending corresponding set signals to the primary controller and the secondary controller respectively according to the fault injection method through the automated test script includes: A fault message signal is generated by the automated test script according to the message fault injection method, so that the fault message signal is used as a corresponding set signal, and the corresponding set signal is sent to the primary controller and the secondary controller respectively.

10. The method according to claim 6, characterized in that The method further comprises: According to the diagnostic response data, determining a target controller from the primary controller and the secondary controller that has an abnormal condition after the fault is injected; Reset information is sent to the target controller through the automated test script to perform fault recovery on the target controller.

11. The method according to claim 10, characterized in that The method further comprises: After waiting for a preset fault recovery time, determining to complete the fault diagnosis test process of the test cases in the current order; The primary controller and the secondary controller are respectively initialized again through the automated test script, and the fault diagnosis test process of the test case in the next sequence is executed until the fault diagnosis test process of the test case in the last sequence is completed.

12. A controller fault diagnosis test device, characterized in that: include: A test case acquisition module, used to acquire test cases and convert the test cases into automated test scripts; wherein the test cases include fault injection types; A fault injection module, used to inject a fault corresponding to the fault injection type into the controller through the automated test script; A fault information acquisition module, 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 after the controller is injected with the fault; The fault information analysis module is used to analyze the fault information through the automated test script to obtain a fault diagnosis test result.

13. An electronic device, characterized in that: include: processor; as well as A memory having executable codes stored thereon, which, when executed by the processor, causes the processor to execute the method according to any one of claims 1 to 11.

Images