IoT architecture - first look under the hood

The concept of IoT (Internet of Things) has long been included in the lexicon of IT-Schnick. Although I did not find such a hub, but I hope it will be fixed soon :)

However, until now many people confuse the IoT architecture with the automation architecture, where the main task is to obtain information from sensors and based on them control of actuating mechanisms is carried out.

The IT architecture includes two seemingly incompatible things: on the one hand, it is a large number of peripherals with low computing power, low power consumption, high reaction speed to events, and on the other hand, cloud servers with high computing power for processing large data sets, their storage and classification, often with elements of machine intelligence and analytics. These two worlds use completely different principles of construction and internal architecture. They look incompatible and today there are few specialists in the labor market who know the Embedded and Cloud solutions equally well. This is a kind of “full stack”. But in this knowledge lies the power that unites the two, at first glance, completely unrelated technologies. From their integration, we get an amazing synergistic effect. It is like the union of a man and a woman — rough and strong, subtle and weak. In this article I will try to describe the basic architecture of IoT, considering the application “as a whole”.

The figure below shows the overall architecture of the IoT solution. It is quite predictable that everything starts with sensors. Moreover, the better the sensor is suitable for performing its task, the more efficient the system will be. This is a kind of “cornerstone” system. It is important to note that the sensor registers the change in the environment, and not its static state. Sensors are divided into active - emitting signals themselves and receiving reflection; and passive - working only at the reception. Naturally, the latter significantly benefit in terms of energy consumption. Most sensors are based on the reception of waves - sound, ultrasound, light of various ranges, heat. However, there is a category of sensors based on changes in their physical characteristics, such as inductance, capacitance, pressure. Good results are obtained from a combination of several sensors, such as a PIR detector and a capacitive sensor for detecting movement.

In any case, the sensor generates an analog signal that needs to be digitized for further processing, which is what the AtoD converter does. After receiving the digital information, it must be processed by the local processor of the peripheral device. Its main task is to put down the tag of the received information or simply classify it. Tags can be simple, as for example - there is movement, and more complex - movement + speed. Sometimes you need multidimensional tags - Motion, Machine. The more complex the tag, the more naturally the power of the peripheral processor and, accordingly, the power consumption. On the other hand, the more informative the tag, the smaller the required amount of information transmitted to the cloud and, accordingly, less bandwidth is needed, and the speed of response to an event increases. Of course, all tags have a timestamp mark.

The next link can be located both in the cloud and on the periphery, and sometimes in both parts. The switch redirects the received information to various objects, classifying tags. These objects can be server, queue, lambda or just storage. Until now, work was carried out with information from a specific peripheral device and in fact was no different from the work of automated control systems. However, at the next level, integration, a qualitative difference begins. Information from various peripheral devices is summarized by tags of the same type. However, the types of peripherals themselves may even be different. It is important that the tags get into a single point responsible for receiving the corresponding event - the tag.
In the future, information from all objects that summarize the tags is systematized by the Analytical Block. It is the main logic or, if I may say so, the brains of the system. There is AI, Machine Learning, and so on. The result of the work of the Analytical block is transmitted to the Presentation block for display to the user. It may look like sending a message to a mobile device, a schedule on a WEB or other.

Since the IoT system is distributed and connected by an unreliable communication channel, it is necessary to have mechanisms for guaranteed information delivery. In the event that it is not possible to transfer information from the peripheral device to the cloud, repeated transmission attempts are made. The same should happen in the other direction. For these purposes, the Virtual Representation Unit of the Peripheral Device is entered, into which information for transmission to the peripheral device or its new state is recorded. Often this is just a text file, but there may be a more accurate presentation model. It is noteworthy that changes in the Virtual Presentation module can be initialized from various modules of the input circuit, as shown in the figure.

After we have disassembled the physical block of the IoT architecture, we can consider its logic

So, everything starts again with sensors that record the environmental change over time. The following tagging module performs primary segmentation into certain system events. In principle, the development of the IoT application architecture should begin with a list of these events. The summation of tags is made according to the group of peripheral devices with similar tags. The integration module is designed to make decisions on approximation (prediction of subsequent events) or determination (identification of the situation from a variety of options). This information serves as a kind of key-coefficient for the module of the virtual model of the peripheral device, in which the actual information from the peripheral device itself is converted into a new state of the peripheral device on the basis of the key-coefficient.

Now a little about what did not fall into the architecture of the scheme described above, but of course it is worth bearing in mind:

• Storage of information . Information storage should occur, both at the level of the peripheral device, and in a cloud. The peripheral device saves its program, settings, status and temporarily stores information from the sensors, until it is guaranteed to be transmitted to the cloud. Cloud storage of information is obvious and does not require clarification, at least in this article.
• Security / Authorization Each peripheral device must be authorized in the system, and individually. This is a separate topic, which is also beyond the scope of this article.
• Queues and pipeline . A separate category of architecture is a means of transmitting information through the system, both inside peripheral devices and in the cloud and between them.

Hope this short review will be helpful. In the future, I plan to continue the article and make a nickname cycle dedicated to IoT solutions. I would appreciate all the comments and topics that will be of interest to you.