Comparing Off-The-Shelf to Custom Designs for Industrial Embedded Systems

CONSIDERATION #1: Time and Money

Cost is almost always the number one concern for companies when building a product: cost in time and cost in money. In terms of the bottom line, the smaller the costs accrued in prototyping and the faster the new revenue appears, the better the company cash flow position.

Let’s look at some of the largest costs for creating the prototype and end-product.

Custom

Since the Custom path requires that the prototype be developed from scratch, the non-recurring engineering (NRE) effort is very significant right from the start.

This large NRE arises from a development flow similar to the following list.

• A hardware designer must first design the PCB schematic and then layout the board to specification, since the board is being made from scratch.
• After the layout is finished, it can take approximately two weeks to spin the PCB. For expedited delivery times, an additional fee must be paid.
• If a bug is found on the PCB, it will take additional design effort and another two weeks to fabricate the revised board.
• If there are mechanical issues, noise problems, backward connections, or any number of bugs, reworking the hardware can significantly delay the project timeline and considerably increase NRE design costs.
• The software development effort can start in parallel with the design and build of the prototype PCB. However, as all software developers can attest, the real work begins only when the hardware is available and debugging in real-world situations can occur.
• Additional tweaks to the PCB and software can occur during the application development, when the application doesn’t perform as expected.

COTS

COTS solutions tend to have a shorter prototyping phase, since the hardware is ready-to-use out of the box and troubleshooting involves only rewiring, reprogramming, or changing the types and quantities of COTS I/O modules. Hence, most of the effort is in software development, and the NRE in prototyping will be smaller than for the Custom approach.

However, you may need to consider converting your COTS prototype into a Custom design for various reasons such as size, power, unit cost, and maintainability, reasons that are likely driven by market desires that force you to remake your prototype into something that your potential customers will buy.

If you do have to rework your COTS prototype, then the NRE will grow, possibly even larger than the NRE in the Custom approach.

The best argument for staying with COTS for your end-product is when either:

• You are not sure your product idea is viable (you can “fail fast” with COTS)
• You don’t think you will be selling many units (so “low” unit cost is not the main driver of sales) and form factor is not an important sales attribute.

If neither of these reasons apply, the COTS approach will very likely end up converted to a Custom approach and hence as expensive as the Custom route.

Hybrid

Since a Hybrid approach tries to balance the benefits of the COTS and Custom approaches, the NRE can beabout the same for prototyping as the COTS approach. Further, you likely will start with close to the same form, fit, and function as the prototype when it’s time to move to production, leaving total NRE lower than either COTS or Custom.

Specifically, this reuse benefit appears when you select the same COTS embedded controller that would be used in your end-product and coupling it with COTS I/O. This hybrid combination brings you closer to the form factor your end-product needs than would COTS alone. However, note that, if you need some I/O that is not available as COTS, then some Custom I/O will need to be developed and the NRE will increase but only proportionally to the amount of COTS compared to Custom I/O you require.

CONSIDERATION #2: Performance and I/O

Your prototype and end-product need to be capable of reacting to inputs, processing data, crunching algorithms, and updating outputs as quickly as needed for your product’s application. Achieving this throughput requires both a controller powerful enough to handle all the tasks and I/O with enough bandwidth, precision, accuracy, and damage protection from the outside world.

The controller market is very mature and offers a broad range of products, from tiny, low-power, very simple microcontrollers to high-speed, fully-featured 32-bit computers. The on-chip peripherals can include:

• Memory (EEPROM, RAM, and Flash)
• Communications (CAN, Ethernet, RF, USB, I²C, SPI, and UART)
• Timers/counters
• PWM channels
• Encoder interfaces
• A/D convertors
• Graphical and touchscreen interfaces
• FPGA

Besides the controller, analog and digital I/O capabilities will be needed. Not only does the controller need to support the appropriate channel count and speeds, you will need signal conditioning between the controller chip and external sensors and actuators.

Also, you may wish to consider an FPGA to offload time-critical acquisition and processing from the controller. A Field Programmable Gate Array (FPGA) is a special integrated circuit consisting of logic blocks with interconnects that can be programmatically “rewired” via VHDL (VHSIC Hardware Description Language) to create different complex applications. Moreover, FPGAs can execute algorithms in parallel with no task switching.

Often, we find that domain experts, while expert in their field, have little experience with embedded technology, and they can be overwhelmed with so many options when trying to choose an embedded controller and I/O for their product concept. Let’s review some of these options.

Custom

Embedded controller companies offer many reference designs that can be leveraged for use in your prototyping circuitry. Many of these reference designs use support ICs made by the same company that makes the controller, so you can gain the benefit of additional components being from a one-stop-shop.

To assist, many companies offer pre-assembled development kits (also called eval boards) that have the controller and a number of features already implemented to help streamline prototyping for certain types of applications. Keep in mind that these starter boards are created as demo versions of the manufacturers’ product, and will often still require heavy customization to become prototype-ready.

For software development, controller companies often provide in-house C and assembler compilers, along with many third-party vendor toolsets. Any FPGA component is usually programmed in VHDL. The application software typically runs on either Linux or some real-time operating system (RTOS). Several RTOS choices are available, including real-time versions of Linux.

For the I/O in a custom prototype, the channel granularity matches the requirements precisely, and you pay only for the necessary features, thus minimizing price per unit of your product. Furthermore, when the system requires support for special sensors and signals, signal conditioning, or signal connections that are not readily or inexpensively available as COTS, or may require many intermediate COTS products, then building a custom solution is more reasonable than buying a COTS solution. It will likely be more straightforward to build the prototype from ground up so that the specifications – such as noise performance, voltage levels, or dynamic range – are not compromised by the availability of COTS products on the market and instead are exactly tailored and optimized to the product’s needs.

COTS

With the COTS approach, you will want to consider a COTS embedded controller that is also ready to accept I/O modules without the need for any customization. Also called Embedded CPUs or Embedded PCs, these controllers will be plug-and-play compatible with COTS I/O modules. Some examples of such systems are the National Instruments CompactRIO and systems based on single board computers utilizing PCI plug-ins for the I/O, offered by such vendors as ADLINK, Advantech, Arduino, Raspberry Pi, and many others. These systems often run a version of Linux for the operating system and some are real-time.

With all these COTS components readily available for purchase, the COTS solution is generally more adaptable to change and the COTS solution can usually be easily modified during multiple prototype revisions.

For instance, the prototype may need just one current input channel, but the COTS supplier only sells modules with four current inputs each. The downside is that three extra channels were purchased and may never be used, taking up both space and budget. The upside is that if the prototype does need more than one current input, the additional channels or modules are immediately available for use and little time is lost. Also, the extra I/O can come in handy for monitoring or troubleshooting an issue on the prototype.

As another example, if the prototype unexpectedly needs an analog output, the COTS supplier likely already has a module for sale. Again, the downside is that additional budget and space have been consumed, but the upside is that a solution was readily and rather inexpensively available.

However, COTS analog or digital I/O boards may not offer adequate connection schemes because of signal speed, channel-to-channel isolation, signal conditioning, or connector requirements. In those cases, custom circuitry and hardware may need to be built in order to add special functionality to COTS systems, which can increase time and cost.

Hybrid

The hybrid approach can utilize both a COTS embedded controller and pre-developed COTS I/O. Connecting this COTS hardware into a prototype system is certainly simpler than the Custom approach and is only slightly harder than offered by the COTS approach. The benefit of the Hybrid approach stems from the ability to develop the prototype close to the same timeline as the COTS prototype and minimal post-prototype customization since so much of the COTS hardware can be reused.

It is important to note that ease of rework to convert the prototype into a ready-to-sell product implies either that 1) the COTS I/O is directly suitable for your product or 2) you have access to the COTS I/O hardware designs so that you can (or the supplier of the COTS I/O will) re-layout only the necessary I/O components into your own specialized I/O board.

CONSIDERATION 3: Product Life Cycle

Selling a product is the ultimate goal. Consequently, consideration must be given to the number of units you expect to sell and the timeframe in which they will sell: do you have a large backlog of customers anxiously waiting to purchase your product or will the product sales ramp over several years? We want to understand the impact of NRE and future product updates on the unit costs of the product over the several years it will be sold, simply because you will want to recoup your NRE investment and quickly.

Let’s explore the COTS versus Custom options to understand the impact of sales on the production life cycle. For the purposes of scale, let’s say that “high” volume sales mean anything larger than 50 units per year. In our experience, the crossover of unit cost between the various COTS, Custom, and Hybrid approaches is often between 10 and 100 units (total, not per year).

Custom

If you know or suspect that you will have “high” volume sales, then starting with a Custom approach is going to give you the lowest unit cost as quickly as possible. The NRE will be highest for this approach, due to all the custom development work and any possible certifications you might need (such as a CE Mark), but the Cost Of Goods Sold (COGS) will be as small as possible. Spreading the NRE costs across each unit sold for this “high” volume situation allows you to keep unit pricing low because you’ll recover your NRE “quickly”.

However, if you do not expect to have “high volume” sales, then this Custom approach is going to make the unit price high for a “long” time. Unless you have a strong reason to follow this approach, such as size or power constraints that your customers demand, use one of the other approaches.

An important benefit of the Custom approach is that longer term modifications, warranty support, and parts life cycle management will be in your direct control, since you have access to all the designs and parts lists in your product build.

COTS

The COTS approach is best suited to “low” volume sales, especially if the customer places minimal constraints on the product design, such as size and power. For example, if your product already has a large enclosure for motor controllers and power supplies, an embedded PC or embedded controller can be very effective. Furthermore, if controller and I/O are a small fraction of the cost for all the remaining components in your product, then unit costs for the embedded system may be less important than reducing costs elsewhere, and you may be able to tolerate using COTS, even for “high” volume sales.

Furthermore, if you are using these initial unit sales as a way to build understanding of your customers through the early adopters of your product, then the COTS approach is especially beneficial, since you can make an updated version quickly compared to the other approaches discussed in this paper.

The life cycle management of a COTS approach offers the advantage of pushing the management of the parts life cycle onto the supplier of the COTS components. Warranty handling can be simplified when using COTS, since the supplier takes much of the risk in product failures. Worldwide support networks often exist for the larger COTS suppliers, and your customer halfway around the world can get a replacement part delivered and possibly installed by the supplier instead of needing to ship parts around the world and talking (or traveling) to the customer for the replacement procedure.

Hybrid

The Hybrid approach combines the benefits of a “low” unit COGS with a “medium” NRE to enable a rapid time to market with reasonably “low” unit costs. This benefit appears because the COTS controller is merged with some combination of COTS and Custom I/O. Thus, this approach can be effective for both “low” and “high” volume sales.

Longer term modifications, warranty support, and parts life cycle management are partly in your control and partly controlled by the vendor of your COTS components. In our experience, your custom parts are often tailored to your product in ways that would make a COTS approach too expensive or even not available. Often, these custom tailored parts are a differentiator for your product (easier field connections, higher signal to noise, etc.), and you would prefer to keep life cycle control over these custom parts, rather than turn over that life cycle management to a COTS supplier. Thus, the Hybrid approach places life cycle management of specific components with the most appropriate people.