# 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.2. ASIL-Oriented Hardware Architecture Exploration Algorithm
\begin{table}
\begin{tabular}{c c c c c c} \hline \hline \multirow{2}{*}{\(PT\_d\)} & \multirow{2}{*}{**HC(\(i\))**} & \multirow{2}{*}{**HO(\(SM_{xyz}(PT\_d(e))\)) (\%)**} & \multirow{2}{*}{\(HC\big{(}SM_{xyz}(PT\_d(e))\big{)}\)} \\ \hline \(\{C(1)\),\(SM_{C(1)}\}\) & 6 & \(HO(SM_{MMM}(C(1)))=20\%\) & 1.2 \\ \(\{C(2)\),\(SM_{C(2)}\}\) & 4 & \(HO(SM_{LL}(C(2)))=8\%\) & 0.32 \\ \(\{C(3)\),\(SM_{C(3)}\}\) & 8 & \(HO(SM_{MMM}(C(3)))=18\%\) & 1.44 \\ \(\{C(4)\),\(SM_{C(4)}\}\) & 10 & \(HO(SM_{HHH}(C(4)))=20\%\) & 2.0 \\ \hline \hline \end{tabular}
\end{table} 
Table 10: List of \(PT\_d(e)\) and their \(HC\big{(}SM_{xyz}(PT\_d(e))\big{)}\). As a result, the current \(HO\_Total_{ite\_d}\) is greater than \(HO\_Max_{sys}\), and therefore, Algorithm 2 is activated to adjust the system hardware architecture acquired from Algorithm 1. First, the set \(PT\_d\) is specified to contain all the safety-related hardware elements that are protected by safety mechanisms, and then all the elements in \(PT\_d\) are sorted according to the increased hardware overhead due to the deployed safety mechanisms. It is evident that \(PT\_d=\{C(4)\), \(C(3)\), \(C(1)\), \(C(2)\)}. Then we declare two pointers, \(p_{down}\) and \(p_{up}\) where \(p_{down}\) points to the hardware element with the highest \(HC\big{(}SM_{xyz}(PT\_d(e))\big{)}\), i.e., \(C(4)\), and \(p_{up}\) points to the hardware element with the lowest \(HC\big{(}SM_{xyz}(PT\_d(e))\big{)}\), i.e., \(C(2)\). Subsequently, the safety mechanism of \(C(4)\), \(SM_{HHH}(C(4))\), is selected as the candidate to be downgraded for the hardware overhead reduction. However, the downgraded safety mechanism could allow \(C(4)\) to become MBP again. Therefore, the downgrade of the safety mechanism for \(C(4)\) is not allowable and hence we need to let \(p_{down}\) point to the hardware element with the next highest \(HC\big{(}SM_{xyz}(PT\_d(e))\big{)}\), i.e., \(C(3)\). Unfortunately, the downgrade of \(C(3)\)'s safety mechanism is also not allowable so the next candidate \(C(1)\) is selected. At this time, the downgrade of \(SM_{MMM}(C(1))\) is allowable and feasible because \(C(1)\) is kept as POD with the downgraded safety mechanism. Consequently, \(SM_{MMMM}(C(1))\) is replaced by \(SM_{LML}(C(1))\). In accordance with this replacement, all the considered design metrics \(HO\_Total_{ite\_d}\), \(SPFM_{ite\_d}\), \(LFM_{ite\_d}\), and \(PMHF_{ite\_d}\) need to be updated. \[HO\_Total_{ite\_d}(\%)=\frac{\sum_{t=1}^{4}HC\big{(}SM_{xyz}(PT\_d(e))\big{)} }{\sum_{i=1}^{5}HC(i)}=\frac{0.48+0.32+1.44+2}{6+4+8+10+3}=\frac{4.36}{31}= 13.68\%\]

\[SPFM_{ite\_d}=1-\frac{\sum_{\textit{Safety-Related HW elements}}(\lambda_{SPF}+ \lambda_{RF})}{\sum_{\textit{Safety-Related HW elements}}\lambda}=1-\frac{8.45 \times 10^{-8}}{1.43\times 10^{-6}}=94.09\%\]

\[LFM_{ite\_d}=1-\frac{\sum_{\textit{Safety-Related HW elements}}(\lambda_{ MPF,L})}{\sum_{\textit{Safety-Related HW elements}}(\lambda-\lambda_{SPF}-\lambda_{RF})}=1-\frac{2.79\times 10^{-8}}{1.35 \times 10^{-6}}=97.93\%\]

\[PMH\textit{File\_d}=\lambda_{SPF}+\lambda_{RF}+\lambda_{MPF,L}=1.12\times 10^{-7}\]

Clearly, the \(PMH\textit{File\_d}\) exceeds \(PMHF_{tar}\) although \(HO\_Total_{ite\_d}\) has met the hardware overhead constraint. Therefore, another design iteration is activated to explore the potential solution. In the next design iteration, the hardware element \(C(2)\) pointed by \(p_{up}\) is selected as the upgraded candidate for its deployed safety mechanism. Apparently, the upgrade of \(SM_{LLL}(C(2))\) is feasible because there exists a safety mechanism with a higher level of DC. Thus, \(SM_{LLL}(C(2))\) is replaced by \(SM_{MMMM}(C(2))\). It is worth noting that the replacement of \(SM_{LLL}(C(2))\) by \(SM_{LML}(C(2))\) cannot resolve the \(PMH\textit{F}_{tar}\) violation situation. For this reason, \(SM_{LML}(C(2))\) is not applied. Again, we need to update the corresponding \(HO\_Total_{ite\_d}\), \(SPFM_{ite\_d}\), \(LFM_{ite\_d}\), and \(PMH\textit{File\_d}\).