IoT architecture is a beast.
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: Devetry’s 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. It requires planning and focus to get your IoT architecture components right.
General Architecture of IoT
No matter your size or complexity, there are four categories within the larger architecture of any IoT product.
- Application — How is your consumer going to interact and use this data?
- Embedded — This is the hardware itself (and the custom software written to run on it). What kind of chips and sensors do you need to collect and send the necessary data?
- Network & Connectivity — How is the data being sent to the cloud?
- Cloud & Infrastructure — What kind of cloud infrastructure and database do you need?
As you start to plan your IoT architecture, these are the four categories you’ll need to figure out as quickly and effectively as possible. Within each of these categories are a series of decisions you need to make, each affecting the other. This is why it’s essential to strategize and plan around your end user.
Where to Start — IoT Architecture
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.
Imagine a future where you have all the data you need.
What are you doing with it? Why are you creating this application?
Then you can start to think about how to deliver the data you need to the user-facing application. Will it be via a web browser, mobile application, smartwatch, or something else? To get a better idea of what to do, include human-centered design principles in your strategy.
Something to consider in this stage is data processing speeds. How quickly your device needs to process data will determine whether you lean on cloud or edge computing.
Edge computing is ideal for data that needs to be processed very quickly (heart monitors, autonomous vehicle braking system). The downside is that edge computing will increase the cost of the device itself.
Cloud computing is ideal for things that aren’t as “life or death” (coffee pots, doorbells). With cloud computing, you can also access the device from anywhere because everything runs through the cloud.
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
- Sensing ability
- 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.
Your network is how you’ll send data to your cloud. To choose this, you’ll need to know your embedded technology and your sampling rate. Whichever MCU you choose needs to support the networking interface you choose, but the networking interface should be driven by your operating environment.
Where will your product operate? In a car? In a cornfield? At a school?
This operating environment plus your sampling rate should give you insight into what kind of network/connectivity you need for your IoT architecture. Here are some popular options:
- Bluetooth (close to mid-range and low energy)
- Wifi (mid to long-range. Wifi takes 10X the power, but is faster and can have a much longer range than Bluetooth)
- Cellular (great for when your device is on the go in urban areas. You don’t need to be tethered to a wifi network or gateway, you just need to make sure you stay within the coverage area of your provider.)
- Satellite (less conventional (read more expensive and harder to find a provider), but enables network connections in rural areas where cellular coverage isn’t available.)
- LoRa (Long Range): Similar to wifi, but it reaches further (up to 10 miles in rural areas).
The final thing to consider is reliability. Is your network going to be available at all times? If not, you might need to account for storage on your microcontroller or gateway.
Cloud and Infrastructure
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 Devetry, 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.
How to Create your IoT Architecture Plan Quickly
If you’ve made it this far, you understand the number of decisions you’ll need to make when creating your entire IoT architecture. Depending on your application, industry, and budget, your final architecture could be one of a hundred combinations. To find the ideal combination, we recommend an architecture sprint.
You want to make decisions as quickly and efficiently as possible. The quicker you can prototype an IoT, the better. During this one-week sprint, focus on the necessities, don’t worry about high-fidelity prototypes.
Being able to consult experts who have experience building IoT products will save you a lot of time as well. That’s why we recommend working with an IoT software development partner during your architecture sprint. The time and effort saved during an intensive sprint will save you in the long run.
Originally published at https://devetry.com on September 28, 2021.