paint-brush
Components and Design Tips for an IoT Solution Architectureby@itrex
418 reads
418 reads

Components and Design Tips for an IoT Solution Architecture

by ITRexMay 11th, 2022
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Using tools such as DagsHub, DVC, MLFlow, and GitHub Actions to create a full-fledged ML/DL project. We will be trying to solve a binary image classification problem using images from two classic video games.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail

Coins Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Components and Design Tips for an IoT Solution Architecture
ITRex HackerNoon profile picture

Businesses are continuing to jump on the Internet of Things bandwagon and turn to IoT consulting firms. According to recent research by Facts & Factors, the global IoT market is expected to reach $1,842 billion by 2028, growing at a CAGR of 24,5%.


Rolling out IoT is not easy though. Beecham Research reports that 75% of all IoT projects are either not meeting the set expectations or fail. A common reason for that is a lack of planning and technical challenges stemming from it.


What helps avert the risk of failure is laying out a blueprint for an IoT architecture in advance. In this blog post, we shed light on the essential components of an IoT architecture and show how devising an IoT architecture may look like in practice using an example of a project from ITRex’s portfolio.


Let’s plunge right in, starting with the very basics.

What is an IoT architecture?

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.

A standard IoT architecture: what’s under the hood?

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

  • Device layer
  • Network layer
  • Service and application support layer
  • Application layer


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:

Device layer

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.

Network layer

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:


  • LPWANs, or Low Power Wide Area Networks, were built specifically to support large-scale IoT solutions. LPWAN provides opportunities for far-reaching communication while being energy-efficient, long-lasting, and cheap. The downside is that LPWANs only transmit small volumes of data at quite a low rate, so they are better suited for use cases that are not time-sensitive and do not require high bandwidth, like smart buildings or industrial IoT.
  • Zigbee is a short-range wireless communication standard that is best suited for medium-range IoT applications with nodes evenly distributed nearby, for example, smart homes. Compared to LPWAN, Zigbee provides higher data rates but it is less energy-efficient.
  • Cellular networks (3G/4G/5G) offer reliable broadband communication, so they are well-suited to support such use cases as connected cars, traffic routing, fleet management, or advanced driver assistance. Still, cellular networks don’t pair well with battery-operated sensor networks and incur high operational costs, which limits their use.
  • Bluetooth provides short-range communication and is used for small-scale consumer IoT devices, like sports or healthcare wearables, the Internet of Body devices, and smart home appliances.
  • Wi-Fi enables high-throughput data transfer. Still, due to coverage, scalability, and energy consumption issues, Wi-Fi is often not a feasible choice for expansive IoT networks or battery-operated IoT devices. Instead, it is more suited for smart devices that get connected to a power outlet, like smart home gadgets, security cameras, or digital signages.
  • RFID uses radio waves to transmit small volumes of data from an RFID tag to a reader located nearby. This communication technology is widely used in logistics and retail.


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

IoT sector

LPWAN

Cellular

ZigBee

Bluetooth

Wi-Fi

RFID

Industrial IoT

Highly applicable

Moderately applicable

Moderately applicable




Smart city

Highly applicable






Smart building

Highly applicable


Moderately applicable

Moderately applicable



Smart home



Moderately applicable

Moderately applicable

Moderately applicable


Connected cars





Moderately applicable


Health IoT


Highly applicable


Highly applicable



Smart retail


Moderately applicable


Highly applicable

Moderately applicable

Moderately applicable

Logistics & tracking

Moderately applicable

Highly applicable




Highly applicable

Smart agriculture

Highly applicable






Edge computing layer

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.

Service and application support layer

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


  • Data accumulation IoT systems generate huge volumes of data, and not all of this data needs to be put into action immediately. Therefore, an IoT architecture may feature a data lake to store all of the generated information and only send cleansed and filtered records down the data management pipeline.


    So, the main goal of this stage is to bring all the data together, figure out whether a particular piece of information is relevant to the business requirements, and decide on how it should be stored — in a temporary database or a data warehouse.

  • Data abstraction At this stage, the information from IoT devices is amplified by the data from relevant external sources. These could include ERPs, EMRs, and other enterprise systems.


    Transformed to match unified formatting, the data goes over to centralized storage, for instance, a data warehouse, where it can be conveniently accessed for insights.

Application layer

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


The types of applications vary depending on the business requirements of 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.

Designing an IoT architecture in practice: what waits ahead?

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 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 to gather 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.

A recap, of why it is crucial to design a blueprint for an IoT architecture in advance

If you have your mind to adopting IoT, you must 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:


  • Maintainability. Well-architected IoT systems are easier and cheaper to maintain. Since the bigger picture with all of the components, processes, and integrations is clear, it is simpler to jump on to smaller tasks. When it comes to project sourcing, well-architected systems, too, facilitate bringing in new talent and reduce the time it takes to transfer knowledge.

  • Scalability. With the initial architecture planned out, it becomes simpler to scale the IoT system both vertically and horizontally, bringing in new functionality or adding more end nodes.

  • Cost-efficiency. Dedicating time to thoroughly designing your IoT system helps make better technology choices, thus lowering the development and operational costs of IoT solutions.

  • High performance. Having a clear architectural vision helps build better data flow, as well as processing the incoming data with appropriate tools, which helps achieve higher system performance.

  • Interoperability. An IoT architecture could span multiple devices using different communication protocols that don’t always pair well together. A thought-out IoT architecture helps make sure different devices and components work smoothly together.

  • Security. By investing initial effort into system design, you could avoid security loopholes and plan out the necessary IoT security mechanisms.


If you have any unanswered questions or want to jump on the IoT bandwagon with little to no risk, contact ITRex IoT development team. ITRex will help you design a reliable and scalable architecture to power your future solution.


Originally published here.