IoT architecture for smart, connected products: architectural components and evolutionary approach

As the Internet of Things is gaining its momentum, more and more businesses consider enhancing their activities with smart, connected products. The benefits provided by such products abound. For example, for customers, it’s the wide specter of improvements from enhanced monitoring of products’ performance and external environment (based on the data gathered from sensors) to the opportunities to delegate certain stages of production (or even the entire production cycle) to smart, connected equipment. At the same time, the vendors of smart, connected products get new revenue streams and upscale their competitive level.

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

Industrial IoT

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) each built on the preceding one: monitoring, control, optimization, and autonomy, and IoT architecture should be designed to support these levels.

A company can implement a smart, connected product beginning with lower maturity levels (skipping certain 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 lacking functionality and more).

In this respect, it’s important 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.

IoT maturity levels


The 1st maturity level - monitoring - allows looking deeper into connected products’ operating conditions, estimate their current state, 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 external environment influence. Monitoring gives every party dealing 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, which should be predefined and stated in a service-level agreement between these parties. Monitoring can be also used to test prototypes and uncover vulnerabilities in machinery and vehicles before releasing them to users.


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 – we’ll touch the reasons of choosing between these options below).

It should be noted, that even in automated control, both these options are needed - control apps may fail to perform required operations (or perform them not as expected), and shifting to manual control saves users’ assets in such emergency cases.

Apart from that, it may be needed to integrate a smart, connected product into a customer’s local systems (SCADA and / or MES) – to successfully perform its functions as a part of the production processes.

Another important control-related issue 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.


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 expected and real performance and uncover inefficient processes.

Real-time monitoring and product control open an opportunity to conduct predictive maintenance and remote repair services that helps reduce downtimes and the expenses on repairs.


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 pure autonomy – such products need to be coordinated with other products and systems used by a customer. Anyway, it’s a serious step forward to such a scenario when even a whole factory can work automatically, conduct self-diagnostics and servicing, learn from the environment and adapt to users' preferences.

Smart, connected product architecture components

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

Smart connected products architecture

Data gathering

A great deal of the benefits unlocked with smart, connected products (SCP in the scheme) 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 data gathering roles. For example, in the pharmaceutical industry, sensors can help monitor the quality of raw materials and medications at various production stages (taking the temperature, density and other parameters of substances). Also, sensors can get the data about current state of pieces of equipment, speed of rotation of certain mechanisms and so on.

Data filtering and storing

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

Filtered data are then transferred to the cloud through a cloud gateway. The gateway also transfers the commands coming from control apps to actuators. Streaming data processor allocates incoming data between other components of the solution architecture.

The data is aggregated in a big data warehouse. Also, 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). It should be noted that in automated production, both these options are needed – due to the breaks in an IoT system or the mistakes in control apps’ algorithms spotted too late, control apps may fail to perform required operations (or perform them in an inappropriate manner), but manual control can save the situation (as well as user’s equipment, production and reputation).

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

Manual control. As soon as the control over a smart, connected product is split between a vendor and a customer (and a third-party service organization in some cases), and each party has 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 enable monitoring thousands pieces of equipment scattered across various factories and even cities and countries, while a customer needs the apps to monitor only smart, connected products installed in his premises.

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’ operation and bring unfavorable outcomes for every party dealing with a smart, connected product. Thus, it’s necessary to control which things are connected to the network and who can control these things.

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

Post-processing applications

Apart from the applications that function on constant basis, 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 “preparing” once a month the bills for customers considering 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 for uncovering usage patterns, detecting prefailure states (and the conditions of using a smart, connected product that lead to such states), displaying performance stats in simultaneously informative and well-digestible ways (schemes, diagrams, charts).

Machine learning

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

Distribution of functions between device software and cloud applications

Another important architecture question is to decide which 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 into the device and the cloud simultaneously. There are several factors that influence this choice.

Response time. When quick responses are a key safety requirement or/and critical issue for production process (for example, emergency shutdowns in a smart factory), the software should be embedded in the physical product. Such an approach also helps to reduce the risk that bad connectivity will slow down response.

Network reliability and security. In emergency cases, connectivity may become unavailable, and users may lose control of 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 will be 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 these costs, some functionality can be moved to the cloud.

On a final note

Smart, connected products have the potential to upscale company’s daily operations, for example, in the industrial world, 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 – ensuring smooth and effective data-related processes, corresponding to security requirements and also allowing changes and adding capabilities when necessary. Apart from internal architecture, a smart, connected product should be integrated into process control on SCADA and/or MES level.

Although a smart, connected product serves 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 full IoT potential, it’s possible to start from a simple IoT solution and, if its core works fine, upgrade it to higher maturity levels adding new modules and modifying the existing ones. With such an approach, IoT implementation becomes fore successful, and a company stays in a more winning position in terms of the return on investments.

About the Author: Alex Grizhnevich

Alex is a process automation and IoT consultant at ScienceSoft, an IT consulting and software development company headquartered in McKinney, Texas. His 17+ years’ experience in IT and OT includes programming industrial microcontrollers, developing web and desktop applications, databases and document management solutions for oil & gas and logistics. Holding the degree in automation and management of industrial processes, Alex is now focusing on IoT and machine learning on sensor data.