Designing The Next Step In Internet Appliances

As electronic devices evolve, they are becoming more intelligent and complex. In addition, the need for people to interact with them is becoming much greater. One obvious choice for person-device interaction is use of the ubiquitous web browser. More electronic devices are being designed today to be network accessible through a web browser. Such devices are often referred to as web-enabled information appliances or Internet appliances.

While benefits of merely web-enabling a device are large indeed, to fully tap the power of the Internet, the device capabilities must go beyond web enabling. For an Internet appliance to be practical and versatile, it must include a variety of hardware and software subsystems. Hardware subsystems must include a processor, an Ethernet controller, a memory and I/O controller, and support logic. Software subsystems, as a minimum, must include an RTOS, a web server (HTTP server), a TCP/IP protocol stack, and an e-mail and FTP server. Today's conventional design approaches dictate that the engineer choose and integrate these discrete hardware and software subsystems from a multitude of choices (and vendors) into an elegant, cost-effective solution.

Until now, such a conventional approach has been cost and time prohibitive for most engineers outside the computer industry. As recently as three years ago, web servers still ran only on high-end Alpha or Sun computers with massive disks. As a result, network-enabling was limited to people-centric applications—people connected to the Internet or Ethernet through computers.

Over the past few years, peripherals such as printers, faxes, and disk drives have been web-enabled, but the power of the Internet and Ethernet remains largely untapped by all devices that have anything to do with information, measurement, or control. Examples of such potential applications abound in a broad range of industries and consumer products; from digital video cameras and medical devices to industrial and building control systems.

Today's Web Devices Recent advances in system-on-silicon technology promises to change all that. Embedded technology has evolved far enough to let web-servers run on single board computers with flash memory as their mass storage. Known as "thin servers" and "thin clients," embedded versions of web servers, such as Spyglass MicroServer, are now readily available. This shrinking of technology has allowed these smart devices, now embedded with a web server, to be accessible through a familiar web browser. Complete network connectivity system-on-silicon, such as the NET+ARM chip, can significantly reduce design time and lower the unit cost of network-enabling products. These compact, low-cost solutions will enable engineers, even from noncomputer industries, to quickly transform their products into fully functional Internet appliances.

With the rapidly increasing popularity of the World Wide Web, embedded systems designers are discovering the advantages of enabling their devices to work on the web. One typical application is to allow the device to be configured using a web browser. Another application is the addition of status reporting by the device utilizing web content. Web content is defined as Hypertext Markup Language (HTML) pages images and applets sent by the device in response to Hypertext Transport Protocol (HTTP) requests from web browsers.

Use of Internet technology doesn't have to stop with mere web-enabling. As we shall discuss shortly in two example applications, for these devices to be practical, they need to handle messaging, data transfer, and diagnostics.

Messaging can be implemented using Internet e-mail protocols such as standard SMTP and POP3. Reliable and error-free data transfer is easy to implement using standard FTP, which can be used to either upload periodic measurement data to a specified host or download software for revision updates. The diagnostics are usually part of a user application software, which, for example, may monitor temperature, pressure, or flow in measuring devices or status such as "paper jam" in a printer. The alerts generated from the diagnostic program use messaging to inform people, and data transfer capability can upload files containing error logs for further analyses.

Before we examine the designing of an Internet appliance, let us look at two application examples that show the dramatic benefits that are possible when a device is transformed into an Internet appliance.

Today, most printers can be connected to Ethernet or the Internet as a shared resource. A long-time problem for customers and vendors is the difficulty of installation and configuration for network printing. Each vendor provides proprietary software which runs on some but not all platforms. Furthermore, each vendor's graphical-user interface (GUI) has a different look and feel, making it difficult for one person to use products from multiple vendors.

One solution is to embed an HTTP server in the printer. This enables HTML screens to display information that can be viewed through a browser. The user benefit: the GUI now becomes a familiar web-browser, which enables the user to interact with a printer remotely. The vendor benefit: the GUI needs to be written only once for it to work on all platforms. Shown is an example of a typical HTML page from a printer (see the figure).

Now that the printer is web-accessible, some of the parameters that can be set or viewed include printer IP address; default gateway; subnet address; AppleTalk name and zone; Novell printer server name, which directory services tree to attach to; which paper tray to use; type of paper; amount of toner; number of pages printed; and printer status, such as ready, in-use, or paper-jam. All these parameters can now be accessible to any authorized person across the network.

Adding messaging or e-mail capability can further extend the functionality of the shared printer. For example, when the toner is low, the printer can send an e-mail message directly to the supplier to deliver the toner cartridge. By adding diagnostic capability, the printer can now alert the office manager whenever there is "paper jam" through an e-mail. Finally, data transfer capability such as FTP can allow vendors to download firmware upgrades and bug fixes directly to the printer.

Let's look at a hypothetical design of a flow meter used to monitor the amount of a substance moving through it. It needs to record the flow at various times and send an alert to intended recipients when the flow is "too high" or "too low." By network-enabling the meter, some of the parameters that can be configured remotely during the installation using a browser are:

• Low Flow-Level Alarm Limit;
• High Flow-Level Alarm Limit;
• Who to notify in case of failure;
• How often to record flow amount;
• Where to store flow data.

With an embedded FTP server, the meter can transfer the flow data to a specified file on a specified computer. An outbound SMTP e-mail server can send an alert to any number of recipients that can be specified depending on the nature of the alert. The message also can be sent to any specified mailbox, including a pager. Having received an alert, the service technician can remotely log into the meter using its IP address, run additional diagnostics, and even reconfigure the meter or download new firmware to resolve the problem without ever leaving his office. What these two examples point out is that the possibilities are limited only by the imagination of the design engineer!

Design Challenges Although embedded technologies are making web-enabled devices much easier to design, several challenges still remain. One of the most serious is supporting dynamic web content on a ROM-based system.

To incorporate web content into an embedded device, an HTTP server is first incorporated into the device. This server processes HTTP requests and responds with web content. The next challenge is to incorporate the actual web content into the HTTP server.

Commercial web servers operating on Unix or Windows NT platforms have large file systems stored on disks which make incorporating web content fairly straight forward since various pages and images can be added to a known directory that then makes the web accessible. Embedded devices usually only have read only memory (ROM) with no file system. The web content in this case has to be incorporated directly into the embedded device application stored in ROM. There are various approaches to incorporating web content into the embedded source code.

Someone proficient in writing HTML by hand can develop HTML pages by adding various HTML markup tags along with text content in a text editor. These same pages can then be incorporated into an embedded device by writing application code to physically send back the HTML page. The page is stored in a large character buffer in the device and is sent back utilizing a network application programming interface such as sockets.

This approach has the following limitations. The tools for generating HTML pages have advanced to the level that web masters do not generate HTML pages by hand because using a tool is much more efficient and removes a significant amount of the tedium involved in working with the markup tags.

Static HTML pages, those whose content never changes, is only a small part of the possible web content provided by a web server. Dynamic content, whereby the web content changes over time is common place and necessary for status reporting. Forms processing, accepting user input and acting on it, also is commonplace and necessary to make configuration changes in an embedded device. An HTML generation tool does not solve the problem of providing dynamic content or forms processing. Application code in the commercial web server (written in Perl, C++, or Java) is necessary for both of these types of web content.

The problem then for embedded devices is how to incorporate static content, dynamic content, and forms processing into the embedded HTTP server source code. The solution to this problem parallels that taken for commercial web servers. Embedded system designers are writing conversion tools that automatically convert web content into application source code. Static pages are converted into the necessary program calls to send back the HTML, image and applet content that does not change over time. For dynamic content, proprietary non-HTML markup tags are inserted into the HTML source using an HTML editor. The conversion tool recognizes these tags and produces shell routines and calls to the routines in the application source code.

The embedded designer is then responsible for implementing the routine such that the appropriate dynamic content is returned when the routine is called. The conversion tool also recognizes HTML forms and adds then necessary shell routines to be called when forms data is sent back to the embedded web server.

The embedded web server typically has an application programming interface which makes it easy to retrieve the Common Gateway Interface data supplied by the browser in response to a forms submission. The embedded designer is responsible for filling in the shell routine with the code necessary to handle the data and send back the appropriate reply.

By utilizing a conversion tool the process for incorporating web content into an embedded device is reduced to the following set of steps.

1. Generate web content using an HTML editor of choice. For dynamic content pages, proprietary tags are inserted where the dynamic portions are to appear.
2. Use a conversion tool to convert the HTML pages, images, and applets into embedded application source code.
3. Implement the generated shell routines that are specific to the overall application running in the embedded device.
4. Compile and link the resulting source code.

The embedded device can now serve web content that is static and dynamic. In addition, the embedded device also can process forms data returned in response to end user submissions.

The following example illustrates the first three steps in the above process for Osicom's NET+ARM product (see "A Code Example,"). Along with firmware to support an e-mail and FTP server, it comes bundled with an embedded HTTP server, and an application programming interface (API) into the HTTP server. This is a conversion tool that converts HTML pages, images and applets into source code. The basic techniques however, may be easily adapted to the development of any platform with similar capabilities.