# 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
* Because the increased hardware overhead for the deployed safety mechanisms is not examined in Algorithm 1, the overall hardware overhead for the whole system could violate the specified constraint. If the constraint is violated, the proposed HO-oriented hardware architecture exploration process should be activated. The corresponding details are depicted in the next subsection. #### 4.3.3 HO-Oriented Hardware Architecture Exploration Algorithm

As aforementioned, the HO-oriented hardware architecture exploration algorithm will be performed if the hardware overhead constraint is not met. The main purpose of this algorithm is to explore whether there are other safety mechanism deployment solutions with lower hardware overhead than the one assigned by the ASIL-oriented hardware architecture exploration algorithm. During such design space exploration, there will be four possible outcomes, which are:

* Both the safety metrics and hardware overhead constraint are met. * The safety metrics are satisfied but the hardware overhead constraint is not. * The hardware overhead constraint is met but the safety metrics are not. * Neither the hardware overhead constraint nor the safety metrics are satisfied. Outcome \(a\) indicates that a feasible system hardware architecture has been found and the FMEDA report will also be generated. For outcome \(b\), a new round of system hardware architecture exploration is required to search for another possible solution with lower overall hardware overhead. To assure that the overall hardware overhead can be effectively reduced, our strategy is to replace the safety mechanism, which contributes the highest hardware overhead among all deployed safety mechanisms, with a safety mechanism with lower DC and lower hardware overhead. However, such a replacement is not allowed if the replacement will cause the element to become MBP again. In such a case, the element with the next highest hardware overhead in the overhead ranking will be selected as the target to be adjusted. Moreover, if outcome \(c\) occurs, the element deploying the safety mechanism with the lowest hardware overhead in the overhead ranking will be chosen to be replaced by the safety mechanism with a higher level of DC. Undoubtedly, the safety mechanism \begin{table}
\begin{tabular}{c c c c c c c c} \hline \hline
**MCS** & \(\mathbf{Gap_{PHMF}}\) (\(\mathbf{MCS_{b}}\)) & \(\mathbf{Gap_{SPFM}}\) (\(\mathbf{MCS_{b}}\)) & \(\mathbf{Gap_{FLM}}\) (\(\mathbf{MCS_{b}}\)) & \(\mathbf{MBP_{PHMF}}\)/\(\mathbf{POD_{PHMF}}\) & \(\mathbf{MBP_{SPFM}}\)/\(\mathbf{POD_{SPFM}}\) & \(\mathbf{MBP_{LFM}}\)/\(\mathbf{POD_{LM}}\) \\ \hline \([C(1)]\) & \(7.6005\times 10^{-1}\) & \(5.3156\times 10^{-1}\) & \(1.49357\times 10^{-1}\) & \(\mathbf{POD_{PHMF}}\) & \(\mathbf{POD_{SPFM}}\) & \(\mathbf{POD_{LM}}\) \\ \([C(2)]\) & \(4.4006\times 10^{-1}\) & \(3.0777\times 10^{-1}\) & \(8.64767\times 10^{-2}\) & \(\mathbf{POD_{PHMF}}\) & \(\mathbf{POD_{SPFM}}\) & \(\mathbf{POD_{LM}}\) \\ \([C(3),SM_{[C(3)]}]\) & \(4.9409\times 10^{-1}\) & \(3.4556\times 10^{-1}\) & \(9.70944\times 10^{-2}\) & \(\mathbf{POD_{PHMF}}\) & \(\mathbf{POD_{SPFM}}\) & \(\mathbf{POD_{LM}}\) \\ \([C(4),SM_{[C(4)]}]\) & \(2.0900\times 10^{-1}\) & \(1.4617\times 10^{-1}\) & \(4.10700\times 10^{-2}\) & \(\mathbf{POD_{PHMF}}\) & \(\mathbf{POD_{SPFM}}\) & \(\mathbf{POD_{LM}}\) \\ \hline \hline \end{tabular}
\end{table} 
Table 7: List of MCSs and their failure probabilities with updated system hardware architecture.