A new approach to wireless sensors: The Instrumentation Cloud
28 March 2010
The convergence RFID with web-based applications means it’s no longer necessary to associate sensor data to a particular PC running a particular piece of software. (This article appears in the April 2010 edition of Control Engineering Europe)
Figure 1: In the Instrumentation Cloud, the ‘sensor tag’ sends or receives data and commands to a commercially available wireless access point (AP).
Replacing Ethernet cable with wireless links is nothing new; we’ve been doing it in homes, offices, and public spaces for years. The benefits are well known if you’ve ‘surfed the Internet’ at your favourite coffee shop. Replacing the hardwire links between sensor units and control PCs is also nothing new, but this hasn’t always been an economic alternative.
The convergence of two technologies, however, is bringing about a major shift in how engineers will look upon wireless sensors. First, RFID (radio frequency ID) technology has become mainstream, meaning that prices for wireless radios has dropped significantly along with physical size. Second, the emergence of web-based applications—a good model being Google Docs— means it’s no longer necessary to associate data to a particular PC running a particular piece of software.
In a new concept known as the Instrumentation Cloud, the only physical connection is between the sensor or actuator and the A/D or D/A front end located on a ‘sensor tag,’ which sends or receives data and commands to or from a commercially available wireless access point (AP) or router (Figure 1).
Further, instead of the data being sent to a particular computer, it sends the data to an AP for further routing to an Internet IP address that defines a Server ID. A user-controlled web-based application server, or Web Page Instrument (Figure 2), receives the data for processing.
This advance breaks tradition with previous jumps in instrumentation technology. The first instruments were in a standalone format. Users connected sensors directly to the instrument, which contained the measurement circuitry and displayed the results, initially on analog meters and later with digital displays. Then test engineers wanted instruments to intercommunicate such as for a stimulus and response test. This was initially done with serial links, but in the 1970s the Hewlett Packard Interface Bus, which evolved into today’s IEEE-488 interface, became the method of choice.
The next major breakthrough came with desktop computers, which made it cost effective for engineering departments to run test programs, control instruments as well as collect data . Minicomputers first interfaced to instruments through serial interfaces, but then plug-in IEEE-488 boards were built that allowed minicomputers and later PCs to perform these tasks. Today such interface cards are often not needed thanks to instruments that communicate with PCs directly over USB or the Ethernet, and most recently even over wireless Ethernet schemes.
Then when the prices of PCs, motherboards and embedded PCs dropped significantly, the next logical step was to combine the instrument and the PC into one box. This took three forms: Traditional standalone instruments such as oscilloscopes or logic analysers incorporated full PC functionality; instruments cards moved into the PC itself; with expansion slots disappearing from most commercial PCs, engineers who want to work with instrument cards have generally migrated to chassis schemes where one or two slots would hold a PC motherboard in an industrial card format and the remaining slots would hold function cards.
Figure 2: This sample Web Page Instrument allows you to take readings and set outputs from any web browser.
UNCHAIN BOTH HARDWARE AND SOFTWARE
Now, in the Instrumentation Cloud, the hardware is unchained — measurement front ends are no longer tied to a particular instrumentation network. A WiFi sensor tag connects to any access point or wireless router within range (Figure 3).
Even more significant, the software is unchained — measurement data are no longer tied to a particular data acquisition program on a specific computer. Instead it resides in the Internet. That is, instead of a sensor tag sending its data to a device driver that feeds measurement readings into local software on a PC, it sends the data to an AP for further routing to an Internet IP address that defines a Server ID. A user controlled web-based application server, or Web Page Instrument, receives the data for processing.
A Web Page Instrument running even on portable devices (Figure 4) can provide any number of services: data presentation to an alarming service that responds to dangerous levels by sending a text message or tweet or even a correcting signal to the sensor tag are just a few in a rapidly growing application space.
THE GATES ARE OPENING
Vendors of instrumentation products and systems are beginning to open the floodgates of very specialised web-based application services. In the simulation space, HUBzero.org allows users to perform modelling and simulation with a web browser. In the realm of instrumentation, an interesting precursor of things to come is Pachube.com, (http://www.pachube.com) which bills itself as a ‘realtime data brokerage platform.’ You connect sensors to a PC or even a mobile device such as an iPod, and by running applets available on that website, measurement results can be displayed on Pachube so you can examine them at any time from anything that can access the Internet (Figure 5).
One piece of hardware popular among hobby experimenters for bringing data into Pachube is the Arduino (http://arduino.cc/). With this microcontroller-based board, users can connect sensors, write acquisition and control programs and interface it to an iPhone or other web-enabled devices.
Industrial users, however, are looking for something more serious and better suited to their needs: an OEM product with a high-performance analogue/digital front end, a powerful processor, adequate memory, and all this in a small format that includes a wireless link yet consumes little power. RFID (radio frequency ID) technology makes it possible to meet all these demands.
Figure 3: Except for sensor wiring, there are no physical links in the Instrumentation Cloud. Users perform all of their tasks on Internet-enabled devices.
PUTTING THE PIECES TOGETHER
A specific example of how the hardware and software elements are all coming together in a form suited for industrial and commercial use comes from Cores Electronic’s Tag4M (‘tag for measurement’, Figure 1). Here silicon originally designed to handle RFID tasks is now being customised for the Instrumentation Cloud.
The 6.5 cm x 4.8 cm sensor tag incorporates a 2.4-GHz IEEE-802.11b/g WiFi transceiver, ceramic chip antenna, 32-bit RISC processor, ROM, RAM plus non-volatile memory for firmware and a data buffer. Its measurement front end comes with a 4-channel 14-bit A/D and 4 digital I/O lines. A small lithium battery can power the unit for weeks.
Every time the tag goes through an operating cycle, it wakes up from sleep mode, acquires data that it sends to the Internet, and finally it receives instructions through the AP for operations such as configuration for (other) measurement tasks or data to write to DIO lines. These instructions are executed during the next wakeup period, after which the tag goes back into Sleep mode to conserve battery power. The amount of time between each cycle can vary from microseconds to hours, depending on the application.
The current tag is the first-generation Instrumentation Cloud hardware product where all measurement capabilities are located inside the WiFi radio, a system-on-a-chip derivative of an RFID tag containing ADC and DIO lines. This architecture has limitations related to accuracy and linearity of the conversions done by the data acquisition channels. ADC sample rates in the current firmware release are relatively modest, peaking at 25 S/s and thus they are suited mostly for sensors or transducers that monitor slowly changing physical parameters. A maximum of 28 kS/s sampling rate will soon be implemented by using the on-board 32 KHz real-time clock.
Next because Cloud Instruments work in a succession of wake-up and sleep periods, they are not intended for applications that requires continuous acquisition and processing. If powered from an external DC adaptor, a tag can be used in a continuous wake-up mode. Note also that tag application tasks are deterministic in the local tag firmware space and non-deterministic in the Internet space.
The tag’s digital I/O proves useful in control applications. Using an algorithm that users load into EEPROM, the Tag4M can respond to alarm conditions that must be executed locally without the assistance of a PC. Every wake-up period it executes the code sequence programmed in its firmware. Further, at the end of each wake-up period (following the immediate execution of a complete firmware loop to take readings and issue control signals), the tag asks the wireless access point if there are any incoming commands that it needs to register for execution during the next wake-up period.
As for software, rather than use public services such as Pachube, industrial users want customised, secure Web Page Instruments. At this early stage, users will typically build these themselves using the Tag4M Web Instrument model as well as standard website tools or even programming languages such as LabVIEW that make calls to the Tag4M’s simple opcodes. Soon, however, users can expect to see a range of application builders that automate the process of creating Web Page Instruments.
Figure 4: Even portable devices such as an iPod can be used to read measurements and send control commands using Web Page Instruments.
DOOR OPEN FOR INNOVATION
This merging of the latest hardware and software technologies now allows engineers to find all sorts of innovative applications for sensor technology by building wireless communication engines for data transfer to APs and creating application firmware.
Indeed, access points will play a much larger role, not only for routing sensor data but also for routing application code, filtering information as well as in security, local determinism and many others.
Innovation will also take place in the domain of web page instrument thanks to tools such as web page instrument builders and updaters. Cluster web pages can include widgets for iPhone and other portable WiFi platforms, running wave-type applications that move from page to page to follow the progress of a physical process, chemical reaction or others. We’re very excited to see what imaginative uses will emerge for the Instrumentation Cloud in the near future.
— Marius Ghercioiu, President, Cores Electronic, Austin, Texas USA (www.tag4m.com)
Most Viewed Articles...