An Embedded Distributed Operating Environment

With so many networked embedded systems today, it is optimal for embedded systems to be able to access services and objects on a remote workstation. Access to the remote workstation extends and enhances the functionality of an embedded application, and reduces CPU power and memory.

Embedded systems can access the services and objects on a remote workstation, such as the GUI, file system, database, sounds, images, and events, using many aspects of a Distributed Operating Environment. With the Internet, embedded applications can be configured, controlled, and manipulated in a standardized way from nearly any workstation anywhere in the world using an embedded distributed operating environment.

A Distributed Operating Environment is a software tool or collection of tools that allows applications to share resources over a distributed network. Resources can be nearly any type of data, CPU usage, or service available to a local host on a network. In this sense, a single application consists of many parts running on separate systems all communicating with each other and exchanging meaningful data.

Because of the limited resources on an embedded target, embedded applications benefit greatly from Embedded Distributed Operating Environments (eDOEs). Any networked embedded target running an application built around an eDOE can utilize remote services such as file systems, GUIs, event notification, sounds, and databases. These embedded systems can access such services and data objects from any remote host including workstations. Workstations will always have nearly infinite resources relative to the embedded system, so why not use them?

Although a specific eDOE and Data Acquisition (DA) system based on the reference implementation is our focus here, nearly all embedded markets, from automation to consumer electronics, benefit from eDOE applications. For instance, a data acquisition system located in a human lethal environment can make use of a remote workstation to display real-time data while logging the data directly into a database on a second workstation in another part of the world.

Embedded Distributed Operating Environment

An eDOE has to have at least two components—the embedded application, and any other remote system cooperating with the application. The remote system can be another embedded system or a workstation running nearly any OS such as Win95/98/NT, Linux, Solaris, or MacOS. Both systems are drastically different in physical configuration, but use a similar set of software to communicate. As long as both sides of the system use an agreed-upon protocol, they'll work together just like any other communication application such as FTP, Telnet, or HTTP. This may sound somewhat trivial but must be underscored because embedded systems don't have sufficient resources to support a complex application protocol. Because of this, the format must be trim enough to fit within the constraints of an embedded target and powerful enough to access workstation resources. The eDOE protocol can ride on top of TCP/IP, gaining the reliable data transfer required for complete communications.

Portability must be maintained across as many tool chains and CPU architectures as possible to create a truly distributed environment. Support for an eDOE should be written in C and should only use least common denominator syntax to ensure all compilers can handle the code. Only high level calls are necessary because the underlying TCP/IP stack and OS should provide necessary CPU and board support. This implies that the eDOE has no CPU dependencies and only needs OS independence and an interface to the middle-ware providing stack.

Writing a complimentary workstation application within a portable runtime environment provides embedded systems or other remote systems access to all resources of the workstation. As long as the application is written in a portable language such as Java, workstation portability is maintained. However, portability is restricted by the availability of a run time environment for the target OS. All eDOE systems can communicate with each other as long as they are on the same network such as a LAN, WAN, or the Internet.

Example eDOE: NetPeer

Several distributed operating environments already exist:

• Sun's Jini
• Lucent's Inferno
• IBM's T-Spaces
• U S Software's NetPeer.

We'll use NetPeer as our example, since it's a U S Software product. NetPeer is an eDOE targeted specifically at embedded systems and is meant to be CPU, TCP/IP stack, and OS independent.

NetPeer consists of two components—a C library to be linked with an embedded application and a standalone Java application capable of running within a Java Runtime Environment (JRE) on nearly any workstation. These two components are built around the same fundamental design and work together using the same application layer protocol.

The target side library and workstation application have a straightforward design that centers on generating and handling requests, with all requests modeled after Java method calls. The collection of all requests embodies the NetPeer API. NetPeer includes C support and Java support for the same API within the limits of the languages.

When a NetPeer system receives a request over the network, it sends the request to a request handler. The handler parses the request and takes the appropriate action. For example, when an embedded system wishes to instantiate a window frame on a remote workstation, the embedded system calls the newFrame ()system call with the necessary parameters describing the frame's height, width, and title.

NetPeer packages this call as a small TCP/IP data segment and ships it to the workstation. The workstation receives the request and invokes the constructor of the Frame class creating a new frame. The target and workstation use the same ID number for the new frame and to reference the frame in future calls. The embedded side also handles such requests, but because of the limitations of the embedded system, it may not be able to instantiate some objects. These requests are passed to the application for processing.

In the embedded C component of NetPeer, an API call such as newFrame ()occupies only a few bytes because it only needs to package the necessary description of the call and send it through the underlying TCP/IP stack. This means that there can be literally hundreds of such API calls in the library and all of them together will occupy less than 16KB of code space on the embedded system.

The workstation can also use the API. Since NetPeer is written in Java and has hooks for user-written plug-ins, the functionality of the workstation can be expanded by using the NetPeer Java API. Plug-ins can be written for Internet chats, email, Telnet, and other similar features, but more importantly can be written to cooperate directly with an embedded application.

Suppose, for example, that an embedded system collects data from a wall thermometer and has very limited memory. The application can connect to a workstation and initiate a thermometer display plug-in in a single line of C code. The thermometer passes the data directly to the plug-in for display, eliminating the need for the embedded system to have code to support the display or build it up component by component. The workstation application contains all the resources and infrastructure necessary for handling this support and eDOEs such as NetPeer can capitalize on this type of support while reducing the overall cost of the embedded system.

NetPeer includes support for C and for Java, so comparing similar calls is most instructive. The newFrame()functions has the following form in C:

Notice the frame's object ID number is returned to the application. The parameter connection represents the TCP/IP socket, and all sizing parameters are in pixels. The same call made from a Java NetPeer plug-in has the following form:

In the Java version, the NetPeer package must be imported and the entire collection of API routines treated as a single object with many methods. The call to the methods, however, is nearly identical. In place of a connection, the Java side API uses a plug-in ID number. The remaining parameters are the same.

Using Java as the basis of NetPeer offers several advantages and a few disadvantages. Java provides a standardization mechanism and a growing functionality base. Any time an eDOE application is going to make use of remote workstation resources, it can do so by using widely published Java methodologies. As Java continues to grow, any eDOE based on Java will grow as well, increasing the functionality of embedded applications. Java's portability is one of the biggest advantages because the workstation application runs without recompiling on any workstation with a JRE. Unfortunately, each workstation OS generates a different look and feel forcing tests to be conducted on as many JRE implementations as possible to ensure proper operation.

A Sample eDOE Data Acquisition System

U S Software built a sample data acquisition (DA) system to illustrate the use of the GUI aspect of an eDOE. The DA system records a temperature and a time stamp, then displays the information on a remote workstation. The embedded application completely controls the GUI displayed on the remote workstation. The demo is Internet accessible by downloading a free version of the workstation application from www.netpeer.com. To connect to the demo, specify amd_temp@ussw.com in the connection dialog box found under the connection menu.

The DA system allows up to six simultaneous users at any given time. Each user runs the NetPeer workstation application and connects to the DA. Once connected, the user is presented with a GUI entirely constructed by the DA system using NetPeer calls. The GUI displays a time field, a temperature field, and a control button that turns the DA system on and off. Only the first user has control over the data taking process, but all users can see the data.

Figure 1: GUI for time and temperature eDOE DA system as seen on a Win95 workstation running JRE version 1.1.8.

The demo runs on an AMD Net186 evaluation board and consists of:

• TCP/IP stack (U S Software's USNET)
• RTOS (U S Software's TronTask!, an RTOS based on the m ITRON 3.0 specification)
• NetPeer.

The AMD Net186 provides an ideal platform because of its small physical size (3.5x3.5-inches). It's also well-suited for communications because of its two serial ports and l0Mbit Ethernet controller. USNET provides TCP/IP support and drivers for the Ethernet controller. TronTask! provides board-level support plus multi-tasking capabilities. As shown by the "You Are Task 5" label in Figure 1, each user has an independent task governing the GUI. NetPeer provides all the GUI control and data logging functionality.

The GUI has four responsibilities:

• Initialize the task's mailbox
• Create the GUI
• Update the GUI as the data requires
• Shut down the task and connection.

NetPeer handles creating and managing the GUI as the user interacts with the system. The other responsibilities fall to TronTask! and USNET.

For the application to make good use of NetPeer's GUI support, it must handle two basic requirements. First, the application must instantiated GUI objects on the remote workstation. This is done through the NetPeer API. Each API call returns an object ID used to refer to the object in any future calls. Second, the application must specify which events generated on the workstation are of interest to the application. When the workstation detects an interesting event taking place, it will ship the event information back to the DA system so it may take the appropriate action. The following C code segment shows how the DA system uses NetPeer calls to generate the initial GUI frame as shown in Figure 1.

In this code example, the new frame is instantiated on the remote workstation connected to socket "c." Notice the newFrame() returns an ID number and that ID number is again used when changing the background and foreground colors of the frame. It's important to keep in mind that the target only needs to store the ID number of the frame because the workstation has the necessary infrastructure to handle the mechanics of the GUI.

The last call, onEvent() tells the workstation to report when the remote user attempts to close the window frame. Only the NP_WINDOW_CLOSING event will be reported back to the DA system. Only the requested events will be reported so there is no excessive traffic on the network. When the DA system receives the NP_WINDOW_CLOSING event, NetPeer will automatically call the UserEvents() function written as part of the application. The application actually handles the event.

The rest of the DA system's GUI is literally built up component by component. Text labels, the control button, and a menu bar are all added to the initial parent frame. Menus are then added to the menu bar and menu items are added to the menus. In each case, the DA system specifies which component GUT events should be shipped back to the DA system for processing. This approach allows the embedded DA system to create a complex, complete GUI in less than 100 lines of C code, including comments.

The final application on the Net186 occupies less than 210KB, including all C libraries, NetPeer, TCP/IP stack, RTOS and even data space. The data space alone for the TCP/IP stack occupies more than 80KB. NetPeer occupies less than 12KB of code space and less than 1KB of data space.

Only the GUI aspect of an eDOE is illustrated by the demo DA system although many other parts of an eDOE could be employed. All the data sent to the remote workstation could be stored directly in a database through a JDBC-ODBC bridge, allowing the data to be placed in its final format directly without having to FTP files or send email. Data could also be sent to another remote system for data reduction, analysis and/or filtering. The DA could also autonomously log on to any remote system when an extreme condition occurs. For example, if the temperature reaches a critical value, the DA system could log on to a remote workstation, display a warning message, and present the user with a diagnostic menu.

Other eDOE Applications

Many market segments from automation to consumer electronics stand to benefit from eDOEs. In the office, an eDOE application in a copy machine could eliminate the need for calling service agents to attend a machine. Any time the machine failed an internal diagnostic, the copier itself could log on directly to technical support and display a diagnostic screen. The copier also could log on to the manufacturer's development site and download new versions of software as needed or log usage information.

Consumers could also benefit from eDOE applications within VCRs. Users could log on to the VCR from anywhere in the world and instruct the VCR to record programs. The VCR itself would be capable of logging onto remote databases and/or downloading application code at will. Devices around the house could easily network together, distributing functionality from one unit to another. When the laundry finishes, notes can be placed on the refrigerator's message screen or the microwave's LCD display.

Control over factory robots or assembly lines is a prime target for eDOE applications. Robots employing eDOEs would be able to download new sets of instructions remotely and log any movements to remote databases for later review. Assembly lines could generate warnings on remote systems outside the factory anywhere or allow remote users to control the line. All these devices can incorporate password and other security features at the application layer depending on the needs of the application. NetPeer will facilitate the data exchange between the remote user and the device.

Distributed operating environments are already in use today in projects like NASA's SETI@Home project. NASA created a screen saver program capable of downloading data from NASA and using a computer's idle CPU to conduct analysis. Many high data volume experiments at Fermi National Accelerator Laboratories use distributed environments to control particle physics experiments, crunch data, and analyze data. Embedded systems stand to greatly benefit from this type of connectivity as demand increases for consumer devices. Applications will no longer be localized to a single device, but will be able to relocate functionality anywhere in the world.

By using an eDOE on an embedded target, the amount of RAM and other resources is greatly minimized, making it possible to significantly reduce the cost of an embedded system requiring remote communication. As the example application shows, a very powerful GUI can be created on a processor of limited power, reducing the cost of the embedded project. By using Java as a standardized interface, the learning curve is reduced by the sheer wealth of information available to the application engineer.

An Internet accessible demo of the DA system can be accessed through NetPeer at amd_temp@ussw.com. To access this demo, the user will need a copy of the NetPeer workstation. The NetPeer workstation application can be downloaded for free at www.netpeer.com. Once installed, look under the "Connection" menu and select the "Connect" menu item. In the text field type the address "amd_temp@ussw.com" to connect to the demo. Source code for the demo DA system described in this document resides at the same NetPeerURL.