# 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 c c} \hline \hline
**Hardware** & \multicolumn{2}{c}{**Iteration 3**} & \multicolumn{2}{c}{**Iteration 4**} & \multicolumn{2}{c}{**Iteration 5**} & \multicolumn{2}{c}{**Iteration 6**} \\ \cline{2-9}
**Element** & \(\mathbf{DC_{RF_{T(i)}}}\) & \(\mathbf{DC_{DPFL_{T(i)}}}\) & \(\mathbf{DC_{RF_{T(i)}}}\) & \(\mathbf{DC_{DPFL_{T(i)}}}\) & \(\mathbf{DC_{RF_{T(i)}}}\) & \(\mathbf{DC_{DPFL_{T(i)}}}\) & \(\mathbf{DC_{RF_{T(i)}}}\) & \(\mathbf{DC_{DPFL_{T(i)}}}\) \\ \hline \(C(1)\) & 60\% & 60\% & 60\% & **90\%** & 60\% & 90\% & 90\% & 90\% \\ \(C(2)\) & – & – & – & – & **60\%** & **60\%** & 60\% & 60\% \\ \(C(3)\) & 90\% & **99\%** & 90\% & 99\% & 90\% & 99\% & 90\% & 99\% \\ \(C(4)\) & 99\% & 99\% & 99\% & 99\% & 99\% & 99\% & 99\% & 99\% \\ \hline \hline \end{tabular}
\end{table} 
Table 8: The assigned \(DC_{RF_{T(i)}}\) and \(DC_{DPFL_{T(i)}}\) in the design iteration 4–6. (The DC value adjusted in each design iteration is marked as bold text. with better DC will lead to higher hardware overhead and has the potential to lead the outcome to turn into \(c\) or \(d\). Therefore, the outcomes could alternatively repeat between \(b\), \(c\), and \(d\) until all the possible safety mechanism replacements have been examined. If so, it means that no feasible system hardware architecture can meet the hardware overhead constraint and the safety requirements simultaneously. Thus, the system engineers should review whether the specified constraint is reasonable for the target ASIL. For outcome \(d\), we tend to meet the hardware overhead constraint first and then the safety metrics because satisfying the hardware overhead constraint is the primary goal in the current design phase. We organize the concepts described above into an algorithm, which is shown in Algorithm 2. The following notations and expressions are defined next:

* \(PT\_d\): The set containing the hardware elements with safety mechanism deployment in the system hardware architecture derived from the Algorithm 1. * \(no\_d\): The number of elements in the set \(PT\_d\). * \(ite\_d\): The number of search iterations performed. * \(HO\_Max_{sys}\): The maximal allowable system hardware overhead in percentage. * \(HO\_Total_{ite\_d}\): Total system hardware overhead due to safety mechanism deployment. \[HO\_Total_{ite\_d}(\%)=\frac{\sum_{e=1}^{no\_d}HC\big{(}SM_{xyz}(PT\_d(e)) \big{)}}{\sum_{i=1}^{n}HC(i)} \tag{25}\]

where

* \(HC(i)\): The hardware size in unit for the \(i\)th hardware element and \(n\) is the total number of hardware elements in the evaluated system. * \(HC\big{(}SM_{xyz}(PT\_d(e))\big{)}\): The hardware overhead in unit for the safety mechanism of the \(e\)th element in set \(PT\_d\). \[HC\big{(}SM_{xyz}(PT\_d(e))\big{)}=HC(PT\_d(e))\times HO\big{(}SM_{xyz}(PT\_d(e) )\big{)} \tag{26}\]

where \(HO(SM_{xyz}(PT\_d(e)))\), the required hardware overhead in percentage for protecting the hardware element \(PT\_d(e)\), is specified by the system engineers.