IoT Reference Architecture: In Search of a Universal Solution

What Are the Standards For?

When technology is being actively taken up en-mass by consumers, it is time to standardize it. The whole world of technical products needs to be classified to prevent chaos. However, even now, there is a lack of a clear system due to a redundant number of standards and the involvement of different organizations in the same field. All this makes the choice for the correct IoT structure tough.

In the case of the Internet of Things, the use of standards becomes an important factor for dealing with large state and commercial customers.

Due to a lack of clear standardization, the IoT architecture is tacitly associated with those existing standards that are most likely to be appropriate. Currently, these standards are represented by two generally recognized organizations – IEEE (Institute of Electrical and Electronics Engineers) and IEC (International Electrotechnical Commission). The main difference between them is that IEEE is popular in the USA and ISO/IEC in Europe. Both standards were taken into consideration in 2014 and this process has continued. Eventually, however, it is only natural to expect that the architecture for IoT projects will be reduced to a common denominator.

Want to develop an IoT solution?

Share your project details and get a free quote.

Aleksandra Golik
Head of Sales
at HQSoftware

Get a Free Quote

IEEE and ISO/IEC

IEEE focuses on issues of dependability and security in the IoT area.  The fact that such ‘monsters’ of industrial automation, such as Cisco, Emerson, Siemens, Toshiba, Hitachi, Huawei, and other large corporations are involved in the development of the standard, proves this direction.

The ISO/IEC standard is borrowed from related and already standardized areas, such as:

• Home electronic systems described in ISO/IEC 14543;
• MPEG-V architecture for media context and control, described in ISO/IEC 23005;
• Sensor Network Reference Architecture (SNRA), described in ISO/IEC 29182.

Usual Architecture Which a Majority of Iot Development Companies Prefers to Use

The presence of sensors in IoT technology enabled the use of the SNRA sensor architecture as a basis for IoT development. We can see the following IoT structure born from the SNRA ISO/IEC 29182 standard, which is based on 4 or 5 typical levels: devices, network, service, and application. In effect, the standard has been reinforced in terms of the IoT, albeit undergoing a few changes.

• Level 1 of the IoT architecture introduces a set of network items as wireless sensors, beacons, actuators, and others.
• At Level 2, the devices aggregate data, using special gateways.
• At the 3^rd level, the received data is pre-processed.
• At the 4^th stage, the data is processed as a final point and can be managed and placed in the cloud storage or server.
• There is the 5^th level but this is optional. It can initiate a user’s control, but in the case of full automation, the level is skipped.

In the IoT architecture, data processing can partly occur at each level. The processing of data can be rejected on each IoT device by analyzing data immediately using a sensor. This can be useful for matters of speed: the faster you need to acquire the information, the closer to the end device that processing should be. So, let’s look in detail at what happens at each level.

1. Devices’ Level – Sensors’ Hegemony

This structure is similar to any project’s skeleton, but the main distinctive element of IoT development is in the presence of multiple devices that monitor appropriate information and send it to the ‘brain center’ for analyzing and reforming into a readable, easy-to-use shape for end consumers. These devices can be introduced as sensors, beacons, actuators, or any transmitting and receiving gadgets.

So, unlike another developed system, the Internet of Things differs by its network concept: numerous small devices gather useful parameters to analyze them and then bring together on the smartphone’s or PC’s screens for future control or circle it in a closed automated system that will operate itself. In other words, sensors or actuators lie at the basic layer and dictate the complete Internet of Things concept.

Sensors collect data about the environment or the state of the object and turn that data into useful information. Actuators can make changes to the physical conditions of the object. For example, consider a simple variant – a smart bulb, which communicates with the entire Smart Home system to tell the system that it is either ‘on’ or ‘off’. The bulb has sensors that keep track of its status – “light” or “no light”. In fact, the sensors are unidirectional, and they only transmit information to the data processing center. Actuators operate in the opposite direction – they receive commands and enable the light bulb ‘to turn on’ or ‘to turn off’.

These commands could be given by the owner of the house remotely, for example, via a mobile application, or the system can be automated and work itself. Take as another example of smart gates. We can open/close them by using a mobile phone, or the gates can be programmed to catch the Bluetooth signal from the owner’s phone when en-route and located in the defined radius, and then to take a particular action.

Sensors can also be put in place to measure indicators that are part of different intelligent systems, such as water level, temperature, air quality, acceleration, heart rate – whichever is appropriate for a specific activity.

In part, IoT’s capabilities have expanded thanks to low-power wireless sensor network technologies and Power over Ethernet, which allows devices in a wired LAN to operate without the use of a separate power source. This is one of the smart technology advantages in the context of the Internet of Things.

2. Transforming Level – Gateway

Initially, the data from sensors could be in analog form, before the data is aggregated and converted into digital streams for processing. The gateway performs the functions of aggregation and data transformation. It connects to a network of sensors, combines outputs, performs the analog-to-digital conversion, and adapts it to the required format for the further levels of the system. The gateway receives aggregated and digitized data and routes it by wired or wireless networks (Wi-Fi, Bluetooth, etc.) for further processing.

Systems at the 2^nd level are often located in close proximity to the sensors. For example, a pump may contain dozens of sensors and actuators that send data to aggregation equipment that is digitizing the data. In this way, the gateway is connected to the pump. The gateway processes the data and transmits it to Level 3 and Level 4 systems.

Why should we process data at this level?

• Division

The reason why data should not be sent to the processing center in a large stream is that the analog data has certain time and structural characteristics that require processing by specialized software. It is better to first convert the data to a digital form in stage 2, and then to work with a convenient format at all stages.

• Digitizing

Data streams coming from sensors create large amounts of data. Just imagine how much sensor data a complex mechanism such as an aircraft engine can create over the course of a day. There is no theoretical limit to the number of sensors that could compile data within an IoT system. Moreover, the IoT structure is always on, providing permanent communication and data transmission. Therefore, it is better to pre-process data directly when reading from the sensor in order to simplify the entire process and have the opportunity to intervene at the appropriate stage if something goes wrong.

The intelligent gateways can also use additional basic functions, including analytics, data management services, and protection from harmful software. These systems allow the analysis of data streams in real-time.

Gateways are peripheral to the data center, so they are wearable and could be used in any location. Considering the example of the pump, if we have 100 pump aggregators and want to process the data directly at the location, we can get data instantly right at the pump level, and here, at the gateway, aggregate the information and provide it as an output to the target device. Gateways are usually designed for carrying or being mobile, for smooth installation, and have a rugged body to resist changes in temperature, humidity, dust, and vibration.

3. Edge It Level – Empower Software Developers

The first 2 levels work mainly at the hardware level, but from the 3^rd one, information technologies begin to take over.

The data center is the prevailing item at this level because edge IT systems come into effect. Edge IT processing systems can be located in close proximity to both sensors and a gateway in order to respond to requirements from the server, which has to turn to them from time to time, for example, when the cloud or the data center is unavailable. Nevertheless, sometimes developers skip this stage, merging it with the 4^th level.

To the degree that IoT data can easily absorb network bandwidth and overload the channels of the data center, it is preferable to have systems that will separately perform analytics and reduce the load on the IT infrastructure. Issues relating to security, storage, and delays in processing are also problems that can be addressed. However, with a step-by-step approach, we can pre-process the data, and generate and transfer only those parameters that are needed by an end system. For instance, we can collect predictions about when each device will fail and be in need of maintenance. This means such an approach allows for the filtering of the compilation of information, depending on particular needs.

4. Data Center / Cloud Level – Files’ Habitat

Here, data is processed into a final form for the purposes of information storage. To compile the data, both the server and cloud storage can be used. The movement and processing of data at this level can take a lot of time because we are dealing with a large flow of information. Therefore, as we have mentioned before, splitting the information stream is important to convert data at each stage into an understandable format and for information to be structured in order to simplify any potential debugging afterward.

5. User Interface Level – Retroaction

This level can be absent if the IoT project is completely automated and any tasks are executed automatically. In that case, the system doesn’t require manual control or intervention until the system needs maintenance.

When considering the whole structure, we can see that the direction of data and commands are not unidirectional and may act in the opposite direction. The user or consumer level the upwards data flow route – it closes the chain of challenges that the system solves – but it also acts in reverse by allowing information to be sent down to the actuators level, when a user, for example, sends commands to actuators to perform some actions via a mobile device or a web app.

Bottom Line

To sum up, the IoT architecture is usually built according to the concept described above. However, some levels can be merged, making the structure simpler. This, in fact, reveals the difference between the standards. Everything will depend on what level something is operating at and their components will be taken as a template. So, the expected standardization may result in the emergence of an average characteristic taken from the flexible structure development process that is used in different IoT solutions, depending on the end goals and tasks. Therefore, IoT architecture may ultimately have to handle a variety of alternative structures that all possess elements of its own traits.