Automatic testing method for redundancy management software

Abstract

The invention belongs to the field of software testing, and particularly relates to an automatic testing method for redundancy management software. According to the automatic test method for the redundancy management software, the test case set is generated by adopting different test case automatic generation scripts, so that the repeated work of testers is reduced, and human errors introduced by the testers due to too much test data are avoided; the test process is divided into the first monitoring voting test and the second monitoring voting test, on the basis of not changing the software architecture, the complete test of the demand is realized, the intermediate link of the fault state test is simplified, and the fault injection is facilitated; through automatic comparison of test results, automatic comparison of test case set results of a large number of signals can be achieved at the same time, the test time is saved, and fault positioning is also facilitated; and a test case record conforming to the format can be generated as an attachment of the test report.

Description

Technical Field

[0001] The present invention relates to the field of software testing, and in particular to an automated testing method for redundancy management software. Background Art

[0002] As the key software of the aircraft management system, the redundancy management software is responsible for the working status monitoring, fault identification and isolation of the redundant information, and the fault synthesis of the detected fault information, and completes the fault reporting, so as to solve the effective coordination of the redundant channels. Therefore, the security of the redundancy management software directly affects the flight safety of the aircraft and the functions of other systems.

[0003] Redundancy management software has the characteristics of huge signal volume and high functional aggregation, so there is a lot of repetitive work during testing, and it has the conditions and requirements for automated testing. At present, the testing of redundancy management software is mainly for testers to input the designed test cases one by one, observe the consistency of voting results and test cases, and the testing efficiency is low. Traditional testing methods involve many test cases, which are time-consuming and costly. When performing fault injection, there are many fault states involved, which makes the operation more confusing, and various factors affect each other, so some requirements cannot be covered. Moreover, this method relies too much on the testers themselves, which is easy to introduce test case errors and increase the difficulty of troubleshooting.

[0004] Therefore, it is desired to have a technical solution to overcome or at least alleviate at least one of the above-mentioned defects of the prior art. Summary of the invention

[0005] The purpose of the present application is to provide an automated testing method for redundancy management software to solve at least one problem existing in the prior art.

[0006] The technical solution of this application is:

[0007] An automated testing method for redundancy management software, comprising:

[0008] Step 1: According to the interface volume of the requirement specification, the input signal is divided into different signal types according to the signal source and the difference of intermediate state;

[0009] Step 2: For input signals of different signal types, write an automated test case generation script according to the value range of the input signal, signal fault type and state fault type, and generate the first monitoring voting test case set for each input signal;

[0010] Step 3: Import the first monitoring voting test case set into the simulation running environment to drive the redundancy management software to run;

[0011] Step 4: Set the test running time. After the test is finished, use the test result automatic comparison script to compare the first monitoring voting test results.

[0012] Step 5: Using the output signal of the first monitoring and voting as the input signal of the second monitoring and voting, and dividing the input signal of the second monitoring and voting into different signal types;

[0013] Step 6: For input signals of different signal types, write an automated test case generation script according to the value range of the input signal, the signal fault type and the state fault type, and generate a second monitoring voting test case set for each input signal;

[0014] Step 7: Import the second monitoring and voting test case set into the simulation operation environment to drive the redundancy management software to run;

[0015] Step 8: Set the test running time. After the test is completed, use the test result automatic comparison script to compare the second monitoring voting test results and generate a test report.

[0016] In at least one embodiment of the present application, in step 1, according to the interface volume of the requirement specification, the input signal is divided into different signal types according to the difference in signal source and intermediate state, including:

[0017] According to the interface division requirements, input signals are divided into electromechanical signals, flight control signals, and avionics signals according to signal sources;

[0018] According to the differences in intermediate states, the input signals from various signal sources are divided into: analog signals, discrete signals, and enumeration signals.

[0019] In at least one embodiment of the present application, the electromechanical signal is divided into: analog signal and enumeration signal according to the difference in intermediate states.

[0020] In at least one embodiment of the present application, the flight control signal is divided into: analog signal according to the difference in intermediate states.

[0021] In at least one embodiment of the present application, the avionics signal is divided into: analog signal, discrete signal, and enumeration signal according to the difference in intermediate states.

[0022] In at least one embodiment of the present application, in step 2, when the input signal is an analog signal of an electromechanical signal, the input signal includes:

[0023] Device status, serdes bus status, CCDL bus status, heartbeat word status, valid bit status, transition status.

[0024] In at least one embodiment of the present application, in step 2, when the input signal is an enumeration signal of an electromechanical signal, the input signal includes:

[0025] Device status, serdes bus status, CCDL bus status, heartbeat word status, transition status.

[0026] In at least one embodiment of the present application, in step 2, when the input signal is an analog signal of a flight control signal, the input signal includes:

[0027] Device status, serdes bus status, mode word status, valid bit status.

[0028] In at least one embodiment of the present application, in step 2, when the input signal is an analog signal of an avionics signal, the input signal includes:

[0029] TTFC status, valid bit status, illegal number status, transition status.

[0030] In at least one embodiment of the present application, in step 2, when the input signal is a discrete signal of an avionics signal, the input signal includes:

[0031] TTFC status, transition status.

[0032] In at least one embodiment of the present application, in step 2, when the input signal is an enumeration signal of an avionics signal, the input signal includes:

[0033] TTFC status, transition status.

[0034] In at least one embodiment of the present application, in step 4, the test running time is set to be greater than the running time of the first monitoring and voting test case set.

[0035] In at least one embodiment of the present application, in step 4, comparing the first monitoring voting test results through the test result automatic comparison script includes:

[0036] Import the first monitoring voting test results into the test result automatic comparison script to generate a test result comparison chart in a fixed format;

[0037] Judging whether the theoretical value of the first monitoring voting test result is consistent with the actual value according to the test result comparison chart;

[0038] If they are consistent, proceed to step five;

[0039] If they are inconsistent, perform fault location.

[0040] In at least one embodiment of the present application, in step five, the input signal of the second monitoring vote is divided into: an analog signal, a discrete signal, and an enumeration signal.

[0041] In at least one embodiment of the present application, in step six, when the input signal is an analog signal;

[0042] Input signals include: maximum fault, minimum fault, maximum-second-maximum fault, maximum-minimum fault, second-minimum-minimum fault, 2:2 fault, 1:1:1:1 fault, device status, link status, and valid bit status.

[0043] In at least one embodiment of the present application, in step six, when the input signal is a discrete signal;

[0044] Input signals include: 0 fault, 1 fault, 2:2 fault, device status, link status, and valid bit status.

[0045] In at least one embodiment of the present application, in step six, when the input signal is an enumeration signal;

[0046] Input signals include: maximum fault, minimum fault, maximum-second-maximum fault, maximum-minimum fault, second-minimum-minimum fault, 2:2 fault, 1:1:1:1 fault, device status, link status, and valid bit status.

[0047] In at least one embodiment of the present application, in step eight, the test running time is set to be greater than the running time of the second monitoring and voting test case set.

[0048] In at least one embodiment of the present application, in step eight, comparing the second monitoring voting test results by using a test result automatic comparison script includes:

[0049] Import the second monitoring voting test results into the test result automatic comparison script to generate a test result comparison chart in a fixed format;

[0050] Judging whether the theoretical value of the second monitoring voting test result is consistent with the actual value according to the test result comparison chart;

[0051] If they are inconsistent, perform fault location.

[0052] The invention has at least the following beneficial technical effects:

[0053] The automated testing method for redundancy management software of the present application splits the intermediate links of the redundancy management software into two layers of testing through the first monitoring and voting test case input script and the second monitoring and voting test case input script, which can ensure that the integrity of the test target software is not damaged, and can also simplify the intermediate links and facilitate fault injection; classify the data sources, use test cases to automatically generate scripts, generate test case sets that meet the needs of different devices, and simplify the repetitive work of test cases; and realize dynamic data comparison of multiple signals at the same time through automatic comparison of test case results, which is convenient for fault location. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] Figure 1 It is a flow chart of an automated testing method of redundancy management software according to an implementation mode of the present application;

[0055] Figure 2 This is a schematic diagram of a first monitoring voting test case set of an implementation method of the present application;

[0056] Figure 3 This is a schematic diagram of the first monitoring and voting test results of an implementation method of the present application;

[0057] Figure 4 It is a corresponding relationship diagram of the first monitoring voting and the second monitoring voting test input of an implementation mode of the present application;

[0058] Figure 5 It is a schematic diagram of a second monitoring voting test case set of an implementation method of the present application;

[0059] Figure 6 This is a schematic diagram of the second monitoring and voting test results of an implementation method of the present application. DETAILED DESCRIPTION

[0060] In order to make the purpose, technical scheme and advantages of the implementation of this application clearer, the technical scheme in the embodiment of this application will be described in more detail below in conjunction with the drawings in the embodiment of this application. In the drawings, the same or similar reference numerals throughout represent the same or similar elements or elements with the same or similar functions. The described embodiments are part of the embodiments of this application, not all of them. The embodiments described below with reference to the drawings are exemplary and are intended to be used to explain this application, and should not be construed as limitations on this application. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application. The embodiments of this application are described in detail below in conjunction with the drawings.

[0061] In the description of the present application, it should be understood that the terms "center", "longitudinal", "lateral", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inside", "outside", etc., indicating orientations or positional relationships, are based on the orientations or positional relationships shown in the accompanying drawings, and are only for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore should not be understood as limiting the scope of protection of the present application.

[0062] The following is combined with Figures 1 to 6 This application is described in further detail.

[0063] The present application provides an automated testing method for redundancy management software, comprising the following steps:

[0064] Step 1: According to the interface volume of the requirement specification, the input signal is divided into different signal types according to the signal source and the difference of intermediate state;

[0065] Step 2: For input signals of different signal types, write an automated test case generation script according to the value range of the input signal, signal fault type and state fault type, and generate the first monitoring voting test case set for each input signal;

[0066] Step 3: Import the first monitoring voting test case set into the simulation running environment to drive the redundancy management software to run;

[0067] Step 4: Set the test running time. After the test is finished, use the test result automatic comparison script to compare the first monitoring voting test results.

[0068] Step 5: Using the output signal of the first monitoring and voting as the input signal of the second monitoring and voting, and dividing the input signal of the second monitoring and voting into different signal types;

[0069] Step 6: For input signals of different signal types, write an automated test case generation script according to the value range of the input signal, the signal fault type and the state fault type, and generate a second monitoring voting test case set for each input signal;

[0070] Step 7: Import the second monitoring and voting test case set into the simulation operation environment to drive the redundancy management software to run;

[0071] Step 8: Set the test running time. After the test is completed, use the test result automatic comparison script to compare the second monitoring voting test results and generate a test report.

[0072] In the automated testing method for the redundancy management software of the present application, in step one, first, according to the interface volume of the requirement specification, the input signals are divided into: electromechanical signals, flight control signals, and avionics signals according to the signal sources; then, according to the differences in the intermediate states, the input signals of each signal source are divided into: analog signals, discrete signals, and enumeration signals.

[0073] In this embodiment, according to the difference in intermediate states, the electromechanical signals are divided into: analog signals, enumeration signals; the flight control signals are divided into: analog signals; and the avionics signals are divided into: analog signals, discrete signals, and enumeration signals.

[0074] In the automated testing method for redundancy management software of the present application, in step 2, based on the classification of input signals in step 1, combined with the value range of the input signals, signal fault types and state fault types, a first monitoring voting test case set is generated.

[0075] Specifically, when the input signal is an analog signal of an electromechanical signal, the input signal includes: device status, serdes bus status, CCDL bus status, heartbeat word status, valid bit status, and transition status.

[0076] When the input signal is an enumeration signal of an electromechanical signal, the input signal includes: device status, serdes bus status, CCDL bus status, heartbeat word status, and transition status.

[0077] When the input signal is an analog signal of a flight control signal, the input signal includes: device status, serdes bus status, mode word status, and valid bit status.

[0078] When the input signal is an analog signal of an avionics signal, the input signal includes: TTFC state, valid bit state, illegal number state, and jump state.

[0079] When the input signal is a discrete signal of an avionics signal, the input signal includes: a TTFC state and a jump state.

[0080] When the input signal is an enumeration signal of an avionics signal, the input signal includes: TTFC state and jump state.

[0081] Furthermore, in step 4, the test run time is set to be greater than the run time of the first monitoring and voting test case set. After the run is completed, the test result automatic comparison script is used to compare the test results of the first monitoring and voting test case set, including:

[0082] Import the first monitoring voting test results into the test result automatic comparison script to generate a test result comparison chart in a fixed format;

[0083] Judging whether the theoretical value of the first monitoring voting test result is consistent with the actual value according to the test result comparison chart;

[0084] If they are consistent, proceed to step five;

[0085] If they are inconsistent, perform fault location.

[0086] The automated testing method for the redundancy management software of the present application, in step five, the output of the first monitoring vote is used as the input of the second monitoring vote, and the input signal of the second monitoring vote is divided into: analog signal, discrete signal, enumeration signal. In step six, according to the signal type in step five, combined with the value range of the input signal, the signal fault type and the state fault type, a second monitoring vote test case set for each input signal is generated. Among them, when the input signal is an analog signal; the input signal includes: maximum value fault, minimum value fault, maximum second largest fault, maximum minimum fault, second smallest minimum fault, 2:2 fault, 1:1:1:1 fault, device status, link status, valid bit status. When the input signal is a discrete signal; the input signal includes: 0 fault, 1 fault, 2:2 fault, device status, link status, valid bit status. When the input signal is an enumeration signal; the input signal includes: maximum value fault, minimum value fault, maximum second largest fault, maximum minimum fault, second smallest minimum fault, 2:2 fault, 1:1:1:1 fault, device status, link status, valid bit status.

[0087] In the automated testing method of the redundancy management software of the present application, in step eight, the test run time is set to be greater than the run time of the second monitoring and voting test case set. After the run is completed, the test results of the second monitoring and voting test case set are also compared using the test result automatic comparison script, which includes:

[0088] Import the second monitoring voting test results into the test result automatic comparison script to generate a test result comparison chart in a fixed format;

[0089] Judging whether the theoretical value of the second monitoring voting test result is consistent with the actual value according to the test result comparison chart;

[0090] If they are inconsistent, perform fault location.

[0091] According to the test results, analyze the items where the theoretical values ​​are inconsistent with the actual values, and generate a test report attachment in the corresponding format.

[0092] The automated testing method of the redundancy management software of the present application is to divide all the signals that need to be monitored and voted into two-level tests: the first monitoring and voting and the second monitoring and voting, and use the output result of the first monitoring and voting as the input of the second monitoring and voting test; analyze the interface volume of the requirements specification to divide the test case input of the first monitoring and voting into three parts according to the source: electromechanical, flight control, and avionics, and then divide the input from different sources into analog signals, discrete signals, and enumeration signals according to the difference in intermediate state quantities. Then use the test case automatic generation script to generate corresponding test cases according to the value range of different input signals, various signal fault types, and state fault types; import the test cases into the target machine by loading the test script to drive the redundancy management software to run; finally, realize the dynamic comparison of multiple signals through the test result automatic comparison script.

[0093] This application proposes an automated testing method for the redundancy management software of a flight control system, in view of the fact that manual testing of the redundancy management software of a flight control system is repetitive and labor-intensive, and in combination with a large number of intermediate states of the software. This method splits the intermediate state of the software into two layers of testing: the first monitoring vote and the second monitoring vote. This method can achieve full coverage that meets the requirements without affecting the software state, and also facilitates the injection of fault states. Test cases with different signal sources are automatically generated through test case script generation, which reduces repetitive work and avoids errors in human test case design. The dynamic output result comparison of multiple signals is achieved simultaneously through automatic comparison of test results, which improves work efficiency.

[0094] Figure 1 This is a complete automated test flow chart for the redundancy management software. The specific implementation method is further described in detail below with examples.

[0095] Step 1: According to the interface volume of the requirement specification, the input signals are divided into electromechanical input, flight control input, and avionics input according to the different signal sources; then, according to the difference in fault status, the electromechanical input is divided into analog signals and enumeration signals, the flight control input is divided into analog signals, and the avionics input is divided into analog signals, discrete signals, and enumeration signals.

[0096] Step 2: Based on each signal source in step 1, take the fuel weight signal of the electromechanical system as an example for analysis. Write a test case automatic generation script according to the rule of traversing the device status, serdes link status, CCDL link status, system mode status, and signal status faults in sequence, and generate a set of test cases that meet all fault states for the fuel weight signal, such as Figure 2 shown.

[0097] Step 3: Batch load the test case set of all signals generated in step 2 onto the target machine to drive the redundancy management software to run.

[0098] Step 4: After setting the test run time to be longer than the execution time of the test case set for each signal, export the run results to the test result automatic comparison tool to generate a fixed-format test result comparison chart to observe whether the theoretical value of the first monitoring vote of the fuel weight is consistent with the actual value. The results are as follows: Figure 3 shown.

[0099] by Figure 3 Taking the test results as an example, it can be seen that the theoretical values ​​at the 3rd fault point and the 11th fault point are inconsistent with the actual values. Corresponding to the test case, it can be located that the monitoring voting logic of the device status failure and CCDL link failure is incorrect.

[0100] Step 5: Use the signal output of the first monitoring and voting test as the input of the second monitoring and voting test, and divide the input into analog signals, discrete signals, and enumeration signals according to the signal type. The corresponding relationship between the signal input of the first monitoring and voting test and the second monitoring and voting test is as follows: Figure 4 shown.

[0101] Step 6: Taking the fuel weight signal as an example, write a script for generating the second monitoring voting test case according to the rule of traversing the maximum value fault, minimum value fault, maximum second-largest fault, maximum minimum fault, second-smallest minimum fault, 2:2 fault, 1:1:1:1 fault, device status fault, link fault, and validity fault in sequence, and automatically generate the fuel weight second monitoring voting test case set, such as Figure 5 shown.

[0102] Step 7: Import the fuel weight second monitoring voting test case set into the simulation running environment to drive the redundancy management software to run.

[0103] Step 8: Set the test run time to be longer than the test case set run time. After the run is completed, import the test results into the test result automatic comparison script for automatic comparison. The results are as follows: Figure 6 shown.

[0104] According to the test results, the items where the theoretical value is inconsistent with the actual value are analyzed. Taking the first monitoring voting value of fuel weight as an example, it can be found that the voting results are wrong when the minimum value fault and 2:2 fault occur.

[0105] The automated testing method of the redundancy management software of the present application uses different test cases to automatically generate scripts to generate test case sets, which reduces the repetitive work of testers and avoids human errors introduced by testers due to too much test data; the test process is divided into the first monitoring and voting test and the second monitoring and voting test, which achieves a complete test of the requirements without changing the software architecture, and streamlines the intermediate links of the fault state test to facilitate fault injection; the test case set results of a large number of signals can be automatically compared at the same time through automatic comparison of test results, which saves test time and facilitates fault location; test case records that conform to the format can also be generated as an attachment to the test report. The present application is particularly suitable for functional testing in the early stage and regression stage of the development of the redundancy management software of the flight control system.

[0106] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions that can be easily thought of by a person skilled in the art within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be based on the protection scope of the claims.

Claims

1. An automated testing method for redundancy management software, characterized in that: include: Step 1: According to the interface volume of the requirement specification, the input signal is divided into different signal types according to the signal source and the difference of intermediate state; Step 2: For input signals of different signal types, write an automated test case generation script according to the value range of the input signal, signal fault type and state fault type, and generate the first monitoring voting test case set for each input signal; Step 3: Import the first monitoring voting test case set into the simulation running environment to drive the redundancy management software to run; Step 4: Set the test running time. After the test is finished, use the test result automatic comparison script to compare the first monitoring voting test results. Step 5: Using the output signal of the first monitoring and voting as the input signal of the second monitoring and voting, and dividing the input signal of the second monitoring and voting into different signal types; Step 6: For input signals of different signal types, write an automated test case generation script according to the value range of the input signal, the signal fault type and the state fault type, and generate a second monitoring voting test case set for each input signal; Step 7: Import the second monitoring and voting test case set into the simulation operation environment to drive the redundancy management software to run; Step 8: Set the test running time. After the test is completed, use the test result automatic comparison script to compare the second monitoring voting test results and generate a test report.

2. The automated testing method for redundancy management software according to claim 1, characterized in that: In step 1, according to the interface volume of the requirement specification, the input signal is divided into different signal types according to the signal source and the difference in intermediate state, including: According to the interface division requirements, input signals are divided into electromechanical signals, flight control signals, and avionics signals according to signal sources; According to the differences in intermediate states, the input signals from various signal sources are divided into: analog signals, discrete signals, and enumeration signals.

3. The automated testing method for redundancy management software according to claim 2, characterized in that: According to the differences in intermediate states, electromechanical signals are divided into: analog signals and enumeration signals.

4. The automated testing method for redundancy management software according to claim 3, characterized in that: According to the difference in intermediate states, the flight control signals are divided into: analog signals.

5. The automated testing method for redundancy management software according to claim 4, characterized in that: According to the differences in intermediate states, avionics signals are divided into: analog signals, discrete signals, and enumeration signals.

6. The automated testing method for redundancy management software according to claim 5, characterized in that: In step 2, when the input signal is an analog signal of an electromechanical signal, the input signal includes: Device status, serdes bus status, CCDL bus status, heartbeat word status, valid bit status, transition status.

7. The automated testing method for redundancy management software according to claim 6, characterized in that: In step 2, when the input signal is an enumeration signal of an electromechanical signal, the input signal includes: Device status, serdes bus status, CCDL bus status, heartbeat word status, transition status.

8. The automated testing method for redundancy management software according to claim 7, characterized in that: In step 2, when the input signal is an analog signal of a flight control signal, the input signal includes: Device status, serdes bus status, mode word status, valid bit status.

9. The automated testing method for redundancy management software according to claim 8, characterized in that: In step 2, when the input signal is an analog signal of an avionics signal, the input signal includes: TTFC status, valid bit status, illegal number status, transition status.

10. The automated testing method for redundancy management software according to claim 9, characterized in that: In step 2, when the input signal is a discrete signal of an avionics signal, the input signal includes: TTFC status, transition status.

11. The automated testing method for redundancy management software according to claim 10, characterized in that: In step 2, when the input signal is an enumeration signal of an avionics signal, the input signal includes: TTFC status, transition status.

12. The automated testing method for redundancy management software according to claim 11, characterized in that: In step 4, set the test run time to be longer than the run time of the first monitoring voting test case set.

13. The automated testing method for redundancy management software according to claim 12, characterized in that: In step 4, the test results of the first monitoring voting test are compared through the test result automatic comparison script, including: Import the first monitoring voting test results into the test result automatic comparison script to generate a test result comparison chart in a fixed format; Judging whether the theoretical value of the first monitoring voting test result is consistent with the actual value according to the test result comparison chart; If they are consistent, proceed to step five; If they are inconsistent, perform fault location.

14. The automated testing method for redundancy management software according to claim 13, characterized in that: In step five, the input signal of the second monitoring vote is divided into: analog signal, discrete signal, and enumeration signal.

15. The automated testing method for redundancy management software according to claim 14, characterized in that: In step six, when the input signal is an analog signal; Input signals include: maximum fault, minimum fault, maximum-second-maximum fault, maximum-minimum fault, second-minimum-minimum fault, 2:2 fault, 1:1:1:1 fault, device status, link status, and valid bit status.

16. The automated testing method for redundancy management software according to claim 15, characterized in that: In step six, when the input signal is a discrete signal; Input signals include: 0 fault, 1 fault, 2:2 fault, device status, link status, and valid bit status.

17. The automated testing method for redundancy management software according to claim 16, characterized in that: In step six, when the input signal is an enumeration signal; Input signals include: maximum fault, minimum fault, maximum-second-maximum fault, maximum-minimum fault, second-minimum-minimum fault, 2:2 fault, 1:1:1:1 fault, device status, link status, and valid bit status.

18. The automated testing method for redundancy management software according to claim 17, characterized in that: In step eight, the test running time is set to be greater than the running time of the second monitoring voting test case set.

19. The automated testing method for redundancy management software according to claim 18, characterized in that: In step eight, the second monitoring voting test results are compared through the test result automatic comparison script, including: Import the second monitoring voting test results into the test result automatic comparison script to generate a test result comparison chart in a fixed format; Judging whether the theoretical value of the second monitoring voting test result is consistent with the actual value according to the test result comparison chart; If they are inconsistent, perform fault location.

Images