原创 Is real-time Android realistic?

For several months I have been discussing with embedded systems engineers about Google's Android and the why's, what's, and how's of using this Linux-based mobile software platform in embedded systems, particularly in applications requiring real-time and deterministic operation. I have been curious to find out: why all the interest in Android?

Part of this interest has to do with the historical relationship of mobile devices—and the Android platform—to embedded and real-time OSes, which strikes me as being analogous to the relationship between trucks and suburban utility vehicles (SUVs).

When SUVs were first conceived, they were designed by truck designers, built by truck workers on truck production lines, and used truck wheels, frames, and components. However, SUVs soon began to diverge, and developed their own unique characteristics. But there was enough shared history and similarity in design that SUVs became a target market for anyone who was in the truck business. Now, in turnabout fashion, truck designers are eyeing some of the SUV enhancements and design approaches and incorporating them back into trucks.

That pattern is mirrored in the recent history of mobile/embedded devices, particularly as it relates to Android smartphones and tablet devices. As distinct a platform as mobile devices have become, their beginnings were in the embedded space. The developers I met with who crowded into the Android classes at the Spring ESC DESIGN West thought they had a lot of embedded design expertise that would be useful in the small footprint, resource constrained mobile device segment as well.

More tantalizing is the reverse possibility—adapting Android for embedded applications. For another analogy it is useful to look back at the evolution of the X86-based PC platform. Before the introduction of the Microsoft OS-based IBM PC and its AT bus architecture, there were dozens of desktop computer vendors using technology derived from the embedded market that had existed for a decade before the PC's introduction. After the standardisation on the AT/Windows platform, dozens of companies and engineers then reversed the flow by developing variations and extensions of the platform for use in embedded applications.

We are at that last stage with Android, with growing interest in creating a variation of that platform supporting real-time deterministic app development. But is this a realistic expectation? And if so, what will it take to get there? Or will it become yet another tantalizing but impossible dream?

The consensus of the developers with whom I've discussed this seems to be that without modification Android would not be a useful vehicle for supporting real-time deterministic embedded apps, no matter how broadly that term is defined. It's not only questionable whether Android can achieve even soft real-time deterministic responses to interrupts, but even if it can, how reliable it will be in doing so, especially when a design is heavily loaded with apps that demand – not merely politely request – access to the underlying hardware/software resources.

The challenges facing Android in embedded apps
The problems with Android seem to fall into two basic categories: the responses of the Linux kernel (Version 2.6) at the core of the platform, and the responses of the Android-optimised Dalvik Java virtual machine. There are also some concerns about the Java code wrapper that surrounds the Linux kernel and is the API through which most development is done.

Engineers I have talked to have assured me that taken individually, each is manageable. But together, they play havoc with the Android platform's ability to achieve the real-time responsiveness and interrupt response times needed for hard-core industrial, automotive, and even some consumer apps.

That has not prevented some of you from trying, despite the fact that any Android application has multiple levels at which interrupt responses can be compromised. First is the latency introduced by the Linux kernel when it handles an interrupt. Then there is the latency added by the Davlik VM, specifically the time interval between when it is received at the kernel event management level and when it is then passed up to the application running on top of the VM. Particularly troubling to developers is the variability in the latency responses. In most cases, the degree of variation goes beyond the upper limit on how much can be tolerated in real-time applications.

The preliminary numbers about Android's real-time performance vary considerably, depending on the source. In general, though, when the application is relatively simple and the system is lightly loaded with no more than 1 to 5 interrupts per second, and the frequency of interrupts is in the 10—30Hz range, the number of deadline misses are troubling, but manageable. But when the system is operating under heavy loads with a dozen or so interrupts per second, and the frequency of interrupts is in the 1 to 5kHz range, the Android OS performance degrades drastically.

Proposed solutions and are they practical?
One option for making Android more real timethat often came up in my conversations is to remove the Linux kernel at Android's heart, along with it's Completely Fair Scheduler (CFS), and replace it with a Real-Time version of Linux. The aim of CFS is to provide a "fair" balance between tasks assigned to a processor and in the adjustments that have to be made when tasks are waiting for an I/O device. This is an OK solution in normal Android human interaction-related tasks. But deadly to determinism, even of the soft real-time variety.

By substituting a Real-Time Linux kernel, the inherent predictability and determinism it brings to Android would allow the use of real-time scheduling classes, do better job of anticipating priority inversion, and allow more carefully crafted strategies for resource management.

An alternative would be to substitute a real-time Java Virtual Machine for the existing Davik Virtual Machine, which would allow incorporation of bounded memory management and real-time scheduling, better synchronisation, and avoidance of priority inversion conditions. But these advantages would be limited to the VM. It would have no impact on the way the Linux OS performs. Full advantage of this option is obtained only when it is used in combination with a real-time Linux kernel.

Some developers think it would be a better idea to extend the real-time capabilities of the Davik Virtual Machine through the use of the Real Time Specification for Java (RTSJ) rather than the standard Java dialect, which would make it possible to introduce more deterministic operations into the VM layer without replacing Davik.

Another possibility would be to use a real-time hypervisor virtual machine monitor and allow Android to run in one of the partitions as a guest OS and real-time applications to run in the other. The advantage of this approach is that it virtually guarantees that any and all real-time tasks have priority over Linux kernel tasks, which means that it can be used for hard real-time deterministic operations. Unfortunately, this approach has two gotchas. First, real-time applications are limited to what is provided by the real-time hypervisor. Second, if a real-time application in the real-time hypervisor hangs up, the whole system is brought to a standstill.

An alternative that intrigues me is the use of a rate monotonic scheduling algorithm (RMA). The idea is to keep the standard Linux distribution but replace CFS with a real-time scheduler, ideally one using a rate monotonic algorithm. (The use of RMAs in embedded design has been written about by Embedded.com columnist Michael Barr.) It is also used in a number of RTOSes, including the open source RTEMS and Deos from DDC-I.

Invitation to the dialogue
Looked at from the mile-high technical journalist's perspective, all the alternatives seem to me to be doable technically, albeit with their own degrees of difficulty. No doubt when viewed close up and personal, numerous problems are more readily apparent. For that on-the-ground perspective I would like to hear from those of you staring the problems in the face.

Unfortunately, no matter what the perspective, one stumbling block to any of these alternatives is that they would undercut the universality and cross-platform usability of applications written for use on Android.

To complicate matters, after a two year ban during which Android developers were not permitted to contribute code to the open source Linux project, they have now been added back into Version 3.3's staging area by project founder Linus Torvald. In the past, this is usually the final step before contributed code is merged into the main Linux tree. Whether this will mean that Linux—and thus Android—will be more amenable to real-time modifications, or less, is hard to say. But it is a complicating wrinkle.

As Yogi Berra has said: it is déjà vu all over again, a replay of what happened after embedded developers started taking the PC/MS Windows platform and adapting it to their needs. The more deterministic and real-time they made their PC/MS designs, the less compatibility they had with unmodified versions of the platform. All developers then had was the comfort of a familiar hardware and software environment within which to do development. But there was little cross-platform compatibility. You could not take an app that ran on a standard platform and be assured it would run on the modified one, and vice versa.

But in terms of a real-time implementation of Android, maybe the availability of the easy to use, easy to program platform is enough. Cross platform compatibility for apps from either implementation – standard or real time—would be nice of course, but is it necessary? What do you think?