Web services are one way to connect devices and sensors to the extended Internet, where objects talk to other objects. Here's a primer on how Web services work for machine-to-machine applications.
Connecting a device or sensor to the Internet where the data can be digested is rarely easy–but nothing is ever easy in embedded systems design. All the great analytical tools that exist online (in “The Cloud”) for your customers to use will not only extend their devices' functionality but also add the convenience and–perhaps–the cost savings of computing via the Internet. You, however, have to build a way to get their data from the device or sensor to these applications in The Cloud, where the data can be analyzed and used. For many embedded systems design teams, this territory is new; you may be traversing it for the first time. Here's what you'll need to know about prepping and sending data to the Web and how to use Web services–“a method of communication between two electronic devices over a network”*–to do some of the heavy lifting of creating your “device cloud” on the Internet.
What cloud are you on?
Most of us have by now been indoctrinated with phrases like “The Cloud” and “cloud computing.” Beyond the veritable wet things that make rain, snow, and other storms, what is it really? The simple answer is to not get too caught up in cloud terminology, but instead to realize that software applications, connectivity, and storage can exist on a local machine, such as a PC, or on a server in a network somewhere. Some of the best examples are the potpourri of Web-based applications like e-mail and other points of centralized intelligence like mapping. The benefit of computing in The Cloud is that it's generally connected and hence can be shared by everyone tied to the extended Internet. The term extended Internet means objects are connected to objects via the Internet, not just people to people. M2M (machine-to-machine) connectivity happens through extended Internet in a device cloud. Explaining how an M2M device cloud is done is what I'll concentrate on here.
Parking the data
Sharing data is the name of the game. That data, however, needs to be parked somewhere where it can be appropriately digested. To connect a device or sensor to the Internet, you need to know first where you can “park” the data. Most modern tools rely on Web services to plug directly into the extended Internet, so you need to know what Web services are, how to use them, and how to apply Web services to a remote device or sensor.
To begin designing an embedded system that will interact with The Cloud, you need a set of functional capabilities to connect the device to the application residing in The Cloud. Keep in mind that a device may be anything from a meter or thermostat to an engine or machine. It may also be something fixed like a tank or containment vessel used for storage and dispensing. On the flip side, the application may be any system used for projecting data. It may be a mobile application housed on a smart phone, a Web-based dashboard-style portal, an enterprise resource planning system, or an expert system. In any event, the challenge is to get the important information about the device or asset to the application. To achieve this objective, we first define a set of three functions necessary to create this pathway.
Creating a pathway
You'll need to start with the functions shown in Figure 1 :
Click on image to enlarge.
- Sense and connect. This function has limited intelligence and is focused on getting the information. It includes radio modules, simple logic, and the sensing technology related to the need at hand.
- Aggregation and transformation. Effectively summarize or aggregate the data points in a manner that makes sense before attempting to ship it across a large network like the Internet. Another key part of this function is to put the information into a common representational language. Hence, this function typically includes rule frameworks, protocol translation, and mapping. It also generally includes a pathway to an IP-based network.
- The device cloud. The device cloud is part of the extended Internet and has general awareness of all devices connected to remote sites. Generally it's a hosted system that serves as a pass through and data storage. It also aggregates the information from all remote locations in the same way that the aggregation and transformation function pulled together disparate information at the individual device.
To understand this environment better, think of cloud architecture as a set of services shown in Figure 2 and defined here:
- Infrastructure as a Service (IaaS). At the lowest level, IaaS is the “nuts and bolts” of The Cloud. It includes the network connectivity, physical servers, firewalls, disks and routers.
- Platform as a Service (PaaS). This includes all the software that forms contextual communication links and management functions. It also provides the environment in which the top level can exist.
- Software as a Service (SaaS). At the top level, these are the actual applications, be they Web pages, mapping, analytics, or others–the place where the ultimate intelligent work gets done, the home of meaningful context. In this way, the device cloud provides the contextual representation of devices using a common language that enables Web-based applications to get real work done.
Sprechen sie Cloud?
Of course, we need a common vocabulary. This is where Web services comes in. A typical definition of Web services is a method for integrating Web-based applications using the XML, HTTP, SOAP, WSDL, and UDDI open standards over an Internet protocol backbone. To simplify, Web services leverage the common language of the Internet to get stuff done by describing things in a common way, using common verbs to send and receive information (Put or Get), and using a methodology that allows for one-to-many and many-to-one, by request or subscription.
How does it work? Start with a language that enables communication–you already know it, however, you may not have known what it meant. It's HTTP or Hyper Text Transfer Protocol. This is the language of Internet clients and servers and most importantly the general purpose protocol for applying Internet verbs to nouns. Sounds good right? We learned about nouns and verbs in 2nd grade.
Internet nouns are things called Universal Resource Locators (URLs) or URIs (Uniform Resource Identifiers). They might look something like www.mycoolwebsite.com .
Click on image to enlarge.
Note that the meaning and context is conveyed within the tags while the content is the value associated with the tags. Because the examples use meaningful, contextual tags, you can omit a piece of information, add other pieces of information, and shuffle them in any order without changing the meaning of the individual elements.
You need verbs to go with the nouns. For the verbs, use Representational State Transfer (REST). According to Wikipedia, REST is “a style of software architecture for distributed hypermedia systems such as the World Wide Web.” REST means you're using a common set of actions, the details of which are handled by the context. For a protocol like HTTP, we commonly talk about seven different actions or verbs, of which four do the heavy lifting in the device cloud. The seven verbs are: Get, Put, Post, Delete, Head, Trace, and Connect. For the sake of this article, don't worry about Head, Trace, and Connect. We really want to focus on the most important four: Get, Put, Post and Delete. Here's what they do.
Every time you go to a Web site, you do a Get. It's a request to “get” or retrieve a representation of a file or collection. Of course, like many questions, they often lead to more questions, so one “get” often begets another. Get is the verb, and the URL plus any other inserted information is the noun. Next is the Put. Put is the opposite of Get and hence is a request to upload or “put” a file or collection into a database. Delete is the magic eraser. No doubt, if something has been “put” somewhere, we may want to “get” a copy of it, but we most certainly also want to be able to “delete” it. Finally, we have Post. This is the complicated one. It's best to think of Post as an intermediary step or a relay. Say you want to know an answer to a question but don't really know who to ask it. You can't do a Get because you don't know what you're asking. So, you take whatever information you have and package it up into a Post. Once it's “post”ed, so-called expert processes will see your post and respond accordingly. You can wait around for the response in real time (synchronously) or go away and ask for notification of response (asynchronously).
To apply these pieces to devices and applications, let's pretend you have a set of temperature sensors connected to different buildings. Each sensor, using the appropriate connection, aggregation and transformation functions sends temperature values into a database in the device cloud every hour. In this context, the temperature values are “put” into The Cloud. Next assume an application analyzes and graphs the various temperatures by time and location. In this context, the application will “get” the values from the database associated with the appropriate time and place nouns. Further, assume that you only want to keep the data for a month, so every day a separate process does a “delete” on the values that are too old. Finally, assume that a user of the application wants the current temperature value in real time, not just to the nearest hour. In this case, the application will “post” a request for the current value at a given location and will wait for the request to be processed and an answer returned. These are Web services at work, using simple nouns and verbs.
In summary, you see that successful connection of device information to remote applications is made easy by the appropriate connection, aggregation, and transformation functions. The device cloud and the extended Internet are then used as the conduit for bridging data to the application. This is all done using a relatively simple collection of internet verbs tied contextually to a set of Internet nouns. It doesn't need to be hard. Just remember to be RESTful and use the Post.
Joel Young is CTO and senior vice president of R&D for Digi International. He has more than 24 years of experience in developing and managing data and voice communications.
This article provided courtesy of Embedded.com and Embedded Systems Design magazine.
See more articles like this one on Embedded.com.
This material was first printed in Embedded Systems Design magazine.
Sign up for subscriptions and newsletters.
Copyright © 2011
UBM–All rights reserved.