IoT solution architecture: an overview of components & design tips

An IoT architecture is a mix of hardware and software components that interact together to make up a smart cyber-digital system. Interoperating with one another, these components make up a base for an IoT solution to be built upon. Before we dive into the details, let’s get things straight: there’s no one-size-fits-all approach to designing an IoT architecture. Still, the basic layout stays largely the same no matter the solution.

Common data-driven IoT applications rely on a standard IoT architecture spanning four layers:

Recently, however, more and more connected systems have started shifting focus toward edge processing, which has led to an additional layer being added to a traditional four-tier architecture. The share of activities performed at the edge depends on a particular implementation but it commonly spans enabling connectivity, as well as filtering, aggregating, securing, and processing the incoming data.

So, an architecture for a common IoT solution featuring edge analytics could look like this:

The device layer comprises all kinds of smart, connected devices or non-electronic objects that are enhanced with cameras and/or sensors and, optionally, actuators.

Sensors take in data from the outer world and convert it into electrical signals so that it can be processed by a computer. IoT sensors vary in size and purpose. They are capable of recording all types of information — from temperature to motion to humidity, and more.

Actuators, in turn, make connected devices act upon commands sent from the processing center. Once an actuator gets a command, it makes a device behave in a certain set way. A smart lighting system, for example, could turn on the lights once a motion is detected nearby.

The network layer encompasses different communication technologies that connect the device layer and the subsequent layers of the IoT architecture. Depending on the IoT solution in question, device connectivity may be enabled directly or via gateways. The latter often applies to legacy devices that fail to be connected directly or when there’s a protocol mismatch.

Modern IoT solutions rely on the following communication technologies:

To get a better idea of what communication technology matches your solution, we’ve compiled a table summarizing a preferred use for each:

An edge processing layer consists of gateways, local servers, or other edge nodes scattered across the network. The idea behind introducing edge devices is to store and process data close to its source, only sending a part of the generated records to the cloud or bulk-uploading data to the cloud at preset intervals instead of transferring it in real time. Apart from processing data, the edge layer could filter, aggregate, and encrypt the incoming information.

Processing data locally helps save time and resources that otherwise would be needed to transmit all of the generated records to the cloud. Doing so, thus, results in better latency and higher performance.

Adding an edge layer is a viable option for IoT use cases that need data to be analyzed in real time and require built-in scalability and enhanced security, for instance, medical IoT systems, CCTV systems, or smart cars.

This is where the majority of data gathered by IoT devices ends up. So, the service and application support layer is used to accumulate, process, and store data. Here, two essential processes take place:

At the application layer, the accumulated, processed, and integrated data from IoT devices and external sources is run through analytics algorithms, and the results of the analysis are presented to users. 

The types of applications vary depending on the business requirements to an IoT system. They may include web or mobile applications that present visualized insights to end users or control IoT devices via actuators, business intelligence tools, or advanced analytics solutions relying on machine learning and artificial intelligence.

Now that we have shed light on the theoretical concept of an IoT architecture, let’s see what devising one may look like in practice. To illustrate the peculiarities of building IoT solutions, we will turn to a project from ITRex’s portfolio.

One of our clients turned to us with the idea of building a smart fitness mirror to help people train at home as effectively as they do at a gym. The mirror would replace a fitness coach, “watching” a person working out to provide feedback on training sessions and prepare tailored training plans for future workouts. ITRex’s engineers took on the challenge and devised an architecture for the solution, embracing everything from hardware to firmware to end-user mobile apps.

The architecture we ended up designing focused heavily on edge computing. The majority of data from the mirror’s sensors and cameras is processed on the device itself, and only a part of statistical information is passed over to the cloud.

Kirill Stashevski, CTO at ITRex, explains the choice to prioritize edge computing over traditional, cloud-based models: “We tested out both approaches — and edge computing won in terms of providing higher performance. So, the data from the mirror’s cameras and adhesive motion sensors that accompany the mirror and go on weights is analyzed close to where it is generated. This saves lots of time and helps cut down operational expenses. And that’s the thing with designing successful IoT architectures — you have to make choices and test out assumptions, choosing what works best for you.”

The high-level architecture for the solution, thus, looks as follows:

The mirror is equipped with AI networks that are pre-trained on extensive video footage of people working out. As a person works out, they are being recorded by the mirror’s built-in cameras, and the video footage is immediately run through the AI networks that compare the workout to a reference model. The AI engine, thus, generates real-time recommendations on whether a person’s workout routine is healthy and suggests the needed improvements — be it in weights, technique, or intensity.

As a trainee uses the mirror, video footage is drawn on to personalize the locally deployed AI networks, so the quality of suggestions improves with time.

According to Kirill, personalization is another reason we opted for an edge-oriented architecture. Training the networks locally based on videos recorded in the context the mirror is actually used in yields far better results than training the algorithms in the cloud relying on generic content. Another reason for choosing an edge-centered architecture is privacy as processing the data close to where it is generated spares the need to transfer footage across the network for analysis.

Despite being edge-oriented, the architecture for the solution features the cloud part as well. However, its main purpose is gathering statistical data on the mirrors’ usage and performance.

Another component of the solution is a social mobile app for end users to record their performance, share it with friends, and train together.

If you have your mind on adopting IoT, it is crucial that you devise a thought-out architecture for the future solution early on. Poorly architected systems are not scalable and cannot handle complexity, while a well-designed IoT architecture would allow you to plan for the future and guarantee: