Using software IP: best practices for embedded systems design
When developing embedded software, a key decision that needs to be addressed is "Make or buy?" It is common practice to utilize proven software IP, such as real time operating systems, in modern designs. The scope for licensing software components is expanding as time-to-market pressures make their use more attractive.
The main concern of developers is the usability and quality of such IP. This article looks at the precautions that may be taken, the best practices for selecting IP, the role of standard validation suites, and where open source fits in.
For many engineers, the attraction of programming embedded systems is the opportunity to start from scratch – to write every last byte of software for a device and create something from nothing. I know that this was an incentive for me. However attractive this concept may be to an engineer, it does not really make business sense, partly because this will inevitably result in “reinventing the wheel” – developing something which has already been created – but also because time to market is always limited, so reducing development time is necessarily a priority.
Almost all embedded applications nowadays include some licensed software components. This may be as simple as a runtime library provided with a compiler, but can be as complex as an operating system, including networking stacks, a file system, and user interface. In any case, software intellectual property (IP) needs to be selected with care.
- IP Selection
- The selection process for software IP is subject to a long list of criteria including:
- Commercial factors
Of course, the starting point for selecting some software IP is functionality – does it do the job that is required? Having established that the required capabilities are accommodated, there is the more difficult issue of excess functionality. It is very likely that a commercial IP product will have functionality above and beyond that required for a particular application. This is inevitable, as the vendor will have developed a specification that encompasses the needs of a wide range of potential customers.
The unused functionality can be viewed positively: future product enhancements may be possible without further software purchases. But it may also be viewed in a negative way. You might ask “Why am I paying for functionality that I do not need?” The answer is that you are not, really. To produce a realistically priced product, the vendor needed to include many options. Excess functionality is only a problem if the result is redundant code in an embedded system, as this is a waste of memory. If the IP is suitably configurable or scalable, this is not an issue.
Assessing the quality of IP is challenging, but obviously a necessary part of the selection process. For some products, like a real time operating system (RTOS), the best options are evaluation and looking at the testimonials of existing users. For others, like a USB stack, there are specific testing requirements that permit the vendor to claim compliance with the standard. In other cases, like networking stacks, standard validation suites are available to ensure standards compliance and interoperability with other systems. It is only necessary to enquire about which validation suite has been employed. Simply accepting the data sheet claims in every last detail is often unwise.
Fundamental to any business decision – for that is what licensing software IP is – are financial considerations. A software product will have a cost associated with it. Is that cost reasonable? It is easy to show that the answer is almost always positive. Let’s run the numbers …
Imagine that I order to offer some specific functionality, a piece of software might cost $100K to develop. A software IP vendor might spend 2X or 3X this amount to create a product, when building in flexibility and packaging, etc., are taken into account. Maybe they can find 100 customers for the product, which they sell at $10K a piece. They make a tidy $700K-800K profit and each customer has saved $90K compared with doing the job themselves. This is quite compelling.
This may be a hypothetical scenario which is grossly over-simplified, but it illustrates the principle that well-designed software IP is a win-win for both customer and vendor.
Price, by itself, is not a good primary selection factor when buying any product and certainly not when making a strategic decision like licensing software IP. All other aspects of the transaction need careful scrutiny, particularly the vendors themselves. There are questions to be asked:
- Is the company big enough to provide support and stability over the long term?
- Do they have a good track record and a substantial customer base?
- Are they committed to this technology/market?
All IP is subject to licensing, even if it is open source. The license defines the permitted use of the IP and the manner in which any remuneration is determined. For example, an RTOS may be royalty free, in which case a single up-front payment is all that is expected, or may be royalty bearing, in which case a payment is due for each unit shipped. In this context, the license may be valid for just one model of device and a further license would be required for a new model, or it might extend to any product manufactured by the customer. These details should be considered carefully and taken into account when selecting the IP.
The availability of source code may also be of interest. Although source code is not required to use many software IP products, its availability may give an impression of long term security. Some products include source code at no extra cost; others require a further purchase. In some cases, source code is provided simply to facilitate easy configuration. In this case, it may have been processed so as to be unreadable to the human eye, which renders it less useful.
There is a further argument for deploying IP which goes beyond the logical analyses discussed so far. Successful companies tend to focus on what they are good at and outsource everything else. For example, auto manufacturers do not make paint or windows; they design and assemble cars – that is their core competency. Anyone could write a TCP/IP stack. There are numerous books on the topic, All that is needed are basic programming skills. However, if you want your networking capability to be robust and reliable, and to interoperate with other systems seamlessly, obtaining the stack from a networking specialist would make sense.
Whatever kind of embedded device you are producing, it represents a core competency of your business. For example, if you make medical instruments, you will have a good understanding of the needs of, say, doctors and be well versed in FDA approvals and the like. If you need an RTOS, WiFi, USB, file system, etc., go to a vendor for whom it is a core competency.
As with embedded software development tools, there are open source options for many types of software IP. For the most part, selecting an open source IP product is much the same process as choosing a commercial product. Particular attention should be paid to licensing issues, as constraints on the application of software IP may limit its usefulness.
It is important not to think of open source as meaning “free”. Even though there may be no charge for deploying the IP, the configuration process may be quite complex and time consuming. In most business contexts time is money. Indeed there are a number of vendors who specialize in configuring open source software and offer preconfigured versions and support services.
The case for using software IP – reusing existing software components – is compelling, particularly when more complex applications are being implemented in shorter and shorter timescales. Careful selection of IP products is necessary, paying attention to both technical and commercial criteria.
Colin Walls has over thirty years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, Colin is an embedded software technologist with Mentor Embedded (the Mentor Graphics Embedded Software Divisio), and is based in the UK. His regular blog is located at: http://blogs.mentor.com/colinwalls. He can be reached by email at firstname.lastname@example.org.