Good enough is exactly that
Scott Rosenthal
August, 1998
Ship it! We've all heard these words from our bosses. But what constitutes "good
enough to ship"? What design tradeoffs must you make to meet market requirements?
What's the difference between the design lab and the real world when it comes to shipping
products? And how do these considerations pertain to embedded systems?
It's no secret that companies stay in business by shipping products. It's a simple
equation: A company ships products that its customers want. They pay for the product, and
you get a paycheck. If the money coming in exceeds product cost, you keep a job and
probably also get adequate tools to do a better job. Conversely, if you don't ship any
products, no payments arrive from customers, and you lose.
The embedded software realm is quite different from other engineering disciplines when
it comes to what's good enough to ship. In the mechanical world, people can touch and feel
an engineer's product. Rigid rules exist for what will and won't work. For example, a
finger hole to open a cabinet must be at least a certain size, or the force to turn a knob
must be less
than a certain value. Designers can fall back on commonly accepted criteria during product
design.
In the embedded world, though, you won't find accepted norms for what is and isn't
acceptable. A simple example of this free-for-all is the beep that sounds after a keypad
press:
- Should there be a beep at all?
- How loud should it be?
- How long should it sound after a keypress?
- What should it sound like?
- If the user holds down a key should the beep also repeat?
- Should the user have the option to disable the beep?
Obviously, someone must answer these questions before finishing an embedded design.
Further, you can probably see that some of these issues concern software, while others
relate to hardware. So what happens if-after carefully studying all these tradeoffs,
designing the system and getting it ready to ship-someone (such as a potential customer)
decides that the beep implementation is substandard? Do you ship the product? Do you redo
everything possible in software and ignore hardware changes? Or do you implement all the
changes?
To ship or not to ship?
Unfortunately clear-cut answers don't exist. So I turn to a handy rule of thumb when
determining whether or not to ship: if the "problem" won't impact sales (and
thus money flowing into the company), I recommend shipping the system and ignoring the
problem for the present. If the problem causes an impact on sales, you must estimate the
cost of the problem and the solution-and don't forget the possible expense associated with
delayed market entry, disappointed customers and bashing by the competition.
If you noticed, I said to ignore the problem for the present. Every product I'm working
on has an associated wish list. This list should contain ideas for improving the product
including new features and manufacturing improvements. Then, at regularly scheduled times,
perhaps twice a year, the design team weeds through the list, keeping what makes sense
while
discarding outrageous ideas and scheduling the next release.
Such incremental improvements allow continued shipping and keep cash flowing while
tuning the product to market needs. Yet some companies won't release a product until it's
perfect. Unfortunately, in reality a perfect product never exists, and trying to design
one takes an inordinate amount of time that can sink a company. I remember reading that
Sony introduced a new Walkman every three weeks instead of trying to design the ultimate
unit. While most of us couldn't produce a new model at that rate, we can learn to ship a
product when it meets most marketplace needs. Understand that I'm not advocating letting
the customer debug the product. But you must make a conscious decision as to when it's
good enough to ship.
Hardware vs software
Another major "what's good enough" criterion for embedded systems comes from
deciding what belongs in hardware vs software. I've seen products designed with three
major philosophies:
- Put as much as possible into software and ignore the extra processing power the system
might need.
- Put as much as possible into hardware to reduce the software chore.
- Implement in hardware whatever you're familiar with and then use software to implement
the stuff you don't know how to handle.
The tradeoff between hardware and software presents a difficult decision for most
products. I've probably spent more time making these tradeoffs than actually designing
hardware. Remember, too, that hardware brings along a recurring cost for every unit
produced, and don't forget that the more hardware a product contains, the more chance that
a unit can fail in the field.
Software design and complexity, though, can quickly overwhelm the cost savings of
moving features over from hardware. I try to anticipate the future, think about what might
change within the product and how the design (both hardware and software) would change to
accommodate the requirements. For example, on a measurement and control system, the
following often change:
- The loop-control time might decrease for better control.
- The system might store more parameters than the initial requirements spec'd.
- The required analog resolution will probably increase with time.
- The math-processing requirements will probably increase.
- The system might need more analog inputs to handle additional sensors.
Just like practicing defensive driving, you can also design embedded systems with
caution. In the above example I'd probably create a system with the following features:
- One or more extra analog input channels, if these channels won't easily fit into a
design, leave room-not just board space, but also chip-select lines and loading
capacity-for an additional chip you could later load if needed.
- Make sure processor bandwidth has sufficient room to add 50% more capability. Today this
aspect generally doesn't significantly impact processor cost, but it could affect the
device's EMC characteristics and power usage.
- If not outrageously expensive, design in an A/D with more bits of resolution than what
the application presently calls for, such as going from a 10-bit to a 12-bit converter.
Again, the upgrade entails little cost difference, but it might extend the life of a
product line.
- Design software to easily allow additional sensor inputs for use in the control loop or
for recording control quality. Good structured design with object-oriented philosophies
easily allow new features without destroying existing code.
One thing I do try to avoid is eliminating any hardware control loops. Sometimes
they're necessary, but if the software does this chore, you'll have more control over
future changes, plus it'll be easier for a technician or ATE device to diagnose a problem.
Real world vs the lab
Another potential problem involves designing a product that, in addition to meeting
market needs, must also adhere to a design lab requirement. Too often, lab standards dwarf
a product's real-world requirements. For instance, medical devices often need an R&D
mode that allows users to bypass calibration and gather data for trials. Once the product
ships, though, it must operate in clinical mode where you don't give users access to
critical setup data and don't need to pay for data logging. The additional complexity
drives up both production cost and the design effort. Be careful going down this path.
It's too easy to design something for the lab and forget about the product's intended use
and where the company's money comes from. If the lab really needs special requirements, it
might be better to design a parallel product instead of saddling the production model with
the needs of just a few. I've driven down this path, and each time I've been challenged to
focus on the product and keep away from lab needs. PE&IN
Adapted from an article that appeared in Personal Engineering & Instrumentation
News.
Return to the article index.
|
