Jump to: navigation, search


< IoT
Revision as of 11:24, 10 April 2012 by Bcabe.sierrawireless.com (Talk | contribs) (M2M Problem Descriptions)

M2M Problems

The Machine to Machine(M2M) space combines systems from the embedded space and the enterprise/cloud space. This combination introduces problems that must be addressed by an M2M system provider that do not traditionally exist in either the embedded space or the enterprise/cloud space. This page is meant to catalog these M2M specific issues. It is intended that these problems will reference M2M Scenario Descriptions which provide the system context.  This catalog is meant to serve as an educational tool for developers and architects who are new to M2M and as a reference during development of M2M technologies at Eclipse.

M2M Problem Description Template

Please refer to this template documentation.

M2M Problem Descriptions

M2M-Problem-0001 - Sharing of information for properly interpreting data values

Consider a sensor that provides the refrigerator temperature as a floating point number. In an M2M system there will be many potential consumers of this sensor reading. Some consumers may be on the embedded platform itself, others may execute in the enterprise or cloud. There is also a producer for transforming this number into a logical format(3.7 degrees C) instead of its protocol wire format. There is additional information that is required in order to properly make use of this floating point number that represents Refrigerator Temperature. Examples of this additional information from the producer include the data type(floating point), the units of the number(degrees Celsius), data range minimum and maximum values, and values used to represent sensor errors or missing sensors. Consumers may have their own additional information about this particular sensor reading, such as warning and error thresholds for alarm notification and text to display the units and sensor name in various human readable languages.

In order for producers and consumers to collaborate effectively, this additional information about sensors and actuators needs to be shared between the interested systems.

Fielded solution patterns

There have been many different ways used to solve this problem. Some solutions rely on the existence of a discovery service, others rely on a priori knowledge and others on always sending everything they know.

There are a couple of solutions to sharing that avoid the need for a discovery mechanism:

  • Modbus - Distributed nodes communicate by reading and writing registers across a modbus network. The information about each register must be known at application design time. No mechanisms are provided for discovering the information required to interpret the bits in a register at runtime.
  • Continua - The Continua Alliance was very aware of the issue when designing their protocols for healthcare data interchange of sensor data. Continua compliant systems send all of the additional information that they have about a sensor reading along with the data value or set of values. This sidesteps the need for discovery of the additional information, as it is always available. This constant availability comes at the cost of significantly increased data transmission sizes.
  • SAE J1939 – The Society of Automotive Engineers created a standard named J1939. This standard describes many of the additional bits of information for a data value, such as units and data ranges. Producers and consumers can be written against this standard and understand how to interpret the data from these sources without explicit communication of additional information. In this way, SAE J1939 makes several improvements beyond Modbus, but is not sufficient if you wish to share properties that are not covered in the specification, such as translations for sensor names, application specific error notification limits, etc.

Related scenarios

Referenced by problems

  • None.