IEEE TRANSACTIONS ON RELIABILITY, VOL. 39, NO. 2, 1990 JUNE 133

Guidelines for Integrating RAM Considerations into an Engineering Project

Vernon H. Guthrie

John A. Farquharson

Robert W. Bonnett

E. F. Bjoro Jr.

JBF Associates Inc., Knoxville

JBF Associates Inc., Knoxville

US Department of Energy, Oak Ridge

US Department of Energy, Germantown

Key Words - Availability, Maintainability, RAM task, RAM tool

Reader Aids - Purpose: Tutorial Special math needed for explanations: None at all! Special math needed to use results: None at all! Results useful to: Planners, managers, design engineers, RAM

engineers

Summary & Conclusions - These reliability, availability, main- tainability (RAM) program guidelines were developed by the US Department of Energy RAM working group. These guidelines pre- sent a structured RAM process for integrating RAM considera- tions in each of six defined project phases: 1) Feasibility study, 2) conceptual and preliminary design, 3) detailed design, 4) procure- ment, 5) startup, and 6) operations. This structured RAM process is initially described using a flowchart identifying the primary tasks and decisions within the process. A RAM program, based on these guidelines, applies this structured RAM process in each project phase.

After the flowchart that identifies the primary tasks and deci- sions within the RAM process is introduced, a general discussion presents the activities required to perform the tasks in the RAM process and the tools that can be used in those tasks. Finally, a matrix shows the specific activities and associated tools that are generally most useful for performing a particular task during a particular project phase. The guidelines apply to any engineered system, and provide a structured approach for designing and im- plementing an effective RAM program throughout a project.

Applying this RAM process to all project phases will help en- sure that the project has a cohesive and cost-effective RAM pro- gram; ie, the RAM program will be directed toward ensuring that the project goals will be met and that RAM-related information needed for project decisions will be provided in a timely manner.

that could prevent the accomplishment of health, safety, en- vironmental, performance, schedule, and economic goals.

To be effective, a RAM program must address the RAM process, as defined below, for each phase of the project. This paper introduces:

The RAM-related tasks and decisions that constitute the RAM process throughout all phases of a project The activities required to perform these tasks The tools that can be used to facilitate performance of these activities.

Relating overall project goals to specific RAM re- quirements is very difficult. Historically, this difficulty has often resulted in establishing RAM requirements with little or no rela- tion to project goals. As the project goals were refined, these RAM requirements lost meaning and became divorced from the development of the project hardware. These circumstances, combined with the ever increasing fiscal and schedule demands placed on project managers, resulted in excessive compromise and the eventual obscurity of RAM requirements.

To be meaningful, RAM requirements should be establish- ed during the initial design phases of a project. These re- quirements must be consistent with the explicit project goals, and project management must be aware of the feasibility of meeting, and the implications of failing to meet, these re- quirements. For example, RAM requirements that stretch the state of the art can be established with the full knowledge of project management. If so, project management must direct suf- ficient effort and funding toward achieving these requirements.

The requirements for a RAM program vary appreciably from project to project. Therefore, the following sections do not dictate how the RAM tasks must be accomplished; rather, they describe the activities and the tools that should be useful in developing effective RAM programs for a variety of projects.

The scope of each RAM program must be adjusted to meet the needs of the project. In general, the scope of a RAM pro- gram is closely tied to the importance of the benefits and the potential difficulties associated with the project and the frac- tion of the project design that is new technology. The challenge is to ensure that the RAM information is adequate for decision making, and that this information is provided in a cost-effective and timely manner.

1. INTRODUCTION 2. OVERVIEW OF THE RAM PROCESS

A reliability, availability, and maintainability (RAM) pro- gram [ 1-51 should be established as part of a project’s system engineering program. Establishing a RAM program will help ensure that the project will be free from RAM-related problems

The RAM process is the act of performing several inter- related RAM tasks during each project phase. The three primary RAM tasks are:

001 8-9529/90/0600-0 133$01.00O1990 IEEE

134 IEEE TRANSACTIONS ON RELIABILITY, VOL. 39, NO. 2, 1990 JUNE

1. Establish RAM requirements. 2. Provide input to the design process and to operations. 3. Monitor RAM achievement.

Figure 1 is a simplified flowchart of the primary RAM tasks (in rectangles) and decisions (in diamonds) that form the RAM process for any project phase. While the specific objectives of the three RAM tasks will change as the project phases change, the RAM process in figure 1 applies to all project phases.

PROJECT GOALS (=___> ESlA’JLISI1 RAM REOUIREMEN TS

-7 PROVIDE INPUT TO THE DESIGN PROCESS

AND IO OPERATIONS

MONITOR RAM ACIIIEMMENT

1 NO

€ STAn1.lSt IFl) IIFOUII?CMF N TS

Figure 1. Simplified Flowchart of the RAM Process.

Accomplishing these RAM tasks requires some of the following RAM activities:

Management Modeling and analysis Testing Data collection and analysis System design and logistics

Table 1 lists several effective RAM-related tools for each RAM activity. These tools have historically been and are an- ticipated to be the most useful in conducting the RAM activities necessary for the three primary RAM tasks. Ref [l] briefly describes each tool, its applicability, and sources of informa- tion about it. To help ensure that the RAM program is proper-

ly focused and that the results of the RAM tasks are accurate, two management tasks must be performed in all project phases:

Develop, maintain, and implement a RAM program plan. Establish and maintain a RAM review process.

Table 1 RAM Activities and Tools

Management

RAM Program Plan RAM Review Process

Modeling and Analysis

Block Diagram Analysis Failure Mode, Effects, and Criticality Analysis Fault-Tree Analysis Markov Analysis Event-Tree Analysis Cause-Consequence Analysis Maintenance-Engineering Analysis Life-Cycle Cost Analysis Sneak-Circuit Analysis Tolerance Analysis Part-Count Analysis Growth Analysis

Testing

RAM Test Plan Test, Analyze, and Fix Process (Growth Testing) Environmental Stress Screening Reliability Qualification Testing Production Reliability Acceptance Testing

Data Collection and Analysis

Generic Data Development Failure Reporting, Analysis, and Corrective Action System

System Design and Logistics

Redundancy and Diversity Modularity and Diagnostics Reliability vs Maintainability Tradeoff Studies Part Control Program Part Derating RAM Procurement Specifications

’ Preventive Maintenance Program Corrective Maintenance Program Spare-Part Program

The project manager should develop the RAM program plan at the beginning of the project. This plan should initially contain the scope of the RAM program required to complete the project. The plan should then be updated in each project phase to include detail sufficient for managing that phase. Specifically, the RAM program plan should address:

The RAM tasks to be performed in each project phase. The schedule for providing results to the design review

How the results of these tasks will be used to make project process.

decisions.

GUTHRIE ET AL.: GUIDELINES FOR INTEGRATING RAM CONSIDERATIONS INTO AN ENGINEERING PROJECT 135

The activities and tools required to accomplish efficiently the

The funding to complete the process. Any of the three primary RAM tasks that do not apply in a

RAM tasks.

particular project phase, and the reasons why.

The RAM reviews should be conducted by RAM experts who are independent of the project team. The first responsibility of the experts is to review the RAM plan. Additional respon- sibilities include verifying the validity of the results of each RAM task.

Sections 3-5 briefly discuss each of the three primary RAM tasks in the RAM process.

3. ESTABLISH RAM REQUIREMENTS

This task can be qualitative, quantitative, or both, depend- ing on the project. Once established, the RAM requirements should be used as another of the project design parameters.

The primary benefit of a qualitative approach is that the designers are provided with simple and systematic guidelines for meeting the project RAM requirements. The primary disad- vantage of a qualitative approach is that a qualitative require- ment, like “all systems must have redundant and diverse sub- systems’’, will almost certainly result in many portions of the project being over-designed.

The primary benefits of a quantitative approach for establishing RAM requirements are:

The health, safety, environmental, performance, and economic goals of the project are clearly defined. Specific RAM targets are provided for design activities and cost-benefit studies, thus minimizing the problem and expense of over-designing or under-designing . Quantitative evidence can be provided that the RAM re- quirements, and thus the project goals, will be met.

The primary disadvantages of a quantitative approach are:

The RAM tools are relatively complex compared to the qualita- tive approach, thus increasing the cost of the RAM program. If the RAM program plan is not well-conceived and im- plemented, the RAM program will simply be a numbers game with no useful feedback for design decisions.

The task can be subdivided into three subtasks that are discussed in the following subsections:

1. Identify the project functions 2. Translate project goals into RAM requirements for each

project function 3. Translate RAM requirements for each project function

into RAM requirements for successively more detailed design elements.

3.1 Identify the Project Functions

The objective is to document the various functions (eg, pro- vide a product at a certain rate, or contain a toxic substance)

whose performance or accomplishment is essential to achiev- ing the goals of the project. It is the responsibility of the pro- ject manager and designers to ensure that the functions of the project are well-established and communicated. However, those conducting the Modeling and Analysis activity should work closely with the designers and the project manager to ensure that:

All project functions are documented well enough to be

The documentation is accurate. translated into RAM requirements.

In general, a RAM program must focus on the functions, or specific tasks and missions, of design elements (systems, sub- systems, etc.) instead of on the design elements themselves. This is because a particular design element can perform several func- tions and the consequence of the failure of one function is like- ly to be quite different from the consequence of the failure of another function. For example, failure of a temperature con- trol system to keep a tank adequately heated could result in a small loss of process efficiency while failure of the system to keep the tank adequately cooled could result in an explosion. If the consequences of the failures of various functions are dif- ferent, then, to ensure that the project goals are met, the RAM requirements for the various functions must also be different. Therefore, when the project goals are initially translated into RAM requirements, the focus is first on establishing RAM re- quirements for each project function and then on translating these requirements to the systems designed to accomplish these functions.

3.2 Translate Project Goals into RAM Requirements for Each Project Function

This task defines RAM program objectives. In general, project goals are expressed as -

A production requirement, such as the amount of product to be produced over a given operating period or over the life of the project, and/or Accident avoidance goals, such as acceptable limits for the health, safety, environmental, and economic consequences associated with the project from its conception to its decommissioning.

Production requirement goals are generally based on economic factors alone. Accident avoidance goals are based on economic considerations; industry standards; Federal Govern- ment regulations, including those mandated by the Department of Energy, the Nuclear Regulatory Commission, the En- vironmental Protection Agency, and the Occupational Safety and Health Agency; and state government regulations.

Project goals addressing production requirements are almost always expressed quantitatively, eg. 100 OOO widgets must be produced each year for 25 years. Each of these project goals is then almost always translated into an availability re- quirement for each production function.

Project goals addressing acceptable limits for health, safe- ty, environmental, and economic consequences can be expressed qualitatively or quantitatively. Project goals addressing acceptable

136 IEEE TRANSACTIONS ON RELIABILITY, VOL. 39, NO. 2, 1990 JUNE

limits have historically been qualitatively expressed simply as, “the design must be as good as it can be” or “the design must minimize public risk.” No translating of these qualitative pro- ject goals is required until qualitative RAM requirements need to be established for the lower levels (systems, subsystems, etc.). An example of a qualitative RAM requirement is that the system should have redundant and diverse subsystems.

Quantitative expressions of the project’s accident avoidance goals could include:

A limit on the dollar loss from fires or explosions An allowable toxic release amount A limit or goal for lost-time injuries.

These goals often include a probability requirement. An example is limiting to less than the probability of releas- ing more than a certain amount of a toxic substance to the en- vironment over a facility’s lifetime. In general, when these quan- titative project goals are translated into RAM requirements, the RAM characteristic of interest is the anticipated frequency of the loss of function events.

While not indicated in figure 1, if these requirements cannot be revised satisfactorily, then either the project goals should be revised or the project should be canceled.

This subtask should be repeated until the RAM re- quirements for the project functions are translated to the level of design detail required for procurement. The RAM re- quirements specified for the design elements that are to be pro- cured are usually for reliability and maintainability. A reliability requirement is usually expressed as a mean time-between- failures (MTBF) value, and a maintainability requirement is usually expressed as a mean time-to-restore value.

3.4 Overview

Once the RAM and other project requirements are established, the design should be developed to the desired level of detail. Since the paths to implement the RAM process were discussed in this section, that information is not repeated in sec- tions 4 and 5.

4. PROVIDE INPUT TO THE DESIGN PROCESS 3.3 Translate RAM Requirements for Each Project Function into RAM Requirements for Successively More Detailed Design

AND TO OPERATIONS

Elements

This final task is an iterative process that involves all of the tasks and decisions in figure 1. Once the RAM requirements for the project functions are established, an initial design is developed to the system level (or some other level of detail) to address these RAM and other project requirements (task 2). This design is then evaluated to see if the RAM requirements for the project functions are being met and to identify critical functions and design elements (task 3).

If the design is not complete but the results of the RAM analyses for task 3 show that the RAM requirements are being met, then these task 3 results should be used as the basis for establishing qualitative and quantitative RAM requirements for the project systems (or some other level of detail). For exam- ple, establishing qualitative RAM requirements for the systems, such as which systems must have redundant subsystems and which redundant subsystems must have diverse designs, can be guided by the results of a Fault-Tree Analysis developed in task 3. For the quantitative case, since the predictions for the systems indicate that the RAM requirements for the project functions will be met, the quantitative RAM requirements (eg, availability, mean frequency) for the project functions can be allocated to the systems by simply setting the system RAM requirements equal to the RAM predictions made in task 3.

However, if the results of task 3 indicate the RAM re- quirements for the project functions will not be met, then the manager must decide whether the RAM requirements for the project functions are attainable. If so then the existing design should be revised to fulfill the RAM requirements and the revis- ed design should be re-evaluated to see if it meets the RAM

Once the RAM requirements are established (task l), the RAM program should address them by providing input to the design process and to operations (task 2).

For the design process, this means using a variety of RAM- related design techniques or tools, such as Redundancy and Diversity, Modularity and Diagnostics, and Reliability vs Main- tainability Tradeoff Studies, to help establish a design that meets the qualitative and quantitative RAM requirements.

For operations, this means having programs in place, such as a Spare-Part Program, and a Preventive Maintenance Pro- gram, to help ensure that the required equipment reliability and maintainability are achieved.

5. MONITOR RAM ACHIEVEMENT

Once a design has been developed to meet RAM and other project requirements (task 2), the RAM program should evaluate the design to provide qualitative and quantitative evidence of its RAM status (task 3). This evidence should be used to:

Decide if RAM requirements are being met or, if not being

Identify critical functions and design elements that need

Make specific recommendations for design improvements.

Providing evidence of the RAM status of the design begins by developing a logic model that addresses each available design level. This logic model can then be used to:

met, if they are attainable.

special attention.

requirements. This process should be repeated until the evalua- tion indicates that the RAM requirements can be met.

If the RAM requirements, such as those established at the system level, are not attainable, then they should be revised.

Identify failure modes that have not been anticipated or ad-

Verify that qualitative RAM requirements have been met, eg, dressed by the designers.

no potential single-point failures exist.

137 GUTHRIE ET AL.: GUIDELINES FOR INTEGRATING RAM CONSIDERATIONS INTO AN ENGINEERING PROJECT

Predict RAM using available data, such as generic, test, or

Identify the critical functions and design elements.

A function or a design element can be identified as critical based on its importance [6] . There are several measures of im- portunce [7, 81 and many are commonly used in the RAM pro-

cess. The appropriate measure depends on the specific decisions that need to be made.

A function or design element can be identified as critical if it cannot be shown (qualitatively or quantitatively) that the associated RAM requirements will be met with sufficient cer- tainty. The following are the primary reasons for a lack of

operating data.

Ihk

I’sLiblish RAM Rquircir icnb

Idciirily !lie pro- ject’s functions

’Itandale project goals inln K A M reqiiircmcnts for each projcct [unction

’Ihinslalc R A M reqiiirenicnts for cacli project lunclion inlo RAM rcqiiircmcnls lor succcssivcly iiiorc ilctailed di.sign clclllcllls

Monitor ItAM k l i imcnicnt

M&A Noned

M&A Frnjcct-lcvel FMECA Evcnl lrec analysis Cause-cnnsc- qiiencc analysis Life q r l c cost analr is

Not a p p l i c a t d

Not applicabled

M&A I’rojcct-lcvcl FMEW

* Event trcc annlysis C;iusc-cirnsc- qucncc nnalysis

DC&A Generic ilnlii drvclnpinciil

M A n Illock diagram

Fai i ’ l tree iinnlpis hlnrknv analysis 1WIX:A FMI iA L7vcnt lrcc .inalysis Ciiusc-cniiscqucncc analysis M;iinlcn;ince rngiiiccring analysis

analysis

S I ) L I , Rcdunilnncy and divcni ly Mndril.irity and dingnnrticr l<cli;ibiIily vs. mi i n 1 :i i nn lhi I i l y Ir;idc-oll studies

Same” Samc”

S I M L I t A M [ i r ~ ~ i i r c m c n l spccificnlions

As applicableC AS applicablec

As applicablec

sDaL I’rcvcntivc maintenance prnfirani Corrrclivc niaiiilcnaiicc prngrnm Spnrc parts program

Sarncb

M M Same” I3lcrk diagram n na lysis I‘aull lrcc niinlysir Markov analysis I:MI:C:A I:MItA I k n l lice nn:ilysis . (‘sllrc c(’II.;c- qi i~i icc niiiilysis M n i n I cn:i ncc rii,yiiwriiig Irllnl!.\ls GI-mvrlr tin;iIpis

I K R A IXACAS

:p rvlIll;li tmds arc a\ail:it>lc lor tliis iiisk.

Cldc:~l~y, this task will not nccd IO IK. pcrrnrincd for IIIIS pmjccl p~iasc. i lowwcr, i f ds ig i i changcs arc nccdcd, ilie tools specificd in colunins to I~IC

Iclt lor this lask can nlsn Ix. useful in liiir project pliasc. dNormally not applic?blc for this m k . c ~ d c a ~ ~ y , IIIC IWX,IS slxcriicd 811 C ~ I I I ~ ~ ? in IIX lcfl wilt not IX. nccclc<I in tliiq project plinrc. I Imvcvcr, i f dcrign c1i;ingc.q itrc nccdcd, llic Icwk

r l lc R A M ilclivilics and lcnils ~(x-ci l icd iii l l ic coliimii in IIic lc l i for this !ask can also IF usrlul in t h i s prnjrct phnsc.

specilicd in coluiiins 10 the lctt lor this cask can also 1% useful in this projccl pliase.

Irgcnd: M&A - Mcxlcling awl Analpis IX&A - Ihta C:ollcdioo and halysis SDGrL - Sptems Dcsigu and Ingistis ’r - I ts t ing

138 IEEE TRANSACTIONS ON RELIABILITY, VOL. 39, NO. 2, 1990 JUNE

sufficient certainty in meeting the RAM requirements of a func- tion, or a design element:

design detail, the accuracy required for decision making dur- ing the initial design stages often is also relatively low. As the design becomes more detailed, relevant generic data can be us- ed to predict more accurately. Finally, as sufficient testing and operating data become available, the certainty that the predic- tions are accurate will appreciably increase.

* The design is not developed to sufficient detail for an ade-

The design contains first-of-a-kind elements. RAM growth is required to achieve the RAM requirements.

quate prediction.

The design is inadequate.

6. THE RAM PROGRAM FOR EACH PROJECT PHASE Identifying the critical functions and associated design elements at a particular level of design detail provides impor-

The specific activities to accomplish a RAM task and the tools that facilitate the performance of the activities vary as the objectives of a task change from phase to phase. Ref [l] ad- dresses the objectives of each task in each project phase.

Table 2 shows typical activities/tools that have proved useful in performing each task, and introduces several generic project-phases :

Feasibility Study. A top-level evaluation of the likelihood that

Conceptual & Preliminary Design. Establishing one or more

tant feedback for establishing the RAM requirements (task 1). The established RAM requirements are then useful in focusing the design effort (task 2).

The point in the design process at which a prediction should be made varies from project to project. Two important factors are:

The availability of relevant data. The accuracy required for decision making.

While certainty in the predictions made during the initial design stages should be relatively low because of the lack of

a proposed project can succeed.

Table 3 Exarple of A l l o c a t i n g t h e R131 Prcgran wt t o R N A c t i v i t i e s by Task a d Pro jec t Phasea

Pro jec t Phase

RN4 P r o g r a Task

~ -~ e m e p t u a l and Pre-

lull P r o g r a F e a s i b i l i t y L i a i m r y De ta i l ed Stdatast s w Design Desig, Procurement S t a r t r p Cperatiorr9 TOTAL

Provide RAM Management

Es tab l i sh RAM Requirements

Provide input t o the Design Process and t o Operations

Monitor RAM Achievement

Develop and maintain a RAM p l a n

Es tab l i sh and maintain a RAM review and approval cyc le

0.4

2

I d e n t i f y the p ro jec t ' s 0.5 ( M U ) f unc t i ons

T rans la te p ro jec t goals i n t o RAM requirements f o r each p r o j e c t f unc t i on

T rans la te RAM requirements f o r each p r o j e c t f unc t i on i n t o RAM requirements f o r successively more d e t a i l e d design elements

1.5 (MU)

1.4 (MU) - 0.5 ( D C U )

b

0.8 0 . 4 0.2 0.1 0.1 2

2 4.6 1 0.2 0.2 10

0.3 ( M U ) 0.2 ( M U ) - 1

3 1.1 (MU) 0 .4 (MU) -

2 (MU) 3 (MU) 1 (Mu) 0.5 ( M U ) 0.5 (MU) 7

aThe M g e t values in t h i s t a b l e represent the percentage of the t o t a l M g e t f o r the RAM program o f a p ro jec t .

Legend:

W - Modeling and Ana lys i s DULA - Data C o l l e c t i o n and Analysis SOCL - Sys tem Design and L o g i s t i c s

T - T e s t i n g

GUTHRIE ET AL.: GUIDELINES FOR INTEGRATING RAM CONSIDERATIONS INTO AN ENGINEERING PROJECT 139

designs to accomplish the project goals and selecting a par- ticular design alternative for refinement in the detailed design phase. Detailed Design. Specifying the design in sufficient detail that the project design elements can be procured. Procurement. Purchasing of all of the equipment required for the project, Startup. Evaluation and/or modification of all aspects of the project to ensure that it can proceed to the operations phase. Operations. The operational life of the project. The design might have to be modified to eliminate problems that went undetected or unaddressed in the previous phases.

The construction phase is not explicitly addressed since little activity is required from the RAM program during this phase. However, design changes can occur and test data can be generated in this phase. Thus, the RAM activities identified as useful in the detailed design, procurement, and startup phases should be used when applicable in the construction phase.

The decommissioning phase is not explicitly addressed because RAM normally does not play a role in project decom- missioning. However, in some instances the decommissioning phase develops into a project, such as the decommissioning of a nuclear waste facility. This type of project can have economic, safety, and environmental goals whose achievement should be monitored by a RAM program. For these decommissioning phase projects, appropriate portions of the RAM process should be implemented as a continuation of the RAM program.

7. RAM PROGRAM BUDGET

REFERENCES

[I] V. H. Guthrie, J. A. Farquharson, D. J. Campbell, Reliability, Avuilubili- ty and Maintainability ( R A M ) Guidelines, JBFA-102R-88, 1988 Mar, JBF Associates Inc., Knoxville, TN USA.

[2] USAF-R&M Zoo0 Process, US Department of Defense, 1987 October. [3] Transition from Development to Production . . . Solving the Risk Equation,

DoD 4245.7-M, US Department of Defense, 1985 Sep, pp 49-50. [4] A. A. Lakner, R. T. Anderson, Reliability Engineering for Nuclear and

Other High Technology Systems, 1985, pp 131-133, Elsevier Applied Science Publishers.

[5] N. J. McCormick, ReliabiliryandRiskAnalysis, 1981, pp91-116, Academic Press.

[6] H. E. Lambert, “Measures of importance of events”, in Reliability and Fault Tree Analysis, Barlow, Fussell, Singpurwalla (Eds), 1975, pp 77-100; SIAM Press.

[7] D. J. Campbell et alii, Risk Assessment Application to NRC Inspection, Progress Report for 1985 January to 1986 January, NUREGICR-4560, ORNLITM-10001, 1986 Jun; Nuclear Regulatory Commission, Washington, DC USA.

[8] W. E. Vesely, et alii, Measures of Risk Importance and Their Application, NUREGICR-3385, 1983 Jul; Nuclear Regulatory Commission, Washington, USA.

AUTHORS

Vernon H. Guthrie; JBF Associates Inc.; Technology Drive; loo0 Technology Park Center; Knoxville, Tennessee 37932-3341 USA.

V. H. Guthrie is an Engineering Supervisor with JBF Associates Inc., a system reliability and risk assessment consulting firm. He received his BS in Nuclear Engineering (1977) from Mississippi State University. He received his MS in Nuclear Engineering (1979) from the University of Tennessee, where his Master’s program focused on system reliability and risk assessment.

essential part of planning a successful RAM program John A. Farquharson; JBF Associates Inc.; Technology Drive; Park Center; Knoxville, Tennessee 37932-3341 USA.

J. A. Faquharson is a Systems Engineer with JBF Associates Inc., a system reliability and risk assessment consulting firm. He has a BS in Mechanical Engineering (1980) and a Master of Business Administration (1986), both from the University of Tennessee. He is a registered professional engineer in the state of Tennessee.

Technology

is the planning Of its budget. The budget

Address the funding for each subtask and associated activity

Be established in the feasibility study phase. Be updated in each subsequent project phase.

in each project phase.

Establishing this detailed budget and including it in the Robert W. Bonnett; US Dept. of Energy; POBOX E; Oak Ridge, Tennessee 37831 USA.

R. W. Bonnett is a Quality Assurance Engineer with the US Department RAM plan helps to ensure that:

The scope of each task/subtask in each project phase is of Energy. He previously worked for the US Department of the Army; a ma- jor automotive manufacturer; and a major telecommunication operating, manufacturing, and research company. He has a BEE (1964) from Auburn

carefully considered.

phases. * The RAM program is staffed Over project University and an ME (1972) from Texas A&M University,

Table 3 iS an example RAM program budget. Except for the first two rows, the values are followed by an abbreviation designating the budget allotments in the first two rows are assigned to Management. The provide a general idea of the level of funding re- quired and should be based on the specific needs of the project. The Values for Testing reflect only the costs of developing the test plans, not performing the tests.

A table like table 3 should reflect the specific needs of the project, and be included in the project RAM plan. Omitting the Manuscript TR88-195 received 1988 November 12; revised 1989 November 27. planning represented by this table will seriously jeopardize the plan’s usefulness. IEEE Log Number 339 11 r T R F

E. F. Bjoro Jr.; MS EH-32; US Dept. of Energy; 19901 Germantown Road; Germantown, Maryland 20874 USA.

E. F. Bjoro Jr. is a member of the Quality Verification Staff in the DOE Office of Quality Programs. He has almost 30 years of reliability, maintainability, and quality assurance experience and has been with the Department of Energy for the past 18 years. Prior to DOE, he supported the NASA Sky Lab and Space Lab programs as a reliability engineer, and supported major programs for both the Navy and the Air Force. He provides reliability support to the National Institutes of Health for the Left Ventricle Assist Device (artificial heart).

that should receive the funds.