Beneath the facade of the applications code of a well-designed real-time embedded system lies
intrinsic firmware that facilitates a fast and effective means of detecting and diagnosing inevitable
hardware failures. These failures can encumber the availability of a system, and, consequently, an
identification of the source of the malfunction is needed. It is shown that the number of possible
origins of all manner of failures is immense. As a result, fault models are contrived to encompass
prevalent hardware faults. Furthermore, the complexity is reduced by determining syndromes for
particular circuitry and applying test vectors at a functional block level.
Testing phases and philosophies together with standardisation policies are defined to ensure the
compliance of system designers to the underlying principles of evaluating system integrity. The three
testing phases of power-on self tests at system start up, on-line health monitoring and off-line
diagnostics are designed to ensure that the inherent test firmware remains inconspicuous during
normal applications. The prominence of the code is, however, apparent on the detection or diagnosis
of a hardware failure.
The authenticity of the theoretical models, standardisation policies and built-in test philosophies are
illustrated by means of their application to an intricate real-time system. The architecture and the
software design implementing the idealogies are described extensively. Standardisation policies,
enhanced by the proposition of generic tests for common core components, are advocated at all
hierarchical levels.
The presentation of the integration of the hardware and software are aimed at portraying the
moderately complex nature of the task of generating a set of built-in tests for a real-time embedded
system. In spite of generic policies, the intricacies of the architecture are found to have a direct
influence on software design decisions. It is thus concluded that the diagnostic objectives of the user
requirements specification be lucidly expressed by both operational and maintenance personnel for
all testing phases. Disparity may exist between the system designer and the end user in the
understanding of the requirements specification defining the objectives of the diagnosis. It is thus
essential for complete collaboration between the two parties throughout the development life cycle,
but especially during the preliminary design phase. Thereafter, the designer would be able to decide
on the sophistication of the system testing capabilities. / Thesis (M.Sc.)-University of Natal, Durban, 1991.
| Identifer | oai:union.ndltd.org:netd.ac.za/oai:union.ndltd.org:ukzn/oai:http://researchspace.ukzn.ac.za:10413/5680 |
| Date | January 1991 |
| Creators | Olander, Peter Andrew. |
| Source Sets | South African National ETD Portal |
| Language | en_ZA |
| Detected Language | English |
| Type | Thesis |
Page generated in 0.0018 seconds