This article aims to focus on edge side of IoT Architectures where all things are. The edge is the place where all event data are generated and automated actions occurs, and because that it must be managed and secured. It also includes a wide array of sensors, actuators, and devices which interact and communicate real-time data each other and with cloud services.
Another aspect is as IoT grows ever larger, some capabilities such as data analysis and decision-making will have to localize, it means is shifting from the cloud to the edge.
Let’s see the big picture below to understand the main components of this architecture.
The diagram above shows the edge side and cloud side. In the edge side the things could be sensors, actuators, devices and a crucial thing called gateway. This gateway has the responsibility to establish communications between things and cloud services and also orchestrate the actions between the things.
The cloud side will not be covered on the this article (it will be subject on next article), but the IoT communication protocols between things and cloud services will be covered. Let’s explore each architectural component of this big picture.
The term edge come from Edge Computing where data are processed at the periphery of the network, as close to the originating data as possible. The edge can be a manufacturing floor, smart city, smart building, energy grid, oil rig, wind farm, dairy farm, planes, trains or automobiles
The key factor which makes the edge processing crucial is turn the data processing and action taking the most close to real-time. We could use as example a “smart car” which its environment is a kind of edge where a lot of sensors are generating all kind of data. Imagine one engine sensor is emitting overheating events, and based on this event, an engine actuator must take action to slow down the engine in order to prevent more overheating.
As we can see on this example, all event data generation, data analysis and taking action occurs at the edge. Of course, the edge architecture must provide cloud integration where in the fact full big data analytics can be applied.
Everything that lives in the edge are things, one of most common thing is called sensors. According with the book Foundational Elements of an IoT Solution, sensors read and report on the real-world status of connected products, machines, and local environments. They are the eyes and ears of the system, monitoring environmental elements like temperature, light, and moisture. Ongoing sensor innovation, an often-overlooked area of IoT technology, will be critical for evolving and improving solutions.
While we might think of sensors only as physical objects, anything that can be read, from files to product-specific data, can and should be considered sensor input. For example, a piece of industrial equipment may have hundreds of data points unique to that product, and every one of them could be considered a sensor. Examples of sensors include
Vehicle on-board diagnostics
There are other common edge thing which is called actuators. Them usually affect the electromechanical or logical state of a product or environment. They are the system’s hands and feet. Actuators might include a light that can be turned on and off, or a valve that can be opened and closed. Commonly actuators offers a set of APIs for its interaction.
System commands sent to embedded applications—such as remote reboot, configuration updates, and firmware distribution—should also be considered actuation because, by changing its software, the system is in fact changing the physical reality of a product. Examples of actuators include:
Commands (“soft” actions, file distribution, firmware updates)
Also, there are the devices living on the edge which is usually called as smart devices, the most commons are:
Mobile devices such as smartphones or tablet computers
Microcontroller units (MCUs) like Arduino devices
Single-board computers like Raspberry Pi devices.
At least, there are appliances (or gadgets) used in smart environments. They usually have a defined function, and can be controlled by human user interface. The example are:
Smart thermostats like Nest Thermostats
Smart lighting systems like Philips Hue.
IoT Smart Gateway
As illustrated in the diagram above, the key component of Edge IoT Architecture is what we call as Smart Gateway. This component is based on traditional IoT Gateway which the main responsibilities is act as a proxy between the world of field things and the enterprise data center, usually cloud based.
A main capability of IoT Gateway is enabling communication from the Edge to the Cloud. It means it must understand field protocols and convert it to cloud protocols. Later on this article, we will explore all theses protocols.
Another IoT Gateway feature is routing data to cloud based on simple rules. For example, a engine sensor emits temperature status each second but it is not relevant for an analytic application based on cloud which will process each minute gap. This kind of rule can be deployed in IoT Gateway to send the event to the cloud in every minute aggregation.
The concept of Smart Gateway comes from adding smart capabilities to traditional IoT Gateway which comes with basic features. Let’s explore each smart capability below.
Since sensors, actuators and devices are living at the edge, they must communicate each other and also with Smart Gateway. This kind of communication are based on field protocols, the most commons protocols are:
Bluetooth Low-Energy (BLE): The new Bluetooth Low-Energy (BLE) – or Bluetooth Smart, as it is now branded – is a significant protocol for IoT applications. Importantly, while it offers similar range to Bluetooth it has been designed to offer significantly reduced power consumption.
Zigbee: Like Bluetooth, has a large installed base of operation, although perhaps traditionally more in industrial settings. ZigBee PRO and ZigBee Remote Control (RF4CE), among other available ZigBee profiles, are based on the IEEE802.15.4 protocol, which is an industry-standard wireless networking technology operating at 2.4GHz targeting applications that require relatively infrequent data exchanges at low data-rates over a restricted area and within a 100m range such as in a home or building
Wifi: This type of connectivity is often an obvious choice for many developers, especially given the pervasiveness of WiFi within the home environment within LANs. It requires little further explanation except to state the obvious that clearly there is a wide existing infrastructure as well as offering fast data transfer and the ability to handle high quantities of data.
NFC: Near Field Communication (NFC) is a technology that enables simple and safe two-way interactions between electronic devices, and especially applicable for smartphones, allowing consumers to perform contactless payment transactions, access digital content and connect electronic devices. Essentially it extends the capability of contactless card technology and enables devices to share information at a distance that is less than 4cm.
The most of IoT solutions, even those ones live almost entirely on the edge need to integrate with cloud services or other IoT solution based on cloud. Since it is a requirement, we need to communicate using a cloud protocol as listed below:
MQTT: Message Queue Telemetry Transport (MQTT) was introduced by IBM in 1999 and standardized by OASIS in 2013 . It is designed to provide embedded connectivity between applications and middlewares on one side and networks and communications on the other side. It follows a publish/subscribe architecture, where the system consists of three main components: publishers, subscribers, and a broker.
AMQP: The Advanced Message Queuing Protocol (AMQP) is a protocol that was designed for financial industry. It runs over TCP and provides a publish/ subscribe architecture which is similar to that of MQTT. The difference is that the broker is divided into two main components: exchange and queues. The exchange is responsible for receiving publisher messages and distributing them to queues based on pre-defined roles and conditions. Queues basically represent the topics and subscribed by subscribers which will get the sensory data whenever they are available in the queue.
CoAP: The Constrained Application Protocol (CoAP) is another session layer protocol designed by IETF Constrained RESTful Environment (Core) working group to provide lightweight RESTful (HTTP) interface. Representational State Transfer (REST) is the standard interface between HTTP client and servers. However, for lightweight applications such as IoT, REST could result in significant overhead and power consumption. CoAP is designed to enable low-power sensors to use RESTful services while meeting their power constraints. It is built over UDP, instead of TCP commonly used in HTTP and has a light mechanism to provide reliability. CoAP architecture is divided into two main sublayers: messaging and request/response. The messaging sublayer is responsible for reliability and duplication of messages while the request/response sublayer is responsible for communication. As in HTTP, CoAP utilizes GET, PUT, PUSH, DELETE messages requests to retrieve, create, update, and delete, respectively.
HTTP: This is the standard protocol for web services and still will be used in IoT solutions, the overhead of this protocol is well know but we will continue use this protocol in some case when latency and bandwidth are not issues. We need also consider HTTP/2, other protocols such as Google Protobuf and even CoAP which are based on HTTP. The most popular architectural style called RESTFul is widely used on mobile and web application and must be considered on IoT Solutions.
Smart Gateway Architecture and Capabilities
The first capability to explore is called dataflow, this feature is the entry point which receive data from the things. It performs as inbound connector ingesting event sensor data using the field protocols as mentioned before, therefore must understand sensor’s protocols. Once data is received it begins an workflow which could apply some function like cleansing, transformation, composition or aggregation. Eventually, it should compose some command to be send back to the things.
Dataflow also must implements security constraints like thing/device authentication and prevent overload data attack. After entire dataflow was performed, it should start a routing flow, which some rules should be performed such as:
Data routing or send commands to the things using field protocols
Persisting data to storage system
Routing aggregated data to the cloud using cloud protocols (to be explained later in this article)
An example of dataflow and routing working together is a building temperature sensor emits each minute temperature data which is received by a Bluetooth connector and dispatched to dataflow. This data is analyzed by a function which contains a rule that implies the building air conditioning must be turned on, so the dataflow call a routing rule to send the command to air conditioning via ZigBee protocol. Also, the incident must reported to analytics system in the cloud, it means the dataflow must call a routing rule to call the analytics API hosted in cloud.
The storage system is responsible to store all configuration and runtime data. It means all persistent configuration data used by dataflow or routing flow is organized in databases. Also tracing and logging data is persisted here and it used to composite analytic data used by analytics and monitoring features which will be explained late. It is important to say that storage system has rules to decide if the data at a given stage of processing should be temporary, persistent, or kept in-memory.
The first operational feature is near real-time analytics which provide a set of analytics dashboards for low latency real-time monitoring and close to the devices without need to send all data to cloud to remote processing. This kind of feature is crucial because the IoT applications will be built on systems that can make intelligent decisions for operations on a moment’s notice. For example, real-time anomaly detection can help manufacturers adjust robots and equipment to optimize yield or identify potential defects as early as possible so affected units can be removed from the assembly line for rework. Read more about  Low Latency, Real-time Analytics at the Edge
Other crucial capability is the reactive monitoring feature, different from analytics which is passive, this feature should be reactive. It means when some event ou alert occurs some action should be take, it could be send an alert email or send a command to an specific device. This kind of feature also should offer a documented API to Monitoring Solutions easily use these APIs.
Finally, the platform needs a configuration console feature where operational and development teams should use to interact with the platform. In others words it means all capabilities listed above are accessed and configured by single user interface.
In fact, we believe which robust IoT architecture should consider the edge side must have strong capabilities. Some of capabilities such as analytics today run on cloud side but we need provide these features close to the things
We also believe in concept of smart gateway brings these strong capabilities to the edge and brings some independence from the cloud. The main capabilities should include protocols to communicate to the things and even cloud, it also must provide bidirectional data and command flow and finally, in the core of platform, the runtime and operational capabilities.
In short, our insight is push smart capabilities to the edge in order to achieve near real-time reactive IoT solutions turning it faster and cloud independent.