## 5 Experimental Results
### Result Analysis & Validation  
Finally, the reduction rate of fault candidates by each method is as follows. We can confirm that both methods have relatively high rates. * Memory-map method
* Size of the data section in which memory updates occurred = 10,786 bytes
* Total size of the fault candidate region (top 18) = 1859 bytes
* Reduction rate of fault candidates = \((1859\div 10,786)\ \times\ 100\ (\%)=17.24\%\)
* Stack method
* Size of the data section in which memory updates occurred = 24,583 bytes
* Total size of the fault candidate region (top 10) = 6202 bytes
* Reduction rate of fault candidates = \((6202\div 24,583)\ \times\ 100\ (\%)=25.23\%\)  
Figure 14: FS ranking by stack. Figure 13: FS ranking by memory map. The fault candidate information refers to ranges of addresses in the memory. Thus, a fault candidate region has the list of symbols allocated to that address. In order to validate the results based on the symbol names for each fault candidate region, we use the symbol information of all memory addresses from each software developer. Based on this information, we confirmed the validity of the results in terms of the correlation between the input signal of the test script and the symbols in the fault candidate region, i.e., the similarity of names in Tables 3 and 4. This is because the cause of a fault is directly related to an input when the fault occurs during a test. Therefore, it is possible to find the cause of the fault by using the symbol information if the fault-candidate symbol is relevant to the input signal. The description of each column title in Tables 3 and 4 is as follows. * **Input signal in test script**: this is an input signal in the inspection range entering the ECU during the execution of the test using the HiL simulation. * **Symbol  
Table 3 shows the correlations between input signals and the symbols in fault candidate regions obtained by the memory map. These fault candidate regions contain the symbols related to 13 input signals of a total of 17 input signals. Table 4 shows the correlations between input signals and the symbols in fault candidate regions obtained by the stack. These fault candidate regions contain the symbols related to 16 inputs signals out of a total of 17 input signals. Of the fault candidate regions in Table 3, those with symbols actually related to input signals are objs. #20, #32, #39, and #44. This is because the symbols in regions other than these are only indirectly affected by the input signal. Therefore, these symbols could not be confirmed through name similarity alone. For the same reason, it was not possible to confirm everything by the stack. As a result, we could find the symbols related to 76% of the input signals by the memory map, and the symbols related to 94% of those by the stack. As can be seen from the results with the other data set in Table 5, similar results were obtained (approximately 75% and 92% on average). However, as seen by comparing Tables 3 and 4, there are differences between the symbol names obtained by the memory map and those obtained by the stack. These differences are illustrated in Figure 15. An input signal applied by the HiL simulator is transmitted internally through the virtual bus to the structure indicating the state information via software logic. In addition, a fault candidate region identified by the memory map includes the symbols of the structure indicating the actual ECU state receiving the input signal; one identified by the stack includes the symbols of the external input signals delivered through the virtual bus. This difference is due to memory information being captured by the operating cycle of the operating system, so the stack information at each time point cannot be obtained via software. Accordingly, there is a limit to directly finding the cause of faults compared to the memory-map method due to losing the stack information.