Latest / Mechanical Engineering Made Simple / (#34) Systems Engineering - Defining Requirements.

Transcript

(#34) Systems Engineering - Defining Requirements. · Mechanical Engineering Made Simple

• 0:00
  Welcome back to Mechanical Engineering Made Simple.
• 0:02
  Today we're really taking a step back.
• 0:05
  We're doing a deep dive into the process that, well, kind of runs
• 0:10
  underneath everything in modern technical design.
• 0:12
  Yeah, moving beyond just the components themselves.
• 0:14
  Exactly. We're looking at the, you know,
• 0:16
  the organizational brain, systems engineering, dynamic
• 0:20
  modeling, and maybe most importantly, the control systems
• 0:23
  that make complex machines actually do what we want them
• 0:27
  to. It's all about managing
• 0:28
  complexity. That's the goal.
• 0:30
  We want you to walk away with some quick but really solid
• 0:33
  knowledge about how engineers get a handle on these massive,
• 0:36
  intricate projects, how they make sure things actually
• 0:39
  succeed. And it's interesting how the
• 0:41
  source material defines systems engineering right off the bat.
• 0:44
  It's not just equations and diagrams.
• 0:46
  No. What is this?
• 0:47
  It's framed as the right mix of mathematical theory, yes, but
• 0:51
  also behavioral and management ideas all brought together to
• 0:54
  tackle these big, messy real world problems.
• 0:58
  See how? Well, problems with large scale,
• 1:00
  wide scope, and, crucially, involving information that's
• 1:03
  often incomplete, uncertain, maybe even just plain imperfect.
• 1:07
  It's about making sense of that. OK, let's unpack this a bit
• 1:10
  because that sounds huge, like solving global crises.
• 1:14
  If that's the big picture, what's the actual, like,
• 1:17
  day-to-day mission for an engineer using systems
• 1:20
  engineering? Where does it even begin?
• 1:22
  Right. The functional mission is much
• 1:23
  more concrete. It's really the art and science
• 1:26
  of producing something. Could be hardware, could be a
• 1:29
  service that performs its function, is reliable, high
• 1:32
  quality, trustworthy. The basics you'd expect.
• 1:35
  Yes. But here's the kicker.
• 1:37
  Doing all that within the cost and time constraints you're
• 1:40
  given, that's critical. Ah, so the perfect machine built
• 1:43
  too late or too expensively is actually a systems failure.
• 1:47
  Precisely the process failed, even if the machine itself is
• 1:50
  brilliant. OK.
• 1:50
  So thinking about that process, that product life cycle from
• 1:54
  idea to reality, what are the absolute essential phases we
• 1:57
  need to understand? You know, real world projects
• 2:00
  break down to lots of steps, concept planning, detailed
• 2:03
  design, testing, you name it. But fundamentally it really
• 2:07
  boils down to three core stages, definition, then development,
• 2:11
  and finally deployment. That's the basic arc from What
• 2:15
  do we need to Here it is. Working definition, development,
• 2:19
  deployment. Got it.
• 2:20
  And if there's one nugget to really latch onto here, it's
• 2:23
  this, that first phase, the definition phase, specifically
• 2:27
  the requirement specification part, that's arguably the most
• 2:31
  critical step in the entire journey.
• 2:32
  Why so important? Because its goal is the detailed
• 2:35
  definition of the needs, the objectives, the things the
• 2:38
  system absolutely must fulfill. Get that definition wrong or
• 2:42
  incomplete. And everything that follows is
• 2:44
  built on a shaky foundation. Exactly.
• 2:46
  The quality of that requirements definition heavily influences
• 2:49
  everything downstream. You could have the world's best
• 2:52
  engineers optimizing perfectly for the wrong goal.
• 2:54
  That's an expensive way to fail. Makes total sense.
• 2:57
  Garbage in, garbage out, as they say.
• 2:59
  So how do engineers actually dig out these requirements,
• 3:03
  especially when things are complex, when maybe the client
• 3:08
  isn't even totally sure what they need yet?
• 3:10
  That happens right at the start in what's called the issue
• 3:12
  formulation step. It's about defining the problem
• 3:15
  clearly and also designing the value system, figuring out what
• 3:19
  the client really values. Is it speed?
• 3:21
  Cost. Safety.
• 3:23
  And how do you find that out? The sources give us a few
• 3:25
  methods. First the obvious one.
• 3:28
  Just asking. Talking to people.
• 3:31
  Right, direct declarative approach.
• 3:33
  If the uncertainty is low, the problem's pretty well
• 3:35
  understood. You go to the experts, the
• 3:36
  stakeholders, and you ask them what the system needs to do.
• 3:39
  OK. Seems straightforward enough.
• 3:40
  What else? Second method is descriptive
• 3:42
  identification. This means you study existing
• 3:45
  similar systems. Very common if you're upgrading
• 3:48
  something. Like looking at the old version
• 3:49
  to design the new one. Exactly.
• 3:51
  But there's a big caution here. This approach often leads to
• 3:54
  only small, incremental improvements.
• 3:58
  Why that? Because you risk getting
• 4:00
  anchored to the old system. You might accidentally carry
• 4:04
  over its limitations, its bottlenecks, maybe even flaws
• 4:07
  you didn't realize were there into the new design.
• 4:10
  So you end up designing a slightly faster horse when maybe
• 4:14
  you should have been thinking about a car.
• 4:15
  That's a perfect analogy. You optimize based on
• 4:18
  yesterday's problems, not tomorrow's needs.
• 4:20
  OK, so asking descriptive identification, it's the third.
• 4:25
  Way that's normative synthesis. This one's more forward-looking.
• 4:29
  It involves studying things like future planning documents,
• 4:31
  upcoming regulations, industry standards, trying to figure out
• 4:35
  the desirable objectives for a system that maybe doesn't even
• 4:38
  exist yet. So trying to anticipate the
• 4:41
  future needs. Right now, once you start
• 4:43
  gathering all this stuff, requirements, components,
• 4:46
  objectives, constraints, it can become overwhelming hundreds of
• 4:50
  interacting pieces. How do you possibly keep track?
• 4:54
  Yeah, how do you avoid just drowning in details?
• 4:57
  You have to impose structure. You need to map out the
• 5:00
  connections, make the complexity visible.
• 5:02
  Listing parts isn't enough, you need to see how they influence
• 5:04
  each other. What tools help with that?
• 5:06
  Interaction matrices are really powerful.
• 5:08
  Think of a big grid like a spreadsheet.
• 5:11
  It lets you systematically map the relationships between
• 5:14
  elements, maybe objectives versus design alternatives, or
• 5:18
  subsystem A versus subsystem B. So you can see hit independent.
• 5:22
  Exactly. Oh, changing this effects that
• 5:25
  over there. And the other key tool is using
• 5:28
  trees. Like organizational charts?
• 5:30
  Sort of their graphical ways to show hierarchy or branching
• 5:34
  structures. Think work breakdown structures
• 5:36
  or functional decomposition. Breaking a big function down
• 5:40
  into smaller and smaller pieces. It just makes the whole thing
• 5:42
  easier to grasp, easier to communicate which.
• 5:45
  Is vital for keeping a large team on the same page.
• 5:48
  Absolutely everyone needs to be building the same thing for the
• 5:50
  same reasons. OK, requirements are defined,
• 5:52
  structured. Now this is where, for me at
• 5:55
  least, it gets really interesting.
• 5:57
  We move into dynamic modeling, core mechanical engineering
• 6:00
  stuff. But why bother with abstract
• 6:03
  math models? Why not just build the thing and
• 6:06
  test it? Isn't simplifying it with a
• 6:07
  model like inherently less accurate?
• 6:10
  Maybe even negligent. That's a fair question, and it
• 6:13
  gets asked a lot, but the reason for modeling is actually very
• 6:16
  practical. It comes down to accessibility.
• 6:18
  Accessibility. Yeah, a mathematical model is
• 6:20
  just way more accessible than the real physical system.
• 6:24
  It's much less expensive to create and run.
• 6:26
  It's faster. It's far easier to modify.
• 6:29
  Safer to test extreme conditions I imagine.
• 6:31
  Definitely. You can simulate failures, push
• 6:34
  boundaries, ask all sorts of what if questions, even about
• 6:37
  systems that haven't been built yet without breaking expensive
• 6:41
  hardware or worse, causing accidents.
• 6:44
  OK, that makes sense from a practical standpoint.
• 6:46
  And here's a key take away from the sources on this.
• 6:49
  The best engineering model isn't necessarily the most complex or
• 6:53
  the most accurate one. Really.
• 6:54
  Really, the best model is the simplest model that gives you
• 6:58
  the information you need to make a specific decision.
• 7:01
  So it's about fit for purpose, not absolute fidelity.
• 7:04
  Exactly. If a quick back of the envelope
• 7:07
  calculation tells you design A is better than design B, and a
• 7:10
  super complex week long simulation tells you the same
• 7:13
  thing, you probably wasted a lot of time and effort on the
• 7:16
  complex model for that particular decision.
• 7:20
  It's always a trade off, fidelity versus the effort
• 7:22
  needed. That really changes how you
• 7:24
  think about modeling. It's a tool for decision making,
• 7:27
  not just description. So when we build these dynamic
• 7:30
  models, say for a suspension system or an electric circuit or
• 7:33
  a fluid flow, is there a unified way to approach it?
• 7:36
  Yes, and that's one of the really elegant things here.
• 7:39
  The unified approach uses what are called ideal elements, and
• 7:42
  these are all based on the concept of energy.
• 7:43
  Energy flow and storage. Precisely, to model energy
• 7:47
  properly, you need a pair of related variables.
• 7:50
  The source material calls them a through variable and an across
• 7:53
  variable. OK, explain those.
• 7:54
  Think about electricity. The through variable is the
• 7:57
  current, how much charge flows through a point per second.
• 8:00
  The across variable is the voltage, the potential
• 8:02
  difference across 2 points that drives the current.
• 8:05
  You need both flow and potential for power.
• 8:08
  Like force and velocity in mechanics or flow rate and
• 8:11
  pressure in fluids. Exactly forces through velocity
• 8:15
  differences across. Flow rate is through pressure
• 8:17
  differences across. It's the same fundamental
• 8:19
  pairing. And what do these ideal elements
• 8:22
  represent? They do one of two things, they
• 8:24
  either store energy or they dissipate it.
• 8:27
  Energy storage elements are called T type or a type.
• 8:31
  Think springs. Storing potential energy depends
• 8:34
  on displacement of a cross variable or masses.
• 8:37
  Storing kinetic energy depends on velocity a through variable.
• 8:41
  And dissipation. Those are D type elements,
• 8:44
  dampers and mechanical systems, resistors and electrical
• 8:46
  systems. They turn useful energy into
• 8:48
  heat, basically. OK, so we have these building
• 8:50
  blocks. How do we connect them?
• 8:52
  Using system relations, which are just the interconnection
• 8:55
  laws, there are two kinds. Continuity relations apply to
• 8:58
  those through variables. They ensure things like dynamic
• 9:01
  equilibrium, Newton's laws, Kirchhoff's current law, sum of
• 9:05
  flows into a junction is 0. Makes sense.
• 9:08
  And the other kind. Compatibility relations.
• 9:11
  These apply to the across variables.
• 9:13
  They usually represent geometrical constraints or
• 9:15
  things like Kirchhoff's voltage law.
• 9:18
  The sum of voltage drops around a loop is 0.
• 9:20
  And the beauty of this? Yeah.
• 9:22
  Why is this unified approach so powerful?
• 9:26
  This is the really cool part when you find different physical
• 9:29
  systems, one mechanical, one electrical, maybe 1 fluidic,
• 9:33
  that end up having the exact same generalized mathematical
• 9:36
  model using these elements and relations.
• 9:39
  They're called analogs. Meaning the math sees them as
• 9:42
  identical. Fundamentally, yes.
• 9:44
  The math is telling you that, say, a simple spring mass damper
• 9:47
  system behaves exactly like an electrical RLC circuit.
• 9:51
  The underlying dynamics are the same.
• 9:53
  Wow. And this is incredibly useful,
• 9:55
  especially for modern systems that are often hybrids.
• 9:57
  Part mechanical, part electrical, maybe with fluid or
• 10:00
  thermal elements too. This unified modeling lets you
• 10:03
  handle the whole thing consistently.
• 10:05
  It's a powerful concept. OK, so we have this elegant,
• 10:08
  hopefully simplified model. The next logical step is
• 10:11
  control, making the system do what we want.
• 10:14
  What's the standard setup for a control system?
• 10:16
  The classic structure, the one you see everywhere from
• 10:19
  thermostats to cruise control to industrial robots, is the
• 10:23
  feedback control loop. Feedback OK components.
• 10:26
  You start with a command that's the desired value, what you want
• 10:29
  the system to achieve. Then you need an error detector.
• 10:32
  This compares the command to the actual measured output of the
• 10:37
  system. The difference is the error.
• 10:39
  Right, that error signal feeds into the controller.
• 10:42
  This is the brain, the logic element containing the control
• 10:45
  algorithm. The controller calculates a
• 10:47
  control signal, sends it to an actuator.
• 10:49
  That's the muscle, like a motor or a valve.
• 10:52
  The thing that actually affects the system.
• 10:54
  Exactly. The actuator acts on the plant,
• 10:56
  which is just the term for the system you're trying to control,
• 10:59
  and then, crucially, you measure the plant's output and feed it
• 11:03
  back to the error detector, closing a loop.
• 11:05
  So the goal is always to drive that error signal towards 0.
• 11:09
  That's the fundamental job of the controller, yeah.
• 11:11
  Keep the output close to the command.
• 11:13
  Let's focus on that controller logic, the algorithm we hear PID
• 11:17
  mentioned all the time. Why is PID control so dominant
• 11:21
  and what are you trying to achieve when you design one?
• 11:24
  PID, Proportional Integral derivative.
• 11:26
  It's just ubiquitous. It's popular because it tackles
• 11:29
  the main control objectives pretty effectively and
• 11:32
  intuitively, which are typically you have three main goals.
• 11:35
  First, minimize the steady state error.
• 11:38
  You want the system to eventually settle exactly at the
• 11:41
  target value. Second, minimize the settling
• 11:44
  time. How quickly does it get there?
• 11:45
  And 3rd, minimize overshoot. You don't want it to swing
• 11:49
  wildly past the target before settling down.
• 11:52
  And each letter and PID addresses one of these.
• 11:54
  Broadly speaking, yes. The proportional P term gives
• 11:57
  you a basic response proportional to the current
• 12:00
  error. The integral action is the key
• 12:02
  for eliminating that steady state error.
• 12:04
  It keeps accumulating the error over time, providing an
• 12:07
  automatic reset that pushes the system until the error is truly
• 12:10
  0. And the derivative.
• 12:12
  Primitive D action provides damping.
• 12:14
  It looks at the rate of change of the error, so it anticipates
• 12:17
  future error, helping to handle sudden changes or oscillations.
• 12:21
  Often this is done using a velocity feedback, like
• 12:24
  measuring motor speed with a tachometer.
• 12:26
  OK, PID seems straightforward, but you mentioned the integral
• 12:30
  term. The sources flag a specific
• 12:33
  problem with it. Reset windup or integrator
• 12:36
  buildup. What's that about?
• 12:38
  Sounds painful. It can be a real pain point.
• 12:40
  Yeah, reset wind up happens when your actuator, the motor, the
• 12:44
  valve, whatever heads its physical limit, it gets
• 12:47
  saturated. Like telling a motor to go
• 12:49
  faster than it physically can. Exactly.
• 12:51
  Imagine commanding 120% power. When it maxes out at 100%, the
• 12:55
  error signal command minus actual is still there, telling
• 12:57
  the controller we're not there yet.
• 12:59
  So the interval term whose job it is to accumulate error, it
• 13:03
  just keeps accumulating. It winds up demanding more and
• 13:06
  more control effort that the actuator simply cannot deliver.
• 13:09
  Oh, what happens then? Well, while the actuator is
• 13:12
  saturated, nothing much changes. But later, when the system
• 13:15
  conditions change, maybe the command drops or the disturbance
• 13:18
  goes away and the system can start responding again.
• 13:21
  You've got this huge stored up value in the integrator.
• 13:25
  Like a tightly wound spring. Good analogy.
• 13:28
  That wound U value has to unwind and it forces the actuator to
• 13:32
  keep ushing hard even when it shouldn't.
• 13:35
  The result is usually a massive undesirable overshoot of the
• 13:38
  target value before things finally settle down.
• 13:42
  It really messes up the performance.
• 13:43
  So. Managing that windup is a key
• 13:45
  design challenge for controllers with integral action.
• 13:48
  Absolutely. You often need specific anti
• 13:51
  windup logic to prevent the integrator from accumulating
• 13:54
  excessively when the actuator is saturated.
• 13:57
  OK. Moving beyond PID, you mentioned
• 13:59
  the world's gone digital. How is digital control change
• 14:02
  things, especially for more complex systems?
• 14:04
  Digital control just offers so much more flexibility and power.
• 14:07
  You can implement much more complex algorithms, and
• 14:10
  importantly, you can often handle system nonlinearities
• 14:12
  more directly. Nonlinearities like things that
• 14:15
  don't behave in a simple proportional way.
• 14:17
  Right friction, changing inertia, aerodynamic drag.
• 14:21
  Lots of real world systems are nonlinear.
• 14:24
  Great example of using digital control to tackle this is the
• 14:26
  computed torque method often used in robotics.
• 14:29
  How does that work? Well, a robot arms dynamics are
• 14:32
  highly nonlinear. It's inertia, the effect of
• 14:35
  gravity on it, it all changes drastically depending on the
• 14:38
  arm's position and speed. It's complex I can imagine.
• 14:41
  So the computed torque method uses the robots dynamic model
• 14:45
  inside the controller in real time.
• 14:47
  It calculates the expected non linear torques, especially those
• 14:50
  due to gravity and Coriolis effects, and then it actively
• 14:53
  cancels them out by adding opposing torques through the
• 14:56
  motors. So it computationally removes
• 14:58
  the non linearity. Essentially, yes.
• 15:00
  It linearizes the system on the fly.
• 15:02
  What's left is a much simpler, effectively linear system which
• 15:05
  can then be controlled very easily and accurately using a
• 15:08
  standard linear controller like APID.
• 15:11
  It's a clever way to use computing power to simplify the
• 15:13
  control problem. That's fascinating, using the
• 15:16
  model to actively fight the complexity.
• 15:19
  OK, so we've designed the system, modeled it, created this
• 15:23
  brilliant controller, but it all relies on measurement, right?
• 15:26
  We have to know what the system is actually doing, and
• 15:29
  measurements aren't perfect. Let's clarify what's the real
• 15:32
  difference between accuracy and precision?
• 15:34
  People mix those up. They do.
• 15:36
  They're related, but distinct accuracy is about how close your
• 15:40
  measurement reading is to the actual true value of whatever
• 15:44
  you're measuring, like. Hitting the bullseye on a
• 15:45
  target. Exactly.
• 15:47
  Precision, on the other hand, is about repeatability.
• 15:50
  It's the degree to which multiple readings agree with
• 15:53
  each other. Like all your shots landing very
• 15:55
  close together, even if they're not near the bullseye.
• 15:57
  Perfect. So you can have high precision
• 16:00
  but low accuracy. All your measurements are
• 16:02
  tightly clustered, but they're all wrong by the same amount.
• 16:05
  And high precision doesn't automatically mean you're
• 16:07
  accurate. Not at all.
• 16:09
  To get accuracy, you need proper calibration against a known
• 16:13
  trusted standard. Something priceable back to a
• 16:15
  national standard, like NIST in the US.
• 16:18
  Right. And another measurement issue is
• 16:20
  when the act of measuring changes the thing you're
• 16:23
  measuring. The source calls this loading.
• 16:27
  Can you give us an intuitive feel for that?
• 16:28
  Sure. Imagine you have a tiny cup of
• 16:30
  very hot coffee and you want to measure its temperature if you
• 16:33
  stick a big cold metal thermometer into it.
• 16:36
  The thermometer itself will cool the coffee down.
• 16:38
  Exactly. The thermometer draws heat out
• 16:42
  of the coffee, so the temperature you read is lower
• 16:44
  than the coffee's original temperature.
• 16:46
  The measuring instrument has loaded the system, altering the
• 16:50
  quantity it was trying to measure.
• 16:52
  How do engineers think about this technically?
• 16:54
  It's often framed using impedance concepts.
• 16:57
  Impedance is like a generalized resistance to effort.
• 17:01
  The key idea is if you're measuring an effort variable
• 17:04
  like voltage, pressure, or force, the input impedance of
• 17:08
  your measuring instrument needs to be much, much higher than the
• 17:11
  output impedance of the thing you're measuring.
• 17:13
  High input impedance for the meter?
• 17:14
  No way. Think of voltage.
• 17:16
  An ideal voltmeter has infinite resistance impedance.
• 17:19
  You connect it across 2 points. If it had low resistance, it
• 17:23
  would draw significant current, changing the voltages in the
• 17:26
  circuit you're trying to measure.
• 17:27
  By having very high impedance, it draws almost no current, so
• 17:31
  it doesn't disturb the circuit voltage as much.
• 17:33
  The measure value depends on the ratio of those impedances.
• 17:37
  How does that translate to mechanical systems, say,
• 17:40
  measuring force? Well, in mechanics, the
• 17:44
  analogous concept to impedance for static measurements is often
• 17:47
  stiffness. Imagine using a load cell, which
• 17:50
  is essentially A calibrated spring with stiffness to measure
• 17:53
  the force in a structure. OK.
• 17:55
  If the structure itself is very flexible, meaning it has a low
• 17:58
  output stiffness, and your load cell is relatively stiff,
• 18:02
  inserting the load cell actually changes how the structure
• 18:05
  deforms under load. Because you've added another
• 18:07
  spring in series, essentially. Yeah, precisely.
• 18:10
  Which means the force indicated by the load cell might not be
• 18:13
  the same as the force that would have been there without the load
• 18:15
  cell. To avoid this loading effect
• 18:18
  when measuring force, your load cell needs to be significantly
• 18:21
  sniffer than the system it's placed in.
• 18:23
  Its impedance needs to be high relative to the system's output
• 18:27
  impedance. So the instrument shouldn't
• 18:29
  significantly alter the system's behavior.
• 18:31
  Makes sense. OK, OK, last piece, error
• 18:34
  analysis. We know measurements have
• 18:37
  errors. How do engineers figure out
• 18:39
  which measurements they need to be most careful about where to
• 18:42
  focus their effort? This comes down to understanding
• 18:44
  air propagation, how small uncertainties in your individual
• 18:48
  measurements combine to create uncertainty in your final
• 18:51
  calculated result. Got an example?
• 18:52
  The classic one is measuring the acceleration due to gravity
• 18:55
  dollars using a simple pendulum. The basic physics tells us the
• 18:59
  dollars is proportional to the pendulum's length divided by the
• 19:02
  square of its period. 2 dollars, 222 so dollar and propto LT22.
• 19:05
  OK, measure length, measure time period.
• 19:07
  Right now, suppose you can measure the length dollars with
• 19:10
  some probable error and the period dollars with some
• 19:12
  probable error. How do these errors combine to
• 19:15
  infect the error in your calculated dollars?
• 19:18
  Let's call it Ed. The formula for the probable
• 19:22
  error using standard propagation of uncertainty methods shows
• 19:26
  that Ed is roughly proportional to the square root of EE dollars
• 19:29
  plus two ET $2.00. Wait, there's a $2.00 in front
• 19:33
  of the time error? Yes, and notice the errors are
• 19:36
  squared. That factor of 2 comes from the
• 19:38
  fact that $2.00 is squared in the formula for $2.00.
• 19:40
  When you square that term to ETO dollars, you get $4.00 ET $2.00.
• 19:45
  So the error in the time measurement contributes 4 times
• 19:48
  as much to the final error variance as the error in the
• 19:51
  length measurement. Exactly.
• 19:52
  That's the crucial insight, because the period dollars is
• 19:54
  squared in the physics equation, uncertainty in measuring dollars
• 19:58
  has a much larger impact on the final uncertainty in dollars
• 20:01
  than the uncertainty in measuring dollars.
• 20:03
  So if you want to improve your measurement of dealers, you
• 20:04
  should just spend way more effort getting a precise
• 20:06
  measurement of the time period than the length.
• 20:09
  Absolutely. That's where you'll get the most
• 20:11
  bang for your buck in reducing the overall uncertainty.
• 20:14
  You focus your precision efforts on the most sensitive
• 20:16
  parameters, the ones with the highest exponents or largest
• 20:20
  influence in your calculation. That's a really practical take
• 20:23
  away. Yeah, OK.
• 20:24
  This has been quite a journey. We've gone all the way from the
• 20:27
  high level need for systems thinking and getting
• 20:30
  requirements right. Down through the elegance of
• 20:32
  unified modeling using those ideal elements and analogies.
• 20:36
  Then into the practicalities of control, PID, its strengths,
• 20:41
  pitfalls like reset wind up, and even advanced techniques like
• 20:44
  computed torque. And finally, landing on the hard
• 20:46
  reality of measurement accuracy versus precision loading
• 20:50
  effects, and crucially, how error analysis tells us where to
• 20:53
  focus our efforts. It really paints a picture of
• 20:55
  the whole systematic framework engineers used to tackle
• 20:58
  complexity and actually deliver working systems.
• 21:02
  And maybe one final thought, underpinning all this structure,
• 21:04
  all this math, we have to remember the human element.
• 21:08
  The source material actually points this out.
• 21:10
  How so? It mentions common human
• 21:12
  cognitive biases, things like availability bias, over relying
• 21:16
  on recent info, anchoring like we discussed with requirements,
• 21:20
  selective perception, confusing facts with values.
• 21:23
  These biases can easily lead to flawed judgments, even with
• 21:26
  smart people. So the systems engineering
• 21:28
  process itself helps counteract. That That's the idea.
• 21:32
  By demanding an explicit, structured, iterative process,
• 21:35
  defining requirements clearly, modeling assumptions, analyzing
• 21:38
  trade-offs, checking results, systems engineering provides A
• 21:41
  framework to help detect and correct these potential human
• 21:44
  errors. It pushes us beyond what unaided
• 21:47
  intuition alone can achieve, improving the quality of both
• 21:50
  the design and the decisions made along the way.
• 21:52
  A structured way to keep ourselves honest, basically.
• 21:55
  Great final point, keep your Nets torqued and spring hard
• 21:57
  design junkies.