## 2 Related Work
### Software Fault Localization  
Finding the location where a fault occurred during debugging is costly and time consuming [12]. Therefore, many studies have been conducted on fault localization methods. Among these methods,  
Figure 2: HiL test environment. there is a technique that finds errors by using information related to the operating elements of the program. Most methods are white-box-based methods that use a source code because a developer can find and fix the cause of the fault. Thus, there are memory-based studies performed using software footprints that can be applied to a black box without source code. There is a method that locates faults by measuring the code executed by the program [13; 14]. This method is called code-coverage-based fault localization (CBFL). Code coverage is one of the test measures, which means that codes are covered during testing. For each statement measured in each test case, suspected areas are calculated by coverage by pass or fail signals. The key idea is that the code executed in the failed test case is the cause of the failure. The CBFL method presents the rank of the statement in order of suspicion. Tarantula [13] and Ochiai [14] are typical methods used for calculating the suspicion of CBFL. However, the CBFL method is unsuitable for testers in OEM environments where the source code is difficult to obtain. There is also a mutation-based fault localization (MBFL) method that utilizes the mutation of the program. This method identifies suspected mutations and finds the point at which the fault occurred with the statement that caused the mutation [15; 16]. A mutation is created by modifying only one statement. The mutation applies the test case that the original performed and kills if the result is the same as the original. The remaining mutations are then mutations that affect the outcome. The MBFL method calculates suspicion with statements that affect the outcome. Typical methods include Metallaxis [15] and Museum [16]. The MBFL method has the disadvantage of creating impractical levels of mutation by creating multiple mutations in each statement in the original program. In order to solve this problem, studies have applied the CBFL method [17] or generate mutation efficiently through test case optimization [18]. However, the MBFL method still has a disadvantage in that it takes a significant amount of time to test with a large number of mutations. HiL testing is unsuitable because it is difficult to control the execution speed differently from software testing. In addition, there are fault location methods extended from the CBFL method that statistically access characteristic elements of program execution. In Reference [19], statistically defines the density and type of faults based on CBFL method and considers multiple faults present in the program as interference rather than individual approaches. And in Reference [20], the PageRank algorithm is applied to the existing CBFL method to weight the rank. These studies presented the statistical approach to test the results and the effects of source code on faults with density and rank weights. However, it is difficult to measure the covered source code in the HiL test, so the source-code-based methods are not applicable. However, analyzing the memory that has the execution trace of the program can grant access to the fault without the source code. One of the traditional debugging methods involves analyzing the memory dump. This method analyzes the behavior of the program based on how the memory is used at the OS level. However, this method should support a memory dump at the OS level and generally a memory dump occurs when the program terminates due to a serious fault. The HiL test does not know when a fault occurs and the HiL test cannot pause for the memory dump because the host PC, simulator and SUT work together according to the test script. Therefore, it is difficult to apply it directly to an ECU/SW HiL test.