UNLIMITED FREE ACCESS TO THE WORLD'S BEST IDEAS

close
Already an Engineering360 user? Log in.

This is embarrasing...

An error occurred while processing the form. Please try again in a few minutes.

Customize Your Engineering360 Experience

close
Privacy Policy

This is embarrasing...

An error occurred while processing the form. Please try again in a few minutes.

SAE - GEIA-STD-0009

(R) Reliability Program Standard for Systems Design, Development, and Manufacturing

active, Most Current
Buy Now
Organization: SAE
Publication Date: 1 May 2020
Status: active
Page Count: 51
scope:

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.

Approach

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.

Tailoring

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.

Organization

Structure of Objectives

Each of the four reliability objectives described herein is structured as follows:

• Introduction

• 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-reliability objective. The second part, Developed Information, lists the information that is developed during the accomplishment of this objective. As shown in Figures 1 thru 5, the input information feeds the processes and methods contained in Activities, Methods, and Tools. Application of these processes and methods should result in a reliable product. Activities, Methods, and Tools contains two parts, a normative (mandatory) set of activities and an informative set of methods and tools that are provided for guidance information only. The developed information that is ultimately provided to other objectives in this standard is listed under Outputs and Documentation.

Development and Flow of Information Between Objectives

Document History

GEIA-STD-0009
May 1, 2020
(R) Reliability Program Standard for Systems Design, Development, and Manufacturing
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...
August 1, 2008
Reliability Program Standard for Systems Design, Development, and Manufacturing
A description is not available for this item.

References

Advertisement