Update on Overleaf.

main.tex

@@ -407,15 +407,15 @@ The ISO\,26262 furthermore specifies the hardware metrics used to evaluate the r
     \label{tab:target}
 \end{table}
 
-Table \ref{tab:target} shows the required target values for $\lambda_\mathrm{RF}$, SPFM, and LFM to reach a specific ASIL. For example, the highest level ASIL\,D can only be reached if the SPFM is greater than 99\%, the LFM is greater than 90\%, and the residual failure rate is below 10.
+Table \ref{tab:target} shows the required target values for $\lambda_\mathrm{RF}$, SPFM, and LFM to reach a specific ASIL. For example, the highest rating ASIL\,D can only be reached if the SPFM is greater than 99\%, the LFM is greater than 90\%, and the residual failure rate is below 10.
 
 \section{Related Work}
 \label{sec:related}
 %
 This section discusses related work and the state of the art.
-\newer{Today's safety standards, such as ISO\,26262, recommend techniques such as \textit{Failure Mode and Effects Analysis} (FMEA), Fault Tree Analysis (FTA) or  Markov Chains for safety analysis. However, none of these techniques can be used directly to obtain the hardware metrics (SPFM and LFM). FMEA as an inductive analysis technique, is suitable for investigating the system from the bottom up and identifying root causes that lead to unwanted system effects. This is helpful in understanding the relationship between HW faults and safety goal violations at the system level. However, FMEA is a purely qualitative analysis technique and therefore not suitable for calculating the desired HW metrics. In practice, a \textit{Failure Mode Effects and Diagnostic Analysis} (FMEDA) is used instead. FMEDAs are typically performed using spreadsheets to systematically examine the HW of the system under analysis for root causes. For each root cause that has the potential to violate a safety goal, safety mechanisms are identified and the coverage with respect to residual and latent faults is determined, providing the basis for calculating the HW metrics for the system under consideration. A special aspect of this technique is that each HW element is analyzed atomically. This is an advantage from a modularization point of view but can be seen as a disadvantage in understanding complex functional dependencies between these elements. In this respect other techniques may be more appropriate.}
+\newer{Today's safety standards, such as ISO\,26262, recommend techniques such as \textit{Failure Mode and Effects Analysis} (FMEA), Fault Tree Analysis (FTA) or  Markov Chains for safety analysis. However, none of these techniques can be used directly to obtain the hardware metrics (SPFM and LFM). FMEA as an inductive analysis technique is suitable for investigating the system from the bottom up and identifying root causes that lead to unwanted system effects. This is helpful in understanding the relationship between HW faults and safety goal violations at the system level. However, FMEA is a purely qualitative analysis technique and therefore not suitable for calculating the desired HW metrics. In practice, a \textit{Failure Mode Effects and Diagnostic Analysis} (FMEDA) is used instead. FMEDAs are typically performed using spreadsheets to systematically examine the HW of the system under analysis for root causes. For each root cause that has the potential to violate a safety goal, safety mechanisms are identified and the coverage with respect to residual and latent faults is determined, providing the basis for calculating the HW metrics for the system under consideration. A special aspect of this technique is that each HW element is analyzed atomically. This is an advantage from a modularization point of view, but can be seen as a disadvantage in understanding complex functional dependencies between these elements. In this respect, other techniques may be more appropriate.}
 
-\newer{Analysis techniques, such as Markov Chains and Fault Trees, are more expressive and better suited to qualitatively and quantitatively examine  complex dependencies. In practice, however, they are less favored, in part because they are typically required only when high assurance levels are required and in part because they can be more demanding from a modeling perspective. The latter is in particularly true for Markov Chains, as the models can grow very rapidly, leading to models that are difficult to understand and maintain. Fault Trees and in particular Component Fault Trees (CFT) introduced by Kaiser et\,al.~\cite{kailig_03} offer a more structured approach. They have the ability to modularize and associate Fault Trees with each of the elements in the HW. Consequently, CFT models compose fault trees according to the hierarchical structure employed in the system design. From the point of view of computing HW metrics, as mentioned earlier, these techniques do not allow a direct computation, since they allow at most the calculation of the probability of occurrence of events. Theoretically, it would be possible to integrate new modeling elements, such as a "measure" type of event to integrate the computation of the coverage fraction of the safety mechanisms. However, this is  likely to increase the modeling effort and the complexity of the models. 
+\newer{Analysis techniques, such as Markov Chains and Fault Trees, are more expressive and better suited to qualitatively and quantitatively examine  complex dependencies. In practice, however, they are less favored, in part because they are typically only needed when high assurance levels are required, and in part because they can be more demanding from a modeling perspective. The latter is especially true for Markov Chains, as the models can grow very rapidly, leading to models that are difficult to understand and maintain. Fault Trees and in particular Component Fault Trees (CFT) introduced by Kaiser et\,al.~\cite{kailig_03} offer a more structured approach. They have the ability to modularize and associate Fault Trees with each of the elements in the HW. Consequently, CFT models compose fault trees according to the hierarchical structure employed in the system design. From the point of view of computing HW metrics, as mentioned earlier, these techniques do not allow a direct computation, since they allow at most the calculation of the probability of occurrence of events. Theoretically, it would be possible to integrate new modeling elements, such as a "measure" type of event to integrate the computation of the coverage fraction of the safety mechanisms. However, this is  likely to increase the modeling effort and the complexity of the models. 
 Our method combines the most important aspects of the above techniques. First, we overcome the drawback of FMEDA by defining a graphical notation capable of maintaining the level of expressiveness similar to CFTs, while keeping the modeling approach simple, allowing us to investigate complex dependencies between the HW elements. Second, we maintain the simplified computation of the HW metrics of FMEDA by integrating dedicated modeling elements.}
 
 The usage of SystemC-based virtual prototypes for safety analysis is already well established. However, all these approaches focus on simulation of the functionality and injection of errors. For example, in~\cite{reipre_13}, the authors present how virtual prototypes can support the FMEA process. There also exist other works whose main focus is on fault injection during functional simulations~\cite{weisch_16},\cite{tabcha_16},\cite{silpar_14} and \cite{tab_19}. As mentioned above, all of these previous works focus on functional simulation and error injection for ISO\,26262 support. The focus of our work lies on the static hardware metrics analysis of ISO\,26262 and how it can be realized within SystemC. 
@@ -978,12 +978,6 @@ When the ECC-enabled bandwidth is set in direct relation to the original bandwid
       enlarge x limits=0.25,
       legend style={at={(0.5,0.95)}, anchor=north,legend columns=1},
     ]
-    % Old
-    % \addplot
-    % coordinates {(Sequential, 100.45)(Random, 47.28)(MAX, 102.40)};
-    % \addplot
-    % coordinates {(Sequential, 96.84)(Random, 33.51)(MAX, 102.40)};
-    
     \addplot
     coordinates {(Sequential, 100.53)(Random, 47.27)(MAX, 102.40)};
     \addplot