Evolutionary approach to an IoT architecture for smart, connected products

As the Internet of Things is gaining its momentum, more and more businesses consider enhancing their activities with smart, connected products. Launching such products can bring multiple benefits. For customers, this involves a broad spectrum of improvements, from enhanced monitoring of products' performance and the external environment (based on the data gathered from sensors) to delegating certain stages of production (or even the entire production cycle) to smart, connected equipment. At the same time, vendors of smart, connected products get new revenue streams and gain a competitive edge.

However, real benefits can be achieved only with the right approach to the IoT development. In this respect, for every enterprise that is planning to implement smart, connected products, there is a crucial point to focus on – an IoT architecture. In our new article, we'll try to shed light on how to make it a solid basis for the effective operation of a smart, connected product depending on the expected outcomes from using such a product.

Short summary:

• The evolution of a smart, connected product explained
• IoT architecture to enable product performance and evolution
• The distribution of functions between embedded and cloud software

Maturity levels of smart, connected products

Depending on the capabilities, smart, connected products differ in their maturity levels, (as defined by Michael E. Porter and James E. Heppelmann): monitoring, control, optimization, and autonomy. An IoT architecture should be designed to support these levels.

A company can implement a smart, connected product beginning with lower maturity levels (skipping some architecture blocks, for example, machine learning and, consequently, reducing the price of IoT development and implementation) and further expand it (when enough data is accumulated) to analyze the performance of a system, see how a product is used, identify the missing functionality and more.

In this respect, it's essential to make the initial IoT architecture flexible enough to allow advancing from lower to higher levels by adding modules without redesigning the whole solution, which can be called an evolutionary approach.

Monitoring

The 1^st maturity level - monitoring - allows looking deeper into connected products' operating conditions, detect deviations from the norms and give alerts. For example, with the help a smart, connected product's sensors, it's possible to monitor and report the state of equipment, trace the conditions of the production flow and take measures to avoid the influence of the external environment. Monitoring gives every party that deals with a smart, connected product (a vendor, a customer and a third-party service organization, if any) better visibility of how a smart, connected product is used and prompts which functionality should be added to a product. Every party should have the corresponding degree of access to monitoring. The parties should predefine such degree in a service-level agreement. Monitoring can also be used to test prototypes and uncover vulnerabilities in machinery and vehicles before they’re released to users.

Control

Smart, connected products can be controlled through remote commands (given by a product user or a product provider) or with algorithms (in the software installed either right on a smart, connected product or in the vendor's cloud).

Even in automated control, both these options are needed - control apps may fail to perform the required operations (or perform them not as expected). Shifting to manual control saves users' assets in such emergency cases.

Besides, a smart, connected product may need to be integrated into a customer's local systems (for example, SCADA, MES) – to successfully perform its functions as a part of the production processes.

Another critical issue is that the control over a smart, connected product is split between a vendor and a customer (and, sometimes, a third-party service organization), and the peculiarities of controlling a smart, connected product should be defined in a service-level agreement.

Optimization

The combination of monitoring and control capabilities brings new opportunities to optimize production processes. Big data coming from sensors can be then used to help identify discrepancies between the expected and real performance and uncover inefficient processes.

Real-time monitoring and product control open an opportunity to conduct predictive maintenance and remote repair that help to reduce downtimes and maintenance costs.

Autonomy

The three previous levels, combined and tuned to support each other, enable smart, connected things act with little or no human participation. However, it's not real autonomy – such products need to be coordinated with other products and systems used by a customer. Still, it's a serious step towards a scenario when even the whole factory can work automatically, conduct self-testing and maintenance, learn from the environment and adapt to users' preferences.

Elements of an IoT architecture for smart, connected products

Below we provide an example of a scalable IoT architecture that would allow adding the elements required to achieve the desired maturity level. 

Data gathering

A great deal of the benefits that smart, connected products (SCP in the scheme) may bring come from big data generated by sensors. Sensors (either physically attached to smart things or located in the proximity to monitor the environment of smart, connected products, processed materials and so on) have pre-defined roles in data gathering. For example, in the pharmaceutical industry, sensors can help to monitor the quality of raw materials and medications at different production stages (measuring the temperature, density and other parameters of substances). Also, sensors can get the data about the current state of pieces of equipment, the speed of rotation of mechanisms and so on.

Data filtering and storing

As sensors regularly generate vast volumes of big data, it makes sense to filter the data, which can be applied for useful insights out of the whole stream – and a gateway can do it.

Filtered data is then transferred to the cloud through a cloud gateway. The gateway also transfers the commands that come from control apps to actuators. A streaming data processor allocates incoming data between other components of the solution architecture.

The data is aggregated in a big data warehouse. It makes sense to add a data lake to the solution to accumulate all the data a company plans to use in the future and thus separate potentially useful data from the data with the already proved usefulness.

Controlling smart, connected machinery

Smart, connected products can be controlled remotely either with mobile and web user apps or by control apps (automatic control). In automated production, both these options are needed, because due to possible breaks in an IoT system or mistakes in control apps' algorithms, control apps may fail to perform the required operations (or perform them the wrong way). Manual control can save the situation (as well as the user's equipment, products and reputation).

Automatic control. When sensors generate the data that requires immediate reaction (too high temperature, too low pressure, an excessive concentration of a particular component in raw materials), control apps send commands to actuators to take corrective measures as early as possible (for example, to reduce heating, to add pressure). Such a strategy helps to save time and money for every party dealing with a smart, connected product (a vendor, a customer and, in some cases, a third-party service organization).

Manual control. As soon as a vendor and a customer (and, in some cases, a third-party service organization) share the control over a smart, connected product, and each party has a different level of access to a smart, connected product's functionality, it makes sense to create separate apps for each party. For example, a vendor will benefit from the user apps featuring the maps of equipment and sensors, which would enable monitoring thousands of pieces of equipment scattered across various factories and even cities and countries. A customer, on the other hand, would needed the apps to monitor smart, connected products installed at his site only.

The fact that smart, connected production equipment can be controlled remotely with apps generates the concern that third-party users can interfere with the connected things’, which may lead to unfavorable outcomes. Thus, the control of which things are connected to the network and who can manage these things becomes of crucial importance.

When various users control the same smart, connected things, it makes sense to consider role distribution and configure user access levels. When contradictive commands come from various users, the commands given by a user with a higher seniority level will have priority.

Post-processing applications

Apart from the applications that function permanently, there are the apps that run periodically, for example, once a day or month and process data in a batch mode. A very typical example is the apps for usage-based billing that "prepare" bills for customers on a monthly basis taking into account the data about how products and services were used.

Data analytics

Data gathered from sensors that survived all the stages of filtering can be used to uncover usage patterns, detect pre-failure states, display performance stats in informative and well-digestible ways (schemes, diagrams, charts).

Machine learning

With machine learning, an IoT system offers models that can improve the functioning of the control apps. The models for the control apps are regularly updated (for example, once a week or once a month – depending on a particular case) using the historical data gathered in a big data warehouse. However, before new models can participate in controlling a smart, connected product, they should be tested and approved (and adjusted, if necessary) by data analysts.

Distribution of functions between device software and cloud applications

Another vital architecture question is to decide what features will be embedded in a smart, connected product itself (embedded software), what components will be cloud-based, as well as what should be included in the device and the cloud simultaneously. Several factors influence this choice.

Response time. When quick responses are a crucial safety requirement and a critical issue for the production process (for example, emergency shutdowns in a smart factory), the software should be embedded in the physical product.

Network reliability and security. In emergency cases, connectivity may become unavailable, and users may lose control over a smart, connected product. So, when the malfunctioning of the latter may be too dangerous (for example, in a smart chemical plant), it's better to embed software into a connected thing. This approach also has a positive impact on security concerns as soon as less sensitive data is transferred to and from the cloud applications.

Cost. The more functionality is included in the product itself the higher is the cost of such a product. To reduce the costs of an IoT solution, some functionality can be moved to the cloud.

On a final note

Smart, connected products have the potential to take company's daily operations to a whole new level. For example, in the industrial sector, they can contribute to every stage of production processes. However, to ensure the success of such IoT initiatives, an IoT system should be built on a reliable architecture. Such architecture should provide smooth and effective data-related processes, correspond to security requirements and allow changing and adding capabilities when necessary. Apart from internal architecture, a smart, connected product should be integrated into process control on the SCADA and/or MES level.

Although a smart, connected product is intended for a customer’s business, a vendor (and, in some cases, a third-party service organization) also has certain access to monitoring and controlling a smart, connected product (the degree of such access for every party involved should be predefined in a service-level agreement).

Pursuing the goal to uncover IoT potential to the fullest, it's possible to start with a simple IoT solution and, if its core works fine, upgrade it to higher maturity levels by adding new modules and modifying the existing ones.