M2mi Blog Why You Should Distribute Your Intelligence to the Edge

As M2M and IoT is slowly evolving from an anticipated hype to a market with real customer traction, a company willing to benefit from its promisses will be faced with a series of challenging questions. These questions range from 'How will I connect my devices to the network?' to 'How will I make/save money?'. Fortunately, M2M and IoT Platforms are there to help. But one Platform is not the other, and choosing the right Platform can be key to a successful M2M and IoT deployment. One important aspect in which Platforms differ is how and when the data from devices is collected, processed, and considered 'in' the Platform. Some believe in the 'centric' approach where devices communicate directly with cloud machines. In this scenario the perimeter of the Platform is well defined and static, and all the value is generated at the core of the architecture. Others, like us at M2Mi, believe in the 'edge' approach where some of the intelligence is distributed or de-centralised to the edge of the network. While there is certainly no 'one size fits all' in M2M and IoT, in this blog post I would like to discuss some of the benefits of choosing the 'edge' approach over the 'centric' one. Cost: Not all the data produced by devices contains actionable value. Consider a smart sensor that records and sends the temperature of a room every minute. The temperature will likely be constant over say a one hour period, and most of the data produced by the sensor will be of no value. In this scenario what really matters to the operator of the sensor is to know when the temperature has changed, or when it is above a given threshold. Separating the 'signal' (the insight) from the 'noise' (the raw data) as close to the sensor as possible will drastically reduce the load on the network as well as the amount of data that must be processed and stored in the cloud. This, in terms, can strongly reduce costs. Security: One of the challenge in securing an M2M and IoT eco-system is that the surface to protect is huge en dynamically changing: every device is a potential entry point to your infrastructure. Try to picture your eco-system as a medieval city you are trying to protect (an arguably limited and simplistic analogy). Having a centralised intelligence at the core is a little like asking every person entering the city to register and identify themselves at the city hall. There is no guarantee that a person will do so, and once a 'bad' person is within the city everything is possible. On the contrary, distributing your intelligence at the edge can be seen as forcing people to enter the city through a set of doors where their intentions will be checked. If all goes well you will detect 'bad' guys before they step a foot in your city. Furthermore, you may know that people from the 'west' use the western door and using this contextual information (e.g. all people from the west are small with black hair) may help you decide if a person should be allowed to enter your city or not. Speed: Not all devices are part of a close-loop system where data may trigger an immediate reaction. But there are certain situations where you need to take immediate action, and the latency of this reaction may be critical. Think of a connected car for example on-boarding hundreds of sensors and interacting with other vehicles on the road, or an airplane that must react to a rapidly evolving environment. In these scenarios making the decision as close as possible to the source can save precious milliseconds. Flexibility: The spectrum of M2M and IoT use cases is extremely large; you have many different devices, sending data of many different format, over many different protocols, and this data is consumed by many different applications, each expecting his own message format. This complexity demands an architecture that can abstract the ingestion of the data from its utilization by applications. And this abstraction layer must be built in such a was as to rapidly accommodate new use cases and deployments. A distributed system where the edge node abstracts the ingestion of the data is an architecture that can provide the required flexibility. To conclude, let us note that the term 'edge' must be understood in a broad sense: the edge could be the devices themselves, an on-premise gateway connecting a group of devices, or even a machine in the cloud. The right flavour will be dictated by the use cases, but in every situation there will be value in distributing intelligence to the edge.Read More