End-to-End IoT Monitoring with Log Data - Part 1
End-to-End IoT Monitoring with Log Data - Part 1
Join the DZone community and get the full member experience.Join For Free
A recent blog explored the importance of logging in general in terms of IoT devices. It also cited predictions that a huge number (50 billion) of IoT devices are expected to exist by 2020. While Machine to Machine(M2M) communication is a related area, the IoT is all about extending the Internet to systems and even low power devices.
While there is uncertainty about the exact nature of how these devices will be networked and how their data will be used, there is no doubt that huge opportunities exist. This blog will develop some of these themes, and introduce some of the technical developments in IoT with a view to exploiting them. Part 2 will illustrate these points with some simple example code to interact with Logentries.
Log and Sensor Data
In our earlier post we claimed that Logs and IoT as being “two peas in a pod.” We find this to be true because:
- the nature of the data. IoT (particularly sensor) data is generally timestamped and appears in a range of formats. This is shared by the various structures or ad-hoc structure of log data. IoT data may also appear as a stream of data, such as a video feed.
- low power sensor devices generally exist in a Wireless Sensor Network (WSN) and require a gateway node to upload data and apply policies related to that site. Similarly, data can be aggregated on a customer site before being sent to a shared log store.
- the devices are not the right place to hold the data for analysis (even if they could), as there is a value to storing this data in a shared store for aggregation and analysis. This applies to Log Data as the value is often not simply found in the data on one server, but by examining logs across servers.
- the volume, variety and velocity of sensor data makes a cloud based solution suitable, as it is for log data.
In terms of requirements, IoT systems require the ability:
- to gather, process and store all the data from a wide range of different of sensors
- to produce alerts on certain conditions being detected in the incoming data
- to analyse or view historical data with incoming sensor data
Again, this is similar to the requirements of a log system. As an illustration, the following diagram shows how the Logentries DataHub can be usedto collect logs on a customer site and send them to Logentries. If I replace “Datahub” with “WSN Gateway”, “Webserver” with “IoT device” and “Logs” with “Timestreamed Sensor data”, then I think the similarity is clear.
What areas will IoT be valuable?
Where do we begin…?
- Automotive – engine sensors reporting data to the manufacturer enabling pro-active setting up of services.
- Healthcare – patient monitoring will be enhanced by the use of wireless devices removing the inconvenience and dangers of wired devices, allowing greater patient freedom. As part of an end-to-end system, this will earlier discharge from hospitals and greater patient freedom or allow greater personalised fitness monitoring as with the wearable watch type products from Apple and Samsung.
- Smart City/Planet -a recent IBM example allows citizens to report Ebola-related issues and concerns through SMS or calls to a big data analytics system. This creates opinion-based heat maps that correlate public sentiment to location information so resources can be targeted. Other examples can be found here including the example of Songdo, South Korea in our earlier blog where almost everything in the city will be connected.
- Smartgrid - smart meters across a large area send a lot of data. This requires analysis in pseudo real-time, e.g. for security checks, but it also creates a set of historical data that can give value, e.g. showing usage trends at times of the year.
- M2M – interaction between machines and sensors on a factory floor, e.g. GE Durathon Battery factory made use of this to improve manufacturing processes and generates over 10000 data points per second.
- Logistics – tracking trucks, estimating their arrival at destinations and using this data for optimizing routes.
Other areas include environmental monitoring, logistics, people-centered sensing and a large number of possible use cases are discussed athttp://www.wired.com/2013/05/internet-of-things-2/all/
Why is now a good time to consider IoT?
WSN devices have been around for a while and we haven’t seen huge growth yet, in spite of previous predictions, e.g. it is worth noting that The Economist’s article “When Everything Connects” is from 2007. This is partly due to the fact that much of the focus to date has been on the cost, performance and reliability of the devices and Wireless Sensor Networks themselves. There are, however, a number of reasons that suggest this promised growth in IoT is not far away:
- development of wireless protocol standards such as Bluetooth Low Energyhttp://www.bluetooth.com/ and IEEE 802.15.6 Body Area Networkhttp://standards.ieee.org/findstds/standard/802.15.6-2012.html . Importantly, chip-sets to support them are also available, e.g. the TI range of microcontrollers and wireless chips at http://www.ti.com/ww/en/internet_of_things/iot-products.html
- use of IP (and especially IPv6) on wireless devices and the emergence low power routing protocols such as RPL, the IPv6 Routing Protocol for Low-Power and Lossy Networks
- experience gained deploying Wireless Sensor Networks and improving the lifetime of the devices, along with adoption of Zigbee zigbee.org and application profiles
- application layer protocols such as MQTT and especially the Constrained Application Protocol (CoAP) using lessons learned from the development of the Internet and the use of REST APIs making device environments more familiar to developers
- a greater range of devices, with richer SDKs and development kits emerging, e.g. Intel’s Grove https://software.intel.com/en-us/iot, Shimmerhttp://www.shimmersensing.com/. The range and nature of OSs available (Contiki, TinyOS, proprietary ones from TI and ARMhttp://www.arm.com/products/IoT-device-platform.php) does, however, make the choice of platform and development on those platforms more difficult and specialized.
- industry supported initiatives such as the IPSO alliance http://www.ipso-alliance.org/ which promotes the use of the Internet Protocol within IoT and M2M applications and defines a set of appropriate protocols, architecture and data definitions for Smart Objects
So progress is being made on frameworks to enable IoT devices to wirelessly connect and overcome the often limited processing capabilities and limited connectivity (to conserve battery life) of those devices.
The key point is that what is needed now are end-to-end architectures and services that can actually gather and analyze this data at scale and relatively easily. This is necessary to support the growth of new devices and particularly new use cases and applications, without requiring unduly large cost or risk.
What this means for IoT End-to-End?
One approach to handling the range of input IoT data is to try to standardize and normalize the diverse data inputs for storage using application domain knowledge or standards and semantic processing, e.g. some research projects are looking at using RDF type approaches to do this .
Another approach is to accept the diversity of devices and use an infrastructure that can handle such diversity and provide visualisation of, and analytics on, that data. This would use tools from the Big Data area to build a solution to handle the scale and diversity. A recent article on Kafka gives an overview of IoT and an example of the role Kafka could play along with other big data solutions. It shows the potential of such solutions for those with the resources and time to pursue this. A more academic example of an architecture using HBase to gather IoT data is shown athttp://www.cs.ucc.ie/~cjs/docs/2013/dpmss2013.pdf
The relative immaturity of standards in this area and the diversity of devices (and commercial interests) mean that it is not clear which protocols or formats will emerge as de facto standards or what will be killer applications. Hence, IoT developers, users and applications need systems that can handle a changing range of protocols and data formats at large scale. This means that the two approaches above are not ones I favor at this point.
The similar characteristics of log data and IoT data suggested above does, however, mean that a flexible cloud based solution for logs is a good choice for sensor data too. This is even more sensible when we consider that the IoT community and early stage developers can benefit from the cost savings and convenience of using a log service shared by a large number of existing log users. It will also allow them to use the analysis and visualization tools of that service to allow them to explore their IoT application area and products more quickly, which is vital given the early stage of development of this area.
I hope that I have shown the potential of IoT and why a cloud-based logging service can play a role in enabling IoT applications. The next part of this blog will build on this by introducing the Constrained Application Protocol (CoAP) and illustrate how it could be used as part of loading sensor data into Logentries.com.
Published at DZone with permission of Trevor Parsons , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.