Get on the Internet of Things fast with an embedded Web app server: Part 1
So you want to build a tank—a beast of a device which makes the ground tremble before it even moves (Figure 1). Your job: to control and position the turret with precision and accuracy, but the environment you are in is anything but welcoming to the necessary electronics. Extreme vibration, high temperatures, dust, incoming explosives, yet a myriad of functions need to control the tank with delicate accuracy. Traditionally, these dynamics imply headaches. Robust engineering. Extensive wiring looms. IP65 enclosures. Big bucks.
However, if you need to solve this problem with less cost, then set tradition aside and consider designing your tank with a Web application. What if you could replace the main display with a simple ruggedized PC and have the hydraulics controllers for the tracks, turret, cameras, and other devices communicate over LAN? This kind of approach cuts costs and translates into many other application areas.
For instance, suppose you are making one of those satellite dishes that you can maneuver to optimize the number of stations received. Do your clients want a primitive controller for that? Not really. They’re used to the sophistication of a smart phone. They want feedback, graphics, ease of use. And they want to pay as little as possible for it.
So do you ditch the primitive controller and use a smartphone app? That’s possible, but not all of your clients want that. An embedded web application can deliver the classy user interface functions, whether on smartphone or on a dedicated device. And the controller device on the dish itself can put its demands into practice.
The list of potential web applications is endless. They can control level monitors, production plant control, lighting controllers, heating controllers, nightclub lasers…
Webbing traditional design
Embedded systems have traditionally been isolated, self-contained systems. At most, they communicated with other systems within a limited range on a local network. But, this is no longer the case. Embedded systems—especially small, very deeply-embedded devices—increasingly use TCP/IP and perhaps (but not necessarily) the Internet to communicate with each other and with the people managing them.
Although desktop-based web applications typically provide information or entertainment, embedded web applications typically cause something to happen—often on a device. For example, the embedded web application can change the direction of a dish, start a hydraulic motor on the tank, open or close a valve on a production line, or make nightclub lasers dance to the music. Virtual buttons in a browser-based form replace (or duplicate) the hard buttons normally built into the system.
Using the Internet to control an embedded system directly impacts both the cost of building and maintaining the system and its reliability. Physical controls like buttons involve additional components and cost as well as a design that must accommodate access to those controls.
Even more importantly, embedded systems, like those in the tank, are increasingly deployed in remote locations. There, the cost of components, while significant, pales in comparison to the cost of delivery to remote places for breakdowns or maintenance. When you’re facing these odds, web-based applications offer more versatility and less component cost, and can take advantage of LAN or Internet infrastructure.
Communicating across the Internet
So, how does this idyllic web application move a hydraulic ram on a tank? Suppose it needs to extend in response to a button press on the ruggedized PC’s application. What happens to connect the hydraulic ram to the PC?
Figure 2: Ultimately, the communications between the ruggedized PC and the hydraulic ram’s controller device consists of HTTP messages passed over the LAN – just as they are passed via the Internet when you access your online bank account.
This application works essentially the same way as accessing a bank account over the Internet via a home PC. Initially the software on the client device (the home PC) initiates a request by establishing a Transmission Control Protocol (TCP) connection to a particular port (that is, a process-specific access point) on the server holding the bank account information. Once that connection is established, the client sends an HTTP message to the server requesting the information. Finally, the server returns either an error message or the requested information which is then displayed on the PC screen.
As illustrated in Figure 2, in the case of a bank’s website the raw information changing hands is hidden behind the slick user interface. But underneath lies the same HTTP message mechanism as the one used by the hydraulic ram controller. Only the result is different. Our controller receives the instruction, moves the ram, and reports back on its success. The other accesses bank account details.
A typical web server has one role: to implement the HTTP protocol. This protocol activates a browser to issue a request that a server can respond to. Today’s web is highly sophisticated, featuring elaborate graphics and streaming media, yet surprisingly, the HTTP is a very simple protocol. All it does is transport requests and responses.
Because HTTP is a stateless protocol, there is no intelligence in the operation: no decision-making, no context, no scripts, and no code to execute. There is also no dynamic page creation to make user interfaces slick and easy to use. If a page is needs to be dynamic, some other program has to do that work and put the result where the web server expects it to be.
HTTP understands only nine operations (typically called ‘methods’ or ‘verbs’), of which the most important are GET and POST. GET is used to download a ‘resource’, typically a file, located at a specified location (the ‘uniform resource locator’ or URL). The response to a GET request contains the resource accompanied by HTTP header information.
This technology, then, is simple to understand, long established, and in itself presents no difficulties. The problems start to surface when we consider the size of the device on which the software resides. A bank’s mainframe is a world away from microcontroller embedded in the device driving the hydraulic ram, and the two present very different challenges.