This standard establishes uniform requirements and criteria for a performance-based sneak circuit analysis (SCA). This performance-based aspect of this standard requires that the organization's SCA capability be rated according to predetermined criteria for process capability and data maturity. Although it is a common industry practice for SCA to be performed using computerized tools, this standard does not mandate that any particular computerized methodology be used.

Purpose

Sneak circuit analysis may be performed on high-criticality systems to uncover inherent design flaws that may cause occurrence of an unwanted function or the inhibition of a desired function. The primary purpose of the SCA process is to identify and eliminate or control all sneak conditions that may lead to such unplanned modes of operation. In this regard, SCA is an important analysis technique because it uncovers latent system faults that otherwise may have gone undetected. SCA should be considered for application on high criticality systems, where undetected design flaws may cause catastrophic events such as loss of life, critical system failure, or loss of mission. To assure maximum analysis benefit while controlling cost, the SCA effort should be scoped to those specific high-criticality areas where sneak conditions are most likely to occur. The early identification and control of such conditions improves system safety and reliability, while enabling design changes to be made in a more cost-effective manner.

The defining cause and effect characteristics of a sneak condition are as follows:

? It is caused by an unintended system path (e.g., wiring, tubing, software interfaces, operator actions, instrumentation, mechanical interlocks, or some combination thereof) or condition (e.g., timing incompatibility) that was inadvertently introduced into the system.

? It leads to unintended system effects that range from an intermittent nuisance to complete system loss or loss of life.

Regardless of whether the SCA is performed using manual, semi-automated, or automated methods, a prerequisite is the collection, processing, and evaluation of detailed system design information. The SCA results may be used to support the activities of a variety of Systems Engineering functions, but its most important use is to aid in the improvement of design reliability prior to product manufacture and test. For this standard, there are four types of sneak conditions:

? sneak paths - Unexpected paths along which current, energy, or logical sequence flows in an unintended direction;

? sneak timing - Events occurring in an unexpected or conflicting sequence;

? sneak indications - Ambiguous or false displays of system operating conditions that may cause the system or operator to take an undesired action1;

? sneak labels - Incorrect or imprecise labeling of system functions (e.g., system inputs, controls, displays, and buses) that may cause an operator to apply an incorrect stimulus to the system. ;

The SCA process assures that the likelihood of unwanted functions or inhibition of desired functions is minimized for all designed-for operating modes. In this context, an unwanted function is a system response that violates a design requirement, and designed-for operating modes include all known states of system success. The analysis of sneak conditions can be considered static in nature because it does not involve stepping through all the possible combinations of inputs and system states. Instead, the analysis applies a rule base (i.e., sneak clues) to topological or functional models of the system to uncover potential sneak conditions. The models contain all possible connectivity paths; e.g., electrical current flow and data/signal flow. Because of its static nature, SCA is a good complement for simulation and testing, which are more dynamic in nature, but may be prone to overlook latent problems that occur only during unexpected operating modes.

¹ An example of a potential sneak indication is when two identical failure indications (i.e., fault signatures) can be generated by different system functions.

Customers who purchased AIAA S-102.2.5
also purchased

• AIAA S-102.1.4 : Performance-Based Failure Reporting, Analysis jsessionid=S6V76uvWEf9MRZHVWzPAeg**.app22?event=DOCUMENT_DETAILSreturn true" onMouseout="window.status=' ';return true">AIAA S-102.1.5 : Performance-Based Failure Review Board (FRB) Requirements
• AIAA S-102.2.2 : Performance-Based System Reliability Modeling Requirements
• AIAA S-102.2.4 : Performance-Based Product Failure Mode, Effects and Criticality Analysis (FMECA) Requirements

See More Documents