The Instrumentation Cloud Brings Web-Centric Operation to SensorsMay 1, 2010 By: Marius Ghercioiu, Cores Electronic LLC Sensors
Combining RFID, analog signal conditioning, and sensors enables you to shift data analysis, monitoring, and control into the cloud.
The world is becoming increasingly Web-centric. We use the Internet for email, news, and entertainment and for social networking. While many people are familiar with Web-based office applications such as Google Docs, there are countless others for almost every imaginable task. These applications are no longer tied to a specific piece of hardware—they are being run on all types of portable devices from netbooks to smartphones.
It's no surprise, then, that the instrumentation world is following this shift in usage patterns. The latest RFID technologies allow manufacturers to create low-cost sensor tags that can send and receive data via a standard WiFi access point (AP) or wireless router. Such tags can run for months on a battery and can communicate directly with a Web Page Instrument, allowing users to monitor and control a process from any device that can access a Web page. This overall concept is called the Instrumentation Cloud.
The Next Logical Step in Instruments
Here, a little history can help you understand the significance of this development. The first measurement instruments were stand-alone devices; users connected sensors directly to the instrument, which contained the measurement circuitry and displayed the results. In many cases, test engineers wanted the instruments to communicate with each other, for instance in a stimulus/response experiment, where a signal generator instructs a digitizer when to start taking samples. Initially this was accomplished by using serial links, but in the 1970s the Hewlett-Packard Interface Bus (HPIB), which evolved into today's IEEE-488 interface, became extremely popular for connecting instruments.
The next major breakthrough came with the widespread availability of desktop computers that made it cost-effective to run test programs, control instruments, collect data, as well as to allow test engineers to process and display data. Plug-in IEEE-488 boards allowed minicomputers and later PCs to perform these tasks. Today instruments communicate with PCs via USB, Ethernet, and most recently via wireless Ethernet (WiFi).
When the prices of PCs, motherboards, and embedded PCs dropped significantly, the next logical step was to combine the instrument and the PC into a single box. This took three forms:
- The PC was incorporated into the instrument. Traditional standalone instruments such as oscilloscopes or logic analyzers incorporated full PC functionality so that users could perform analysis using familiar tools, such as spreadsheets or analysis packages like MATLAB.
- The instrument moved into the PC. Manufacturers developed plug-in instrument cards, initially for the PC-XT and PC-AT bus and today for variations of the PCI bus.
- Chassis schemes were developed. When expansion slots disappeared from most PCs, engineers who wanted to work with instrument cards migrated to chassis schemes where one or two slots in the chassis would hold a PC motherboard in an industrial card format and the remaining slots would hold function cards.
Unchain Hardware and Software
In the Instrumentation Cloud the hardware is unchained—measurement front ends are no longer tied to a particular instrumentation network or PC. A WiFi sensor tag connects to any AP or router within range (Figure 1).
Figure 1. Except for sensor wiring, there are no physical links in the Instrumentation Cloud. Users perform all their tasks on Internet-enabled devices
The software is also unchained—measurement data are no longer tied to a particular data acquisition/analysis program on a specific computer. Instead of a sensor tag sending data to a device driver, which then feeds readings into local software on a PC, the tag sends the data to an Access Point for further routing to one or more user-controlled Web-based application servers, or Web Page Instruments, for processing. Each Web Page Instrument is specified by its own Server IP address.
A Web Page Instrument running on a range of devices (Figure 2) can provide any number of services: from a simple data presentation to an alarm service that sends a text message, tweet, or even a correcting signal to the sensor tag. It could act as a metering service that calculates consumption and costs, a database service that stores data, or it could provide machine health monitoring or home-based medical supervision. These examples give you an idea of what promises to become an enormous application space.
Figure 2. Portable devices such as an iPhone can be used to read measurements and send control commands using Web Page Instruments
Figure 3. Innovative Web sites such as Pachube, where people from around the world are putting their data for remote display, illustrate that the Instrumentation Cloud is moving from concept to reality (Click image for larger version)
Pachube.com, which bills itself as a "realtime data brokerage platform," is an interesting precursor of things to come in the instrumentation domain. You connect sensors to a PC or even a mobile device such as an iPhone or iPod and, by running applets available on the Web site, the measurement results are displayed on Pachube so that you can examine them at any time from any device that can access the Internet (Figure 3).
One piece of hardware that is popular among hobby experimenters for bringing data into Pachube is the Arduino, an open-source, microcontroller-based electronics prototyping platform. With this microcontroller-based board, users can connect sensors, write acquisition and control programs, and interface to iPhones or other Web-enabled devices.
Industrial users, however, are looking for something better suited to their needs: an OEM product with a high-performance analog/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 technology makes it possible to meet all these demands.
Putting the Pieces Together
An 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") shown in Figure 4.
Figure 4. The Tag4M incorporates WiFi capability, an A/D instrumentation front end, and even holds the battery in a very small OEM-style package
In detail, the 2.55 in. x 1.88 in. sensor tag incorporates a 2.4 GHz IEEE-802.11b/g WiFi transceiver, a ceramic chip antenna, a 32-bit RISC processor, and RAM/ROM plus nonvolatile memory for firmware and a data buffer. Its measurement front end comes with a 4-channel, 14-bit ADC and 4 digital I/O lines. A small lithium battery can power the unit for weeks.
For every operating cycle, the tag wakes up from Sleep mode and first acquires data that it sends to the Internet. Next it listens to the AP and receives instructions on any operations that it should do next, such as configuring and updating digital I/O (DIO) lines. For instance, a control tab in a Web Page Instrument could configure the hardware DIO lines as outputs and also set their values. These instructions are executed during the next wake-up 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.
This tag is a first-generation Instrumentation Cloud hardware product where all measurement capabilities are located inside a system-on-a-chip derivative of an RFID tag containing the radio link plus ADC and DIO lines. At present, ADC sample rates are relatively modest, peaking at 25 Sps, and thus are suited mostly for sensors or transducers that monitor slowly changing physical parameters. A maximum sampling rate of 28 kSps will soon be implemented by using the onboard 32 kHz real-time clock.
Because these first Cloud Instruments work in a succession of wake and sleep periods, they are not intended for applications that require continuous acquisition and processing. If powered from an external DC adaptor, however, a tag can operate continuously.
The Web Page Instrument
As for software, rather than use public services such as Pachube, industrial users want customized, dedicated, and secure Web Page Instruments. At this early stage, users will typically build these themselves using the Tag4M Web Instrument model (Figure 5) as well as standard Web site tools that make calls to the Tag4M's simple opcodes, which consist of a function code followed by a value associated with that function. For example, the Sleep Time opcode is 1; the command (1, 3000) tells the tag to set its Sleep Time to 3000 ms. Soon, however, users can expect to see a range of application builders that automate the process of creating Web Page Instruments.
Although this concept is of recent vintage, a number of obvious application areas for the Instrumentation Cloud come to mind, the most obvious being environment sensing embedded in to the pervasive WiFi infrastructure that exists in enterprises, retail outlets, factories, and warehouses. Cloud Instruments will enable people to tag and share real-time sensor data from objects, devices, and spaces around the world, using Web pages and widgets. A widget is a stand-alone instrumentation applet that can be embedded into third-party Web sites by users, on any pages where they have rights of authorship (e.g., a Web page, blog, or profile on a social media site). Cloud Instruments make it easier for people around the world to standardize their measurements and share tools, information, and the results of their experiments
One such example is MIT's iLab Service Broker, which is an academic Cloud Instrument dedicated to sharing lab experiments as broadly as possible. The iLab Service Broker creates a rich set of experiment resources that make it easier for faculty members around the world to share lab content and experiments over the Internet. Students all over the world can log into the iLab framework and perform local experiments using Tag4M WiFi tags that send data via local APs to the iLab service broker (the Server IP at MIT). Then their local measurements show up in the iLab framework context, making their experimentation interactive.
When it comes to reading sensors, the Tag4M's analog front end can interface with almost any sensor or transducer that generates a voltage, current, or digital output signal. Many such sensors connect directly to the tag, while others require minimal external circuitry.
In terms of preventative maintenance for complex machinery, plant engineers can place tag-based vibration sensors at key locations on the equipment to monitor moving parts. For such a monitoring application, we need to support ADC scanning rates to 20 Ksps; a specialty tag dedicated to vibration monitoring that contains only a vibration sensor is under discussion. Because many factories are equipped with wireless hot spots, with off-the-shelf technology, it becomes less expensive to add WiFi tags than it does to add ZigBee or Bluetooth radios, which require specialized APs to translate their proprietary protocols into TCP/IP or UDP for Internet compatibility.
A special ability of the Tag4M WiFi radio is its ability to make distance measurements. The tag can read the Receive Signal Strength Indicator (RSSI) and calculate its distance to the AP with which it is communicating. Tag measurements can thus be both time- and location-stamped, providing useful information in applications that require a mobile or moving setup.
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.
Door Open for Innovation
This merging of the hardware and software technologies allows engineers to find all sorts of innovative applications for sensor technology. They can do this by building wireless communication engines for data transfer to APs and by creating application firmware. Indeed, APs will play a much larger role, not only for routing sensor data but also for routing application code.
Today APs are used almost exclusively as routers to connect portable computing devices to the Internet. In a computer-based environment where applications are PC-based, the AP appears an underutilized computing device. Not so in a network-based computing environment, in which the AP can run Web Page Instruments, package sensor data in protocol scripts, and route them to specialized Web pages capable of reading those scripts and, for instance, downloading firmware updates or application patches to APs for further download to WiFi tags.
Expect innovation in the domain of Web Page Instruments thanks to tools such as automatic builders and updaters. Cluster Web pages, that run in multiple servers and that all belong to the same complex application, will include widgets for portable WiFi platforms. They will run wave-type applications that move from Web site to Web site to follow the progress of a physical process. We're very excited to see what imaginative uses will emerge for the Instrumentation Cloud in the near future.
Most Read Articles