Latest / Mechanical Engineering Made Simple / (#71) Risk and Lifecycle Cost

Transcript

(#71) Risk and Lifecycle Cost · Mechanical Engineering Made Simple

• 0:00
  Welcome back, design junkies, to Mechanical Engineering Made
• 0:02
  Simple. If you enjoy the podcast, show
• 0:04
  your support with a like a follow.
• 0:07
  Let's keep levelling up together.
• 0:09
  Today we're doing a deep dive that should, I think, really
• 0:12
  change how you approach some of the biggest decisions you have
• 0:14
  to make as an engineer. Yeah, we're talking about those
• 0:16
  high stakes choices. Exactly the ones that determine
• 0:19
  safety costs. The actual lifespan of these
• 0:21
  huge multi £1,000,000 assets. The mission here is to move all
• 0:26
  of that away from, you know, instinct or just this is how
• 0:30
  we've always done it. And anchor it in something
• 0:32
  solid. Anchor it firmly in verifiable,
• 0:34
  defensible numbers. That's the real challenge, isn't
• 0:37
  it? Bridging that gap between a
• 0:39
  technically brilliant idea and, well, corporate accountability,
• 0:44
  the core question we're really trying to answer today is how do
• 0:47
  I prove that one design is numerically safer, or more
• 0:51
  reliable or just flat out more cost effective than another?
• 0:55
  And not just for a day one. Right.
• 0:56
  Not just for startup, but across the entire, you know, multi
• 0:59
  decade life of the thing. We've put together a framework
• 1:02
  for that, for that kind of engineering accountability.
• 1:05
  We're going to walk through 4 critical pillars.
• 1:09
  OK, what? Do we got?
• 1:10
  First, risk quantification. This is where we justify safety
• 1:14
  decisions with hard data, probabilities, consequences, the
• 1:18
  whole 9 yards getting. Past the hand waving.
• 1:20
  Precisely. Then we'll get into post failure
• 1:23
  investigations. This is about learning something
• 1:25
  real from a defect report, not just patching the symptom.
• 1:28
  So what? Actually went wrong.
• 1:29
  What actually went wrong and how we stop it 3rd we'll tackle
• 1:34
  human error integration this is the uncomfortable one the truth
• 1:38
  that you know, human performance often dominates how reliable a
• 1:41
  modern system is it's. Not just about the hardware
• 1:43
  anymore. It's rarely just about the
• 1:45
  hardware. And finally, we'll bring it all
• 1:48
  home with designing for the full life cycle.
• 1:51
  This is where we show why the cheapest option upfront is often
• 1:53
  the most expensive 1 you can possibly choose.
• 1:56
  OK, this is a huge topic. Let's get into it, starting with
• 1:59
  that bed rack principle. Risk quantification for decision
• 2:02
  making. We need to take that vague fear
• 2:05
  of what if and turn it into something management can
• 2:10
  actually act on. Right into cold hard math.
• 2:13
  Exactly. The whole foundation for this
• 2:15
  rests on a really precise technical definition of risk.
• 2:20
  Risk isn't just, you know, a hazard existing.
• 2:23
  It's more of that it's explicitly 2 measurable things
• 2:25
  that you have to look at together first, the frequency or
• 2:28
  the probability of something bad happening.
• 2:30
  OK, so how often? How often?
• 2:32
  And 2nd, the measurable scale of the consequence that results
• 2:36
  from it. So if I'm designing A pipeline,
• 2:39
  it's not enough to say the pipe might break.
• 2:41
  No, that's useless. I have to say how likely it is
• 2:44
  to break and then quantify the outcome, the damage, the
• 2:47
  environmental harm or, you know, the loss of life.
• 2:50
  Precisely. And that's the whole point of a
• 2:51
  quantified risk assessment or QRA.
• 2:54
  It's the structured process of taking those two things,
• 2:57
  frequency and consequence, and actually putting numbers on them
• 2:59
  which. Lets you compare things.
• 3:00
  It lets you compare different risks, different designs,
• 3:03
  different safety measures, apples to apples.
• 3:05
  So walk us through that classic process plant example.
• 3:09
  It really shows how this works in practice.
• 3:11
  Sure. So imagine you're assessing a
• 3:13
  big process plant. It's near a town, and it handles
• 3:16
  some pretty nasty materials. Toxic, flammable, you name it.
• 3:22
  High hazard. A very high hazard situation.
• 3:25
  Your QRA, after a lot of work, might determine that the
• 3:29
  probability of a catastrophic release is, let's say one in
• 3:32
  10,000 years. OK, one in 10,000 on its own,
• 3:36
  that sounds incredibly low. Most people would hear that and
• 3:39
  think, OK, we're good. Right.
• 3:40
  It seems acceptable because it's so rare, but then you have to
• 3:43
  bring in the other half of the equation, the consequence, the
• 3:45
  consequence. So your consequence analysis
• 3:47
  models the toxic plume. It factors in wind population
• 3:50
  density, maybe time of day, and it determines that this one
• 3:54
  single event would result in 40 fatalities.
• 3:58
  And suddenly that one in 10,000 year number doesn't feel so
• 4:01
  reassuring. It's completely changed the
• 4:03
  picture. That combination, a rare event
• 4:06
  with a catastrophic outcome, now defines the whole scenario as an
• 4:10
  unacceptable risk. It doesn't matter how low the
• 4:13
  probability seems, the consequence is just too high.
• 4:16
  This sounds like a massive undertaking.
• 4:17
  You can't just guess these numbers, you need some kind of
• 4:21
  formal, structured way to figure out what could even happen in
• 4:24
  the 1st place. Oh.
• 4:24
  Absolutely. It's incredibly rigorous.
• 4:26
  You start with what's called a Hazid hazard identification.
• 4:30
  Hazid. This is where the whole team,
• 4:32
  engineers from every discipline, gets in a room and
• 4:36
  systematically identifies every single possible hazard in the
• 4:40
  design. They're asking where's the
• 4:42
  energy? Where are the toxins?
• 4:43
  Where can things break? And after you've identified the
• 4:45
  what, you move on to the how. Exactly.
• 4:47
  You move to the HAZO too, the hazard and operability study.
• 4:50
  This is where you take those hazards from the Hazid and you
• 4:52
  figure out how they might actually arrive.
• 4:54
  So not just the tank could over pressurize, but the cooling
• 4:58
  water could fail leading to a runaway reaction leading to over
• 5:02
  pressurization. Precisely.
• 5:05
  It uses these systematic keywords like no flow, more
• 5:08
  temperature to force you to think through every possible
• 5:11
  deviation from the design intent.
• 5:13
  It's like a structured creative brainstorming session for
• 5:16
  disasters. And once you've figured out the
• 5:18
  failure mechanism, the final piece is the Hazam.
• 5:22
  The hazard analysis, or as it's also known, consequence
• 5:26
  analysis. And this part is highly
• 5:29
  specialized. You're talking complex modeling,
• 5:31
  fluid dynamics, chemical dispersion, you name it, to
• 5:34
  predict the physical outcome. So the Hazan gives you the 40
• 5:37
  fatalities number from our example.
• 5:39
  Right, that's the output, and that number plugs directly back
• 5:42
  into your overall QRA. OK, so that's the consequent
• 5:45
  side of the equation. Let's flip over to the frequency
• 5:47
  side. How in the world do you predict
• 5:49
  the probability of failure for, say, a brand new system?
• 5:53
  You rely on the established methods of reliability
• 5:55
  prediction. The workhorses here are tools
• 5:57
  like fault tree analysis, FTA and reliability block diagrams,
• 6:01
  or RBDS. And these tools let you build up
• 6:03
  a system's reliability from the reliability of its individual
• 6:07
  parts. Exactly.
• 6:09
  You're using known failure rates for pumps, valves, resistors,
• 6:13
  data that's often been collected over decades by industry, and
• 6:16
  you combine them logically to predict the failure rate of the
• 6:18
  whole system. The logic of the fault tree is,
• 6:21
  I think, a real light bulb moment for a lot of engineers.
• 6:24
  Can we breakdown those logical gates, the A&D and the OR gates?
• 6:28
  Yeah, the. Translation is key, so if your
• 6:30
  fault tree uses an A&D gate, you're modeling a system where
• 6:34
  multiple things have to fail at the same time for the top event,
• 6:38
  the big disaster, to happen. Redundancy.
• 6:40
  It's the model for redundancy. It's the same as a parallel
• 6:43
  diagram in an RBD. And because simultaneous
• 6:46
  failures are way less likely, you multiply the probabilities
• 6:50
  of the individual failures together.
• 6:51
  And when you multiply 2 small numbers, you get an even smaller
• 6:54
  number, so redundancy drastically cuts your failure
• 6:57
  rate. Right.
• 6:57
  That's high integrity design in action.
• 6:59
  Now the flip side is the OR gate.
• 7:01
  The OR gate. If you use an OR gate, you're
• 7:03
  modeling a series case. Think of a simple chain.
• 7:06
  Any single link breaks, the whole chain fails.
• 7:09
  So failure of component A or component B or component C and
• 7:13
  you're done. You're done, the system fails,
• 7:16
  and in that case you're basically adding the failure
• 7:18
  rates. So the system's overall failure
• 7:20
  rate is going to be dominated by your single worst component.
• 7:23
  So once you've run these huge complex analysis, what's the key
• 7:27
  output? What's the thing you take to
• 7:29
  management that actually gives them strategic direction?
• 7:32
  They need actionable intelligence, and the most
• 7:35
  powerful output for that is the list of ranked cut sets.
• 7:38
  Ranked cut sets? OK, what's a cut set?
• 7:40
  A cut set is the minimal combination of component
• 7:42
  failures that are necessary to 'cause that top level event.
• 7:46
  The analysis then ranks these different failure paths in order
• 7:49
  of their percentage contribution to the total system failure
• 7:52
  rate. So it's like a Pareto analysis
• 7:55
  for failure. You're finding the 20% of
• 7:57
  failure pads that cause 80% of the risk you've.
• 7:59
  Got it. It's incredibly powerful.
• 8:01
  For example, you might analyze a fluid system and find that the
• 8:04
  failure path involving the pump contributes 50% of your total
• 8:08
  risk, the path that the motor contributes 40%, and literally
• 8:12
  every other possible failure path combined only accounts for
• 8:15
  the last 10%. That's amazing.
• 8:18
  So instead of just guessing where the weak link is or
• 8:20
  spreading your budget thinly across every component.
• 8:22
  You now have data. You know with numerical
• 8:25
  certainty that improving the reliability of that pump will
• 8:27
  give you the single biggest risk reduction.
• 8:30
  It tells you exactly where to focus your money and your
• 8:32
  engineering effort. It moves the conversation from
• 8:35
  opinion. I've always had bad luck with
• 8:37
  these motors to defensible fact. Which brings us to a really
• 8:41
  difficult area where engineering meets, I guess, public policy
• 8:45
  and ethics. Yeah.
• 8:47
  How do you decide what level of risk is acceptable?
• 8:51
  I mean, we know zero risk is impossible.
• 8:53
  It is. And this is where we have to
• 8:54
  define three zones of risk. At the very top you have the
• 8:57
  unacceptable risk zone. If your analysis puts you there,
• 9:00
  you have to reduce the risk. Cost is not an object.
• 9:03
  OK, that's clear below. That you have the tolerable risk
• 9:06
  zone, and this is where the core principle of ALARP applies.
• 9:09
  Alarp as low as reasonably practicable?
• 9:13
  I've heard that phrase 1000 times, but what does reasonably
• 9:16
  practicable actually mean to a working engineer?
• 9:19
  It means that if your risk is in this tolerable zone, you still
• 9:22
  have a duty to reduce it further.
• 9:24
  You have to keep pushing it down unless the cost of the next
• 9:27
  safety improvement is grossly disproportionate to the safety
• 9:30
  benefit you'd get. So you have to do an economic
• 9:32
  justification for not making it safer.
• 9:33
  Precisely. You have to prove that spending,
• 9:36
  say £1,000,000 to get a tiny, almost immeasurable safety
• 9:40
  benefit just isn't a reasonable use of resources.
• 9:43
  But the burden of proof is on the engineer.
• 9:45
  And engineers translate these abstract principles into actual
• 9:49
  design targets using safety integrity levels right S.
• 9:53
  Isles are absolutely paramount in any high hazard industry.
• 9:57
  They run from SIO one, which is the least stringent, all the way
• 10:00
  up to SIO 4, the most stringent. They give you a quantitative
• 10:03
  target for the reliability of any safety system, like an
• 10:06
  emergency shutdown. And how demanding are we talking
• 10:09
  for something like a CSO 4 system?
• 10:11
  We're talking almost unbelievable numbers for a
• 10:14
  system that's in high demand, meaning it's always operating.
• 10:17
  SIO 4 requires a dangerous failure rate of between 10 to
• 10:21
  the power of -9 and 10 to the power of -8 failures per hour.
• 10:25
  So a one in a billion chance of failure per hour, that's that's
• 10:32
  a level of certainty that demands absolute rigor in
• 10:34
  everything, design, components, analysis, everything.
• 10:38
  It does. And you know, you mentioned
• 10:40
  something earlier that trips a lot of people up.
• 10:42
  The difference between failures per hour, which is a rate, and
• 10:46
  probability of failure on demand, which is a dimensionless
• 10:49
  number. Oh, we got two different
• 10:50
  metrics. It really depends on how the
• 10:52
  system is used. For that high demand system,
• 10:54
  like the car brakes we talked about, it needs to work
• 10:57
  constantly, so we care about its failure rate.
• 10:59
  But for a low demand system, think of a fire suppression
• 11:02
  system. It might sit there doing nothing
• 11:04
  for years. We don't care about its failure
• 11:06
  rate per hour. We care about one thing, the
• 11:10
  probability it will fail. On the one occasion we actually
• 11:12
  demand it to work, that's probability of failure.
• 11:15
  On demand, it's unavailability. That clarifies it perfectly.
• 11:19
  Yeah. OK, let's get to the final
• 11:20
  financial justification. How do you convince the board to
• 11:23
  spend £1,000,000 on a safety upgrade?
• 11:25
  You have to speak their language and that means using a metric
• 11:28
  called Cost per life saved or CPLS.
• 11:32
  Now this is controversial. You're putting a price on a
• 11:35
  human life. Well, yes and no.
• 11:37
  It's controversial, but engineers use it not to set an
• 11:40
  absolute value on life, but to rank different safety rojects.
• 11:45
  If you have a limited budget, it helps you decide where to spend
• 11:48
  it to get the most protective benefit.
• 11:50
  So you're not saying a life is worth X amount, you're saying
• 11:53
  project A saves life for X amount and project B saves a
• 11:56
  life for Y amount, so we should do the more efficient one first.
• 11:59
  Exactly, it's a ranking tool. Take the motor car braking
• 12:02
  system example. OK.
• 12:03
  Leave out the numbers. Let's say a braking system
• 12:05
  upgrade costs £40 per car. The manufacturer makes 2 million
• 12:09
  cars a year and your QRA predicts this upgrade will save
• 12:13
  500 lives annually in the UK. OK, the CPLS calculation is £40
• 12:19
  * 2 million cars divided by 500 lives saved.
• 12:23
  So that's £80 million / 500, which is 160,000 lbs. £160,000
• 12:30
  per life saved. That number now becomes your
• 12:33
  benchmark. You can use it to justify the
• 12:35
  expenditure to management and regulators.
• 12:38
  It translates a safety measure into a concrete financial
• 12:41
  figure. And that is a perfect
• 12:42
  transition. We've proven the safety case.
• 12:45
  We've justified the initial cost, but that's just year one.
• 12:49
  What happens over the next 20 years?
• 12:52
  This brings us right to our second pillar post failure
• 12:55
  investigations that actually teach something.
• 12:57
  Right, because even the best design systems will eventually
• 13:01
  fail. The key is turning those
• 13:03
  failures into actual knowledge. And to do that, you first have
• 13:06
  to understand where on the reliability life cycle the
• 13:09
  failure happened. We're talking about the famous
• 13:11
  bathtub curve. The bathtub curve is
• 13:13
  fundamental. It charts the failure rate of a
• 13:15
  component over its operating life and it shows 3 really
• 13:19
  distinct phases. The first phase is a high but
• 13:22
  decreasing failure rate. That's infant mortality.
• 13:25
  These are failures that happen right at the beginning of a
• 13:27
  component's life, and they're almost always caused by
• 13:30
  manufacturing defects. So things like bad welds,
• 13:32
  cracks, maybe just incorrect installation.
• 13:35
  Exactly. Substandard items that were
• 13:37
  flawed from day one. The solution here isn't a design
• 13:41
  change, it's better quality control in your supply chain,
• 13:44
  burn in testing, better screening.
• 13:46
  Then the curve flattens out in the middle.
• 13:49
  That's the period of random failures.
• 13:51
  The failure rate is constant. These are the failures we assume
• 13:54
  are caused by random stress events in the environment, a
• 13:57
  power surge of operation that just happens to exceed the
• 14:01
  component's strength. And this constant rate, that's
• 14:04
  what we typically call the design reliability.
• 14:05
  That's the number you're aiming for in your initial QRA models,
• 14:09
  and since these are truly random, the best defense is
• 14:12
  redundancy. OK.
• 14:13
  And then as the component gets old, the failure rate starts to
• 14:16
  climb again sharply. That's the wear out phase.
• 14:19
  This is predictable aging, corrosion, fatigue, friction,
• 14:22
  where things are just getting old and breaking down.
• 14:25
  And if you know a component has a wear out life, the goal is to
• 14:28
  replace it before it hits that steep upward curve.
• 14:30
  That's the entire basis of preventative maintenance.
• 14:34
  So understanding which of those three regions your failure came
• 14:36
  from is the absolute first step in any real root claims
• 14:40
  analysis. So even before we have failures,
• 14:43
  how do we systematically think through what could go wrong?
• 14:47
  That's where you use a failure mode and effect analysis or
• 14:50
  FMEA. It's a bottom up process where
• 14:52
  you look at every single component in a system and ask
• 14:55
  how can this part fail and what is the effect on the overall
• 14:58
  system if it does. So you're tracing how a single
• 15:01
  resistor failing open could lead to a total loss of communication
• 15:05
  for the entire system. Precisely, And there's a really
• 15:08
  important nuance here. If you just add up the failure
• 15:11
  rates of every single part the parts count total.
• 15:14
  That number will always be higher than the failure rate for
• 15:17
  a specific system failure mode you're analyzing.
• 15:20
  Wait, why is that? That seems counterintuitive.
• 15:22
  Because not every component failure matters to the function
• 15:26
  you're looking at. A light bulb on a control panel
• 15:28
  might burnout, but if it doesn't trigger the emergency shutdown,
• 15:31
  it's a component failure. But it's not a system failure
• 15:33
  for that shutdown function. FMEA helps you focus only on the
• 15:37
  failures that actually have a dangerous effect.
• 15:39
  OK, so now we have all this failure data coming in from the
• 15:42
  field, Hundreds of defect reports.
• 15:45
  How do you decide what to fix first?
• 15:48
  Where do you focus your limited resources?
• 15:51
  You use Pareto analysis, the old 8020 rule, and while it's useful
• 15:55
  to rank defects by how often they happen.
• 15:57
  There's a better way. There's a much more powerful way
• 16:00
  you rank them by their total cost contribution.
• 16:03
  So you focus on the most expensive problems, not just the
• 16:05
  most frequent. Ones it gives you incredible
• 16:07
  financial leverage. You might have, say, a fault in
• 16:10
  a mechanical transporter that only happened 4 times low
• 16:12
  frequency, but each repair was so expensive that it accounted
• 16:16
  for 22% of your total failure costs for the quarter.
• 16:20
  Meanwhile, you might have a printed board fault that
• 16:21
  happened 15 times. Right, very frequent, but maybe
• 16:25
  each fix was cheap. So even though it happened a
• 16:28
  lot, it only made-up, say, 35% of the total cost.
• 16:31
  By fixing that one printed board issue, you eliminate over a
• 16:35
  third of your entire failure budget.
• 16:37
  You get the biggest bang for your buck.
• 16:39
  Exactly. You focus your investment where
• 16:41
  it has the greatest economic impact.
• 16:43
  Of course, all of this analysis relies on getting good data from
• 16:46
  the field. The old saying garbage in,
• 16:49
  garbage out must be especially true here.
• 16:52
  It's the absolute truth. You need incredibly detailed,
• 16:55
  specific information on your failure report forms.
• 16:58
  What's on that essential checklist?
• 17:00
  You need to track repair time, both active and passive.
• 17:04
  The exact fault type. Was it random?
• 17:06
  Was it induced by a person? Was it a primary failure or a
• 17:09
  secondary 1? You need the nature of the
• 17:12
  fault, wearout drift, a design flaw, and you need the exact
• 17:17
  location and the environmental conditions at the time.
• 17:20
  I imagine tracking time consistently it's a huge
• 17:22
  challenge, especially for those wear out parts.
• 17:25
  It's a non negotiable nightmare. You have to be totally
• 17:27
  consistent about using calendar time versus actual operating
• 17:30
  time. For a pump that only runs 8
• 17:32
  hours a day, it's wear out. Life is measured in operating
• 17:35
  hours, not days on the calendar. And this is where unique tag
• 17:38
  numbers for each component become critical.
• 17:41
  Absolutely. The tag number is the
• 17:42
  component's birth certificate and medical history.
• 17:46
  If a valve body has been there for five years, but you replaced
• 17:49
  its internal diaphragm last year, the time to failure clock
• 17:53
  for the diaphragm started one year ago.
• 17:55
  For the valve body, it's five years.
• 17:58
  Without that level of tracking, your wear out data is completely
• 18:01
  useless. What are the common pitfalls you
• 18:04
  see that lead to companies collecting this kind of
• 18:07
  misleading data? There are two big ones that
• 18:10
  corrupt data all the time. The 1st is recording non
• 18:13
  failures. Recording non failures.
• 18:14
  How does that happen? It happens during
• 18:16
  troubleshooting. A technician is trying to find a
• 18:19
  fault, so they start swapping out parts one by one.
• 18:22
  They replace board A, still broken.
• 18:24
  They replace board B, still broken.
• 18:26
  They replace board C and it works.
• 18:28
  The problem is, often boards A&B get logged as failures even
• 18:32
  though they were perfectly fine. So you're inflating the failure
• 18:35
  rates for good components? And you're burning through your
• 18:37
  spares inventory for no reason. The second big issue is
• 18:41
  confusing a secondary failure with a primary.
• 18:43
  One explain that. A primary failure, say a power
• 18:46
  supply failing, might send a huge voltage spike that fries a
• 18:50
  downstream circuit board. That fried board is a secondary
• 18:54
  failure. It's a victim.
• 18:56
  If the technician just replaces the board without finding the
• 18:59
  root cause in the power supply, it gets log as a primary failure
• 19:03
  for the board. And all your data now points to
• 19:05
  the wrong problem. You end up spending a fortune
• 19:08
  trying to make a more robust circuit board when the real
• 19:11
  problem was the cheap power supply all along.
• 19:13
  It's so clear that reliability has become less about perfect
• 19:16
  hardware and more about perfect information systems analysis.
• 19:21
  Which brings us to the third, and maybe the most uncomfortable
• 19:24
  pillar, human error and operational risk.
• 19:27
  Yeah, this is where it gets really complicated.
• 19:29
  The whole paradigm of system failure has shifted.
• 19:32
  For a modern complex system with lots of redundancy and controls,
• 19:36
  failure is no longer dominated by random hardware breaking.
• 19:39
  It's. Become a system problem.
• 19:40
  It's overwhelmingly a system problem, and it's dominated by
• 19:43
  software, by the environment, by common mode failures, and most
• 19:47
  of all by human factors. So the weakest link isn't the
• 19:50
  steel anymore, it's the person operating the system or the
• 19:53
  person who maintained it last week.
• 19:55
  And history proves this over and over.
• 19:57
  Major industrial disasters? They rarely happen because a
• 20:00
  single piece of equipment failed on its own.
• 20:03
  There's always a human element. There was always a significant
• 20:05
  human factor in the chain of events.
• 20:07
  Look at Flixborough in 74 or Piper Alpha in 88.
• 20:12
  The initial hardware failure in those cases was often
• 20:15
  manageable. It was the series of procedural
• 20:18
  mistakes, organizational failures and human decisions
• 20:22
  that cascaded it into a catastrophe.
• 20:24
  And the regulators have learned this lesson, right?
• 20:26
  This is mandatory now. It is Regulatory bodies now
• 20:29
  require that hazard assessments must specifically analyze the
• 20:32
  role of human error. It's not an option anymore.
• 20:35
  This means Human Reliability analysis HRA is a required part
• 20:39
  of a safety case for any major facility.
• 20:42
  But that's the real challenge. How do you quantify human
• 20:44
  behavior? How do you put a number on the
• 20:46
  probability of a person making a mistake?
• 20:48
  You use specialized HRA models. They try to estimate human error
• 20:52
  rates by looking at things like stress training and the
• 20:56
  complexity of the task. One of the most common and
• 20:59
  detailed methods is called heart.
• 21:01
  Heart, The human error assessment and reduction
• 21:03
  technique. How does it work?
• 21:04
  So heart starts by giving a task a baseline error probability
• 21:09
  based on its type. For example, a totally
• 21:12
  unfamiliar task performed at speed, high stress, very high
• 21:16
  stress that might get a baseline error probability of say 0.55, a
• 21:21
  55% chance of error. And on the other end, a routine,
• 21:25
  highly practiced, rapid task might have a baseline
• 21:28
  probability of just 0.0 to a 2% chance.
• 21:32
  So that's the starting point, but then you have to account for
• 21:35
  the real world, the time pressure, the confusing
• 21:37
  instructions, the poor lighting. Right.
• 21:39
  And that's the next step. You take that base rate and you
• 21:42
  modify it using up to 38 different error producing
• 21:45
  conditions or EPC's. And these EPC's each have a
• 21:48
  multiplier that increases the chance of an error.
• 21:50
  And some of those multipliers are huge.
• 21:52
  For example, unfamiliarity with the critical situation can
• 21:56
  multiply the base error rate by a factor of 1717.
• 22:00
  A shortage of time for error detection and correction has a
• 22:03
  multiplier of up to 11. Even something that sounds soft,
• 22:06
  like a low awareness of risk, can multiply the probability by
• 22:10
  4. So if management is rushing a
• 22:12
  critical job, they are mathematically increasing the
• 22:16
  risk of a catastrophic human error by a factor of 11.
• 22:19
  That's the risk penalty. They are choosing to pay for
• 22:22
  speed. Now, the trickiest part of heart
• 22:24
  is how the analyst applies these factors.
• 22:27
  It involves judgement. So how do you make that
• 22:29
  judgement auditable? The analyst has to assign a
• 22:32
  proportion of the effect for each EPCA number between zero
• 22:35
  and one. So if the maximum multiplier for
• 22:38
  inexperience is 3, and the analyst judges the situation is
• 22:42
  about 40% of that worst case inexperience, they use a formula
• 22:46
  to calculate a final factor of say 1.8.
• 22:48
  So that specific level of inexperience increases the error
• 22:51
  chance by 80%, and you do this for all the relevant conditions.
• 22:55
  Exactly. You multiply the baseline
• 22:57
  probability by all the calculated factors for all the
• 23:00
  relevant EPC's to get your final human error probability.
• 23:04
  It provides A documented quantitative trail for what is
• 23:07
  at its heart, a judgment based assessment.
• 23:10
  One of the biggest fears with human error is that it can
• 23:13
  defeat all the clever redundancy you've designed in a single
• 23:17
  mistake can take out both systems.
• 23:19
  That's common cause failure CCF. It's a huge organizational risk.
• 23:23
  You have two redundant pumps, but the technician miscalibrates
• 23:26
  the sensors on both of them in the exact same wrong way.
• 23:29
  Your redundancy is now worthless.
• 23:32
  So how do we defend against that?
• 23:33
  It comes down to two things, procedures and design.
• 23:37
  Carefully written, properly followed procedures are your
• 23:39
  best defense. They optimize the sequence of
• 23:41
  actions and prevent people from skipping critical steps.
• 23:44
  They reduce the cognitive load on the person doing the work.
• 23:46
  Exactly. And the second defense is
• 23:48
  designing for maintainability. The physical layout of your
• 23:51
  equipment has a fundamental impact on the likelihood of a
• 23:54
  human making a mistake while working on it.
• 23:56
  You're talking about things like just being able to reach a bolt
• 23:59
  easily. Yes.
• 24:00
  Engineers use a formal maintainability checklist.
• 24:04
  It asks questions like, is there adequate physical access for a
• 24:08
  person to see what they're doing?
• 24:10
  Is there room for their hands and tools?
• 24:12
  If the answer is no, the chance of error goes way up.
• 24:15
  And things like standardizing fasteners so you don't need a
• 24:18
  dozen special tools just to open a panel.
• 24:20
  Or needing supplementary materials.
• 24:22
  If a routine maintenance task requires a special jig or ladder
• 24:26
  or a scaffold, that's a red flag.
• 24:28
  It's a sign of poor design for maintaining and it increases the
• 24:32
  time, the complexity and therefore the risk of that task.
• 24:35
  You have to design for the reality of human interaction.
• 24:38
  This really forces a holistic view.
• 24:40
  The design isn't finished until you've considered how it will be
• 24:43
  taken apart and put back together in the real world.
• 24:46
  This connects perfectly to our final pillar, designing for the
• 24:49
  full life cycle, not just startup.
• 24:51
  Right, because when an engineering team focuses only on
• 24:54
  minimizing the upfront purchase price, they're almost
• 24:57
  guaranteeing long term financial pain for their company.
• 25:00
  The real number that matters is the life cycle cost the LCC.
• 25:03
  The LCC, it's every single penny you will spend on that asset
• 25:08
  over its entire life, which could be 30 or 40 years, and it
• 25:12
  breaks down into 4 main categories.
• 25:14
  OK, what are they? 1st is the obvious one,
• 25:16
  Acquisition cost, the capital, the installation transport.
• 25:21
  The sticker price. The sticker price.
• 25:22
  Second is ownership cost. This is all your maintenance,
• 25:26
  preventive, corrective and any modifications you have to make.
• 25:29
  Third is operating cost, your energy, your materials.
• 25:33
  And 4th, and this is the one people often forget, is
• 25:36
  administration cost. Administration cost, what falls
• 25:39
  under that? It's all the data collection,
• 25:41
  the record keeping, the documentation, the software
• 25:43
  licenses you need to manage the asset.
• 25:45
  If you don't track the assets history, you can't manage its
• 25:48
  life cycle cost effectively. And this is where those abstract
• 25:51
  design qualities, reliability and maintainability, have a
• 25:55
  direct and massive financial impact over decades.
• 25:57
  It's the key leverage point for a designer.
• 26:00
  Reliability directly determines how often you have to do
• 26:03
  repairs, which sets your spares inventory if you pick an
• 26:06
  unreliable component because it was cheap.
• 26:08
  You're signing up for decades of expensive, unplanned repair.
• 26:12
  You are, and maintainability dictates your training costs,
• 26:16
  your test equipment costs, your manpower needs, and most
• 26:19
  importantly, your downtime. Downtime is lost revenue and it
• 26:24
  can easily become the single biggest driver of your life
• 26:27
  cycle cost. The overall cost of
• 26:29
  unreliability is just staggering when you look at it this way.
• 26:33
  The historical data is genuinely alarming.
• 26:36
  In the UK back in the 90's the total cost of poor quality was
• 26:39
  estimated to be 150 thousand 1,000,000 lbs.
• 26:43
  Failure costs alone were eating up 4 to 15% of a companies total
• 26:47
  turnover. 15% of revenue just wasted on things breaking.
• 26:52
  Wasted. And here's the crazy part.
• 26:54
  The amount spent on prevention, on quality engineering, on
• 26:57
  better design verification, on stopping the failures before
• 27:00
  they happened, was only about 1% of that total quality cost.
• 27:04
  It's a massive strategic imbalance.
• 27:05
  You're spending all your money cleaning up messes instead of
• 27:08
  preventing them. The financial leverage for
• 27:10
  designing it right the first time is immense.
• 27:13
  And failure costs aren't just the obvious repair bill.
• 27:16
  It's the cost of late stage design changes, of rejecting
• 27:20
  defective parts from vendors, of scrap of warranty claims and all
• 27:24
  those untracked hours spent fault finding during
• 27:27
  commissioning. So when a design team is looking
• 27:29
  at two options, a cheap pump and a more expensive robust 1, how
• 27:35
  do they make the final call? They need a formula that
• 27:38
  accounts for all of this. They do, and that formula is
• 27:40
  based on the Net Present Value or NPV method.
• 27:44
  It calculates the total lifetime cost of each option in today's
• 27:48
  money. OK, so let's break down that
• 27:49
  calculation conceptually for our listener.
• 27:51
  Conceptually, the NTV for a component has four big blocks.
• 27:55
  Block 1 is easy. It's the initial installed cost,
• 27:57
  what you pay today, what you pay today.
• 27:59
  Block 2 is the present value of all your future planned
• 28:02
  inspection costs. Block 3 is the present value of
• 28:05
  all your future maintenance costs, both planned and
• 28:08
  crucially, unplanned corrective maintenance.
• 28:10
  And that's where the components reliability number feeds
• 28:12
  directly into the financial calculation.
• 28:14
  It does. And then there's the final, most
• 28:17
  important block. Block 4 is the present value of
• 28:20
  the expected consequences of failure.
• 28:22
  So you're multiplying the probability of a catastrophic
• 28:25
  failure by the massive cost of that failure, the downtime, the
• 28:29
  environmental cleanup, the potential loss of life, and
• 28:33
  adding that risk cost into your purchasing decision today.
• 28:36
  You are mathematically pricing risk into your component
• 28:39
  selection, and this framework gives you that critical design
• 28:43
  insight. Oh so.
• 28:44
  If a component is in high use, high stress service, those
• 28:47
  maintenance and failure consequence terms, blocks three
• 28:50
  and four are going to be huge. They will easily justify
• 28:53
  spending more upfront on a super reliable component.
• 28:56
  You pay more now to avoid paying much, much more later.
• 28:59
  But if the component is in modest low stress use, the
• 29:02
  initial cost block 1 is going to dominate the equation.
• 29:05
  And in that case, spending a fortune on a gold plated
• 29:07
  component you barely use just doesn't make financial sense.
• 29:10
  It moves the decision from a subjective argument to an
• 29:13
  actuarial calculation. We've really covered the full
• 29:16
  spectrum from the physics of failure to the psychology of
• 29:19
  human error, all the way to the long term economics of design.
• 29:22
  We have, and this deep dive really confirms that modern
• 29:25
  engineering is about numerical accountability.
• 29:28
  We started with risk quantification using QRA and
• 29:31
  sales to back up our safety decisions with real data.
• 29:35
  We then showed the absolute fiscal necessity of reliability
• 29:38
  through the life cycle cost model.
• 29:40
  And we learned how to turn our mistakes into real knowledge
• 29:42
  using the bathtub curve to understand the failure time and
• 29:45
  cost focused Pareto analysis to make sure we're fixing the most
• 29:49
  important problems first. And finally, we confronted the
• 29:52
  critical need to integrate human error into our models with tools
• 29:55
  like Heart, recognizing that procedures and maintainability
• 29:58
  design are just as important as the hardware itself.
• 30:01
  All these methods give you, the engineer, the tools to move
• 30:04
  beyond opinion and gut feeling. It changes your role really.
• 30:08
  You're not just a technician anymore, you're a strategic
• 30:10
  partner who can articulate long term value and risk in the
• 30:14
  language that management understands numbers.
• 30:17
  That is your greatest advantage. So we want to leave you with one
• 30:20
  final provocative thought to chew on something that builds on
• 30:23
  everything we've talked about. OK, let's hear it.
• 30:25
  Given the fact that the majority of serious software errors and
• 30:28
  design faults actually originate right at the very beginning at
• 30:32
  the requirement specification stage, and given that the cost
• 30:35
  to fix them grows exponentially the longer they're in the
• 30:38
  system, how much more competitive would your company
• 30:42
  be if the time and money currently spent on field
• 30:44
  corrections and warranty work were redirected into
• 30:47
  implementing formal verification methods right at the absolute
• 30:51
  earliest stage of every project, even when the scope is still
• 30:55
  being defined? A massive upfront investment in
• 30:58
  getting it right to avoid a decade of paying to fix it when
• 31:01
  it's wrong. A lot to think about there.
• 31:04
  Thank you for joining us for this deep dive.
• 31:05
  If you found this useful, please hit that like and subscribe
• 31:08
  button. Let's keep leveling up together.