Web-Based Device Monitoring and Control

Rodney Snell Software Development Manager Intelligent Instrumentation Inc. Tucson, AZ USA rsnell@instrument.com

INTRODUCTION The advent of the Internet and its associated applications and services has given new life to the collection, monitoring, analysis, and control of nearly every kind of information imaginable. The advantages that this client-server technology provides are endless, as evinced by the daily use and growth of this industry. Most companies now have an incredible amount of information online for use by their employees, suppliers, customers, and other interested parties. While much of this information can be provided in near real-time, it is not typical for instruments that collect data to be directly accessible on a network. There are many advantages in doing so, though, and this paper explores the issues involved in placing a computer-controlled device on a Web-based network. The following is a basic outline of the discussion: Terminology - a quick overview of the vocabulary used in this paper and what it means. Web networks - a discussion of the basic principles used when a Web browser accesses a server to monitor and control a device. Devices - a description of the types of devices that can be Web-enabled including short descriptions of the underlying bus mechanics such as Ethernet, serial, etc. Web-enabling techniques - a categorization of the most common techniques for connecting a device to a Web network including advantages and disadvantages of each method. Client applications - a discussion of what is possible from an application level. Browser techniques using HTML, JavaScript, and Java are discussed and stand-alone applications are also described. Application example - description of what is possible when real-time data collection devices are made available on a Web network WebDevice - an overview of a powerful, extensible technology to connect nearly any device to a Web network. Future Developments - a short discussion of what to expect in the coming years, including discussions of device communication based on new standards such as XML and Jenie.

TERMINOLOGY Here is a list of the most common network terms used in this paper and what they mean. Internet Any network based on TCP/IP. This includes subsets of the global Internet such as company Intranets (mainly for use by company employees) and Extranets (mainly for use by company suppliers and customers). Web network An Internet that is mainly accessed via a Web browser (Internet Explorer, Netscape Navigator). Browsers are used on the client end to access a Web server or Web-enabled device and normally communicate via the HTTP protocol. However, there are a myriad of other standard or proprietary protocols that can be used, within a browser or in a custom client application. This paper is mainly concerned with HTTP communication between the client and server and additionally focuses on Ethernet networks, which constitute the majority of such connections. HTTP The HyperText Transport Protocol. This is an application-level protocol for distributed, collaborative, hypermedia information systems and is mainly used for Web browsers to communicate with Web servers. HTTP messages use TCP/IP as an underlying protocol. Ethernet The most common physical network layer for a Web network. In this paper, Ethernet is assumed to be the network being used, even though there may be intermediate networks in use (as is always the case with the global Internet). Ethernet is a shared network bus that allows connected devices to send messages at any time. TCP/IP The Transmission Control Protocol/Internet Protocol. This protocol defines how messages are constructed, sent, and routed between networks. The standard provides for guaranteed delivery of messages because the recipient of a message must acknowledge that the message arrived. UDP The User Datagram Protocol. This protocol is very similar to TCP, but there is no guarantee that a UDP message actually reaches it's intended destination because no acknowledgment of the message is required. Because of this, messages delivered by UDP result in faster communication and take less network bandwidth.

URL Uniform Resource Locator. This is the text that is typed into a browser that tells a Web server what to return back to the client. What the URL actually refers to is totally decided on by the server itself - it can be a static file, a static HTML page, or a dynamically constructed page. HTML The HyperText Markup Language. This is a conceptually simple tag language used by a Web browser to display and allow user interaction within a document. HTML documents are often called Web pages. CGI The Common Gateway Interface. This protocol can be used to add functionality to a Web server for dynamically creating pages. Bus The physical connection mechanism used by a device to communicate with a computer. The most common bus we will discuss is Ethernet, but other busses will be discussed such as serial, (IR, industrial control busses [DeviceNet], wireless, etc.) and internal (PCI, VME). Client-Server For purposes here, the client is always the system that is interacting with an application under a Web browser and the server is the software running on a device or an external system. WEB NETWORKS This paper is mainly concerned with device interaction through a Web browser interface, although custom client applications are also discussed where appropriate. A browser communicates via the HTTP protocol to a Web server by sending a request that indicates the operation that the browser wants to perform, and receiving a response in the form of an HTML page for viewing. The operation to perform is determined by the URL and gives the server full control over what to make of that URL. The most familiar operation is just a file retrieval with the URL specifying the file to be returned. But to incorporate live data into a response, the server must dynamically create the "file" to return to the client. Some of the advantages of implementing a data collection application via the browser interface include: No client software is usually needed because Web browsers are present on every platform. This greatly simplifies the administration of an application.

Browser interaction is simple and users are already comfortable with using it. Few new techniques need be learned for a new application Applications automatically benefit from browser innovations by simply altering the page text that is returned from the server. Internationalization of an application is easier because only the page text needs to be translated. The browser interface is already appropriate for most languages. Administration of applications is easy because no client software need be installed. Only the server-side pages, applets, and scripts need be administered - once updated all clients automatically receive the latest application. Applications can be fully integrated with online help including drawings, schematics, audio, and video without any additional software.

The client-server nature of a Web network makes it possible for many clients to simultaneously access devices and view real-time data no matter where the user is located (as long as there is access to the network). This is different than the traditional single-user approach and allows new and powerful control over any number of instruments. DEVICES Any device with which a computer can communicate can be placed on a Web network. These include traditional data acquisition devices sampling analog and digital data, programmable logic controllers, sensors, scales, cameras, oscilloscopes, etc. However, the techniques used to Web-enable a device are based on many concerns, including the device bus and resources. Some of the techniques described in this paper require that a device be networkable - it must have the intelligence (processor, OS, TCP) to connect directly to a Web network. As hardware becomes more inexpensive, the industry will see an increasing number of these devices. The majority of existing instruments, though, do not have this capability and use busses that need translation to participate on a Web network. This includes serial, IR, USB, PCI, and VME instruments. Some of these (primarily serial) have forced a market for conversion devices that translate network commands into native device commands and vice-versa. However, these conversion devices are usually not directly suitable for Web networks because the network protocol is not HTTP, which is the standard language of a Web network. All of these non-network bus devices require an external Web server that knows how to translate requests and communicate with the device in its native protocol. This is especially true of devices that are dumb by nature and cannot be modified easily to support a network interface. DEVICE WEB-ENABLING METHODS There are four main techniques that can be used to place a device on a Web network. While there is overlap between each of the techniques presented, they each have their own advantages and disadvantages that make them unique. Note though, that it is very possible for a device to be usable by more than one of these methods at a time.

Embedded Web Server For an intelligent Ethernet-based device, it is possible to place a Web server directly on the device and allow a browser to communicate one-to-one with that device. This has the primary advantage of simplicity - just hook up the device and point your browser to it. There is typically no need for additional hardware or software with this method. This technique is especially useful for stand-alone instruments because of its plug-and-play nature. However, there are several disadvantages with this approach. One of the most crippling is that the Web server and application is limited directly by the device resources. Since most embedded devices by nature contain small amounts of memory and storage, it may be difficult to allow the level of presentation and interaction that you desire. There will typically be limits on the amount of graphics or applets that you have available on such a device simply because of resource limitations. One other major disadvantage is that this scenario does not allow a Web browser to communicate with any other node on the network at the same time. If you are retrieving a page from a device using this method, you cannot assimilate data from any other device. Instead, you must have the browser connect to that device as a separate operation - this is the nature of a Web browser. This can be alleviated by using a non-browser client application to collect data from more than one device at a time and integrate that on the client end, but this scheme requires installation of client software. The larger problem with this method is that there is no centralization of data collection. It is mainly a point-to-point technique and so makes it difficult to integrate devices into a more intelligent network. Finally, there is the problem of device modification. To use this technique, your device must be intelligent - that is, have a processor and operating system and network (TCP) interface. This makes this method less than suitable for existing dumb devices and devices in which selling price is a major concern. Embedded Web Server + External Web Server With this method, you can avoid some of the disadvantages of an embedded-only server approach. The external Web server in this case would be a custom server that understands how to pass on requests to the appropriate devices. The main advantage here is that while there is a one-to-one correspondence between the browser and the external Web server, the external server can communicate with several networked devices and perform some processing on this data before returning the result back to the browser. Thus, this method allows centralized control over a network of embedded devices. The other advantage gained is that the external server can usually be a powerful PC with plenty of memory and storage for graphics, applets, etc. However, this power comes at a cost in that external hardware and software are now needed on the network. Usually this wont be a major concern but there are instances where this could be unacceptable because of power, cost, or space limitations.

External Web Server + CGI This and the following method avoid the biggest problem of the previous two methods: the requirement that the device be intelligent and have enough resources for an embedded server. Here, the browser is communicating only with the external Web server, but instead of the server passing requests to a device as above, the requests are translated by the CGI layer into device-specific communication that does NOT have to be an HTTP network request. That is, the device communication is now separated from the browserserver communication so that the device can be on a different bus (serial, IR, etc.) but appear to the browser as if it is on the Web network. This technique also gives us the advantage of centralized control because the CGI methods can assimilate data collected from more than one device, if necessary. Note also that with this method, the external server could simply be an off-the-shelf package since the only requirement is that there be CGI support. This gives the developer the advantage of an industrial-strength, well-tested server. This technique has some of the disadvantages as the previous one since an external hardware/software package now has to be included on the network, but its main disadvantage comes from the CGI interface itself. CGI is not well-suited for real-time collection of data, and would have to be augmented greatly to simply add the pieces needed for device communication. A newer technology from Sun called Servlets may alleviate this concern. Servlets are pieces of Java code that the server invokes to perform some function and return data back to the client. Servlets are faster than CGI to invoke, but will typically have to be extended with non-Java code to perform the actual device communication. Custom External Web Server The final method for placing devices on a Web network can be the most powerful of all methods. This method is similar to the previous in that the server takes browser requests and translates them into appropriate device transactions. Instead of CGI however, a custom server can use whatever means it wants to perform the translation and offer centralization services. This allows ultimate flexibility and speed for data that often needs to be addressed in this manner. The WebDevice Server discussed later is based on this method and gives the developer and user the capability for data collection in real-time with full data processing functionality. This technique has the same disadvantages as other external servers in that it requires extra hardware and software on a PC on the network but unlike the other external methods, it has the potential to be used directly on an embedded device to achieve the advantages of the first two methods. EXAMPLE APPLICATION A concrete example using the various techniques described above follows: An online weather station has two data acquisition devices connected to an external Web server. In this scenario, one device has a direct network (Ethernet) interface with an embedded Web server and is responsible for collecting temperature and humidity data. The other device has a serial interface and is responsible for measuring wind speed. A diagram of this is shown below:

Temperature

Humidity

Device 1 Ethernet Client Web Browser Embedded Web Server

Serial External Web Server Device 2

Wind Speed

The external Web server takes requests from clients (typically through a browser), collects data from both devices, and formats a page to return to the client. Depending on the application, the client may see real-time charts of acquired weather data and be able to reset or calibrate the devices. This system uses a method that requires an external server for interaction with the serial device, but does not necessarily need the external server for the first device. As shown, a client browser can communicate directly with the first device if desired, but cannot acquire data from the second device without going through the external server. This system demonstrates the use of both an external server and an embedded device server. The advantage of communicating through the external server is that data can be collected from both devices and combined into a single response. This uses the concepts described in the last three methods above. If the wind speed data was not needed, the system can be simplified by removing the external server. The client can then communicate directly with the embedded server on the device which is the first method discussed above. WEB NETWORK CONSIDERATIONS Regardless of the method used to place a device on a Web network, there are considerations of speed, security, and determinism that should be addressed to understand where potential bottlenecks lie. Speed The connection between the client (browser) and the Web server is always based on the capabilities of the network. Ethernet networks are almost always used for this connection and are currently rated at either 10 or 100 Megabits per second (MBps). Given a dedicated line, this bandwidth is sufficient for almost all data collection applications. However, because Ethernet is a shared access network, the achievable rate for a given application will depend on the number of devices communicating on that network. The best way to ensure consistent speed on an Ethernet network is to separate critical network segments using switches or routers. For instance, on a 100 MBit network, a segment of many devices on the network can be separated by using a switch to

give multiple devices their own 10 Mbit line. This will reduce unnecessary traffic from other systems on the network and enhance the speed at which these devices are communicated with. Note though, for internal or controlled networks, data transfer speed is often not the bottleneck. Instead, the limitations often lie with the devices themselves because of hardware limitations. On the global Internet, applications are at the mercy of the myriad of gateways, routers, and switches that lie between the client and the server and so consistent speed can rarely be guaranteed. When a Web server needs to stream data back to a client in real-time (as opposed to returning a formatted page containing the most recent data), the data transfer speed is also dependent on the methods used to send that data. This is discussed more fully below. Security Access to a given device can be controlled in many ways. One standard method is to have the Web server control access via the standard HTTP challenge mechanism. This means that the server can ask the browser to provide simple credentials when specific URLs are requested. Because this technique involves clear text transmission (albeit encoded), it is not usually used in high security environments. However, it is very effective in a controlled network and should not be overlooked. Every device on a Web network has a unique address (IP and Ethernet) so that they can receive messages destined for them and ignore all other network traffic. Web servers (usually custom) can be programmed to only allow certain clients access by filtering the IP or Ethernet address of an incoming request. However, it is more common to use a hardware based solution (router) to provide this filtering because of the simplicity, speed, and flexibility of such a solution. Browsers can also implement encryption techniques such as the Secure Sockets Layer (SSL), which are highly effective in controlling access to a given URL or device. Protocols like SSL allow a browser to securely connect to a Web server, encrypt all data sent to that server, and decrypt all data received from the server. The encryption method makes it nearly impossible for an unauthorized user to make any meaning of the data. These techniques can be used for all data transmission (not just initial access) between the client and server for extreme data security. However, when encryption is used like this, the complexity of the server is increased and data transfer speeds are decreased. Determinism Many data collection industries are concerned about being able to guarantee data delivery at specific, definite times. This is especially true in markets which use industrial control busses (PLC's, DeviceNet, etc.) On an Ethernet network, however, it is not possible to determine when a particular device will actually get to send or receive a message since all systems on the network can send messages at any time and a device may have to wait for the network to clear before its message gets sent. Since most Web networks rely on Ethernet at some point between the device and the client, the concern is

that the shared non-deterministic nature of the network is not sufficient for real-time applications. In truth, though, this is not a valid concern for the majority of applications because of the high bandwidth of Ethernet (10/100 Mbit/s) and the readily available solutions described above (switches, routers) for ensuring consistent speed on the network. While there will always be applications that can not sacrifice determinism, a properly configured Web network usually provides sufficient performance. CLIENT APPLICATIONS Once a device is accessible on a Web network, the focus turns to creating the application with which the end-user will interact. The applications we are most concerned with are browser applications because of the advantages described above. However, there are times when a custom application is desired for increased flexibility and functionality. Browser Applications All browser applications start with HTML pages. Many pages can be static in nature to provide information about the application and devices, and to guide the user with online help. To be truly useful with data collection devices, though, pages will have to be able to be constructed dynamically so that live data can be placed along static HTML in the same page. There are many ways to dynamically construct a page. With an embedded Web server, the server might simply be programmed to call internal low-level code to get current readings from a device and return a formatted Web page with these results. This functionality is usually hard-coded and can not easily be changed without altering the device software. Also, because of storage limitations, it may be difficult with an embedded Web server to provide applets that can display the data in real-time. HTML does provide a tag to instruct a browser to automatically refresh a page at some interval. This may be sufficient for simple data collection needs, but is not a solution for real-time updates in most situations. With an external server, the techniques available for creating a dynamic page increase in number. The developer or user might have access to a complete scripting engine with which to modify the way a page gets created (Visual Basic, Cold Fusion, etc.). Additionally, an external server usually has access to a number of other resources such as databases, so that device data can be stored for other enterprise application use or integrated with archived data. When a script engine or other similar environment is available, there are endless possibilities to manipulate device data before returning results back to a client. Since an external server has fewer resource constraints than an embedded device server, Java and other programming options are more likely to be available. There are many cases where the user needs to adjust operating parameters of a device or otherwise provide input that is necessary for the application. HTML pages can provide forms for user input so that a user can enter information that will be used by the server or device. Additionally, it is usually possible for the user to upload a complete file to the server so that a device can receive an upgrade to its operating parameters. This is

especially useful when the information needed by a device (or the server) is in a binary format or is too large for the user to type in manually in a form. One other useful feature that most browsers provide is client side scripting via JavaScript. Script commands are embedded directly in a page and can be used to validate form input, control hypertext linking, and animate page elements. The advantage of using this type of scripting is that the server need not be contacted for such interaction which saves network bandwidth and allows the server to concentrate on more important functionality. Real-time data viewing The major weakness of a browser-based application is that there is usually no standard way to stream real-time data from the server or device back to the client. For common types of real-time data such as audio or video, a browser can allow viewing of the data inherently. However, for most data collection applications, users want to see data displayed in a chart or panel and easily manipulate how the data is viewed. This is where applets come in. Applets (ActiveX, Java) are automatically downloaded by a browser as a separate application that gets used within an HTML page. Once the applet is loaded, it has control over where it gets its data and how to display or manipulate that data. Presently, for real-time viewing of device data, applets are fully necessary. ActiveX and Java applets differ significantly in how they are constructed, but the user may not even know or care which type of applet they are using. The most important difference between the two for data collection on a Web network is that ActiveX controls are Windows-based and can not be used with non-Windows browsers (UNIX, Mac). Java applets on the other hand are, by nature, cross-platform and will act the same within any browser. The decision of which type of applet to construct and use is usually based on this factor. Another way that a browser can exhibit applet behavior is through the use of a plug-in. This is a piece of software that is built to interact directly with the browser and then take control from there. The main disadvantage of a plug-in is that the software must be loaded and installed on the client computer, a situation which is not typically desired because of administration complications. Plug-ins are also typically written for a specific browser (ie. Netscape), and may not function with other browsers. Real-time data updating A Web network's client-server approach brings new possibilities for device data viewing that are not usually dealt with in existing applications. A single device/server may have many clients that want to interact with the device at the same time. This presents special problems related to speed and viewing consistency. Although applets can use the Web standard HTTP protocol (based on TCP) for receiving new data, they are not restricted to do so (whereas a browser is). For instance, if a server needs to send the same data set to ten client applets, it may send ten separate HTTP messages to each applet, each with the same data. However, depending on the circumstances, this may not be suitable for an application because this may take a long time and prevent all clients from viewing

the same real-time data. In these cases, it may be possible to use UDP as the data transfer method. The server would send a UDP message to each applet and gain the advantage of speed (UDP is faster than HTTP/TCP) and less bandwidth usage. The main disadvantage with using UDP is that it is not guaranteed that a message really arrives at a client, so that the first client may be viewing data that is different than the data that the tenth client is viewing. Normally, though, this concern can be alleviated by ensuring that the Web network is clear of most extraneous traffic and is mainly dedicated to the application at hand. If ultimate speed is desired, a UDP message can be sent in multicast mode which means that only one message is sent on the network and that each client receives that same message. Using this method you ensure that all clients view the same data simultaneously. A very important caveat for the UDP transfer method is that the many routers (including most on the global Internet) do not allow UDP messages to be passed through. Therefore this technique is currently useful only on a controlled Web network. Non-browser applications For some functionality it may not make sense for a browser to be involved, even though providing a custom client application complicates the administration and usage of an application. This is especially true with "alarm" type conditions, where the server or device needs to notify a user of an event and possibly allow that user to perform some action based on it. While it is straightforward to design an applet to handle this kind of thing, that applet would have to be present on every page of an application so that a user will not miss the alarm. This has it's own problems since normally static pages like online help would always have to include this applet and the browser must be active with that application at all times. Additional reasons for wanting a non-browser application may be for speed since the application is already resident and for more invasive client procedures where client resources such as files may need to be manipulated. WEBDEVICE It is worth giving an overview of the method of Web-enabling a device provided by Intelligent Instrumentation. The technology (code-named WebDevice) uses the fourth method described above - it is a fully custom Web server designed from the ground up to give the most power and flexibility with nearly any device. The key to the WebDevice server is it's full featured script engine. Scripts are used to collect data from a device, manipulate it, archive it, and send it to clients in numerous ways. The script engine is designed to efficiently handle nearly any kind of device data (unlike other scripting environments) and is very easy to use. This gives the ultimate flexibility to develop any application quickly. In addition, it is possible for the end-user to easily modify and extend an application for specific needs. The other main advantage of the WebDevice server is that has been designed to operate on an embedded level as well as an external level so that all advantages of each method can be achieved depending on the situation. Most servers (especially industrial Web servers), cannot achieve this flexibility. The main features of the WebDevice concept are:

Designed for both embedded and external use. The server executable is small and generally does not depend on features that are operating system specific. Has a built-in powerful, easy-to-use script engine. Scripts are used with Web pages and applets to develop an application. Scripts can be created by developers or endusers. Has built-in support for efficiently updating any number of client applets with real-time data. No development is necessary for most common update needs (interval, data change, etc.). Is highly extensible to add support for communicating with nearly any instrument. Contains most traditional server components including form processing, security, and file uploading.

FUTURE OUTLOOK There are a number of companies currently focused on placing devices on a Web network. Many of the technologies are based on existing packages that have been "Webified". This is especially true in the Human-Machine Interface (HMI) arena where long-standing interfaces are being made available as-is through a browser interface. We can expect to see many more developments in this area, especially as new standards are accepted. One of the standards being worked on for device communication is the extensible mark-up language, XML. XML is a tag-based language similar to HTML but with the vocabulary defined on an application-specific level. There is currently much interest in producing an XML syntax for data collection devices so that all such devices can be interrogated for functionality and exchange data in a standard way. The nice thing about this technique is that a server can act as surrogate to a "dumb" device so that it need not have a network bus to participate in the network. Another more ambitious effort being proposed by Sun is called Jenie. This standard allows devices to be instantly recognized on a network and let their functionality be known for remote method invocation. This requires that all devices be network-aware, however, and this is not currently practical for numerous existing devices. SUMMARY Because of the many advantages afforded by Web technology, placing devices on a Web network gives any number of clients simultaneous real-time access to data. Devices can be monitored and controlled with ease from any location desired. In the years to come, Web-enabled device networks will become commonplace and give new power and flexibility to any device-based application.