Periodical hardware checks should be performed on every single hardware
component despite its state. This ensures that no hidden faults can stay undetected
in the system and possibly spread. Thus, from any state exists a transition to the
so-called “suspected” state; also from Standby as currently not used devices must
also be tested regularly.
It is even possible to revive faulty components, as, for example, environmental
changes could allow a component to function correctly again.
7.4.3 Hardware Condition Monitor—System Software
Support
One of the distinguished features of our platform is reconfiguration ability. As
already explained, the system is able to reconfigure the system in the case of faults.
Different scenarios are anticipated for the reconfiguration:
1. hardware malfunction,
2. permanent hardware failure, and
3. software failure.
All these scenarios share the same basic functionality, namely, the reconfiguration
of software and hardware. In contrast to standard operating systems where all such
reconfiguration has to be performed by the applications themselves, we propose that
the runtime itself has the capability and responsibility of performing the
reconfiguration.
This way, applications don’t have to be fully aware of all possible reconfiguration possibilities, which would increase application complexity and reconfiguration significantly. In contrast, by moving the reconfiguration ability from the
application directly into the operating system, we decouple the actual application
functionality from the fault tolerance reconfigurability mechanism.
In order for this to work, all applications must provide additional metadata such
as the required services (dependencies), processor time requirements, memory
requirements, etc. Such metadata information could be added to each application
during runtime or preferably already at compilation time.
This way, the system is always aware of all requirements and dependencies of
the running applications. Here an example: An application is typically dependent on
other services or resources, such as a logging service. The application just needs to
know how to access the logger, but the actual implementation is of no importance to
the application.
Thus, a first logger could log over a serial connection to another computer, and a
second logger writes the log to disk. Now, the reconfiguration in this case could be
applied on different software levels:
7.4 Software Support for Hardware Reconfiguration
105
component despite its state. This ensures that no hidden faults can stay undetected
in the system and possibly spread. Thus, from any state exists a transition to the
so-called “suspected” state; also from Standby as currently not used devices must
also be tested regularly.
It is even possible to revive faulty components, as, for example, environmental
changes could allow a component to function correctly again.
7.4.3 Hardware Condition Monitor—System Software
Support
One of the distinguished features of our platform is reconfiguration ability. As
already explained, the system is able to reconfigure the system in the case of faults.
Different scenarios are anticipated for the reconfiguration:
1. hardware malfunction,
2. permanent hardware failure, and
3. software failure.
All these scenarios share the same basic functionality, namely, the reconfiguration
of software and hardware. In contrast to standard operating systems where all such
reconfiguration has to be performed by the applications themselves, we propose that
the runtime itself has the capability and responsibility of performing the
reconfiguration.
This way, applications don’t have to be fully aware of all possible reconfiguration possibilities, which would increase application complexity and reconfiguration significantly. In contrast, by moving the reconfiguration ability from the
application directly into the operating system, we decouple the actual application
functionality from the fault tolerance reconfigurability mechanism.
In order for this to work, all applications must provide additional metadata such
as the required services (dependencies), processor time requirements, memory
requirements, etc. Such metadata information could be added to each application
during runtime or preferably already at compilation time.
This way, the system is always aware of all requirements and dependencies of
the running applications. Here an example: An application is typically dependent on
other services or resources, such as a logging service. The application just needs to
know how to access the logger, but the actual implementation is of no importance to
the application.
Thus, a first logger could log over a serial connection to another computer, and a
second logger writes the log to disk. Now, the reconfiguration in this case could be
applied on different software levels:
7.4 Software Support for Hardware Reconfiguration
105