Failures are everywhere:

-A robot shuts down in the field.
-You miss the bus on your way to work.
-Your hip starts hurting right before a volleyball game.

Some failures are minor. Some are costly. Some are painful — literally.

The real question isn’t whether failures happen (they always do), but:

• How do we respond when they happen?
• How do we understand why they happened?
• And most importantly, how do we prevent them from happening again?

That’s where FRACAS comes in.

What Is FRACAS?

FRACAS stands for Failure Reporting, Analysis, and Corrective Action System.

At its core, FRACAS is a structured way to deal with real-world failures — failures that have already happened in the field. It’s not a tool or software by itself, but a process that organizations use to:

1. Capture failures
2. Understand root causes
3. Define and implement corrective actions to prevent recurrence

A key point is: FRACAS focuses on actual failures, not hypothetical ones.

This is what differentiates it from methods like FMEA (Failure Modes and Effects Analysis), which are typically used during design phases to anticipate how a system might fail in the future. FRACAS, on the other hand, starts when reality strikes.

The ultimate goal of FRACAS is simple:

Reduce repeat failures by learning from what already went wrong.

The Core Phases of FRACAS

Although different organizations may use different terminology, FRACAS generally follows a consistent flow from failure occurrence to resolution.

1. Failure Occurrence: Something goes wrong. A system fails. A requirement isn’t met. An expectation is violated. This is the trigger — without a failure, there is no FRACAS.

2. Immediate Response (Containment): What do we do right now to: Stop the problem from getting worse? Limit impact to customers, operations, or safety? This step is about containment, not root cause.

3. Failure Analysis: Now we slow down and ask: What happened? How did it happen? What was the chain of events that led to the failure? This is where root cause analysis lives.

4. Corrective and Preventive Action: Based on what we learned, we define actions to: Prevent the same failure from happening again and reduce the likelihood or impact of recurrence

This is the step that turns failure into learning.

FRACAS in Everyday Life

Here’s the interesting part: Most of us already use FRACAS in daily life — just informally.

Example: Being Late to Work

Failure: I failed to arrive at the office at 8:00 a.m.

Immediate Response: I message my manager to let them know I’ll be late.

Analysis:
I missed the bus →
because I woke up late →
because I stayed up too late the night before.

That’s a failure event chain.

Corrective Action:
1.Set an additional alarm. 2. Commit to going to bed before midnight

That’s FRACAS without the acronym.

What FRACAS does is formalize this thinking, so individuals and organizations do it consistently and systematically.

FRACAS in an Industry Context

Now let’s look at a simplified industrial example.

Failure: A customer reports that a system cannot be powered on.

Immediate Response: A Field Service Engineer (FSE) goes on-site and restores functionality by replacing a broken cable. The system works again — but the story shouldn’t end here.

Failure Analysis:
Engineering investigation finds:

• The broken component was an Ethernet cable
• The cable design is prone to mechanical damage in real-world use

Corrective Action:
R&D proposes a design change:

• Use a stronger cable
• Improve strain relief
• Reduce the likelihood of similar field failures in the future

Now the same failure isn’t just fixed — it’s less likely to happen again.

That’s FRACAS working as intended.

Why FRACAS Matters

The value of FRACAS isn’t that it defines failures — we already know failures happen.

Its value is that it provides:

• A structured, closed-loop process
• A shared language across functions (Service, Quality, R&D)
• A mechanism to convert failures into measurable reliability improvement

There’s no single universal way to name or implement FRACAS steps, but the core principles remain the same:

Failures should be reported, analyzed, and followed by meaningful corrective action.

When done well, FRACAS isn’t about blaming mistakes — 
it’s about learning fast, fixing smart, and failing less often.

And honestly, that’s something worth doing — whether you’re designing robots or just trying to catch the bus on time.

I had a horrible physical therapy (PT) experience — and my background as a reliability engineer helped me understand why it failed.

The Problem Statement

Since last December, I’ve been dealing with persistent pain along the lateral side of my hip and leg. I’m a volleyball maniac, and this injury hit me both physically and mentally.

-It hurt every time I jumped.
-My vertical dropped.
-I subconsciously avoided using full power.
-Some nights, the pain was bad enough to wake me up.

I tried resting for a couple of weeks, hoping it would resolve itself. It didn’t. So I did what most people would do: I searched for an in‑network physical therapist and booked an appointment.

Because of scheduling delays, I finally saw the PT one month later.

The Diagnosis (or So I Thought)

During the first visit, the PT asked a few questions and ran some range‑of‑motion and strength tests around my right hip joint. Based on that, the conclusion was:

• Limited hip joint space
• Pinching during movement
• Possible scar tissue
• Weak glutes

The prescription: High‑rep, low‑load exercises to “remove scar tissue” and strengthen the glutes. At the time, this sounded reasonable.

The Execution

Each session followed a similar pattern:

• The PT showed me a few exercises
• Unless it was a brand‑new movement, I was mostly left on my own
• There was very little 1:1 observation or adjustment

Week after week, I reported the same thing:

“Daily life is mostly fine, but it hurts a lot during and after volleyball — especially jumping.”

I kept going, hoping improvement would eventually show up.

It didn’t.

What did show up was the bill:
Thanks to my insurance, each visit cost $80 out of pocket.

That’s when I quit.

And that’s when I got mad.

Then I Asked: Why Did It Fail?

Once the frustration settled, my reliability engineer brain kicked in.

Physical therapy, at its core, is failure investigation and mitigation. The “system” is the human body. Pain is a failure signal. Treatment is a corrective action.

And looking back, there were several red flags — very familiar ones. In this specific PT experience,

1. The User Profile Was Ignored

In reliability engineering, understanding operating conditions is fundamental.

My failure mode occurred during:

• Jumping
• High‑impact
• High‑cycle loading (volleyball)

Yet:

• My jump mechanics were never assessed
• Single‑leg landing or stabilization was never evaluated
• Fatigue and repetitive stress were not considered

This is equivalent to analyzing a component failure without ever testing it under its real load profile.

2. Module Testing Instead of System‑Level Testing

What was tested:

• Local hip strength
• Local range of motion

What was not tested:

• Kinetic chain behavior
• Ankle stability
• Alignment during dynamic movement
• Load transfer across joints

In engineering terms, this was module‑level validation without system‑level integration testing.

A system can pass every local test and still fail catastrophically in real operation.

3. No Failure Event Chain

In reliability analysis, we don’t stop at “what broke.” We ask:

• What initiated the failure?
• What propagated it?
• What secondary stresses were introduced?

There was no clear failure event chain built here.

For example:

• Could lateral hip pain be compensatory?
• Could ankle weakness or alignment issues overload the hip?
• Could asymmetrical landing mechanics be driving fatigue damage?

Without understanding the chain, corrective actions become guesswork.

Final Thoughts

This post isn’t about blaming one PT. It’s about recognizing that methodology matters, regardless of the domain.

As reliability engineers, we know:

• Context matters
• Load matters
• Systems matter
• And failures rarely exist in isolation

When those principles are ignored, even well‑intentioned solutions can fail.

Ironically, this experience didn’t just teach me about my body — it reinforced why structured failure analysis exists in the first place.

Sometimes, the problem isn’t lack of effort. It’s lack of system thinking.

In the previous article, we walked through the philosophical concept behind Bayesian inference and used a reliability example to show how we can obtain reliability parameters — such as the shape and scale parameters in a Weibull model — from a posterior distribution. In this note, I want to focus a bit more on the math behind Bayesian inference.

This is a self‑therapy article, meant to prove (or at least convince myself) that I’ve finally overcome something.

Why this post exists

I used to be afraid of this equation:

What I struggled with wasn’t Bayesian thinking itself, but Bayesian inference written in probability density function (PDF) form.

In statistics class, a classic Bayesian example is the disease test problem:
What is the probability that you are actually sick given a positive COVID test?

That example made sense. It was discrete, intuitive, and easy to reason about. But once things became more complicated: moving from discrete scenarios to continuous variables, from probability to probability density, from numbers to full distributions. I always felt like something important was missing. Specifically, I couldn’t see clearly where those equations came from, or how they connected back to simple probability ideas. So, I’m going to start from a basic probability framework, then carefully move forward into continuous variables and distributions.

Bayes’ rule in discrete probability

There are already many resources available on the internet explaining the Bayesian inference. Part of the notation, intuition, and geometric interpretation used in this article comes from a YouTube video by 3Blue1Brown. I strongly recommend watching it first if you’re not already comfortable with Bayesian inference. The video does an excellent job visualizing the relationships between the prior, likelihood, evidence, and posterior using geometry, which makes the notation, graphs, and ideas in this post much easier to follow.

https://www.youtube.com/watch?v=HZGCoVF3YvM

Here is a short summary of the math

For the Steve example, the notation becomes:

From probability to probability density (one important rule)

Before going further, here’s one rule I’ll use throughout this article:

Even when a variable is continuous, I’ll keep using probability language.

Whenever I say “the probability that λ equals some value,” what I really mean is: PDF value × a very small interval

Mathematically: probability =g(λ)dλ

where g(λ) is the PDF(probability density function) of the variable. With this rule in place, the transition from discrete to continuous becomes much less scary.

A Reliability Example

Now we can move to a reliability example and face my fear for continuous variables and distributions.

Suppose we know that the product’s time‑to‑failure follows an exponential distribution, and we have observed two failures: one at 0.3 years and another at 1.2 years.

The goal here is to understand the posterior distribution of the failure rate λ, which is the single parameter in the exponential model. Then we can use it to generate the reliability distribution at given time t.

Note that there are two different distributions involved in this problem: one is the distribution of the parameter λ, and the other is the distribution of time‑to‑failure given λ. More details about this concept can be found in the previous note.

Let’s begin with the probability concept by using the Steve visualization and probability framework. The question we want to answer is:

what is the probability that the product failure rate is equal to 10/year given 2 time-to-failure samples 0.3 and 1.2 year

Geometrically, this corresponds to the ratio:

Model Assumption

H (Hypothesis): the product failure rate λ is equal to 10 failures per year

E (Evidence): two time‑to‑failure samples, 0.3 and 1.2 years

We also need some math models to tell us how to determine the fraction of the blue/green and light/dark area. Therefore, we introduce:

Now we can put the math into the equation:

Note that for demonstration purposes, the plot shows λ = 1, 2, 3… but since λ is a continuous variable, this is actually the sum for the infinity slice of λ. At the end it can be written as an integral form.

Frome Posterior Probability to Posterior Distribution

With all the required pieces in place, we can now calculate the probability that the failure rate λ equals 10 given the observed evidence:

Dividing both sides by dλ, we obtain the posterior PDF value at λ=10:

Finally, replacing the specific value λ=10 with a general λ, we obtain the posterior distribution of λ:

This expression is exactly the standard Bayesian posterior form: the posterior distribution is proportional to the likelihood multiplied by the prior, with the evidence acting as the normalization constant.

This article is a note on my understanding of Frequentist and Bayesian.

For me the Bayesian mindset is:

We don’t know what the truth looks like, and we can’t access it directly. All we ever have is a belief about uncertainty.

On the other hand, the Frequentist (the one we are more used to ) mindset is:

There is a true value out there. Our job is to design procedures that, over repeated experiments, will reliably land close to it.

The core difference between Bayesian and frequentist inference is less about formulas and more about how we think about truth and uncertainty. They are both a way of reasoning about the world when outcomes vary and information is incomplete.

Reliability Example

Here is a reliability analysis example to illustrate the difference.

Suppose we collect 16 time‑to‑failure samples and assume the data follow a Weibull distribution. Our goal is to estimate the shape (beta) and scale (alpha) parameters so that we can calculate the reliability at 50 days.

The Frequentist Perspective: An ultimate truth seeker

From a frequentist perspective,

• There exists a true but unknown Weibull shape and scale parameter.
• The observed failure samples are realizations drawn from this true time‑to‑failure distribution.
• Using model‑fitting methods, we obtain estimators of the shape and scale parameters.

Are these estimators the true values? We do not know. Instead, frequentist statistics use tools such as, variance, covariance ,confidence intervals to describe how well the estimation process would perform if we repeated the experiment many times.

At the end, we typically obtain a reliability curve with confidence bounds. In this example, at t=50 days: Estimated reliability: 20.6%, 90% confidence interval: [6.3%, 40.5%]

The Bayesian Perspective: Belief from an observer

In Bayesian inference, everything starts with prior belief.

Before observing data, we express our belief about the parameters. For example, shape (beta) between 0.1 and 3, scale (alpha) between 0 and 200 days. This belief may be subjective or informed by prior experience.

Once the 16 time‑to‑failure samples are collected, we combine the prior belief and the observed data and throw them into a Bayesian inference algorithm, such as MCMC (Markov Chain Monte Carlo).

The output of MCMC is thousands of sampled parameter values for shape and scale. These samples represent the posterior distribution, i.e., our updated belief after seeing the data.

To compute reliability at t=50 days, Each posterior sample of shape and scale produces one reliability value. Together, these values form a posterior distribution of reliability

From this posterior reliability distribution, we can obtain:

• Posterior mean reliability: 17.4%
• 90% credible interval: [5.9%, 32.7%], obtained from the 5% and 95% posterior quantiles

Two Ways of Thinking About the Same Uncertainty

In this example, Both approaches attempt to estimate reliability at t=50 days using the same data:

• Frequentist:
  Reliability = 20.6%
  90% confidence interval = [6.3%, 40.5%]
• Bayesian:
  Reliability = 17.4%
  90% credible interval = [5.9%, 32.7%]

Both provide a point estimate and a range to describe uncertainty. (We are not focused on which number is “correct” because we will never know the true value.) However, their core philosophies for interpreting uncertainty are fundamentally different.

• Frequentist view:
  A confidence interval represents how often this interval‑construction process can capture the true value if the experiment were repeated many times.
• Bayesian view:
  A credible interval is based on the posterior distribution and is obtained by taking quantiles (e.g., the 5% and 95% quantiles) of the posterior samples.

I also made a meme for frequentist. I don’t know where to put it so I will just leave it here.

When it comes to complex systems, reliability isn’t just a metric — it’s a mission-critical requirement. Yet, understanding where and why a system becomes “unreliable” can feel like searching for a needle in a haystack. Enter JARS (Just Another Reliability Spreadsheet): a powerful, Excel-based tool designed to simplify reliability analysis without sacrificing depth.

What is JARS?

JARS is a structured reliability calculation tool that transforms raw failure data into actionable insights. At its core, it requires two key inputs:

• Failure Modes: Each component’s potential ways of failing.
• Time-to-Failure Distributions: Statistical parameters (e.g., Weibull shape and scale) that define how and when failures occur.

With these inputs, JARS computes system-level reliability and allows you to drill down into subsystem, assembly, and module-level reliability. This hierarchical approach means you can pinpoint weak links in your design with precision.

Why Use JARS?

• Comprehensive Analysis: From top-level system reliability to granular failure modes, JARS provides a clear picture of performance.
• Easy Breakdown: Navigate through subsystems and assemblies effortlessly to identify which part is dragging down overall reliability.
• Data-Driven Decisions: By highlighting critical failure contributors, JARS empowers engineers to prioritize design improvements and maintenance strategies.
• Cost & Spare Planning: Beyond reliability, JARS integrates failure resolution cost and spare demand calculations, bridging the gap between engineering and logistics.

How It Works

1. Input Your Data: Populate the spreadsheet with failure modes, Weibull parameters, and expected usage.
2. Run Calculations: JARS computes reliability for each component and aggregates results up the hierarchy.
3. Analyze Results: Visualize system reliability, identify high-risk modules, and plan corrective actions.

Who Benefits?

• Reliability Engineers: Gain clarity on system weaknesses and optimize design.
• Maintenance Teams: Forecast spare parts demand and reduce downtime.
• Program Managers: Make informed decisions on cost, risk, and lifecycle planning.

Bottom Line

JARS isn’t just another spreadsheet — it’s a strategic tool for anyone serious about reliability engineering. By turning complex reliability modeling into an intuitive process, JARS helps you answer the most important question: What’s making my system unreliable, and how do I fix it?

My experience

When I first studied reliability engineering, one term kept popping up: “failure mode.” It was introduced in my very first class. I remember the professor explaining its definition, but honestly, I didn’t pay much attention. Back then, I was more interested in calculations such as fitting Weibull distributions, estimating acceleration factors, and crunching numbers. To me, failure mode and failure mechanism were just fancy synonyms for “failure.”

A failure mode is simply any event that causes a functional failure.

I didn’t realize how critical these terms were until I started my first job as a reliability engineer.

My first role was working on surgical robots. One of my initial responsibilities was building a Failure Reporting, Analysis, and Corrective Action System (FRACAS), which is like a platform for reporting failures observed during testing, demonstrations, or field use. Essentially, it’s a database for capturing product failure information.

My task sounded straightforward: extract insights and present findings such as:

• Which components fail most frequently
• What types of failures or root causes are associated with specific components
• Quantitative metrics like failure rates for individual parts

But reality was different. Failure reports varied wildly:

• Some documented only functional failures without root cause analysis.
• Others noted vague symptoms like “error code popped up” with no context.
• Some described components by appearance alone, forcing me to investigate part numbers and locations.

I spent weeks cleaning and restructuring data, filling gaps, standardizing terminology, and organizing failures into meaningful categories. Eventually, I realized the root problem:

there was no clear, consistent way to describe and report failures effectively.

That’s why I’m writing this, to share my thoughts on why describing failures matters and how to do it better.

Why does Failure Descriptions Matter?

Clear failure descriptions are essential for reliability work because they improve:

• Communication
• Documentation
• Analysis

Without a shared framework, the same failure can be described in many ways, causing confusion and wasted time. Structured reporting turns raw data into actionable insights by grouping failures, identifying patterns, and building searchable records. Precise descriptions also support analysis by tracking failure frequency, prioritizing critical issues, and guiding design improvements. In short, describing failures well is the foundation for understanding and improving system reliability.

How to Describe Failures: Think in Chains

To describe a failure effectively, we first need to break it down: what makes a failure instance? Failures in a product or system typically result from a combination of interconnected events (failure modes). Each failure mode has a cause-and-effect relationship with another, forming a chain. One failure mode exists due to the next level failure mode.

Engineers use failure analysis (or root cause analysis) to trace and link these modes. The result is a structured view of the failure: starting from the top-level functional failure, moving through subsystem-level symptoms, and ending at the root causes: such as a faulty component, a physical or chemical reaction, human error, or environmental stress.

Example: System Initialization Failure

Consider a surgical robot system. When powered on, it begins an initialization process that verifies connections and communication between all stations (robot, camera, PC). Only after these checks succeed can the user proceed to the next step. The example below illustrates a failure description for one specific case of system initialization failure.

In this example, the top-level failure mode (Level 0) is a functional failure. Each subsequent level represents a deeper cause, linked by the phrase “due to.” For instance:

• Level 0 failure is due to Level 1: The system fails to initialize due to the connection test failing.
• Level 1 failure is due to Level 2: The connection test fails due to the robot-PC connection not being established.
• And so on.

Each failure mode is described using the format: [Subject] + [Verb], such as “the wire fractures” or “the cable is discontinuous.”

Through failure analysis, we identified failure modes from Level 0 to Level 5, forming a detailed chain for this initialization failure. This hierarchy clearly illustrates the cause-and-effect relationships behind the failure, making it easier to understand and address.

What level should failure analysis stop?

The next question is: how deep should we go? Digging into another level of failure mode adds cost and effort. If we reach a level where we have no control or cannot take meaningful action, continuing the analysis becomes wasted labor. That’s why it’s critical to identify the right level of detail, one that is both actionable and meaningful for resolution.

For practical purpose, a root failure mode is defined as the last cause we choose to pursue in the failure analysis. Root failure mode is where the failure analysis should stop at. It is not necessarily the lowest-level physical cause, but rather the point where:

1. A specific physical object or condition is clearly identified. For example, “The connection between the robot station and the PC is not established” is not an appropriate root failure mode, since there can be several components involved in the connection between robot station and PC and we cannot isolate the cause.
2. The root failure mode should be actionable, meaning the subject described in root failure mode can be repaired, replaced, redesigned, or controlled. Going beyond this level would not add practical value based on your role, scope, or authority.

The determination of root failure mode also depends on different scenarios, the following uses the same initialization failure, but due to different scenarios, the root failure modes are different.

• If the connection cable is a commercial off-the-shelf part, and engineers simply replace it when it fails, then cable discontinuity is a sufficient root failure mode.
• If the cable is a proprietary design, and your team has control over its internal structure, then it makes sense to go deeper and identify Ethernet wire fracture as the root failure mode.

In short, the root failure mode is where failure analysis stops, because further investigation would not lead to more actionable insights or is outside the scope of control.

Key Takeaways

• Language matters: precise failure descriptions enable better communication, documentation, and analysis.
• Think in terms of chains of failure modes, not just symptoms.
• Define a root failure mode that is specific and actionable.
• Good failure reporting is the foundation for reliability improvement.

Reference:

Failures vs. Functional Failures vs. Failure Modes vs. Failure Mechanism

What is the Difference Between Failure Analysis (FA), Root Cause Analysis (RCA) and Root Cause Failure Analysis (RCFA)?

Imagine you are a reliability engineer working on a product. The product has a reliability target Rₒ, for example, Rₒ=99% over 7 years of usage. Your manager asks:

“Does our product meet this target? How do you statistically prove that?”

Your first thought: Run a test.
The purpose of the test is simple: we don’t know if the product’s actual reliability Rᵢ is above or below 99%. The test result should tell us, based on whether it passes or fails.

In an ideal world, you could design and run a perfect test:
- If the product’s reliability is greater than 99%, it passes.
- If not, it fails.

The pass rate versus actual reliability would look like a step function (Figure 1):

• Fail when Rᵢ<99%​: Pass rate = 0
• Pass when Rᵢ≥99%​: Pass rate = 100%

Reality: Uncertainty and Test Errors

In reality, the pass rate versus actual reliability Rᵢ is unlikely to be a step function. Instead it is more likely to be an increasing curve (Figure 2).

• Higher true reliability → higher chance of passing
• Lower true reliability → higher chance of failing

When we talk about the “chance of passing,” it means there is no absolute guarantee, a highly reliable product might still fail, and a less reliable one might occasionally pass. This uncertainty arises from test error, which represents the risk that the test result does not accurately reflect the true reliability.

There are two types of errors:

• False Pass: The test says the product meets the target, but it actually doesn’t. (Consumer risk).
• False Fail: The test says the product fails, but its reliability is actually above the target. (Producer risk).

These are shown in Figure 3 as red (false pass) and light red (false fail) areas. The size of these areas depends on the shape of the pass-rate curve. Engineers can manipulate this curve to control test error and therefore confidence in the result.

What is a Reliability Demonstration Test (RDT)?

So, how do we control confidence of a test result? Let’s use the Reliability Demonstration Test (RDT) as an example.

An RDT aims to show that a product meets its reliability target Rₒ. The result is either pass or fail. A typical zero-failure RDT works like this:

• Run the same life test on N identical samples.
• Each sample either passes or fails.
• If all N samples pass, the product passes the RDT.

In our case, if the actual reliability of the product is Rᵢ. The probability for each sample to pass each life test is also Rᵢ. Then the probability of passing the whole RDT is

Pass Rate = (Rᵢ)^N

This is the orange pass rate curve we saw in the previous figures. By changing N, engineers can shift the curve and control test confidence.

Manipulate the Pass Rate Curve

Example: Compare a 2-sample RDT vs. a 4-sample RDT (Figure 4):

• The 4-sample passing rate curve shifts downward, making the product harder to pass RDT (given the Rᵢ).
• This reduces the chance of a false pass (bad product passing). (Compare the orange and purple area)
• But it increases the chance of a false fail (good product failing).

So we can conclude the two tests as the following table.

Which is better? At first glance, 2-sample seems cheaper and has lower producer risk. But in practice, consumer risk matters more because:

• False pass → unreliable or unsafe product reaches the market (serious consequences).
• False fail → delays and extra cost for the producer (less severe).

So, when designing a test, controlling false pass is the top priority.

Control the Test Error

So far we already know

1. Test error, false pass and false fail, are inevitable.
2. We can control the error probability by changing the number of samples N in an RDT.
3. We care most about false pass because of its impact on customers.

At the beginning of a test design, we need to set a requirement for the maximum allowed false pass probability for RDT, denoted as α.

α = maximum allowed probability for a faulty product to pass the test

If the actual product reliability is below Rₒ (99%), e.g., 98.99% or 97% or 95%, we want the pass rate to be below α.

Figure 5 shows this concept.

• Red area = scenarios that the actual reliabilities Rᵢ are lower than target Rₒ, 99%.
• If the pass rate = α at Rᵢ=Rₒ, any reliability Rᵢ that is below Rₒ would have a pass rate less than α. This ensures the risk of letting a bad product pass is controlled.

Now we can easily solve the number of samples N to meet the consumer risk requirements α.

Designing an RDT

In conclusion, there are two core elements we need to design an RDT.

• Target reliability: Rₒ
• Maximum acceptable false pass probability: α

Using the Rₒ and α in previous equation, you can calculate the minimal number samples N.

When the test is succussed (all N samples passed the life test), you can claim that:

“With the confidence of (1-α), the product of the reliability is greater than Rₒ.”

One of the jobs of reliability engineers is to obtain reliability data for products (component/assembly/system). Such data includes failure modes and life models, which describe how and when the subject will fail. The data can be acquired through reliability testing. Whether the testing is conducted within our own lab or through third-party facilities, it is crucial that the reliability engineer prepares an initial test plan to facilitate communication and coordination among involved teams.

The following bullets are the ones I think are important to think through for reliability test planning. The first three bullets are about the test subject itself. Those bullets should be consulted and discussed with the product development team (hardware/electronic team) since they are the people who are the most familiar with the product. Bullet 4 to 7 are about the reliability objective and testing itself. The reliability engineer should confirm the test objective and discuss the testing requirement with the testing team.

1. Test Subject

• Definition: Identify what is being tested: component, assembly, or system-level.
• Function: Clarify the function of the test subject and understand how the test subject operates in real-world conditions.

2. Mission Profile

• Expected Life: Define the total operational hours or number of power cycles, with an emphasis on the importance of precise time units.
• Environmental Conditions: Specify temperature, humidity, and other relevant environmental factors during operation.
• Force Profile: For mechanical parts, detail the forces or torques experienced during normal operation.
• Electrical Profile: For electronic components, specify typical voltage and current levels.

3. Failure Definition

What is considered a failure for the test subject, which may include:

• Failure to pass functional tests (fail to perform certain functions)
• Measurement exceed a given criteria: e.g., Electrical anomalies such as overcurrent or resistance deviations

4. Test Objectives

Determine the primary purpose of the test, which may include:

• Identifying failure modes (more qualitative like HALT, HASS)
• Building a life model (will need quantitative time-to-failure data)
• Demonstrating reliability concerning specific requirements
• Measuring performance metrics

Multiple objectives can be targeted within a single testing campaign.

5. Testing Parameters

• Test Type: Life testing, accelerated life testing, HALT, etc.
• Sample Size: Most of the time this is a constraint related to cost and availability.
• Test Duration & Cycles: Calculated based on expected life and accelerated testing principles.
• Testing Environment: Nominal vs. accelerated conditions.

6. Test Bench & Equipment Capabilities

• Simulation of Mission Profile: Capable of creating the required environmental condition (temperature/humidity) and/or replicating the operation of the test subject.
• Automation Level: Manual vs. automated testing processes.
• Measurement & Monitoring:
  Capability to halt test and/or record the timepoint/cycles upon failure
  What is measured (e.g., voltage, temperature, stress levels) during / at the end of the test

7. Data Collection and Analysis

• Data Collection Format: time, performance (metric or pass/fail), other observations.
• Analysis: qualitative (failure modes identification) or quantitative (time-to-failure model)

1. Obtain the Reliability Model

The reliability model describes the time-to-failure distribution for the component. This model can be derived from datasheets, fitted from testing samples, or based on field data.

2. Generate Failure Events

Using simulation techniques such as Monte Carlo analysis, failure event timelines can be generated. The intervals between failures are either sampled from the time-to-failure (TTF) distribution or based on pre-determined preventive maintenance intervals.

3. Calculate the Cash Flows

For each failure event, the corresponding cash flow should be estimated. A comprehensive cost model should include costs such as part repair or replacement, labor, shipping, and other relevant expenses.

4. Analyze Cost Distribution

By running numerous Monte Carlo simulations, multiple cash flow scenarios are generated. These results can be visualized through cash flow diagrams, and the collected cost samples can be displayed using histograms and density plots.

This approach allows for the estimation of the overall cost attributable to component reliability. It also enables analysis of how improvements in reliability influence costs. Additionally, different maintenance strategies, such as varying preventive maintenance windows, can be evaluated to determine the most cost-effective approach.

how many spare parts should we keep in stock?

Misjudging inventory levels can have significant consequences. If we overprepare, we tie up resources and incur unnecessary costs; if we underprepare, we risk extended downtime for fielded systems. This leads to an important consideration: how “safe” is our current stock level, and what is the impact of inventory decisions on system availability? At the end of the day, it is always a tradeoff problem between money, availability and customer satisfaction. To make good decisions, we need to understand the relationship among these factors.

This memo aims to utilize a simple model to estimate system downtime based on our inventory stock levels. The model draws on METRIC inventory model (Sherbrooke, 1992) and Palm’s theory (Palm, 1938). Under a single-echelon inventory scenario, the number of spare parts available follows a Poisson distribution. This allows us to estimate the probability of stockouts and calculate the associated impact on system downtime due to waiting for spare parts.

Scenario/Scope

The model is suitable for single echelon inventory, high-value spares that uses (s, s-1) inventory policy.

Figure 1 illustrates a single echelon inventory scenario for an individual component, represented by the gear icon in the figure. In this setup, a single inventory of the component supports all fielded (customer) systems. We are implementing a (s, s-1) spare support policy, which is typically used for high-value components. Initially, a certain quantity of spare components will be purchased and replenished from refurbished units. In this context, faulty components will be repaired and returned to inventory after failing in the field.

In Figure 1, the orange arrow indicates the complaint flow. When a system failure occurs due to a faulty component, the fielded system submits a complaint requiring intervention to replace the defective unit.

The blue arrows depict the flow of components, including spare units and faulty items. Upon receiving a complaint, an engineer retrieves a spare component from the inventory to address the issue in the field, by removing the faulty component from the system and installing the spare. The defective unit will then be sent to a repair center. Once repaired, it will be reintegrated into the inventory.

Figure 2 considers an example with the following assumed time values: The mean time between complaints (t𝒸), which reflects how frequently fielded systems require spare components, is set at 1 month. It is expected that this interval may decrease as the number of fielded systems increases.

The spare replenishment time (tᵣ) for a faulty component is estimated to be approximately 4 months. This total duration encompasses the time required for shipping the defective component to the repair center, the actual repair time, and the subsequent shipping period for returning the repaired component to the inventory.

Additionally, the time taken for an engineer to deliver a spare component in order to replace the faulty unit (t𝒹) is estimated at an average of 2 days. This period is generally shorter than the other durations discussed, as it is critical to minimize system downtime, which can lead to considerable costs. For the purposes of subsequent calculations, this shorter duration can be considered negligible.

Spares in the inventory

With the time setup, we can now discuss what actually happen to the inventory. Assume that an initial stock of N spares is purchased at the beginning (termed stock level, SL), with N being sufficient to support the fielded systems. The spares on hand (OH) in the inventory over time is illustrated in Figure 3: During the first four months, the quantity of spares on hand decreases due to an average of one complaint per month (t𝒸=1 month). After four months, the inventory begins to replenish as the first repair of a faulty component is completed and the component is returned to the inventory. Although the spares on hand will continue to decrease at an average rate of one per month, they will also be replenished at the same rate. At this point, the spares on hand will stabilize at an average of N−4 units.

If we modify the data by subtracting the stock level (N) from the spares on hand, we can derive the pipeline over time, shown in Figure 4. The term “pipeline” refers to the quantity of faulty components that are undergoing replenishment or repair at a given moment. In this scenario, when a faulty component is removed from the fielded system, it enters the pipeline, increasing the count by one. Once the faulty component is repaired and returned to inventory, it exits the pipeline, resulting in a decrease of one in its quantity. Initially, faulty components are gradually added to the pipeline. After four months, the first faulty component leaves the pipeline and the pipeline reaches a steady state of average four faulty components in the pipeline after four months.

Steady state distribution

We know either pipeline or spares on hand will eventually enter a steady state. The steady state can actually be represented by an analytical function. According to Palm’s theorem (Palm, 1938), if the spare demand follows a Poisson process with a mean of time between complaints (t𝒸) and the spare replenishment time (tᵣ) is identical and independent of a specific distribution, the pipeline distribution can be represented by a Poisson distribution with a mean equivalent to tᵣ/t𝒸. This mean (μ) is also the average pipeline. In Equation (1), Pr(X) represents the probability of having X items in the pipeline, i.e., X subsystems still in resupply process.

This distribution allows us to approximate the probability of the number of faulty components in the pipeline during a steady state. For each pipeline scenario, there are corresponding spares available on hand and backorders. These scenarios are listed in Figure 5.

Saying that we have N stock level, i.e., N spares are prepared in advance,

• When there are no components in the pipeline (pipeline = 0), all N spares in the inventory remain available (OH = N).
• Conversely, when there are N faulty components in the pipeline (pipeline = N), there are no spares left in the inventory (OH = 0).
• If the number of components in the pipeline increases to N+1, not only will there be no spares on hand, but there will also be one backorder, which indicates that any spares replenished must be allocated immediately to satisfy the backorder.

Wait Time Estimation

Furthermore, we can estimate the wait time for the spares, as shown in Table 1. Whenever a spare is needed,

• If the pipeline count is less than or equal to N−1 (indicating at least one spare is available), there will be no wait time for the spare.
• If the pipeline reaches N, the process must wait until the next spare is replenished.
• Similarly, if the pipeline reaches N+1, there will be a wait for two spares to be replenished (due to one backorder).

During the steady state, the time between spare replenishments (the interval at which fixed spares arrive in inventory) is equivalent to the time between complaints (t𝒸). Therefore, we can estimate the spare wait time by multiplying the time between complaints (t𝒸​) with the number of backorder plus 1.

As a result, We calculate the average wait time as the sum of the products of the probabilities of each scenario and their corresponding wait times. This leads to the expected spare wait time per complaint. Adding this value to the time required for an engineer to deliver a spare component (td​) gives us the expected system downtime for customers per complaint.

Example

To illustrate this model, let’s use some numerical values for the parameters: tᵣ, t𝒸 and t𝒹. The average pipeline can be calculated as tᵣ/ tc=4 (unit). In this example, we aim to assess the inventory performance with a stock level of 10.

Using Table 1 as a template, we can fill in the values. The probability column is derived from the Poisson Distribution with a mean of 4. The wait time column can be calculated by multiplying tc​ with one plus the backorder.

By aggregating all scenarios, we determine that the average spare wait time is approximately 8.83 hours. By adding this to t𝒹​, we estimate the average customer system downtime to be around 2.37 days.

Reference

• Palm, C. (1938). Analysis of the Erlang traffic formulae for busy-signal arrangements. Ericsson Technics, 4, 39–58.
• Sherbrooke, C. C. (1992). Optimal Inventory Modeling of Systems: Multi-Echelon Techniques. Wiley.