Using an embedded Web server
On hearing the term "Web server", it would be quite natural to think of a massive data center, full of powerful servers, which enable pages from hundreds of websites to be delivered to thousands of users at the click of a mouse. However, the exact same technology may be readily employed in an embedded system to provide an interface to the application. This article explains this approach and outlines its key advantages.
Trouble with a Router
I was having some trouble with my Internet connection recently. I will probably never know exactly what was wrong (as broadband is, for all intents and purposes, magic), but investigating the problem was interesting. I am not a networking specialist, so I would expect that messing with the settings inside a router would be hard, but the manufacturers have made it very simple.
I began to wonder why there are not more devices that work in the same way ...
An Embedded HTTP Server
As the router allocates IP addresses to computers and other devices on the network, it seems unsurprising that it allocates one to itself. To take advantage of the resulting functionality, it is only a matter of entering this IP address into the browser on any other device on the network. There is then the opportunity to view and adjust lots of settings and parameters for the broadband connection.
So, how does this work? Essentially, the router contains a Web server. This term makes me think of a big powerful computer, which has access to an enormous database of Web pages that it can serve up to a remote computer on demand. But, it would be more accurate to call it an HTTP server, as, essentially, all it does is respond to this standard protocol in order to deliver data that looks very like a website. The developers of the router software could very easily construct quite a sophisticated user interface using just a few HTML files.
The key benefit to the embedded developer is being able to provide a useful and potentially quite sophisticated UI for their system without any concern about what computer/OS the user might have available. They just need to have something with a network connection and a Web browser.
HTTP Server Functionality
An HTTP server can perform three basic functions:
- Return HTML pages to a Web browser
- Monitor the device within which it is embedded
- Control the device within which it is embedded
Return HTML Pages to a Web Browser
This is the most fundamental capability of an HTTP server. The HTTP server waits on the network for a Web browser to connect. Once connected, the Web browser provides a file name to the HTTP server and the page is downloaded to the Web browser.
In the most basic case, the HTTP server can download simple HTML files (simple because there is no inherent capabilities other than to show information) from within its file system to the Web browser. This feature is ideal for downloading user documentation from the embedded system so it can be used in a Web browser.
A more sophisticated and extremely powerful capability is for the HTTP server to download Java programs or applets (encapsulated in an HTML file) to the Web browser. Once loaded in the Web browser, the Java code executes and can communicate with the target (that contains the Web server) using the TCP/IP protocol. The power of this capability lies in the ability to:
- Support legacy applications (existing TCP/IP applications which now communicate with a Java application that runs in a browser rather than writing proprietary applications for different desktop operating systems)
- Write sophisticated TCP/IP based applications between a host and server where you control both sides regardless of what kind of host is in use or where it is running
Monitor a Device
Often there is a need to retrieve (monitor) information about how an embedded system is functioning. Monitoring can range from determining the current pixel resolution of a digital camera to receiving vital signs from a medical device.
By embedding appropriate commands within an HTML page, dynamic information can be inserted into the HTML stream that is sent to the Web browser. As the Web server retrieves the file from the file system, it scans the text for special comments. These comments indicate functions to be performed on the target. These functions then format dynamic information into HTML text and include the text into the HTML stream being sent to the Web browser.
Control a Device
HTML has the ability to maintain “forms.” If you have ever browsed the Web and tried to download something, you probably have seen a form. A form is a collection of “widgets” such as text entry fields, radio buttons, and single action buttons that can be assembled to collect virtually any type of data.
By constructing an HTML page with a group of widgets, information can be collected from the user in a Web browser. That information can then be transmitted to the target and used to adjust or alter its behavior. For example, an HTML page could be constructed to configure a robot arm to move in certain sequences in order to perform some necessary function (to bend a piece of sheet metal for example). This could be done by placing specific text entry boxes in the HTML page that instruct the user to enter a number of specific data points. After being sent to the Web server, the data points can then be analyzed by the embedded system’s application, validated, and then executed upon (or, if the data is invalid, to have the user re-enter the data) to move the robot arm in the proper directions.
The functionality offered by different vendors’ HTTP servers varies, but some typical features to look for include:
- Authentication (security)
HTTP provides for basic network authentication. When accessing a Web Page, it is common to be presented with a dialog box asking for a Network ID and Password; this is a manifestation of this capability. You should verify that the package provides the ability to add and delete users to the Username/Password database in the HTTP server. In some cases you will be required to add the code to do this.
- Utilities for embedding HTML files
In general, most embedded HTTP servers use a very simple file system that resides in memory. Vendors that provide support for this should also provide support for building that file system on your desktop so that it can be included in ROM or Flash on your target. Furthermore, the vendor should also supply an ability to use a more full-featured file system that is capable of handling the numerous off-line storage capabilities available for embedded systems.
- File compression
If a vendor supports the building of an in-memory file system (files included in ROM or Flash) as just discussed, they should also provide a file compression capability. HTML files can become large. They can therefore consume a lot of space in an in-memory file system. The compression capability should be able to compress the files while building the in-memory file system and uncompress the file when requested by the HTTP server.
Although you might think of a Web server as being large, an HTTP server that is optimized for embedded applications is likely to be quite small in terms of code size. Most embedded operating systems have networking options and an HTTP server is commonly available.
Although I know that my router is far from unique in operating in this way, it does seem to me that there is enormous potential for other equipment to be given this capability. For example, my hard disc video recorder could be easily controlled from my iPhone or iPad, without the manufacturer needing to create and maintain an app. The same might go for my heating system (program and adjust from anywhere in the house or elsewhere even) or my digital camera (deal with settings, view pictures etc.) or many other electronic devices.
The possibilities for this kind of UI are really only limited by the designer's imagination.
Colin Walls has over thirty years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, Colin is an embedded software technologist with Mentor Embedded (the Mentor Graphics Embedded Software Division), and is based in the UK. His regular blog is located at: http://blogs.mentor.com/colinwalls. He may be reached by email at firstname.lastname@example.org