A Proposal of Fault Tree Analysis for Embedded Control Software

: There are many industrial products in our life, and the actions of those products are controlled by embedded control software (ECSW). Recently, many troubles have been caused by ECSW. To avoid those troubles, it is necessary to clarify the causes of the troubles and take countermeasures. However, the results of those tasks depend on the skills of the analyst. This paper proposes an analytic method that clariﬁes the causes of troubles by applying fault tree analysis (FTA) to the ECSW. The characteristics of the proposed method are as follows: Preparation of fault tree templates (FTTs) corresponding to instructions of the ECSW, and deﬁnition of the FT development rules by combining FTTs according to the back-tracing of the instruction execution process. By complying with the proposed method strictly, when an analyst who has studied computer science and safety engineering for 2–3 years conducts FTA, the analyst can obtain an appropriate result of FTA. This indicates that the safety level of ECSW will improve. As a result of applying the proposed method to existing ECSWs, we ﬁnd that we can obtain the result of FTA at the appropriate level. and FDR, and propose an FTA method. a result of the proposed to the top of the existing ECSWs, we FTs and fundamental These show the e ﬀ ectiveness of proposed and support tool. In the proposed method, as we developed the FT complying with the application of the FTTs and FDR, the quality of FT information improved. Additionally, we improved the level of understanding within the appropriate time. In the future, we shall apply the proposed method to large-scale ECSW, and feed-back the results into the proposed method.


Introduction
This paper proposes an analysis method of unexpected events (top events) caused in embedded control software (ECSW) for industrial products written in the C language. The proposed method realizes a safe ECSW by analyzing the causes of a top event and taking countermeasures.
Industrial products dealt with by this paper are home electronic products, medical equipment, product facilities, automobiles, aircrafts, space equipment, etc. ECSW is software that controls motions of an industrial product. We assume that the target ECSW has the following characteristics: Working on a single-chip CPU with a single-core, having several thousands of lines of code (KLOC), written in the C language, and not using newly developed technologies. The reason those assumptions are adopted is as follows: The rate of usage of the single-core CPU is about 60%, the median of lines of code (LOC) is 6.7 KLOC, the rate of usage of the C language is about 60%, and the rate of development without newly developed technologies is 80% [1]. The reason the median of LOC is used is as follows: Even the LOC of ECSW is distributed from 0.1 to 1551 KLOC, the average of the LOC is 41 KLOC, and the rate of ECSW with over 50 KLOC is under 10%. Additionally, as the large-scaled ECSW is built by combining several control equipment using a network and/or data-bus, the LOC of ECSW installed into individual equipment is nearly the same as the LOC of the target ECSW. Fault tree analysis (FTA) is a safety analysis method that identifies the causes of a top event (fundamental events) by tracing logical relationships between a top event and its causes. In FTA, the logical relationships between a top event and fundamental events are shown as tree structures called the fault tree (FT).

Overview of the Proposed Method
In this subsection, we provide an overview of the ECSW top event occurrence process, the FT Template, the FT development rules, and the proposed method.

Execution Process of the Top Event
First, we explain the top event of ECSW. In general, when conducting FTA for an embedded system, the system-level FTA for the fault is conducted, and the faults (the top event) for hardware and software are clarified. The system-level FTA is shown in Figure 2. The proposed method is applied to the software fault. The software fault is considered as follows: The value of the specific variable is too large or small, and the function cannot invoke or cannot terminate, etc.
Next, we explain the occurrence process of the top event. We describe the process by which top events occur in the ECSW. First, we assume the ECSW operates normally until a certain instruction is executed. Then, after the next instruction is executed, it is assumed that a slight deviation occurs from the normal state and a top event occurs when executing the n-th instruction. Here, the j-th executed instruction is described as I j , and the j-th occurring event as <Event j >. The sequence of instructions and events from the time at which the fundamental event occurs to the time at which the top event occurs can be described as follows. This is referred to as an execution process. The execution process includes a return from interruption, branches by a condition branch instruction, and confluences by a repeat instruction. For example, the execution process of I 101 in Figure 1 shows a return from interruption, and <Event2 201 > shows the branch by the condition branch instruction.
Information 2020, 11, x FOR PEER REVIEW 4 of 23

Proposed FTA Method
In this section, we describe the proposed method, the FT template, the FT development rules, and the FT support tool, which are described in Sections 3.1-3.4, respectively.

Overview of the Proposed Method
In this subsection, we provide an overview of the ECSW top event occurrence process, the FT Template, the FT development rules, and the proposed method.

Execution Process of the Top Event
First, we explain the top event of ECSW. In general, when conducting FTA for an embedded system, the system-level FTA for the fault is conducted, and the faults (the top event) for hardware and software are clarified. The system-level FTA is shown in Figure 2. The proposed method is applied to the software fault. The software fault is considered as follows: The value of the specific variable is too large or small, and the function cannot invoke or cannot terminate, etc.
Next, we explain the occurrence process of the top event. We describe the process by which top events occur in the ECSW. First, we assume the ECSW operates normally until a certain instruction is executed. Then, after the next instruction is executed, it is assumed that a slight deviation occurs from the normal state and a top event occurs when executing the n-th instruction. Here, the j-th executed instruction is described as Ij, and the j-th occurring event as <Eventj>. The sequence of instructions and events from the time at which the fundamental event occurs to the time at which the top event occurs can be described as follows. This is referred to as an execution process. The execution process includes a return from interruption, branches by a condition branch instruction, and confluences by a repeat instruction. For example, the execution process of I101 in Figure 1 shows a return from interruption, and <Event2201> shows the branch by the condition branch instruction.

FT Templates and FT Development Rules
Here, we describe the FT Template and FT development rules. With <Eventn> and In as the starting point of Figure 1, if we perform reverse-tracking on the execution process, we can reach <Event1> and I1. Therefore, a method for determining Ij-1, which is a precondition for executing Ij, is defined as the FT Development Rules (FDRs). Additionally, the relationship between the change from <Eventj> to <Eventj-1> before and after executing Ij is defined as the FT Template (FTT). Hereafter, from the perspective of simplifying the understanding of the explanation of the algorithm, the top event is defined as <Event1>, the instruction generating this as I1, the fundamental event as <Eventn>, and the instruction generating this as In by numbering the index in reverse order. The suffix j in Ij and <Eventj> is used to identify them uniquely and does not mean the order of execution.

Outline of the Proposed Method
To conduct FTA for the ECSW using the proposed method, it is necessary to decide the top event and instruction that causes the top event. There are two types of top events. One is the top event that is caused by the ECSW itself; the other is the top event that is caused by the combination of the hardware's action and ECSW's behavior under specific conditions. The former events are as follows:

FT Templates and FT Development Rules
Here, we describe the FT Template and FT development rules. With <Event n > and I n as the starting point of Figure 1, if we perform reverse-tracking on the execution process, we can reach <Event 1 > and I 1 . Therefore, a method for determining I j-1 , which is a precondition for executing I j , is defined as the FT Development Rules (FDRs). Additionally, the relationship between the change from <Event j > to <Event j-1 > before and after executing I j is defined as the FT Template (FTT). Hereafter, from the perspective of simplifying the understanding of the explanation of the algorithm, the top event is defined as <Event 1 >, the instruction generating this as I 1 , the fundamental event as <Event n >, and the instruction generating this as I n by numbering the index in reverse order. The suffix j in I j and <Event j > is used to identify them uniquely and does not mean the order of execution.

Outline of the Proposed Method
To conduct FTA for the ECSW using the proposed method, it is necessary to decide the top event and instruction that causes the top event. There are two types of top events. One is the top event that is caused by the ECSW itself; the other is the top event that is caused by the combination of the hardware's action and ECSW's behavior under specific conditions. The former events are as follows: The overflow and underflow of the variable, and non-formation of the conditions for starting and stopping the function. The instructions that cause such top events are as follows: The instruction that calculates the value of the variable, and the instruction that executes and terminates Information 2020, 11, 402 5 of 22 the specific function. The latter events are not needed, as the ECWS's behavior itself is inappropriate. By conducting the system-level safety analysis (FMEA and/or STPA, etc.) for the industrial product, it is necessary to clarify the combination of both the hardware's action and ECSW's behavior under the specific condition (the system-level safety analysis is beyond this research). These top events are as follows: The value of the variable exceeds the threshold, and it either invokes or does not invoke the specific function under the specific conditions. Those instructions that cause those top events are the same as the instructions such that the ECSW itself causes the top event. In the following explanation, it is assumed that the ECSW's top event and instructions have already been identified. Figure 2 shows an overview of the proposed method that consists of the preparation stage and the development stage. In the preparation stage, we analyze the existing ECSW, and develop a FTT for instructions used with a high degree of frequency (described later in Section 3.2). In addition, we define the FDR (described later in Section 3.3). The FT corresponding to the top event is developed during the development stage. First, the top event and the instruction that causes the top event are defined by conducting system-level safety analysis. Next, pre-processing is performed in the ECSW to be analyzed. During pre-processing, instructions for which FTT has not been prepared are replaced with instructions for which the equivalent FTT has been prepared. Third, the pre-processed ECSW is analyzed, and the ECSW information required for FTA is extracted. Finally, based on the last pre-processed ECSW, the top event, the ECSW information, the FTT, and the FDR are used to develop the FT. The reason the pre-processing is performed is that it is difficult to prepare FTT for all instructions in the C language in the view of cost. When new frequently used instructions appear, the FTTs for these instructions are developed and added. As FTT only stipulates the relationship between the events before and after executing the instruction, there is no impact on existing FTTs and the FDR. The overflow and underflow of the variable, and non-formation of the conditions for starting and stopping the function. The instructions that cause such top events are as follows: The instruction that calculates the value of the variable, and the instruction that executes and terminates the specific function. The latter events are not needed, as the ECWS's behavior itself is inappropriate. By conducting the system-level safety analysis (FMEA and/or STPA, etc.) for the industrial product, it is necessary to clarify the combination of both the hardware's action and ECSW's behavior under the specific condition (the system-level safety analysis is beyond this research). These top events are as follows: The value of the variable exceeds the threshold, and it either invokes or does not invoke the specific function under the specific conditions. Those instructions that cause those top events are the same as the instructions such that the ECSW itself causes the top event. In the following explanation, it is assumed that the ECSW's top event and instructions have already been identified. Figure 2 shows an overview of the proposed method that consists of the preparation stage and the development stage. In the preparation stage, we analyze the existing ECSW, and develop a FTT for instructions used with a high degree of frequency (described later in Section 3.2). In addition, we define the FDR (described later in Section 3.3). The FT corresponding to the top event is developed during the development stage. First, the top event and the instruction that causes the top event are defined by conducting system-level safety analysis. Next, pre-processing is performed in the ECSW to be analyzed. During pre-processing, instructions for which FTT has not been prepared are replaced with instructions for which the equivalent FTT has been prepared. Third, the pre-processed ECSW is analyzed, and the ECSW information required for FTA is extracted. Finally, based on the last preprocessed ECSW, the top event, the ECSW information, the FTT, and the FDR are used to develop the FT. The reason the pre-processing is performed is that it is difficult to prepare FTT for all instructions in the C language in the view of cost. When new frequently used instructions appear, the FTTs for these instructions are developed and added. As FTT only stipulates the relationship between the events before and after executing the instruction, there is no impact on existing FTTs and the FDR.

FT Templates
In this subsection, we discuss FTTs. In this research, we analyze the existing ECSW, and prepare FTTs for nine types of frequently used instructions. The reason we analyze the existing ECSW is that the instructions frequently used in FTA and their FTT can be revealed because the ECSW does not

FT Templates
In this subsection, we discuss FTTs. In this research, we analyze the existing ECSW, and prepare FTTs for nine types of frequently used instructions. The reason we analyze the existing ECSW is that the instructions frequently used in FTA and their FTT can be revealed because the ECSW does not use the newly developed technologies. Additionally, as the FTT shows only the relationship between events before and after the execution of the instructions, the addition of new FTTs does not affect other existing FTTs. In Figure 3, we show the symbols used in FTT. As the symbols used for the supplementary explanation are only shown in the notes, these do not affect the meaning of the FT.
Information 2020, 11, x FOR PEER REVIEW 6 of 23 use the newly developed technologies. Additionally, as the FTT shows only the relationship between events before and after the execution of the instructions, the addition of new FTTs does not affect other existing FTTs.
In Figure 3, we show the symbols used in FTT. As the symbols used for the supplementary explanation are only shown in the notes, these do not affect the meaning of the FT.  Figure 4 shows the FTT for the assignment (variable = expression (value)). This FTT indicates that an assignment causes an event when the substituted value generates an event, or the operator generates an event. This FTT is the same as the FTT in [12].  . This FTT indicates that the block if statement generates an event in the case one or more events occur within the condition node. Furthermore, an event occurs in the case "the i-th condition node is established" and "the i-th process causes an event," or in the cases the "else node is established" and the "else node processing causes an event."     Figure 4 shows the FTT for the assignment (variable = expression (value)). This FTT indicates that an assignment causes an event when the substituted value generates an event, or the operator generates an event. This FTT is the same as the FTT in [12].

FTT for Assignment Statement
Information 2020, 11, x FOR PEER REVIEW 6 of 23 use the newly developed technologies. Additionally, as the FTT shows only the relationship between events before and after the execution of the instructions, the addition of new FTTs does not affect other existing FTTs.
In Figure 3, we show the symbols used in FTT. As the symbols used for the supplementary explanation are only shown in the notes, these do not affect the meaning of the FT.  Figure 4 shows the FTT for the assignment (variable = expression (value)). This FTT indicates that an assignment causes an event when the substituted value generates an event, or the operator generates an event. This FTT is the same as the FTT in [12].  . This FTT indicates that the block if statement generates an event in the case one or more events occur within the condition node. Furthermore, an event occurs in the case "the i-th condition node is established" and "the i-th process causes an event," or in the cases the "else node is established" and the "else node processing causes an event."     . This FTT indicates that the block if statement generates an event in the case one or more events occur within the condition node. Furthermore, an event occurs in the case "the i-th condition node is established" and "the i-th process causes an event," or in the cases the "else node is established" and the "else node processing causes an event." Information 2020, 11, x FOR PEER REVIEW 6 of 23 use the newly developed technologies. Additionally, as the FTT shows only the relationship between events before and after the execution of the instructions, the addition of new FTTs does not affect other existing FTTs.

FTT for Assignment Statement
In Figure 3, we show the symbols used in FTT. As the symbols used for the supplementary explanation are only shown in the notes, these do not affect the meaning of the FT.  Figure 4 shows the FTT for the assignment (variable = expression (value)). This FTT indicates that an assignment causes an event when the substituted value generates an event, or the operator generates an event. This FTT is the same as the FTT in [12].  . This FTT indicates that the block if statement generates an event in the case one or more events occur within the condition node. Furthermore, an event occurs in the case "the i-th condition node is established" and "the i-th process causes an event," or in the cases the "else node is established" and the "else node processing causes an event."     Figure 6 shows the FTT for the while statement (while (condition) {statement}). This FTT shows that the while statement causes an event in the case "the event occurs because the while statement is not executed," or "the event occurs because the while statement is executed." The former expresses cases in which the while statement is not executed while the repeated conditions are not established, whereas the latter shows that the repeated conditions are established, and the event occurs because the statement execution is repeated n-times (including the repeat limit in a while loop). This FTT is similar to the FTT in [12]. Figure 6 shows the FTT for the while statement (while (condition) {statement}). This FTT shows that the while statement causes an event in the case "the event occurs because the while statement is not executed," or "the event occurs because the while statement is executed." The former expresses cases in which the while statement is not executed while the repeated conditions are not established, whereas the latter shows that the repeated conditions are established, and the event occurs because the statement execution is repeated n-times (including the repeat limit in a while loop). This FTT is similar to the FTT in [12].  Figure 7 shows the FTT for the function call statement. This FTT expresses the fact that the function call statement generates an event in the case the function parameters generate an event, or the function is not appropriately started. This FTT is similar to the FFT in [12].  Figure 8 shows the FTT for the interrupt. This FTT expresses the fact that an interrupt generates an event in the case "the event occurs when the interrupt occurs," or "the event occurs because the interrupt does not occur." The former refers to the case where the interrupt is generated, and as the interrupt routine is executed, the event occurs. The latter can be divided into cases where the interrupt is not generated and cases where it is disabled. In cases where the interrupt is not generated, this expresses cases in which the interrupt does not occur, and because the interrupt routine is not executed, the event occurs. Cases where the interrupt is disabled express cases where the event occurs because the interrupt is disabled (prohibited).   Figure 7 shows the FTT for the function call statement. This FTT expresses the fact that the function call statement generates an event in the case the function parameters generate an event, or the function is not appropriately started. This FTT is similar to the FFT in [12].  Figure 6 shows the FTT for the while statement (while (condition) {statement}). This FTT shows that the while statement causes an event in the case "the event occurs because the while statement is not executed," or "the event occurs because the while statement is executed." The former expresses cases in which the while statement is not executed while the repeated conditions are not established, whereas the latter shows that the repeated conditions are established, and the event occurs because the statement execution is repeated n-times (including the repeat limit in a while loop). This FTT is similar to the FTT in [12].  Figure 7 shows the FTT for the function call statement. This FTT expresses the fact that the function call statement generates an event in the case the function parameters generate an event, or the function is not appropriately started. This FTT is similar to the FFT in [12].  Figure 8 shows the FTT for the interrupt. This FTT expresses the fact that an interrupt generates an event in the case "the event occurs when the interrupt occurs," or "the event occurs because the interrupt does not occur." The former refers to the case where the interrupt is generated, and as the interrupt routine is executed, the event occurs. The latter can be divided into cases where the interrupt is not generated and cases where it is disabled. In cases where the interrupt is not generated, this expresses cases in which the interrupt does not occur, and because the interrupt routine is not executed, the event occurs. Cases where the interrupt is disabled express cases where the event occurs because the interrupt is disabled (prohibited).   Figure 8 shows the FTT for the interrupt. This FTT expresses the fact that an interrupt generates an event in the case "the event occurs when the interrupt occurs," or "the event occurs because the interrupt does not occur." The former refers to the case where the interrupt is generated, and as the interrupt routine is executed, the event occurs. The latter can be divided into cases where the interrupt is not generated and cases where it is disabled. In cases where the interrupt is not generated, this expresses cases in which the interrupt does not occur, and because the interrupt routine is not executed, the event occurs. Cases where the interrupt is disabled express cases where the event occurs because the interrupt is disabled (prohibited). 3.2.6. FTT for Global Variables Figure 9 shows the FTT for the global variables. Global variables can exist anywhere within the ECSW. This FTT expresses the fact that in cases where a global variable causes the event, there is a relationship with one or more instructions in which the used global variable is set for the value. 3.2.6. FTT for Global Variables Figure 9 shows the FTT for the global variables. Global variables can exist anywhere within the ECSW. This FTT expresses the fact that in cases where a global variable causes the event, there is a relationship with one or more instructions in which the used global variable is set for the value.  Figure 9 shows the FTT for the global variables. Global variables can exist anywhere within the ECSW. This FTT expresses the fact that in cases where a global variable causes the event, there is a relationship with one or more instructions in which the used global variable is set for the value.   Figure 11 shows the FTT for an array. This FTT expresses the fact that "index of the array becomes less than 0," "the array causes the event when the N-th element does not exist (out of range, illegal index access)," or "the value stored in the N-th element is inappropriate."   3.2.6. FTT for Global Variables Figure 9 shows the FTT for the global variables. Global variables can exist anywhere within the ECSW. This FTT expresses the fact that in cases where a global variable causes the event, there is a relationship with one or more instructions in which the used global variable is set for the value.   Figure 11 shows the FTT for an array. This FTT expresses the fact that "index of the array becomes less than 0," "the array causes the event when the N-th element does not exist (out of range, illegal index access)," or "the value stored in the N-th element is inappropriate."  3.2.8. FTT for Array Figure 11 shows the FTT for an array. This FTT expresses the fact that "index of the array becomes less than 0," "the array causes the event when the N-th element does not exist (out of range, illegal index access)," or "the value stored in the N-th element is inappropriate."

FTT for Array
Information 2020, 11, x FOR PEER REVIEW 9 of 23 Figure 11. FTT for array.
3.2.9. FTT for Pointer Figure 12 shows the FTT for a pointer. This FTT expresses the fact that the pointer causes an event when the address referenced by the pointer does not exist, the address is referenced by the other pointer, or the value stored in the address referenced by the pointer is inappropriate.  3.2.9. FTT for Pointer Figure 12 shows the FTT for a pointer. This FTT expresses the fact that the pointer causes an event when the address referenced by the pointer does not exist, the address is referenced by the other pointer, or the value stored in the address referenced by the pointer is inappropriate. 3.2.9. FTT for Pointer Figure 12 shows the FTT for a pointer. This FTT expresses the fact that the pointer causes an event when the address referenced by the pointer does not exist, the address is referenced by the other pointer, or the value stored in the address referenced by the pointer is inappropriate.

FTT for Hierarchical Instruction
Here, we shall discuss an FTT when an instruction is hierarchically combined. Hereinafter, we refer to this kind of instruction as a hierarchical instruction. For example, an instruction where a tracked instruction exists within a controlled instruction, such as a block if instruction or while instruction, etc., is a hierarchical instruction. In this case, the controlled instruction including the tracked instruction is seen as one instruction, and to express that targeted instruction is executed when the conditions in the controlled instruction are established, FFTs are combined in the order of controlled instruction to targeted instruction. If the hierarchical instruction has three or more layers, the hierarchical instruction is seen as being within the scope of the furthest external instruction, and it connects the FTT from the furthest external instruction to the nearest internal instruction. At this time, the layer number for the furthest external layer is referred to as Lmax, and the nearest internal hierarchical instruction is set to "1." The method of developing the FT for the hierarchical instruction is explained later under FT development rules in Section 3.3.

FT Development Rules
In this subsection, we discuss static program slicing (hereinafter, slicing) used to determine instructions executed just before the instruction being executed. Next, we discuss the ECSW information required for executing FTA. Third, we discuss FT development rules. Finally, we discuss FTA support tools.

Slicing
Slicing is a method of extracting all instructions that impact the calculation results for the variables focused on in the program, and the extracted instruction groups are called slices [24]. When the same input is applied to the original program and the slice, the calculation results for the variable

FTT for Hierarchical Instruction
Here, we shall discuss an FTT when an instruction is hierarchically combined. Hereinafter, we refer to this kind of instruction as a hierarchical instruction. For example, an instruction where a tracked instruction exists within a controlled instruction, such as a block if instruction or while instruction, etc., is a hierarchical instruction. In this case, the controlled instruction including the tracked instruction is seen as one instruction, and to express that targeted instruction is executed when the conditions in the controlled instruction are established, FFTs are combined in the order of controlled instruction to targeted instruction. If the hierarchical instruction has three or more layers, the hierarchical instruction is seen as being within the scope of the furthest external instruction, and it connects the FTT from the furthest external instruction to the nearest internal instruction. At this time, the layer number for the furthest external layer is referred to as L max , and the nearest internal hierarchical instruction is set to "1." The method of developing the FT for the hierarchical instruction is explained later under FT development rules in Section 3.3.

FT Development Rules
In this subsection, we discuss static program slicing (hereinafter, slicing) used to determine instructions executed just before the instruction being executed. Next, we discuss the ECSW information required for executing FTA. Third, we discuss FT development rules. Finally, we discuss FTA support tools.

Slicing
Slicing is a method of extracting all instructions that impact the calculation results for the variables focused on in the program, and the extracted instruction groups are called slices [24]. When the same input is applied to the original program and the slice, the calculation results for the variable that is being focused on shall be the same. A slice is a collection of all instructions with the control dependency on the focused instruction and with the data dependency on the variables included in the focused instruction. Here, a data dependency from I s to I t means that the variable values set in I s can be referenced with I t . A control dependency from I s to I t means that I s is a branched instruction, and I t is included within that branch, or I s is a repeated instruction, and I t is included within the repetitions. The data dependency and control dependency from I s to I t are described respectively as DD(I s ) → I t , CD(I s ) → I t . Furthermore, I s and I t can be expressed as "instruction line number + target variable." Here, to obtain the instruction I n that generated <Event n > from I 1 that generated <Event 1 >, you need to follow the reverse-direction data dependency and reverse-direction control dependency. Instructions with a reverse-direction data dependency have the I s set for the value referenced by I t and the instructions with a reverse-direction control dependency have branches in which I t is included or a repetitive I s . From here, these are described as RDD(I t ) → I s , and RCD(I t ) → I s , respectively. These can obtain the data dependency and control dependency, respectively. In general terms, the correspondences from I t to I s are one-to-many. Table 1 shows a list of information extracted from ECSW. This information is input into the FTA support tool.

FT Development Rules
Here, we explain the terms used in the FT Development Rules (FDR). The event at the top of each FTT (event immediately after executing the instruction) is referred to as the Top Event (TEvent), and the event at the bottom (event immediately before executing the instruction) is referred to as the Bottom Event (BEvent). The FTT has one TEvent and multiple BEvents. In addition, Φ expresses the FT initial state, and it only has one joint TEvent and BEvent. If Null is entered in the BEvent, this indicates that the event can no longer be tracked. Figure 13 shows an overview of the FDR. The FT under development (dFT) refers to the FT being developed. After the first time that Φ is set for dFT, the FT setting is expressed with "→". Next, we determine <Event 1 > and I 1 , and set <Event 1 > for the dFT initial state BEvent 1 . Here, <Event 1 > is a software fault resulting from the system-level FTA and I 1 is the instruction that causes the <Event 1 >. Furthermore, FTs are developed until the content of all BEvents in dFT are Null. At this time, the FT is the completed version of the FT. in the BEvent or the partial FT within the hierarchical instruction. First, in step 1 of Figure 14, Φ is substituted for wFT and initialized. Next, in step 2, the instructions included in the wFT BEvent are acquired, and a partial FT related to the instruction is developed. The development of the FT can be classified into cases where the instruction is a hierarchical instruction (RCD(I) not = φ + φ), as shown in step 2.1, or is a non-hierarchical instruction (RDD(I) = φ + φ), as shown in step 2.2. Here, φ + φ means the instruction line number and the target variable does not exist. In the case of a hierarchical instruction, the FTT of instruction for each layer is combined from the most outer layer (hierarchy Lmax) to the most inner layer.
Step 2.1.1 obtains the hierarchical instruction in which Ig is included and calculates the Lmax, which is the maximum layer of the hierarchical instruction and layer L where Ig exists. In step 2.1.3, the FTT corresponding to Ig is regarded as wFT. In step 2.1.4, BEvent in dFT is regarded as TEvent in wFT.
Step 2.1.5 calculates all the BEvents in wFT.
Step 2.1.6 combines the FTT for the global variable with wFT when the BEvent includes the global variables, and the FTT for local variables with wFT when the BEvent includes the local variables, and then wFT is combined with dFT. Finally, in step 2.1.7, this operation is repeated until it reaches a hierarchy in which the instruction being tracked exists. Next, the wFT is joined to the dFT to develop a new dFT. In the case it is not a hierarchical instruction, the FTT for this instruction is joined to the wFT, and, in a way, similar to the hierarchical instruction case, the FTT for global variables or local variables is combined with the wFT and, if necessary, the contents of the TEvent and the BEvents are modified. Then, the wFT is combined with the dFT to make a new dFT. Finally, in step 3, the developed dFT is returned.   Figure 14 shows the development procedure for the FT under operation corresponding to the dFT BEvent (wFT) (section of dFT within Figure 14). Figure 14 describes the details in the module, while the development of FT (dFT) is described in Figure 13. wFT refers to the instructions included in the BEvent or the partial FT within the hierarchical instruction. First, in step 1 of Figure 14, Φ is substituted for wFT and initialized. Next, in step 2, the instructions included in the wFT BEvent are acquired, and a partial FT related to the instruction is developed. The development of the FT can be classified into cases where the instruction is a hierarchical instruction (RCD(I) not = ϕ + ϕ), as shown in step 2.1, or is a non-hierarchical instruction (RDD(I) = ϕ + ϕ), as shown in step 2.2. Here, ϕ + ϕ means the instruction line number and the target variable does not exist. In the case of a hierarchical instruction, the FTT of instruction for each layer is combined from the most outer layer (hierarchy L max ) to the most inner layer. Step 2.1.1 obtains the hierarchical instruction in which I g is included and calculates the L max , which is the maximum layer of the hierarchical instruction and layer L where I g exists. In step 2.1.3, the FTT corresponding to I g is regarded as wFT. In step 2.1.4, BEvent in dFT is regarded as TEvent in wFT.
Step 2.1.5 calculates all the BEvents in wFT.
Step 2.1.6 combines the FTT for the global variable with wFT when the BEvent includes the global variables, and the FTT for local variables with wFT when the BEvent includes the local variables, and then wFT is combined with dFT. Finally, in step 2.1.7, this operation is repeated until it reaches a hierarchy in which the instruction being tracked exists. Next, the wFT is joined to the dFT to develop a new dFT. In the case it is not a hierarchical instruction, the FTT for this instruction is joined to the wFT, and, in a way, similar to the hierarchical instruction case, the FTT for global variables or local variables is combined with the wFT and, if necessary, the contents of the TEvent and the BEvents are modified. Then, the wFT is combined with the dFT to make a new dFT. Finally, in step 3, the developed dFT is returned.

FTA Support Tool
We prototyped an FTA support tool. For the development language, Java language and Apache POI were used. Apache POI is an API that is used to read and write Microsoft Excel format data in the Java application. As shown in Figure 2, the FTA support tool comprises the ECSW pre-processing tool, the information extraction tool, and the FTA support tool. The pre-processing tool converts ECSW instructions into instructions prepared for FFT. The information extraction tool extracts ECSW information shown in Table 1 from the replaced ECSW. The FTA support tool takes the replaced ECSW, the ECSW information, top event (<Event 1 >), and the instructions generating this event (I 1 ) as input, and develops the FT. The FTA support tool shows the dFT draft to the analyst. The analyst confirms and modifies the content of the dFT's BEvent. The FTA support tool specifies the instruction executed immediately before based on the modified BEvent, develops a dFT by adding the FTT for this instruction, and shows the dFT to the analyst, and the analyst modifies the dFT. The analyst completes the FT by repeating this process. The FTA support tool creates the dFT in CSV format, which is then displayed using a spreadsheet application (Microsoft Excel). The reason the spreadsheet application is used is that the display style depends on the user favor. The user can change the displaying application easily. Additionally, as the dFT data are in CSV format, it can be exchanged easily between the FTA support tool, other displaying applications, and analysis tools.
Information 2020, 11, x FOR PEER REVIEW 11 of 23 in the BEvent or the partial FT within the hierarchical instruction. First, in step 1 of Figure 14, Φ is substituted for wFT and initialized. Next, in step 2, the instructions included in the wFT BEvent are acquired, and a partial FT related to the instruction is developed. The development of the FT can be classified into cases where the instruction is a hierarchical instruction (RCD(I) not = φ + φ), as shown in step 2.1, or is a non-hierarchical instruction (RDD(I) = φ + φ), as shown in step 2.2. Here, φ + φ means the instruction line number and the target variable does not exist. In the case of a hierarchical instruction, the FTT of instruction for each layer is combined from the most outer layer (hierarchy Lmax) to the most inner layer.
Step 2.1.1 obtains the hierarchical instruction in which Ig is included and calculates the Lmax, which is the maximum layer of the hierarchical instruction and layer L where Ig exists. In step 2.1.3, the FTT corresponding to Ig is regarded as wFT. In step 2.1.4, BEvent in dFT is regarded as TEvent in wFT.
Step 2.1.5 calculates all the BEvents in wFT.
Step 2.1.6 combines the FTT for the global variable with wFT when the BEvent includes the global variables, and the FTT for local variables with wFT when the BEvent includes the local variables, and then wFT is combined with dFT. Finally, in step 2.1.7, this operation is repeated until it reaches a hierarchy in which the instruction being tracked exists. Next, the wFT is joined to the dFT to develop a new dFT. In the case it is not a hierarchical instruction, the FTT for this instruction is joined to the wFT, and, in a way, similar to the hierarchical instruction case, the FTT for global variables or local variables is combined with the wFT and, if necessary, the contents of the TEvent and the BEvents are modified. Then, the wFT is combined with the dFT to make a new dFT. Finally, in step 3, the developed dFT is returned.

FTA Support Tool
We prototyped an FTA support tool. For the development language, Java language and Apache POI were used. Apache POI is an API that is used to read and write Microsoft Excel format data in the Java application. As shown in Figure 2, the FTA support tool comprises the ECSW pre-processing

Application and Evaluation
This section discusses an evaluation of the results of applying the proposed method to the existing ECSW and future issues.

Application and Evaluation of the Proposed Method
FTAs for "spin-stabilized satellite rotates too fast" written in [12] are conducted. The reason we conducted this application is that we felt there were no descriptions related to the middle analytic process that led to the top event when we read this result for the first time. We considered that the analyst omitted the middle analytic process based on his skills and experiences. We would like to confirm that the omitted parts can be complemented by applying the proposed method and the complete FT improves the understandability. Additionally, we apply and evaluate the proposed method for the existing five ECSWs.

Application and Evaluation of the Top Event for "Rotation Rate of the Satellite Became Too Fast"
Leveson et al. executed a system-level FTA related to an accident where the rotation rate of the spin-stabilized satellite became too fast, and the boom was torn off by centrifugal force. The result of this became an accident in cases where, in the top events, "value of variable period became too high" or "value of variable length became too low" in ECSW were caused. Figure 15 shows the ECSW structure chart. Vbrh and monitor spin are started with a timer interrupt, RESTART3 has an interrupt from the sun's pulses, and RESTART4 is started up with a clock interrupt. Figure 16 shows the source code rewritten in C (in [12], this is described in Pseudo Pascal).   The number of events in the P_FT and L_FT is evaluated. The number of the event in L_FT is 20, while the number of the event in P_FTs is 56 (excluding events surrounded in the dotted line and supplementary comments). The reasons the P_FTs include many events are as follows.

•
As for the P_FT, FDRs are strictly applied, and there is no omission of interim progress (in L_FT, the analyst omits the interim progress).

•
As the module startup with interrupt is used many times, the FTT for interrupt is also used multiple times.

•
As the global variables are used multiple times, the FTT for global variables are also used.

•
In comparison to the FTT developed by Leveson, the FTT in the proposed method has many events.
We analyzed the correspondence between the two FTs. (I) to (VII) in Figures 17 and 18 express the section where the FTs correspond. The event group in P_ FT corresponding to each event in the L_FT is indicated by the section surrounded by a dotted line. The other group in Figure 18 is the section not described in Figure 17. From the above, we can see that, excluding Other, both FTs have the same structure. In addition, we can see that the P_FT analyzes the cause of the fundamental events occurring in detail.  The number of events in the P_FT and L_FT is evaluated. The number of the event in L_FT is 20, while the number of the event in P_FTs is 56 (excluding events surrounded in the dotted line and supplementary comments). The reasons the P_FTs include many events are as follows.

•
As for the P_FT, FDRs are strictly applied, and there is no omission of interim progress (in L_FT, the analyst omits the interim progress).  • As the module startup with interrupt is used many times, the FTT for interrupt is also used multiple times.

•
As the global variables are used multiple times, the FTT for global variables are also used.
• In comparison to the FTT developed by Leveson, the FTT in the proposed method has many events.
We analyzed the correspondence between the two FTs. (I) to (VII) in Figures 17 and 18 express the section where the FTs correspond. The event group in P_ FT corresponding to each event in the L_FT is indicated by the section surrounded by a dotted line. The other group in Figure 18 is the section not described in Figure 17. From the above, we can see that, excluding Other, both FTs have the same structure. In addition, we can see that the P_FT analyzes the cause of the fundamental events occurring in detail.          if previous wdcss is lowmax, wdcss becomes low. => this partial FT is an ancillary cause.
wdcss become 0. => this partial FT is a cause. wdcss becomes high. => this partial FT is not cause.
because wdcss is over 0 and wdlost is less than 64, wdcss does not become low => this FT is not cause.
Because "wdcss low " has conflict to "wdcss high" in the upstream branch (2), this partial FT is not cause. In the case of this top event, the total time for conducting FTA takes about 3.0 h. The details of the FTA time are 0.5 h for understanding the source code (this task is conducted manually) and 2.5 h for developing FTAs (this task is conducted automatically using the developed tools). Here, the developing time of L_FT is unknown. The time is appropriate and acceptable for developing P_FTs. The reason the proposed method takes a short time for developing FTs is that the proposed method takes a shorter time to search the previously executed instructions.
Finally, we review the detected fundamental events. With L_FT, "magp < 100 and magp >" or "sunp > 100 and sunp <" are established, and "missing the sun pulse" or "the clock becoming too fast" were fundamental events. On the other hand, with P_FT, based on (V) and (IV) in Figure 18a, if "magp < 100 and magp >" or "sunp > 100 and sunp <" are established, then, from (VI) in Figure 18b, "the clock interrupt occurs frequently," or from (VII) in Figure 18b, "sun pulse interrupts do not occur" are the fundamental events. Although the description is different, "missing the sun pulse" and "sun pulse interrupt does not occur" are similar content.
Here, we describe the FTA result for the top event "value of variable length is too low." The evaluation method is the same as the former example. There were 15 L_FT events and 54 P_FT events. The two FTs had a similar structure. With L_FT, the fundamental events were "clock does not occur," "interrupt prohibition was not released," and "return value of function sample is too small." With P_ FT, on the other hand, "clock is not generated," "interrupt prohibition is not released", and "return value of function sample was inappropriate." These have the same content, and the reason there is a large number of P_FT events is the same as for the previous results. The time for conducting FTA takes about 2.0 h. The details of the FTA time are 0.5 h for understanding the source code (this task is conducted manually) and 1.5 h for developing FTAs (this task is conducted automatically using the developed tools). Here, the developing time of L_FT is unknown. The time is appropriate and acceptable for developing P_FTs. The reason the proposed method develops P_FTs within the appropriate and acceptable time is the same as in the former example.
From the above results, we can see that appropriate FTs can be developed corresponding to the top events in the proposed method within the appropriate time. As the number of the middle event in P_FTs becomes three times the number of the middle event in L_FT, there exists a concern about understanding the outline of the P_FTs. Therefore, P_FTs are shown as the hierarchical FTs in Figure 19. This FT is easily developed from P_FT by summarizing the middle events as a group. Figure 19 is the top-level FT, and lower-level FTs are the same as the FTs shown in Figure 18b-d. As a result, the analyst insists that displaying FT as the hierarchical FT can improve the readability. Additionally, an analyst insists that the analyzing process in the P_FTs is understandable because the P_FTs do not omit the middle process of conducting FTA. In the case of this top event, the total time for conducting FTA takes about 3.0 h. The details of the FTA time are 0.5 h for understanding the source code (this task is conducted manually) and 2.5 h for developing FTAs (this task is conducted automatically using the developed tools). Here, the developing time of L_FT is unknown. The time is appropriate and acceptable for developing P_FTs. The reason the proposed method takes a short time for developing FTs is that the proposed method takes a shorter time to search the previously executed instructions.
Finally, we review the detected fundamental events. With L_FT, "magp < 100 and magp >" or "sunp > 100 and sunp <" are established, and "missing the sun pulse" or "the clock becoming too fast" were fundamental events. On the other hand, with P_FT, based on (V) and (IV) in Figure 18a, if "magp < 100 and magp >" or "sunp > 100 and sunp <" are established, then, from (VI) in Figure 18b, "the clock interrupt occurs frequently," or from (VII) in Figure 18b, "sun pulse interrupts do not occur" are the fundamental events. Although the description is different, "missing the sun pulse" and "sun pulse interrupt does not occur" are similar content.
Here, we describe the FTA result for the top event "value of variable length is too low." The evaluation method is the same as the former example. There were 15 L_FT events and 54 P_FT events. The two FTs had a similar structure. With L_FT, the fundamental events were "clock does not occur," "interrupt prohibition was not released," and "return value of function sample is too small." With P_ FT, on the other hand, "clock is not generated," "interrupt prohibition is not released", and "return value of function sample was inappropriate." These have the same content, and the reason there is a large number of P_FT events is the same as for the previous results. The time for conducting FTA takes about 2.0 h. The details of the FTA time are 0.5 h for understanding the source code (this task is conducted manually) and 1.5 h for developing FTAs (this task is conducted automatically using the developed tools). Here, the developing time of L_FT is unknown. The time is appropriate and acceptable for developing P_FTs. The reason the proposed method develops P_FTs within the appropriate and acceptable time is the same as in the former example.
From the above results, we can see that appropriate FTs can be developed corresponding to the top events in the proposed method within the appropriate time. As the number of the middle event in P_FTs becomes three times the number of the middle event in L_FT, there exists a concern about understanding the outline of the P_FTs. Therefore, P_FTs are shown as the hierarchical FTs in Figure  19. This FT is easily developed from P_FT by summarizing the middle events as a group. Figure 19 is the top-level FT, and lower-level FTs are the same as the FTs shown in Figure 18b-d. As a result, the analyst insists that displaying FT as the hierarchical FT can improve the readability. Additionally, an analyst insists that the analyzing process in the P_FTs is understandable because the P_FTs do not omit the middle process of conducting FTA.

Application and Evaluation Applying to Existing ECSW
In order to be evaluated, the proposed method is applied for the five existing ECSWs. Those are the ECSWs that control the electrical device, and the size of the ECSW is 30-200 LOC written in the C language. Two analysts who have over three year's experience and the same skills conduct FTA individually. One analyst develops the FT based on his experiences (hereafter, E_FT), and the other analyst develops the FT using the proposed method (hereafter, P_FT). After developing the FT, analysts evaluate the FTs with each other. Table 2 shows the outline of the ECSWs, top event, and the size of the ECSW. Table 3 shows the evaluation results of P_FT and E_FT, such as the fundamental events, number of events, developing time using the developed tools (except for the time for understanding the code), and the validity of the FT. As a result, in Table 3, in example No.5, P_FTs are appropriate, while E_FTs miss the fundamental event where the value in the buffer is too low. This result shows a possibility that applying the proposed method reduces the oversight of the fundamental events. The number of events in P_FTs is two times larger than the number of events in E_FTs. The considered reason is that the number of used interrupts and the number of the used global variables are small in comparison to the case described in Section 4.1.1. The FT developing time of P_FTs and E_FTs is the same. However, in the case of analyzing the ECSW with complex structure, it is considered that the analyzing time for P_FT becomes longer because the proposed method has to analyze the FT branches, which could not be the fundamental events. This issue can be resolved by excluding such branches. This is the trade-off between the FT developing time and oversight of fundamental events.

Issues in the Proposed Method
This subsection describes the issues in the proposed method.

Issues Related to the Scale of ECSW
The size of the ECSW used for the evaluation was 50-200 LOC. In recent years, the scale of the ESCW has grown to realize high performance. In addition, with the ECSW, data sending and receiving using global variables are often used, and module startup using multiple interrupts is used. Therefore, the structure of the developed FT using the proposed method is considered to be complex, and it is feared that the level of understanding will be low and the analysis time will be long. It is necessary to introduce the design standard, such as ISO26262 [6], etc., that requires the usage restrictions on global variables and the multiple interrupts.

Issues Related to the ECSW's Dirty Structure
There are many ECSWs that are not applying the appropriate design process and standard. In many cases, those ECSWs have dirty structure (structure without appropriate functional dividing and design). When applying the proposed method to those ECSWs, it becomes highly possible that the developed FTs become more complex and larger. We investigate the refactoring method for the ECSWs with dirty structure before conducting FTA.

Issues Related to the Large Number of FT Events
When developing the FT using the proposed method, the number of the event in the FT becomes larger. While this can realize the development without the oversights of information related to the FT, the readability of the FT is decreased. To resolve this problem, we are going to develop the tools that show the FT with hierarchical expression (like Figure 19) and prunes the FT branch using Boolean algebra.

Issues Related to the Judgment of the Analyst
When developing the FT, the same section of the FT within the FT may be repeated multiple times. This type of FT structure occurs where the tracked instruction exists within the repetition instruction or interrupt processing occurs frequently. In this kind of FT structure, there are two types, such as (1) the top event occurs when the process is repeated until the certain times, and (2) the event goes into an infinite loop. In the proposed method, there is no judgment made as to which stage to stop the analysis. Therefore, we add a function that notifies the information that the repetitions reach a certain number. By using this information, the analyst can decide whether to continue or stop the analysis.

Issues Related to Object-Oriented Languages
If we define FTT for instructions in other procedural programming languages, the proposed method can be applied. On the other hand, the proposed method cannot be applied to ECSW written in object-oriented languages. This is because the FTTs and FDR in the proposed method give no consideration to inheritance and polymorphism that are features of object-oriented programming. We would like to investigate the proposed method for object-oriented programming in the future.

Summary
In this paper, we define FTT and FDR, and propose an FTA method. As a result of applying the proposed method to the top event of the existing ECSWs, we could confirm that appropriate FTs were developed, and appropriate fundamental events were detected. These show the effectiveness of the proposed method and support tool. In the proposed method, as we developed the FT complying with the application of the FTTs and FDR, the quality of FT information improved. Additionally, we improved the level of understanding within the appropriate time. In the future, we shall apply the proposed method to large-scale ECSW, and feed-back the results into the proposed method.