05 Nov 2014
Design trade-offs for electronics product development
Dunstan Power, Director of Embedded Electronics Design Consultancy at ByteSnap Design describes why design trade-offs are needed during electronics design and how to make them
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 on development cost.
Here we explore some of the key trade-offs made during product design. With reference to both software and electronic design aspects, we focus primarily on the commercial and time implications of these decisions.
A fine balancing act - time, specification and unit price
When deciding on trade-offs, the first priority is to identify what is being traded (Figure 1).
Figure 1. The starting point when considering design trade-off factors.
A design engineer needs to balance the three factors of technical specification, development cost and unit price. To understand where the bias should be, the following 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.
Many factors can skew decisions, such as high annual volume, shown in Figure 2…
Figure 2. Initial planning for a product where units will be built in large numbers shows that the unit price is the overriding design consideration.
The focus here is on unit cost. But 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 this in Figure 4: something that is over-engineered and expensive but will still be around and working long into the next century.
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 centre of the technical decisions are the trade-offs between 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) represents approximately two thirds of the overall development cost.
Choice of components can have a fundamental impact on software development time. As a result there is often a straight fight 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).
In practice - simplifying a motorcycle head-up display design
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?
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.
Whilst for production, it would be represented like this in Figure 8:
Figure 8. For the production of BIKEHUD, unit price was important. We focused on features and unit cost, so consequently development time and cost rose.
We selected 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.
Understanding project risk
As shown in Table 1, we can divide project risk into three areas corresponding to the trade-offs discussed earlier:
|Major Project Risk Areas|
|Technical specification||Specification cannot be met, product recalls etc|
|Unit price||Unit price target cannot be achieved|
|Development cost/time||Development cost/time will balloon|
Each of these factors has implications on product design.
1. Development time vs development cost
Whether you have your own development team, or outsource the work, in general the development cost of a product is proportional to the time it takes. So you are getting hit twice when overruns occur, once with cost and again with time to market.
One solution is to assign development to a team on a fixed price basis, so passing the timescale risk on – they foot the bills for overruns that you are not responsible for.
Third party software libraries can reduce software development time but increase the cost. Further licensing costs will also impact the unit cost.
2. Bill of materials (BOM) cost vs risk
Generally, the level of risk translates to the difference between an accurate and inaccurate time and cost estimate. Zero risk projects complete inside time and cost projections, while high risk projects wildly deviate from these estimates. System planners generally aim to eliminate as much risk as possible to allow for the most accurate budgeting. Engineers can and do mitigate risk by “playing it safe” when choosing components, for instance using older, tried and tested technologies, rather than a newer, lower cost devices. Shorter development cycles therefore often result directly in a higher BOM cost.
To minimise BOM cost, often some level of experimentation is required of uncertain time duration. The risk here is to timescales for the customer and to costs for a contractor who has quoted a fixed price, or internal costs for an engineering team. So BOM cost optimisation is often best done once after the technical design goals have been met, so that time to market impact is minimised.
3. Software vs hardware integration
Carrying out software design in isolation from the hardware design is highly inefficient. A project that is purely software driven may result in an expensive hardware platform to support it, rather like the ‘bloatware’ that is often complained about in desktop computers. In this scenario, ever more powerful hardware features are introduced, and yet all too frequently the software support is not added to use them, software ‘grunt’ being used instead because it is easier to implement.
Conversely, hardware design without reference to software can lead to different problems. For instance, a microprocessor module may have its operating system shipped as a binary board support package (BSP), rather than as source code, with limits on which I/O pins can actually be used, and how peripherals are mapped to the I/O. Just looking at the data sheet for the module can lead to a false sense of security during the design.
Similarly, choice of peripherals modules, such as Wi-Fi, is driven more by availability of software drivers for the target operating system than by the cost, size etc. No matter how strong the hardware’s feature set, if the software isn’t compatible, it’s probably an unsuitable solution. A critical success factor is deciding whether the design and development process should be hardware or software driven.
4. Reference vs production-ready software
The difference between a reference software package (e.g. a BSP) and ‘production-ready’ code is important as the resulting software development timescales can differ greatly.
As system-on-chips (SoC) have become more complex, some suppliers can only remain competitive by selling large amounts of source code to support their devices. However, a reference BSP is unlikely to be optimised, will probably be buggy and won’t in all likelihood support all the features. A production-ready BSP should have a clearly defined bug free feature set, and importantly, if bugs are found, the vendor should take responsibility to fix them or change the specification.
Production-ready code is more valuable but comes at a price – either being locked to a hardware platform typically (e.g. CPU module), or being sold with a licence fee. While a reference software package is often free.
Making decisions on product development can appear to be a circular process as you narrow in on the best platforms to use. At each stage you can find that making one decision has adverse effects on another. It is a moment of joy when you make a decision that helps tackle multiple problems simultaneously.
Page 1 of 1
About the author
Dunstan Power is Director at ByteSnap Design. he is a chartered electronics engineer providing design, production and support in electronics to all of ByteSnap Design's clients. Having graduated with a degree in engineering from Cambridge University, Dunstan has been working in the electronics industry since 1992 and in 2004 founded Diglis Design Ltd, an electronic design consultancy, where he developed many successful electronic board and FPGA designs. In 2008, Dunstan teamed up with his former colleague Graeme Wintle to establish a company that would supply its clients with integrated software development and embedded design services, and ByteSnap Design was born.
ByteSnap Design is a specialist in innovative embedded systems development encompassing hardware and software design with an international client list. The company is a Zigbee Alliance member and Windows Embedded Silver Partner. The team’s experience ranges from electronic design to iOS, Android and Windows mobile app development. ByteSnap Design won Design Team of the Year in 2013 at the British Engineering Excellence Awards (BEEA) and was a finalist for Consultancy of the Year 2011 for its design work on electric vehicle charging posts for the London 2012 Olympic Games, and was highly commended the following year, at BEEA 2012. The company also won European Design Team of the Year 2011 in the Elektra awards. The consultancy also has experience in electronic circuit and microcontroller design, Linux and embedded software development, designing hardware products such as PDAs and smart meters, and software projects such as developing Windows CE board support packages (BSPs) and signal processing applications.
Most popular articles in Circuit Design
Share this page
Want more like this? Register for our newsletter