A Generalization of Diagnosability Analysis

A new concept of generalized diagnosability is proposed for a formal diagnosis model which incorporates most diagnosis models so far proposed. A self-diagnosis model consists of a set of units which can test other units and be tested by other units. Generalized diagnosability is a new measure of diagnosability in system diagnosis problems which is extensively studied with respect to self-diagnosis models. This diagnosability expresses explicitly such information as (1) the maximum number of units to be identified as faulty, (2) the maximum number of units to be identified as fault-free, and (3) the maximum number of units whose states are definitely identified when the upper bound on the number of faulty units is assumed. Conditions for generalized diagnosability are expressed by certain relations between the power sets of a set of faulty units. Since these conditions are of the form that they must be checked all over the possible syndrome, it is generally difficult to investigate generalized diagnosability. However, these conditions are meaningful in cases in which the graph of a diagnosis model has symmetricity, or a diagnosis model has a constrained structure about the relation between fault patterns and syndromes. Some examples of these cases are presented. Furthermore, we discuss the problem of finding the minimal fault pattern consistent with a given syndrome. This problem is formulated as a mathematical programming problem with the same relations both in constraints and objective functions as those used to express conditions for generalized diagnosability

Built-in tests for a real-time embedded system.

Thesis (M.Sc.)-University of Natal, Durban, 1991.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