The 5 Components of IoT Architecture

Building IoT Devices is hard.

There are multiple components.  They require different skill sets to pull together.  There are often complex technical challenges to overcome, and they have to be exceedingly robust to survive in the real world.  The IoT Architecture can be hard to understand.

According to this report by Beecham Research, integrating IoT solutions and managing data are the most common challenges IoT projects face.

How can we overcome some of these problems?

One thing which can really help is having a solid understanding of the components of the solution you want to build or implement, the IoT Architecture and how it all fits together.

What is IoT?

But before we dive into that, let’s remind ourselves what a IoT Device actually is.

When we talk about connected devices, we mean a physical device, something you can hold in your hand, but which is connected, directly or indirectly, to the internet.  They are sometimes referred to as Connected Devices.

They are typically used to acquire data, from sensors included as part of the device.  Sometimes they are also used to control something.  Very often they are combined with some degree of Artificial Intelligence or Machine Learning.

How does having a model of the IoT architecture help, you may ask?

Well, one of the common problems we see with projects to build or implement a connected device is a failure to consider the wider picture.  People focus on the device itself and don’t think about the environment in which it operates.

Having an IoT Architectural model for your whole solution helps you to think about the full range of issues that will need to be addressed.  For example, rather than just focus on the device itself, you will think about how that device connects to the wider systems around it.

The other way a model can help is by thinking about how your solution will meet real user needs.  You might have come up with the cleverest IoT product, but unless it does something that people find valuable and useful, you won’t be able to sell many of your products.  Considering all aspects of the model helps you understand how your product will deliver that benefit.

The 5 Level Architecture

So here is our model for an IoT Architecture:

• Sense
• Process
• Transfer
• Analyse
• Respond

Let’s drill into each of these in turn.

Sense:

This is where we acquire raw data from sensors.  There are many types of things we might want to sense, pressure, temperature, humidity, flow, motion, or many others.  It will depend on your use case.

Process:

Having sensed the raw data, we then will process it in some way.  This is often to smooth it or compress it.  Raw data can be acquired at a high bandwidth and can be very noisy.  We want to strip out the data that isn’t useful.  Sometimes this can be a very significant compression, from complex signals to simple, actionable information.  For other solutions, the local processing can be quite minimal.  When people talk about Edge Computing, this is a good example of what they mean.  Processing takes place on the device itself, so right at the edge of the solution.

Transfer:

This is where we take the processed data and move it from the device, most likely to a cloud-hosted backend.  This might be directly, via Wifi or a cellular connection, or it might be via a local hub.  In some solutions that local hub might be a user’s mobile phone.  In other cases, it might be a dedicated unit, potentially connecting to multiple sensing devices.  More details on connectivity are here.

Analyse:

Here we combine and analyse the processed data.  Since this is likely to be in a backend cloud-hosted environment we have more processing power, and more control to manage the service.  When we analyse our IoT data we have the opportunity to combine it with additional product or logistical data, to produce useful insight.  For example, we might combine the sensor data with profile or account information, or with open data sources relating to the location.  There are many possibilities.

Respond:

Finally, we consider what effect the device will have.  If it does not induce some kind of response, what purpose does it have?   That response might be at a central location, for example, a call centre, or it might be to deliver information back to a remote user.

In order to trigger the right response we will often do things like create a score or ranking so that we can focus on the assets with the highest priority.

We may integrate our data with other systems, such as CRM, Service Desk or Logistics.

Notice that many people use a four-layer architecture, but we deliberately expand it to 5 to emphasise that processing on the device is different from analysing at the backend.

Like all models, this is a framework, not a rule book.  Each separate solution might combine these elements in different ways.  Processing may take place before and after Transfer.  Transfer might be just to a local hub (such as a mobile device) or directly to the internet, via wifi or mobile data.  Some might avoid one component, but fundamentally, most Connected Devices align with this model.

In Conclusion

So there we have it, our model for and IoT or Connected Devices Architecture.

Are you building an IoT solution or Connected Device?  Have you created an architecture model for your solution?  Tell us about it in the comments.

500 More helps organisations to build purposeful innovative digital solutions, including IoT.  If you’d like to find out more about what we do or how we can help you design, build and deliver your project, book an appointment now.