1、 Standard ANSI/AIAA S-102.1.4-2009 Performance-Based Failure Reporting, Analysis (2) Hardware Reliability any undesired state of a component or system; (3) Components a defect or flaw in a hardware or software component NOTE 1 A fault may cause a failure. NOTE 2 A fault does not necessarily require
2、failure. maturity level measure of the degree of accuracy 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 a top-down, comprehensive, risk management process that is performed over the life cycle of a
3、 high unit-value system to identify, evaluate, and mitigate or control all potential hazards and failures that pose an unacceptable risk to mission success. NOTE Potential, damaging-threatening hazards and mission-impacting failures may be caused by requirements, developmental activities, handling m
4、ethods, environmental conditions, physical interactions, functional characteristics, or operator actions. performance-based R All of the candidate root causes are most likely identified. 3 MEDIUM Most of the information believed necessary to investigate root causes effectively is identified, collect
5、ed, and analyzed; Most of the candidate root causes are most likely identified. 2 LOW- to-MEDIUM Only some of the information believed necessary to investigate root causes effectively is identified, collected, and analyzed; Only some of the candidate root causes are most likely identified. 1 LOW Lit
6、tle or no information believed necessary to investigate root causes effectively is identified, collected, and analyzed; No candidate root causes are identified, and only the proximate cause is known. Table 3 Corrective Action Maturity Rating Criteria Maturity Rating Corrective Action Description 5 H
7、IGH FRB or equivalent function chooses comprehensive corrective actions that are based on appropriate technical or statistical analysis methods that fully address both the definite and candidate root cause mitigation. 4 MEDIUM to-HIGH FRB or equivalent function approves comprehensive correction acti
8、ons that are based on appropriate technical or statistical analysis methods that fully address candidate root cause mitigation. 3 MEDIUM FRB or equivalent function approves limited corrective actions that are based on appropriate technical or statistical analysis methods, but the mitigation of candi
9、date root causes is not fully addressed. 2 LOW-to-MEDIUM FRB or equivalent function approves “use as is” disposition based on inappropriate technical or statistical analysis methods. 1 NEGLIGIBLEto-LOW FRB or equivalent function ignores the definite root cause, even though identification approach is
10、 based on appropriate technical or statistical analysis methods; FRB or equivalent function approves “use as is” disposition based on inappropriate technical or statistical analysis methods. ANSI/AIAA S-102.1.4-2009 14 Figure 1 Sample FRACAS Output Evaluation Matrix 5.10 Lessons Learned If a Capabil
11、ity Level 3 FRACAS is required, the FRACAS shall review FRACAS products of other projects, including analyses of project trends, to identify candidate lessons learned topics. The FRACAS shall then evaluate for quality and prioritize these candidate lessons and forward them to the Lessons Learned App
12、roval Authority (LLAA) for further consideration. If a Capability Level 4 FRACAS is required, the FRACAS shall also consider aspects of its own process that may constitute lessons learned candidates, submit the lessons to the LLAA for review and approval, and share the lessons with the FRACAS of oth
13、er projects throughout the enterprise. The FRACAS process shall meet annual improvement goals established by the project and institutional management. The improvement goals shall be directed at achieving a level of FRACAS process capability that is consistent with the level of residual risk acceptab
14、le to the project. This residual risk results from the potential for operational failures to occur if the FRACAS were to perform inadequate assessments of failures and correction actions. An independent assessment of the FRACAS process shall be performed at intervals not to exceed one year. This ass
15、essment shall employ methods or individuals that are different from but complementary to those used in the project to evaluate a representative sample of FRACAS reports generated over the review period. Included in the output shall be metrics for the progress made in process improvements, and the id
16、entification of any remedial steps necessary to meet improvement milestones. If a Capability Level 5 FRACAS is required, the contractor shall exchange non-proprietary, approved lessons learned with other organizations, entering into agreements and employing safeguards to protect 5 4 3 2 1 High Signi
17、ficant Moderate Low Negligible Failure Consequence Rating FRACAS Output Maturity Rating Green means residual risk is acceptable Yellow means residual risk warrants Watch Item status Red means residual risk is unacceptable Low risk of mission impact / High maturity FRACAS output High risk of mission
18、impact / Low maturity FRACAS output ANSI/AIAA S-102.1.4-2009 15 security-classified, International Traffic in Arms Regulations (ITAR)-restricted, proprietary, or other sensitive data. The received data shall be reviewed to identify significant recommendations that should be implemented in the projec
19、t or enterprise-wide. 5.11 Structured Review If a Capability Level 5 FRACAS is required, the contractor shall develop and apply a structured review process to aid participation in and evaluation of the FRACAS process. The review process shall include personnel who are cognizant of anomalies in syste
20、ms similar to the one being developed. FRACAS product and process-based lessons learned that are relevant to the system being developed shall be gathered across the enterprise and used to develop review checklists that support timely implementation of the structured review process. The review checkl
21、ists shall reflect the technical knowledge, process insights, anomaly lessons learned, or other sources of clues that aid the uncovering of escapements in the FRACAS process. ANSI/AIAA S-102.1.4-2009 16 Annex A AIAA S-102 Standards Document Tree (normative) Performance-Based Reliability & Maintainab
22、ility Program Requirements S-102.1.1 R&M Program Planning S-102.1.2 Subcontractor and Supplier Monitoring & Control S-102.1.3 R&M Program Working Groups & Reviews S-102.1.4 Failure Reporting, Analysis, and Corrective Action System S-102.1.5 Failure Review Board S-102.1.6 R&M Critical Item Risk Manag
23、ement S-102.1.7 Project R&M Database System S-102.1 Performance-Based R&M Management Requirements S-102.2 Performance-Based R&M Engineering & Analysis Requirements S-102.3 Performance-Based R&M Testing Requirements S-102.3.1 Environmental Stress Screening S-102.3.2 Reliability Development Growth Tes
24、ting S-102.3.3 Reliability, Maintainability, and Availability Demonstration Testing S-102.3.4 Reliability Life Testing S-102.3.5 Design of Tests S-102.0 Performance-Based Reliability & Maintainability Program General Requirements S-102.2.1 Functional Dependency & Architecture Modeling S-102.2.2 Syst
25、em Reliability Modeling S-102.2.3 Component Reliability Predictions S-102.2.4 Product Failure Mode, Effects, and Criticality Analysis S-102.2.5 Sneak Circuit Analysis S-102.2.6 Design Concern & Drawing Error Analysis S-102.2.7 Parts Stress Derating Analysis S-102.2.8 Worst Case Analysis S-102.2.9 Hu
26、man Error Predictions S-102.2.10 Environmental Event Survivability Prediction S-102.2.11 Anomaly, Detection, and Response Analysis S-102.2.12 Maintainability Predictions S-102.2.13 Operational Dependability and Operational Availability Modeling S-102.2.14 Hazard Analysis S-102.2.15 Software Reliabil
27、ity Predictions S-102.2.16 Process Failure Mode, Effects, and Criticality Analysis S-102.2.17 Event Tree Analysis S-102.2.18 Fault Tree Analysis S-102.2.19 Fishbone Analysis S-102.2.20 R&M Similarity and Allocations Analysis S-102.2.21 Parts Engineering and Analysis S-102.2.22 Stress and Damage Simu
28、lation Analysis ANSI/AIAA S-102.1.4-2009 17 Annex B AIAA S-102 FRACAS Capability Level Requirements (normative) B.1 The Capability Level 1 FRACAS shall include the following tasks: B.1.1 Prior to implementing the FRACAS process, establish, document, and approve FRACAS requirements and operating proc
29、edures that include: Criteria for failure identification, verification, analysis, and corrective action (including use-as-is) (this is a process validation activity when it includes evaluation of the appropriateness of the failure analysis approach prior to its use) Authority over failure dispositio
30、n and closure, and over resources needed to support this activity Management structure for assuring closed-loop disposition of failure reports in a timely manner in accordance with the project schedule and milestones B.1.2 Timely establishment of FRACAS implementation Technical Performance Metrics (
31、TPM). B.1.3 Timely documentation of all verified anomalies throughout the acquisition life cycle in accordance with the contract and the following requirements: Brief description of each reported anomaly event Verification of each reported anomaly prior to opening an anomaly report Identification, a
32、pproval, and implementation of the corrective action(s) necessary to either prevent the recurrence of the verified anomaly throughout the project life cycle or mitigate the effects of its reoccurrence Closure of the anomaly report when all corrective action(s) has been performed satisfactorily Summa
33、rization of all anomaly reports status B.1.4 Timely analysis of each verified anomaly to determine the proximate cause(s), and subsequent documentation of findings in the anomaly report. B.1.5 Maintenance of all verified anomaly reports as controlled records throughout the acquisition life cycle in
34、accordance with the contract and an established records control and retention policy. B.2 The Capability Level 2 FRACAS shall include all the tasks in Capability Level 1 plus the following: B.2.1 Timely documentation of the detail of each reported anomaly event to include the following information:
35、Definitions of all acronyms and a clear description of the anomaly, using the formal organized writing style common to published technical papers A detailed description of the test configuration or operating environment, and of all relevant events leading to the anomaly Where applicable to hardware
36、failures, photographs, or diagrams depicting the failed component For hardware anomalies: An equipment/device reference identifier, functional flow diagrams, schematics, or other representations necessary to provide a complete description of the intended function and observed anomaly ANSI/AIAA S-102
37、.1.4-2009 18 For software anomalies: Software module reference identifier, logic flow diagrams, computer code, or other representations necessary to provide a complete description of the intended function and observed anomaly A flowchart, frequency spectra graph, failure timeline or other appropriat
38、e depiction of the anomaly process B.2.2 Augment Task B.1.2 with timely analysis of each verified anomaly to determine the contributing/intermediate cause(s), and subsequent documentation of findings in the anomaly report. B.3 The Capability Level 3 FRACAS shall include all the tasks in Capability L
39、evel 2 plus the following: B.3.1 Prior to implementing the closed-loop FRACAS process, document and approve a FRACAS plan or procedure that defines the following: FRACAS operating requirements Organization(s) responsible for implementing the FRACAS process Criteria for identifying anomaly events tha
40、t are subject to reporting, verification, analysis, corrective action, and closure Detailed procedures for anomaly event reporting, anomaly verification or validation, anomaly analysis, corrective action, and anomaly report closure FRACAS data attributes B.3.2 Augment Task B.2.2 with timely analysis
41、 of each verified anomaly to determine the root cause(s), and subsequent documentation of findings in the anomaly report. B.3.3 Timely identification and comparison of the alternative corrective action(s) with the corrective action(s) approved for implementation to assess suitability of the decision
42、, and subsequent documentation of findings in the anomaly report. B.3.4 Timely correlation of each new verified anomaly of the project with all previous verified anomalies of the project to identify anomaly trends6that pose unacceptable risk to mission success, and as needed, determination of approp
43、riate preventive or corrective action to mitigate that risk. B.3.5 Timely development and maintenance of a FRACAS database that meets the following requirements: (1) controlled opening, modification, and closure of anomaly reports, (2) selective retrieval, sorting, and querying of anomaly data, (3)
44、an on-line help function that explains each data entry field on the anomaly report form, and (4) a parallel review and approval capability7that allows simultaneous reviews and approvals of each anomaly report. B.3.6 Timely transmittal of anomaly reports to all interested project functions, such as,
45、Design, R&M, System Safety, Maintenance, Logistics, Manufacturing, Risk Management, and Test. B.3.7 Timely evaluation of all aspects of the FRACAS process, including its implementation and data products, to identify candidate product-based and process-based lessons learned candidates. Evaluate 6Iden
46、tification of anomaly trends includes creating trend reports for the attention of project management and enterprise management. 7In contrast to a serial review process, this permits reviewers such as system safety and reliability engineers to review and approve proposed corrective actions without wa
47、iting for others to approve the report. ANSI/AIAA S-102.1.4-2009 19 for quality and prioritize these candidate lessons learned, and forward them to the LLAA for appropriate action. B.4 The Capability Level 4 FRACAS shall include all the tasks in Capability Level 3 plus the following: B.4.1 Include r
48、elevant enterprise-wide anomaly reports with other input required for Task B.3.4 (correlation of verified anomalies). B.4.2 Collect the following information and use as needed in Task B.3.2 (analyze each verified anomaly to determine the root causes): (1) principal analyses performed during the desi
49、gn phase on the failed item or on a higher level item (e.g., reliability predictions, Failure Mode and Effects Analysis (FMEA), Worst Case Analysis (WCA), Fault Tree Analysis (FTA), Part Electrical Stress Analysis (PSA), Redundancy Verification Analysis, Sneak Circuit Analysis (SCA), or tradeoff studies), and (2) principle reviews performed on the failed item or a higher level item prior to the reported failure (e.g., peer reviews, design reviews, test reviews, or software walkthroughs). B.4.3 Timely development and mai
