## 1 Introduction  
Approximately 90% of all recent car innovations are based on the automotive Electronic Control Unit (ECU) and its software. These include active/passive safety systems (e.g., airbags and collision avoidance), driver assistance systems (e.g., lane-departure warning and night vision), and infotainment systems (e.g., telephone, internet, and TV) [1]. However, as the number of ECUs in a car increases, the functional complexity of their software also increases. Accordingly, the likelihood of faults due to systematic ECU problems is increasing [2]. A car malfunction caused by a fault of an automotive ECU can threaten driver safety as well as create potential legal difficulties. In order to solve such problems, systematic testing/debugging techniques are required that ensure software reliability while taking its complexity into account [3]. Generally, finding the location of a fault requires significant amounts of time and effort [4]. However, the fault-location information available to developers of automotive software is currently too restrictive. Therefore, the problem is that it takes a large amount of effort and time to localize the faults. One way to solve this problem is to provide the developer with fault-location information during testing. In this paper, we propose a method whereby a tester of an automotive ECU can generate memory-location information about a potential fault during testing. The fundamental cause of this problem is original equipment manufacturer (OEM) systems in the automotive industry, as shown schematically in Figure 1. An OEM system means a series of steps in the process where developers and a tester perform development, testing, and debugging in independent environments. Firstly, an OEM designer provides the manufacturer's requirements to the developers working for each supplier. Each developer then develops an independent ECU based on these requirements, performs unit testing on it, and then delivers it to a tester in the OEM company. This tester receives the software in a binary form with the ECU in order to protect the corporate intellectual property (IP) rights, whereupon they perform black-box testing of each supplier's ECU and send the test results back to each relevant developer. Finally, each developer performs debugging based on these test results [5]. Unfortunately, there is relatively little information that is exchangeable between the OEM company and supplier companies because development and testing are performed in independent environments. The tester may find it difficult to locate the cause of a fault because he/she receives the software in a binary form (not as source code) because of IP protection. Therefore, developers find it difficult to locate faults because they do not receive location information about the faults that occurred during testing. This difficulty is shown by the dotted line of Figure 1. A tester performs black-box testing using an HiL simulator to assess whether the ECU functions correctly in accordance with the requirements [6]. Accordingly, it is impossible to find the source-code location of faults that occur during testing. Consequently, developers receive a test script and associated results that do not contain fault-location information. As shown in Figure 2a, a developer equipped with the source code can use it for purposes such as locating a fault, obtaining its description, establishing the list of called functions, and determining the pertinent value of each variable. However, as shown in Figure 2b, the test results currently give only information such as the name of the test script, the time of the test, the number of test cases, and pass/fail information. Therefore, developers who debug automotive software are at a disadvantage compared to those who perform debugging with the source code. Moreover, testers experience difficulties when debugging because they perform integration testing on independently developed ECUs with various types of interfaces.