Military Embedded Systems

Linux in the military to achieve double-digit growth, but performance is still key

Story

April 02, 2008

Chris A. Cuifo

Editorial Director

Military Embedded Systems

MontaVista Software invented the category of embedded Linux commercialization back in 1999, and has remained the leader since then. Increasingly, MontaVista is being considered for defense applications - sometimes pushing aside the better-known Linux-for-defense suppliers such as Wind River or LynuxWorks. I had a chance to conduct an email interview with Jim Ready, MontaVista?s founder and pioneer of the RTOS VRTX. Edited excerpts follow.

Figure 1: Jim Ready, MontaVista

(Click graphic to zoom)


21

 

MIL EMBEDDED: Tell us about Linuxís adoption in the
general embedded market and specifically about Linux in the military.

READY: According to
the September 2007 report "Linux in the Embedded Systems Market" by analyst
firm VDC, Linux is growing rapidly in the embedded market. They project a
Compound Annual Growth Rate (CAGR) of 11.7 percent from 2006 to 2009 for sales
of Linux-related embedded software and services.

The area of fastest growth according to VDC will be embedded
Linux in mobile phones, at 16.9 percent CAGR from 2006 to 2009. Due to embedded
Linuxís "networking and communication strengths," there is a predicted
military/aerospace CAGR of 13.3 percent. This makes military/aerospace the
second-fastest growing market for embedded Linux.

As contributing factors causing the growth of Linux in the
embedded systems industry, VDC cites: the use of Linux in real-time,
safety-/mission-critical, and secure applications; a growing understanding of
the intellectual property issues of the GPL license used for Linux; and
industry forces driving greater standardization.

MIL EMBEDDED: If a programmer codes in and deploys a
certain Linux distribution, how much do they really control their own destiny?
Specifically, how portable is their code if they want to remain
vendor-agnostic?

READY: For all
versions of Linux, the developer has access to source code, so if the developer
wants to customize the kernel, change userland, or modify the UI, the developer
has the visibility into the code to allow those changes to be made. This
increases control. A developer working with proprietary software has no
visibility into its code, so his hands are tied.

The additional control given by the specific version of Linux
depends on the presence or absence of four ingredients in that Linux version.

First, if the developer is building a commercial product,
they need a Linux with a commercial quality. This will not be provided by
source code downloaded from Linux.org.

Andrew Morton is the lead maintainer of the Linux kernel, and
the person most responsible for Linux after its creator Linus Torvalds. At the
Linux Foundation Summit last year, Morton said as much: "The kernel.org
community is no longer delivering a quality commercial product. It delivers
cutting-edge technology and depends on commercial distributions to clean it up
and make it into a commercial product."

The full Linux operating system can include 40 million lines
of code. Would you want your product to include even 1 million lines of
untested code? Of course not. But in the open source community, nobody is
responsible for testing every line of code. Nobody is responsible for making
open source code commercial quality. For an embedded developer to have the
control required to produce a commercial-quality device, the developer must
begin with commercial-quality software.

The second ingredient is integration. The Linux OS in an
embedded device can include the kernel, GNU toolchains, drivers, tools, and
applications. It is not unusual to combine software from more than 100
different open source products within the software for a single device. It is
one thing to put such variegated software together; it is another matter
entirely to get all the pieces working with each other, and to make sure that
bug fixes and enhancements to one piece of software donít break the other
pieces.

The third ingredient is technical support. Support
requirements for embedded Linux are different from those for desktop Linux or
server Linux. For one example, desktop and server users expect to migrate to
newer versions of the kernel as they are released. Embedded developers usually
select one version of the kernel and keep it for the life of their device. So
when a newer kernel comes out with new bug fixes, someone will have to backport
those fixes to the older kernel that the device uses. Having that sort of
detail-oriented, focused support – as well as answering software and
hardware questions –contributes greatly to giving developers control over
their project.

Lastly, hardware enablement gives control. A developerís
project will be much more difficult if a commercial-quality embedded Linux is
not available for the hardware he needs. Thorough hardware enablement answers
two questions: First, will this Linux run on my board? Second, if it runs on my
board, how deeply is it enabled? In other words, will it support all the I/Os I
need on my reference board, and all the processor-specific features I need?

You ask, "How portable is the code"? If one distribution supports
the boards you need, it is much more portable across different hardware types.
If not, it wonít be.

MIL EMBEDDED: What
are the key questions one must ask (and answer) when considering Linux for a)
real-time embedded and for b) mission-critical applications?

READY: In surveys,
embedded developers list real-time performance among the top three concerns
about adopting Linux.

To be an effective real-time platform, native real-time Linux
must:

  • Offer response latencies on a par with legacy systems and meet emerging
    requirements.
  • Use existing native Linux/POSIX APIs, IPCs, and other constructs,
    not inject new ones.
  • Enable real-time programming in both user program and Linux
    kernel contexts.
  • Not break existing non real-time behaviors or semantics.
  • Allow reuse of existing board support and device drivers.
  • Offer sufficiently compelling performance improvements to gain
    acceptance by the larger Linux kernel development community.

When MontaVista and others began investing to make Linux more
real-time at the start of this decade, those requirements presented a high
barrier. Through perseverance and incremental, community-based, open source
research, prototyping, and contributions, native Linux now meets all those
requirements.

Mission-critical embedded applications may or may not require
real-time performance, but they do require high availability. Some vendors have
added high availability features to Linux that have achieved availability of
greater than 99.9999 percent for applications with high-volume system loads.
The key questions to ask would be whether high-availability features are
available, and what results actual commercial products in the field have
delivered using those features.

Jim Ready
is a recognized authority in the embedded systems and real-time software
industry. He founded MontaVista in 1999 to provide the Linux operating system
to the embedded systems market and to offer embedded-systems expertise to the open source Linux community. He received
his BA in Physiological Psychology from the University of Illinois at
Urbana-Champaign and his MA in Physiological Psychology from the University of
California, Berkeley. For more information, email [email protected].

MontaVista Software
408-572-8000
www.mvista.com

Featured Companies

Montavista Software

5201 Great America Pkwy, Suite 432
Santa Clara, CA 95054