I find it frustrating when people who are outside the design-review process, or those in the product-reviewer and pundit class, ask, “Why didn’t they [designers and engineers] just add such-and-such feature, or do it this way instead?” Sometimes the reason is obvious and maybe even painful on reflection: perhaps that feature or capability was overlooked, or there was a judgement error in the design specification.
Still, in many cases, the design reality is much more complicated and subtle. When you start getting into scoping out a design at the system level and then drill down into the specifics of the implementation, the design and engineering effort soon becomes largely about managing tradeoffs and balancing the many “wants” against a long list of factors including basic performance, size, power, BOM cost, footprint, complexity, risk, schedule, and manufacturability, among others. Without having insight into the tradeoffs, how they were evaluated, and what “costs” were associated with each, it’s all-to-easy to say, “They should have done that instead of what they did” when the final choice actually involved many issues working against each other.
Making these comparisons and understanding how to assess their impact is both an analytical and a “gut” exercise. Being able to do so is a critical skill and art which experienced designers bring to the party, especially as many of these issues are not amenable to hard analysis. Sure, you can often (but not always) model and analyze the performance of a specific configuration, but how do you judge what the right balance is, and where the “sweet spot” is among the many permutations?
That’s much harder to do, of course, and at present cannot be done in general by an algorithm (although we should “never say never” as AI may do that for us someday!). In many cases, it’s hard to quantify the tradeoffs and the compromises that are possible with respect to each other, as they and their linkages are subtle and not constant but are instead somewhat fluid.
This is not a new situation; it’s been ongoing since the first “designer” took a small step on the path of innovation and improvement. It shows up in many ways, as well. Recently, I was reading an IEEE newsletter in which “old timer” Paul Graham briefly reminisced about one of his first jobs, working as an audio engineer at a manufacturer of police, fire, and ambulance emergency-warning products for cars. The challenge of his project seemed clear enough: streamline the light bar going across the hood to reduce its wind resistance (Figure 1), improve vehicle gas mileage and performance, and provide an effective open grill for the loudspeaker/siren (a horn-loaded compression driver).
Figure 1 The light bar and electronic siren have conflicting results for aerodynamic streamlining versus front-facing audio projection.
This calls for a sleek aerodynamic profile to meet the former goal but a fairly open, forward-facing set of openings for the latter so as to provide good sound dispersion. In short: minimize turbulence as much as possible while meeting the specific sound pressure level (SPL) number. At first, this appears to require conflicting solutions. In his piece, Graham reminded us that in the late 1970s, what we call “wind-flow” computer-based modeling was not available, so they tested models of different shapes of light bar and grill patterns on a vehicle at various speeds, using strain gauges mounted on the bar. The successful outcome included a patent for an “optimum” pairing (Figure 2). The patent has some airflow diagrams to illustrate its analysis and functions (Reference 1).
Figure 2 The resultant patent shows how both goals were achieved with good performance for both. (Source: US Patent 4,334,211)
Note that combining lights and siren in a single enclosure only started in the 1930s. Putting the two functions on a car was previously accomplished via a standalone light (Figure 3) while the earliest sirens were separate non-electronic units powered by the air rushing through them – an anticipatory embodiment of now-popular energy harvesting (Reference 2).
Figure 3 Before the integrated light and siren bar, emergency vehicles often used standalone rotating lights; they are still in use in some situations.
This design and engineering tradeoff and compromise dilemma is not new. Engineers have had to deal with it since “forever” and it is an unavoidable issue on large-scale projects as well as at the small-component level. After all, why do we need dozens if not hundreds of somewhat similar op amps from a given vendor? Certainly, having all these distinct line items in the catalog adds to production costs, but the reality is that each op amp is different in its own unique way.
Some are significantly superior in one specification but only “just OK” in others (such as very high speed for the former versus somewhat higher dissipation for the latter), while others have a subtle blend of “all pretty good but none really great” as their claim to fame. The designer has to evaluate the choices and decide what makes sense with respect to the project objectives, constraints, and priorities.
What sort of engineering tradeoffs and compromises have you wrestled with? Did you have difficulty explaining them to, or defending them with, your design team? What about with your management? How about with the end customers?
- US Patent 4,334,211, “Speaker Grill for Streamlined Light Bar Mounted on Vehicle Roof,” June 8, 1982.
- Auto Evolution, “History of Police Lights and Sirens,” 4 Feb 2012
- Do We Really Need Yet Another Op-Amp?
- Op amp overcomes precision/protection tradeoff dilemma
- Is Analog-IC Design Still So Special?
- Learning to like high-voltage op-amp ICs