## 6 Conclusions  
The proposed method collects memory data in the cycle of main task execution during the HiL test. Analyzing the updated information of collected memory and applying the sequential pattern-mining algorithm enables the acquisition of both the updated feature and updated memory patterns of software execution. The time of fault occurrence indicates that the frame sequence does not match the updated patterns of normal operation in the frame of the integration test where the fault occurs. The fault candidates are categorized into ranks of the featured addresses of the fault-occurrence sequence and the executed sequence. As a result of the experiment by fault injection, 80% of faults suggest the time of fault, and the fault candidates were localized to 3.28% on average. If 100 variables are used in the integration test, the fault can be found by checking only 3 variables before and after the fault occurred at the time of debugging. \begin{table}
\begin{tabular}{c c c c c c c c c c} \hline \hline \multirow{2}{*}{\begin{tabular}{c} **Fault** \\ **Index** \\ \end{tabular} } & \multirow{2}{*}{**Function**} & **Allocated Memory** & **Updated Address** & \multicolumn{2}{c}{**Number of Fault**} & \multirow{2}{*}{\
\begin{tabular}{c} **Frame** \\ **Candidates** \\ \end{tabular} } & \multirow{2}{*}{
\begin{tabular}{c} **Localization** \\ **(\%)** \\ \end{tabular} } & **Method** \\  & & **(Byte)** & & & **R1** & **R2** & **R3** \\ \hline
1 & Front Turn Signal & & 187 & **1** & 3 & 7 & 0 & 0.53 & 9(4.61\%) \\ \hline
2 & Head Lamp & 3714 & 195 & **1** & 1 & 7 & 0 & 0.51 & 14(7.18\%) \\
3 & Steering & & 200 & **1** & **1** & 4 & 1 & 1.00 & 4(2.00\%) \\ \hline
4,5 & AEBS & & 221 & 0 & 0 & **20** & - & 9.05 & 22(9.95\%) \\
6,7 & Driving Mode & & 179 & 0 & 0 & **17** & - & 9.50 & 13(7.26\%) \\ \hline
8 & Rear Turn Signal & & 170 & **1** & 3 & 5 & 0 & 0.59 & 9(5.29\%) \\
9 & Brake Lamp & & 132 & **2** & **4** & 6 & 1 & 4.55 & 75(3.03\%) \\
10 & ESS & 3711 & 289 & 2 & **4** & **4** & 4 & 3.46 & 9(3.11\%) \\
11 & Rear Alert & & 167 & 1 & 1 & **3** & 1 & 2.99 & 4(2.40\%) \\
12 & Adv. ESS & & 163 & **1** & 3 & 15 & 0 & 0.61 & 17(10.43\%) \\ \hline  & Average & & & & & & 0.875 & 3.28\% & 5.77\% \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Experimental result. The proposed method has the following advantages. First, fault-occurrence time is suggested in a black-box environment, where the source code is difficult to use and the memory address that causes the fault can also be detected. The proposed method, based on normal operation information, that acquires the unit test, can assess the difference in fault situations. Second, with the only automotive communication interface, it is possible to obtain debugging information, even without using existing debugging tools. The proposed method collects memory in the cycle of the main task period of the system, which has a comparable effect of observing the system without debugging tools. Third, the fault-occurrence time and cause of the fault are detected, based in the memory-updated features and the updated pattern of normal operation. Thus, those who perform the test can apply the proposed method even without any background knowledge about the execution flow of the software or the characteristics of the input and output signals. Therefore, the proposed method is based on the memory-updated features and updated patterns without source code or existing debugging tools, and determines not only the time of fault occurrence, but also the memory address responsible to the fault. The developer can thus reduce the time required for debugging. As our method considers the updated status, not to the saved value in the memory, in cases in which the saved value in a major address is updated to the wrong value, it is difficult to determine the time of the fault occurrence. Additionally, because we focus on the updated status, it is limited in the case in which the updated status is not important, like an analog signal, which is common.