ANSI AIAA S-102.2.5-2009 Performance-Based Sneak Circuit Analysis (SCA) Requirements.pdf

《ANSI AIAA S-102.2.5-2009 Performance-Based Sneak Circuit Analysis (SCA) Requirements.pdf》由会员分享，可在线阅读，更多相关《ANSI AIAA S-102.2.5-2009 Performance-Based Sneak Circuit Analysis (SCA) Requirements.pdf（43页珍藏版）》请在麦多课文档分享上搜索。

1、ANSI/AIAA S-102.2.5-2009 American National Standard Performance-Based Sneak Circuit Analysis (SCA) Requirements Sponsored by American Institute of Aeronautics and Astronautics Approved 17 November 2008 American National Standards Institute Abstract This standard provides the basis for developing the

2、 analysis of sneak conditions. The sneak conditions may consist of hardware, software, operator actions, or combinations of these elements. The requirements for contractors, planning and reporting needs, and analytical tools are established. The linkage of this standard to the other standards in the

3、 new family of performance-based reliability and maintainability standards is described, and all of the keywords for use in automating the SCA process are provided. ANSI/AIAA S-102.2.5-2009 ii Library of Congress cataloging-in-publication data on file Published by American Institute of Aeronautics a

4、nd Astronautics 1801 Alexander Bell Drive, Reston, VA 20191 Copyright 2009 American Institute of Aeronautics and Astronautics All rights reserved No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without prior written permission of the publish

5、er. Printed in the United States of America ANSI/AIAA S-102.2.5-2009 iii Contents Foreword v 1 Scope. 1 1.1 Purpose . 1 1.2 Application . 2 2 Applicable Documents . 2 2.1 Normative References . 2 2.2 Relationship To Other S-102 Standards 3 3 Vocabulary . 4 3.1 Acronyms and Abbreviated Terms . 4 3.2

6、Terms and Definitions 4 4 General Requirements . 7 4.1 Contractor Responsibility . 7 4.2 Planning . 7 4.3 SCA Report 8 5 Detailed Requirements 8 5.1 Establish SCA Requirements and Define Analytical Ground Rules . 8 5.2 Establish SCA Technical Performance Metrics 9 5.3 Collect System Design Data 9 5.

7、4 Perform the Analysis 9 5.5 Sneak Condition Disposition 17 5.6 SCA Database . 18 5.7 Data Exchange Between SCA Process And Other Project Functions . 19 5.8 SCA Process Performance Evaluation 19 5.9 Lessons Learned . 21 5.10 Structured Review . 21 Annex A AIAA S-102 Document Tree (normative) . 24 An

8、nex B AIAA S-102 SCA Capability Level Requirements (normative) . 25 Annex C AIAA S-102 SCA Keyword Data Element Descriptions (normative) 28 Figures Figure 1 S-102 Standardized Set of Functional Operators 12 Figure 2 Five Basic Sneak Circuit Analysis Topographs . 13 Figure 3 Sneak Condition Dataset E

9、valuation . 22 Figure 4 Sneak Condition Disposition Evaluation 23 Tables Table 1 Sample Sneak Circuit Analysis Topological Clue List . 14 ANSI/AIAA S-102.2.5-2009 iv Table 2 AIAA S-102 Failure Severity Classification Criteria 16 Table 3 Sneak Condition Dataset Maturity Rating Criteria 20 Table 4 Sne

10、ak Condition Disposition Maturity Rating Criteria . 20 ANSI/AIAA S-102.2.5-2009 v Foreword A performance-based Sneak Circuit Analysis (SCA) standard has been developed to aid organizations in assuring that their SCA tasking presents a “value-added” contribution to the product-development effort. The

11、 need for such a standard arises from the absence of an accepted methodology for assessing the capability of reliability and maintainability (R plan the activities necessary to achieve a level of R appraise the performance of an R and identify the activities necessary to improve the performance of a

12、n R 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., sy

13、stem 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

14、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

15、system states. Instead, the analysis applies a rule 1An example of a potential sneak indication is when two identical failure indications (i.e., fault signatures) can be generated by different system functions. ANSI/AIAA S-102.2.5-2009 2 base (i.e., sneak clues) to topological or functional models o

16、f 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 overloo

17、k latent problems that occur only during unexpected operating modes. 1.2 Application This standard applies to acquisitions for the design, development, fabrication, test, and operation of commercial, civil, and military systems, equipment, and associated computer programs. This standard provides cri

18、teria for rating the capability of an acquisition projects SCA practices and assigning the practice to one of five predetermined levels of performance capability. The capability criteria provide the logical sequence of activities for improving the effectiveness of an existing SCA practice by advanci

19、ng in stages. Organizations may evaluate their existing SCA practices against these minimum acceptable criteria to identify the features that need to be added to improve their existing SCA practices. This standard also applies to the integration of the SCA database with a project R (2) Hardware Reli

20、ability any undesired state of a component or system; (3) Components a defect or flaw in a hardware or software component, NOTE: (1) An accident may cause a fault. NOTE (2) A fault may cause a failure. NOTE (3) A fault does not necessarily require failure. maturity level measure of the degree of acc

21、uracy of a data product, as developed using a specified set of input data, in relation to what is considered the best achievable results mission assurance project-wide identification, evaluation, and mitigation or control of all existing and potential deficiencies that pose a threat to mission succe

22、ss, throughout the product life cycle NOTE Deficiencies include damage-threatening hazards, mission-impacting failures, and system performance anomalies that result from unverified requirements, optimistic assumptions, unplanned activities, ambiguous procedures, undesired environmental conditions, l

23、atent physical faults, inappropriate corrective actions, and operator errors. network forest a higher-order network diagram depicting the interrelationships among the numerous network trees network tree a functional, topologically oriented circuit segment that is analyzed for the existence of sneak

24、circuits and conditions. NOTE Numerous network trees are generated to describe the system under analysis. partitioning subdivision of functions at the circuit or device level into separate, cross-referenced functions, to aid in the data reduction / pathfinding process, as well as to facilitate the g

25、eneration of topological network trees performance-based R b) the SCA requirements as needed to support the project, including milestones for developing fault trees, or modifying existing fault trees; c) scope and ground rules of the SCA; 4Failure compensation methods may include special design feat

26、ures, analyses, inspections, tests, controls, instructions, or operational corrective actions, such as replacement, reconfiguration, repair, or preventive maintenance. ANSI/AIAA S-102.2.5-2009 8 d) detailed procedures for selecting the set of sneak conditions of concern; e) detailed procedures for e

27、stablishing the system level at which sneak conditions are identified; f) detailed procedures for constructing functional flow or network tree models, and samples thereof; g) detailed SCA process descriptions and flow diagrams that include the approach for applying sneak clues to identify sneak cond

28、itions; h) detailed procedures for documenting and reporting the SCA data/results in a timely manner; and i) definitions of SCA data attributes; i.e., data characteristics and formats that accommodate the needs of other project functions, including those of reliability, maintainability, system safet

29、y, and risk management. The SCA process shall be planned to support timely and cost-effective implementation of the R b) identifying the design data sources; ANSI/AIAA S-102.2.5-2009 9 c) selecting the types of sneak conditions to be identified and the analysis methods75.2 Establish SCA Technical Pe

30、rformance Metrics to be used; d) describing how consistency will be achieved among independently performed SCA; e) defining the procedures and nomenclature by which sneak conditions will be documented; and f) describing the extent that sneak conditions due to external system interfaces and influence

31、s (e.g., human errors, operating environments, etc.) will be identified. The out-of-scope areas that require only interface analysis also shall be identified. Care shall be taken to ensure that the SCA effort is limited to those high-criticality areas where sneak conditions are considered most likel

32、y to occur. The contractor shall establish SCA Technical Performance Metrics for purposes of tracking and reporting the progress of the SCA activities. 5.3 Collect System Design Data Prior to beginning the evaluation of possible undesired sneak conditions, the contractor shall collect sufficient sys

33、tem design information to identify all functional and physical dependencies in the system that fall within analytical ground rules to be specified by the contractor (see Reference 5). The system design information shall include the following: Schematics Indentured parts lists Wire lists and intercon

34、nects Design specifications Descriptions of the mission phases, mission environments, and all normal, degraded, and contingency system modes that are applicable to each mission phase The statement of work If a Capability Level 3 or higher SCA is required, this information shall be entered in the SCA

35、/FMECA database to allow cross-referencing of identified sneak conditions against official design drawings. 5.4 Perform the Analysis Following the collection of system design information, the contractor shall perform a structured analysis approach that achieves the following objectives: a) developme

36、nt of partitioned system models that are based on functional interrelationships (i.e., functional diagrams) or energy flow (i.e., network trees); b) identification of sneak conditions; c) evaluation of sneak condition severity; d) identification of sneak condition detection methods; e) if a Capabili

37、ty Level 4 or higher SCA is required, estimation of sneak condition probability of occurrence; and f) documentation of identified sneak conditions; 7This is a process validation activity when it includes evaluation of the appropriateness of the SCA process prior to its use. ANSI/AIAA S-102.2.5-2009

38、10 5.4.1 Development of Partitioned System Models that are Based on Functional Interrelationships or Energy Flow The contractor shall develop partitioned system models that are based on functional interrelationships or energy flow. The models shall be developed to a level of detail that allows a com

39、prehensive analysis of possible sneak conditions. The models shall provide an accurate representation of the operating modes and time-based interrelationships of the systems functions. The contractor shall develop these models by partitioning the system-level or subsystem-level design into smaller,

40、functionally related segments that permit efficient and effective application of the sneak clue list. Factors to be considered in the partitioning effort shall include, but are not limited to, mission time intervals, functional or energy inputs, functional or energy outputs, flow paths, switching fu

41、nctions, event sequences, modes and transitions, and feedback paths and controls Items to be distinctly identified in partitioned segments shall include, but are not limited to: Power Ground Large signal distribution nodes Input signal lines having a large fan-in Control signals Transistors Relays C

42、omplex sequential devices 5.4.1.1 Functional Diagram Models If the contractor elects to perform SCA using functional diagram models, then these models shall be built in a manner that illustrates the operation and inter-relationship between functional entities of the system at all levels as dictated

43、by the drawings and schematics. The functional diagram shall be developed by converting the items in the partition segment into functionally equivalent building block symbols or functional operators. If a Capability Level 3 or higher SCA is required, the contractors functional diagram models shall b

44、e constructed using the standard set of functional operators. For this document, the standard set of functional operators is as illustrated by Figure 1. The logic for properly manipulating these functional operators is defined in algorithms provided in Reference 5 AIAA S-102.2.1 (Draft), Functional

45、Dependency and Architectural Modeling Requirements). The functional operators shall be used singularly to model simple devices and in combinations to model functionally complex assemblies or configurations. The functional diagrams shall be analyzed with the aid of functional and design-related sneak

46、 clues85.4.1.2 Network Tree Models to identify any sneak conditions that may exist. The output of this structured approach shall include functional path reports that can be used to redraw the functional flow models. If the contractor elects to perform SCA using network tree models, then the partitio

47、ned system segments shall be used to generate topologically oriented network tree models that are the functionally equivalent of design schematics. These network trees shall be analyzed to identify SCA topographs. Figure 2 provides the five basic SCA topographs. The component-level network tree mode

48、ls shall reflect the interrelationships between partition segments and the components found in each segment. The network tree models shall be constructed in a manner that facilitates the application of sneak clues and the 8Sneak clues can be stated in many different ways, and as a result, there are

49、several versions of the sneak clue list currently in use; e.g., MIL-STD-1543B, Annexes B and C. ANSI/AIAA S-102.2.5-2009 11 identification of sneak conditions. Accordingly, component-level network tree models shall follow the following rules to the extent practicable: a) top-to-bottom or left-to-right power flow; b) top-to-bottom or left-to-right signal flow; c) adjacent intersect nodes collapsed; d) symmetry/similarity maximized; and e) crossed lines minimized. The contractor shall elect to develop either top-down or left-to-ri