M2M : Machine 2 Machine

The picture of a future with wireless sensor networks-webs of sensory devices that function without a central infrastructure–is quickly coming into sharper focus through the work of Los Alamos National Laboratory computer scientist Sami Ayyorgun.

Proponents of this new technology see a world with deployments to improve a wide range of operations. Engineers could wirelessly monitor miles of gas and oil pipelines stretching across arid land for ruptures, damage, and tampering. Rescue workers might detect signs of life under the rubble of a collapsed building after an earthquake, thanks to a network of sensors inside the structure. Armed forces could keep an eye on a combat zone or a vast international border via a sensor network that could promptly provide alerts of any intrusion or illicit trafficking.

“It’s not easy to envision the impacts that sensor networks will make, both socially and economically,” Ayyorgun said. “Like many other researchers, I think they are likely to rival the impact that the Internet has made on our lives.”

Ayyrogun has developed a new communication scheme that brings the reality of these and other applications a step closer. He has shown for the first time that concurrent gains in many measures of performance are possible, including connectivity, energy, delay, throughput, system longevity, coverage, and security.

In recognition of the multifaceted improvements Ayyorgun’s research makes on state-of-the-art technology in this field, his recent paper, “Towards a Self-organizing Stochastic-Communications Paradigm for Wireless Ad-hoc/Sensor Networks,” has been nominated for the Best-Paper Award from a pool of more than 250 manuscripts at the International Conference on Mobile Ad-hoc and Sensor Systems (MASS) of the Institute of Electrical and Electronics Engineers (IEEE).

Ayyorgun will present the paper at this prestigious meeting of the IEEE beginning September 29, in Atlanta, Georgia.

Like cell phones, wireless sensor networks depend on small, independently powered devices, often called motes, to communicate. But unlike cell phones, which always relay their signal through a base station such as a tower, multihop sensor motes use each other to relay signals, transmitting communiqués through a series of “hops” from one mote to the next. Without the need to build a mesh of base stations that must be wired or have a substantial supply of energy, creating information-bearing ad-hoc networks to suit each unique set of circumstances would significantly reduce costs.

In the past I had come across this open source M2M software platform. I meant to do a write up on this but got delayed due to a variety of reasons. I still have not done a write up but here is the input on Mango M2M that I received from Matt  - Thanks to Matt for providing this write up..

Users first create “data sources”, which are typically based upon a protocol (currently Modbus, but others will be bundled with coming releases). Data sources define “points”, which are representations of single pieces of dataand are configurable in many ways including data logging, text rendering,and chart rendering. (There are two pages to view: data point details - readonly - and data point editing.) Both of these objects allow user permissionsto be set in very granular ways. These points can be monitoring on the”watch list”, or users can build graphical views using drag-and-dropfunctionality on uploaded background images.Users could stop there and only use the system for manual monitoring,
control, and data logging, but the automation power of Mango is in the event subsystem. Events are split into two parts: the detection and the handling. These parts can be arbitrarily paired in a one-to-many fashion, and can also be chained.

An event detector can be something like a high limit (for analog data) or a
binary/multi-state state. For example, you can define conditions such as
“when the humidity exceeded 60% for more than 1 hour”. (Conditions depend on
the data type of the point, so you will not see all of them on a single
point editing page. I can provide you with a list if you are interested.)
There are also hard-coded event detectors for data source exceptions, system
exceptions, and other things like new Mango version notifications.

On the handler side, users decide what should happen when an event is
raised. Currently there are two handlers: email notification and set point.
When the event is raised, email notifications are sent to specified email
addresses, users, or mailing lists. Optionally, if an event is still active
at some timeout, the event can also be sent to an escalation list. Finally,
upon event deactivation, notifications can optionally be sent to all event
participants.

The set point handler allows the user to define how a point should be set
upon the raising of an event. This is how conditions can be chained
together.

There are certainly pieces of functionality that should be added to the
system - and Serotonin has plans to do so - including new data sources,
“meta” data points, scheduled events, inter-Mango communication, a scripting
language, multi-point event detection, etc.

*** End of Overview ***

On to your questions:

A> What does Serotoninsoftware.com do?
Serotonin Software comes from a software development and consulting
background, mostly in the web development vertical. We started building
Mango mid-last year because we found the concept of an Ajax-based controls
system too compelling.

B> What was the driver behind starting this company?
I’ll assume that given the above you mean Mango. In addition to the geeky
answer above, there were a number of other reasons, including personal
usage. But based on market research we found that there was an obvious
opportunity in the industry for a product like Mango. Every other product
that we are aware of suffers from at least one of the following problems:
- Too expensive
- Too complicated
- Assumes too much prior knowledge from the users
- Uses old technologies that do not adapt to modern application standards
- Depends upon “closed” or proprietary technologies

Mango was created specifically to bring powerful controls technology to
technical and non-technical people alike. Every aspect of Mango - the user
interface, the integrated architecture, right down to nomenclature - was
carefully considered to appeal to the widest possible range of users. As
someone said, we aim to be the Google of the controls market.

C> Who do you see as your customers?
Mango is very generalized at the moment. Marketers that we speak to
inevitably suggest that we should be targeting a specific vertical. We will
likely address this by creating customizations of Mango (”mango salad”?,
“mango grove”?, “mango tarts”?), but for the moment we are deliberately
casting a wide net. We understand that there are risks in doing so (i.e.
being ignored my potential users in specific verticals), but the feedback
that we are getting is helping us determine our next moves.

D> What are the some of the challenges that you see in the M2M Space?
Challenges in general, or for Mango? In general, the controls industry is
expensive, proprietary, and evolves at a rate that is, compared with the
internet, glacially slow. With Mango we want to bring the mentality of the
internet to the controls space, i.e. open standards, collaborative
development, easy access to information… all of it. It’s a tall order for
a small company in a massive and entrenched industry, but we think that it
will inevitably happen anyway and we’re excited to be a part of it.

E> Anything that you would like to share with our readers?
Mango is now slightly over two weeks old (i.e. since release), and we are
very encouraged by the response we have received. There is a great deal of
work still to do, though, to bring the product to where we really want it to
be. Early adopters who get involved in the Mango community have the
opportunity to strongly influence its development. Now is the time to get
involved!

Why is M2M good for cellular carriers?

Handset churn rate - 20-30%

M2M telemetry devices churn rate - 5% with no subsidy (e.g no $200 free phone)

Source - Harbor Research

Results from a year-long study on high-tech electricity meters found smart grid technology performed as intended, saving consumers about 10 percent on their bills while easing strain on the power grid.

The Department of Energy’s Pacific Northwest Laboratory on Wednesday released the findings from its GridWise project, which tested the use of Internet-connected thermostats and other controls in 112 homes in the Seattle area.

Consumers also tried out appliances, like water heaters and dryers, that were able to automatically change their settings according to signals sent by the utility over the power grid.

The trial showed that consumers are willing to have utilities remotely dial down the appliances to lessen the load on the power grid and reduce their consumption, said Rob Pratt, program manager at Pacific Northwest National Lab.

These changes could be as small as turning off the heat on the dryer while it continues to tumble for a few minutes. But those minute-to-minute adjustments, driven by the fluctuating demand on the power grid, can have significant benefits to utilities.

“We could save $70 billion in investments in the next 20 years by offsetting construction of new infrastructure that would otherwise be needed to meet load growth,” Pratt said during a teleconference with the media.

Smart grid technology would also provide more reliability to the power grid, allowing utilities to isolate problems more easily. Clean power sources such as wind and solar, which pose technical challenges because they don’t supply a steady stream of electricity, can be better incorporated with upgraded equipment, the study found.

The electricity infrastructure in the United States needs significant investment to be modernized, according to industry analysts. But utilities tend to be very conservative and unwilling to make large capital expenditures on new equipment.

My search continues for products that provide a bundled standalone package of - sensor, power and communication in a stand alone / low maintenance environment. In an ideal deployment the sections on concern in any module are
* Sense - How do I measure the the operation that I am monitoring?
* Power - How do I power this so that it is reliable, long term and low maintenance
* Communicate - How do I communicate this information back.

This combination forms the front end of any M2M application - the piece of hardware/ software that is deployment in the field next to you asset/ process under that is being monitored. In one of my previous posts I pointed out enOcean that provides a packages all the above elements. Another Control Microsystems provides a similar bundle SOLARPack 410, an integrated, ultra low power flow computer for electronic flow measurement (EFM). The SOLARPack 410 features a compact, all-in-one design that integrates a powerful 32-bit flow computer, high accuracy temperature and pressure sensors, ultra low power solar battery system, and wireless Bluetooth communications for quick and easy retrieval of production and transmission data. Designed for use in remote locations where solar is the only power source and access by technicians is limited. The type on sensors on this box are very specific to the metering application but you get the point of a one box end point.
Vendors providing these endpoints will be a critical part of the M2M ecosystem. If these end points are unreliable then the whole value prop of M2M and smart services goes for a toss…