Sometimes customers explicitly define the reliability requirements to the supplier. In other cases, the supplier must first determine if the stated requirements are realistic and achievable and then translate them into design specifications. Often, especially in the case of consumer products, customers do not explicitly specify the reliability requirements. Instead, the suppliers themselves may need to establish the requirements using a variety of techniques. Table 1 summarizes typical scenarios.
Table 1. Customer Reliability Requirement Scenarios (Excerpted from Reference 1)
Customer Requirements
Description of Scenario
Application Guidance
Explicitly Expressed
Customer specification includes requirements for reliability performance as a quantitative measure (i.e., percent reliability, mean time between failure, etc.)
The specified value may need to be adjusted to account for factors that may cause failures beyond supplier control, i.e., translation of user requirements to design goals.
Implicitly Expressed
Specification includes product characteristics that necessitate certain levels of reliability in order to satisfy them (i.e., life cycle cost, support cost, maintenance manpower, and warranty provisions).
The level of reliability necessary to meet other explicitly stated product characteristics should be derived. This process is based on known or hypothesized relationships among characteristics and often involves trade-offs.
Not Expressed
Often the case for commercial products. Supplier must "anticipate" needs and/or position his product in the marketplace. Supplier may or may not have data on similar or competitive products.
Market surveys, Quality Function Deployment, benchmarking, etc., are among approaches that can be used. Data on existing products can help the supplier "position" his reliability objective. Often, this can be a competitive advantage.
Developing reliability requirements for products and systems is a multi-step process as shown in Figure 1. The process entails a number of common tasks as summarized in Table 2. Each step in the process is important in choosing the level of reliability that drives the scope of design oriented tasks necessary to meet customers' needs and expectations. The following sections will discuss how typical reliability tasks relate to effectively accomplishing these steps.
Determine Customer Needs
→
Derive Customer Reliability Requirements
→
Derive Product Level Design Requirements
→
Allocate Product Level Requirements to Lower Levels
Figure 1. Reliability Requirements Development Process
Table 2. Activities Related to the Development of Goals and Requirements
Activity
Tasks and Description
Relevance to Purpose
DESIGN
Environmental Characterization. Determining the operational stresses the product can be expected to experience.
A process to identify the scope and magnitude of the end-use environments to which the product will be exposed throughout its useful life. Used to establish performance-based reliability requirements.
Fault Tolerance. Designing alternate means to continue product operation when components fail.
Consideration of this failure masking technique allows the establishment of higher level reliability product goals, but lowers series reliability potential.
ANALYSIS
Allocations. Translating product level reliability goals and requirements into reliability goals and requirements for the components making up the product.
Used to establish lower assembly level requirements from product level requirements based on complexity, parts counts, etc. Provides an effective means to check reliability requirements for realism.
Dormancy Analysis. Determining the effects of expected periods of storage or other non-operating conditions on the reliability of the product.
Accounts for periods of non-operating or stand-by conditions which the product will experience throughout its useful life, in order to establish and understand special design needs and their impacts on the product.
Durability Assessment. Determining whether or not the mechanical strength of a product will remain adequate for its expected life.
Used to define life limiting aspects of the product. An effective means to strategize for repair policy requirements and plan for upgrading products.
Life Cycle Planning. Determining reliability (and other) requirements by considering the impact over the expected useful life of the product.
A process to set goals for all portions of its life cycle. Considers levels of reliability at each stage and plans for end-of-life. Impacted significantly by repair policies and product durability.
Modeling and Simulation. Creating a representation (model), usually graphical or mathematical, for estimating the expected reliability of a product and validating the selected model through simulation.
An approach to establish meaningful reliability requirements that can be allocated to lower assembly levels. Provides a means to determine degree of appropriate fault tolerance. Provides an understanding of the impact of unit failure on the product.
Predictions. Estimating reliability from available design, analysis, or test data, or data from similar products.
A means to estimate realism of potential hardware and software reliability goals and requirements. Can indicate scope of fault tolerance appropriate for challenging requirement levels.
Thermal Analysis. Analyzing the heat dissipations, transfer paths, and cooling sources to determine if part/product temperatures are consistent with reliability needs.
Analysis to determine the relationship between intended design reliability and the thermal use environment to establish reliability requirements.
Translations. Determining product design goals (i.e., product reliability) from the user's operational requirements for the product.
Models that will translate customer or user performance based requirements into product design reliability goals or requirements.
OTHER
Benchmarking. Comparing a supplier's product and process performance attributes with those of competitors or with the best level of performance achieved by any supplier in a comparable activity.
Can be used to establish competitive position with respect to reliability. Identifies goals necessary to develop discriminated product on the basis of reliability.
Quality Function Deployment (QFD). Capturing the desires of the customer and translating these desires to design requirements and then to tasks needed in the product development effort.
A technique for understanding customer needs that provides a means of defining quantitative reliability goals and tasks to effectively satisfy them.
Market Survey. Determining the needs and wants of potential customers, their probable reaction to potential products, and their level of satisfaction with existing products.
A basic means to identify customer needs and expectations as an input to developing supplier product goals.
Determine Customer's Product Needs
Some customers, such as the general public, do not explicitly "specify" what they need in a product, especially reliability. Customers for other products may be very specific and state a numerical reliability requirement. When customers do not explicitly specify their product reliability needs, suppliers have to determine them using a variety of methods.
Determining customer needs is the basis for deriving operational performance reliability requirements and subsequent design requirements. Without designing to those needs, products will not succeed in the marketplace. Customer needs should be determined early in the Concept/Planning (C/P) phase of a product development program, before large investments of time and resources are made. Customer needs are a prerequisite to deriving performance reliability requirements. Performance reliability requirements, in turn, are the basis for the design requirements, which should be defined before starting any design and development. Several approaches may be used to determining the customer needs.
Market Surveys are frequently used to determine what customers want and need in terms of new or improved products. They address desired features and attributes that range from basic functionality to general appearance. There is no better way to understand the needs of customers than to ask them. Surveys can, however, be subject to bias and sampling error. Wellplanned efforts can minimize these effects.
Usually surveys are performed in the C/P phase but alternative forms of surveys can be used when a prototype product is available. In this case, the customers being surveyed may provide real feedback on likes and dislikes in time to introduce product changes prior to full scale development.
Benchmarking (Reference 2) is a proactive process for comparing an organization's products, services, or processes with those of an organization recognized as "best in class" or which is the strongest competition. The purpose is to implement changes in the product, services, or processes needed to meet or beat the competition. By benchmarking its competition or the best-inclass enables a supplier to better understand the needs of the marketplace and to successfully compete in that marketplace. Note that the best-in-class for a process, such as warehousing, or a service, such as maintenance, may not be a direct competitor.
When applied to a product, benchmarking helps an organization understand the levels of performance, including reliability, which the best-in-class are achieving. Ideally, it is conducted prior to product planning and is initiated in the C/P phase of product development. Often, the organization benchmarking a competitor's product will buy a sample of the product and conduct exhaustive testing. The purpose of the testing is to determine the design characteristics of the product including materials used, design margins and tolerances, design approach, and likely manufacturing and assembly methods. The testing will help to understand the operating characteristics and levels of performance. The organization then must decide whether to attempt to match, surpass, or design to some level slightly below that of the best-in-class product. In the case of the first option, the reliability of the best-in-class product becomes the minimum requirement. The last option might be selected if management determines that a product with nearly as good a level of reliability but with a lower cost is an effective way of growing market share.
Benchmarking is useful not only for developing product-level requirements but also for developing requirements at lower levels of indenture. In addition, it may lead to developing requirements for manufacturing and assembly and other aspects of business management that will improve the overall cost and performance of the product.
Environmental Characterization is used to define the operational and environmental stresses that the product will experience when put into use by the customer. Without an understanding of the stresses to be experienced by a product, the statement of reliability objectives, explicitly or implicitly, is meaningless. For example, a product that could have an MTBF of 500 hours in a consumer household may only experience a 200 hour MTBF in an automobile, due to a more stressful environment. The environment should be defined in gross terms very early in the C/P phase. For additional information on environmental effects upon mechanical design see Reference 3.
At a high level, the environment can be characterized in terms such as ground, mobile, airborne, space, etc. This provides a rough indication of the severity ranges of stresses to be experienced. As the design process starts, more detailed information may be necessary. For more severe environments, it may be appropriate to actually use instrumentation to measure the expected stress levels. For example, Time Stress Measurement Devices are available that can be used to measure and record stresses such as temperature, humidity, shock, vibration and power.
Life Cycle Planning (LCP) addresses the product reliability at every phase of the life cycle. It addresses the various phases in developing a mature product all the way to end-of-life considerations, often including product disposal. It should address specific time periods during the product's useful life including shipping, storage (shelf life) and operation. Products need to be planned and designed to preclude failure due to any period of exposure to stress. LCP addresses all phases of the life cycle and both catastrophic and wearout failures. The C/P phase is the time to establish reliability goals and requirements that address the different stress exposures and characteristics during the product's life cycle.
Any time (e.g., shipping, storage, and operation) a product is subjected to stress, there is the potential for failure. Sometimes the stresses of nonoperating periods can be more detrimental than those during operation. From a mechanical standpoint, a consumer television operates in a benign environment but may need extensive protection for shipping. Many products during storage are susceptible to moisture and, therefore, need to be packed with desiccants. All of these factors need to be considered in planning and developing the appropriate reliability goals and requirements for the product.
Customer's Performance Reliability Requirements
It is necessary to identify or derive the customer's performance reliability requirements from the customer's needs for the product. Needs may be qualitative (e.g., "good reliability"). Reliability requirements may be "hidden" in other needs that are expressed. For example, a need may be stated as availability (a function of both reliability and maintainability), or as a safety concern (no safety critical failures).
Depending on what customer needs are stated, performance reliability requirements can be derived in one of two ways. If the need is already stated as a recognized reliability requirement (e.g., MTBM), no further action is required because the need and the requirement are synonymous. However, when the performance reliability requirement is "hidden," the basic definition of the need must be analyzed to derive any reliability requirements. Ideally, the definition can be described by a relationship, in which reliability is one factor.
A number of reliability-oriented tasks are useful in deriving performance reliability requirements from the needs of customers. These tasks include the following.
Modeling and Simulation is an effective technique to determine a level of reliability, or range of reliability, necessary to meet a more general customer need or requirement. It enables the trade-off of various product characteristics to achieve a more general requirement. Simulation makes use of computer automation to "try" various solutions until an optimized solution is achieved. Modeling and simulation is most beneficial early in the C/P phase. It provides a means of identifying solutions without the costly design, build, and test process. As the product evolves during the Design/Development (D/D) phase, the models should be updated to reflect the current product design configuration.
In developing reliability requirements using mission and support models, the relationships among reliability and the various mission and support figures of merit (FOMs) are defined using mathematical relationships. These FOMs may be the number of spares required for a given scenario, the number of flights that can be generated in a given time period, the average number of products down for service at any one time, etc. By varying the operational measures of reliability, the effect on the FOMs can be determined. Those values of operational reliability which give the "best" results, all other factors being held constant, are then selected as the reliability requirements.
Reliability is just one of many product performance requirements. Depending on the product's functions, many other performance requirements may be imposed. These can include:
range, payload, speed, weight, power output, rate of fire, and maintainability. In addition to functional performance requirements, products may have form, fit, function, and interface (F3I) requirements. These requirements describe how the product must look, its dimensions and shape, and its electrical and mechanical interface.
Ideally, each product requirement would be optimized. But seldom, if ever, is it possible to optimize every requirement. Instead, the overall product must be optimized, with the product's requirements addressed holistically, as a set. That is, the product's requirements must be addressed holistically, as a set. For example, maximizing the number of people (payload) to be carried by a commercial airliner makes it difficult to also maximize the range. These requirements are conflicting. So a "best mix" of range and payload is chosen as a result of trade-off studies. Sometimes, requirements are complementary. For an automobile, maximizing gas mileage is consistent with maximizing range. Whether requirements are conflicting or complementary, they must be viewed as a whole, and not as independent requirements. Reliability requirements should be developed within the context of the overall requirements for the product and program constraints. Since reliability is only one of many, often competing, requirements that are not necessarily equal in importance. The focus must be on the overall product performance. So other performance requirements, and even form and fit requirements, can complement or conflict with the reliability requirements. To reach a "best" compromise, trade-offs are conducted in which an increase in one requirement is traded for a decrease in another. When conflicts arise, reliability might be traded off (i.e., the requirement is reduced) to achieve better performance in another area.
Product Level Design Reliability Requirements
The way in which a customer measures the reliability of a product in use may not be directly meaningful as a design reliability goal or requirement. While some factors are not under the supplier's control, they should be accounted for in establishing the level of design reliability necessary to meet the customer's needs or expectations. Usually, the supplier can anticipate that while many failures affecting reliability performance will be caused by the design, other classes of induced failures will occur during use (including repair and manufacturing). This hierarchy of failure causes can be visualized as segments of a pyramid as shown in Figure 2.
Figure 2. Product Performance Failures (Click to Zoom)
The shape of the "pyramid" can vary with time because each segment is a function of time. It is critical to account for all known failure causes in establishing product design reliability goals. The process of establishing design requirements/goals from needed performance measures is sometimes referred to as "translating" customer (performance) reliability to supplier (design) reliability.
Design reliability requirements, at the product level, should be derived before the start of the D/D phase of a program. Even if they are initially stated as goals, design requirements should be available before designers attempt to implement the product concept developed in the early phases of the program. A number of reliability oriented tasks are helpful in deriving design reliability requirements from performance reliability requirements.
Quality Function Deployment (QFD) (Reference 4) is a tool for translating customer requirements into appropriate design requirements at each stage of design and development. It addresses several steps in the requirement development process using the House of Quality matrix, depicted in Figure 4. QFD provides a means of developing a structured set of customer requirements, thus ensuring that the design features address those attributes. It also provides a means of weighting, or prioritizing the needs. QFD should be applied in the C/P phase.
Figure 4. QFD House of Quality (Click to Zoom)
Briefly, the following steps are used in the QFD approach.
Enter the WHATs already determined, further defining as Primary, Secondary, & Tertiary requirements if necessary.
Determine the HOWs (the design requirements) based on technical experience and knowledge.
Develop HOW-WHAT relationships, assigning a numerical value to each (e.g., a Very Strong relationship might = 5, a Strong relationship = 3, and a Weak relationship = 1). The determination of relationships is based on experience and technical knowledge. To provide an easily understood graphical display, the symbols shown in Figure 5 are used.
Define and assign a customer importance factor for each of the lowest level requirements (Primary, Secondary, or Tertiary) and the degree of technical and cost risk associated with each HOW. Assign numerical values to the factors and degrees of risk (e.g., Greatest = 5, Average = 3, Least = 1).
Develop relationships between the HOWs. Use the same definitions for the strength of the relationship and the corresponding numerical value that was used for the HOWWHAT relationships.
Calculate the relative and absolute weights for the HOWs. For each HOW (DR1, DR2, and DR3), the relationship values in that column are summed. The results are 39, 38, and 30, respectively. Rank ordered, the HOWs are given absolute weights of 1, 2, and 3. Now multiply the sum of each column by its risk yielding the following products: 39, 190, and 90, respectively. So the relative weights are 3, 1, and 2, respectively, for DR1, DR2, and DR3.
Based on the values of the absolute and relative weights, select the key HOWs (i.e., those requiring the most attention). DR2 rates the most attention; DR3 the least.
Figure 5. Typical Excerpt of House of Quality (Click to Zoom)
The right-hand side of the completed House of Quality is used to project the relative level of effort, cost, required manufacturing capability, and the supplier's competitive position regarding each WHAT. Projections are usually stated as Greatest, Average, and Least.
Translations of performance reliability measure to design reliability measures provide designers with targets by focusing on those reliability characteristics that can be met. By satisfying this target, the performance reliability objective will "automatically" be achieved. The benefit is that each designer will have a realistic target to work towards for that portion of the design under his/her direct control. The design target should be established before the design begins (i.e., during the C/P phase) in order to work towards achieving the reliability goal in the most efficient manner.
The first step in deriving design reliability requirements is to translate operational performance parameters into design parameters. For example, MTBM is a measure that takes into account factors that may be beyond the control of a supplier who designs the product, such as induced failures during customer use, or non-verifiable failures. So MTBM must be translated into a contract specification term, such as MTBF.
Finally, if a supplier's product is a component of the customer's product, the performance and design reliability requirements may be identical. For example, a customer's performance reliability requirement for a component may be an MTBF of 500 hours. In this case, the supplier of the component need not do any translation.
Following are two methods of making the translation from operational reliability to design reliability. While they were developed for the military, similar relationships can be used for commercial products, or simple "k factors" can be applied to relate performance reliability to design reliability based on supplier experience.
Operational Parameter Translation (OPT) Models. A set of models are available to translate operational (performance) reliability and maintainability measures into contractual, specifiable, and measurable values, i.e., design reliability. The models were developed by first identifying the variables that influence the measures being translated. Then, operational and design data was collected and statistical analysis techniques were used to develop and verify the models (Reference 5).
Automated Requirements Translation Tool (ART). The Reliability Information Analysis Center (RIAC) developed an automated method of translating operational reliability, maintainability, and diagnostic (RM&D) parameters into design requirements. The modeling methodology used was as follows:
Identify a set of operational RM&D requirements for the type of product.
Identify definitions for each operational requirement.
Derive an algorithm for each definition.
Simplify each algorithm to its simplest terms.
Use the terms resulting from simplification as the design requirements.
Use data for baseline products to set acceptable ranges of design values.
Simultaneously solve the algorithms.
The model provides ranges of design RM&D values derived from the operational RM&D requirements. Users of the model can then make trade-offs to find the best mix of RM&D design requirements. ART is available from the RIAC as a PC-based software tool (Reference 6).
Reliability Design Requirements from Analyses Many forms of reliability related analyses aid in the process of deriving the design reliability requirements. They provide a means of assuring compatibility with environmental and operational use conditions as well as assuring that the requirements are compatible with the state-of-the-art. However, they should not be blindly derived by applying a set of algorithms to performance reliability requirements. By supplementing the translation process with a tailored set of analyses, compatibility with other requirements and constraints can be cost-effectively assured. These analyses should be initially applied when the requirements are first being derived during the C/P phase, but should be iterated as appropriate during the Design and Development process.
The process cannot end with translation to a design specification. The translated requirements must be evaluated for realism. Questions that should be answered include: 1) are the requirements compatible with the available technology, and 2) do the requirements unnecessarily drive the design (conflict with other product constraints such as weight and power). Answering these questions usually involves a review of previous studies and data for similar or comparative products (if any exist). The design requirements, operational requirements, or both may need to be adjusted to account for the improvement in technology, different operating environments, different duty cycles, and so forth. Some of these analysis methods include the following.
Thermal Analysis (Reference 7) Temperature is one of the most important influences on reliability. Although temperature effects are usually associated with electronics, the reliability of mechanical components is also affected by temperature. By conducting a thermal analysis, designers can determine heat transfer paths and modes, temperature extremes experienced by individual components and parts, and the impact of thermal shock caused by rapid changes in temperature. In performing the analysis, the designer may find that even with reasonable cooling provisions and optimum placement of components and parts, the temperatures encountered by a product and its constituent parts make the reliability requirement technically or economically infeasible. The RIAC web site (Reference 8) shows a variety of commercially available thermal analysis software tools.
Durability Assessment For mechanical and structural elements of a product, a durability assessment can be used to determine if any associated service life requirements can be met. A generalized approach to conducting such an assessment is based on a Damage Tolerance Assessment methodology developed by the US Air Force for aircraft. Figure 6 depicts the generalized approach.
Figure 6. Generalized Approach to Durability Assessment (Click to Zoom)
Note that the durability assessment approach is a process that begins during design and continues throughout product testing. The service life estimates that result from the assessment can be used to evaluate the realism of the requirement. In addition to assessing the durability of the product, the approach provides information needed to establish maintenance inspection requirements (what is to be inspected and with what frequency).
Predictions As soon as initial predictions can be made, they should be compared with the requirement. A comparison of the different prediction methodologies can be found on the RIAC web site (Reference 9) or in greater detail in Reference 10. Depending on whether the prediction is lower than, equal to, or higher than the requirement, some action may be warranted.
If the predicted reliability is less than the requirement, the assumptions and methodology used in making the prediction should be reviewed and, if necessary, adjusted. If the prediction is reasonable, then the requirement must be re-examined.
If the prediction is considerably higher than the requirement, consideration should be given to raising the requirement to:
Gain a competitive advantage
Reduce future costs (e.g., warranty and maintenance)
Enhance safety
If the predicted reliability is approximately equal to the requirement, some concern is warranted. Predicting reliability is not a precise science, and some error is always associated with a prediction. Usually, a conservative position is taken in which the prediction should be higher than the requirement.
Fault Tolerance is an approach that allows the product to continue to meet its functionality while experiencing failure. It is normally accomplished by redundancy (usually active where all units are operational, but sometimes by standby where additional units become operational only at the time of failure) where parallel paths are added to keep the product operational if one path fails. In the context of deriving requirements, analysis of the degree of fault tolerance is a means of assuring that a needed reliability design level is practical to achieve.
Dormancy Analysis Like all time periods within the product life cycle, dormant periods have the potential to cause failure. An analysis of dormant periods identifies those unique attributes that affect the reliability requirements for nonoperating periods.
Safety Factors (SF) or derating factors are frequently applied in developing reliability requirements. They are used to account for the uncertainty in our understanding of physical phenomena, the inaccuracies of our models, and the limitations of our tools. Assume the probability of failure for a cable under a tensile load of 1,000 pounds must be less than 5%. We could apply a SF of 25% resulting in a requirement that the probability of failure be less than 5% when the tensile load is 1,250 pounds.
Derating is essentially the complement of a safety factor. It is a process of limiting electrical, thermal, and mechanical stresses on parts to levels below their specified ratings. Consider again the cable example. Assume the tensile strength of the cable is rated at 1,250 pounds. We can apply a derating factor of 80%, which means we will not use the cable in applications where it will be exposed to tensile loads greater than 1,000 pounds (i.e., 25% safety factor). Derating guidance can be found in a RIAC START Sheet (Reference 11) and in more detail in Reference 12.
Allocate Lower Level Requirements
Allocations provide a means to assign reliability requirements for complex products to lower levels. Product-level requirements are often insufficient to scope the design effort. For example, a requirement that a truck have an MTBF of 1,000 hours doesn't help the designers of the transmission, engine, and other components. How reliable must these components be?
Allocation addresses these questions. The allocation process is often iterative, requiring several attempts to satisfy all requirements. In other cases, the requirements can't be satisfied (to meet the product-level requirement, components are needed with unachievable levels of reliability) and dialogue with the customer and trade-offs are required to resolve the problem. Allocation of product-level reliability requirements to lower levels of indenture makes it easier to manage and track requirements. It enables the tracking of progress toward meeting the product requirements, provides a means of making a sanity check of product-level requirements, and facilitates trade-off studies.
Allocation of product reliability to lower levels of indenture begins as soon as the product-level design requirements have been derived from performance reliability requirements during the C/P phase. An initial allocation should be completed before design begins at each level of indenture, usually before a functional design review during the D/D phase. Updates are normally made before any major design reviews.
For large, complex products, it is difficult for a supplier to depend only on product-level reliability requirements. Productlevel requirements should not be imposed on the designers of each of the different components, subsystems, etc. When outside suppliers are involved, the problem is even more difficult. Some way of assigning a portion of the product-level requirement to designers and to outside suppliers is necessary. Allocation is the method of apportioning requirements.
If only product-level requirements were used, analysis would be the sole means of tracking progress until the entire product was built and tested. Testing of lower indenture items, however, can begin very early in a product development program. By tracking the progress made on each of these items, and then analytically "combining" the results, a good idea of the progress being made toward the product-level requirements can be gained. Problems, and solutions to problems, can be identified earlier than would otherwise be possible.
Even carefully developed product-level requirements may be unachievable. A way to check the realism of product-level requirements is through the allocation process. Of the many methods of allocating reliability, the five most common are: 1) Equal Distribution, 2) Complexity Based, 3) Feasibility of Objectives, 4) Minimization of Effort, and 5) Similarity.
Equal Distribution Method allocates the same value of reliability to each lower indenture item. It is most useful when the components are similar. It is defined as follows.
λia = (1 / n) * λpr
where,
λ
=
Lambda, the failure rate
i
=
Subscript for each lower indenture "item"
a
=
Subscript for "allocated"
N
=
Number of lower indenture items
p
=
Subscript for "product"
r
=
Subscript for "requirement"
It is often appropriate to allocate reliability "with reserve" where a certain fraction of the product requirement is held in "reserve" (is unallocated). By its very nature, this method provides conservative design goals for the lower indenture items. This modification can be used with any of the allocation methods described.
Other complexity based methods similar to the Equal Distribution method exist that attempt to account for the complexity of the product by weighting the allocations. Three common complexity based methods of allocation are the ARINC, AGREE, and parts count methods. Descriptions of the ARINC and parts count methods follow.
ARINC Method Complexity is assumed to be measured by the relative failure rates of the items (i.e., the higher the failure rate, the more complex the item). The method is described by:
λia = λpr (λie / λpe) = 1
/ MTBFia
where,
λ
=
Lambda, the failure rate
i
=
Subscript for each lower indenture "item"
a
=
Subscript for "allocated"
p
=
Subscript for "product"
r
=
Subscript for "requirement"
e
=
Estimated (or predicted)
The component with the highest predicted reliability is allocated the highest requirement, the component with the lowest prediction is allocated the lowest requirement, and so forth. For the example, no component has an estimated reliability equal to, or greater than, the allocated value. The designers can improve the reliability of the components, use redundancy, or select different components to meet the product reliability requirement.
Parts Count Method This method implicitly uses parts count as a measure of complexity. Allocations of reliability, as a failure rate, are made in proportion to the number of parts.
Other Methods More sophisticated allocation methods are described in the literature, including the minimization-of-effort, the feasibility-of-objectives, and the similarity method.
Minimization-of-Effort Method attempts to allocate requirements in a way that minimizes the effort needed to achieve the allocated requirements. Effort is a function of the number of tests, amount of analysis, and number of trades made, etc.
The Feasibility-of-Objectives Method was originally developed for repairable electromechanical products. Allocations to lower indenture items are based on numerical ratings of the design maturity (state of the art), intricacy, mission operating time, and conditions for each item to which the product reliability will be allocated. Ratings are assigned by a lead design engineer based on experience and judgment, or by a group of engineers using the Delphi technique. Ratings for each factor range from a low of 1 to a high of 10. Definitions of the factors and the meanings of the ratings are as follows:
Design Maturity An indication of the level of technology and degree of proven design approaches used in an item. Items with the most highly developed, mature design are assigned a rating of 1, those with the least mature design a 10.
Intricacy An indication of the number of parts and sophistication of the architecture. The least intricate items are assigned a rating of 1, the most intricate a 10.
Mission Operating Time An indication of the percentage of mission time during which an item operates. Items that operate for a small percentage of the mission time are assigned a rating of 1; those that operate continuously are assigned a 10.
Environment An indication of the severity of the environment experienced by the item during product operation. Items that operate in the least severe environment are given a rating of 1; those operating in the most severe are assigned a 10.
Just as the product-level requirement can be based on the achieved reliability of a similar product, allocations can be made based on how previous allocations were made for products with similar architectures.
"Electronic Derating for Optimum Performance," RIAC publication D-RATE.
About the Author
* Note: The following information about the author(s) is same as what was on the original document and may not be correct anymore.
Norman B. Fuqua is a Senior Engineer with Alion Science and Technology. He has 44 years of varied experience in the field of dependability, reliability, and maintainability and has applied these principles to a variety of military, space, and commercial programs. At Alion Science and Technology, and its predecessor IIT Research Institute (IITRI), he has been responsible for reliability and maintainability training and for the planning and implementation of various dependability, reliability, and maintainability study programs.
Mr. Fuqua developed unique distance learning Web-based and Windows-based computer-aided reliability training courses. He is the developer and lead instructor for the Reliability Analysis Center's (RIAC) popular Electronic Design Reliability Training Course. This three-day course has been presented over 200 times to some 7,000 students in the US, England, Denmark, Norway, Sweden, Finland, Germany, Israel, Canada, Australia, Brazil, and India. Audiences have included space, military, industrial, and commercial clients.
He was also the lead developer and instructor for a two-day Dependability Training Course for an Automotive Supplier and a three-day Robust Circuit Design Training Course. These courses enable mechanical and electronic design engineers and reliability engineers to utilize advanced software-based tools in producing designs that exhibit minimum sensitivity to both internal and external variations.
Mr. Fuqua holds a Bachelor of Science degree in Electrical Engineering from the University of Illinois, Urbana Illinois, is a Registered Professional Engineer (Quality Engineer) in California (retired), and a Senior Member of the IEEE and the IEEE Group on Reliability.
He is a former Member of the Editorial Board, "Electrical and Electronics Series," for Marcel Dekker Inc., and the Education and Training Editor for the "SAE Communications in Reliability, Maintainability and Supportability Journal." He is also a former Member of the EOS/ESD Association, and Chairman of three different EOS/ESD Association Standards Committees. He is the author of a number of technical papers, twenty RIAC publications and a reliability college textbook published by Marcel Dekker Inc.
Printer-Friendly Version
