Embedded Web app server development (Part 1)
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.
Figure 1: Embedded web applications take the Internet to places previously unheard of – even a tank.
For instance, suppose you are making one of those satellite dishes that you can manoeuvre to optimise 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.