标签: engineering design

Finding solutions to problems is one considerable part of the engineering design process . By "solutions", I don't mean finding bugs once the design and development are underway; I do mean figuring out the "best" way to accomplish a given task. That's the design engineer's dilemma. There usually is no single "best" solution or even a single solution; instead, in most cases, there is an array of viable choices. Each brings with it tradeoffs in size, performance, cost, power, reliability, test time, fabrications time, and other design factors. I sometimes use the example of planning the best route for a space mission from Earth to another planet: Is your priority travel time? Minimizing fuel use? The need to rendezvous at a specific point in space? Or at a specific time? Or is it some combination of all of the these? That's why navigators will usually say they have worked out "A" solution, rather than "THE" solution to the captain's request. This is not a straightforward problem such as "what is the sum of 1 + 1 but, unfortunately, that's how too many people with limited understanding of the unavoidable nature of tradeoffs perceive design and implementation. That's one of the many reasons I get so frustrated when critics who know little of what went into design decisions are so quick to demand answers, after the fact. "Why didn't you do this?" "Shouldn't you have done that?" "Couldn't you have done it this way?" The answer is "sure, but then we'd have to give up or change other specifications", which is a fancy way of saying "there is no such thing as a free lunch." There is a big difference between weighing the tradeoffs and making decisions, versus taking cheap-and-easy shots in hindsight. Once in a rare while, there are situations where the tradeoff cost is small and clear. For example, boosting your voltage rails to reduce current at a given power level (and thus reduce losses), has only a modest cost, in the need for step-up and step-down stages; that's why nearly every higher-power design uses higher voltages. It's just so much more efficient, that the choice to go with higher voltages/lower currents is almost a "no brainer." Sometimes, just sometimes, even nature smiles at us with a no-tradeoff construct. Consider the brachistochrone curve. No matter where you place the ball on the curve, the time it takes for it to reach the bottom is the same. It's somewhat counterintuitive, but it's both provable in theory and demonstrable in practice. If only more design decisions were like that! Have you ever faced design tradeoffs that were painful, and were not easily explained? How did you handle the situation?

A huge part of the engineering design process is dedicated to finding solutions to problems. By "solutions", I don't mean finding bugs once the design and development are underway; I do mean figuring out the "best" way to accomplish a given task. That's the design engineer's dilemma. There usually is no single "best" solution or even a single solution; instead, in most cases, there is an array of viable choices. Each brings with it tradeoffs in size, performance, cost, power, reliability, test time, fabrications time, and other design factors. I sometimes use the example of planning the best route for a space mission from Earth to another planet: Is your priority travel time? Minimizing fuel use? The need to rendezvous at a specific point in space? Or at a specific time? Or is it some combination of all of the these? That's why navigators will usually say they have worked out "A" solution, rather than "THE" solution to the captain's request. This is not a straightforward problem such as "what is the sum of 1 + 1 but, unfortunately, that's how too many people with limited understanding of the unavoidable nature of tradeoffs perceive design and implementation. That's one of the many reasons I get so frustrated when critics who know little of what went into design decisions are so quick to demand answers, after the fact. "Why didn't you do this?" "Shouldn't you have done that?" "Couldn't you have done it this way?" The answer is "sure, but then we'd have to give up or change other specifications", which is a fancy way of saying "there is no such thing as a free lunch." There is a big difference between weighing the tradeoffs and making decisions, versus taking cheap-and-easy shots in hindsight. Once in a rare while, there are situations where the tradeoff cost is small and clear. For example, boosting your voltage rails to reduce current at a given power level (and thus reduce losses), has only a modest cost, in the need for step-up and step-down stages; that's why nearly every higher-power design uses higher voltages. It's just so much more efficient, that the choice to go with higher voltages/lower currents is almost a "no brainer." Sometimes, just sometimes, even nature smiles at us with a no-tradeoff construct. Consider the brachistochrone curve. No matter where you place the ball on the curve, the time it takes for it to reach the bottom is the same. It's somewhat counterintuitive, but it's both provable in theory and demonstrable in practice. If only more design decisions were like that! Have you ever faced design tradeoffs that were painful, and were not easily explained? How did you handle the situation?  

It's not news that engineering design and debug is an exercise in investigation and problem solving. After all, if it were not for the constraints of price, time to market, and performance, all afflicted by bugs, unexpected issues, and mysterious observations, engineering would be "simple", relatively speaking.   But, to steal a phrase, there are problems, and then there are problems. In Volume 1 of his classic textbook Detection, Estimation, and Modulation Theory (full disclosure: I barely made it through this first volume of the three-volume set), Harry L. Van Trees identified three classes of signal theory problems:   Detection: Finding a known signal in noise; where "known" means the signal is binary and you just need to know if it if there or not Estimation: Assessing the one-time value of an unknown signal in noise, where the value is analogand its value can be anywhere within a specified range Continuous estimation: where the challenge is to demodulate a continuous, unknown (analog) signal, again in noise   Van Trees also emphasized that the more we know about the nature of the random noise, the better job we can do at any with these three classes. Often, we assume the noise is Gaussian, either because it really is, or because it's all we can deal with. In reality, noise can also be impulse, pink, or have time-varying or cyclostationary mean and other parameters, to cite a few of the many possible variations. (Let's be honest: it wasn't for noise, our engineering lives would be oh-so-much easier.)   Even though many of us do not have to deal directly with detection, estimation or continuous estimation, we do have to deal with problems that are analogous. When reading about the Apollo space program (one of my favorite pastimes), I found that the project teams also divided problems in three groups: the knowns, the unknowns, and the unknown unknowns.   Known problems were those that were well understood, and the solution was relatively easy and cost-free, such as changing a component value in a circuit. Unknown problems were those which were understood fairly well, but the available solutions were unpleasant and involved serious trade-offs and costs in time, performance, and execution.   But the most challenging of all were the unknown unknown problems , where you did not understand the nature of the problem, or that you even had one—at least, not yet. And that was the class that worried the project team the most.   Of the three, what kinds of problem experience do you have? Are they mostly in the known category? Or is your project rife with unknown unknowns? And if the latter, what can you do to minimise their number or severity?

It's not news that engineering design and debug is an exercise in investigation and problem solving. After all, if it were not for the constraints of price, time to market, and performance, all afflicted by bugs, unexpected issues, and mysterious observations, engineering would be "simple", relatively speaking.   But, to steal a phrase, there are problems, and then there are problems. In Volume 1 of his classic textbook Detection, Estimation, and Modulation Theory (full disclosure: I barely made it through this first volume of the three-volume set), Harry L. Van Trees identified three classes of signal theory problems:   Detection: Finding a known signal in noise; where "known" means the signal is binary and you just need to know if it if there or not Estimation: Assessing the one-time value of an unknown signal in noise, where the value is analogand its value can be anywhere within a specified range Continuous estimation: where the challenge is to demodulate a continuous, unknown (analog) signal, again in noise   Van Trees also emphasized that the more we know about the nature of the random noise, the better job we can do at any with these three classes. Often, we assume the noise is Gaussian, either because it really is, or because it's all we can deal with. In reality, noise can also be impulse, pink, or have time-varying or cyclostationary mean and other parameters, to cite a few of the many possible variations. (Let's be honest: it wasn't for noise, our engineering lives would be oh-so-much easier.)   Even though many of us do not have to deal directly with detection, estimation or continuous estimation, we do have to deal with problems that are analogous. When reading about the Apollo space program (one of my favorite pastimes), I found that the project teams also divided problems in three groups: the knowns, the unknowns, and the unknown unknowns.   Known problems were those that were well understood, and the solution was relatively easy and cost-free, such as changing a component value in a circuit. Unknown problems were those which were understood fairly well, but the available solutions were unpleasant and involved serious trade-offs and costs in time, performance, and execution.   But the most challenging of all were the unknown unknown problems , where you did not understand the nature of the problem, or that you even had one—at least, not yet. And that was the class that worried the project team the most.   Of the three, what kinds of problem experience do you have? Are they mostly in the known category? Or is your project rife with unknown unknowns? And if the latter, what can you do to minimise their number or severity?