Latest / Mechanical Engineering Made Simple / (#50) Axiomatic Design Protects Product Robustness

Transcript

(#50) Axiomatic Design Protects Product Robustness · Mechanical Engineering Made Simple

• 0:00
  Welcome back, design junkies, to Mechanical Engineering Made
• 0:02
  Simple. Today we are moving beyond just,
• 0:05
  you know, drawing parts that fit together, and we're taking a
• 0:07
  deep dive into the formal structured discipline of systems
• 0:12
  engineering. That's absolutely right.
• 0:14
  Our mission here is to really explore the structured
• 0:17
  methodologies, these formal Rd. maps that engineers use to
• 0:21
  navigate what can be overwhelming complexity.
• 0:25
  We're not just talking about theory, are we?
• 0:26
  No, not at all. We're talking about tools like
• 0:29
  axiomatic design and critical parameter management.
• 0:31
  The goal isn't just to design a product that works.
• 0:34
  But it functions. Right.
• 0:35
  The goal is reliability, its manufacturer ability, and its
• 0:39
  robustness against every bit of variation that happens once it
• 0:42
  leaves the factory floor. And that's the crucial challenge
• 0:45
  we're investigating, isn't it? That tension between a brilliant
• 0:47
  idea on day one and the reality of manufacturing it.
• 0:51
  Exactly how do you make sure that that robust design, that
• 0:54
  genius concept survives the, let's say, brutality of detailed
• 0:59
  component design, cost down initiatives and the transition
• 1:02
  to mass production because. If you don't.
• 1:04
  If that conceptual rigor isn't maintained, the risk just spikes
• 1:08
  dramatically. You end up with costly design
• 1:11
  delays, excessive warranty claims and worst of all, a
• 1:15
  product that just performs inconsistently for your
• 1:17
  customer. We have to look at the process
• 1:20
  used to lock in those early decisions.
• 1:22
  OK, so where do we start? What's the blueprint for that?
• 1:25
  To connect this to the bigger picture, every successful system
• 1:28
  is built on a formal life cycle structure.
• 1:31
  It starts with need identification, moves through
• 1:34
  requirements analysis, synthesis and eventually verification.
• 1:38
  And the foundation of all that is having clear requirements
• 1:41
  that cascade down. They have to cascade down
• 1:43
  clearly and controllably. Absolutely.
• 1:45
  So we can't just write down wishes, the requirements
• 1:48
  themselves have to. Be have to be high quality first
• 1:50
  and foremost. Our requirement must be
• 1:52
  verifiable. How will you know you met it?
• 1:55
  That's the question. If you can't define an
• 1:57
  unambiguous test or measure to consume it, it's not a
• 1:59
  requirement, it's a dream. It also has to be attainable, of
• 2:03
  course. And crucially, olution neutral.
• 2:06
  O focusing on the what, not the how.
• 2:08
  Recisely what the system must achieve, not how you think the
• 2:12
  design is going to do it. This level of rigor is what
• 2:15
  really distinguishes formal engineering and the semantics.
• 2:19
  The words you use, They really matter, don't they?
• 2:22
  Especially when you're talking across different teams.
• 2:24
  Oh, they absolutely do. In formal requirements docs, we
• 2:27
  are incredibly specific with our verbs.
• 2:29
  We reserve the word shall for true binding requirements.
• 2:33
  For example, the machine shall operate at a maximum noise level
• 2:37
  of 60 decibels. That's a contract.
• 2:39
  OK, we use will for statements of fact, and if an attribute is
• 2:44
  really desirable but maybe too costly or difficult to verify,
• 2:47
  we use should. So that signals it's a design
• 2:50
  goal, not something you can get sued over.
• 2:52
  Exactly. It prevents arguments later and
• 2:55
  this structure leads us to really important checkpoints,
• 2:57
  the requirements baselines. These are like contractual
• 3:00
  milestones. That's a great way to put it.
• 3:02
  You need 3 primary baselines. First is the validated baseline,
• 3:06
  which is basically the contract. Then you have the system
• 3:08
  functional baseline, often in a document called the PFS.
• 3:11
  And that one's critical. It's critical because it locks
• 3:14
  down what the system does at a high level.
• 3:16
  Finally, there's the allocated baseline, or PAS, which breaks
• 3:19
  those functions down and assigns them to specific hardware or
• 3:23
  software. So PFS is the big picture and
• 3:25
  PAS gets surgical. It says this subsystem is
• 3:28
  responsible for this requirement.
• 3:30
  Right. And those baselines give you
• 3:32
  traceability all the way back to the original need.
• 3:35
  OK, so requirements are solidified.
• 3:37
  Now we have to actually design something.
• 3:40
  This brings us to axiomatic design.
• 3:41
  Developed by Nam PSU, yes, it gives us a way to make good
• 3:45
  decisions by mapping functional requirements or FRS to specific
• 3:50
  design parameters DPS. And it's based on 2 axioms,
• 3:53
  which sounds simple but are actually pretty profound.
• 3:55
  They are. Axiom 1 is really the foundation
• 3:58
  of a robust design, the Independence axiom, meaning it
• 4:01
  mandates that your design must maintain the independence of its
• 4:04
  functional requirements. I think of this as if I turn 1
• 4:07
  knob, I don't want it to accidentally mess up the setting
• 4:10
  on another knob. Why is that so important?
• 4:12
  Because coupling is complexity and complexity is risk.
• 4:16
  If changing your first design parameter DP1 also impacts your
• 4:19
  second functional requirement FR2, you have a coupled system.
• 4:23
  Every time you try to fix one thing, you break another.
• 4:25
  It's a nightmare. It is so axiomatic design forces
• 4:29
  you to create a design matrix that's either uncoupled or at
• 4:32
  worst decoupled. Each DP should really only
• 4:35
  affect one Fr the. Refrigerator samples perfect
• 4:38
  here. Let's say Fr one is easy access
• 4:41
  to items. Fr 2 is minimizing energy loss.
• 4:44
  OK good. So if you design A tall fridge
• 4:46
  with a single vertical door, your DP 1 opening that door
• 4:49
  let's all the cold air fall out. It has a massive impact on FR2
• 4:52
  energy loss. That's highly coupled, right?
• 4:54
  But if you shift your concept to say, horizontal access like
• 4:57
  drawers or a chest freezer, opening one section only
• 5:01
  minimally affects the others. That simple conceptual shift
• 5:04
  guided by axiom one. Just it massively reduces it.
• 5:08
  Makes the whole system more robust.
• 5:09
  Yeah, so simple. OK, that makes perfect sense.
• 5:11
  Let's move to axiom 2, the information axiom.
• 5:14
  This one is often the most misunderstood.
• 5:16
  It says you must minimize the information content of the
• 5:20
  design. Information content sounds a bit
• 5:22
  abstract. What does that actually mean?
• 5:24
  It's this formal way of measuring complexity and risk,
• 5:27
  but if we simplify it, we're just maximizing the probability
• 5:30
  of meeting the functional requirements.
• 5:33
  So a simpler design has a higher chance of success.
• 5:36
  Exactly. The formal math defines the
• 5:38
  system information content. They call it ISIS as being
• 5:41
  inversely related to P sub M the probability of success.
• 5:45
  So high information, low probability.
• 5:48
  That's it. A design that needs, you know,
• 5:51
  highly specialized parts with hair splitting tolerances has
• 5:54
  high information content. It's probability of success out
• 5:57
  in the real world is low. A design using Haman robust
• 6:01
  parts has low information content and is therefore more
• 6:03
  likely to succeed. It's really a mandate for
• 6:06
  simplicity. And these two axioms are linked
• 6:08
  by something called the zigzagging process.
• 6:10
  Correct, that's how the conceptual world meets reality.
• 6:14
  You start with a high level Fr, you decompose it, find the DPS
• 6:17
  you need, and then those DPS them themselves become the new
• 6:20
  requirements for the next level down.
• 6:23
  It's how you keep the big picture in mind as you get into
• 6:25
  the tiny details. So once we have these simple
• 6:27
  decoupled design parameters, we have to protect them you.
• 6:30
  Don't have to protect them. This leads us directly into
• 6:33
  critical parameter management, or CPM.
• 6:36
  The whole discipline here is making sure that the critical
• 6:39
  values you optimize for early on are sustained through the entire
• 6:43
  process. It sounds like governance.
• 6:45
  How do you make sure an engineer trying to save a few cents
• 6:48
  doesn't undermine the whole robust design?
• 6:50
  It creates an unbreakable criticality flow.
• 6:52
  Let's use your example. A belt tension of 15 Newtons is
• 6:56
  your critical parameter. That's the key to performance,
• 6:59
  the CPM process. Make sure the detailed designer
• 7:02
  who's now just sourcing a spring translates that 15 Newton
• 7:05
  requirement into a critical spec, like a spring constant K
• 7:09
  with a very tight tolerance. If they sub in a cheaper spring
• 7:12
  with a looser tolerance, they've just undermined the entire
• 7:15
  systems robustness. So protecting those critical
• 7:18
  parameters is everything. But that brings up the classic
• 7:20
  problem. Precision costs money.
• 7:24
  How do you decide how precise to be?
• 7:26
  This is where the economics of tolerancing gives us a formal
• 7:29
  answer. You have to set tolerances to
• 7:31
  minimize the total cost. That's manufacturing cost plus
• 7:35
  the quality loss from variation. So you look at it from two
• 7:38
  sides. There's the customer's limit and
• 7:39
  the factory's limit. Precisely.
• 7:41
  First, the customer tolerance. Let's call it Delta C This is
• 7:45
  the point where the average customer says this thing is
• 7:47
  broken and calls for a warranty repair.
• 7:50
  The cost associated with that L sub C is very high.
• 7:53
  Field service, logistics, all of that.
• 7:56
  And the second limit is the one on the blueprint, the
• 7:58
  manufacturing tolerance or Delta M.
• 8:00
  And Delta M is set much, much tighter than the customer's
• 8:04
  tolerance. Why?
• 8:05
  Because the quality loss L sub M for catching and fixing a
• 8:07
  problem in the factory is way less than the cost L sub C of
• 8:11
  fixing it in the field. So delta M is the decision
• 8:14
  point. It's the economic economic
• 8:15
  boundary. If a units deviation is greater
• 8:17
  than delta M, you rework it in the factory for cost L sub M If
• 8:22
  it's less, you ship it because the cost of fixing it now is
• 8:26
  actually higher than the statistical risk of it failing
• 8:28
  in the field. That's a truly data-driven
• 8:30
  approach to quality. It's not just arbitrary numbers.
• 8:33
  Not at all. It's pure economics.
• 8:35
  So we have this rigor and structure, but what about
• 8:38
  innovation? How does systems engineering
• 8:40
  help us find new, better solutions?
• 8:42
  That's a great question. We often hear about TRZ, the
• 8:46
  theory of inventive problem solving.
• 8:48
  Right. The 1 based on analyzing
• 8:49
  patents. Hundreds of thousands of
• 8:51
  patents. And the key insight from TRZ is
• 8:54
  that inventors often settle for compromises.
• 8:57
  You know, they make something lighter, but it's also weaker.
• 9:00
  TRZ guides you to overcome those technical contradictions
• 9:03
  entirely. How to make something stronger
• 9:05
  and lighter at the same time? And once you have an innovative
• 9:08
  idea, you have to test it. We hear a lot about Design of
• 9:11
  Experiments or DOE. And DOE is fantastic for
• 9:15
  building complex statistical models, but we're also seeing a
• 9:18
  strong case for a simpler approach, adaptive one factor at
• 9:21
  a time, or AO fat. So you just change one thing,
• 9:25
  see if it works, and if it does, you keep it.
• 9:27
  That's the gist of it, and while it's not as comprehensive,
• 9:30
  research shows AO fat can get you about 80% of the system
• 9:34
  benefits of a complex DOE, but much faster.
• 9:38
  It's an efficiency tradeoff. What's fascinating to me is how
• 9:41
  this choice affects the human engineer.
• 9:43
  There's some cognitive research showing something really
• 9:45
  surprising here. I think I know you're referring
• 9:47
  to when engineers use the simple one factor at a time strategy.
• 9:52
  They were statistically more likely to find bugs or flaws in
• 9:55
  a computer simulation than those using a complex experiment.
• 9:58
  Why is that? The connection is profound.
• 10:00
  By simplifying the external task to just focus on this one
• 10:04
  variable, it frees up the human brain's capacity to notice other
• 10:07
  things, to see anomalies in the output.
• 10:09
  When the experiment is too complex, the engineer is just
• 10:12
  busy managing the experiment, not critically observing the
• 10:15
  results. So systems engineering, with all
• 10:17
  its math, comes right back to the limits of the human mind at.
• 10:20
  The end of the day, it's an activity conducted by human
• 10:23
  beings, limited human minds. This has been incredible.
• 10:27
  This deep dive shows that mastering complexity really
• 10:31
  demands structure with axiomatic design, rigor with critical
• 10:36
  parameter management, and an appreciation for the most
• 10:41
  efficient path to discovery, like with Aophat and.
• 10:44
  Maybe I can leave you with one final thought on that human
• 10:47
  variable. Systems engineering, in theory,
• 10:50
  requires perfect rationality, but it's performed by people who
• 10:53
  are highly susceptible to cognitive biases.
• 10:56
  Things like anchoring on your first idea.
• 10:58
  Exactly. Anchoring availability bias.
• 11:01
  Wishful thinking. You name it.
• 11:03
  We can build perfect models, we can generate perfect data.
• 11:06
  But the biggest challenge is, and always will be, that people
• 11:08
  are strongly motivated to confirm what they already
• 11:11
  believe to be true about their own design.
• 11:13
  So the ultimate success metric isn't the model, it's how well
• 11:16
  the people can challenge their own assumptions.
• 11:18
  That's the whole game. Thank you for joining us for
• 11:20
  this deep dive.