Embedded Web Servers: Status and Issues

  • By Won Kim, Jae-Young Hong, Doheon Lee, Eui-Kyeong Hong, Kyung-Chang Kim
  • July 13, 2001

The miniaturization of computers and electronic devices has given rise to embedded systems of ever-shrinking size. The concurrent explosion of Web technology is now bringing about embedded Web-server technology as a fusion of embedded system technology and Web technology. A vast network of very tiny computers, each with an embedded Web server, offers an intriguing glimpse into the not-too-distant future of the ways in which people and organizations will live and function. This article provides a brief survey of the current state of embedded Web-server technology, describes the architectural framework for supporting embedded Web servers, and outlines key technology trends and issues to overcome.

World Wide Web technology has brought about the Internet-based information revolution that has started to change the everyday life of people and organizations around the world profoundly. Web technology includes the Web browser, Web server, common gateway interface (CGI), hypertext markup language (HTML), and hypertext transfer protocol (HTTP). HTML standards for formatting and displaying Web pages, a CGI standard for linking applications with Web servers, an HTTP standard for communicating Web pages, use of universal resource locator (URL) to uniquely identify any Web site, easy-to-use Web browsers to browse the Web pages, and availability of software tools for easily creating Web pages, have been responsible for people and organizations around the world building millions of Web sites and making unlimited types of information available for access by anyone equipped to access the Web.

Today, the Web browser runs on desktop or palmtop computers and the Web server runs on workstations. However, now there is a flurry of activities, both in academe and industry, to have the Web server run on "very tiny" computers that can be included in all conceivable devices that people can carry or that people use in everyday life.1,2 Such devices include automobiles, home electronic appliances (refrigerators, microwave ovens, light and temperature controllers, televisions, etc.), security systems, all types of sensors and actuators, cellular phones, pagers, and smart cards. The premise of these activities is that once a device can be connected to a Web server running on a very tiny computer, the data gathered by the device can be stored in the Web server, or be routed to a large repository on a "larger" computer somewhere on the Internet; and that authorized people can access the data from anywhere via the Internet and can control the devices.

The current activities on embedded Web servers are efforts to combine the "embedded technology" (that is, a computer, a sensor, wireless communication, and a power supply in a single device) and the Web technology. This "gather data from anywhere a device can be connected to a Web server," "access the data from anywhere," and, where appropriate, "control the device from anywhere" creates a new paradigm of Internet-based information processing.

In this article, we survey notable current research and development activities for embedding a Web server on a very tiny computer, review a general architectural framework being developed for embedded Web servers, and discuss technological trends and issues that will need to be addressed before a widespread adoption of the embedded Web-server technology can become a reality.

CURRENT R&D ACTIVITIES
Already there are several embedded Web servers on the market. These include RomPager from Allegro Software, EmWeb from Agranat Systems, GoAhead WebServer from GoAhead Software, MicroServer from SpyGlass, and WebPort from InterNiche. The following are brief descriptions of these products:

  1. Allegro RomPager 2.20 from Allegro Software (http://www.allegrosoft.com)
    • runs on a variety of operating systems, including NetBSD, Digital Unix, BSDI, AIX, OS/2, Windows 3.x, SCO, HPUX, Macintosh, Embedded, Windows NT, Linux, MS-DOS, Windows 95, FreeBSD, IRIX, and Solaris; and
    • supports HTTP 1.1 persistent connection and PUT capability.
  2. EmWeb embedded Web server R3_03 from Agranat Systems, Inc. (http://www.agranat.com)
    • runs on a variety of operating systems including Digital Unix, BSDI, AIX, SCO, HPUX, Embedded, Windows NT, Linux, Windows 95, FreeBSD, IRIX, and Solaris;
    • supports HTTP 1.1 persistent connection and PUT capability; and
    • provides sophisticated access control methods.
  3. GoAhead WebServer 2.0 from GoAhead Software (http://www.goahead.com)
    • runs on a variety of operating systems, including Embedded, Lynx, Windows NT, Linux, Windows CE, QNX, Windows 95, Windows 98, and Solaris;
    • supports HTTP/1.1 persistent connection;
    • provides sophisticated access control methods, including S-HTTP and SSL; and
    • source is available free of royalty.
  4. Spyglass MicroServer 2.0 from Spyglass (http://www.spyglass.com)
    • runs on a variety of operating systems, including Embedded, Windows NT, Linux, and Solaris; and
    • supports HTTP 1.1 persistent connection and PUT capability.
  5. WebPort from InterNiche Technologies (http://www.iniche.com)
    • supports HTML 2.0;
    • all code is written in ANSI C;
    • portable multisession HTTP 1.1; and
    • "Server-Side push" facility allows for continuous updating of browser screens.
There are a number of university embedded Web server R&D projects, including the University of Massachusetts at Amherst, Stanford University, Massachusetts Institute of Technology, Carnegie–Mellon University, and Ewha Women's University (in South Korea). The following briefly summarizes some of these university activities:

  1. Matchbox Web Server at the Stanford University (http://news-service.stanford.edu/news/1999/february10/webserver210-a.html) has the following characteristics:
    • A single board AMD 486-SX computer with a 66 MHz CPU
    • 16MB RAM and 16MB flash ROM
    • RedHat 5.2 Linux with a Web-server daemon
    • Two serial ports, one printer port, and a connector for a floppy drive
    • 20 gram, 5V power supply
  2. The iPic project (or Match Head Web Server) at the University of Massachusetts at Amherst (http://www-ccs.cs.umass.edu/~shri/iPic.html) has the following characteristics:
    • CPU: PIC 12C509A (Clock: 4 MHz)
    • EEPROM: 24LC256 (Capacity: 32K bytes)
    • Implements the iPic tiny TCP/IP stack
    • HTTP 1.0 compliant Web server
    • Simple telnet server (for editing files on the chip)
ARCHITECTURE FOR SUPPORTING EMBEDDED WEB SERVERS
An embedded Web server is not useful unless it can be made to work with a device and a computer that hosts at a minimum a Web browser and in general the Internet. The following depicts a typical architectural framework that includes an embedded Web server. The architectural framework includes, besides an embedded Web server, a device controller, a file system and storage, application functions, and a communication system. These must all be made to fit into the storage and CPU processing power limitations of the very tiny computer on which they must run. The following describes the characteristics of the architectural components.

  • The device controller controls the device with which the embedded Web server is to interact via the application functions. The embedded Web server may gather data from the device or send signals to control the device. The device controller and the very tiny computer communicate via a serial communication line, if they are not on one board.
  • The application functions are programs that interact with the device and are interrupt-driven to receive data from the device and to send control signals to the device. They are implemented through CGI or Server Side Include (SSI), and are highly optimized in size. Even if they are implemented through CGI, they are commonly attached to the Web-server process as local functions.
  • File systems for storing HTML files for the Web server are typically implemented on memory devices such as EEPROM rather than magnetic hard disks. They are often called virtual file systems (VFSs).
  • Since most embedded Web servers are implemented on very tiny computers, they rely on the TCP/IP stack with a serial data link protocol such as Serial Line Internet Protocol (SLIP) and Point-to-Point Protocol (PPP) to connect to the Internet rather than the full TCP/IP stack with the standard Ethernet protocol.
  • The Web server and TCP/IP stack are also highly optimized in their size to fit the very small-sized hardware platform.
The current technical focus on the implementation of the embedded Web server is on the minimization of the footprints of all software running on very tiny computers. The following summarizes the footprints in some of the current implementations of the embedded Web servers.

Embedded Web servers

  • Allegro's RomPager: 60K (code: 25K, static data: 4K, dynamic data: 5K per connection)
  • Agranat's EmWeb: 8–50K (typically 25K)
  • GoAhead Software's Open WebServer: 60K
  • Spyglass's MicroServer: 36K
  • InterNiche's WebPort: 30K (code: 13K, static data: 3K, dynamic data: 5K per connection)
  • University of Massachusetts's iPic: 256 words (12 bits/word)
Embedded TCP/IP stack
  • Agranat's EmStack: 35K
  • InterNiche's Portable TCP/IP: 51.5K
  • University of Massachusetts's iPic: 256 words (12 bits/word)
The two basic operations involving an embedded Web server are to GET and PUT status information on a device. The following details how these operations are accomplished using the architectural framework shown in Figure 1.

Get state information.

  1. The user gives the URL of a device to the Web browser.
  2. The Web browser sends the URL to the Web server attached to the device.
  3. The Web server invokes an application function to capture state information.
  4. The application function captures the state information from the device controller, and composes an HTML representation with the captured information.
  5. The Web server returns the HTML representation to the Web browser.
  6. The Web browser shows the HTML representation to the user.
Set state information.
  1. The user is given a form to set device state information through the same process as in get state information.
  2. The user fills out the form.
  3. When the user completes the form, the Web browser sends it to the Web server.
  4. The Web server invokes an application function to modify state information.
  5. The application function commands the device controller to modify control parameters according to the received form information.
  6. The device controller changes the parameters.
In a distributed network that includes many devices of arbitrary types, and associated embedded Web servers, it becomes highly desirable to empower the devices to join and leave the network at any time without causing any disruptions on the network. The devices (through their associated embedded Web servers) in general must include the following capabilities.

  1. Configuration: Self-configuration without human administrative intervention.
  2. Self-announcement: Ability to announce its presence to the network.
  3. Description: Ability to describe its capabilities.
  4. Discovery: Automatic discovery of other devices on the network.
  5. Querying: Ability to query/understand the capabilities of other devices on the network.
  6. Interoperation: Seamless interoperability with other devices when appropriate.
Currently, there are two proposals for supporting such device capabilities: JINI from Sun MicroSystems (see Fig. 2), and Universal Plug and Play (UPnP) from Microsoft. UPnP is an open standard technology for transparently connecting appliances, PCs, and services by extending Microsoft's Plug and Play technology to support networks and peer-to-peer discovery and configuration. The following briefly summarizes the capabilities and limitations of each.

JINI

  1. Configuration: JINI does not address this area.
  2. Self-announcement: Registration to lookup services.
  3. Description: Upload JAVA code, which is a proxy that can be used to contact an interface on the device and invoke methods of that interface.
  4. Discovery: Querying lookup services with properties of devices of interest.
  5. Querying: Download the corresponding JAVA code.
  6. Interoperation: Remote method invocation (RMI).
UPnP
  1. Configuration: Supports through DHCP, AutoIP, Multicast DNS.
  2. Self-announcement: Multicast an ANOUNCE message (URI of the device) through HTTP. An optional directory service can store this information.
  3. Description: Multicast an ANOUNCE message (URL of the XML page describing the capabilities of the device) through HTTP. An optional directory service can store this information.
  4. Discovery: Multicast an OPTIONS message targeted at the URI of the device.
  5. Querying: Access the corresponding XML page.
  6. Interoperation: UPnP does not address this area effectively.
EMBEDDED WEB-SERVER TECHNOLOGY TRENDS
There are a few trends regarding embedded Web servers. One is that the very tiny computers are becoming even tinier. The iPic computer at the University of Massachusetts at Amherst is the size of a match head. At the University of California at Berkeley, a project is underway to create a device that combines a microprocessor, a two-way optical communication, a sensor, and a power supply in a device the size of a grain of sand. This device is labeled a "computer dust."3

We believe that the current two-tier organization of the architectural framework for embedded Web servers will need to give way to a three-tier organization. One problem with the two-tier organization is that it makes it difficult to implement centralized control over multiple devices. The following is a three-tier organization that we envision.

With a three-tier organization of computers, the computer in the middle runs a conventional Web server. The conventional Web server can process not only HTML pages but also the more powerful eXtensible markup language (XML) documents. Powerful device drivers for multiple devices may run as applications on the host that runs the conventional Web server through CGI or SSI. Further, the host computer for the conventional Web server may provide services necessary for device lookup and directory of devices in the proposed JINI and UPnP network architecture.

Although one current focus of R&D in embedded Web servers is on minimizing software footprints, we feel that as the very tiny computers become more powerful this singular focus will give way to supporting embedded software of varying footprints. It may be acceptable and even necessary to include fuller versions of embedded software (Web server, application functions, TCP/IP stack, and real-time operating system) on very tiny computers for certain types of applications. However, as the very tiny computers become even tinier to suit the environmental requirements of other types of applications, the need for minimal-footprint software will continue to exist.

EMBEDDED WEB-SERVER TECHNOLOGY ISSUES
It is clear that the embedded Web-server technology should make it possible to automatically collect and access data (e.g., money left in an ATM machine, money deposited and soft drinks remaining in a vending machine) from many devices (e.g., ATM machines or vending machines that are located around a city). The capabilities should lead to more cost-effective and real-time management of devices, even of such devices where it is too dangerous for humans to be. However, presently the technology is in its infancy. Some technology and gadgetry-oriented early adopters have taken up the technology, but the market is far from established. Although marketers of the technology mention vaguely limitless applications of the technology, many of the example application scenarios they mention do not amount to much upon closer examination. In other words, it will take a while before the technology becomes real and the market needs for the technology to become clear.

In terms of technology, there are a number of issues that need to be addressed:

  • Security: Security is a well-known major problem on the Internet. The security issue arises from the fact that data must pass through many layers of software from its origin to destination, and each layer of software has bugs through which security may be breached. With an embedded Web server, the efforts to minimize software footprints may compromise security by throwing away code designed to enhance security and by introducing new code that will need to be hardened through many years of use and discovery. The watered-down communication system in use with embedded Web servers today, namely the PPP protocol along with the minimalist TCP/IP stack, is an example of less secure software than the full-fledged TCP/IP suite including the Ethernet protocol. Further, many of the devices containing embedded Web servers may be easily lost or stolen, and the embedded Web servers in lost or stolen devices can make a great entry point for hackers to pick off data and wreak havoc on the data of the device owners.
  • Privacy: As very tiny computers, sensor devices, and wireless communication are combined, privacy of people and organizations can become precarious. If, for example, the "computer dust" becomes a reality, it is not clear how such "dust" can be detected if it is deployed to eavesdrop on communications and conversations.
  • Standardization: There needs to be a set of standards regarding the vocabulary (i.e., variables) for accessing state information and controlling the operations of each type of device. Each type of device, and indeed each device within the same type, can perform a set of operations, and there needs to be a standard on the vocabulary and semantics of these operations. UPnP includes a proposal for the use of XML for describing such operations. However, there still needs to be a standard on the semantics of the different XML tags to be used for the different operations. Besides this, there is the potential issue of different embedded Web-server network standards involving JINI and UPnP, as these are being pushed by two major vendors whose tendency has been to offer different standards on almost everything.
  • Communication network infrastructure: Since the very tiny computers that will house the embedded Web servers must communicate with "conventional" computers and such communications in general should take place wirelessly, wireless communication network infrastructure is essential. "The Post-PC Era"2 points out that today, wireless LANs, terrestrial wireless data networks, and high-speed "last mile" connectivity to homes, etc. are just beginning to be deployed and need to come to maturity.

References

  1. Burton, L. "Embedded Internet Systems: Poised to Take Off," IEEE Internet Computing, May/June 1998.
  2. Press, L. "The Post-PC Era," Comm. of the ACM, 42(10), Oct. 1999.
  3. Locke, M. "Smart Dust in the Wind," Austin American-Statesman, Austin, TX, Nov. 22, 1999.

Suggested reading

  1. Cocks, H. "Web May Reach into Tiny Places," Austin American-Statesman, Austin, TX, Oct. 9, 1999.
  2. Waldo, J. "The JINI Architecture for Network-Centric Computing," Comm. of the ACM, 42(7), July 1999.
Most   Popular