GEIA-STD-0009-2008 Reliability Program Standard for Systems Design Development and Manufacturing (Formerly TechAmerica GEIA-STD-0009)《系统设计 开发和制造的可靠性计划标准》.pdf

《GEIA-STD-0009-2008 Reliability Program Standard for Systems Design Development and Manufacturing (Formerly TechAmerica GEIA-STD-0009)《系统设计 开发和制造的可靠性计划标准》.pdf》由会员分享，可在线阅读，更多相关《GEIA-STD-0009-2008 Reliability Program Standard for Systems Design Development and Manufacturing (Formerly TechAmerica GEIA-STD-0009)《系统设计 开发和制造的可靠性计划标准》.pdf（72页珍藏版）》请在麦多课文档分享上搜索。

1、ANSI/GEIA-STD-0009-2008 Approved: November 13, 2008 ITAA STANDARD GEIA-STD-0009 Reliability Program Standard for Systems Design, Development, and Manufacturing GEIA-STD-0009 August 2008 INFORMATION TECHNOLOGY ASSOCIATION OF AMERICA Copyright Government Electronics eventually, it is the user. 1.3 Tai

2、loring This standard does not specify the details concerning “how to” engineer a system/product for high reliability. Nor does it mandate the methods or tools a developer would use to implement the process requirements. The tailoring is dependent upon customers funding profile, developers internal p

3、olicies and procedures and negotiations between the customer and developer. 2 Copyright Government Electronics the inputs to each objective are often the outputs of another objective. Copyright Government Electronics or that a certain course of action is preferred but not necessarily required; or th

4、at (in the negative form) a certain course of action is discouraged but not prohibited. Supplier Provides a product or group of products to a customer. The supplier can be a vendor that has a product that does not need development, or a developer that must develop the product or products. System/Pro

5、duct A system/product is an end item that may consist of hardware, software, firmware, facilities, data, materials, personnel, services, techniques, and processes. Systems Engineering A branch of engineering whose responsibility is creating and executing an interdisciplinary process to ensure that c

6、ustomer and users needs are satisfied in a high quality, trustworthy, cost efficient, and schedule compliant manner throughout a systems entire life cycle, from development to operation to disposal. Technical Review An event at which the progress of the technical effort is assessed relative to its g

7、overning plans and technical requirements. User Individual, organization, or enterprise that uses, applies, or operates the product. 9 Copyright Government Electronics & Information Technology Association Provided by IHS under license with GEIA Not for ResaleNo reproduction or networking permitted w

8、ithout license from IHS-,-,-GEIA-STD-0009 Term Definition Verification Confirmation by examination and provision of objective evidence that the specified requirements to which the end product is built, coded, or assembled have been fulfilled. 10 Copyright Government Electronics & Information Technol

9、ogy Association Provided by IHS under license with GEIA Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-GEIA-STD-0009 11 4 Objective 1: Understand Customer/User Requirements and Constraints 4.1 Introduction (Informative) The focus of the first objective is to devel

10、op an understanding of the customers system/product reliability requirements and constraints (both internal and external) and clearly communicate the developers understanding of the customers requirements. The first objective defines the reliability requirements, assessment criteria, controls, and r

11、esponsibilities of all organizations involved in order to ensure program success. Figure 2 graphically depicts the operation of this Objective. Reliability is the ability/probability of the system/product to perform its intended functions over the expected user and environmental profile for a given

12、period of time. The failure definitions must be coordinated with the customer because not all failures (hardware, software, firmware, process, procedure, or user) are reliability failures but must be assessed for potential corrective action. Reliability requirements are quantifiable and measurable m

13、etrics used to assess the compliance of the contractual requirements. 4.2 Mission and Goals (Informative) The mission of this objective is to assemble a multifunctional team (user, customer, and developer) to 1. understand the customers requirements, failure definitions, user and environmental profi

14、les, and 2. influence the design based on the users needs and constraints. Copyright Government Electronics & Information Technology Association Provided by IHS under license with GEIA Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-GEIA-STD-0009 Figure 2 Objective

15、 1 Inputs, Activities, and Output 12 Copyright Government Electronics & Information Technology Association Provided by IHS under license with GEIA Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-GEIA-STD-0009 4.3 People and Organizations (Normative) Multifunctional

16、 groups shall collaborate during each phase of the program, perceive and mutually understand specific goals and objectives, and define and develop the system/product reliability requirements using a number of industry tools such as Quality Function Deployment (QFD). Customer-User Communication: The

17、customer community must collaborate with the users to define the desired capabilities for a system/product. This capability definition includes design reliability and operational reliability in the smallest logistics footprint. The logistics footprint is a function of system/products embedded diagno

18、stics and the customers system/product support plan (spares, maintenance, training, and technical manuals). Customer-Developer Communication: The customer must communicate the users desired reliability and performance requirements for the system/product to the developer. The developers engineering o

19、rganizations must analyze the requirements and establish a dialogue with the customer so that the developer can complete a detailed requirements analysis to ensure that the requirements are understood and feasible. The developer shall communicate the acceptance of the requirements or recommend an al

20、ternative to the customer. This communication is necessary to ensure eventual system/product suitability. These communications between the developer and customer should be documented. User/Customer-Developer Communication: The system/product reliability feasibility assessment (i.e., the assessment o

21、f the feasibility of achieving the user/customer requirements) shall be completed to the same level as the customers specification to the developer. System/product engineering and reliability engineering functions shall be responsible for implementing and executing the design-for-reliability methodo

22、logy over the system/products life cycle. The customer will ensure that sufficient funding is available for the developer to provide a system/product that meets requirements when operated and maintained by the user over the system/products life cycle. The goal is to apply the optimum funding profile

23、 for design, development, verification, and deployment at the appropriate time. 4.4 Supporting Information (Normative) The information listed under Input Information is required in order to enable the developer to design, produce, and deliver a system/product that meets requirements and is suitable

24、to the end user. This information may be provided by the customer or may be jointly developed by the customer/user and developer. 4.4.1 Input Information (Normative) The following information is required before a reliable system/product can be designed: Quantitative reliability requirements and rati

25、onale for the system/product. Cost and schedule requirements and funding profile. Known failure modes and mechanisms, if any. Failure Definition and Scoring Criteria, if customer supplied. 13 Copyright Government Electronics & Information Technology Association Provided by IHS under license with GEI

26、A Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-GEIA-STD-0009 User and environmental profile that defines the system/products life cycle (operating and non-operating environments (including storage), expected operating and non-operating times, etc.). For example,

27、 miles traveled, percent terrain type, hours of operation, rounds fired, etc. Other documentation such as performance requirements and specifications, system/product engineering plans, system/product test plans, documentation on operational concepts, maintenance concepts, and logistics support. Rati

28、onale for the reliability requirements should include, as applicable, 1. requirements for availability, maintainability, testability, durability, and system health fined as embedded diagnostics, Built-In Test (BIT), and prognostics), 2. customer/user design constraints (e.g., technology, manpower, t

29、raining, and logistics port), 3. desired maintenance concepts, 4. reliability estimates, support concept, and limitations for similar systems/products, and 5. data on how the system/product will be packaged, handled, shipped, and transported. 4.4.2 Developed Information (Normative) During the course

30、 of designing reliability into a system/product, a considerable amount of information will be developed. In many cases, input information to this objective will be expanded on and updated. The activities in Section 4.5.1 will result in the developer generating this information. The information devel

31、oped shall include: Reliability Program Plan that spans the system/product life cycle and includes, as a minimum, the activities specified in Section 4.5.1, as well as the framework for the Reliability Case and the initial reliability cost, schedule and staffing plan. Conceptual reliability model fo

32、r the system/product and allocations derived from the customers top level requirements to the major subsystems. Initial reliability flow-down requirements to the major subsystem level. Failure definitions and criteria that are integrated with the developers Closed-Loop Failure-Mode Mitigation Proces

33、s. Initial reliability assessment showing that the customers design constraints are understood and the reliability requirements are feasible. Candidate reliability trade studies for available technology or needed technology development to mitigate development and associated risks. Agreed-to definiti

34、ons for new design, Non-Developmental Items (NDI), modified NDI, Customer-Furnished Items (CFI), and Commercial-Off-The-Shelf (COTS) hardware/software. Reliability Requirements Verification Strategy/Plan including a traceability and verification matrix connecting the customers requirements to develo

35、pers requirements. System/product-level user and environmental profile. 4.5 Activities, Methods, and Tools This section is divided into two parts. The first part specifies the normative activities that the developer shall perform. The second part is informative in nature and lists methods and tools

36、that the developer may consider to effectively support the normative activities. 14 Copyright Government Electronics & Information Technology Association Provided by IHS under license with GEIA Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-GEIA-STD-0009 All activ

37、ities, methods and tools used should be evaluated and applied in a manner that adds demonstrated value to the program, at an optimized life cycle cost and utilization of resources, in support of the stated mission and goals of this Objective. 4.5.1 Activities (Normative) 4.5.1.1 Reliability Program

38、Plan (RPP) The developer shall develop a program for designing, manufacturing, and sustaining reliable systems/products. The RPP shall be tailored to each system/product. A RPP should ideally be developed both by the developer (delineating those activities required to meet customer reliability requi

39、rements) and the customer (who provides an expansion of the required activities to include the tasks and customer-supplied resources to support and confirm the attainment of reliability requirements). The developer may identify and include additional activities not identified herein. The RPP is init

40、ially prepared early in the program and is periodically updated and coordinated with the customer. The RPP shall: Plan for the attainment of customer reliability requirements. Provide visibility into the management and organizational structure of those responsible and accountable (both developer and

41、 customer) for the conduct of reliability activities over the entire life cycle. Define all resources (e.g., personnel, funding, tools, and facilities) required to fully implement the reliability program. Include a coordinated schedule for conducting all reliability activities throughout the system/

42、product life-cycle. Include detailed descriptions of all reliability activities, functions, documentation, processes, and strategies required to ensure system/product reliability maturation and management throughout the system/product life cycle. Document the procedures for verifying that planned ac

43、tivities are implemented and for both reviewing and comparing their status and outcomes. Manage potential reliability risks due, for example, to new technologies or testing approaches. Ensure that reliability allocations, monitoring provisions, and inputs that impact reliability (e.g., user and envi

44、ronmental loads) are flowed down to subcontractors and suppliers. Include contingency-planning criteria and decision-making for altering plans and intensifying reliability improvement efforts. Include, at minimum, the normative activities identified throughout this standard. Include, when applicable

45、, additional customer-specified normative activities. The RPP shall address the implementation of all the normative activities identified in Objectives 1 - 4: System/Product Reliability Model and Requirements: Describe 1. the methods and tools that will be used to build and refine the system/product

46、 reliability model and requirements, 2. the extent to which detailed component stress and damage models will be incorporated in the system/product reliability model, 15 Copyright Government Electronics & Information Technology Association Provided by IHS under license with GEIA Not for ResaleNo repr

47、oduction or networking permitted without license from IHS-,-,-GEIA-STD-0009 3. how the system/product reliability model and requirements will be updated as the system/product design evolves and as failure modes are identified during the analysis of test and field failures, and 4. how the system/prod

48、uct reliability model and requirements will be used to identify reliability-critical items. Engineering Process: Describe 1. how it will be ensured that the normative reliability activities are an integral part of the systems-engineering process, 2. how reliability-improvement actions will routinely

49、 be incorporated into the design and manufacture of the system/product, 3. how it will be ensured that design rules that impact reliability, including parts, materials, process review, selection, and control, parts stress derating, electrical, mechanical, thermal and other guidelines, are adhered to, 4. how reliabil