either be executed by the hardware itself, or more thoroughly but also slower by
software. It is up to the system software to perform the software-based checks and
react on detected faults. Task base checking (see Sect. 7.1) is an example of when
to perform the checks. As shown in Fig. 4.3, hardware-based checks, especially if
they are performed in parallel to the current instruction execution, are ideal in terms
of time overhead.
Reconfiguration. In case of permanent faults, it might also be necessary to
reconfigure the system to exclude a failed component from the currently used
working set. In that sense, the state of the software and hardware is directly
dependent as hardware faults are reflected in software. If a failed hardware component is excluded from the working set, all the software components that use this
hardware component must be reconfigured accordingly (see Sect. 7.4).
Preparation for recovery. The system software is also responsible for taking
measures to react on faults. Thus, it is responsible for the preparation for recovery,
which consists of creating recovery points. A recovery point is a snapshot of the
whole or part of the system at a specific point in time. In case of a fault, the system
can rollback to the stored snapshot and continue processing. Of course, recovery is
only successful if the fault was not present in the system when the recovery point
was created. Various implementation schemes exist for creating recovery points
with various time and space constraints. See Chap. 8 for more details.
Recovery. If a fault is detected in the system, the recovery process is responsible
for the elimination of the fault impact in hardware and software. This process
depends therefore on the previous two processes for fault identification and elimination. Thus, after using the checking schemes to identify the fault and eliminate
the fault impact, the software must in a second step be recovered to the last consistent state using the recovery points. See Sect. 9.1 for more details.
References
1. Microsoft Corporation (2008) Windows embedded CE overview. World Wide Web
Electronic Publication
2. VxWorks (2008) Vxworks overview. World Wide Web Electronic Publication
3. Green Hills Software (2008) Integrity, the most advanced RTOS technology. Technical
report, Green Hills Software
4. Friedrich et al (2006) Array-structured object types for mathematical programming. In:
Lecture notes in computer science, vol 4228, pp 195–210. http://link.springer.com/book10.
1007/11860990
5. Takaoka T (1986) The semantics of new while loop. Comput J 29(1)
6. Russell D, Tiedeman M (1979) Multiprocess recovery using conversations. In: Digest of
papers FTCS-9, 9th international symposium
7. Schagaev I (1986) Algorithms of computation recovery. Autom Remote Control 7
8. Schagaev I (1987) Algorithms for restoring a computing process. Autom Remote Control 48
(4)
68
6 System Software Support for Hardware Deficiency…
software. It is up to the system software to perform the software-based checks and
react on detected faults. Task base checking (see Sect. 7.1) is an example of when
to perform the checks. As shown in Fig. 4.3, hardware-based checks, especially if
they are performed in parallel to the current instruction execution, are ideal in terms
of time overhead.
Reconfiguration. In case of permanent faults, it might also be necessary to
reconfigure the system to exclude a failed component from the currently used
working set. In that sense, the state of the software and hardware is directly
dependent as hardware faults are reflected in software. If a failed hardware component is excluded from the working set, all the software components that use this
hardware component must be reconfigured accordingly (see Sect. 7.4).
Preparation for recovery. The system software is also responsible for taking
measures to react on faults. Thus, it is responsible for the preparation for recovery,
which consists of creating recovery points. A recovery point is a snapshot of the
whole or part of the system at a specific point in time. In case of a fault, the system
can rollback to the stored snapshot and continue processing. Of course, recovery is
only successful if the fault was not present in the system when the recovery point
was created. Various implementation schemes exist for creating recovery points
with various time and space constraints. See Chap. 8 for more details.
Recovery. If a fault is detected in the system, the recovery process is responsible
for the elimination of the fault impact in hardware and software. This process
depends therefore on the previous two processes for fault identification and elimination. Thus, after using the checking schemes to identify the fault and eliminate
the fault impact, the software must in a second step be recovered to the last consistent state using the recovery points. See Sect. 9.1 for more details.
References
1. Microsoft Corporation (2008) Windows embedded CE overview. World Wide Web
Electronic Publication
2. VxWorks (2008) Vxworks overview. World Wide Web Electronic Publication
3. Green Hills Software (2008) Integrity, the most advanced RTOS technology. Technical
report, Green Hills Software
4. Friedrich et al (2006) Array-structured object types for mathematical programming. In:
Lecture notes in computer science, vol 4228, pp 195–210. http://link.springer.com/book10.
1007/11860990
5. Takaoka T (1986) The semantics of new while loop. Comput J 29(1)
6. Russell D, Tiedeman M (1979) Multiprocess recovery using conversations. In: Digest of
papers FTCS-9, 9th international symposium
7. Schagaev I (1986) Algorithms of computation recovery. Autom Remote Control 7
8. Schagaev I (1987) Algorithms for restoring a computing process. Autom Remote Control 48
(4)
68
6 System Software Support for Hardware Deficiency…