A common discussion point with many of our clients, particularly the smaller ones, is whether they should try to buy an “off-the-shelf” hardware platform, or design a bespoke system from scratch.
The usual answer is “it depends” and while I’m not claiming that we have the definitive design solution I’d like to share some of the lessons that we have learned over the last decade regarding the most cost effective way to develop products for our customers.
Firstly let’s just look quickly at the reasons as to why you would want to buy off-the-shelf electronics modules or sub-systems instead of just designing it all yourself. The main reasons are usaully :
- Cost – if you don’t have a large design team and a significant design budget, then you need an alternative approach to designing everything from scratch.
- Time – a complex PCB may take many months to design and verify
- Quality – a complicated board will take a lot of testing to prove both its functionality and reliability
A lot of what I’m going to discuss is not particularly relevant to multinational product companies with large design teams and equally large design budgets, but many of our customers don’t have that level of engineering available to them. Alternatively it may be as simple as they want to build a prototype system to prove a design or a concept before developing it further.
Methodology
We usually take a modular approach to both hardware and firmware development and while this article is not going to focus on the latter, much of the reasoning applies equally to firmware development.
My view is that there is a need to be pragmatic here – design trade-offs may mean that certain components need to be on the same board particularly when it comes to high speed digital systems, or complex analogue or RF designs.
The hardware architecture design will normally identify logical connection points between modules and sub-systems (these are frequently interface bus based) and these can then be considered for build versus buy decisions.
Of course the choice between build or buy may not be that clear cut, and it may well be possible that a combination of the two is in fact the best solution.
Off-the-shelf Processor Boards
There is an incredible range of off-the-shelf CPU modules and boards available today at comparatively low cost. In low quantities these are much cheaper than we could design or have manufactured ourselves, unless of course we were going to be shipping tens of thousands.
We find there are often trade-offs regarding where boards are sourced. CPU boards from the Far East may be cheaper but in our experience there is better quality and often better technical support available from board manufacturers based closer to home. In particular we have had excellent experiences with Blue Chip Technology in the UK, and Toradex in Europe.
If all you need is a basic processing node, with standard peripherals e.g. Ethernet, USB, flash card support, then an off-the-shelf board may be all you need to provide a high quality solution at a reasonable cost in low volumes.
Bespoke Design Processor Boards
At the other end of the scale are complete bespoke processor board designs. These may have a custom form factor or perhaps custom peripherals e.g. high speed ADCs and DACs, or FPGAs, and may also be used to combine carrier card and CPU functionality on a single board e.g. for reliability.
This results in higher development costs and probably higher manufacturing costs as well (in low volumes), but you get exactly what you want. This may be a particular form factor to fit in an enclosure, or an unusual combination of peripheral devices which are not available in a standard off-the-shelf design.
When developing your own bespoke design it is important to have an experienced PCB layout designer because while you can often get a great deal of what you need from reference designs supplied by silicon vendors, high speed digital lines or RF sub-systems (or even the increasingly common Gigabit Ethernet) require careful layout and close observance of PCB design rules.
A Third Way…
There is a third option which is a half-way house combining off-the-shelf CPU boards with custom interface boards. This sits between the two previous examples, and can be a very cost effective way of providing low speed custom peripherals based around a standard CPU board.
As long as the COTS board has standard interface buses such as SPI or I2C then it can be fairly straightforward to design a simple interface board with extra peripherals and this is an approach we have taken for a number of customer projects with successful results.
However if peripherals have to be memory mapped e.g. some DACs or ADCs for streaming high speed data, or FPGAs then a custom processor board as discussed earlier may be a better choice.
Note that there are other design considerations and you may have to take various other factors into account e.g. it is not practical to put a CPU on one board and high speed memory on another without careful consideration of design rules such as track lengths or connector types. Reliability may also be a factor here so (as always) the design should be carefully thought through.
Communications modules
Communications modules for common standards such as Wi-Fi, GSM or ZigBee are usually good candidates for buying off-the-shelf.
Many wireless standards require certification of both the hardware and software which can be expensive and time consuming but buying pre-certified modules avoids this while “guaranteeing” compatibility and interoperability.
That said, there are different levels of module. You can get surface mount versions that solder directly onto your board, modules with connectors to plug onto boards, or complete modules that just need power and a serial connection.
The points to consider are the same as before – how much time do you want to spend laying down a board, how much space is available in your product, what is your budget, etc.
One thing to watch for here is the maturity of the design – some vendors may have relatively mature designs and long release cycles with products which will probably work very well in areas related to the standard. However if you have a problem with some proprietary aspect that the vendor has designed, or a missing feature, it may take a long time for that feature to appear in a release.
Ironically you may actually get a better response from a company with a less mature product, particularly if they are trying to break into a particular market.
Standards such as ZigBee may require certification if you want to advertise as ZigBee compatible, and if so then you probably want to at least use a reference design and pre-certified firmware.
However ZigBee is a protocol based on the IEEE 802.15.4 standard which defines the PHY and MAC layers, but there is nothing to stop you implementing a proprietary protocol on top of this standard such that you can use standard hardware to implement a proprietary solution. Obviously this would still have all the well-known draw backs of ZigBee but that’s a subject for a whole different discussion…
For less common or proprietary methods the decision is more complicated. Off-the-shelf modules may be more expensive or even non-existent, and there may be no requirement for certification e.g. in low power radio communications in the unlicensed ISM bands such as 433MHz or 868MHz. In this situation a proprietary solution may be the best (or indeed only) choice.
There are many trade-offs to be made here and no right or wrong answers. This is a very wide ranging topic with many different aspects so please get in touch if this is something you might be interested in.
Conclusions
As I said at the outset, there are no sure-fire solutions or guaranteed successful design philosophies, and every time you think you’ve seen everything, along comes another customer with their own special requirements which mean you have to go back to the drawing board, sometimes literally!
Cost, time and quality are the most common trade-offs to be made, and of the three I would suggest you compromise least on quality as it is almost always the one that will come back to bite you.
You have to take each case on its merits, and try to make informed design choices based on all the various factors I’ve talked about. What’s right for one project may be wrong for another, and only rarely are there “cookie cutter” solutions where you take exactly the same approach for two different projects.
