M2M Middleware Platforms

Sean Horan of AT&T recently wrote a very good blog entry on “4 Reasons to Justify M2M Middleware Solutions.” Basically, Mr. Horan argues that M2M middleware makes it faster and easier to develop a broader range of more functional M2M applications. He especially sees M2M middleware helping large enterprises implement diverse M2M initiatives across their business units.

The four major benefits of using M2M middleware that Mr. Horan points out are:

·         Support for Multiple M2M Device types
There is a large and growing variety of M2M devices that an application or set of applications may need to support. Each of these devices comes with their own protocols, particularly for device management, and middleware helps insulate application developers from these differences by making their applications device agnostic.

·         Reduce M2M application development costs and standardize deployment
M2M middleware provides a number of M2M application and communication functions, as well as a framework to simplify the development of the application’s custom logic. M2M middleware also provides the architectural underpinnings to enable users to scale and manage M2M applications easily.

·         Integration enablement
The data collected from remote M2M devices is useful only if processed, analyzed and used in central applications. This is particularly true for larger enterprises in which the M2M data is often used to enhance the operation of existing enterprise applications. M2M middleware makes it easier to interface M2M data or applications with general enterprise applications.

·         Support Multiple Connectivity optionsBroadly speaking, M2M applications need to communicate across a broad range of wireless networks in addition to cellular – WiFi LANs, satellite, and low power wireless technologies. Applications also sometimes need to accept connections over the Internet. M2M middleware helps applications to be network agnostic and well as device agnostic.

Without a doubt, M2M middleware platforms enable you to develop and deploy M2M applications more easily and quickly. They can help deliver the four important benefits that Mr. Horan describes.

But there are two architectural approaches to M2M middleware that differ significantly in their approach to trying to deliver these benefits. They each have their pros and cons. It is advantageous to use an M2M middleware platform in developing your application, but it is critical to pick the middleware architecture that best meets your application's requirements and environment.

One type of M2M middleware platform follows the paradigm of classic information systems client/server middleware, in which one half of the middleware is implemented on the central application server, and the other half (the "agent") is implemented on the remote device. This approach can deliver all of the benefits Mr. Horan describes, and it is especially effective for migrating the rules engine, exception handling, and sophisticated diagnostics to the network "edge." This is particularly beneficial for applications that operate over networks that charge for usage, like cellular networks.

The downside with this approach is that EVERY device manufacturer involved in the application must implement the agent in their firmware. This may not be an issue if you are developing the hardware in-house, or only buying a single device from a manufacturer with whom you have leverage. This is more challenging if you are trying to get the agent implemented by the manufacturer of the vehicle-tracking device, the retail kiosk manufacturer, the vending machine manufacturer (all models), etc. Also, these agents are not lightweight, which is often an issue with many embedded devices. Implementing an agent in the full computer that is built into an MRI machine is easy; implementing it on the 8-bit microcontroller in a tank level monitor, not so easy.

The other major type of M2M middleware platform centralizes the device translators on the server and allows the many multiple M2M device types to communicate to the central server in their unaltered, native mode. This makes it easier to incorporate devices from many different manufacturers, and to handle the manufacturers' upgrades to hardware and firmware. The manufacturer does need to share their devices' communications protocols so that the appropriate translator can be created, but this is usually easier than getting the manufacturer to incorporate licensed agent firmware into their product. Otherwise the equally powerful server component of this middleware platform delivers the four major benefits that Mr. Horan profiled.

The downside of this approach is that functionality is not standardized across devices, particularly for device management and diagnostics. It is also more difficult to optimize application performance and wireless costs when incorporating unaltered, inexpensive, off-the-shelf M2M devices.

Either one of these major types of M2M middleware platforms can deliver the major benefits that middleware provides -- multiple device support, easier application development, integration enablement, and multiple connectivity options. But the specific difficulty and cost of developing, deploying and operating your application can differ markedly between the two architectures. You should carefully consider how your application requirements match up against the specific capabilities of the two approaches to select the best middleware for you.