m2mxml White Paper

7/30/2019 m2mxml White Paper

1/5

M2MXML: An Open Standard for

Machine-To-MachineCommunications

White Paper

Byron K. Appelt

SensorLogic, Inc.


2/5

IntroductionThe field of machine-to-machine (M2M) communications is rapidly expanding,

however, it adoption cannot yet be termed widespread. One of the reasons behind this isthe difficulty in building end-to-end solutions. In most cases, every component, from the

device and embedded code, to the back-end application and web interface is a customeffort. This has begun to change.

Radio manufacturers and third party integrators have started offering completetelemetry modules inclusive of the radio, power supply, I/O, and even the enclosure and

connectors. The availability of this sort of hardware, in many cases reduces the device

side hardware design to the selection of an off the shelf component.The advent of the Telemetry Service Provider (TSP) which, for a monthly fee,

provides all of the interfaces to carriers, data storage, web interfaces, and other back-end

functions, now allows the server side of an M2M application to be purchased as a servicerather than architected at great expense and effort.

Even though both the hardware and the back-end are available as off the shelf

products, the device manufacturers have difficulty selling their products because there isstill a significant integration effort in writing embedded code to talk to a back-end

service. Similarly, back-end providers are expending resources writing embedded

applications because they cant sell their service without devices that can talk to it.

The missing piece of the pervasive off-the-shelf telemetry application is a widelyadopted protocol allowing embedded code to be written for the commercially available

hardware to talk to the server-side application available for hire at the TSP. If this

protocol existed, especially as an open standard, device manufacturers as well as thirdparties could write the embedded applications to interface to any TSP that implemented

the protocol.

Complete M2M applications could then be constructed from three potentially off

the shelf components: back-end services, device hardware, and embedded code. The endusers would be able to choose to buy the entire application as a package, implement one

or more of the components themselves, or acquire them from different sources. They

would all be able to interface because they relied on a standard protocol.M2MXML is being developed as an open standard to be this protocol. The

standard, along with supporting code libraries is being developed in the open-source

community and is hosted at http://www.m2mxml.org.

Limitations of existing protocolsThere are a number of protocols that have been used in M2M and related fields,

such as industrial automation. However, they all are a poor fit for one or more reasons.

Designed for a connection oriented environment

Many protocols that have been deployed in M2M were borrowed from industrial

automation and were originally designed for use on multi-drop serial networks

such as RS485. Therefore a low latency high availability was assumed in theirdesign.
http://www.m2mxml.org/http://www.m2mxml.org/


3/5

Designed for a Master-Slave deployment

MODBUS is also an example of a protocol designed to be used in a master-slave

configuration. This is sometimes appropriate for M2M, but frequently is not. The

ability to have devices report on a schedule or report by exception is crucial toefficient use of wireless bandwidth.

Bandwidth Intensive

Many protocols that were not designed for M2M applications are incrediblybloated when viewed in the context of wireless networks.

Complex

The fact that an M2M protocol needs to be implemented, in some cases, by

devices that have very limited computational resources, means that a protocolneeds to be simple. This need is further exacerbated by the fact that many of the

individuals who would implement the embedded code are principally hardwaredesigners and not software engineers and frequently work individually or in very

small teams.

Over Engineered

Many protocol standards are over-designed, with XML protocols being some ofthe worst. They are written in an attempt to satisfy all members of a committee

and often the result is a protocol may satisfy everyone, but is useable by no one.

M2MXML Design Goals

Terse but not too terse

M2MXML needs to be tight enough for reasonable use over wireless networks.

However, the cost of bandwidth is decreasing and this should not be ignored. There is

a tradeoff between terseness and the effort required for implementation and debug. In

the design of M2MXML the goal was to be fairly terse, but maintain a level of humanreadability so that the protocols use can be quickly understood from examples and be

readily debugged especially considering the limited toolsets that are often available to

the device developer. It is also assumed that once an application is mature, a

compression layer could be implemented on top of M2MXML to reduce theoperations cost, if necessary.

XML Based

As its name implies, M2MXML is implemented using the eXtensible Markup

Language. This choice was made to leverage an existing and well known grammar,

and to allow the use of widely available third party APIs for handling XML. XML in


4/5

the embedded world has often been criticized as too bloated, but intelligent use allows

the previously mentioned balance of terseness to be reached

Self-Contained messages

In order to facilitate its use on high latency and low availability networks, as well as

to decrease the complexity of transactions, M2MXML is essentially composed ofself-contained messages. Generally transactions are a single fire and forget message,

or a request message followed by a response message.

Transport Agnostic

M2MXML does not specify anything about what transport protocols are used. Any

protocol for delivering XML can be used to deliver M2XML.

Extensibility

M2MXML is meant to be the framework for communications in a wide range of

M2M applications. Therefore, its design is not meant to include all of the possiblecommands and configuration parameters, etc. that a complex application would needto define. Parts of the protocol are meant to be defined in an application specific

manner. However, the protocol is meant to complete enough that the vast majority of

simple applications can use it out of the box.

ExamplesA quick way to provide a general feel for M2MXML is to show a few examples. This isnot meant to be a tutorial or any sort of reference documentation. These examples are just

meant to demonstrate the simplicity and intuitiveness of the protocol.

Example 1: A reporting a data point

The first example is simply a device reporting a single data point on a schedule. In

M2MXML data point messages are called percepts, which is a term borrowed from

robotics. The following message reports a reading of 42 for an analog port with address

A1. Additional attributes can be specified to indicate other data types, a timestamp that isnot current, etc.

Example 2: A command to turn on an output

This example is a command sent to a device to energize a relay. The port connected to therelay has an address of relay1 which is an arbitrary designation unique within the

device. A sequence number is used to match the response to the request. The name

attribute of the Commandelement is an example of an area where the protocol is meant to


5/5

be customized. The turnOn command is part of the base specification, but additional

commands specific to an application can be added.

Request:

Response:

m2mxml White Paper

Documents

Transcript of m2mxml White Paper