Android—At Last a ubiquitous Embedded os?

Download 28.26 Kb.

Date	25.06.2017
Size	28.26 Kb.
	#21751

Android—At Last A Ubiquitous Embedded OS?

The Android operating system has established itself in a vast number of mobile devices. Now developers are eyeing expanded application possibilities for this dynamic software. Here is a survey of some of those attractive, but uneven, possibilities.

by Bill Weinberg, Olliance Group (A Black Duck company) and LinuxPundit.comThis article is the third in a series written for RTC discussing the potential and reality for developing and deploying embedded systems using Android. The first, “Android Moves Beyond Mobile” (RTC, September 2009), introduced the then-outlandish idea of using the mobile OS to build intelligent devices beyond its core domain of mobile handsets. The second, “Android—Google’s Mobile Platform and its Capabilities for Embedded” (RTC, July 2011), highlighted the expanding application space for Android but also examined the gaps in its capability set for many types of smart devices. We now continue the discussion, paying specific attention to the progress of the Google mobile OS and to both actual and potential inroads in specific markets and applications. These domains include those listed in Table 1.

Automotive

Automotive systems break down roughly into two broad categories: critical systems control and in-vehicle infotainment (IVI). The first addresses core functions and safety-critical operation in engine/ignition control, anti-lock braking, steering, etc., and is the domain of RTOS-type platforms with small resource footprints. The second, IVI, encompasses smart dashboards, GPS devices and “head units” that integrate these and other functions in a single box. It is these applications that today garner attention in the press and in the boardrooms of automotive OEMs and the Tier I suppliers that serve them, because these IVI systems increasingly define and differentiate the vehicle occupant experience.

A consortium of the leading OEMs and Tier I suppliers, Genivi, was launched in 2009 by BMW, Wind River, Intel, GM, PSA, Delphi, Magneti-Marelli and Visteon, to “foster a vibrant open-source IVI community” by delivering an open-source platform consisting of Linux-based core services, middleware and open application layer interfaces, and by engaging developers to deliver compliant applications. Originally building on MeeGo, Genivi today supplies an open specification with a range of compliant platforms from OSVs and community sources.

To some degree Android is the “competition” for Genivi and also for GM OnStar systems (based on QNX), but to date this is primarily only in aftermarket applications such as GPS devices and media systems like the Clarion Mirage. One exception is the IVI system in Renault Clio and Zoë vehicles.

So why isn’t Android coming to an OEM dashboard anytime soon? Basically, it’s “an impedance mismatch.” For one thing, Android releases come too often for the conservative automotive segment and its 5- to 10-year design cycles. The other issue is that despite efforts from both handset makers (Motorola Cliq/Blur, HTC SenseUI, etc.) and from OSVs with add-on UI products (FST FancyPants and Mentor Graphics Inflexion), automotive OEMs seek a truly differentiated user experience (UX). Therefore they have set their sights “lower” in the stack for a common platform, ensuring that each vendor/vehicle platform will be unique and making cross-brand application interoperability unlikely.

There is, however, another path to market for Android in IVI. OEMs and Tier 1 suppliers are looking at cutting costs through processor consolidation in their head-unit devices, in particular onto ARM and IA silicon. Enabling the integration of IVI, CAN and MOST stacks on a single CPU will likely be done with embedded virtualization technology (from OK Labs, Wind River and others). With Genivi, AUTOSAR and legacy RTOS stacks living in virtual machines (as “guests”) on a single piece of silicon, adding Android to run apps from Android Play becomes a snap.

Consumer Electronics

Consumer electronics manufacturers, primarily in Asia, have embraced Android for next-generation digital TVs, set-top boxes, DVRs, media players and other CE devices. Many of these devices are built on the MIPS architecture, and MIPS Technologies and their partners have invested substantially in optimizing Dalvek to run well on MIPS—a 4 to 5x speed-up, according to MIPS marketing—and in creating reference implementations.

With good support for ARM and MIPS and other relevant hardware, consumer electronics as a segment has enjoyed the most success with Android beyond mobile. A quick glance at the CE retail space reveals announcements of Android-based TVs, IPTV boxes, media players, controllers and other products from LG, Motorola, Philips, Samsung, Sony and Vizio, as well as lesser-known brands.

Enterprise IT and Office Automation

Over the last decade, Linux has won countless designs in both enterprise networking (routers, access points, firewalls, etc.) and in office automation (printers, copies, MFPs). Most of these systems are closed devices—they support field upgrade (reflashing) but not unconstrained download of new applications and functions in the manner of Android-based smartphones and tablets.

Android is finding its way as a general purpose embedded OS into this design domain, primarily by manufacturers wanting to leverage Android’s Java programming model and increasingly familiar GUI. But it is not being done to enable users to download and play Angry Birds (or even more useful apps) on routers and copying machines.

Enterprise IT (EIT) is leveraging Android as a platform for Enterprise Mobility—to deploy internal apps and enhance mobile worker productivity by giving them access to enterprise assets in company data centers and in private and secure public clouds. This BYOD (Bring Your Own Device) paradigm lets EIT staff add software to employee-owned Android devices to enable remote productivity and ensure the security of business-critical data.

Numerous vendors of Mobile Device Management (MDM) and mobile virtualization solutions offer Android-based EIT mobility software, ranging from application-level sandboxes to thin clients to virtual machine platforms to multi-function MDM suites that provision, manage, monitor and even wipe Android-based devices

Defense and Aerospace

In theory, Android and Android-based devices fit the increasing trend for acquisition of COTS solutions by military, government and civilian aerospace contractors and users. In practice, the development and deployment profile of Android in Aerospace and Defense (A&D) has encountered several key limitations important to military and aerospace—security and certifiability.

In terms of security, Android, at least in its mobile incarnation, is notoriously susceptible to exploits of all types: ranging from zero day attacks, process-level denial of service, API and document-based exploits, to malicious apps in standard app stores, especially Google Market and Android Play. Moreover, the Android platform includes native encryption, and while security-minded integrators and OEMs could certainly deploy stronger measures, many apps and much third-party-ware blithely employ native encryption methods like secure sandbox apps.

In addition, Android, starting with the underlying Linux kernel, bionics libraries and going right up through the rich Android m/w framework, is too large, complex and dynamic to pass current certification regimes such as Common Criteria EAL and FIPS 140-2. Such disciplines are optimized for code bases of 10-15K lines of code, although Linux-based systems have undergone EAL4+. However, the total Android stack size numbers are in the tens of millions of lines of C and Java coming to approximately 6 Gbyte of source code in total.

As with EIT, use of Android for enterprise mobility, A&D (and government IT too) is looking to virtualization to facilitate development and deployment of Android devices and applications. Full hypervisors and less feature-rich separation kernels address both the above concerns by presenting a much smaller code base, streamlining certification and offering a diminished “attack surface” to malware as with the NSA’s High Assurance Platform “HAP.”

The use of Android in so-called “superphones,” smart radios and other hardened communications devices, responds to the same requirements as EIT BYOD: let service personnel carry a secure single device with a friendly and familiar user experience for regular communications, and “military grade” security for mission-critical messaging, voice and data transport. This paradigm also serves to cut costs in line with COTS procurement policies. Re-flashing or special ordering COTS Android handsets and tablets with High Assurance firmware and middleware developed by integrators and government contractors is orders of magnitude less expensive than developing, deploying and maintaining traditional equipment.

Industrial Control and Instrumentation

Industrial control and instrumentation systems seem the least likely of candidates to be powered by Android, and yet developers are seriously considering using Google’s mobile OS here as well. For nitty-gritty control applications, they are mostly building native applications and drivers on the Linux kernel that lies underneath Android. The Java execution engine (Dalvik), while boasting excellent performance, is not particularly well suited to latency-sensitive control and sensor applications, although it is more than sufficiently able to communicate with dedicated hardware modules to perform those functions.

Where Android really comes into play is in creating the control panels and operator interfaces to program and run control and instrumentation systems. Developers are drawn to using Android for both communications with dedicated control/instrumentation hardware and with “back office” resources. The attractive and familiar user interface, rich complement of services and middleware, and integrated networking make CTOS Android-based devices and custom interface devices ideal to support both control and instrumentation apps.

Medical

Medical monitoring and treatment devices based on Android face comparable challenges to that of the Google mobile OS in A&D—certifiability and security (privacy). But the attraction of a platform that comes ready-to-use with hundreds of medical apps, touch screen support, networking and other must-have capabilities is overcoming those key limitations. Just as Linux did before it, Android is making its way onto medical systems for diagnosis and monitoring—not life-critical, but those that confer convenience and a friendly user experience to clinicians and patients alike.

Suggested medical device applications for Android include hospital room patient monitors, remote monitors and surgical displays, portable medical records input/display devices, pharmaceutical dispensers and scanners—anything where user interaction is paramount. Another area that has faced certification issues is out-patient monitoring equipment. To some extent, suppliers have side-stepped the issue by creating apps and mobile-phone add-ons for COTS Android phones, letting patients automatically report their vitals and long-term test data over 3G and 4G mobile networks.

In the higher-stakes area of therapeutic and imaging devices, medical OEMs are following the same path as their peers in industrial automation—use Android devices with built-in displays as front-ends to certified proprietary devices requiring certification from the FDA and other regulatory bodies. And in scenarios where even separate displays face certification, OEMs obtain it for a single common design destined for reuse across a range of life-critical systems.

Is Android the Right Choice?

Despite its expansion across the segments described above, Android is still probably not for everyone. Whether Android fits your particular intelligent device application will depend upon the unique combination of considerations endemic to your business and your particular project. See Table 1, which calls out arguments for and against the use of Android with rationale teased from across application segments and the particulars of the platform. Also, see the sidebar titled, “Arguments For and Against Android”.

The sheer number and scope of arguments against using Android beyond mobile might in the future doom the little green robot to dwelling in smartphones and tablets. However, the smaller set of for arguments is quite compelling, and our verdant friend is marching across the field of device applications with no signs of pause or retreat. Like I used to say for embedded Linux, the Google Android OS is finding broad deployment not so much because of its attributes, but in spite of them.

Olliance Group. [www.olliancegroup.com].

Linux Pundit. [www.linuxpundit.com].

[Sidebar]

Arguments For and Against Android

Arguments for Android

Arguments Against Android

Ubiquitous—Android is increasingly ubiquitous, and so is the expertise to develop systems with and apps for it. Furthermore, it leverages an even larger global community of developers already fluent in Java and other programming disciplines.
Open Source—with the release of Android 4.0, the OS is generally considered to be “open source” (again), giving OEMs the ability to customize and enhance for a range of new application domains.
OEM-Friendly Licensing—OEMs have in general made their peace with license compliance when deploying the GPLv2 Linux kernel. Far more forgiving (“liberal”) is the Apache 2.0 license that applies to the majority of Android code, letting OEMs modify and redistribute with minimal disclosure requirements.
Linux—As of Q1/2012, Android no longer forks Linux. Instead, changes unique to Android have been merged into the kernel.org tree under a special architecture branch, assuring that the core of Android will track mainstream Linux evolution.
Paravirtualization—since the underlying Linux kernel and hardware-dependent parts of Android are supplied in source, the platform can be paravirtualized for execution on processors with hardware virtualization support. This capability offers developers and OEMs the option of addressing some Android shortcomings (security, performance) by running the OS as a guest of a hypervisor, alongside more secure and/or higher performance software (including vetted instances of Android itself).

Size—Android is too large in both source and binary forms for many application types. Its massive source base is too large to certify and the derived binaries can outstrip the resources of smaller embedded designs.
Overkill—Android, between the kernel, application framework, and including “hygiene” apps, is far richer than many (most?) intelligent devices need. Strip out the apps and sections of the framework and it’s not “Android” anymore—not all apps will run, etc.
Application Architecture—the Android programming model is optimized for building mobile handsets (i.e., Activities, Services, Broadcast receivers and Content providers). While that model can be stretched and bent to fit other paradigms, Google’s OS is still at heart best suited for smartphones (and maybe for tablets).
Performance—while the Dalvik run-time engine has been optimized for most silicon architectures, Android is still fairly “heavy” and can overwhelm modest processors and lean memory systems, as evidenced by sluggish system response and sub-par application performance on low-end (single core) handsets.
Real-time—Android, like Linux, in its unadulterated form has somewhat limited real-time response capabilities. That being said, most embedded applications don’t really have particularly stringent latency requirements. When they do, there are many means to meet those requirements, including “ugly” shortcuts around standard system mechanisms (true for Android and true for many legacy RTOSs as well). One area of concern for latency-sensitive systems is Android power management, whose aggressive sleep states of course degrade responsiveness. It can be disabled, of course.
Security—Android native security combined with both vulnerable and outright malicious apps presents a grim picture for security conscious developers and deployers in general. However, it is probably no worse (and likely better) than many/most legacy RTOSs and other platforms it replaces. And, Android’s global developer community makes aggressive efforts to patch and update to address known exploits and other threats.
Reliability—Users report that Android phones crash a lot. One study reported that low consumer satisfaction drives Android device return rates as high as 40%. Reliability is paramount to intelligent device design: not all applications are mission-, safety- or life-critical, but even a failed toy or fun gadget can be business-critical to its manufacturer and distributors.
Forking—the flip side of liberal (Apache) licensing is that developers and deployers can customize Android beyond recognition. Forked Android implementations are fine for closed box systems, but a major selection criterion for the OS is its ample and growing portfolio of 400,000+ apps in Google Play (a.k.a. the Android Market). If open devices can’t run a significant number (or they run badly), then the whole ecosystem suffers.

Download 28.26 Kb.

Share with your friends: