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.Application servers
Embedded web applications generally mustbe able to let the web functionality affect the device operation. Inother words, the remote browser has to be able to ‘talk’ to the system. Aweb server has no such capability, so everything beyond the simpleprocessing of HTTP must be written as a part of system development.
Thelow-level code that interacts directly with system hardware istypically written in C and, because these routines are sosystem-specific, they need to be written during development no matterhow the web connectivity is implemented. However, a web server has noway of accessing these routines, so some way of connecting the two mustbe built.
The two high-level elements created are:
- A way for the web browser to invoke another program
- A program that can take an HTTP request and, from the request contents, invoke the appropriate C code in the embedded application (Figure 3 ).
Figure3: An environment is needed that allows the web server to hand off to ahigh-level script, which accesses low-level C routines.
Thesetwo functions are conceptually simple, but the details of what amountsto a translation from a web conversation into device action are tediousand error-prone. Developers frequently underestimate by a wide marginthe amount of time required to produce this code. For this reason, usingonly a web server results in months of additional coding working onnitty-gritty details that an application server framework already has inplace.
Application servers build onto web servers a much broaderrange of configurable functionality. At the very least, they provide away for the web server to hand off tasks to a variety of applicationscripts and executables that can handle requests for things other thansimple resources. This means that an application server providesreal-time decision making and business logic, invoking other scripts orprograms and, if appropriate, dynamically creates response pages in realtime.
Most important for developers, however, is the fact thatapplication servers tend to come with complete frameworks for use indeveloping code for the system. For example, if only a web server isused, then one must write custom code to recognize and parse requestsand generate responses for functions handled outside the web server. Bycontrast, the framework accompanying an application server typically hasa library that includes request and response objects. The low-levelgeneric work is already done, and the code can focus on adapting therequests and responses to your specific technology, whether to move thehydraulics, position the satellite dish, or sequence the lasers.
Each application server may provide a different set of resources for its targeted programming environments and languages.
Figure4. The Barracuda Application Server includes a development frameworkand libraries for easily managing scripts (such as Lua scripts), C/C++code, and system resources.
Figure 4 illustrates the elements provided as a part of such an applicationserver. The application server can handle C/C++ code in addition toscripts. It includes support for plug-ins, secure transactions, varioustypes of I/O, file storage, and even database functionality. The APIthat remains consistent between different operating systems guaranteesease of portability.
Selecting a development language
Withan application server to ease the coding burden of translating a webconversation into device action and with C source code accessing thehardware interfaces, it initially appears best to stick with thefamiliar. If there is some C anyway, why not stick with it throughout?Why go to the trouble and expense of learning a new language?
To figure that out, let’s look at what needs to be done. Development work can be broken down into the following categories:
- Managing data
- Parsing requests
- Assembling responses
Allof this needs string manipulation. String manipulation in C isn’trocket science, but it’s tedious and extremely easy to get wrong.Everything must be strictly typed, and memory must be explicitlyreserved and released as needed, requiring scrupulous attention to everydetail and making maintenance difficult. Assembling a C server pagerequires string concatenation on a grand scale.
On the other hand, with Web scripting environments such as Lua ,much of this work has already been done. The application serverabstracts the web server details, giving access to request and responseobjects and their associated APIs. This means that the applicationspecific code has to deal only with high-level behavior and data.
Asingle line of script can implement the entire string concatenation.The lower-level machinations are automatically handled. Scripts alsoaccess and manipulate data without the need to worry about dataorganization or type definition.
Another important distinction isthat scripting languages use just-in-time compilation while the systemis operating. Whenever the user navigates or refreshes the browser, thevirtual machine compiles any changed script before it sends therequested page to the browser, thereby automating the host ofcompilation, linking, and other developer overheads associated with anequivalent C-based application. Figure 5 illustrates the developmentprocess.
Figure5: Scripting languages ensure that the scripts are compiledjust-in-time when requested by the browser. The diagram relates to theLua language (Lua Server Page).
So the bottomline becomes clear. Web applications can be developed in as little as1/30th of the time if, instead of using custom written C, scripts andpre-built infrastructure are used wherever possible.
Scripts don’ttotally eliminate C from the equation. C is retained for what it doesbest (Figure 6). Scripting environments intentionally restrict scriptsfrom getting down to the hardware level, so C routines (similar todrivers) connect the hardware to the web application.
Figure6: Lua to C/C++ access is called a Lua binding and can be createdmanually or by using an automatic Lua Binding Generator.
Maintaining sharp user response
Itwould be easy to suppose that the overhead of compilation ‘on the fly’would impact the user experience, but that is far from the case. Infact, the impact on response time is negligible compared with theoverhead of the network connection. Lua web applications typicallyrespond with lightning speed, even when run in small, web-based embeddeddevices.
That experience can be further enhanced by writing userinterface applications that can send data to, and retrieve data from, aserver asynchronously, in the background, without interfering with thedisplay and behavior of the existing page.
Embedded is not the same
Thedifference in the embedded environment and the restraints it imposesmake a massive difference to the optimal deployment of HTTPcommunication technology.
In the end, what really matters isthat end users experience the system in a way that matches what theyexpect. By using web or application servers designed to work on smallembedded systems along with an appropriate scripting language, you canfocus on your key application development, giving your users theinterface they want while letting you dedicate most of your energy todoing the things that you do best.
In Part 2 we willdescribe how to use the Lua Web scripting language to integrate InternetProtocol connectivity into your C-language application code.
Wilfred Nilsen ,Founder & CTO of Real Time Logic,( http://realtimelogic.com/) has25 years' experience in designing embedded software. Powered by a visionof a connected embedded systems, he designed the Barracuda ApplicationServer, tailoring it for the small footprint, real-time needs ofembedded microcontrollers and microprocessors.