Why Android Deserves a Look in Embedded Wireless Systems

It’s clear that you should at least consider Google Android as an operating system if you were designing a smartphone or tablet, given the growing popularity of the platform. But will Android ever fit into wireless-enabled embedded systems designed for specialized applications? Until recently, I would have said no. But I’ve come to believe that embedded design teams should at least consider Android in many applications even if the Linux-based operating system is combined with a more traditional embedded software platform.

Why Android? I’ll discuss some potential advantages for the design team in a moment, but let’s start with the end user or the operator of the embedded product. You can go a long way toward satisfying the customer, or the customer’s customer, by providing a known user interface. You can even provide the same experience that an operator is familiar with in terms of an application.

Let’s consider an example. Say you are building a wireless-enabled embedded system that includes a GPS. A simple example might be the tablet that couriers use as they deliver packages. A more complex example might be a system deployed in some type of transportation application -- perhaps a vision-oriented highway safety system that classifies traffic.

A GPS function in such applications would serve to automatically track data relative to location. But the operator might also require or benefit from access to the GPS function. Why not provide that operator with the same Android-based GPS application that the person uses on their personal smartphone? Now let’s turn back to the design team. The trend is to try and not reinvent functionality in system design today. Time to market matters. A platform such as Android might speed time to market via inherent support for GPS or other functions while providing a known user interface to the operator.

You can extend the concept quite easily. Perhaps your embedded application could take advantage of text messaging. There are an amazing number of other embedded apps coming to the Android platform. Many or most will never have a place in a serious embedded system design, but some might fit surprisingly well.

The fact is that we’ve seen a similar scenario play out before. Consider how many embedded products use some form of Windows or Linux today. In some cases the general-purpose operating system can host the entire embedded application. In other cases it may just host the user interface serving to put a familiar display in front of the operator.

Embedded teams have a lot of similar flexibility as to how they might utilize Android. Going forward, many potential users of an embedded system will have familiarity with the Android user interface. Operators will already understand how to use gestures and swipes. And design teams wouldn’t have to implement such capability from the ground up.

Fortunately, Moore’s Law means that many applications can afford the processing power required to run Android even if the platform serves no function other than the user interface. Many embedded applications that don’t have hard real-time requirements could also be executed on the platform.

There are many reasons your application might require a different operating system. You might have security issues that require a specialized operating system. The previously-mentioned real-time aspects might also prompt a different choice. That doesn’t mean you shouldn’t still use Android in the system. Indeed many embedded systems combine Windows or Linux with a real-time operating system.

Embedded teams can pursue two paths in combining Android with another operating system. With the falling price of processors, you might just use two. Many mobile phones integrate multiple processors. But you can also utilize virtualization technology to simultaneously host multiple operating systems on one processor. Most of the real-time-operating-system vendors support virtualization and allow you to separate mission-critical tasks on one operating system while hosting a user interface or other application on a platform such as Android.

Again you may ask why Android? It’s a fair question why you should choose Android compared to another mobile operating system with inherent wireless support. But you don’t have many choices. Windows mobile is one but it has lost traction in the mobile space. We don’t yet know if Microsoft’s new partner Nokia might revive the Windows Mobile platform.

The Apple iPad platform would be the obvious choice given its broad use and robust feature set. But Apple won’t be licensing its platform. Symbian is not a legitimate choice considering that even Nokia is moving away from that in-house platform. Intel continues to pursue MeeGo. But it appears Intel has lost Nokia as a partner.

Whether you believe in Google as a technology purveyor to the embedded market or not, Android is the lone platform that promises broad deployment and longevity. As an embedded designer, you can’t expect a lot of help from Google. But fortunately the embedded operating system community appears poised to support Android.

Android won’t be right from all systems. Some applications won’t be able to afford – from a cost or power perspective -- an Android-capable processor and memory. But don’t dismiss the concept until you consider what it might simplify in your system design and what benefits it might bring to your customer and their customers.