# 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
To protect the selected hardware element with duplication, a duplication of the original hardware element is required. Next, the original and the duplicated hardware elements are formed as a pair, and each output of the paired hardware elements is compared to check the consistency through a comparator. Any inconsistency means that there must be at least one faulty element in the hardware pair. It is worth noting, in this work, we assume that the duplicated hardware element is implemented with the diversity technique so that the probability of common-cause failure occurring is reduced to be low enough and can be ignored. Thus, the formed hardware element pair combined with the comparator will cause the safety goal violation only when all of them fail concurrently. Such a fault scenario conforms to the three-point faults, which have been classified into a safe fault as mentioned in \[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\%\]7 Thus, the failure rate of the hardware element deployed with hardware duplication will not be counted when computing the three hardware architecture metrics. However, the hardware overhead required to implement the hardware duplication technique will be 100%. In this demonstration, we specify ASIL D as the target to be achieved. Thus, \(PMHF_{tar}\), \(SPFM_{tar}\), and \(LFM_{tar}\) are required to be \(10^{-8}\) h\({}^{-1}\), 99% and 90%, respectively. The hardware element's failure rates used for the purpose of demonstration are listed in \[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\%\]8 System engineers may specify more realistic component failure rates by applying reliability data books such as SN-29500, IEC-62380/61709, and HDBK-217F, which are widely adopted in the related industry. The percentage of non-safe faults and the applied safety mechanism library for each hardware element can also be found in \[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\%\]9 Besides, the mission time \(t\) is set to be five thousand hours, and the hardware overhead constraint \(HO\_Max_{sys}\) is set to be 40%. Now we can compute \(\lambda_{K/N\_Sub}\) by applying the specified failure rates and mission time to expressions (27) and (28), respectively. The acquired \(\lambda_{K/N\_Sub}\) is \(4.18\times 10^{-11}\). \(\lambda_{K/N\_Sub}\) is approximately \(-3\)\(\cdots\)\(-4\) order of magnitude compared to the failure rates of other hardware elements, so its effect on the overall system's failure rate can be ignored. Thus, the \(\lambda_{K/N\_Sub}\) will not be counted in the following hardware architecture metric calculation. In addition, the K/N-formed subsystem, i.e., the four EBD nodes, is also excluded in the FTA-based weak-point analysis. In addition to the K/N-formed subsystem, the identified MCS failure probability, acquired by quantified gaps through expressions (18)-(20) and the corresponding _Max_Gap_ are summarized in \[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\%\]0

According to Table 12, the \(PT\) is assigned as \(PT=PT\_MBP=\{\)CAN bus, AEB microcontroller, Brake pedal sensor, Brake pedal ECU, Radar, Radar ECU, Speed sensor, Speed Meter ECU\(\}\). Then the ASIL-oriented hardware architecture exploration algorithm is performed. For the sake of saving space, the AEB microcontroller, Brake pedal sensor, Brake pedal ECU, Radar ECU, Speed sensor, and Speed Meter ECU are abbreviated as AEB_MCU, B_SEN, B_PECU, R_ECU, S_SEN, and S_ECU, respectively, in the following demonstration. Among all MBP weak points, it is evident that the _Max_Gap_ of the CAN bus and AEB_MCU are much higher than others.