RTC Group, Inc.

Machine to Machine – Intelligent Devices Talking to Each Other

By: Bill Weinberg, LinuxPundit.com and OllianceGroup.com

An increasing phenomenon is the connection of autonomous nodes comprising sometimes vast systems and moving huge amounts of data with relatively occasional human intervention. The development and use of M2M systems involves a variety of opportunities and options.

Most end-users and indeed most engineers have a very human-centric view of Internet—people using computers to view web pages, send email, download content, transact business, etc.  Equally valid and increasingly pervasive is using the ’Net and attached (non-TCP/IP) networks to facilitate communication among machines, with little or no human intervention.    

This machine-to-machine or M2M paradigm involves collection and transmission of event-level data (called telemetry in older systems) from end-nodes—various types of intelligent devices—varying degrees of consolidation, aggregation and analysis en route, and eventual delivery to servers or workstations upstream for analysis and action. M2M data can travel via wired or wireless transport and involve minimal/trivial payloads (e.g., current temperature, location data or simply node ID) over long intervals, or massive data sets and latency-sensitive high-frequency data streams (e.g., audio and video signals).

M2M deployment is steadily growing in size and scope and is on course to outpace human Internet users and traffic: Industry analysts forecast 25 billion connected devices by 2015 (3-4 times the entire human population), with M2M traffic expected to grow by 258 percent.

Example M2M Applications

As all classes of intelligent devices become networked (or at least networkable), M2M applications follow. To date, there have been certain sweet spots and more obvious applications:

Smart Energy: The emerging Smart Grid is practically the poster child for M2M. The most familiar smart energy application lies in smart meters that monitor premises energy usage and relay kilowatt/hour data upstream to utility companies for billing. Other Smart Grid M2M nodes include upstream aggregation points (mesh routers) for Smart Meters, substation and transmission line monitors; downstream are high load premises devices like HVAC systems, pool pumps and large white box appliances that utilities would like to manage during peak loading hours.

Manufacturing and Inventory Control: Today, factories and warehouses increasingly use smart labels and RFID tags to track goods through the manufacturing process and out the door into distribution channels. While RFID devices are mostly passive, data from scanners is passed upstream to servers, helping to monitor production yields, inventory turnover and leakage, and to monitor the provenance of health-critical goods like medicine and contaminated foodstuffs. A related M2M application is monitoring inventory levels at points of sale, especially mechanical vending machines.

Environmental Monitoring and Animal Tracking: Systems that “Take the temperature” of the globe through sensors that measure heat, light, seismic activity, wind speed, ocean currents, air quality, position and other physical attributes of our planet are typical M2M targets. In some cases, data gathered reflects natural phenomena, like volcanic activity and El Niño current variations; in others M2M systems are called upon to monitor crop yields or shock waves from weapons detonation. A related set of applications involves tracking the movements of animals, both domestic—herds of sheep and cows, and in the wild—sea turtles, migratory birds, etc.

In-Vehicle Systems: Connected in-vehicle systems and data from them are multiplying rapidly.  Systems like GPRS radio (e.g., OnStar), BlueTooth and other wireless media relay vehicle status information, with more types of data becoming increasingly accessible to dealers, repair shops and also insurance companies—including maintenance information, global positioning coordinates, wireless payment for tolls and gas pumps, and data from “black boxes” on speed and driving habits of personal, commercial and also racing vehicles.

Smart Signage: Digital signs on the highway and at transportation centers, programmable billboards and flat panel advertising displays (a.k.a. Digital Out-of-Home “DOH” advertising) are the recipients of M2M data streams as automated warning systems and ad brokering servers provision and update them with up-to-the-minute content. Conversely, the signage reports back on device health and sometimes on local conditions as well.

Mobile Data: An application not usually considered M2M is collection and analysis of usage and local information collected from mobile phones and other wireless devices. While the human user interacts with the device for voice and text communication, playing media and running mobile apps, the phone itself registers myriad data points about user behavior, most notoriously, location data.

These diverse applications and others share a set of attributes common to the M2M paradigm:

• Endpoints (and other nodes) operating without human intervention


• Fan-out from/to increasingly numerous nodes of varying intelligence and provisioning

• Communication over a mix of TCP/IP networking and other protocols with a range of physical transport types

• Some degree of data consolidation / aggregation from endpoints to infrastructure


M2M Architecture and Ecosystem

There is no universal, one-size-fits-all architecture for M2M. Most M2M designs fall into two broad categories: all-IP and hybrid. In the past, all-IP designs were considered “high end”—only better-provisioned nodes boasted embedded CPUs with sufficient horsepower to run TCP/IP stacks and bills of material robust enough to include Ethernet or Wi-Fi. Today, TCP/IP availability is descending into more modest hardware, through cheap all-in-one networking chips and from migration to an increasing interoperability with IP communication within industrial networking standards like ZigBee.  

All IP-designs have the advantage of just “plugging in” to available Wi-Fi or Ethernet.  Disadvantages include higher node costs, potential mismatch between latency requirements and network characteristics, and the need to worry about device security. There is also the challenge of accommodating IPv6. IP-capable devices are today mostly enabled for IPv4—no problem when deployed on IPv4 subnets. However, with the emerging IPv4 address famine and imminent transition to IPv6, the projected billions of M2M nodes will be well served by adopting IPv6 sooner rather than later.

Hybrid designs involve M2M nodes that for various reasons cannot accommodate standard networking interfaces—they are too small, too power-sensitive, too remote or just too “weird.”  Examples include devices on mountaintops, sensors buried deep in the earth or inside the human body, tracking devices on birds and other animals or devices deployed in outer space. Hybrid designs accommodate legacy telemetry-type systems and low-end M2M device nodes, including mostly passive sensors like RFID tags, low frequency devices like environmental sensors, and one-time use devices like sensors for massive seismic events and weapons testing.  

A hybrid M2M system entails deployment of terminal nodes that communicate via non-IP digital and also analog signals, either among themselves in a mesh network or directly with a gateway controller. The gateway consolidates and aggregates the signals from/to the devices and connects upstream to IP networks. In some cases, the gateway also performs local signal conditioning, filtering, logging and other processing before passing data onward and upward for analysis.

Hybrid doesn’t necessarily mean legacy or non-standard. Many M2M designs employ mobile telephony for transport, sending packets over GSM or CDMA networks to reach Internet gateways and ultimately data centers and workstations for analysis. Similarly, other M2M designs rely on wireless mesh networking standards like Zigbee or build on Bluetooth or Zwave for monitoring and control, as is common in Smart Grid premises equipment (Figure 1).

Transport Options

While a detailed discussion of M2M transport mechanisms is beyond the scope of this article, some communications mechanisms merit brief examination here. Some definitions of M2M assume that terminal nodes will build on mobile/wireless networking (as with Telenor, Jasper Wireless and others). While this may seem counterintuitive—why embed the equivalent of an entire mobile phone in a sensor or other dedicated device?—their use of General Packet Radio Service (GPRS) differs greatly from conventional handset applications. First, M2M ecosystem suppliers have developed special versions of wireless chipsets and SIMs to serve this market, with price points and specifications targeted at M2M terminal nodes. Second, most M2M devices don’t need voice or even full (3G) IP communications capabilities—they make do by piggybacking on SS7 networks and actually using SMS to communicate upstream despite lack of guaranteed delivery, security, etc.

Mesh networking is ideal for connecting moderate to large numbers of peer-level terminal nodes, as in Smart Grid premises monitoring, industrial control and environmental monitoring. For developers, it is important to understand the complexity of working with mesh networks. While literature and resources for building terminal nodes is plentiful (especially for Zigbee), less available is information about building mesh controllers and establishing, joining and managing mesh networks over time. Moreover, while standards like Zigbee are well documented for low-level communications, higher-level profiles and best practices for interoperability are less mature.

Another mechanism is RFID, which strictly speaking is not a transport mechanism. RFID-tagged objects depend on scanners or physical portals (at the entrances to warehouses, etc.) to energize the tags, retrieve identity codes and other payloads stored on them, add data if needed, and log or transmit the scanning event upstream. Nonetheless, RFID participates in the M2M paradigm and is a source of M2M data—the functionality otherwise associated with a single node is just spread between the tagged item, the tag and the scanner (e.g, location information).

Responding to the M2M Data Deluge with Big Data

With billions of devices delivering telemetry from endpoint to infrastructure, M2M implies generation, storage and processing of gigabytes, terabytes and even petabytes of data on a monthly, weekly or even daily basis. Today, much of that data still drops into the bit bucket, but companies are increasingly realizing the value of “mining” it for insight. M2M was born into a world where large data stores were processed by relational databases and archived into data warehouse. Today, the ever-growing deluge of device-generated data is outstripping these legacy stores in complexity, volume and velocity.

An emerging response to the data deluge is called “Big Data”—massive scalable data management clusters built from commodity blades/servers that distribute terabyte or larger data sets across distributed file systems and run Google’s MapReduce algorithm and analytics programs to make sense of unstructured and semi-structured M2M event data and telemetry (Figure 2).

The leading Big Data technologies build on Apache Hadoop and related open source projects (HDFS, Hive, Mahout, etc.), with vendors such as Cloudera, HortonWorks, Amazon, Karmasphere and others offering commercial Hadoop distributions, Cloud-based Hadoop implementations and analytics tools.

M2M Implementation Resources

Embarking upon an M2M project is no more daunting than starting other types of embedded design. In fact, many conventional intelligent device types, augmented with connectivity, fit by definition into the M2M networking paradigm. However, there are attributes and requirements unique to M2M, and resources dedicated to M2M development, especially written in and for Java:

aJile (http://www.ajile.com) aJile Systems provides an RTOS and standard JME platform for M2M applications and ready-to-embed implementations of its software in silicon. aJile features support for multiple OSGi profiles and Java CDC, CLDC and MIDP runtimes.

BITXml (http://www.bitxml.org/) offers an XML-based protocol for M2M communications that covers syntax, semantics and formal definitions for devices and gateways and associated events, commands and payloads. There are also open source implementations of BITXml in Java (http://sourceforge.net/projects/bitxml-java/) and for .NET (http://sourceforge.net/projects/bitxml-dotnet/).

CEP (http://www.oracle.com/technetwork/middleware/complex-event-processing/overview/) a.k.a. Complex Event Processing is Oracle’s M2M platform for building applications to filter, correlate and process events in real time to feed upstream applications and SOA systems. CEP provides capabilities for designing, defining and implementing event processing for both enterprise and embedded applications and builds on standard SQL, Java, Spring DM and OSGI.

Cinterion TC65I (http://www.cinterion.com/products/m2m-evolution/connector/tc65i.html) is an M2M module running Java. It’s a great starting point to prototype M2M applications and boasts built-in GPRS, TCP/IP over AT and a Java IMP-NG virtual machine.

COOS (http://www.coosproject.org) the “Connected Objects Operating System” is not an M2M OS, but rather an open source, modular, pluggable and distributable, middleware platform.   Written in Java, COOS supports connecting, monitoring and managing services and device objects using messages.

M2MXML (http://m2mxml.sourceforge.net/) is another XML-based M2M protocol with open source implementations in Java and in C.

Motorola G24 (http://www.motorola.com/) is a Java-powered wireless controller targeting M2M applications. Its feature set includes messaging, secure Internet connections and support for MQTT M2M protocol.

MQTT (http://mqtt.org) is an M2M protocol featuring lightweight publish/subscribe messaging.  MQTT is ideal for remote sensors communicating to a broker via satellite link, applications using dial-up connections and in a range of home automation and small sensor device scenarios. It offers small footprint, low power usage, minimal data packet size, and efficient distribution of information to one or many receivers. 

OSGi (http://osgi.org) the Open Source Gateway Initiative (now OSGi Alliance) and the OSGi Platform provide standardized primitives for small, reusable and collaborative application components and functions to change device composition dynamically on a variety of networks using a service-oriented architecture (SOA). OSGi includes standard interfaces for HTTP servers, configuration, logging, security, user administration, XML and a framework for managing the life-cycle of software components, services and devices.

Sunspot (http://java.net/projects/spots/) SPOTs are small, Java-based, wireless devices originally developed at Oracle Labs. The SPOTs project hosts development of open source code for building actual devices, including system code, application frameworks, demonstrations and applications. 

Viewbiquity (http://www.viewbiquity.com/) offers a Cloud-based M2M platform to connect devices, processes and applications. The Viewbiquity Cloud Interface (VCI) features a scripting interface and support for reliable connectivity, application control, device configuration, automated database logging capabilities, redundancy and backup.

Embracing M2M is not really a matter of embarking on a new class of embedded design. It’s more about enabling existing classes of intelligent devices to communicate upstream with back office systems and data centers as part of larger, more comprehensive end-to-end applications.  M2M is a mindset—in today’s world of ubiquitous networking, no device can afford to be an island. Whatever type of device your organization is specifying and implementing today should include support for M2M protocols, connectivity and capabilities, because it’s likely to find deployment by your channel partners and customers in a larger context of M2M systems and software.  


Bill Weinberg

(408) 568-2492.



© 2009 RTC Group, Inc., 905 Calle Amanecer, Suite 250, San Clemente, CA 92673