## 1 Introduction  
As the number of electronic control units (ECU) in automobiles increases, so does the functional complexity of automotive software. Therefore, the possibility of systemic ECU problems also increases [1]. Thus, testing has become a key process in the development of vehicle ECUs. The automobile industry develops and manufactures the electronics and their software via original equipment manufacturers (OEMs). Accordingly, a tester for the automobile company conducts an acceptance or integration test on the ECU and automotive software (ECU/SW) developed by a separate manufacturing company [2]. Figure 1 shows the process of electronic component development and testing utilized by the automotive industry and OEMs. The developer receives the requirement from the designer and develops the ECU/SW. The tester receives the developed ECU/SW and uses the Hardware-in-the-Loop (HiL) simulator to test unit or integrated functions without source code. The faults detected during the test are then reported to the developers for modification [3]. At this time, the test results that the tester reports include only the test script and the corresponding pass/fail information (i.e., the expected  
value for a test condition and the actual output value of the ECU/SW). Therefore, the developers need to rebuild the same testing scenario to correct the reported failure. If the tester can provide debugging information on the internal operations when a failure occurs, the developer can easily resolve the cause of the failure [4]. When developing embedded systems such as ECUs, developers can use existing debugging tools to obtain internal operating information on particular software failures. However, those tools are not available for the HiL testing of ECU/SWs for vehicles that the tester conducts for the following reasons. First, an in-circuit emulator (ICE, for example, Trace32, Multi-ICE), which is generally used as a debugging tool in an embedded system, requires a dedicated connector as a debugging interface. In the case of a completed ECU, the debugging interface is rarely exposed to the exterior of the component. If the debugging interface is not taken into consideration from the design stage of the ECU, the debugging tool cannot be used to check internal operation during an ECU/SW HiL test [5]. Second, even if the ECU is modified to connect the debugging interface, internal operation monitoring using debugging tools is unsuitable for the HiL test environment. The HiL test is based on a test scenario of the test script and the host PC, the HiL simulator and the ECU/SW are organically executed. In order to apply the method of step by step observation of the software using the break point with the existing debugger, the entire HiL test environment should be suspended. Accordingly, it is impractical to use the debugging tool to pause and observe a suspected buggy spot on a running system [6]. There are studies that use software fault localization methods to acquire information needed for debugging without directly using a debugging tool. The conventional method of software fault localization has evolved to find faults efficiently based on source code [7]. However, the tester tests the ECU/SW in a black box without source code. As a result, it is difficult to apply the conventional source-code-based method of to HiL testing. Therefore, in order to understand the internal operation when a fault occurs during the HiL test, a method that does not use the source code and the debugger are needed without affecting the test flow performed on the test script basis. Memory dump analysis can be used as a way to find the cause of a fault without the source code. In the data-flow analysis, it is called DU chains (or DU pairs), where data is defined (D) and then used (U) (i.e., \"A = B + C\"; A is \"define;\" B and C are \"use\"). Therefore, according to the DU chain, the results of all right-hand side (RHS) expressions processed by the CPU are stored on the left-hand side (LHS).