Steven Pemberton, CWI, Amsterdam, The Netherlands
http://www.cwi.nl/~steven
This is a computer:
It has an ARM 9 CPU running at 400MHz, with a BogoMIPS value of 421; it has 32 MB RAM, 7MB flash for firmware, a 16GB disk, and WiFi; it has a web server, and runs under Linux; it costs around €30. It is equivalent approximately to a turn-of-the-century desktop computer, except, much, much cheaper.
We shouldn't be surprised by developments like this. Moore's Law has been steadily providing us with faster, smaller and cheaper computers for more than 50 years. It was only a matter of time before computers became so small and so cheap. And despite the many reports of Moore's Law coming to an end, it still seems to be producing cheaper, faster and smaller computers. For instance, here is a yet cheaper computer, a barebones Arduino running at 16MHz with 16kB of memory, for less than $3:
Embedding computers in everything is clearly about to happen. However, these are low-powered computers, with little storage space, and there will always be a demand for using such computers, since they reduce the end-price of the objects they are embedded in, and, especially in battery-powered objects, they use much less power.
It was possibly one of the biggest surprises of the introduction of the world wide web when commercial devices (such as routers) started including web-servers for the purpose of configuration. A web server doesn't require excessive amounts of memory and computer power, but there is a certain minimum; and it is better to minimise as far as possible the external requirements of an embedded computer, in order to leave as many resources as possible over for the real task that the embedded computer is intended for. It is better, if possible, not to have to have a web server, but just to deliver and accept data, and keep the analysis and setting of that data off of the embedded device.
One example of such an approach is that used by NACS (The National Association for Convenience and Fuel Retailing). This is an association that represents a large number of petrol stations in the USA. At each location there are many devices, pumps, storage tanks, cash tills, dispensers, that all need to be networked, configured, and controlled. For instance, the pumps have to be programmed with the current price of fuel, and they have to produce details about the current sale, which needs to be delivered to the cash tills, and at the end of the day the pumps need to deliver the amount of fuel sold, and the cash tills the day's takings. The solution that was used was to let the devices accept XML streams containing configuration data, and to produce streams of data.
In order to make this data human-readable and settable in a flexible manner, the solution was to use XForms [1]. XForms is a W3C technology that was originally designed for web-based form processing, but in later incarnations has evolved into a powerful application-definition language.
Its basic approach is to accept instances of XML data (and a few other formats, including JSON), to which restrictions and relationships can be attached, and then bind these data values to controls, either for viewing or setting; data instances can be sent back to the originating device with a single action. Although such interfaces are programmable in other ways, such as with Javascript, experience has shown over a wide range of projects that XForms costs about a tenth of the effort to produce an interface, when compared to traditional programming methods.
XForms is straightforward to implement, is device-independent, and can run on small portable devices.
XForms running natively on an iPhone.
Consider a simple connected household thermometer. Its data consists of the actual temperature, the required temperature at this moment, the time now, the current state (auto, continuous, party, and absent), and a collection of events for each day of the week, consisting of a time and a corresponding required temperature.
In XForms, getting this data is a simple case of writing
<instance resource="http://therm.local/data"/>
Displaying the current temperature is as easy as:
<output ref="temp"/>
and setting the required temperature:
<range ref="required" start="0" end="30"/>
which will create a control set to the current required temperature, that allows the value to be changed within a range of values. (For simplicity, we assume here it only works in Celsius.)
To return the new values to the device, all is needed is:
<submission resource="http://therm.local/data" method="put"/> <submit label="Set"/>
XForms is currently in use around the world, by companies such as the BBC, Yahoo, Xerox, NASA, the Dutch national weather service, and EMC, just to name a few. The current released version is XForms 1.1 [1], but version 2.0 is in preparation [2]. There are native versions, such as implemented by IBM [8], client side implementations that run in browsers, such as XSLTForms [5], and open-source server-side implementations, such as Orbeon [6] and BetterForm [7]. Apart from the specifications themselves, there are tutorials [3] and quick references [4] available as well.
In order to minimise the cost and resource requirements of attached web-of-things devices, the devices themselves should not be required to do much more than the task they are designed for; user-interface tasks in particular should be outsourced to external devices with sufficient spare resources. XForms is a particularly flexible way of doing this, with an added advantage of the speed with which applications can be built, in comparison with traditional methods.
[1] XForms 1.1, http://www.w3.org/TR/xforms11/
[2] XForms 2.0, https://www.w3.org/MarkUp/Forms/wiki/XForms_2.0
[3] XForms for HTML Authors, http://www.w3.org/MarkUp/Forms/2010/xforms11-for-html-authors/
[4] XForms 1.1 Quick Reference, http://www.w3.org/MarkUp/Forms/2010/xforms11-qr.html
[5] XSLTForms, http://www.agencexml.com/xsltforms
[6] Orbeon, http://www.orbeon.com/
[7] BetterForm, http://www.betterform.de/en/index.html
[8] IBM Lotus Forms http://www-03.ibm.com/software/products/en/ibmformfami