Four trade-offs electronics design teams should consider
15 October 2014
Fast time-to-market, low product cost and high-quality technical specification - these are key factors when launching new products. However, many stakeholders are unaware of the trade-off decisions that designers face during new product development.
Electronics design consultancy ByteSnap Design, exhibiting at this year’s Electronics Design Show (Coventry, October 22-23), will be sharing its expertise on the challenges of embedded product development, drawing on real world examples to demonstrate how companies can make better decisions about:
- Time to market
- Development budget
- Target market sale price
- Anticipated annual sales volumes
- Value in exceeding or modifying the specification
To improve the product development process, ByteSnap Design has developed guidance for the more common design decision points and trade-offs:
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.
One answer is to assign development to a team on a fixed price basis, so passing the timescale risk to them – they foot the bills for overruns that are not your fault.
Buying third party software libraries can reduce software development time but increase the cost. Further licensing costs will also impact the unit cost.
Bill of materials (BOM) cost vs risk
Generally, the level of risk translates to the difference between an accurate time and cost estimate, and an inaccurate one. So zero risk means that the project will complete inside time and cost projections.
High risk means that it may 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.
This means that the shorter development cycle often results 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 fixed price for the work, or internal costs for an engineering team.
So BOM cost optimisation is often best done once the technical design goals have been met, so that time to market impact is minimised.
Software vs hardware integration
Carrying out software design in isolation from the underlying hardware design is highly inefficient – there is a trade-off between what the software and hardware does.
A project that is purely software driven may result in an expensive hardware platform to support it. This is 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 good the hardware is, if the software isn’t available to use it, it’s probably an unsuitable solution. Deciding whether the design and development process should be driven by hardware or software is a critical decision.
Reference vs production-ready software
What is the difference between a reference software package (e.g. a BSP) and ‘production-ready’ code? This matters 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, this is not to say there is no software work to do.
A production-ready BSP should have a clearly defined set of features that is bug free, and importantly, if bugs are found, the vendor will take responsibility to fix them or change the specification.
So production-ready code is more valuable but comes at a price – either being locked to a hardware platform typically (CPU module, for example), or being sold with a licence fee. The reference software package is usually free.
How this can affect a project is illustrated by a project where we used a manufacturer’s ARM based SoC which had integrated hardware MPEG decode and encode. We used this CPU primarily for this function and the BSP appeared to support it. But the performance was poor and it soon transpired that not only was the decode very limited in the exact flavour of MPEG but, in addition, the BSP didn’t actually use the hardware acceleration, instead just using pure Microsoft software libraries, which did the work in the CPU. We were well into the project by the time this was discovered. This caused a large overrun in the software development timescale.
Dunstan Power, Director of ByteSnap Design concludes: “Making decisions on product development can appear to be a circular process as you home 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.”
Contact Details and Archive...