Design trade-offs for product development - Embedded.com

Design trade-offs for product development

ByteSnap is in the business of designing new products for customers, and one of the pleasures of the job is hearing about interesting new ideas that customers have and trying to work out a good route to market for them. Once the project has been discussed, the conversation often follows this course: “I know it is hard for you to say, and I won’t hold you to it, but how much do you think it will cost, and how long will it take?”

This is an understandable question; often the customer is trying to establish whether something is actually financially viable. Without a spec, only a rough idea can be given, and there are always lots of decisions to make in the design process. That is why electronics is an art. Give the same specification to ten engineers and you will get ten, possibly wildly different, designs, all of which may meet the specification perfectly. However, one of those designs will win in terms of unit cost and another (probably not the same one) will win on development cost. A third may have the best technical specification, though providing they all meet the original spec, do these enhancements matter?

This article seeks to explore some of the key trade-offs made when designing a product, with reference to the software and electronic design aspects. It focuses primarily on the commercial and time implications of these decisions.

Balancing time, specification and unit price
So how does one go about deciding on these trade-offs? The first thing is to identify what is being traded (Figure 1).

Figure 1. The starting point when considering design trade-off factors

The design engineer has to balance the three factors of technical spec, development cost, and unit price. To make the best choice of where the bias should be, these factors are considered:

  • Time to market
  • Available development budget
  • Target market sale price
  • Anticipated annual sales volumes
  • Value in exceeding or modifying the specification

Unfortunately many of these are not hard values and, in particular, the anticipated volume can be a wild guess, as anyone who has watched Dragons’ Den will have witnessed! Feeding these factors in can skew the decisions like this shown in Figure 2 .

High annual volume:

Figure 2. The initial planning for a product where units will be built in large numbers shows that the unit price is the overriding design consideration.

It’s all about the unit cost. But then what if the time to market pressures are high? As shown in Figure 3 , the choice may be to use a greater proportion of off-the-shelf, modular hardware, at the expense of unit price and technical spec.

Figure 3. High time to market pressure: design choices need to reflect the focus on reducing development cost and time.

Give it to an engineer without guidance and you may end up with something that is over-engineered and expensive but will still be around and working long after we are all pushing up daisies (Figure 4 ).

Figure 4. Given a free choice, engineers tend to make design choices that focus on the best technology and features at the expense of development time and unit cost.

At the center of the technical decisions are the trade-offs between the use of software vs hardware. The software cost doesn’t appear on the bill of materials generally, but it is far from ‘free’. Software development can be extremely onerous and, in a typical project that we carry out, the software cost (application plus drivers) makes up about 2/3 of the overall development cost. Choice of components can have a fundamental impact on the software development time. As a result there is often a conflict between this time and the unit cost as shown in Figure 5 :

Figure 5. In embedded designs, using more costly components can often help reduce software development time (and vice versa).

So how does all this equate to decisions in a real project given that the ideal is minimum development time, development cost, and unit cost? Let’s look at a real world example, our experience with a head-up display for a bike.

Simplifying a motorcycle head-up display design
We were commissioned to design what was a fairly radical product, a head up display (Figure 6) for a motorcycle. Initially the customer needed a proof of concept to try out a variety of features. He wanted minimum development time and cost plus maximum technical flexibility. Unit cost was immaterial at this stage, as it was not a production product.

Figure 6. The motorcycle head-up display, BIKEHUD, installed in a helmet.

To meet this requirement, we made two key decisions. The first was to use an operating system, which allowed for easy peripheral expansion, rather than going for the lowest cost microcontroller with bespoke drivers and code. Secondly, we decided to use a single-board computer as a prototyping platform and to add an expansion board to this, rather than creating a full-custom solution.

The prototype weighing of factors may have been represented like this shown in Figure 7 :

Figure 7. For the BIKEHUD prototype, features and time to delivery were more important than unit price.

While for production, it would be represented as in Figure 8 :

For the production of BIKEHUD, unit price was important. We focused on features and cost, so consequently development time and cost increased.

We chose an Olimex OLinoXino card, as it supported operating systems (Linux and Windows CE) and had more than enough horse power for our needs. It was also open-sourced in the hardware department, unlike some other contenders (Raspberry Pi for example), so we knew we could modify the design and create a full custom solution at a later date. We created an add-on board for it with hardware specific to the system, such as RPM measurement and GPS.

Once this system was working and the concept proven, we then evaluated whether it could actually be used in production, to reduce time to market and development cost. It was clear to us, from an engineering perspective, that the solution was not robust enough for production, here the technical specification needed to poke its head up and trump the financial and time considerations. However, having taken a big step forward, much of the risk had been taken out of the project.
Risk
As shown in Table 1 , we could divide project risk into three areas corresponding to the trade-offs discussed earlier:

Table 1. Dividing up the project risk

Sowhat are the trade-offs and factors that are at odds with the cost ofproduct development? The more common decision points and trade-offsinclude:

Balancing development time vs. development cost

Balancing bill of materials (BOM) cost vs. risk

Software vs. hardware integration

Reference software packages vs. production ready code

Should software or hardware platform choices drive product development?

We look at each of these considerations in more detail below.

Development time vs. development cost

Whetheryou have your own development team or outsource the work, in generalthe development cost of a product is proportional to the time it takes.So in essence you are getting hit twice over when overruns occur, oncewith the cost and once with the time to market.

There are waysof divorcing these two factors. If your development is being carried outby a development team on a fixed price basis, you are passing thetimescale risk onto them and thus they foot the bills for overruns thatare not your fault.

The purchase of third party softwarelibraries can reduce software development time while increasing thedevelopment cost. Further licensing costs will also impact the unitcost.

Bill of materials (BOM) cost vs risk

Broadlyspeaking, the level of risk is the difference between an accurate timeand cost estimate and an inaccurate one. So zero risk means that theproject will execute inside time and cost projections. High risk meansthat it may wildly deviate from these estimates. System plannersgenerally aim to eliminate as much risk as possible, to allow for themost accurate budgeting possible. This has the potential downside thatoptimization of the BOM cost may not happen and is a reason whydevelopment costs are often at odds with BOM costs.

To minimize aBOM cost, often some level of experimentation of uncertain timeduration is required. The risk here is to timescales for the customerand to costs for a contractor who has quoted fixed price for the work,or equally internal costs being burned by an engineering team. To thisend, BOM cost optimization is often best done after the technical designgoals have been met, so that time to market impact is minimized.

Software vs hardware integration

Carryingout either software or hardware design divorced from the otherdiscipline is not likely to lead to the optimal solution. The reason isthat there is a trade-off between what the software and hardware does. Aproject that is purely software driven may result in an expensivehardware platform to support it. This is reminiscent of the ‘bloatware’that is often complained about in PC-level systems. In this scenario,ever more powerful hardware features are introduced, and yet all toofrequently the software support is not added to utilize these features,software ‘grunt’ being used instead because it is easier to implement.

Theopposite approach of hardware design without reference to softwareengineers can lead to different problems. For instance, a microprocessormodule may have its operating system shipped as a binary board supportpackage (BSP) rather than as source code, with limits on which I/O pinscan be used, and how peripherals are mapped to the I/O. Just looking atthe data sheet for the module can lead to a false sense of securityduring the design.

Similarly, choice of peripherals modules suchas WiFi is driven more by availability of software drivers for thetarget operating system than by the cost, size, etc. No matter how goodthe hardware is, if the software isn’t available to use it, it probablyis an unsuitable solution. An example of this is the lack of supportedWiFi solutions for Windows CE 7, which for at least one project that wehave undertaken has lead us to revert to Windows CE 6.

Again,this is an example of the link between software and hardware. Windows CEis a great product, but without suitable hardware support, it isunsuitable for many modern connected designs. We see a similar problemwith Android for embedded applications, though, in this case, theproblem will solve itself due to the huge uptake of the OS.

Reference vs production-ready software

Whatis meant by a reference software package (e.g. a BSP) vs ‘productionready’ code? This matters, as the resulting software developmenttimescales can differ greatly.

As System-on-Chips (SoC) havebecome ever more complex, it has become incumbent on the suppliers tosell large amounts of source code to support their devices in order toremain competitive. As discussed previously, if such code is notavailable a competitor’s product generally will have something and theSoC may not be chosen as a result.

However, this is not to saythere is no software work to do! Far from it. A reference BSP is justthat – a reference. It is unlikely to be optimized, it will probably bebuggy, and it’s not likely to support all the features. Some softwarevendors use such BSPs as a way of generating ongoing consultancy income.

A production-ready BSP should have a clearly defined set offeatures that are bug free, and importantly, if bugs are found, thevendor will take the responsibility to fix them, or to change theirspecification.

So production-ready code is more valuable, andcomes at a price – either being locked to a hardware platform (e.g. CPUmodule), or being sold with a license fee attached. The referencesoftware package is usually free.

An example of how this canaffect a project was in some work we recently undertook. We used amanufacturer’s ARM-based SoC which had integrated hardware MPEG decodeand encode. We were using this CPU primarily for this function and theBSP appeared to support it.

However the performance was lousyand it soon transpired that not only was the decode very limited in theexact flavor of MPEG, but in addition, the BSP didn’t actually use anyof the hardware acceleration, instead just used pure Microsoft softwarelibraries, which did the work in the CPU. We were well into the projectby the time this was discovered. This caused a large overrun in thesoftware development timescale.

Should software or hardware drive product development?
Deciding whether the design and development process should be driven by the hardware or software is a critical decision.

When software platform choices are the driver. There are a number of things that can make software (including FPGAcode, if applicable) drive the selection of the hardware, including:

  • Availability of device drivers
  • Ease of application development (think Xbox PC hardware vs the Playstation cell processor)
  • Low unit volumes, meaning development time is the main cost over the product lifetime
  • High complexity of the software vs. the hardware
  • Market product price insensitivity

When hardware choices should drive the process. For hardware some key factors that can put the hardware design in control are:

  • High volume products
  • High market price sensitivity (not necessarily associated with the sales volume)
  • Technical specification issues, e.g. mechanical size, power consumption, or temperature range of components. So if an industrial temperature range is specified it could rule out the most suitable platform from a software development point of view.
  • Component availability is often a sting in the tail when designs are committed to production and components are not available.
  • High compliance costs meaning that rework and retest is unpalatable.

Summary
Makingdecisions on product development can appear to be a circular process asyou narrow in on the best platforms to use. At each stage you can findthat making one decision has adverse effects on another. It is a momentof joy when you make a decision that helps tackle multiple problemssimultaneously.

Dunstan Power is a chartered electronics engineer providing design, production and support in electronics to all of ByteSnap Design 'sclients. Having graduated with a degree in engineering from CambridgeUniversity, Dunstan has been working in the electronics industry since1992 and in 2004 founded Diglis Design Ltd, an electronic designconsultancy, where he developed many successful electronic board andFPGA designs. In 2008, Dunstan teamed up with his former colleagueGraeme Wintle to establish a company that would supply its clients withintegrated software development and embedded design services, andByteSnap Design was born.

Leave a Reply

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