April 10, 1997

Web servers in embedded systems enhance user interaction

RICHARD A QUINNELL, TECHNICAL EDITOR

If an embedded system can mimic a Web page, the system can leverage all the capability of the Internet. The key is using the right Web-server software.

Explosive Internet growth has generated fallout beneficial to embedded-system developers. The technology that makes the World Wide Web so popular can provide embedded systems with a rich but inexpensive user interface and can simplify connections to remote equipment. The trick is to pick the right match for system needs.

The Internet's data-transport protocols allow diverse computer systems to exchange information using a client/server model. In the case of http (hypertext-transport protocol) on the Web, this exchange allows the client to create a rich visual experience for the user with minimal information from the server. The combination provides an opportunity for embedded-system developers to open a window into their devices without extensive development effort.

In effect, Internet technology provides a poor man's graphical user interface (GUI) for embedded systems. A major challenge of providing user-interface software--generating screen images and accommodating a range of user hardware--becomes trivial. The embedded system need provide only Web-compatible http-server software and html (hypertext-markup-language) page information. All the hard work is done by an off-the-shelf Web browser running on the user terminal.

The applications that can use Internet technology are legion. Virtually any embedded system that needs an interface port for user monitoring and control can apply Internet technology to that need. An embedded Web server can source system-status information and accept configuration data, software updates, and control commands. It doesn't matter if users connect directly to the system or through a LAN (intranet) or the public Internet. The same browser and embedded software work regardless of the physical connection.

Remote monitoring and control are not new features. For years, developers have included serial diagnostic ports in systems with interfaces to PCs, terminals, or networks. Some developers have included telephone connections for dial-up access. These interfaces have always been custom-designed, however, and dedicated to specific user equipment. In many cases, developers created abbreviated user interfaces with cryptic coded commands to attain compact code for the interface's embedded side.

Internet-technology use performs the same function as do these custom interfaces but with extensive formatting options at a reduced development cost. Interface development becomes the simpler task of designing html pages and application software to respond to browser queries. As a bonus, the interface becomes one that is familiar to a growing number of users.

By leveraging the power and robustness of off-the-shelf Web browsers, an embedded Web server can give your system tremendous flexibility. The user interface now stays with the system, rather than being a separate software package for installation in the user's host equipment. Any user system with a Web browser can interact with your system with no additional development effort on your part. Customized user interfaces become relatively simple. The html page definitions contain all of the differences in appearance, language, and graphics, such as company logos. The system software remains the same.

Internet-technology use also allows the embedded system to offer substantial online capabilities without using system resources. By having html pages point to other network locations, the system can offer users more online documentation and richer graphics than the system hardware could otherwise support. Netscape Communications (Mountain View, CA) uses this technique in its PC-hosted Web browser, for example. Netscape Navigator 3.0 includes help files that point to locations on Netscape's home page. This technique gives the user more information than would fit in a reasonable program size. In addition, this technique lets Netscape correct or modify the company's documentation without distributing errata to all Netscape customers.

The same technique can increase the apparent processing power of the embedded system as seen through the browser. The user interface could offer statistical analysis of system data by pointing the browser to a more powerful partner on the network and by supplying the raw data. The partner performs the calculations and returns the results to the browser. As far as the user is concerned, however, the information appears to come from the embedded system.

Internet is not for everyone

For all of its advantages, though, Internet technology may still be an unsuitable choice for an embedded system's user interface. If your system's needs are simple, you may not want the overhead of Internet protocols (IPs) and embedded servers. The interface's speed may also be an issue. The Internet's TCP/IP (Transmission Control Protocol/Internet Protocol) includes overhead for handling network errors, such as retransmission of lost packets. This overhead reduces the data rate achievable through a given link and may compromise the interface's speed. The overhead also makes a TCP/IP link nondeterministic, so that the link may be unsuitable for time-critical control applications.

Another drawback to the Internet as a user interface is that the technology is relatively static. An html page is typically predefined, although a server can alter some text sections on the fly when displaying tabular data. Using Java applets in the page definition can bypass this limitation, however, and animate the interface. Note that, for the server, these applets are just another file to transfer. The Java virtual machine is in the browser.

If the embedded system is part of a network that unauthorized users can access, the system's security could be an issue. It is easier to protect data from eavesdroppers if your system uses proprietary data formats and protocols than if you use standard Internet methods. Similarly, you may need more protection from commands issued by unauthorized users than standard IPs allow. You can get some security by using password-protected access or by restricting the system's response to unknown-user IP addresses, but you may need the additional protection of a proprietary design.

Access to the public Internet leaves your system open to another form of intrusion: robots. Some Internet users create software that automatically scans Web sites and catalogs the sites' contents. These programs, called robots, can wreak havoc on a Web server if the Web page has recursive pointers and the robot takes a "depth-first" approach to scanning. You may need additional software to keep robots off your server or to limit their impact.

For many embedded systems, however, these disadvantages pale in comparison with the cost savings and extended capability that Internet technology can bring to embedded-system design. The next question, then, is what system resources need to be in place to embed the Internet. The system's hardware and software must be appropriate.

Embedded-Internet hardware needs are surprisingly modest. The system needs either a network or an RS-232C interface, a processor with performance equivalent to an 80386 or better, and sufficient program memory to house the server and protocol code and the html pages. The html pages can range from simple text files to large graphics files, depending on the page design. The server and protocol-code software size depends on implementation.

An embedded system needs several software elements to provide Internet capability. Figure 1 shows software blocks of an embedded-Internet system, arranged in layers. Not all blocks are necessary, however, depending on your application. A minimal set includes the operating system and application software, the http server, the TCP/IP stack, and drivers for communications hardware, such as Ethernet. If your system uses an RS-232C or a modem link, the system also needs the point-to-point protocol (PPP) or serial-line Internet protocol (SLIP).

Communications drivers and the TCP/IP stack have for years been part of most commercial OSs as standard communications protocols. Many OSs also have PPPs and SLIPs as standard modules. What has been missing is http servers that standard Web browsers can use to communicate with the embedded system.

The http server interprets the browser's queries and commands, activates application programs, and returns data files to the browser. In most cases, the embedded system predefines and stores these files. The system can also use software that generates html pages on demand, allowing the embedded system to display information that changes with time.

The application program interacts with the Web server by responding to requests and supplying data for the html pages. By accessing a Web page, for example, a user could examine the contents of memory or registers in the system's processor. Users can also modify the contents of memory or registers by filling out tables on a Web page and submitting them to the server by clicking on a button icon.

A browser, the server, application software, and communications protocols provide a full-fledged GUI to an embedded system. The cost to provide the interface in the areas of development time and system resources is relatively small. Many of the software elements are already part of OSs. Table 1 summarizes the offerings available and the approximate code size needed.

Servers vary

Table 1 shows code sizes for the various Web-server implementations. This range does not necessarily reflect differences in code efficiency, however. Web servers can have a range of capabilities and still be http-compatible. Designers should carefully evaluate server offerings to determine what capabilities they provide and match them to the system's needs.

One capability for designers to check is the server's tolerance to variations in the browser's command strings. The sequence of parameters in a command, for example, may vary from browser to browser. Handling such variations adds complexity to the server's code and increases the code's size. An overly compact server may sacrifice this ability and thus may operate improperly with some browsers. On the other hand, if only one browser type connects to the server, the added complexity is unnecessary.

Another capability to check is the system's ability to obtain an IP address. Each node in a TCP/IP network needs its own 32-bit IP address. The address cannot be factory-set; it can be assigned only at network installation. This restriction implies a need for a keypad or other data-entry mechanism independent of the TCP/IP network to set the address at installation. Alternatively, if the network offers a DHCP (dynamic host-control protocol) server, the http server can request an IP address at system boot. The ability to make such a request is another performance attribute to check when evaluating server alternatives.

Oversimple Web servers may lack the ability to process multiple, simultaneous browser requests. Processing multiple requests may be important if more than one user is to access the embedded system at the same time or if the system is to report itself busy to potential users. When the server can handle only one browser request at a time, secondary users receive no response until the server becomes free. This lack of response could be unacceptable to users.

Even if only one user connects to the server at a time, the browser may still make multiple simultaneous requests. Each graphic element and Java applet in an html page provokes a separate transfer request by the browser. The result can be many requests simultaneously pending.

How the server handles multiple requests is another characteristic to examine. Some systems respond to multiple requests by spawning processes, one for each request. Each process has its own copy of the server. If there are too many simultaneous requests, such an approach can consume all the available system memory and interfere with normal operation. Such servers require developers to make certain that system memory is large enough to handle the anticipated number of multiple requests.

The embedded Web server's performance and the underlying TCP/IP stack are other important considerations, particularly when adding public-domain Internet software to a custom OS. The Internet software should be efficient enough so that the network link is the limiting factor for how quickly data passes between server and browser. Further, the embedded server's presence should not affect the system's primary real-time operation. If the TCP/IP stack has too high a priority, for example, and you cannot alter the priority, the Web server can block normal system operation as the server waits for response from the network. Similarly, a server implementation may block interrupts to protect critical code areas, thereby compromising a system's responsiveness to the system's main duties.

Application code also deserves attention when embedding Internet functions. As any experienced Net surfer knows, it is too easy for developers to create html pages that are burdened with excessive graphics. The presence of too many graphical elements in an embedded system's html pages degrades the system in two ways. First, the graphics consume far more memory than text, so heavy graphics use comes at the cost of more system memory. Second, downloading graphics to the browser can take more time than the user is willing to wait. A good rule for embedded html pages is to design them to take less than 5 sec to download.

Another application behavior to consider is the timing of data capture for presentation to the browser. The system state may change, for example, between browser requests for two pages in a diagnostic application. Because the browser caches the pages, allowing the user to switch between them, the pages appear to represent the same time slice.

Developers seeking to use Web servers and IPs in their embedded systems must therefore carefully evaluate their application needs. Too hasty an implementation can compromise system performance, consume excessive system memory, and result in a sluggish user interface. When implemented carefully, however, Internet technology can provide systems with powerful interfaces free of many of the hassles that custom designs endure.

| EDN Access | Feedback | Table of Contents |