Latent fault

Operation. Upon activation, a latent Fault produces a SAV Error, and when this Error affects the delivered service, a Failure occurs. 

Systems of which the number of states is either indefinite or as huge that all possible states covering V V is not practicable, should be observed closely to determine to which extent the verified states represent full scope of them and based on that comparison classify credibility of latent fault. 

The main purpose of the BBN is to estimate the significance of the outstanding errors remaining in the system at the end of the phase. This clearly depends on a wide variety of factors, many of which are usually implicit but are exposed in the BBN. One inq)ortant example is that the reliability of a piece of software will depend on its operational profile of inputs during use. It is assumed (as it is in some standards) that such information is inq)licitly factored in to the assessment i.e. the verification methods used are focused on the proposed usage of the system, so that faults that cause large numbers of failures are found quickly. There is some evidence that if this is true, software reliability is predictable provided latent fault numbers can be predicted [Bishop, Bloomfield, 1996]. 

One of the most important issues connected with digital I C is common cause failure (CCF). There exists the probability that a latent fault can exist in the system. This fault can be triggered and may propagate throughout the system as shown in Fig. Xll/3.1.1-1. In most software one subprogram/subroutine may be used many times in a full program. Naturally, if there is a fault, then it can be repetitive, and when used even with redundant channels the same mistake may recur. Naturally extra care must be taken to ensure with thorough validation and verification. 

Conventional reliability assessments of random failure rates for hard-wired systems are based on measured failure rates for all the system s components and an assumption of perfect routine testing (i.e., the routine testing detects all latent faults). This assessment approach can often yield umealistically low predictions for actual systems failure rates. The system failure rates will in practice be dominated by common-mode failures and not by random failures. 

NOTE Regarding the avoidance of latent faults, requirements elicitation can be performed after a first iteration of the system design subphase. 

The random hardware failures addressed by these metrics are limited to some of the item s safety-related electrical and electronic hardware parts, namely those that can significantly contribute to the violation or the achievement of the safety goal, and to the single-point, residual and latent faults of those parts. For electromechanical hardware parts, only the electrical failure modes and failure rates are considered. 

The Latent-Fault-Metric (LFM) is defined as follows ISO 26262, Part 5, Annex C ... 

This metric reflects the robustness of the item to latent faults either by coverage of faults in safety mechanisms or by the driver recognizing that the fault exists before the violation of the safety goal, or by design (primarily safe faults). A high latent-fault metric implies that the proportion of latent faults in the hardware is low. 

C3.1 This requirement applies to ASIL (B), (C), and D of the safety goal. The definition given by the following equation shall be used when calculating the latent-fault metric ... 

The failure rate assigned to latent faults can be determined using the diagnostic coverage of safety mechanisms that avoid latent faults of the hardware element. The following equation gives a conservative estimation of the failure rate associated with latent faults ... 

DCwith respect to latent faults Diagnostic Covcrage as a percentage... 

The ISO 26262 introduces the term of a perceived fault , but does so in a different context (in the context of perceiving latent faults In a technical systems, that have no diagnostic mechanism, but are perceivable by the driver, e.g. by a strange noise). The term perceived fault must not be misused in the context of hazard classification, simply assuming that a failure of a CMS, as soon as sit Is perceived by the user, is safe (a drastic example drivers would certainly perceive It when their steering wheel is blocked due to some technical fault, but nevertheless, would have few possibilities of avoiding an accident in this situation.). 

Of course, there is much more to know about technical safety concept creation, e.g. how to care about latent faults, how to ensure freedom from interference etc. so the recommendation for companies that are confronted with functional safety for the first time is to ask for consultancy by experienced experts. The TSC is the place where the most mistakes can occur to the author s experience. 

A latent failure refers to a component that is not checked for operability before the start of a mission thus, it could unknowingly be failed when required for use. When failure of the component occurs, it is not detected or annunciated. Certain latent faults can be of system safety concern because they are involved in system designs where operation is critical. Latency can significantly increase the potential safety risk because this situation effectively increases the component exposure time. The latent time period is the time between maintenance checks, which can often be significantly greater than the mission time. This large exposure time can make a large impact on the probability. Latency is also sometimes referred to as dormancy or dormant failure. 

Constraining architectural metrics, to cover faults, are defined as single point fault metrics and latent fault metrics, their definition being ... 

The latent fault metrics can be seen as the capacity of a system to control latent or hidden failures. 

The same principle can be applied to the latent fault metric. It is possible to allocate the various metrics to the different components of a system. 

---