What's the difference between this article and other writings about M2M communications? Is this yet another M2M story in disguise that uses some new catch phrase? No, it's not. It turns out that the solutions snuck up on all of us, and we were just looking in the wrong place.

The promise of M2M communication

M2M has been a general term used to describe all aspects of machine-to-machine, machine-to-human, machine-to-enterprise-type communication for the purpose of management and control of assets and devices. The goal was to drive efficiency and create new revenue streams. Much of what has been written about M2M has been the promise of managing high-value assets. Of course, there needed to be some big software application, listening and tracking. And usually connectivity was handled by a friendly, wired IP pipe. While this was interesting and beneficial for a class of assets, it was certainly limiting. The challenge of scalability was limited by the need to either give the lesser devices the ability to speak - a sort of an intelligence boost using hubs -, simplify the software on the application side, or improve the connectivity efficiency by using more wireless media.

Over the past several years, many engineers have carved out targeted, fragmented solutions to address each of these limitations. For example, some have given the communication-challenged devices the ability to speak. Others have used a network-communications firewall-friendly phone home model. Of course, others have been working to simplify the software by creating a hosted software model.

Today, there is a steady stream of partial solutions for remote device management. Nonetheless, we still hear cries that the ramp up is yet to come. In order to best find the remote device management successes, it is useful to first take a look at the barriers that have kept some from realising the dream.

First of all, running wires has always been a nuisance. Wireless offers a new promise of wiring avoidance. However, we have learned that RF, with the complexities of interference, range and configuration, has made this difficult for the novice. Secondly, just because you now have wireless connectivity to the device doesn't mean that the protocols, addressing and routing mechanisms that enable communication between the device and the necessary application are defined and work.

When using a computer, if something goes wrong, we have all been trained in the art of Ctrl-Alt-Delete. However, remote device management means that the device is of course remote, making the presence of human beings a luxury that often can't be afforded. This means that somewhere along the value chain, communication must be enabled and maintained without human intervention. Intelligent devices that have a processor and lots of memory are smart enough to have additional functionality programmed in. However, the non-intelligent devices demand more subtle approaches, which often require analysis of various sensor inputs. These mean programming and a detailed understanding of device behaviour.

While seemingly obvious, cost effectiveness is often overlooked. Defined as the total cost to monitor or manage a device, it is directly related to the value of the device or commodity being monitored. The lower the value, the less needs to be spent on it.

In order to best describe the solutions being used to address the aforementioned components, it is important to introduce the concept of a drop-in network. The goal of a drop-in networking solution is to provide complete, end-to-end connectivity to devices in locations where wire-line infrastructure doesn't exist or doesn't satisfy customer needs. Such solutions are primarily wireless, cost efficient, non-intrusive, secure, reliable and easy to deploy.

Often, devices can be connected with PAN (personal-area-network) technology via wireless technologies like ZigBee, 802.15.4 or proprietary mesh. These are connected through a router back to a programmable gateway device. Note that in the simplest case, the PAN can be rolled up back into the gateway. Consequently, in the simplest form, the gateway may be connected directly to the end device. The programmable gateway provides data aggregation, routing, and conversion of data between the device side and the IP/WAN side of the network. Also connected to the IP/WAN is a management server and remote application server. The management server provides the ability to manage the connectivity of the end device up through the network, while the application server provides the business application associated with the end device. They could be remote from each other or in the same premises; nonetheless, functional separation of these applications means they can be hosted in different media: for example, one may be a hosted service, and the other may be deployed at a customer premises.

The concept behind this architecture is to provide a method for end-to-end connectivity while simplifying the aggregation points. Because the gateway is programmed with a high-level language like Python, common functions can be added by a web or IT developer skill set, without touching the lower level connectivity functions associated with the PAN or WAN networks. In addition, connectivity management is also handled with an agent on the gateway, separate from the programming engine, providing a level of protection from application errors. Further, because of the remote-connectivity-management infrastructure, the system is protected from needing a human presence at the remote locations.

When looking at the different environments, it is easiest to split them into a number of different application types. In a legacy application, the end customer has a pre-existing application environment that they wish to use. While it could be either in a hosted service or a customer-premise model, legacy applications tend to be in an on-site data centre. The notion here is that the application has been in existence connecting a typically local, wired infrastructure for some time. In this scenario, it is the job of the gateway to masquerade as a local, wired device, masking the complexities of the WAN and wireless networks. A common usage model for this scenario is Modbus/TCP, where the software on the gateway masquerades as a Modbus/TCP slave device, front-ending the end devices. This is the most common deployment seen today because it provides an easy economic justification and is related to an existing business model.

Web-service applications require that the end customer has a web-service back-end system and a proficient web-development-oriented IT staff. The gateway is normally programmed to send and receive data via XML. While it could be used in either a hosted service or a customer-premise model, typically the application is already deployed within the end customer's data centre. Both the gateway application and the corresponding application integration logic tend to be completed by the end customer's local IT organisation. Like the legacy application, this also is a very common deployment today, for the same reasons.

Collaboration clients are perhaps the newest trend in remote device management and have yet to really begin to scale. However, it promises to be the wave of the future as more end customers need to have a more intimate relationship with their devices. In this scenario, the collaboration client often takes the form of a focused application that filters and aggregates key information. The information can be populated into a database or displayed as a dashboard item, gadget or widget on a mobile phone or PC. The key here is that the application can be easily pulled from a pool of focused applications and customised by the user for a specific purpose. It is almost always front-ended by a virtual server in the sky using Web 2.0 constructs, mitigating the need for big IT investment. The application on the gateway can be very focused on the constructs that are important to the user.

Evolutionary direction

Legacy-application connectivity and web-service approaches have been happening for some time, as have wired connections to intelligent devices. This part is merely an evolution of connectivity options. The revolutionary part, which includes the seamless wireless connectivity from the device to the application, is now beginning to ramp. This is enabling many different applications that we haven't ever seen. The enabler here is the availability of the drop-in network, which provides cost-effective, seamless connectivity to most any device, even those of lesser intelligence. Finally, this connectivity is enabling the applications to go beyond the typical premises-based, big software to efficient hosted services. It is also beginning to drive demand for the set of collaboration clients, previously only available for web-based gadget functions.