In fact, we should answer one question: What is system software able to do and
should do to fulfill the two requirements—real-time processing and fault tolerance.
To achieve this goal, one has to present constructive design principles to follow and
apply at all steps.
A number of principles will be introduced on the way of further development,
but the first principle of the system development here is simplicity. The rational
behind this is obvious: complex system even without fault tolerance is hard to
manage and understand, thus making the fault tolerant even harder. Simple systems,
i.e., systems that use a simpler architecture but are still able to meet the system
requirements are easier to implement, control, and make fault tolerant.
However, the newly developed system software will need some extra features,
thus it will not be absolutely simple (not simpler than simple). But again, new
features should be designed and developed with the same approach—simplicity,
better say, maximum possible simplicity.
From all possible options to support the new features of the system (will be
specified further), we will choose the simplest and the most promising choices. This
means that if we have some options to realize a new feature at the language, OS or
application program levels, we will always choose if possible the language level.
This allows the omission of complex dynamics and uncertainty during program
execution. At the same time, if a new feature requires runtime support, this support
will be provided by the OS, again, by the simplest way.
Therefore, the additional overhead by the runtime support will be as minimal as
possible. It is expected that performance and other additional overhead caused by
the support of new features will not be significant and can be in the first consideration ignored. We call this principle essential redundancy.
In this work, system software is considered as the combination of a programming language and an operating system with runtime support for all languages
features. System software for embedded systems usually provides some RT
features.
Regarding RT, we will focus on the optimization of already existing system
software specifications, efficiency analysis of existing solutions, and where possible
the reduction of complexity in these solutions. The logic behind the research for
new features is shown in Fig. 6.1 as a comparison of RT and FT.
(A possible realization with required features is shown in Fig. 6.1 with the
following meaning of capital letters: HW—Hardware, OS—Operating System, AP
—Application Program.)
Next, we present some comments on real-time and fault tolerance features and
the supportive means by the operating system. Assume that a program requires RT
access to program data.
To guarantee the required real-time constraints, it is important to exclude file
structures, as these do, in general, not allow direct and equal (in time) access to the
data. Instead, simpler data structures with guaranteed design equality to access each
data element or record should be introduced.
60
6 System Software Support for Hardware Deficiency…
should do to fulfill the two requirements—real-time processing and fault tolerance.
To achieve this goal, one has to present constructive design principles to follow and
apply at all steps.
A number of principles will be introduced on the way of further development,
but the first principle of the system development here is simplicity. The rational
behind this is obvious: complex system even without fault tolerance is hard to
manage and understand, thus making the fault tolerant even harder. Simple systems,
i.e., systems that use a simpler architecture but are still able to meet the system
requirements are easier to implement, control, and make fault tolerant.
However, the newly developed system software will need some extra features,
thus it will not be absolutely simple (not simpler than simple). But again, new
features should be designed and developed with the same approach—simplicity,
better say, maximum possible simplicity.
From all possible options to support the new features of the system (will be
specified further), we will choose the simplest and the most promising choices. This
means that if we have some options to realize a new feature at the language, OS or
application program levels, we will always choose if possible the language level.
This allows the omission of complex dynamics and uncertainty during program
execution. At the same time, if a new feature requires runtime support, this support
will be provided by the OS, again, by the simplest way.
Therefore, the additional overhead by the runtime support will be as minimal as
possible. It is expected that performance and other additional overhead caused by
the support of new features will not be significant and can be in the first consideration ignored. We call this principle essential redundancy.
In this work, system software is considered as the combination of a programming language and an operating system with runtime support for all languages
features. System software for embedded systems usually provides some RT
features.
Regarding RT, we will focus on the optimization of already existing system
software specifications, efficiency analysis of existing solutions, and where possible
the reduction of complexity in these solutions. The logic behind the research for
new features is shown in Fig. 6.1 as a comparison of RT and FT.
(A possible realization with required features is shown in Fig. 6.1 with the
following meaning of capital letters: HW—Hardware, OS—Operating System, AP
—Application Program.)
Next, we present some comments on real-time and fault tolerance features and
the supportive means by the operating system. Assume that a program requires RT
access to program data.
To guarantee the required real-time constraints, it is important to exclude file
structures, as these do, in general, not allow direct and equal (in time) access to the
data. Instead, simpler data structures with guaranteed design equality to access each
data element or record should be introduced.
60
6 System Software Support for Hardware Deficiency…