Java embeds itself in the control market

Although most of the focus on Java to date relates to the Web and the desktop, Java is attracting a lot of attention in the embedded systems market as well.

As in other markets, Java is still being hurt by its lack of maturity and well-developed software tools. Still, Java is being deployed, developed, or seriously considered in applications as diverse as cellular telephones, factory control systems, and the Hubble Space Telescope.

“Trends indicate Java will become big in the embedded market,” says Carol Feigenbaum, director of product marketing at Microtec Inc., a division of Mentor Graphics based in San Jose, CA, that makes a real-time operating system and tools for embedded systems. “How Java is applied to embedded applications is another matter. There’s a lot of debate and some confusion on that.”

Part of the problem for Java in embedded systems is simply Java’s immaturity. It takes time for a product like Java to grow from a specification to a full set of software development tools and into deployed applications. Part of the problem is the confusion engendered by the Java Wars between Sun and Microsoft. And part of it is a series of concerns that are particular to the embedded systems market, notably determinacy and size. In spite of it all, Java is attracting a lot of adherents in embedded systems, and there seems to be little doubt that Java will become a central part of the embedded market.

The nature of the embedded systems market

Embedded systems provide much of the intelligence in today’s “smart” devices. Microwave ovens use them, telephones use them, even toaster ovens (increasingly) use them. And factories, transportation systems, and most of the rest of the infrastructure of modern life use them in massive numbers.

Embedded systems rely on microprocessors and microcontrollers — a computer on a chip that combines a microprocessor with some ROM, RAM, I/O channels, and perhaps some other specialized devices. Although there still is a significant market for 4-bit microcontrollers, increasingly the business is moving to 8-, 16-, and 32-bit controllers. In higher-end jobs, such as controlling a laser printer or running the sensors and controllers on a machine tool, embedded systems often rely on full-blown RISC processors. Intel’s i960 series has been a big hit in the embedded systems market, and Sun has versions of its SPARC processors that are widely used as well.

Estimating the size of the market for Java tools is difficult. While nearly everyone agrees that Java is growing explosively in the embedded systems market, numbers are hard to come by. That’s not surprising, considering that estimates of the entire embedded software tools market vary enormously. International Data Corp. (IDC), a research firm based in Framingham, MA, estimates the tool market at just under 00 million in 1995 and expects it to grow to .6 billion by 2000. Wessels, Arnold & Henderson, a research company in Minneapolis, says the market was .5 billion in 1996 and will grow to .2 billion by 2001. Part of the difference in the estimates is in what the different analysts are counting as embedded systems software. Even more comes from uncertainty about a market that is fragmented and often hard to define. There is, however, general agreement that Java’s portion of the embedded systems market today is miniscule and that it will become significant over the next several years.

One of the things feeding this growth is the increasing use of 32- and 64-bit processors in embedded systems. IDC estimates there will be 250 million of them in use in embedded applications by 2000. By other estimates, 32- and 64-bit processors will be the fastest-growing segment of the embedded processor market. Of course, these are the processors that are best-suited to running Java and that can benefit most from Java.

According to a recent survey by Electronic Engineering Times magazine, nearly half again as many companies reported using 32-bit processors in their designs as reported using them in last year’s survey. The same survey reported an increasing interest in advanced languages, such as Java, which is now more popular for embedded applications than any language except assembly, C, and C++. Note, though, that Java proponents may make too much of this. Assembly language still leads by far, with roughly two-thirds of the survey respondents using it. C and C++ has less than half as much use as assembly, and Java has less use yet. On the other hand, most survey respondents are working with smaller, 8- and 16-bit microprocessors (which don’t support advanced languages well), and Java is ahead of a number of traditional embedded systems languages such as Forth.

Networking: A LAN in your auto?

The other big trend in embedded systems is networking. Although many devices are still standalone, more and more of them can communicate with other systems. If it seems odd to think of a local area network in your car, keep in mind that there are already an average of 16 microcontrollers/microprocessors in the average new car, and Motorola, which is a major player in the market, predicts that by 2000 there will be 35 microcontrollers/microprocessors per new car. Some of them, such as the ones controlling the engine and the transmission, need to communicate very closely. As a result, automakers are hard at work on automotive LANs.

The trend toward networking is especially pronounced in areas like automation, where connecting “islands of automation” (as they are known in the business) has been the biggest goal of the last decade.

Factories have tended to automate piecemeal, concentrating on the parts of the production process where automation would produce the biggest or quickest returns. Now companies have to tie together these previously automated parts and integrate them into factory-wide automation systems. Since the pieces were installed at different times — often using equipment from different vendors — this is a challenge.

One important benefit of networked embedded systems is the ability to download upgrades or fixes across the ‘Net to the individual systems. Traditionally, the software has been burned into ROM, meaning that a software upgrade required replacing the chip. Today products such as modems from US Robotics and others use rewritable memory technologies such as flash memory and accept upgrades over phone lines.

The importance of embedded software

Which brings us to embedded software — and Java. The software component of the typical product has grown sharply in the last several years. Today it can easily be the dominant part of a product in terms of development time and expense — even more dominant in embedded systems than in the desktop. Not only is every embedded system a new application, but reusability has been limited, and often the target hardware isn’t available until late in the design cycle.

But even more than in desktop applications, embedded software is composed of relatively few types of constructs. The basic jobs involved in an embedded system aren’t that numerous, and that makes embedded systems ideal candidates for object-oriented languages.

Embedded software also has to perform correctly. Anything from the proper shade of brown on your morning toast to the lives of a planeload of passengers may be riding on the software. By their nature, rigidly object-oriented languages like Java are easier to test than non-object languages like assembly, or C++, which supports object-oriented methodology but also permits programmers to write code that is not actually object-oriented.

The idea of a distributed, object-oriented language for embedded applications makes a lot of sense. Indeed, many companies are rushing to deliver products using Java or tools that can be used to write such products.

Java and real-time operating systems

For example, several of the makers of real-time operating systems (RTOSs), like Wind River Systems, Microware, Integrated Solutions Inc., and Microtec, are adding Java capability to their systems. Because of the limitations of Java (see below) these RTOSs aren’t being rewritten in Java, but JVMs are being grafted onto them so they can run applets. Microware’s effort includes adding Spyglass’ Web Technology Kit (WTK) to its OS-9 operating system for embedded applications. The result is an embedded operating system with a JVM and a very compact Web browser that can act as a server as well as a client.

Other embedded and control tools for Java have been announced or are appearing. ObjectAutomation Inc., a Santa Ana, CA, maker of industrial control software, has announced a real-time Java-based control engine for Microsoft Windows NT and Windows CE. The product will use VenturCom’s RTX 4.1 RTOS and the PERC virtual machine from NewMonics Inc. of Ames, IA. (See the discussion of real-time Java below.) Several companies specializing in embedded software development, including Software Research Inc. and Wind River Systems (maker of the Tornado development system), have added Java support to their debuggers.

Applications also are starting to appear — both those written entirely in Java, such as Forge Software Corp.’s Java Manufacturing Interface, a Java-based front end for interfacing with legacy and client/server manufacturing applications, and HMS Software Inc.’s Shop Floor Control and Data Collection, which tracks assemblies and components on the shop floor. Other companies are adding Java capability to their products. For example, SoftPLC, a Houston company that makes PC-based replacements for process controllers, has added to its software the ability to create additional instructions with Java.

Applications: How Java fits in

In general, Java is more likely to be found in higher-end embedded systems, handling things like user interfaces and communications over a network. This high-end focus exists primarily because the user interfaces, communications over networks, and the like are where the development momentum is in the much larger desktop market. For example, nearly all modern browsers can handle Java code, making it easy to Internet-enable a system with Java. Java also fits best in higher-level embedded systems because Java’s disadvantages for embedded systems, such as its resource demands and its lack of built-in real-time capability are less important at these higher levels.

One of the advantages of Java is that it is not an all-or-nothing proposition. If you want to start reaping the benefits of Java in your embedded system, you don’t have to rewrite all your software in Java. You can add a JVM to your product and use Java for jobs like communicating.

In fact, if you intend to use the Internet or an intranet as your network, Java is probably the leading contender for an embedded language, just as it is on Web-based applications in general. This has resulted in an explosion of embedded Java applications in highly visible projects such as the Hubble Space Telescope. NASA used Java to write part of the user interface for the Control Center System so that users anywhere in the world could obtain telemetry and engineering data from Hubble over the Internet. Sun collaborated with NASA on the Web Interface for Telescience (WITS), which is used to let Web surfers run simulated Mars Rover missions by downloading an applet. On the next mission in 2001, WITS will actually be used to run the Rover.

The Java strategy is especially attractive in the industrial controls and automation market. One of the outstanding characteristics of the controls market in the 1990s is how much it resembles the computer market of the 1970s. There is a strong reliance on proprietary solutions built on proprietary architectures.

“Almost any general-purpose programming language and architecture looks like an improvement to the customers [compared to] the very vendor-centric stuff you have today,” says Scott Lundstrom, director of research, enabling technologies for Advanced Manufacturing Research, a Boston, MA, firm specializing in manufacturing and automation. “There’s a move to open systems because it means improved competitive features and price-performance in an open market.”

“The challenge is that the vendors of proprietary systems feel they have achieved some level of customer-locking, and they are very hesitant to move to the more competitive marketplace of open solutions,” says Lundstrom.

Java flavor du jour

One of Java’s other advantages is that it lends itself well to dialects for special applications. Sun has been playing to the embedded market, among others, by developing dialects for applications such as smart cards.

Smart cards, containing a microcontroller and a small amount of memory, promise to be one of the major growth industries of the early 21st century. According to Siemens Semiconductors, part of German electronics giant Siemens AG and a leading maker of smart card products, the market will grow from about 3 million this year to nearly billion by 2001, and continue to grow strongly after 2001.

Sun has announced a Java dialect called Java Card that can run in much smaller microcontrollers and memory spaces — as little as 256 bytes for the virtual machine from startup Integrity Arts (San Mateo, CA). Schlumberger Ltd., the first licensee of Java for smart cards, already sells its Cyberflex Java smart cards and development kits, and Gemplus, the leading maker of smart cards, already has announced plans to move to Java. And in July Siemens Semiconductors announced it would license Java technology for its new generation of smart cards.

In April Sun announced two other Java dialects, PersonalJava and EmbeddedJava, also designed for embedded applications. PersonalJava is optimized for network-connectable consumer products such as set top boxes. It assumes the product has a display, but not necessarily a keyboard or a mouse. EmbeddedJava is for products with more limited display capability, including instrumentation, factory automation equipment, pagers, and phones. The reference implementations of PersonalJava and Embedded Java, as well as for a new version of Java Card, 2.0, are due by the end of 1997.

Drawbacks 1: Size and speed

By the standards of embedded systems, Java is big and power-hungry. To a designer used to working with 8-bit controllers with a few thousand bytes of ROM and RAM, the idea of system software that requires a 32-bit processor and a megabyte or more of memory is daunting.

The resource issue is inherent in Java. “With Java you have to allow space for the Java virtual machine and decoding all the classes on the fly,” says Vladimir Ivanovic, senior marketing engineer for runtime solutions at Microtec. “The other part of it is that you have to run the interpreter. If you try to save time by adding a JIT compiler, you increase the memory consumption. Personal Java might take up a megabyte of RAM for the JVM and classes,” says Ivanovic.

A 32-bit system with a megabyte of memory sounds huge for an embedded system. But it is not that uncommon anymore. What’s more, the systems that use 32-bit processors tend to be a better natural fit for Java. “Thirty-two-bit applications tend to be larger and networked,” Feigenbaum points out.

Java also is slow. This becomes a critical limit if the timing of the system is tight. Again, this is not an insurmountable problem. Better Java interpreters, JIT Java compilers, compiled Java, and Java processors will speed up execution considerably. All of these approaches are in the works, especially for the embedded market.

Each of these approaches to speeding up Java has its own advantages and disadvantages, which is why we will probably see all of them in the near term. Using compiled Java code rather than the JVM, for example, makes for a smaller and much faster package at the expense of not being able to download applets. Microtec is one of the companies pursuing the compiled Java approach. In addition to its JVM, Microtec offers a Java compiler that produces instructions in the target processor’s native code.

“If someone needs to download random applets, then the JVM is the way to go,” says Ivanovic. “If they don’t, they get much better performance with compiled Java.”

But if you’re going to compile Java code, why use Java at all? It seems to negate most of the advantages of the language, such as “write once, run anywhere” and the ability to download modules as needed. The answer, according to Ivanovic, goes back to the fundamental nature of Java. Besides being simpler than C++, Java has object orientation and all the constructs needed to write non-real-time embedded systems. Sun claims Java programmers are much more productive than C++ programmers, applets and “write once” aside, and some of Sun’s customers have supported this claim based on their own experience with Java. (One recent example: The director of editorial technology at Time Inc. New Media said recently that Time developed a new dynamic version of its Money Magazine Web site, Money.com Plus, in “a third of the time it would take with C++.”)

Another way to shrink the size and boost speed of Java is to use a microprocessor that realizes the Java virtual machine. The processor’s native instruction set is Java, in other words. The first such processor was produced by Rockwell Collins in August, 1997. Sun announced a family of such devices in 1996, but as of this writing hasn’t set a release date.

Meanwhile, Patriot Scientific Corp. (San Diego) has a Java processor that is a port of the JavaOS to the company’s own 32-bit PSC1000 processor. Unlike the Rockwell Collins effort, this is a merchant part, which sells for less than 0 in high volumes. The PSC1000 processor runs at 100 MHz and is available in 3- and 5-volt versions. The company started shipping Java development boards in early December.

The Rockwell JEM1 is a 50-MHz part that averages only 60 milliwatts of power consumption and has all the standard features for an embedded microcontroller. Its size, power, and speed make it very well suited for mid-range control applications. Rockwell Collins has compared it in size, computing power, and other features to the processor needed to run a PDA or similar handheld device.

The JEM1 is an excellent example of how and why Java is penetrating the embedded systems and controls market. For starters, Rockwell Collins isn’t a chip maker (although its parent, Rockwell, also owns Rockwell Semiconductor, which of course makes chips). Rockwell Collins makes aviation electronics systems (avionics), and it designed the JEM1 not for sale, but to power its own avionics systems. Note that the company did not use Sun’s picoJava core. Because the JVM’s architecture is stack-based it is a good match for many traditional microcontrollers, including Rockwell’s AAMP microcontroller. The JEM1 is based on the AAMP rather than picoJava.

“We have our own microcontroller design [the AAMP] that we have been putting in our own products,” says Nick Mykris, manager of the advanced microprocessor section at Rockwell Collins. “We suffered from having to design and maintain our own tools.” Not only was this a major effort, Mykris says, but the company was always behind when compared to tools from commercial vendors. However, Rockwell Collins did have a lot of experience with designing stack-based microprocessors, which is what a Java processor is.

“When the JVM spec came out a couple of years ago we looked at it and realized we were doing that already. Here was a way we could use commercial off-the-shelf tools, and if we needed more throughput we could go to commercial versions of these processors without having to recompile everything.” This approach works because the native instruction set of a Java processor is Java, no matter who makes the processor or what the design is.

Like a lot of embedded systems, avionics are becoming increasingly software-driven. Java’s combination of object orientation and a write-once-run-anywhere paradigm considerably speed up software development, especially cross-platform development.

“We do a lot of host development as well,” says Mykris. “With Java we have an architecture supported on the host, which is easily obtained and which uses the same source [as the target microprocessor]. With all that, it becomes much more efficient to develop applications.”

In embedded systems, the target system and software often are developed simultaneously. The code can be developed and tested on another JVM while the hardware is being developed. Companies already do this with microcontroller emulators on development platforms such as workstations, but the universality of Java code makes the process more accurate and faster.

(Typically, after designers have decided how to partition the tasks between hardware and software, and picked the processor they will use, they start writing the software using emulators. The first stage is typically done with a software emulator on a PC or workstation. Later, as the details of timing and such become more important, the emulation is done using a hardware emulator or a development system using the actual processor. There are a number of problems inherent in this process, not the least of which is that designers often end up rewriting critical sections of code two or three times as they move from emulator in software to emulator in hardware to actual hardware. Java can’t eliminate all the problems, but it has two features that help alleviate them. One is object orientation, which lets designers treat software functions as plug-in modules. Those modules can be more easily replaced by updated software, or even hardware if needed. The second is the write-once run-anywhere paradigm. That works well enough to eliminate problems caused by differences in code that will run on an emulator but won’t run on the real system.)

Finally, unlike conventional control systems, Java controllers are designed from the beginning to work with downloadable software. Improved or corrected versions of the software can easily be added to products in the field. This is especially important in rapidly developing, mission-critical fields like avionics. (Airplane passengers stake their lives in part on the reliability of aviation systems.)

While Rockwell Collins has no current plans to sell the JEM1 to third parties, the company says it may do so in the future. In addition, the JEM1 is just the first in a family of Java microprocessors. The next version, which is in development, will have about twice the power of the JEM1.

So far Rockwell Collins and Patriot are the only companies to produce a Java microprocessor. Sun announced in early 1996 its JavaChip family, which consists of the picoJava core and the microJava and ultraJava microprocessor families. Sun expects its first actual Java processor, the microJava 701, to be in volume production by the second half of 1998. The microJava 701 will feature a newer version 2.0 of Sun’s picoJava microarchitecture.

PicoJava is not a chip. It is intellectual property — the core design, optimized for native Java code execution, that chips like Sun’s microJava 701 and its higher-performance sister, the ultraJava (expected in late 1998), will employ.

Korean manufacturer LG Semicon Co. (formerly Goldstar Electron Co.) expects to ship several devices using its version of the picoJava processor early next year. Likely applications include memory and graphics controllers for computers. LG Semicon will supply chips to Sun for sale to third parties. NEC Corp., which also has licensed the picoJava design from Sun, hasn’t yet announced its plans. Fujitsu Microelectronics, Mitsubishi Electronics, Thomson Sun Interactive, and Toshiba Systems Group also reportedly are working on picoJava-based chips. Meanwhile, Sun indicates its JavaStation, a thin client desktop machine (or network computer), will feature Java-specific processors in the future.

Drawbacks 2: The real-time problem

There is a fundamental irony in the fact that although Java was originally designed for embedded systems, it is not well adapted to true real-time applications. The main reason is that Java’s garbage collection feature interferes with the determinacy real-time systems demand. There are, however, a lot of embedded and control applications which are not real-time. Java’s portability, object orientation and ease of software development are extremely attractive for embedded systems and control applications that don’t demand real-time operation.

When people outside the field think of the requirements for real-time software, they usually think of speed first. Speed is important in real-time applications, but the key issue is determinacy, or predictability. A real-time system must be able to perform an operation within a known time window and be able to do it every time that operation is called. (Of course, there’s also the problem that no commercially available distributed operating system is strictly real-time. If you are going to use a distributed architecture you have to settle for “near-real-time,” a nebulous term, or deal with a very arduous and messy custom build of a real-time distributed OS.)

Determinacy is where Java’s garbage collection feature works against it. Garbage collection is one of the things that simplifies Java programming, so the programmer doesn’t have to worry about de-allocating memory when an object has finished executing. But the programmer can’t fully control when garbage collection will execute (programmers have limited control, but if the JVM senses it is running out of memory it will initiate garbage collection) and has no control over how long garbage collection will take to complete. This introduces a fundamental indeterminacy into Java that programmers must live with and vendors can only try to work around.

The usual way around these problems is to graft the Java virtual machine onto a real-time operating system and to write the real-time pieces of code in languages such as C or assembly. This is what most of the RTOS companies with Java offerings are doing. A more sophisticated approach is NewMonic Inc.’s PERC, which replaces the JVM with a virtual machine that includes a couple of new constructs. Under PERC, the operating system reports to the application and it is up to the application to decide how to handle the situation. Several RTOS companies, including VenturCom, have licensed PERC from NewMonics to use in their systems.

None of these approaches produces a 100 percent pure Java application. The mixed-environment operating systems require routines in other languages to function. The PERC technology is Java-like rather than Java and it puts a load on the application, which has to decide how to handle possible indeterminacies as they occur.

Sun may have its own plans in this area. Sun’s recent acquisition of Chorus Systems gives the company a highly flexible, modular, distributed, microkernel-based embedded operating system that can run on as little as 16 kilobytes of RAM. The Chorus technology would make an excellent base for a true real-time version of Java, possibly without garbage collection.

Acceptance

Java is still in the early acceptance phase in embedded and control systems. A lot of companies say they are interested in Java applications, but only a few of them are actually trying it. Still, Java definitely has momentum in these markets. Within a few years Java may well be the dominant tool for embedded systems software development.