1. A common logger component preprocesses the log data and saves it on a device.
Two hardware configurations in this case drivers that have the same interface
and provide thus also the same service are present in the system. If now, for
example, the disk fails, the system could transparently replace the faulty disk
device by the serial device.
2. Two different logger components that provide the same service are present in the
system and thus if one fails, the other one could take over.
As shown by this small example, the reconfigurability feature can be applied on
different levels in the system with their respective advantages and disadvantages.
The implementation on a lower level in the software hierarchy results in less
dependencies and in general smaller components.
However, the first version shares a single point of failure, the preprocessing
component of which no alternative version is available. In that sense, version two
promises to be more reliable as it has no single point of failure. As a conclusion, it
can thus be stated that the granularity of the implementation of an alternative
version should be chosen on the lowest level as possible, as long as an alternative
version is available. Single points of failure must be omitted.
A Reconfiguration Monitor (RM) in the runtime is aware of the current and all
possible configurations in the system and is also responsible for executing the
reconfiguration. The RM can, based on the available metadata of every resource or
component, generate the map of all possible configurations.
The number of these configurations could theoretically be quite large in large
software systems as even for n instances of the same entity, n! possibilities exist to
satisfy the system.
However, in concrete systems, it is not expected to have much less possibilities.
The total number of configurations is shown in Eq. 7.2.
c tot ¼
Y j
i¼1
n i
k i
ð7:2Þ
where j is the total number of distinct resource entity types, n i the number of
available entity alternatives of type i, and k i is the number of instances the system
requires to operate. The assumption here is that every implementation of one type is
only instantiated once and that the implementations are distinguishable from each
other.
This is reasonable as not all implementation of one type might be equally
powerful and efficient.
If all metadata information is already available at compilation and link time, in
other words, if the programming language is powerful enough to express all
dependencies and requirements at the language level, all possible reconfigurations
could be pre-calculated and stored in the boot image.
106
7 Testing, Checking, and Hardware Syndrome
Two hardware configurations in this case drivers that have the same interface
and provide thus also the same service are present in the system. If now, for
example, the disk fails, the system could transparently replace the faulty disk
device by the serial device.
2. Two different logger components that provide the same service are present in the
system and thus if one fails, the other one could take over.
As shown by this small example, the reconfigurability feature can be applied on
different levels in the system with their respective advantages and disadvantages.
The implementation on a lower level in the software hierarchy results in less
dependencies and in general smaller components.
However, the first version shares a single point of failure, the preprocessing
component of which no alternative version is available. In that sense, version two
promises to be more reliable as it has no single point of failure. As a conclusion, it
can thus be stated that the granularity of the implementation of an alternative
version should be chosen on the lowest level as possible, as long as an alternative
version is available. Single points of failure must be omitted.
A Reconfiguration Monitor (RM) in the runtime is aware of the current and all
possible configurations in the system and is also responsible for executing the
reconfiguration. The RM can, based on the available metadata of every resource or
component, generate the map of all possible configurations.
The number of these configurations could theoretically be quite large in large
software systems as even for n instances of the same entity, n! possibilities exist to
satisfy the system.
However, in concrete systems, it is not expected to have much less possibilities.
The total number of configurations is shown in Eq. 7.2.
c tot ¼
Y j
i¼1
n i
k i
ð7:2Þ
where j is the total number of distinct resource entity types, n i the number of
available entity alternatives of type i, and k i is the number of instances the system
requires to operate. The assumption here is that every implementation of one type is
only instantiated once and that the implementations are distinguishable from each
other.
This is reasonable as not all implementation of one type might be equally
powerful and efficient.
If all metadata information is already available at compilation and link time, in
other words, if the programming language is powerful enough to express all
dependencies and requirements at the language level, all possible reconfigurations
could be pre-calculated and stored in the boot image.
106
7 Testing, Checking, and Hardware Syndrome