In this post you will learn what it takes to build a functional and simple IoT solution. We will focus on the architecture as a whole.
Simplified IoT Architecture
Physical Data Collection
Begin by looking for sensor modules. Sensors will collect data from the physical space. Understanding the output of sensors is very important.
Sensors cannot communicate out of the box. To make sensors communicate, we need one more module. Communication modules are more than likely going to fall under the RF modules.
Cloud & Management
Once a communication module is chosen. It is time to chose a cloud service provider that would accept those messages being sent out by the communications module. Management takes place in this step as well.
Application & Insights
Best part, the outcome of your entire build. The application will take the stored data in the cloud and convert it to something we can all understand. Insights are generated in this final step.
Physical Data Collection
By looking specifically at your problem. Can you come up with a list of data you would like to know about the physical space you are working with?
Once you have a good idea of what you are looking to collect out of the physical space, it is time to research the sensors that are capable of collecting those specific data.
|Physical Data Needed||Sensor Capable of Collecting|
|Temperature & Humidity||DHT22 Temperature-Humidity Sensor (Digital)|
|Light Intensity||GA1A12S202 Analog Light Sensor (Analog)|
|Magnetic Field||Hall Effect Magnetic Sensor (Analog)|
|Movement & Vibration||3-axis Gyroscope and 3-axis Accelerator (Digital – I2C)|
Sensor modules come out as an output device. The output must be ingested and sent out via a communication protocol. Hence the “Internet” part of the IoT. How do we enable our sensor module to communicate?
You must first select a MCU (Micro-controller Unit) that would be the main “brain” of your IoT device. The MCU will collect the data from the sensor via either an ADC (Analog-to-Digital Converter) for Analog data or via an I/O input.
The MCU will be programmed to read the signal coming out of the sensor and to do a very simple mathematical calculations on the data just to filter it. Remember we must not overload our MCU with calculations tasks, as its main purpose would be to send the data points to the cloud and we will take care of the rest.
A communications module would then be used to (based on the protocol used) will send the data to the cloud. Where it will be stored and next steps would follow in the assembly line.
It can be very daunting when picking a specific IoT communication protocol. Let me tell you from now, whatever you pick will depend highly on your current structure. For instance, if you are installing your infrastructure in a commercial setting where WiFi is the predominant protocol, then that is what you want your IoT device to work with. if you pick different protocol, you better have a very good reason otherwise it would just be a waste of resources on building a network that already exists.
Options become endless if you are in an industry setting where there is no infrastructure in place. However, answering the following questions to select your communication module would shrink your options.
Here is a full list of a large list of IoT Standards and Protocols.
Communication Module Selection
- Is there a protocol you are already familiar with? – if you know a protocol well, you should stick with it since it would expedite your development process tremendously.
- Technical requirements, such as,
- Low power usage
- Distance of communication (Signal Range)
- Amount of data and frequency (how fast)
- Obstructions, such as physical obstacles or signal saturation (lots of RF noise in the area)
- Cost and more…
- Does your back-end support that protocol (or what kind of protocols does your back end support)? You can always work your way backwards. As a matter of fact, I recommend that you sometimes work your way backward if you already have a back-end solution, that you start thinking about what your back-end solution offers and supports.
- Ease of deployment, since most of the time, you are not the one who will physically install those devices. Most people who install IoT devices are not tech savvy.
|WiFi, BLE, Bluetooth, Eithernet||ESP32-DevKitC||Espressif|
|LTE Cellular||pycom Gpy||pycom|
|LoRa||SparkFun Pro RF – LoRa, 915MHz||SparkFun|
|Z-Wave||500 Series Evaluation Boards||Silicon Labs|
After you make a selection of what protocol you are going with. It is time to test it. Same idea as before this step. You want to select a development board to test out your theory and start to test the connectivity to the cloud. Once you have the pipeline built between your cloud and the physical device. Everything else falls into place easily.
An example list of protocols and their respective development boards for testing is shown on the right.
Cloud & Management
At this point, you enabled your sensor to communicate. Next, is figuring out to who will your module communicate and send what exactly.
Picking the right cloud service provider will save you a tremendous amount of time. Come up with a list of cloud providers that have great deal of support as well as their popularity amount makers should be high. It would make the world different if you come across an error and can search it up real quick and find the answer since there is such a big community for it.
The cloud provider will serve you with a huge bucket of documents that you would need to follow to have your data sent. I would not go through the documents first. Instead begin with an example and dismantle the sample code to understand how their structure works.
Cloud Service Provider Selection
IoT devices require that you manage them for a long period of time. Since they are to be place in remote locations, you want to make sure that you have enabled your device’s firmware to accept OTA (Over-The-Air) updates. This way you do not have to send someone out every time to update your devices. This will save resources!
Your IoT Cloud Service should be able to provide you with the following abilities at a minimum:
- Automated provisioning of new devices as they are being added to the network. When your devices come out of the manufacturer they are loaded with their secret keys, in which when it is first turned on. It should try to connect to the provisioning service where it will check its credentials and accept it into the network. (This is an important security feature)
- Bidirectional communication between the edge device (your sensor) and the cloud.
- Event driven would be a great solution since most of the IoT module are going to be sending continuous data. Sometimes there is a specific threshold, when reached it would fire an event.
- Data visualization capabilities.
- Easy integration into other applications.
- Data analysis features are very important!
Application & Insights
You have the data, now what? So far, we have been working just to be able to get the data from the physical world into a server. Once the data arrives into the servers, that is where our application comes into play.
Your application should be written on-top of the framework from the cloud service provider or else you will need to create APIs that would allow for extending endpoints to your applications. This is where the user is the most important factor. If the collected data are to be displayed for users and the user is responsible for taking actions, then all your job would be to show the user the data. In a meaningful way of course.
Act upon the Incoming Data
If the data are not to be shown to the user and are just for history purposes, then you want to create a line of actions. The line of actions would involve listening for any data changes and firing out an event that would cause an action to be taken. The action could be a notification to a human to make an adjustment or it could be to another machine to make an adjustment. Say, a fully automated factory. A machine has a temperature sensor on the surface to ensure that its temperature stays within a certian limit. The sensor’s job is ONLY to send data to the back-end. The back-end saw a temperature data increasing. Starting to increase at least. Based on history, the algorithm knows that it is about to hit a certain limit that would cause a damage. So the system would fire a warning message to the engineer on the floor letting them know of the status and could also possibly shut off the machine to cool down again. This is a great example of M2M communication and actions.
Hope this article gives you a good overview of what an IoT architecture involves and how you can get started. We will continue to post for everyone to learn how to build IoT devices. Please follow us, comment and support us as we continue to build our community.