Where is the cost in an embedded Linux system?

With the ever increasing complexity of embedded systems, the availability of skilled engineers, better development tools and the evolving connected device world, Linux is today recognised as a serious player in the embedded system space and a viable alternative to traditional commercial real-time operating systems (RTOS).

The adoption of a “free” operating system has radically changed the cost model for embedded systems, but not necessarily the bottom line.

A defining moment in this transition has to be Andrew Tanenbaum’s seminal work Operating Systems Design and Implementation, which placed the entire source code to the Minix operating system in the hands of a plethora of software engineers, feeding into the GNU Linux we know today.

Engineers like to play, and Linux has been ported to many systems simply for the challenge. At the same time, embedded systems have become far more complex, often functionally equivalent to desktop PCs.

The initial attractions of Linux are clear. You can download a large body of code and start development of your system in a few hours, side-stepping the traditional up-front, per-developer seat costs and safe in the knowledge there will be no runtime royalties to pay on deployment. You get thousands of lines of code which do most of what you want.

For connected devices, TCP/IP and USB stacks are bundled in. Best of all, your engineers will tell you, it’s all free. So why are project managers sometimes struggling to see significant cost savings on the bottom line?

See also: The Electronics Weekly Open Source Engineering blog

Where is the cost in an embedded Linux system?

Any project manager will tell you that the major cost of projects is development effort.

Starting out on Linux is often a top-down approach. A large body of code and functionality is adopted, but ask yourself how much of it will actually be used?

Debugging and development effort is a function of the number of lines of code to work through, and there is usually little or no support to help you – it is available, but you only get what you pay for. When compared to a bottom-up approach, starting with a conventional real-time operating system and building upwards, Linux-based projects typically have a larger total line of code count, more code is written, and development teams are consequently larger in size.

For many applications there will already be something written which does 80% of what you want, but remember Pareto – this is probably the easy part and the final 20% can prove challenging.

Next on the list is time to market. Missing your product introduction window is doubly costly. Not only is revenue lost as sales are not generated, but development is likely to be ongoing. The euphoria of a near complete demo near the start of the project will be long forgotten if debugging and completing that tricky last mile drags ever onwards.

Time to market is particularly acute in the consumer retail space when the target window is linked to an unmovable event such as the World Cup or Christmas, and missing the window means not just reduced revenue, but no revenue.

See: Mobile Linux boosted by second Vodafone 360 handset

Bill of materials

The bill of materials (BOM) cost of your end product is also likely to be higher, with a requirement for more RAM and flash memory. All those inherited lines of code in your project will be executed too, consuming CPU horsepower, and you may need a higher-specification processor than first anticipated, a secondary effect of which is often greater power consumption. Customer demand and increasing legislation is bringing power to the forefront of design consideration, so ignore it at your peril.

For larger organisations there may also be a significant, but often overlooked, cost in IT infrastructure. There is a security risk posed by embedded Linux development platforms appearing on a corporate network. From an IT perspective, these are uncontrolled machines with root privileges capable of providing all of the network connectivity and services of a server machine. It may be ­necessary to install and maintain a private network to separate this uncontrolled development environment from the main corporate infrastructure.

Malicious intents aside, the network disruption caused by an accidental address conflict can be considerable.

Finally, no discussion of Linux would be complete without covering open source licensing. There are implications here for embedded devices which include custom propriety hardware IP, because device drivers accessing the hardware typically need to execute in kernel space, and this means the source code will be subject to the General Public Licence (GPL). You will have to publish it, and this may give your competitors knowledge of your design.

In the case of secure systems which include IP to protect data or implement digital rights management, information which may aid hackers could be placed in the public domain; poorly designed systems that rely on obfuscation are particularly at risk.

Also, you need to be sure of your legal position before a commercial product launch, which may entail consultancy fees. If you want to take advantage of Linux then you must also play by the rules and be aware that all rights may be affected if a breach is made, so all of your products could be on hold because of one infringement.

It has been a rocky ride, but Linux as an embedded operating system is now firmly established and has gained significant market share against the commercial RTOS.
Linux projects tend to spread costs more evenly over the project duration, avoiding large capital up-front costs, but beware the mantra of a free operating system – commercially it isn’t but you are very welcome to use it.

Author is Andy Lunness, programme manager at STMicroelectronics

See also: The blog Open Source Engineering with Linux & GNU Observations from the coal face of Open Source Engineering, bringing Linux and GNU software to embedded environments, whether for industrial, automotive or mobile applications.