I once heard the internet of things referred to as a cyber-physical system. This really hit home for me, as it encapsulated everything I understood it to be but had not yet found a way to articulate. It described the system as one which relies on actuators and sensors to automatically collect data from the physical world and synthesize it digitally — faster and more accurately than humanly possible. Describing it this way emphasizes the fact that an IoT solution is indeed a system — a set of components that all need to work together to provide any value. It captures how everything is physically connected and needs to be secured, monitored and controlled as data is sensed and processed 24 hours a day, 365 days a year.
One could compare IoT to the human body’s nervous system which collects information from the senses via nerves, processes the information in the brain and then tells the muscles what to do. Different tiers in the IoT system similarly have specific functions, such as data collection, information processing and action management. Yet each layer or tier of the system’s architecture needs to integrate and communicate with the others, something that can be facilitated through the use of open source software.
What are the layers of an IoT architecture?
The Eclipse Foundation’s IoT Working Group recently discussed this at length in the white paper, “The Three Software Stacks Required for IoT Architectures.” The IoT technology stack consists of three tiers: sensor devices, gateways, and the data center or cloud IoT platform. As explained in the paper, “a typical IoT solution is characterized by many devices (i.e., things) that may use some form of gateway to communicate through a network to an enterprise back-end server that is running an IoT platform that helps integrate the IoT information into the existing enterprise.”
The device tier focuses on information gathering via sensors. Because sensors are so tiny and inexpensive, they can be embedded in many different types of devices, including mobile computing devices, wearable technology, and autonomous machines and appliances. They capture information about the physical environment, such as humidity, light, pressure, vibration and chemistry. Standards-based wired and wireless networking protocols are used to transmit the telemetry data northbound from the device to the gateway. Northbound data, if you remember from my previous post, is data going from the device through the gateway up to the cloud. It is typically telemetry data, but can be command and control requests. Southbound data, on the other hand, is generally command-and-control data that goes from the cloud to the gateway or from the cloud, through the gateway, to the device.
The gateway, sometimes referred to as the control tier, acts as an intermediary that facilitates communications, offloads processing functions and drives action. Because some sensors generate tens of thousands of data points per second, the gateway provides a place to preprocess the data locally before sending on to the data center/cloud tier. When data is aggregated at the gateway, summarized and tactically analyzed, it can minimize the volume of unnecessary data forwarded on. Minimizing the amount of data can have a big impact on network transmission costs, especially over cellular networks. It also allows for critical business rules to be applied based on data coming in. The control tier is bidirectional. It can issue control information southbound, such as configuration changes. At the same time, it can respond to northbound device command-and-control requests, such as a security request for authentication.
The data center/cloud tier performs large-scale data computation to produce insights that generate business value. It offers the back-end business analytics to execute complex event processing, such as analyzing the data to create and adapt business rules based on historical trends, and then disseminates the business rules downstream (southbound). It needs to scale both horizontally (to support an ever growing number of connected devices) as well as vertically (to address a variety of different IoT solutions). Core functions of an IoT data center/cloud platform include connectivity and message routing, device management, data storage, event processing and analysis, and application integration and enablement.
Just like any system, it all needs to work together
Think of an IoT implementation as a living, breathing entity that uses its senses to see, hear and feel the environment. If information derived from a finger says something is too hot, it needs that information to be delivered quickly to the brain so the hand can be pulled back. In order for an IoT solution to work, all the software, hardware and networking components need to interoperate and communicate seamlessly. As pointed out in the IoT working group’s white paper, “communication between the stacks should be based on open standards to ensure interoperability.”
It can be very difficult to make an IoT solution work when dealing with independent siloed applications designed by a single vendor. The vendor may not have all the components required and may not interoperate with a required piece to the puzzle. The Eclipse IoT community offers open source solutions that provide the capabilities that each tier in the architecture requires; a complete stack for constrained devices, gateways and IoT cloud platforms. They even offer cross-stack functionality. Red Hat is pleased to be working with their community to bring these open source IoT technologies to fruition.
All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.