## 1 Introduction
Owing to the nature of these computer systems, the footprints of important data remain in memory when the software is executed. The method used to analyze the memory dump is involving analyzing the stack and variables at the moment when the fault occurred [8]. However, in the HiL test,  
Figure 1: Development and testing processes of ECU/SW by OEM. ECU/SW: electronic control unit/automotive software; OEM: original equipment manufacturers; HiL: Hardware-in-the-Loop. a test failure occurs when the output of the ECU does not meet the expected value. Therefore, the test failure determination and the occurrence of the fault may manifest at different times and it is difficult to dump the memory by specifying the fault occurrence timing. Accordingly, the memory dump-based debugging method cannot be applied as-is to the HiL test. If it is applied to the HiL test, it is necessary to trace both the updated memory data during the test and the timing information on the fault occurrence. For that reason, in the preliminary work [9], we developed a fault localization method that utilizes an updated data frequency when the failure occurs. However, all update symbols derived by the input without a clear criterion are presented as fault candidates. There is no guarantee that an updated symbol will be associated with a fault while the input is reflected. In the opposite case, if the test fails because important symbols are not updated, the defect candidate will not include the symbol because it has no update frequency. Therefore, in addition to the memory update information available at the time of the fault, a criterion for judging abnormal operation is required. If it is possible to obtain the memory usage information from the ECU during normal operation, it can serve as reference information to be observed in order to judge the cause of the fault in the memory-updated information acquired at the time of fault. In this paper, we propose a method of fault localization for automotive software in an HiL environment. This is accomplished by comparing analysis results of updated memory between a normal unit test and a failed integration test without the source code. First, analyzing the memory usage of the unit test in normal operation can identify the memory update information required for the operation on the function, such as used memory addresses, corresponding symbols, stored values and updated frequency. The memory usage information of the identified unit test is compared with the memory usage information at the time of the fault. The symbols necessary for the operation of the specific function are compared and presented as fault candidates (Invalid updated or fixed symbols and stored values). As a result, a tester at the OEM can provide the developer with the fault occurrence time, malfunctioning symbols and stored values during an integration test in the HiL environment. He can accomplish this by using the operation information from the unit test without the source code and the debugging tools. The proposed method is applied to an HiL test of an OSEK/VDX-based ECU/SW. As a result of testing using fault injection, we confirmed that fault causes can be found by checking the localized memory symbols at an average of 5.77% by the proposed method. In addition, when applying this methodology to a failure that occurred during a body control module (BCM) (which provides seat belt warnings) test, we could identify suspicious symbols and find the cause of the test failure with only 8.54% of localized memory symbols. In this paper, we can provide debugging information for suspicious symbols and memory usage in an ECU/SW integration test in the HiL environment. This paper is organized as follows. In Section 2, we analyze HiL test limitations and existing fault localization methods. In Section 3, we define the process of fault localization and the memory-updated information that can be collected during HiL testing of ECUs.