Latest / Mechanical Engineering Made Simple / (#33) The Great Translation: Mastering the Flow-Down of Critical Parameters

Transcript

(#33) The Great Translation: Mastering the Flow-Down of Critical Parameters · Mechanical Engineering Made Simple

• 0:00
  Welcome back, design junkies, to Mechanical Engineering Made
• 0:02
  Simple. We are diving into what I often
• 0:04
  call the great translation problem.
• 0:07
  You know, how do you take a genuinely vague, maybe hopeful
• 0:11
  customer wish and reliably translate it into a physical
• 0:15
  product that actually works, can be manufactured affordably, and
• 0:20
  crucially, won't fail catastrophically like a year
• 0:24
  down the road? Right.
• 0:25
  And that whole process, that's really the hardest systems
• 0:28
  engineering, isn't it? And today, our mission is really
• 0:31
  synthesizing best practices. We're not just talking about
• 0:33
  brainstorming here, but proven quantitative frameworks that
• 0:38
  actively minimize design risk, things that help avoid those
• 0:42
  structural flaws early on. We're basically building a
• 0:44
  foundational road map. OK, a road map.
• 0:46
  So it sounds like we're focusing on three big pillars that guide
• 0:49
  this whole translation effort. First.
• 0:50
  Sounds like creating really airtight requirements.
• 0:53
  Absolutely fundamental. 2nd, structuring the solution using.
• 0:55
  Well, you mentioned powerful frameworks like axiomatic
• 0:58
  design. Yep, that's key for managing
• 0:59
  complexity. And finally, applying something
• 1:01
  called Critical Parameter Management or CPM to make sure
• 1:05
  that initial robustness survives the the chaos of manufacturing.
• 1:10
  Exactly. So let's start right at the
• 1:12
  absolute beginning, because honestly, if you mess up here.
• 1:16
  The rest is just damage control. Pretty much, let's talk
• 1:19
  requirements. OK, defining requirements
• 1:21
  foundational. It feels like if your input here
• 1:24
  is fuzzy, your output is almost guaranteed to be shaky, right?
• 1:28
  These requirements, they need to capture the voice of the
• 1:30
  customer, which I guess usually comes out of a solid stakeholder
• 1:33
  analysis. That's the ideal starting point,
• 1:36
  and you need clear, effective requirements.
• 1:38
  So I want you listening right now to think, do your current
• 1:43
  requirements really meet these kinds of high level standards
• 1:46
  we're about to discuss? Well, they absolutely must meet
• 1:50
  several non negotiable attributes.
• 1:52
  OK, first functionally they have to be verifiable.
• 1:55
  That means you can actually prove, maybe through a test or
• 1:57
  some independent calculation, that you met the goal.
• 2:00
  OK, verifiable, Testable makes sense.
• 2:03
  And they must be attainable. This just speaks to technical
• 2:07
  feasibility. Is it actually possible within
• 2:10
  the project scope? The budget?
• 2:11
  The timeline. Right.
• 2:13
  And beyond just function, the clarity aspect is huge, isn't
• 2:16
  it? Oh absolutely.
• 2:17
  They need to be concise, you know, short and to the point and
• 2:22
  unambiguous. Everyone needs to read it and
• 2:23
  understand the same thing. But maybe the single most common
• 2:27
  failure point we see, especially in early stage design, it's
• 2:30
  violating the rule that requirements must be solution
• 2:32
  neutral. The classic what not how
• 2:35
  principle. Easy to say, hard to do.
• 2:38
  Incredibly hard. Sometimes people naturally jump
• 2:41
  to solutions. If your requirement specifies,
• 2:43
  say, the diameter of a shaft or the material for a casing.
• 2:47
  You've started dictating the how.
• 2:48
  You haven't defined what the system needs to achieve.
• 2:51
  You basically killed off potential innovation before the
• 2:53
  designer even, you know, do the first line.
• 2:56
  That's a really critical distinction, confusing the need
• 2:58
  for some component with the actual functional requirement of
• 3:01
  the whole system. That seems like the root of so
• 3:03
  many early unnecessary constraints.
• 3:06
  Exactly right, and the language, the semantics you use carries
• 3:10
  that weight. This is where we talk about
• 3:11
  commitment. You absolutely must use the word
• 3:14
  shall for those quantifiable requirements, the things the
• 3:18
  system is contractually obligated to meet.
• 3:20
  OK, give me an example. Like the system shall weigh less
• 3:23
  than 3 kilograms or the system shall provide a torque of at
• 3:28
  least 10 Newton meters. See Quantifiable.
• 3:31
  Verifiable. Got it.
• 3:32
  So if I see shall in a spec, I know that needs a test, a
• 3:36
  number, some kind of proof. What about other verbs like will
• 3:39
  or should? Good question.
• 3:41
  If you're just setting the stage, maybe making a statement
• 3:43
  of fact about the context, perhaps describing an operating
• 3:47
  scenario or the environment you use will think like the aircraft
• 3:51
  will fly it and now to do the 30,000 feet.
• 3:53
  That's context, not a requirement on the system being
• 3:55
  designed. OK.
• 3:56
  Context versus requirement and should when does that fit in?
• 3:59
  You use should really only for design goals or maybe desired
• 4:03
  attributes where you just can't apply a strict, quantifiable,
• 4:07
  verifiable metric. It signals a preference, not a
• 4:10
  mandate. Getting that hierarchy right,
• 4:12
  shall, will, should, is absolutely essential for
• 4:15
  traceability, for verification, and for defining a solid product
• 4:19
  baseline. OK, so let's say we've done it.
• 4:21
  We have these crisp solution neutral requirements shall
• 4:25
  statements lockdown. Now we face that massive
• 4:28
  challenge translating those abstract what's into a physical
• 4:32
  system, the how. And this is where complexity
• 4:34
  just explodes, isn't it? We need some kind of framework
• 4:37
  like axiomatic design you mentioned to manage the chaos.
• 4:40
  Exactly. Axiomatic design provides a
• 4:42
  structure. It helps map the customer wishes
• 4:44
  which live in the customer domain through the functional
• 4:47
  domain what the system must do, then into the physical domain
• 4:50
  how it does it, and finally the process domain how you actually
• 4:53
  make it. For this discussion, let's focus
• 4:55
  on that link between functional and physical.
• 4:57
  Right. We're focusing on mapping the
• 4:59
  functional requirements, let's call them FRS, the what's to the
• 5:02
  dine parameters or DPS the house.
• 5:04
  So the Fr might be the system needs to stop the car, and the
• 5:08
  DPS would be things like the diameter of the brake rotor, the
• 5:10
  material grade of the brake pads, the hydraulic pressure.
• 5:13
  OK, far as map to DPS and this relationship, you call it the
• 5:16
  design matrix and it's governed by two big rules or axioms.
• 5:20
  Axiom 1 feels like the really critical one for structure.
• 5:23
  It absolutely is. Axiom 1 is the independence
• 5:25
  axiom. The fundamental goal here is to
• 5:28
  maintain the independence of your functional requirements.
• 5:31
  Basically, you want to avoid a situation where changing one
• 5:34
  physical thing, ADP, unintentionally messes up
• 5:37
  multiple functions F Rs. Because if you link them all up
• 5:41
  in a complex, tangled way. You've doomed yourself to what
• 5:44
  we sometimes call iterative hell.
• 5:46
  Iterative hell, that sounds expensive and frustrating.
• 5:49
  It's the guaranteed path to it, because fixing one problem
• 5:53
  inevitably breaks three other things.
• 5:55
  It's endless cycles of redesign. So we strive for what's called
• 5:59
  an uncoupled design. That's the ideal.
• 6:01
  It's where each Fr is controlled by only one unique DP.
• 6:05
  Think of a diagonal design matrix.
• 6:07
  Clean separation. One knob controls one function.
• 6:11
  Simple. Exactly.
• 6:12
  Now, if that's completely impossible, which it sometimes
• 6:15
  is in complex systems, we aim for the next best thing, a
• 6:19
  decoupled design. This is like a triangular
• 6:21
  matrix. Changes might still ripple, but
• 6:23
  they only flow one way. You can adjust things in a
• 6:25
  specific sequence without iterating endlessly.
• 6:27
  OK, so uncoupled is best, decoupled is manageable.
• 6:30
  What's the bad? One, the bad 1 is a coupled
• 6:32
  design. That's where changing a single
• 6:34
  physical parameter, a single DP, effects multiple functional
• 6:37
  requirements, multiple FRS simultaneously, and often
• 6:40
  unpredictably. But hang on, you mentioned
• 6:42
  complex systems. If axiomatic design demands this
• 6:44
  perfectly uncoupled diagonal matrix, isn't that sometimes
• 6:48
  just a fantasy? How do we actually use this when
• 6:50
  reality forces some coupling? That's the brilliance of the
• 6:54
  framework. It doesn't just demand
• 6:56
  perfection, it forces you to recognize and manage the
• 6:59
  coupling you have. Take a simple example like a
• 7:02
  refrigerator door. You have one key design
• 7:05
  parameter. Let's say that doors insulation
• 7:07
  thickness and seal quality. This single DP effects
• 7:11
  functional requirement 1, which might be provide reasonable
• 7:14
  access to the food and it affects functional requirement
• 7:17
  to minimize energy loss. They're coupled.
• 7:20
  Right. Make the insulation thicker for
• 7:21
  better energy efficiency. And you might make the door
• 7:24
  bulky, harder to open, reducing accessibility.
• 7:27
  You see the conflict. An uncoupled or decoupled
• 7:30
  approach would try to find separate DPS to control those
• 7:33
  FRS independently if possible. Maybe different seal mechanism
• 7:36
  or vacuum insulation panels. Something.
• 7:39
  Even if you can't fully uncouple it, the framework highlights the
• 7:42
  trade off. It acts as a goal post,
• 7:44
  constantly pushing you towards a simpler, more independent
• 7:47
  architecture. It makes the coupling explicit.
• 7:50
  OK, that structural clarity seems invaluable.
• 7:52
  It makes optimizing things later way more achievable.
• 7:55
  So axiom 1 is all about structural purity independence.
• 7:58
  What about axiom 2? That sounded more mathematical.
• 8:01
  It is. Axiom 2 is the information axiom
• 8:04
  and the goal here is, surprisingly to minimize the
• 8:07
  designs information content. Minimize information?
• 8:09
  That sounds counterintuitive. Don't we want more information?
• 8:13
  Not. In this sense, here information
• 8:15
  released to uncertainty. The more complex and uncertain a
• 8:18
  design is, the more information you need to specify it fully and
• 8:21
  guarantee you meets the requirements, the less likely it
• 8:23
  is to actually succeed. If we look at the formula, the
• 8:26
  system information content, let's call it I subsist, it's
• 8:30
  inversely related to P sub M, which is the probability of
• 8:33
  meeting all the functional requirements.
• 8:35
  Mathematically, it's often written as I subsist equals
• 8:37
  minus the sun from I equals one to M of log base 2 of P sub I or
• 8:41
  simply I subsist equals minus log base 2 of P sub M.
• 8:45
  OK, so maximizing the probability of success P sub M
• 8:48
  means minimizing the information content I subsist.
• 8:51
  Precisely a design where you have higher certainty about its
• 8:55
  performance, where the ranges are well controlled, it
• 8:58
  inherently has lower information content in this axiomatic sense,
• 9:02
  and it's mathematically considered a superior design.
• 9:05
  All right, we've navigated the requirements.
• 9:06
  We've used axiomatic design to create a potentially brilliant,
• 9:09
  maybe even uncoupled conceptual design.
• 9:13
  Now comes the hard part, moving from that concept to execution,
• 9:18
  subjecting our idea to the harsh realities of detailed design,
• 9:22
  manufacturing tolerances, the shot floor.
• 9:25
  This sounds like where we need that third pillar, critical
• 9:27
  Arameter management or CM to sort of protect our initial
• 9:31
  genius. That's a great way to put it.
• 9:33
  CPM is all about maintaining the system's robustness, its ability
• 9:36
  to function correctly despite variations throughout its entire
• 9:40
  life cycle. The goal is to make sure that
• 9:42
  those optimized values for the critical design parameters, the
• 9:44
  DPS we identified earlier, are actually sustained, that they
• 9:48
  flow down correctly and are used to set the right manufacturing
• 9:51
  precision levels, the ones that ultimately guarantee customer
• 9:54
  satisfaction. And you mentioned a key tool
• 9:56
  here, some kind of drawing. Yes, the critical parameter
• 9:59
  drawing. Think of it as a special
• 10:01
  document that highlights only those few parameters that are
• 10:05
  absolutely critical for the core function and robustness
• 10:08
  identified way back in concept selection.
• 10:10
  How does it act like a beacon as you put it earlier?
• 10:13
  What does it protect against? It protects against the natural
• 10:16
  tendency for detailed designers to get lost in the weeds.
• 10:20
  And I say that with respect. Their job is incredibly complex.
• 10:23
  They're focused on, you know, localized safety factors,
• 10:26
  specific manufacturing processes, minimizing the cost
• 10:29
  of this bracket, ensuring that component can be assembled
• 10:32
  easily. Right, lots of local
• 10:33
  optimizations. Exactly.
• 10:35
  And in that intense focus, it's incredibly easy to accidentally
• 10:39
  compromise one of those original critical functional
• 10:41
  requirements. Maybe it was ensuring a specific
• 10:44
  belt tension stays nominally at 15 newtons, plus or minus very
• 10:48
  little. The critical parameter drawing
• 10:50
  cuts through all that other noise.
• 10:51
  It keeps everyone's attention focused on those specific values
• 10:55
  that are essential for the robustness of the original
• 10:57
  technology. Choice.
• 10:58
  It says whatever else you do, don't mess this up.
• 11:01
  This whole issue balancing precision with cost, it feels
• 11:06
  like the foundational struggle of modern manufacturing going
• 11:09
  back centuries. You can trace this obsession
• 11:11
  with tolerances way back right late 18th century griebelval in
• 11:16
  France trying to get interchangeable musket parts.
• 11:18
  A dream only really realized much later by people like Henry
• 11:21
  Ford with his assembly lines and his intense focus on going to go
• 11:26
  gauging and tight tolerances. But that obsession just kept
• 11:29
  driving costs up, didn't it? Just making everything tighter
• 11:32
  and tighter. It did, until Doctor Walter
• 11:34
  Schuhart gave us the crucial insight we needed back in the
• 11:36
  1920s at Bell Labs. He realized through statistics
• 11:40
  that we must distinguish between two types of variation.
• 11:43
  There's the natural inherent variation in any process what we
• 11:46
  characterize using standard deviation Sigma.
• 11:49
  And then there's variation caused by specific assignable or
• 11:52
  special causes, a broken tool, a bad batch of material, etcetera.
• 11:55
  And that distinction is key. It's everything GR give us.
• 11:58
  Control charts, the tool to stop chasing ghosts, the inherent
• 12:01
  random variation, and focus our efforts only on fixing the real
• 12:04
  special cause problems. It fundamentally changed quality
• 12:07
  control. OK, so that statistical
• 12:09
  understanding leads directly to the core economic choice we face
• 12:13
  today. How tight should our tolerances
• 12:16
  actually be? Because making things more
• 12:18
  precise always cost more money to manufacture.
• 12:21
  Right. The optimal decision from an
• 12:23
  economic standpoint is the one that minimizes the total cost.
• 12:27
  And total cost is the sum of two things, the manufacturing
• 12:30
  process cost and the quality loss that occurs downstream due
• 12:34
  to variation from the target value.
• 12:36
  Quality loss, meaning failures, Customer dissatisfaction.
• 12:40
  Warranty costs. Exactly.
• 12:42
  And this brings us to the concept of three tiered
• 12:44
  tolerances, which is directly tied to Doctor Taguchi's quality
• 12:47
  loss function. Let's break that down
• 12:48
  conceptually, because this feels like where the real money is
• 12:51
  saved or lost in production. The key insight from Taguchi is
• 12:54
  that quality loss doesn't just suddenly appear when you hit a
• 12:58
  tolerance limit. It grows quadratically as you
• 13:00
  deviate from the ideal target value.
• 13:02
  Quadratically, meaning if you're twice as far from the target.
• 13:05
  The loss isn't just double, it's four times higher, three times
• 13:08
  the deviation, 9 times the loss. It ramps up fast.
• 13:12
  The expected quality loss, let's call it L, is proportional to
• 13:15
  the square of the deviation delta squared.
• 13:18
  So the basic relationship is L equals some constant times delta
• 13:22
  squared. OK, so how do the three
• 13:24
  tolerance tiers fit into this? Right.
• 13:27
  First you have the customer tolerance.
• 13:29
  Let's call it delta sub C This is the deviation point where the
• 13:32
  average customer becomes dissatisfied.
• 13:34
  Maybe the product feels noisy or it fails prematurely.
• 13:38
  Hitting or exceeding this incurs a massive quality loss L sub C
• 13:42
  Think expensive field costs, recalls, brand damage huge.
• 13:46
  Numbers Cliff, we absolutely want to avoid out in the.
• 13:49
  Field exactly. Now back in the factory, we have
• 13:51
  the manufacturing tolerance, Delta sub M.
• 13:53
  This must be much, much smaller than delta sub C Why?
• 13:56
  Because the cost of countermeasures inside the
• 13:58
  factory, let's call it L sub M, is vastly cheaper.
• 14:01
  We're talking about scrap rework, maybe sorting parts.
• 14:05
  Much less expensive than a field recall.
• 14:06
  So we set a tighter tolerance in the factory because fixing
• 14:09
  problems there is cheaper. How do we calculate how much
• 14:12
  tighter? We use the quality loss function
• 14:13
  to balance those costs. The full formula for expected
• 14:16
  loss is L = L sub C times the ratio of open parenthesis delta
• 14:20
  squared close parenthesis divided by open parenthesis
• 14:23
  delta sub C ^2 ) and define the optimal manufacturing tolerance
• 14:27
  delta sub M where the cost of fixing it in the factory L sub M
• 14:32
  equals the expected loss. If we shipped it, we calculated
• 14:34
  as delta sub M equals delta sub C * sqrt ( L sub M / L sub C ).
• 14:41
  OK, let me repeat that back slowly.
• 14:43
  Delta sub M equals delta sub C times the square root of the
• 14:47
  ratio of L sub M / L sub C. That's it.
• 14:50
  That formula gives you the rational economic boundary for
• 14:53
  your manufacturing tolerance. It tells you, based on the cost
• 14:56
  of failure in the field versus the cost of fixing it now,
• 14:58
  whether a part should ship or be reworked.
• 15:00
  It's pure economic optimization based on that quadratic loss.
• 15:03
  We've covered structural rigor with axiomatic design, economic
• 15:06
  control with CPM, and the quality loss function.
• 15:09
  But the whole process is still driven by human creativity,
• 15:12
  right? And increasingly by our reliance
• 15:15
  on really complex simulation tools.
• 15:18
  Computer aided engineering. CAE So how do we ensure our
• 15:22
  innovative thinking is actually effective?
• 15:24
  And maybe more importantly, how do we make sure we don't just
• 15:27
  blindly trust our complex computer models?
• 15:30
  Great questions. On the innovation front, it's
• 15:32
  useful to contrast conventional design thinking with approaches
• 15:35
  like Tiz that they're even inventive problem solving.
• 15:38
  Conventional thinking often defaults to finding a
• 15:40
  compromise, you know, balancing competing requirements.
• 15:44
  TRIZ, however, is guided by something called the Law of
• 15:47
  Ideality, which observes that technical systems tend to evolve
• 15:50
  towards being more reliable, simpler, more effective, more
• 15:53
  ideal over time. TRZ provides tools and
• 15:56
  principles to actively overcome technical contradictions without
• 15:59
  making those compromises. It's a different mindset.
• 16:02
  Aiming for the ideal, not just the acceptable, compromise.
• 16:05
  That philosophical shift seems powerful.
• 16:07
  It is, and that drive towards ideal solutions often pushes us
• 16:12
  towards heavy reliance on CAE, on simulation, for verification
• 16:17
  and optimization. Which brings us to your second
• 16:19
  question. Trusting the models because
• 16:21
  let's be honest, simulations can be wrong.
• 16:23
  They absolutely can be, and sources consistently point out
• 16:26
  that poor answers from simulations are frankly,
• 16:30
  tragically common. It could be bugs in the code, it
• 16:32
  could be physical effects the model doesn't even include, or
• 16:36
  just garbage and garbage out with inaccurate input data.
• 16:38
  So this raises a really critical question.
• 16:41
  When engineers are using these sophisticated models, maybe
• 16:44
  doing parameter design studies to optimize something, what's
• 16:47
  the best strategy not just for optimizing, but for actually
• 16:50
  detecting if the simulation itself is flawed?
• 16:53
  And the research on this yielded A fascinating and highly
• 16:56
  counterintuitive result. OK, I'm intrigued.
• 16:58
  What do they find? Well, a study was done comparing
• 17:01
  engineers using different strategies for parameter design,
• 17:05
  specifically looking at their ability to detect underlying
• 17:08
  flaws deliberately hidden within the computer simulation model
• 17:12
  they were using. One group used complex
• 17:15
  statistically designed experiments.
• 17:17
  DOE you know the multi factor orthogonal array type stuff?
• 17:22
  The gold standard for efficient optimization.
• 17:24
  Right, the methods we spend a lot of time teaching engineers.
• 17:27
  Exactly. The other group used a much
• 17:29
  simpler approach, adaptive, one factor at a time or O fat.
• 17:33
  Basically just changing one variable, seeing what happens,
• 17:35
  changing the next the old school way.
• 17:37
  OK, so intuition says the complex DOE method should be
• 17:40
  better, right? More systematic.
• 17:42
  That's what you'd think. But the goal here wasn't just
• 17:45
  optimization efficiency. It was flawed detection.
• 17:48
  And the results were, well, shocking.
• 17:51
  Don't keep me insistent. The engineers using the simpler
• 17:53
  adaptive Ofat method were significantly more likely to
• 17:56
  detect the hidden flaws in the simulation.
• 17:58
  How much more likely? The detection rate for the
• 18:00
  adaptive OFAT group was 52 percent. 52% of them found the
• 18:03
  flaw. OK.
• 18:04
  And the complex DOE group. Only 4%.
• 18:07
  Wait, what, 52% versus 4%? That's that's almost
• 18:11
  unbelievable. We push these complex methods
• 18:14
  and the simple one step at a time approach was over 10 times
• 18:17
  better at catching bugs in the model.
• 18:20
  That's what the study found. The interpretation is at the
• 18:22
  very complexity of the designed experiment Strategy might
• 18:25
  actually mask the unexpected behavior caused by a flaw.
• 18:29
  When you change multiple things at once, it's harder to notice
• 18:32
  when the system response is just weird off doesn't make sense.
• 18:38
  Whereas changing one thing at a time makes anomaly stand out
• 18:40
  more clearly, you have a simpler expectation to compare against.
• 18:44
  Precisely. So the key take away here.
• 18:46
  For you listening is profound, sometimes simplification of
• 18:50
  your. Search strategy actually.
• 18:51
  Makes you more capable of perceiving those hidden.
• 18:53
  Critical errors especially. In complex computer simulations,
• 18:57
  it's a crucial human insight that complements all the
• 19:00
  sophisticated mathematical and structural.
• 19:01
  Tools we've discussed. We are simply.
• 19:03
  Better flaw detectors. When we simplify the immediate.
• 19:06
  Test environment had tag tag outro apro.
• 19:10
  So when you pull it all together.
• 19:11
  Success in complex systems design really hinges on a
• 19:14
  combination of things. It requires structure.
• 19:17
  Enforcing absolute clarity and solution neutrality and
• 19:19
  requirements using frameworks like Axiomatic Design to strive
• 19:23
  for that uncoupled architecture. It requires vigilance, applying
• 19:26
  things like critical parameter management to maintain
• 19:28
  robustness through the manufacturing process, and maybe
• 19:31
  most critically, recognizing the human element, understanding
• 19:34
  that sometimes simplicity in our testing approach is what allows.
• 19:37
  Us to perceive. The flaws that complex methods
• 19:39
  might obscure. Structure, vigilance, and
• 19:41
  simplicity. It really is fascinating, isn't
• 19:43
  it? After diving into these high
• 19:45
  level concepts, the design matrix, quadratic quality loss,
• 19:49
  Economic optimization, we circle right back back to the
• 19:53
  realization that sometimes our most reliable defense against
• 19:56
  potentially catastrophic design flaws isn't some super complex
• 20:00
  analysis, but maybe just the most basic one factor at a time
• 20:03
  test done thoughtfully. Indeed, and perhaps that leads
• 20:06
  to the final provocative thought for you to take away and
• 20:08
  explore. In a world filled with
• 20:10
  increasingly complex, interdependent systems, how can
• 20:13
  you structure your next technical challenge, your next
• 20:15
  design problem, to ensure that the simplest possible test case
• 20:18
  has the best chance of revealing the most critical flaws?