SAE - GEIA-STD-0009
(R) Reliability Program Standard for Systems Design, Development, and Manufacturing
|Publication Date:||1 May 2020|
This standard requires the developers and customer/users working as a team to plan and implement a reliability program that provides systems/products that satisfy the user's requirements and expectations. The user's requirements and needs are expressed in the form of the following four reliability objectives:
• The developer shall solicit, investigate, analyze, understand and agree to the user's requirements and product needs. The developer, working with the customer and user, shall include the activities necessary to ensure that the user's requirements and product needs are fully understood and defined, so that a comprehensive design specification and Reliability Program Plan can be generated.
• The developer shall use well-defined reliability- and systems-engineering processes to develop, design, and verify that the system/product meets the user's documented reliability requirements and needs. The developer shall implement a set of engineering activities (included in this standard as normative activities and informative activities, refer to Section 3) so that the resulting system/product satisfies the customer's documented requirements and needs.
• The multifunctional team shall verify during production that the developer has met the user's reliability requirements and needs prior to fielding. The developer shall include activities that assure the customer that the reliability requirements and product needs have been satisfied.
• The multifunctional team shall monitor and assess the reliability of the system/product in the field. The team is responsible for identifying the data elements to assess the reliability of the system/product in the field and to ensure the data collected are accurate and complete. The team will establish a closed-loop feedback method to flow recommended improvements (corrective actions) for monitoring reliability growth.
This standard defines a systematic approach to engineering or reengineering a system/product, incorporating best practices that have evolved considerably in recent years. The systematic approach of this standard is applicable for:
• Completing corrective actions,
• Making refinements,
• Developing derivatives,
• Producing modifications,
• Updating existing products,
• Creating and realizing new systems,
• Allowing for the safe and cost-effective disposal (retirement) of a system/product.
This approach is incrementally applied in an engineering life cycle framework that can be implemented during any one or more phases of an enterprise-based life cycle (for example, during production, operations, support, or disposal). The defined approach has two premises:
• A system/product is an item that may consist of hardware, software, firmware, facilities, data, materials, personnel, services, techniques, and processes.
• The engineering of a system/product is accomplished by applying a set of processes to each element of its hierarchy by a multifunctional team of people who have the requisite knowledge and skills.
Reliability Program Plan and Reliability Case
This standard requires customers and developers operating as a multifunctional team to cooperatively define, document and integrate their reliability processes to ensure systems/products are developed and manufactured to be highly reliable and sustainable over their life cycle. The Reliability Program Plan and Reliability Case are integral to this process. At the beginning of a new development or major modification program, the development team in conjunction with the user, should employ a continuous assessment process to define and document the capability and limitations imposed by the level of reliability, maintainability, system health, and availability with an emphasis on the operational impacts. Whereas the Reliability Program Plan takes a forward view by describing the activities together with any applicable success criterion that are to be undertaken to demonstrate that the Reliability requirements objectives have been achieved, the Reliability Case provides a retrospective view. The Reliability Case provides the record (evidence) of how well the requirements have been demonstrated at each program phase and provides the evidence that the developer achieved the reliability requirements.
The evidence is typically a sequence of reports that demonstrate the developer's actions and analyses to achieve the reliability requirements. A well-documented Reliability Case will greatly benefit any acquisition process, but the retrospective view (as compared to the forward view of the Reliability Program Plan) has historically allowed it to be neglected if the acquisition program has been successful at achieving the reliability requirements defined in the Reliability Rationale. If the reliability requirements are not clearly achieved, the benefits of the Reliability Case increase immensely as the Reliability Case documents the steps that were taken to meet Reliability requirements. The Reliability Case evolves from the direction of the customer and the developer as the project matures. Initially the customer is the acquisition organization; eventually, it is the user.
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 customer's funding profile, developer's internal policies and procedures, and negotiations between the customer and developer.
Structure of Objectives
Each of the four reliability objectives described herein is structured as follows:
• Mission and Goals
• People and Organizations
• Supporting Information (Normative)
• Input Information (Normative)
• Developed Information (Normative)
• Activities, Methods, and Tools
• Activities (Normative)
• Methods and Tools (Informative)
• Output and Documentation (Normative)
The Introduction briefly introduces the objective. The subsection, Mission and Goals, provides additional background and context that are needed so one can develop a clear understanding of this objective. It is followed by a People and Organizations subsection which introduces considerations of personnel and organization that must be addressed when designing reliability into a product. The Supporting Information subsection contains two parts. The first part, Input Information, lists essential input information that is needed in order to accomplish this design-for-reliabili
Development and Flow of Information Between Objectives