Hardware errors

Models implemented as software programs may suffer from errors in program code, hardware errors as well as differences in various computer operating systems. 

The required SIL designates the methods and measures that have to be executed during the overall safety lifecycle phases. The SIL is a probabilistic quantitative concept. If certain techniques and measures are applied one expects on average that a certain reliability of the safety functions is realized. Besides statistic and systematic hardware errors this concept also takes systematic software failures into account. 

When hardware failure is a root cause for software error (1. b), we could keep this event within the boundary of hardware component failure when we loose just recovery action (made by software). The problem is that those types of hardware failures are so called soft errors , i.e. stochastically occurring events automatically repaired and it is questionable, whether they were reported when data for reliabihty parameters were gathered. Nevertheless, the uncertainty of e.g. processors failure rates is typically so high that treatment of hardware-software interface failures as just hardware errors seems to be justifiable. Moreover this kind of failures is basically not suspected fi om CCF (Common Cause Failures) potential. 

Encoding software using arithmetic codes facilitates software-implemented hardware error detection. In contrast to replication, arithmetic codes enable also the detection of permanent errors. Furthermore, the error detection capabilities of arithmetically encoded applications can be determined independent of the used hardware (see Sect. 3). 

Other software approaches work with replicated execution and comparison of the obtained results. The protected software is modified during or before compilation—rarely, dynamic binary instrumentation is used [24]. Replication can be implemented at different levels of abstraction. Some approaches duplicate single instructions and execute them in one thread [22,19,10,25,24,6]. Other approaches execute duplicates of the whole program within several threads and provide synchronization means for them [31,12,32]. For all those approaches which are based on redimdant execution of the same program instructions, it is not possible to provide guarantees with respect to permanent hardware errors or soft errors which disturb the voting mechanism. 

A long known technique to detect hardware errors during runtime are arithmetic codes. Arithmetic codes add redundancy to processed data which results in a larger domain of possible words. The domain of possible words contains the smaller subset of valid code words. Arithmetic codes are conserved by correct arithmetic operations, i. e., a correctly executed operation taking valid code words as input produces a result which is also a valid code word. On the other hand, faulty arithmetic operations destroy the code with a very high probability, i. e., result in a non-valid code word [Ij. 

Schiffel, U., Schmitt, A., Siifikraut, M., Fetzer, C. ANB- and aNBDmem-encoding Detecting hardware errors in software. In Schoitsch, E. (ed.) SAFECOMP 2010. LNCS, vol. 6351, pp. 169-182. Springer, Heidelberg (2010)... 

For the electronic we often find very tight intersections, particularly because the evaluation of the hardware architectural metrics (ISO 26262, part 5, chapter 8) as well as the evaluation of safety goal violations due to random hardware failures (ISO 26262, part 5, chapter 9) are based on the failure probability of electric components or occurrence probability of random hardware errors. Section 4.4.2.S covers such quantitative safety analyses in detail. Often, chapter 7 part 5 of ISO 26262 is overlooked, which covers the correct dimensioning and verification of... 

Example 2 refers to one of two external hard disks attached to the file server, for which three failure modes are shown (Table 4). The second entry is described as follows if one hard disk fails, due to hardware error (failure cause), the affected drive cannot store data (local consequences) but since the disk is mirrored by an identical disc to which it is paired, information from the back up disc is used automatically. Consequently, there is no data corruption... 

We define error sensitivity as the likelihood that a software component will produce a silent data corrnption, as a resnlt of a hardware error. 

In general, the ability of a computer system to detect and recover from hardware errors depends on both the hardware architecture and the machine code of the executed software. Hence, when we conduct out-of-context fault injection experiments to assess a software component s ability to handle hardware errors, we must run the experiments on a hardware platform that is similar to the one used in the real product. However, to generalize the benchmarking outcome, different hardware platforms should be considered. 

Such benchmarking experiments aim to measure the likelihood that the executable code of a software component exhibit silent data corruptions (SDCs) for hardware errors that propagate to instruction set architecture (ISA) registers and main memory locations. The purpose of such measurements is to identify weaknesses in the executable code, and thereby finding ways of hardening the code against hardware errors by means of software-implemented hardware fault tolerance techniques. 

---