Embedded system design with open source software: doing it right - Embedded.com

Embedded system design with open source software: doing it right


Software development is challenging. Embedded software development targeting the newest breed of devices is even more challenging. The additional hurdles faced in this sector of technology are largely down to the rapidly escalating lines of code being deployed inside devices that must deliver a more consist look and feel to conventional PC user interfaces if they are to find commercial success.

The complexity of software systems design within the embedded space can escalate rapidly given the potential breadth of obstacles faced in typical deployment scenarios. Modeling software programming architecture in this sector poses additional challenges to those faced in a traditional PC- or server-based development environment, due to the 'locked in' nature of the software when it is a the post-deployment stage inside of a device.

Before exploring the potential of open source software (OSS) for your embedded device development, you need to ask yourself why you have chosen this route as opposed to any proprietary platform or toolset.

Test for OSS robustness
Have you chosen OSS for embedded to try and save costs – and if so have you accounted for the full costs of provisioning for support and service when this becomes necessary? Is it to work with bleeding edge open source products that might offer the greater power and flexibility you need for a complex embedded deployment? If so, has the code in question been enhanced and evolved enough to offer some reasonable level of robustness?

Proprietary binaries
What you need to remember is that integrating software on hardware is tougher with embedded than it is with desktop systems because there is just so much variety in terms of the hardware itself. What we are talking about here is the provisioning you will need to make for drivers as well as considerations higher up in the software stack.

If you have a collection of binary drivers they may not necessarily work. To fix this, you need the source code for re-fitting the drivers to get them to work on your hardware. Even when you have a working proprietary driver on one hardware configuration, it might not work on a later version. With open source software you have a chance to fix these issues. But with proprietary binaries you need to ask the vendor to fix the issue, which might delay your project considerably. This also goes for the complete software stack, including the UI layer.

What development methodology works best?
Most industry commentators would not propose that an Agile or Extreme programming methodology would work best for the embedded space, as these models typically work more effectively for lighter weight applications. In this space, the use of iterative development models provides an arguably more rapid system build as the project progresses towards the end game, i.e. enabling a shorter time to market.

An embedded GUI is different
An embedded GUI might not look like a desktop application at all. An embedded application is often task-driven with a simplified input mechanism, either via touch screen or a limited keyboard. The screen size is often much smaller than a desktop and you don't get a desktop mouse. This changes the whole user experience, impacting the overall design of your application.

You will most likely run your application development on a PC, emulating the embedded device. If you decide to use an application framework such as Qt, running the application might also work fine on a PC. But you should plan and design the application for the task at hand, making the user experience good for a smaller screen with touch screen or a limited keyboard.

The three pillars of Embedded
If there are three pillars of embedded systems development to recognize and embrace – then it may be the following three tenets: integration, innovation and industrialization. Now these are not rules carved in stone, they are not even de facto standards, they are instead the commonly shared challenges that development in this space comes up against time and time again.

Integration challenges: Coordinating with outside partners and software developers will inevitably be part your total project equation. In this highly “exacting” development environment, to manage this process effectively, a degree of so-called 'strategic business planning' must be present to run in parallel with your own development team's efforts.

Where open source development helps here is that by its very nature an eco-system of developers exists forming the open source community. Sometimes also referred to as 'the contribution model', this socially and technologically integrated set of individuals (and in some cases teams) shares a common philosophy of exchange and interchange. In this environment, integration is naturally more fluid.

If you can only take your project so far and can't find the missing components and code blocks that you need already in existence, the option to “ask” others to help fill in your missing gaps is not uncommon. After all, parts of the open source community will, at any one time, be looking for the next direction to channel their creativity towards.

Innovation challenges: You need a new product. You also need a must-have product that is truly innovative and you need the skills to produce it. A lack of in-house embedded software expertise is one of the most common obstacles facing development shops in this space. How do you get around this?

It is quite apparent how open source development methodology can help here. It should be obvious that by its very nature, the additional scope that an open community engenders allows your project to tap into skill sets held by others and dovetail them into your own project.

Taking the devil's advocate view for a second, a pessimist might argue that this is never ideal as the skills needed will never be in-house and always remain just outside the scope of the individual or company itself that needs them. The reality is that there is little evidence to suggest that this is a real problem. In practice, embedded developers are using open source plug-ins, code samples or more full-blown components to examine and scrutinize every element of external technology that they bring into play. In effect, they learn on the job.

Industrialization challenges: Embedded software, generally speaking, is sold on a large industrialized scale. Building your software to scale to this challenge is not a given thing and introducing interoperability testing MUST be part of this process.

When open source development is executed diligently and industriously with an appropriate level of strategic planning, there is no discernible difference to its scalability compared to that of a large-scale proprietary-based development shop. If anything, interoperability is likely to be less of a challenge compared to the provisioning that will need to be carried out inside a closed proprietary shop. Especially in a large-scale project, no amount of exhaustive testing is too much.

The industrial “drive” for Embedded
SmartPhones are widely argued to have a large part to play in the next stage of embedded development, but phones and PDAs by no means represent the only devices that are driving the demand for embedded software. Consumer electronics and household appliances will also contribute to this groundswell of embedded growth.

While companies like Samsung have built GUIs into refrigerators – a complex undertaking in its own right – this is still essentially a stand-alone device. When SmartPhones or other sophisticated products carrying embedded software start to need networking through the web, through Bluetooth or through some other standard or protocol ” the complexity of the programming challenge ahead increases exponentially. After all, complexity without testing is worthless.

Nokia Qt Framework's work with Samsung has been extensive. In addition to the refrigerator, Qt has also been used to develop the GUI for Samsung's latest Digital Video Recorder for CCTV implementations. As a piece of advanced surveillance equipment, this product also boasts web-based monitoring and search capabilities. Building those kind of functions into an embedded software powered device was unheard of a decade ago, the breadth and reach of open source has helped this evolution take place.

It's not just the consumer-facing end of modern manufacturing to benefit from open source software development at the embedded level; Qt itself has also been used to develop products in the industrial sector too. Siemens has used Qt to develop its SIPLACE large industrial placement machines, the HGZ Coffee Machine features an embedded Linux touch screen which is once again built using Qt.

As well as the Italian company MicroNova whose coffee grinder features a Qt-based touchscreen UI, E.R.S.A and Pixy have developed train driver displays with Qt. Basically, the variety of applications is as limitless as the imagination of the software developers who use today's tools.

But it doesn't stop there. We've already spoken about the increasing complexity of embedded software. If this type of software development with its spiraling intricacies is not matched with a commensurate level of testing, then poor product quality and reliability is likely to develop ” and this is something that customers never want to see.

If you take this issue and combine it with the fact that the power and physical space constraints of devices themselves is not increasing at the same rate, then you can see why a potential brick wall is ahead if software application development best practices are not adhered to. To be honest, even if we do follow best practice, the lines of code are almost certainly increasing at a faster rate than the number of transistors available on the CPU, so there is inevitability about the challenge that lies ahead.

The pros and cons of embedded
When we look at embedded software application development from both a technical and commercial perspective, as product functionality is enhanced and if deployment is clunky or labored, then you may end up with a more costly development cycle and suffer from a slower time to market.

We've talked about development best practices here and the CMMI Level 5 process improvement approach mandates have special relevance. The Capability Maturity Model stipulates that best practices should enable processes facilitating zero-defect software development with an emphasis on the causality of defects instead of their effects.

If we can do this and we can embrace interconnectivity and interoperability at a level that allows us to industrialize our development and use third party technology where necessary, then the future for embedded is bright. Now, all we need is the developer skills to make it happen!

Knut Yrvin is Community Manager for Qt Development Frameworks and Burkhard Stubert is Sales Engineer for Nokia Qt Development Frameworks at Nokia

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.