Jump to: navigation, search

Difference between revisions of "IoT/M2MIWG/M2M Scenarios"

< IoT
(Added M2M Scenario 0003)
m (minor wording and capitalizaiton changes)
(One intermediate revision by one other user not shown)
Line 44: Line 44:
 
| identifier = 0003
 
| identifier = 0003
  
| name = Providing SCADA Sensor/Actuator Information to multiple Producers/Consumers
+
| name = Fitting Refrigeration Unit Information Into a Multiple Producer/Consumer Model
  
| description = One of the issues that modern M2M technology will have to address going forward is that sensor and equipment manufactures will start to look at M2M technology and associated tooling to integrate into their next generation products.  Indeed, one of the current market segments exiting for M2M devices are to serve as “Communications Gateways” to existing industrial device and sensor infrastructure. But the market is still fractured into many divergent and non-compatible technologies that do not lend themselves to a real migration away from many stovepiped “little m2m” solutions to a larger, more mature “BIG M2M” solution set as we evolve to the vision that is the Internet of Things. One of the primary scenarios to investigate then is the producer/consumer model of “many to many” data relationships.  
+
| description = Solutions to scenarios 001 and 002 soon result in the business discovering that although the company is monitoring and managing increasing temperatures, the data could also provide valuable information and insight to other business units. It might also be discovered that other business units may have been able to provide input into the “application” that could help in the overall solution. For example, an upcoming sale will increase the level of activity so proactively decrease the temperature in anticipation of the event.  
  
Real success will be determined when these capabilities can be built directly into the end device with associated standards, tooling, frameworks, and services that can aid devices manufactures getting to market quicker, and more importantly, businesses being able to access the data easily, when they want it, where they want it.  
+
Because the original regional office application which was polling the freezer units did not anticipate having to share the data with multiple data consumers, the application developers and IT architects will have address sharing and access of the data  by unanticipated new consumers and providers. They soon realize that writing additional application code for the regional office will unexpectedly require additional firmware having to be developed for the freezer control units. They now need to recommend that the cost effective to replace both the application and the freezer unit code to meet new and future business requirements.
  
Although message oriented middleware (MOM) infrastructures have been prevalent in IT architectures for many years, the adoption within the embedded/M2M community have been very limited. Using proper MOM technologies, M2M can break the viscous cycle of protocol development and let developers focus on value add functionality.
+
| rel_scenario1 = 0001
 
+
| rel_scenario2 = 0002
MQTT is a Publish and Subscribe middleware that is squarely targeted at the M2M solution space. Instead of the historical, 2-tier poll response protocols of the past, MQTT provides a robust 3-tier architecture that separates the data transport from the data delivery along with other numerous advantages.
+
 
+
By incorporating MQTT into M2M architectures, the first benefit is that an automatic “many to many” data relationship is established. In the M2M-Problem-0003 statement we examined the problems encountered when tying a remote application directly to a host application via a “protocol”.
+
 
+
With MQTT, a data broker is used in lieu of any host application and a “Publish”/”Subscribe” paradigm is used to deliver data to any interested data consumer. Using the same example as given in the Problem statement, let’s assume a process variable from a sensor is interesting data to several applications (App#1, App#2, App#3) in addition to the operational SCADA application. All four data consumers can simply “Subscribe” to the topic that the sensor is publishing the data on. As soon as the Publish message is delivered to the MQTT broker, all four consumer applications will receive the message. No application development or configuration is required for this “many to many” distribution of data. MOM systems can adapt to new data producers without effecting existing applications. Remember that in the problem statement the SCADA host be aware of this requirement and add the overhead of polling for the new data (even if it was not interested in this data point). With MOM architectures, new, interesting data can be added to and subtracted from the system on demand.
+
 
+
An important benefit that is also realized from this architecture is the application separation between the data producers and data consumers. Applications interested in say “temperature readings” can simply subscribe to the temperature topic. The consuming application does not have to know anything about the producing application.
+
  
 
| rel_problem1 = 0003
 
| rel_problem1 = 0003

Revision as of 21:22, 23 July 2012

M2M Scenarios

The Machine to Machine (M2M) space combines systems from the embedded space and the enterprise/cloud space. This page catalogs example scenarios from the M2M space that capture combined overall M2M system requirments that may not traditionally exist in either the embedded space or the enterprise/cloud space.

Scenarios are intended to be high level descriptions which are characteristic of M2M business needs. The goals of this scenario work are to:

1) Document key needs obstacles, and inhibitors, both technical and market based, that the Eclipse M2M community can address with architecture and projects.

2) Document requirements to be addressed by follow-on architecture and open source project deliverables

It is expected that specific M2M Problem Descriptions will reference these scenarios, identifying technical issues and requirements.

Together, the problems and scenarios are also meant to serve as an educational tool for designers, developers and architects who are new to M2M and as a reference during development of M2M technologies at Eclipse.

M2M Scenario Description Template

Please refer to this template documentation.

M2M Scenario Descriptions

M2M-Scenario-0001 - Food Refrigeration Unit Failure

A regional office for a food store chain wants to detect increasing temperatures in their store's meat freezers and delivery vehicles. Upon detecting that the temperature has increased above a specified threshold, a group of analytic processes will access the system for additional data such as the customer activity level (indicator of the doors opening and closing a lot), on/off cycle frequency of the refrigeration compressor, and the recent history of refrigerant temperature values. Based on the outcomes of the analytic processes, a root cause will be determined and appropriate actions to remedy the situation will be started: maintenance technician dispatch, notification to store manager, re-supply, etc.

Related scenarios

  • None.

Referenced by problems





M2M-Scenario-0002 - Food Refrigeration Unit Zone Control

A regional office for a food store chain wants to control and monitor temperatures in each freezer unit within a store. There are many freezer units within each store and many stores within the region. The freezer units are controlled using a legacy point-to-point, request-response, serial protocol from an embedded computer. The embedded computer can simultaneously communicate with many freezer units, up to the maximum number of onboard serial ports. The embedded computers are connected to the in-store network and accessible from the regional office.

Related scenarios

  • None.

Referenced by problems





M2M-Scenario-0003 - Fitting Refrigeration Unit Information Into a Multiple Producer/Consumer Model

Solutions to scenarios 001 and 002 soon result in the business discovering that although the company is monitoring and managing increasing temperatures, the data could also provide valuable information and insight to other business units. It might also be discovered that other business units may have been able to provide input into the “application” that could help in the overall solution. For example, an upcoming sale will increase the level of activity so proactively decrease the temperature in anticipation of the event.

Because the original regional office application which was polling the freezer units did not anticipate having to share the data with multiple data consumers, the application developers and IT architects will have address sharing and access of the data by unanticipated new consumers and providers. They soon realize that writing additional application code for the regional office will unexpectedly require additional firmware having to be developed for the freezer control units. They now need to recommend that the cost effective to replace both the application and the freezer unit code to meet new and future business requirements.

Related scenarios

Referenced by problems