The typical architecture of IoT solutions is usually far more complex than the architecture of most enterprise systems. One of the main factors that increases the complexity of IoT systems is that backend services residing in the data center, which is the heart of most enterprise systems, are actually just a piece of the bigger IoT picture. With IoT solutions, we have to deal with a myriad of devices working in the field. Because the nature of these devices is very different from web, desktop, or even mobile clients, we need an intermediate architectural element that will act as a proxy between the world of field devices and the enterprise data center. What we need is an IoT gateway.
WHY YOU NEED AN IOT GATEWAY
You may be wondering now: what exactly are the key reasons behind introducing a gateway into your IoT architecture? Let me shed some light on this issue by discussing some of the most important aspects of how gateway architecture functions.
First, sensors usually have very limited capabilities in terms of networking connectivity. Your sensors can likely utilize Bluetooth Low Energy (BLE), just as the majority of beacons available on the market can; there is also the possibility that some of your sensors offer connectivity using the ZigBee protocol. There are also a bunch of other protocols that can be found in the Local Area Network (LAN), Home Area Network (HAN), or Personal Area Network (PAN). All of these protocols have one thing in common—they can’t directly connect to larger networks like Wide Area Network (WAN) or the Internet. You need a gateway that can provide your sensors with a single point of contact with external networks by using WiFi, GSM, or some other type of connectivity.
Keep in mind that a gateway is not just a dump proxy that forwards data from sensors to backend services. Sending all the information collected by sensors to a data center would be highly ineffective in terms of performance and network utilization. An IoT gateway is needed to perform the pre-processing of information in the field, before they’re sent to the data center. Such pre-processing includes message filtering and aggregation.
The gateway should also act as a single point of access for monitoring the selected area of the operational field. You don’t want to connect to every sensor with your monitoring software; it is easier to monitor only the gateway, which in turn is responsible for gathering all the necessary metrics from the sensors.
The following gateway architecture diagram is the most common architectural design where the gateway itself is not equipped with sensors. The gateway software installed on the device is responsible for collecting data from the sensor, pre-processing that data, and sending the results to the data center.
Keep in mind that it is possible to have variations on this sensor architecture where some of the sensors are located at the gateway device, as illustrated in the following diagram.
Embedded sensors that might be present at the gateway could include options like a GPS unit or a temperature sensor connected to the gateway using the GPIO interface.
THE GATEWAY SOFTWARE
The software application is the heart of the gateway. The gateway software is responsible for collecting messages from the sensors and storing them appropriately until they can be pre-processed and sent to the data center. The gateway software decides if the data at a given stage of processing should be temporary, persistent, or kept in-memory.
The gateway software should be designed with failure and disaster recovery in mind. Since gateway devices are often operated in the field, you should prepare for working conditions that are far from ideal. For example, the gateway software should be prepared for a power outage or other actions that may result in an interruption of gateway processing. The gateway software should be bootstrapped and started automatically as soon as power returns to the device, and it should continue to work from the point where it was interrupted.
Gateway software should also be smart enough to properly handle system logging. It has to find the right balance between the number of log entries stored on the device and those sent to the data center.
You can read the whole article here.