The Tower of Babel: Machine-to-Machine (M2M) and Sensor Networks
From SCInterface Wiki
The following is a brief whitepaper on issues related to disparate types of M2M and sensor networks and solutions for managing them. Please contact us with any questions.
Download PDF Version (Adobe Acrobat 6.0 Reader or higher required)
Contents |
Since the Beginning
The Tower of BabelFor the last few decades, sensors have become more and more present in day-to-day operations. There are now countless varieties of sensors and sensing devices available on the market. Historically, vendors have created ways to access the data from sensors by creating sensor networks. These sensor networks did not have standards in place for communicating with one another. Each vendor essentially had their own proprietary protocol to govern the transactions that occurred. For the vendors that created these proprietary protocol networks, they served as a means to capture and ensure market share. However, these disparate sensor networks represent a great challenge for integrators by restricting freedom and flexibility of choosing the best solution for the end-user.
Initially, proprietary protocols were acceptable since the sensor networks were not as common as they are today. Advancements in technology has developed sensors that are more cost effective, smaller and feature rich than their predecessors. However, these advancements did not come without a cost. Each sensor required configuring and deploying a separate network for a particular vendor. These networks would be accessed in similar, yet different ways. The sensor networks would lack the ability to work together, and thus the analogy of the Tower of Babel. Many sensors often work well by themselves; however, they cannot pool resources since they cannot co-exist within the same network. Essentially, sensors speak different tongues or protocols. As large scale Machine-to-Machine (M2M) and sensor networks become more popular, there have been mainly two options available to address these issues: standards and meta-protocols.
Option #1: Standards
Option 1 - StandardsTraditionally, the first option has been to create a standard protocol. The limitations and implications are similar to what they were with proprietary protocols, except that these protocols are open or non-proprietary. The standardized protocols are customarily designed with a more generic use in mind and as a general rule are considered future-proof. Furthermore, this non-proprietary approach provides greater competition in the marketplace. In a world previously dominated by a few players, a shared protocol opens the playing field by creating a low barrier to entry and plenty of room for innovation and encouraging competition.
In most cases, standards are regulated by a governing body. This governing body regulates the implementation of a standard protocol. The standard protocol is used by vendors in order for them to interoperate. In a way, this is a switch from a monopoly to a cartel. Vendors are still required to conform to a specific implementation, however, a standard protocol creates more latitude for disparate network integration. Since this approach is similar to the proprietary version, there could be standards that cannot work together. Sensors still need to implement this protocol as well as control systems that manage them.
Option #2: Meta-protocols
XML WrapperThe second option has been to create a meta-protocol. In this implementation, a protocol would be created with the goal of being generic enough to be able to encapsulate functionality from different sensor protocols. Meta-protocols achieve this functionality by using a translator between the sensor and the user interface. On a given implementation of this meta-protocol, an integrator could install sensors “speaking” their own protocol as long as there is a translator to bridge the communication between the sensor and the network.
Extensible Markup Language (XML) is an example of a language that can implement a meta-protocol. XML provides an ideal framework to encapsulate sensor data from various types of sensors. Assuming a user interface “speaks” this new XML meta-protocol, nearly any type of sensor can be controlled from anywhere through any interface. The XML alleviates the requirement to use sensors with a specific proprietary or standard protocol and allows various types of sensors interoperate within the same environment. XML Translator
Meta-protocols do appear to be the most attractive medium. However, they do add some complexity. The meta-protocol must be maintained with the latest updates from the developers of the supported protocols. Meta-protocols provide a strong solution for addressing the Tower of Babel within sensor networks; however, the methodology used to add or modify support for protocols will make or break a given implementation.
Learn more about solutions for disparate M2M and sensor networks at http://sensors.scinterface.com.
About Netarus
Netarus, LLC is a software development firm located in Virginia Beach, Virginia. We provide a diverse array of smart products and innovative services for web-based control and management systems.
Netarus, LLC
Download PDF Version (Adobe Acrobat 6.0 Reader or higher required)
