IoT Architecture 101
Explore the fundamentals of IoT systems and learn the key considerations when building your first project with this starter’s guide.
This starter’s guide will explore the technologies that currently drive the Internet of Things value chain and explain how they collectively relate to a broader strategic framework. We hope you will find this a useful reference whether you are just curious about IoT or actually planning a project.
Contents
- Defining IoT and Its Value
- Points to Consider When Building an IoT System
- IoT Architecture Examples: Device-to-Cloud and Using Gateway
- IoT Architecture Examples: Using Mobile and Using Server
- Selecting a Protocol and Other Considerations
- File Transfer in IoT Systems
- IoT System Application Examples
1. Defining IoT and Its Value
While the concept of smart devices had been around for some time, the term Internet of Things first gained prominence in 1999 thanks to Bill Joy’s presentation at the World Economic Forum in Davos that year. Today, IoT has become such a hot topic that not a day goes by without some kind of high-profile media coverage. But, what exactly is IoT? To answer this question, we will try to unpack its essential qualities.
Connecting Devices to the Cloud
Generally speaking, IoT means adding value to the way we live and do business by connecting not just computers and smartphones, but various devices to the internet.
So, what exactly are these devices that add value? What kind of value can we acquire? Each person will probably answer these questions differently. In our work, we have the opportunity to discuss IoT with people who hold various points of view. The one thing everybody agrees on is that IoT is a very broad term and that the exact meaning is hard to grasp.
For example, some might think of wearable devices for consumers such as the Apple Watch, while others might talk of remote-controlled large-scale construction equipment. The specifics and points of view are often very different. Perhaps because of these characteristics, there are still many people for who IoT is just another buzzword.
IoT Is a Tool That Gives Rise to Innovation
So, what are the fundamental properties of IoT? We think of IoT as a method and a tool that facilitates innovation.
For example, when cloud computing arrived on the scene, a lot of people skeptical of the idea questioned its necessity. Why would it be different from existing data centers’ housing models, or from VPS? Is it essential to work with the cloud?
We remember hearing many discussions around questions like these. However, at present, the cloud has become an indispensable option for system infrastructure. Not only that, numerous innovative services and businesses have come into existence that successfully use cloud features.
In the same way, we often hear people question what the difference is between IoT and M2M (machine to machine) or mobile services. We feel they are confusing the true meaning of IoT.
IoT is a tool or a method. The essential quality of an IoT system lies in how much you can innovate by effectively using this tool.
The value that you can add through an IoT system and the way it will change people’s lives depend on the individual or business that uses it. Some might use it for health care, while others might use it for financial payments. The shape and form of IoT differ significantly for each user.
From a practical point of view, IoT is just one method for innovation, but it is a method with limitless potential. We believe it is an option that no enterprise should leave untouched.
Suitable Applications of IoT
Let’s try to break down a little more what value one can think of when using IoT, and then look at types of existing IoT systems and services.
IoT is a tool that provides endless possibilities. In the future, we believe many new systems and services that use IoT properties are going to be created. As for the IoT systems that we can think of now, we can divide them into the following categories.
- Payments: Payment with remote devices.
- Remote monitoring: Remote support and monitoring of facilities and equipment.
- Security: Home security and protection services.
- Sensing: Collecting sensing data from items and places.
- Smart meters: Measuring devices and controls for electricity, gas, and so on.
- Telematics: Information provision services for cars and transport vehicles.
- Tracing: Tracing objects while they are transported, moved, assembled, or processed.
Effectively Using IoT
Similar to the cloud, IoT might be relevant to anyone who is involved with IT systems. We believe the successful use of IoT will be an important factor in dealing with the world of tomorrow. It is a new type of service model, and it, if used effectively, has the potential to change current forms of system architecture.
2. Points to Consider When Building an IoT System
In this section, we will shed some more light on the aspects to consider when building an IoT system.
An Overview of IoT
From home security to factory automation, IoT can be used for various things that surround us. However, no matter how many scenarios you can think of, the factors that make-up IoT are almost always the same. The figure below gives an overview of IoT.
IoT can be divided into two major categories:
- Machine-to-machine (M2M) connection
- Machine to human (M2H) connection
A typical example of M2M would be a remote monitoring system to manage or control a smart meter for electricity management or construction equipment from a distance. This is useful for making an intelligent analysis of the network, a development that is drawing attention along with the liberalization of electrical retail.
Under M2H we can classify wearable devices, such as devices attached to a person’s wrist or leg to monitor the number of calories burned or steps taken. These systems are mainly constructed based on a cloud platform. To efficiently manage a large number of devices or data, you need a highly scalable platform such as a cloud.
However, a cloud platform is only infrastructure. You need applications to make a system work and to manage it. For tasks such as analyzing or controlling, applications are built on a cloud platform. By combining multiple elements in this way, IoT is realized.
The Elements of IoT
Let’s look more closely at the elements that make up IoT. As we explained before, IoT consists of three layers: device, cloud, and application.
First, data is collected or transferred through a SIM card and/or a wireless connection from a device such as a sensor or a smartphone. The transferred information is then stored in a database or a file in the cloud. After that, the application retrieves the stored data and then carries out analyses, visualization, and simulations.
What is important here, is that the data can be exchanged across all the layers. This means that if data cannot be thoroughly integrated between the device, the cloud, and the application, the IoT system will not work.
Furthermore, data integration must be possible between elements that have not been connected before — that is, between devices and the cloud.
Data Integration Is the Key
A fundamental issue in IoT is the degree to which data integration is possible. Situations might exist where sensor devices can only communicate through a short-distance wireless connection or where data is transferred through a low-quality, unstable 3G/LTE connection. To deal with these circumstances, data integration needs to be scalable, efficient, and reliable.
IoT is a data-centric system.
In other words, data collection and data integration are inseparable functions of an IoT system. They are the keys which make IoT possible. Therefore, the most important step when building an IoT system is to think about how you are going to collect and integrate data.
3. IoT Architecture Examples: Device-to-Cloud and Using Gateway
By now, you have probably grasped the general idea behind IoT so we can imagine you want to see some examples of specific IoT architecture.
About IoT Architecture
In IoT, the system architecture is based on how data is collected and integrated. The design of the cloud will vary depending on the tasks performed after data has been received. But because there is no significant difference with conventional system architecture, we want to focus on data collection and data integration here.
The existing IoT system architecture that we have been involved with so far can be divided into four major categories.
- Device-to-Cloud
- Using Gateway
- Using Mobile
- Using Server
Below, we will introduce the former two categories.
Device-to-Cloud
This type of architecture is perhaps the simplest, and easiest to imagine. It merely allows data to be sent from a sensor or device directly into the cloud.
The characteristics of this method can be summed up as follows.
Advantages:
- Can be set up relatively quickly.
- The architecture requires little modification as the number of devices increases.
- Allows for flexible data handling in the cloud.
Disadvantages:
- The maintenance costs climb as the number of devices increases.
- When the data from each device differs, any subsequent action needs to take place in the cloud.
- Re-sending data has to be handled on the device side.
- Battery consumption is high, making it impractical.
Using an IoT Gateway
Because Device-to-Cloud architecture requires devices to have a certain amount of performance, the cases in which it can be used are limited.
To use primitive devices such as sensor chips, you will need to add an IoT gateway before data transfer. This allows data to be forwarded after it has been aggregated once. We will refer to this type of architecture herein as Using Gateway.
The characteristics of this method can be summed up as follows.
Advantages:
- Short-range communication can be used to reduce the load on the device.
- Requires minimal device setup when the number of devices increases.
- Data transfer is easy to control (re-sending, filtering, etc.)
- Devices can be managed in groups.
Disadvantages:
- Higher costs.
- Device management requires a separate structure.
- When the gateway fails the entire group of devices becomes unusable.
Conclusion
We have introduced two types of architecture with IoT characteristics.
We believe the characteristics of IoT systems are as follows.
- The number of data collection points (the number of devices) is very large.
- Devices are not expected to have high performance.
- Devices may break down (requiring you to consider a device’s replaceability).
This means that to create an IoT system, you need to build a scalable and cloud-intensive architecture.
4. IoT Architecture Examples: Using Mobile and Using Server
Building on the last section, in this one, we will introduce the two types of architecture: Using Mobile and Using Server.
Using Mobile — Ideal for Wearables
Using Mobile is a type of architecture that is used a lot in consumer services. It closely resembles the previously introduced Using Gateway, but it works with smartphones and mobile devices instead of an IoT Gateway.
The characteristics of this type of architecture can be summarized as follows.
Advantages:
- Can be diverted to a user’s mobile device.
- Can be used for other purposes besides relaying.
- Easily control transfers.
Disadvantages:
- Devices that collect data do not always have a mobile device nearby.
- Requires you to check beforehand whether the data collection device is operating.
- A large number of data collecting devices puts a heavy load on the mobile device.
- The most straightforward example of this type of architecture would probably be wearable services.
If a device worn on a user’s body sends data directly to the internet, battery consumption or data transfer controls can become problematic. To solve this, you can use a system for data transfer that uses commonly owned mobile devices such as smartphones.
Not only does this solve these issues, but it also enables you to request pre-transfer operations, such as letting users check required permissions on their side or letting users add specific attributes before sending data.
The downside is that mobile devices are not always carried alongside data collection devices. You can also imagine there are cases where mobile devices are not in a usable state. This requires other solutions, such as triggered data transfer on opportunity or midway data storage.
Using Server — Making Use of Existing Assets
Using Server is a type of architecture where similar to Using Mobile, you replace the IoT Gateway with a so-called regular PC server.
The term server might not be immediately apparent to some. We mean it to include devices such as a Programmable Logic Controller (PLC), a server that is lightweight and compact for use in specific situations.
The characteristics of this type of architecture can be summarized as follows.
Advantages:
- Allows for tasks such as data conversion and data storage to be performed during data relay.
- Existing assets often can be diverted.
- Easily control transfers.
Disadvantages:
- Lack of mobility (devices are fixed).
- Adding servers raises costs.
- Can cause problems with network environment construction and security measures.
The use of a server might seem atypical for IoT. Yet in a setting where, for example, data is collected from a factory production line, it may be more efficient to process data transfer by using existing devices such as PLCs or servers that aggregate data without introducing IoT Gateways.
Additionally, when data is aggregated, you can perform complex processing. This allows for constructions like so-called edge computing, where data transfer takes place after completing a certain amount of processing at the edge.
However, the costs are an issue, and devices such as PLC sometimes do not connect directly to the internet. This may require you to perform time-consuming tasks on your network and security measures.
Summary of the Four Types of Architecture and Their Use
So far, we have introduced four types of architecture that all have their pros and cons. Below we will categorize them according to their characteristics and range of applications.
Thus far, we have explained IoT architecture by dividing it into four types, but keep in mind that these are subject to change due to technological innovations and trends in technology.
For example, as we explained earlier, Device-to-Cloud is currently impractical because of limitations in battery use, but once low power transfer technology is developed this will no longer be an issue. Also, the specifications of IoT Gateways are improving day by day. It might not be long before IoT gateway specs are equivalent to those of PC servers.
Nevertheless, it would be wrong to say that Device-to-Cloud is meaningless. Consider how you collect data and how you transfer it. It is not necessarily a good thing when a device and the cloud are near each other. You need to control the distance according to the situation and your objectives.
Having looked at four different types, we can conclude that control over the optimal distance between devices and the cloud is a critical variable in IoT architecture.
5. Selecting a Protocol and Other Considerations
So far, we have looked at four types of IoT architecture, but there are several options for transfer protocols as well. To select the optimal protocol in an IoT context, we need to look at the setting and the various trade-offs.
Below, we will give an overview of the characteristics of typical protocols that frequently appear in an IoT context, and then look at how we can apply these to a system.
HTTP
HTTP (Hypertext Transfer Protocol), one of the most widely known protocols, uses TCP and has the following characteristics:
- Simple and highly versatile.
- Large overhead.
- Easy to divert existing systems.
- For HTTP requests and responses, you need to attach a message header, which is necessary for processing HTTP messages.
- For an IoT system, you might want to avoid HTTP due to the cost of creating and transferring message headers.
MQTT
Next is MQTT (Message Queuing Telemetry Transport), a lightweight protocol that uses a Pub/Sub communication pattern and is used relatively often in IoT systems.
MQTT has the following characteristics:
- Small overhead.
- Messages of up to 256 bytes can be sent all at once.
- Pub/Sub communication.
- QoS (quality of service) or delivery guarantee.
- Big differences in available functions of different products.
- MQTT is more lightweight than HTTP and is suited when resources on the data sending side are limited.
- To perform MQTT communication, you need to place a server called an MQTT broker in between the client that sends data and the service that processes the data.
- Granular tasks that occur in large quantities can be distributed by preparing a large number of subscribers.
- You can select a QoS level to suit a particular situation, and you can enable delivery guarantee between client and broker.
Low Layer Communication Methods
In an IoT system, lower layer protocols that are even more lightweight than HTTP or MQTT are sometimes used such as TCP and UDP.
- Transmission Control Protocol (TCP) focuses on reliability and is the basis for HTTP and MQTT. TCP uses a three-way handshake to ensure the reliability of data transfer. However, this increases the number of times that communication takes place.
- User Datagram Protocol (UDP). When data is sent to the receiver, it does not guarantee the arrival or order of data. This means that data transfer will lack in reliability. However, it will be light in weight, so even if some data is lost, you may still want to use this protocol when lightweight communication is a priority.
Trade-Offs and Selection
Next, we want to look at what protocol can be used for what kind of situation. We will also look at some issues around protocols that require individualized solutions.
- Communication quality
- Communication volume (fee)
- Machine resources
- Battery
- Mission criticality
- Real timeliness
- Security
Communication Quality
Points to Consider:
- Data loss
- Communication speed
Especially for Device-to-Cloud, Using Gateway, and Using Mobile, it is common to use a cellular line. Depending on the quality of the cellular line, some data loss can be expected. To transfer important data, you will need a method to cover any losses.
For example, in HTTP you need to implement measures such as a mechanism that re-transmits data after detecting data loss. You may also need a buffering function when the communication quality is low, and real-timeliness is lost because of delays in the transmission.
Communication Volume (Fee)
Points to Consider:
- Traffic
- Transfer frequency (communication overhead)
In some cases, such as when using a cellular line, you will want to limit communication volume (fee) and use a protocol that is as lightweight as possible.
To ensure real-timeliness, you should consider using MQTT or an independent protocol.
If you can afford to compromise real-timeliness, you may want to consider a method that includes buffering, compressing, and sending data in batches.
Machine Resources/Battery
Points to Consider:
- Encrypted communication
- Protocol complexity
This is a point that is especially important to consider for Device-to-Cloud and Using Gateway. If the machine that transfers data has limited resources, you may want to use a protocol that is as simple as possible. MQTT is more straightforward than HTTP, yet when encrypted communication is required, it is hard to tell which one is more effective than the other.
Mission Criticality
Points to Consider:
- Delivery guarantee
- Order guarantee
- Transactions
If you use MQTT, it is possible to raise the QoS:
- MQTT’s delivery guarantee is a guarantee between the publisher and the broker. When you want to further guarantee successful data processing at the backend, you may want to consider AMQP protocol as another option.
- MQTT does not provide an order guarantee. To perform processing including transactions and order guarantee, you should consider a commonly used message queue system rather than a protocol specialized for IoT.
Real-Timeliness
Points to Consider:
- Transfer frequency
- Communication overhead
Achieving real-timeliness means that data transfer will take place frequently. If the purpose is to decrease communication overhead, MQTT is effective. If you want to transfer data even if some data loss occurs, UDP could be an option.
Device Control
Points to Consider:
- Bidirectional communication
If you want to give instructions to a device, especially in the case of an IoT Gateway, you can use a protocol capable of two-way communication or a system where instructions from the device are regularly acquired through message queues.
A protocol capable of bidirectional communication is WebSocket. Because it uses a continuous connection with the server, the server requires a lot of resources. In MQTT a device can also function as a subscriber, so it is also effective for device control.
Conclusion
When you are considering building an IoT system, there is a large variety of communication protocols and methods to look into and compare.
The protocol that tends to receive the most attention in an IoT context is MQTT. However, MQTT is not used because it is the best protocol. Its use is the result of various trade-offs in a specific situation.
When you select a protocol or communication method, we think it is not only necessary to know its characteristics in various circumstances, but also to understand how its weak points can be covered.
6. File Transfer in IoT Systems
In the last column we mentioned that whatever protocol you choose to use, you will need to cover its various limitations according to the environment in which the IoT system is built.
We have looked at several protocols and transfer methods. We will divide them into three categories and use a table to indicate for each the ease of development and the extent to which they meet the conditions necessary for IoT.
Advantages and Disadvantages of Protocols Used for IoT:
The most commonly used protocols for IoT are probably MQTT and HTTP.
- HTTP is very versatile and used in many settings besides IoT.
- MQTT is very lightweight and suitable for unstable networks, making it an attractive protocol for IoT systems.
- File transfer, although it is not often mentioned in IoT, is worth paying attention to as an alternative transfer method. Since it is based on the powerful and basic idea of a file system, it is easy to use and scale.
File Transfer in IoT Systems
Let’s look at how you can use file transfer for an IoT system, and what considerations are necessary. To make it easier to visualize the system, we want to build. First, we will illustrate a few cases of file transfer.
Outputting Sensor Data to a File
The sensor data is added to a specific file in succession in this way.
Collecting and Transferring a Certain Amount of Data
The sensor data is filtered or aggregated to be output to a file, and then a certain amount of that data is transferred in this way.
Points to Consider for Carrying out File Transfer
Let’s go over some points to consider when transferring files in cases such as these.
- Data Loss: For example, in Using Gateway, when the IoT Gateway serves as more than a single router, and you use it to accumulate, filter or aggregate data to send all the data at once, it is important that it will be transferred without any data loss. One method to prevent data loss is to match the file size, hash value, or other attributes on the sending side and the receiving side.
- Communication Speed: In situations not limited to file transfer where connection bandwidth is limited, data compression is indispensable. Also, if you want to send large quantities of accumulated log files, to distribute the load more evenly on the server and keep the connection open, you can split the data before sending it.
- Machine Resources: A point to consider when transferring files is the time it takes since it might cause stagnation in subsequent data generation processes. If machine resources are more limited than on a regular server, as is the case for an IoT Gateway, the time required for transferring may be increased including the time for the tasks such as compression and encryption. If in such a situation sensor data is continuously overwritten in the same file, you will need a solution to prevent data output from being disrupted. For example, you could rename files directly before they are transferred.
- Delivery Guarantee: If you are using a TCP protocol, you can usually guarantee that data is delivered. It is essential that you can ensure that data duplication and data loss did not occur after performing a series of data transfers. For example, when retransmitting data after the network is disconnected and reconnected, you will want to prevent that the wrong data range gets retransmitted.
- Real Timeliness: When you use file transfer to transfer data at high frequency, and the receiving server always receives data with the same file names, data that has not been processed might be overwritten. To avoid this, you could output data after changing the file names little by little, and then delete the files after data analysis is finished.
- Capacity: Another point to consider is whether you can construct your system to handle a large amount of access. With file transfer, data is output to the file system once, so you need to think about how data is distributed after that.
We will try to show these points in the following diagram.
Conclusions
- Whatever protocol you choose for your IoT system, you will need solutions to deal with various limitations, such as unstable networks or machine resources.
- By taking appropriate measures, you can use file transfer as a suitable transfer method for an IoT system.
- We can imagine many different settings in which IoT can be used, but it is hard to single out a transfer method that works uniformly well for all of them. It is therefore essential to explore a wide variety of options.
7. IoT System Application Examples
Up to this point, we have introduced the types and features of IoT system architecture and the main points thereof. You should now have a basic mental image of the kind of architecture required for IoT systems.
In this section, we will show you how such architecture is actually used in systems by looking at some application examples. This should give you a better idea of what kind of architecture to choose for what systems, and how to apply the architecture.
Application Example 1: Remote Maintenance
This type of IoT system connects to machinery such as construction equipment or machine tools via the internet for remote monitoring or maintenance.
This type of system has been in use since the early stages of IoT systems. KOMTRAX by Komatsu, a leading manufacturer of heavy machinery, is a prime example.
Real-time M2M equipment control systems continued to advance steadily over the years. However, since the arrival of cloud technologies, the number of systems in which customer’s devices are monitored by manufacturers in more open environments with a broader range of applications has increased.
These devices are generally large and comparatively high in price, and most notably tend to be intelligent devices capable of operating independently. Such devices usually have a built-in operating system, and in almost all cases operating status and logs can be obtained directly from the OS. Even if devices do not have a built-in OS, all that is required is to attach an external IoT gateway. This method is used to monitor movable equipment, as well.
The main points of this example are as follows:
- The devices or gateway is high-performance and usually has a built-in OS.
- The system handles large amounts of data and requires a high level of security for data transfer.
- The network environment is generally 3G/LTE.
As for the system architecture, as there is almost always an OS, data transfer is carried out Device-to-Cloud, in which the data is transferred directly from the device. There are various methods of data transfer which can be divided into two general types. The first transfers data from the device as needed using push technology and collects and visualizes the data in the cloud. The second aggregates data on the device and then sends it to the cloud.
For the type that transfers data as needed using push technology, MQTT is well-suited as the protocol. If just understanding the overall condition is sufficient, even if there is some data loss, then there is no need to worry about data control, either.
The type that gathers data and then sends it generally collects the data into files and uses protocol for file transfer, such as FTP. In this case, a system must be arranged to process resending in the case of error during transmission, sending a notification to an application on the cloud when the transfer has finished, and so on.
- Architecture used: Device-to-Cloud, Using Gateway
- Protocol used: MQTT, FTP, HULFT
Application Example 2: Image Inspection
In the manufacturing field, there is increasing use of systems relying on images for quality inspections and the checking of processing conditions during processing, rather than the eyes of skilled workers. There has also been an effort to use machine learning, in particular, deep learning, to turn the know-how of skilled workers into algorithms, and thus overcome the difficulties of inspecting all items that are limited, in reality, by man power.
With this type of system, the application is often configured on the device for the sake of processing speed, and the processing is completed on the device. However, there is also usually the need to upload and accumulate the data in the cloud for analysis of the results.
In this case, the high-resolution image data must be transferred to the cloud without any data loss. And just sending the images is not enough. Processing to combine the images with metadata to identify each picture as the correct product is also required.
The main points of this example are as follows:
- The images are usually processed on the gateway or PLC first and then transferred.
- The images are compressed only during transfer.
- The network environment is generally LAN or WAN.
Although models of camera that can connect directly to the cloud do exist, usually the data is transferred after image processing, so this type of architecture uses either Using Gateway or Using Server. Because the data is transferred as-is in files, this type uses protocol for file transfer, such as FTP.
Naturally, the files must be compressed, but as was mentioned in the description above, if the files are collected and compressed on the device, the burden on the device is heavy. Therefore, DEFLATE compression, which compresses only during transfer, is highly effective. After transfer to a cloud is done, it is common to decompress the data before storing it in order to make future processing easier. In this case, a function to carry out decompression of the files after a transfer is necessary.
- Architecture used: Using Gateway, Using Server
- Protocol used: FTP, HULFT
A Wide Range of Applications
In this guide, we looked at some concrete examples to give you an idea of how the architecture and protocols we introduced up to this point are applied.
However, the examples we have given are only examples. In actual application, the architecture is likely to be more complicated, and different protocols chosen for various uses. Regardless, the types of architecture introduced in this column should help you to recognize different segments of an overall system, and help you grasp the basics faster.
Conclusion
IoT systems are sure to diversify from here on, to meet the many, varied needs of the future. As they do, the birth of new architecture and new protocols may follow. IoT will remain a field to keep a close eye on.
About the Authors
This guide was created by the HULFT Development Team. We produce various middleware for data integration, including for IoT scenarios. To learn more about what we’re working on, please visit hulft.com.
