Latest / Mechanical Engineering Made Simple / (#57) Structured Methods for Product Design Success

Transcript

(#57) Structured Methods for Product Design Success · Mechanical Engineering Made Simple

• 0:00
  Welcome back, design junkies, to mechanical engineering made
• 0:02
  simple. Today we're doing a deep dive
• 0:05
  into the structured methods that really let engineers get a
• 0:09
  handle on creating a product. We're talking everything from
• 0:13
  the, you know, high level customer wish list all the way
• 0:16
  down to the tiniest manufacturing detail.
• 0:18
  OK, let's unpack this. We're dealing with systems so
• 0:21
  complex they they often just exceed our natural cognitive
• 0:26
  limits. The old way of thinking, that
• 0:28
  machine age idea of just breaking things into parts.
• 0:31
  It just doesn't work anymore. Right, we need frameworks to
• 0:34
  actually manage system level complexity to get into what some
• 0:38
  people call synthetic thinking. Absolutely.
• 0:40
  When we talk about engineering these really complex systems,
• 0:43
  you, you run right up against the brains limitations.
• 0:45
  I mean, there's that famous paper, The magic #7 ± 2, yeah.
• 0:49
  You can only juggle so many things at once.
• 0:51
  Exactly. We can only really process a
• 0:52
  handful of distinct categories at one time.
• 0:55
  So to succeed in this this system age, we have to have
• 0:58
  robust structures for how we think and how we document.
• 1:01
  So the mission today is to uncover those structures
• 1:04
  starting, I guess, right at the beginning with requirements.
• 1:07
  When we say success is baked in from the start, it means writing
• 1:11
  great requirements. What?
• 1:13
  What does that actually mean beyond just being clear?
• 1:16
  Well, the number one attribute is being solution neutral.
• 1:19
  A good requirement specifies the what what the system has to
• 1:23
  achieve, never the how. And of course it has to be
• 1:26
  concise, unambiguous and, and this is the big one, verifiable.
• 1:31
  Verifiable is a must have. I mean, if you can't prove you
• 1:33
  met it later with a test or some analysis, it's just a wish list.
• 1:36
  Right, it is, and that's why the grammar, the language we use,
• 1:40
  matters so much. It sounds nitpicky, but it's
• 1:42
  critical requirements use the word shall.
• 1:44
  That's a command. It's a non negotiable
• 1:46
  specification. OK, so the system shall.
• 1:48
  Right. And then statements of fact,
• 1:50
  they use will and goals, you know, those desired attributes
• 1:53
  that are maybe harder to quantify.
• 1:55
  They use should that linguistic discipline.
• 1:57
  It just removes a massive amount of ambiguity down the line.
• 2:00
  That clarity is essential because these things cascade
• 2:03
  down through the whole life cycle the the V model.
• 2:06
  So if requirements flow down, what's the biggest failure
• 2:10
  point? Is it a vague scope at the top,
• 2:12
  or maybe poor verification testing at the bottom?
• 2:14
  The V model is designed to prevent both of those, really.
• 2:18
  It shows how requirements flow from the high level, you know,
• 2:20
  the voice of the customer, that's your initial baseline.
• 2:23
  Then they get decomposed into technical specs, and then
• 2:25
  they're tested and validated back up the other side of the V
• 2:28
  all the way to a verified product baseline.
• 2:31
  So every step is like a contract.
• 2:32
  It has to be. It prevents that uncontrolled
• 2:34
  drift. OK, so we've defined what we
• 2:36
  need. Now how do we design so it's
• 2:39
  robust? This seems to take us into
• 2:41
  axiomatic design, which tries to create almost universal laws for
• 2:46
  good design sues 2 axioms. It does.
• 2:49
  Axiomatic design gives you a really rigorous framework for
• 2:52
  picking architectures that connect the the customer domain,
• 2:55
  the functional, the physical, and even the process domains.
• 2:58
  And axiom 1 is all about avoiding dependency, the
• 3:01
  independence axiom. Correct.
• 3:04
  It states that you have to maintain the independence of
• 3:06
  your functional requirements, your FRS, and we can visualize
• 3:10
  this with a design matrix. The ideal, the perfect scenario
• 3:15
  is an uncoupled design. That gives you that clean
• 3:18
  diagonal matrix. One component or design
• 3:21
  parameter only controls 1 functional requirement.
• 3:24
  Exactly 1 knob for one function. But the real world you know it
• 3:29
  means trade-offs. Of course it does.
• 3:31
  So decoupled designs are often necessary, and they're
• 3:34
  manageable. That's a triangular matrix where
• 3:37
  you can at least sequence your adjustments in a logical order.
• 3:40
  The real killer, though, is a coupled design.
• 3:42
  That's where changing one thing just messes up a bunch of other
• 3:45
  things. Right.
• 3:45
  It leads to endless costly tradeoffs.
• 3:48
  The classic example is the old refrigerator, the one with a
• 3:50
  single fan for both the freezer and the fridge.
• 3:53
  You adjust one and you throw off the temperature of the other.
• 3:55
  It's totally coupled. A perfect example.
• 3:57
  Now axiom 2, the information axiom.
• 4:00
  That one focuses on minimizing the information content of the
• 4:03
  design. Which sounds abstract, but what
• 4:05
  does it mean in practice? It just means maximizing the
• 4:08
  probability that the system will work reliably.
• 4:11
  We want elegant designs with a high probability of success,
• 4:15
  designs with less uncertainty. It's basically an argument for
• 4:18
  simplicity. OK, so once we have that elegant
• 4:21
  uncoupled design, the next fight is protecting it when it hits
• 4:24
  the factory floor. And that's where Critical
• 4:28
  Parameter management CPM comes in.
• 4:30
  That's the practice. It's aimed specifically at
• 4:33
  sustaining that system robustness all the way through
• 4:36
  detailed design and into manufacturing.
• 4:39
  So early on, engineers optimize these critical parameters.
• 4:43
  They might figure out the perfect belt tension for a paper
• 4:45
  feeder has to be, say, 15 Newtons.
• 4:48
  Right. 15 Newtons is this critical functional value, but
• 4:51
  it's so easy for someone on the manufacturing side to lose sight
• 4:54
  of that if they're just focused on cost or making it faster to
• 4:56
  assemble. That is the exact risk CPM is
• 4:59
  designed to fight. It ensures that those optimized
• 5:02
  functional requirements are flowed down properly to set the
• 5:04
  manufacturing precision levels you need.
• 5:06
  It keeps the focus on the systems function, not just, you
• 5:09
  know, easy assembly. This flows right into the
• 5:11
  economics of all this. We've come a long way from the
• 5:14
  old gonna go gauging culture that was just obsessed with
• 5:19
  tight tolerances for their own sake.
• 5:21
  Oh. Absolutely.
• 5:22
  The modern view is entirely economic.
• 5:25
  You select a production process to minimize the total cost, and
• 5:28
  that total cost is the sum of two things, the manufacturing
• 5:32
  process cost plus the quality loss you get from variations.
• 5:36
  So you have to ask, is the money I'm spending on more precision
• 5:39
  actually worth the reduction in failures I'm going to see?
• 5:41
  That's the question. And that whole framework is
• 5:44
  really built on the work of Doctor Shehart back in the
• 5:46
  1920s, his realization that variation is just a natural part
• 5:50
  of any process. Right, you have that natural
• 5:52
  inherent variation Sigma, and then you have variation from
• 5:55
  special causes that you try to eliminate.
• 5:57
  Exactly. And our goal is to economically
• 5:59
  manage the variation that we can't easily get rid of.
• 6:01
  So tell us about this three tiered tolerance approach.
• 6:04
  It's a really powerful idea that ties engineering precision
• 6:08
  directly back to the customer's wallet.
• 6:10
  It is. It uses what's called the
• 6:12
  quadratic quality loss function to set tolerances based on cost.
• 6:17
  So the outermost limit is the customer tolerance.
• 6:19
  We'll call it Delta C If a product deviates past that
• 6:22
  point, the average customer gets so mad they call for a recall or
• 6:26
  repair. And that incurs a huge loss L
• 6:28
  sub C from all the field service and logistics.
• 6:31
  A massive loss. So working inward from that, you
• 6:33
  have the manufacturing tolerance Delta M.
• 6:35
  That's what actually goes on the drawing.
• 6:37
  OK, so how is that one calculated?
• 6:39
  Delta M is calculated to minimize the total cost.
• 6:42
  The idea is if a unit deviates past delta M in the factory, it
• 6:47
  is cheaper to fix it right there at cost L sub M than it is to
• 6:50
  ship it and risk that huge field cost L sub C.
• 6:54
  That trade off basically defines your manufacturing window.
• 6:57
  The formula is delta M equals delta C times the square root of
• 7:01
  LM over LC. And then there's a third, even
• 7:04
  tighter limit, the adjustment limit D.
• 7:05
  That's an internal factory limit.
• 7:07
  It's used in operations to save even more money.
• 7:09
  By stopping variation before it even gets close to the delta M
• 7:12
  boundary, it proactively avoids the need for any factory rework.
• 7:16
  So you're forcing everything to be really tightly grouped around
• 7:19
  the ideal target value. That's the goal.
• 7:22
  Managing all this complexity and variation, it often demands real
• 7:26
  innovation. What if we hit a technical
• 7:28
  contradiction? You know, where improving
• 7:31
  feature A makes future B worse? How do we breakthrough that
• 7:35
  without just making a lazy compromise?
• 7:37
  Well, that is the entire philosophy of TRIZ, the theory
• 7:40
  of inventive problem solving. Conventional engineer.
• 7:43
  You're right, it usually settles for a compromise.
• 7:45
  TRIZ thinking tries to overcome that contradiction completely.
• 7:49
  That sounds a lot like it's aiming for the law of ideality.
• 7:52
  It is. That's the central concept.
• 7:54
  Any technical system tends to become more reliable, simpler,
• 7:57
  more effective, more ideal over its lifetime.
• 8:01
  The ideal solution is often when the element that's causing the
• 8:03
  problem is just absent. Can you give an example?
• 8:06
  Sure, imagine you're testing the effect of acids on metal
• 8:09
  specimens inside a special chamber, but the acid is also
• 8:12
  reacting with the chamber walls, messing up your results.
• 8:15
  The ideal solution is for the chamber to be absent.
• 8:17
  How is that possible? You use the specimen itself as
• 8:20
  the chamber. You find a way to contain the
• 8:23
  acid within the thing you're testing.
• 8:25
  The problematic element is gone. Wow, that's a huge creative
• 8:29
  leap. This also changes how we think
• 8:31
  about reliability, doesn't it? It moves it from just a static
• 8:34
  probability to something more active like failure mode
• 8:37
  avoidance, pushing the walls of the operating window further
• 8:40
  apart. Exactly, and one really powerful
• 8:43
  strategy for widening that window is to create 2 distinct
• 8:47
  operating modes for a component. What would that look like in the
• 8:50
  real world? Think about a retard role in a
• 8:53
  copier. It's a wear item.
• 8:55
  It's designed to fail eventually.
• 8:57
  The innovation was to add a tiny drag break that only engages to
• 9:01
  inhibit rotation during a multi feed a paper jam.
• 9:04
  So it's not wearing out during normal operation.
• 9:06
  Right, it creates a special mode just for handling jams, which
• 9:09
  saves all that wear and tear during normal single sheet
• 9:11
  feeding. It dramatically extends the
• 9:13
  system's life. Let's pivot to testing for a
• 9:15
  second. Engineers are relying so much on
• 9:18
  simulations now, even though we all know those computer models
• 9:21
  can be flawed. So what happens when you throw a
• 9:24
  complex, statistically designed experiment at a bad model?
• 9:28
  Does that help find the flaw? The research here is actually
• 9:32
  really counterintuitive. It turns out that when engineers
• 9:35
  used flawed computer models, they were more likely to spot
• 9:39
  the flaw using simple adaptive one factor at a time or ofat
• 9:43
  searching. Wait, you're saying a simpler
• 9:45
  search strategy made the human engineer better at finding an
• 9:48
  error in a complex simulation, not a big complex statistical
• 9:52
  design? That's what the data showed.
• 9:54
  It seems the complexity in the testing method actually
• 9:56
  overwhelms the engineer's cognitive ability to perceive
• 10:00
  the error in the model. Simple step by step changes
• 10:03
  enhance our ability to see when something's wrong.
• 10:05
  OK, So what does this all mean for us?
• 10:07
  I mean, we've gone from requirements that have to say
• 10:09
  shall to decoupling design with Axiom One, to these economically
• 10:12
  optimized tolerances and even designing for failure avoidance.
• 10:16
  What's the thread that ties it all together?
• 10:18
  I think it's how quantification extends into every part of the
• 10:21
  design process, even into quantifying the uncertainty
• 10:24
  itself. Think about air propagation in a
• 10:27
  measurement. Say you want to determine the
• 10:29
  local acceleration of gravity G using a pendulum.
• 10:33
  The formula is g = 4π ^2 L / t ^2 where L is the length and T
• 10:39
  is the period. So you have to measure the
• 10:41
  length, and you have to measure the period, and any error in
• 10:44
  those measurements is going to affect your final calculation
• 10:47
  for gravity. Exactly.
• 10:48
  And when you look at the formula for the most probable error,
• 10:51
  it's fascinating. The final error in G, let's call
• 10:54
  it EG, equals the square root of the error in l ^2 plus the
• 10:58
  quantity 2 times the error in T all squared.
• 11:01
  So hold on, the error in the period T is multiplied by two
• 11:05
  before it gets squared. Correct, which means the
• 11:07
  measurement error in the period contributes 4 times as much
• 11:10
  uncertainty to your final result as the error in the length.
• 11:13
  L4 times the impact. Wow, that tells you exactly
• 11:16
  where you need to spend your time and money to get more
• 11:18
  precision in that system. It does.
• 11:21
  It raises that critical question for any system you design, which
• 11:25
  parameters, which measurements are truly driving the success or
• 11:28
  failure of your outcome, and where?
• 11:30
  Shouldn't you absolutely stop compromising and instead
• 11:33
  maximize precision? Focus your precision where the
• 11:35
  physics actually demands it. That's a perfect final thought.