# Safety-Oriented System Hardware Architecture Exploration in Compliance with ISO 26262
## 4 Safety-Oriented System Hardware Architecture Exploration Framework
### System Hardware Architecture Exploration with Safety and Hardware Overhead Consideration
#### 4.3.1 Safety Mechanism Library  
There are different types of hardware elements in a system, such as microcontroller units, storages, sensors, and actuators. The specific safety mechanisms for each type of hardware element should be deployed to assure the effectiveness in terms of the diagnostic coverage and corresponding hardware overhead. If there exists a database that collects all the feasible safety mechanisms with the information of DC and hardware overhead for each type of hardware element, then we can rapidly discover the most appropriate safety mechanism to be employed. In this study, we call such a database the _safety mechanism library_. For safety-related hardware elements, a specific safety mechanism library can be established. Moreover, the safety mechanism library is formalized and then can be used in the succeeding ASIL-oriented and HO-oriented system hardware architecture exploration algorithms.  
It is worth noting that there are two feasible fault-tolerant design concepts to prevent the dual-point faults from becoming latent. The first one is to deploy a safety mechanism with a self-checking capability and the other is to adopt two-layered safety mechanisms, which means that there is a first-layer safety mechanism for the hardware element protection and a second-layer safety mechanism to detect the first-layer safety mechanism's faults. In this study, we assume that all the deployed safety mechanisms are developed with self-checking features to monitor the safety mechanism itself, and therefore, no second-layer safety mechanism is required.  
The notations for the formalized safety mechanism library are defined below.  
\begin{table}
\begin{tabular}{c c c c c c c} \hline \hline
**MCS** & \(Gap_{PMHF}\) (\(MCS_{k}\)) & \(Gap_{SPFM}\) (\(MCS_{k}\)) & \(Gap_{LFM}\) (\(MCS_{k}\)) & \(MBP_{PMHF}\)/\(POD_{PMHF}\) & \(MBP_{SPFM}\)/\(POD_{SPFM}\) & \(MBP_{LFM}\)/\(POD_{UM}\) \\ \hline \([C/1]\) & \(7.6005\times 10^{-1}\) & \(5.3156\times 10^{-1}\) & N/A & \(POD_{PMHF}\) & \(POD_{SPFM}\) & N/A \\ \([C/2]\) & \(4.4006\times 10^{-1}\) & \(3.0777\times 10^{-1}\) & N/A & \(POD_{PMHF}\) & \(POD_{SPFM}\) & N/A \\ \([C/3]\) & \(2.5990\times 10^{0}\) & \(1.8177\times 10^{0}\) & N/A & \(MBP_{PMHF}\) & \(MBP_{SPFM}\) & N/A \\ \([C/4]\) & \(1.0475\times 10^{1}\) & \(7.3260\times 10^{0}\) & N/A & \(MBP_{PMHF}\) & \(MBP_{SPFM}\) & N/A \\ \hline \hline \end{tabular}
\end{table}
Table 4: List of MCSs and their quantified gaps to the target values and MBP/POD identifications.  
* \(SM_{xyz}\)(_PT(e)_): The deployed safety mechanism for the protection target _PT(e)_, the _e_th element in the set _PT_, where _x,y,z_\(\in\{L,M,H\}\); \(x\), \(y\) represents the level of the \(DC_{RF_{T(e)}}\) and \(DC_{DPF,L_{PT(e)}}\) of the deployed SM for _PT(e)_, respectively, where \(\blacktriangleright\) \(L\) means diagnostic coverage = 60%/ // Low diagnostic coverage. \(\blacktriangleright\) \(M\) means diagnostic coverage = 90%/ // Medium diagnostic coverage. \(\blacktriangleright\) \(H\) means diagnostic coverage = 99%/ // High diagnostic coverage. \(\blacksquare\) \(z\) is for the hardware overhead of _PT(e)_ contributed from the deployed SM for _PT(e)_. \(\blacktriangleright\) \(\blacktriangleright\) The percentages of hardware overhead for L(Low), M(Medium), and H(High) are assumed to be known and specified by the system engineers. Then, the formalized safety mechanism library can be defined in the following:
* \(SM_{Lib}\)(_PT(e)_): The safety mechanism library for the _PT(e)_; the safety mechanisms of an element can be represented by a set that contains all feasible safety mechanisms such as [\(SM_{LLL}\), \(SM_{MMMM}\), \(SM_{HHH}\)] or [\(SM_{LML}\), \(SM_{MHH}\), \(SM_{HHH}\)] or [\(SM_{MHH}\), \(SM_{HHH}\)] depending on the hardware element type. \(SM_{Lib}\)(_PT(e)_) collects the sets of safety mechanism for all hardware elements in the _PT(e)_.