The build-or-buy conundrum - Embedded.com

The build-or-buy conundrum

Some years ago I visited Agilent's oscilloscope division in Colorado Springs. They had just finished designing the “Infinium” series of scopes. The product was — and is — impressive. Still more interesting was their development approach. The engineers told me that every time they started work on a new product they'd first design the device's computer board.

But Agilent is not a computer company. Why, they wondered, focus on endlessly creating embedded computers instead of zeroing in on the product's application?

This minor revelation shaped the Infinium's entire development strategy. Instead of an embedded computer the scope uses an off-the-shelf PC motherboard.

Revelation number two: why spend so much time and effort getting a cranky embedded RTOS and complete environment going? The Infinium runs Windows, autostarting the scope app once the OS boots.

These two decisions cut man-years from the development process. Designers immediately jumped into the meat of the product, building hardware to suck in analog data at astounding rates, and writing code to display and interpret this data.

I imagine Agilent sells thousands of these scopes each year. Not millions — it's not a high volume product like a cell phone. The average price is many thousands of dollars, so there's room to increase costs — some — to shorten development time. That PC motherboard is surely not the cheapest solution, but cutting man-years of effort saves money over the product's entire lifecycle.

In my job as embedded gadfly I look into the workings of an awful lot of companies building products. A phenomenal number never balance the non-recurring engineering (NRE) versus cost of goods equation. The math is simple: if it costs X dollars to develop a product, and Y units are sold, then the engineering cost per unit is X/Y. It's a cost that is as real as the price of the chips and resistors, as the RTOS licensing fees and the plastic enclosure.

NRE is a cost that must be amortized over the product's lifecycle. To do otherwise means you can't make intelligent engineering tradeoffs. Spend half a mil on an ASIC and, if volumes are low, the per-unit cost of that chip is thousands of dollars. Does this make sense for your product? Add these thousands to the production cost of the product – is it still profitable? If not, you're going broke.

(Of course, there are cases where other factors intrude — size, power dissipation, and the like may overwhelm simple cost drivers).

Maybe you really do need to design that 8051-based board, but sometimes it's far cheaper in the long run to adopt a more expensive solution like a Basic Stamp. The Buyer's Guide, on this site, lists hundreds of vendors pushing all sorts of COTS boards. In low volumes I'll bet you can't beat what initially might seem like the high prices of these done, tested, working-today solutions.

To design, debug, respin, retest, document and productize a moderately complex PCB with an 8- or 16-bit processor will cost at least $25k, and $100k is not out of the question. Thirty-two-bitters will be more.

If size, power and other factors aren't a huge issue, and if volumes are low, how can a responsible designer not pick a COTS solution?

Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. He founded two companies specializing in embedded systems. Contact him at . His website is .


Reader Response

The Avionics industry was one area where the COTS approach had trouble “flying” often.

The many rigorous tests spelled out in RTCA DO-160-D often spelled doom for COTS computer boards that were not well protected by additional hardware, and a good case.

ESD, HIRF, Lightning induced transients, temperature extremes, vibration, chattering relay tests, and a host of others all would play havoc on an un-protected COTS CPU board.

I expect the same is true to a lesser extent for automotive, marine, and similar electronics.

Bill Murray
Design Engineer, Baseband
Nokia


While I agree with your column in general, I must disagree with a couple of specific cases that you mention.

First, there are a lot of problems with using an “off-the-shelf PC motherboard” for an embedded application. I have done this, and it took a lot of time and testing to find one that would work reliably in a real-time industrial environment. Then after six months you can no longer get the exact same motherboard, and you end up going through all the searching and testing every six months. Not to mention changes in motherboard form factors, geometry, and connectors affecting your mechanical design. A better solution is to get an off-the-shelf embedded CPU board, although more expensive.

My second disagreement is with using Windows instead of a “cranky embedded RTOS.” In my experience Windows is a far crankier OS than any embedded RTOS that I have used. This sounds like a statement from someone who is comfortable only with Windows and does not understand embedded real-time programming nor RTOSes.

Harold L. Dewar
Free-lance curmudgeon


This basic concept should be taught at every engineering school. Personally, I think every graduating engineer should do a 20 page paper, including a financial analysis of this. So many people burn money, time to market and opportunity cost without thinking. If it is not your core product, justify the engineering effort. We are adding gigabit ethernet to our video cameras. You bet I want to license it for all those reasons. And continued product improvement and support.

Steve Nordhauser

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.