IoT Architecture: every component you need for your IoT project

An IoT ecosystem has the potential of having thousands of sensors, hundreds of microcontrollers, and a handful of gateways before storing the data in your cloud.

From the cloud, there are additional considerations before delivering that data to an application so it can be used.

We are currently building our own IoT product: Office Vitals, a smart system that measures temperature, carbon dioxide, and capacity in our Denver-based office. As we built out the IoT architecture, we realized that getting all the components right the first time is difficult.

If you’re starting from scratch or trying to unlock specific data for the first time, start with your application’s architecture. Your final endpoint will shape the rest of your architecture.

As you think about your app, ask your team these questions:

– Why are we creating this application?
– What kind of data do we need?
– How will we obtain this data?
– What are we doing with this data?
– What might we want to do with this data in the future?

You need to answer these questions upfront. The rest of your IoT’s architecture depends on it because once you start introducing hardware, it’s difficult to change.

The one expectation to this is if you already have a board. In that case, start with your embedded architecture components.

There are a lot of decisions you’ll need to make when it comes to embedded systems, the first being your sensors and actuators.

When selecting sensors, you have some considerations to take into account.

– Operating environment
– Maintainability
– Cost
– Sensing ability
– Sensitivity
– Range of information

After you’ve selected your sensors, you need to define your sampling method and sampling rate.

– Sampling method: Will you sample via interruption or polling? I.e., Are you recording data every XX seconds? Or waiting for an event?

– Sampling rate: If you’re polling, how often will you sample? For this, you’ll need to consider how quickly the data you’re sampling changes. Determining if you need to sample every 1 second or 1 month makes a big difference in how you’ll collect and process that data. Further, depending on how urgently you need to send that data back to the cloud will influence the requisite quality of your network connectivity. If you sample too much, you’ll drive up network costs. Plus it’s wasteful. Generally speaking, you want to sample just enough data to get by.

After you’ve got the above worked, out, the next piece of your IoT architecture is your microcontroller (MCU).

Your MCU processes all your IoT data. You’ll need one that does wireless communication. When choosing an MCU, get one that does a bit more than you need because as you develop your product, you’ll probably add features for your users.

Consider using an RTOS like FreeRTOS or MongooseOS which allows over-the-air (OTA) updates. You’ll be able to add new features and update security as vulnerabilities are found.

Other things to consider:

– Cost: Especially for industrial IoT, you might need hundreds of microcontrollers. For consumer devices, you want to keep the cost of production low to maximize profit and make your product more accessible.

– Power: Your application may require your MCU to run off of a battery instead of being plugged into a power source. You need to understand how long the battery will last and which operating conditions will quickly drain your battery (for example, reading samples from sensors generally takes far less energy than performing wireless communication).

– Memory: If you need to aggregate large amounts of data for edge processing before sending it off to the cloud, you may quickly run out of memory!

– Gateways: If you have a low-power microcontroller, you’ll need a gateway. A gateway bridges your embedded architecture with your network.

– Information rate: If your sensors are producing a lot of information quickly, it might affect the MCU you get.

Popular boards include Raspberry Pi, Arduino, and ESP, and we typically recommend one of these while prototyping. However, once you decide on a system, you will likely design your own board. This selection gives you the control, flexibility, and security that you need for your product.

Never put a development board into mass-produced/commercial products.

Arguably the biggest decision for your IoT architecture is your database. After you’ve collected and sent all your data, how will you store it? With IoT, you’ll be collecting time-series data (at X time, the value is Y). Here are a few preferred time-series databases for IoT.

If you’re unsure of which cloud provider is suitable for your team, know that each provider allows you to make a free account with a dashboard. So you can always tinker with each before choosing one.

Although, what will most likely drive your decision is what you’re most familiar with.

At DEPT®, we have other infrastructure in AWS so it makes sense to stay in that ecosystem. AWS’s IoT Core plays well with its other products.

Your Top Options for IoT Cloud

– Google: Google isn’t a dominant player in IoT right now, but trying to make a push.

– Amazon: They have everything you need, but, to us, it feels like they’re more focused on industrial IoT. One possible benefit is that Amazon has its own hardware brand called SiteWise. They also have SnowFamily (edge processing).

– Microsoft: Microsoft seems to be more friendly to consumer products.

– Cisco: Specifically focused on industrial and smart cities. They also have their own hardware

To send information to the cloud, you’ll likely use MQTT protocol. For IoT, this has become the industry standard. This protocol keeps messages small.

To send information to your consumer-facing application or web browser, you’ll probably use protocols like MQTT or HTTP.