## 1 Introduction
Figure 1: The process of developing automotive Electronic Control Unit (ECU) software. The memory information can be used in such an environment to provide fault-location information to developers [7]. This is because memory information is of the same type for each ECU, regardless of its interface. For example, a binary file is executed independently in each ECU in the associated environment that was developed based on AUTOSAR (AUTomotive Open System ARchitecture) or multiple ECUs. Therefore, a trace of the software that is independently executed with the platform is left in the ECU memory. Accordingly, this information can be used for each ECU in the same way. Also, memory use is independent between modules because each ECU developer determines the range of memory use before developing a module. Meanwhile, the fundamental reason that the memory can be used for fault localization is the Def and Use (DU) pair of variables in the source code, which leave \"footprints\" in the memory during program execution. For example, in the statement \"A = B\", which consists of variables A and B, A is defined as \"Def\" and B is defined as \"Use\" [8]. The memory update occurs in the memory address of the Def variable by combining memory interface commands such as LOAD, STORE, and MOVE when this statement occurs during program execution [9]. Thus, the most intuitive way to provide the location information of the fault to the developer using the memory update is to provide the pair of the updated addresses for fail test and fault time. By utilizing this information, developers are able to localize faults targeting the list of updated addresses at a particular time [10]. However, a disadvantage of this method is that it requires significant computational time and expense to localize a fault within an excess of memory updates. To overcome this, a method is required that can reduce the extent of potential fault locations by using the memory update information. In this paper, we propose such a method for reducing both time and expense, whose target is the data section of the memory. Fault localization can be divided into two parts. First, suspicious code is identified that may contain a fault. Next, the developer determines whether it actually contains a fault [11]. In this paper, fault localization refers to the task of finding candidates for faulty symbols (symbol name and address) by tracking the memory based on the suit of failed tests (binary source file, test case, and memory) from the HiL simulation. In order to reduce the extent of potential fault locations in the data section, we partition it using a memory map and the stack. Unlike a general memory map, the one used in automotive software includes information about the memory range to be used for each object file. This makes it possible to use the memory map to divide the data sections into object-file units. It is also possible to use the stack to divide the data section by predicting the information in a memory map. This is because the stack works by being divided into each functional unit while the automotive software is running. It is then possible to divide the data section by subjecting it to the unit information defined by the stack. The stack information is useful for dividing the data section because it is possible to apply the call relationships to the partitioned stack section, in much the same way as the call relationships that exist between functions in the source code. Meanwhile, there is the constraint that a developer has to transmit a memory map to a tester in the method by memory map. Therefore, we propose memory-map and stack methods that use only the memory information. Figure 2: Debugging information with/without source code. (**a**) Debugging information with source code; (**b**) debugging information without source code. In this way, we adopt the standpoint of the tester when locating faults that occurred during the integration test.