Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "IoT/M2MIWG/M2M Scenarios"
(Added M2M Scenario 0003) |
|||
| Line 38: | Line 38: | ||
| rel_problem1 = 0002 | | rel_problem1 = 0002 | ||
| + | }} | ||
| + | |||
| + | {{M2M_Scenario | ||
| + | |||
| + | | identifier = 0003 | ||
| + | |||
| + | | name = Providing SCADA Sensor/Actuator Information to multiple Producers/Consumers | ||
| + | |||
| + | | 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. | ||
| + | |||
| + | 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. | ||
| + | |||
| + | 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. | ||
| + | |||
| + | 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 | ||
| + | |||
| + | |||
}} | }} | ||
Revision as of 18:43, 2 July 2012
Contents
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 - Providing SCADA Sensor/Actuator Information to multiple Producers/Consumers
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.
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.
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.
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.
Related scenarios
- None.
Referenced by problems