The current trend of automation and data exchange in manufacturing technologies is often called Industry 4.0 or the Fourth Industrial Revolution. This new era of industrialization is characterized by integrating cyber-physical systems, the Internet of Things (IoT), artificial intelligence (AI), and big data analytics to gain a competitive advantage. In this aspect, the data generated by IoT devices and other sensors has a huge impact on businesses. These insights can be used to optimize production processes, reduce downtime, and improve product quality. Furthermore, data analytics can help companies to identify new market opportunities, develop new products, and improve customer experiences. Nevertheless, even with the extensive accessibility of tools and technology, creating intelligent applications within the industrial framework still poses a challenging and costly undertaking. This paper proposes a lightweight framework that can facilitate the adoption of IoT and IIoT solutions in industry and domotics. The framework is designed to be extensible, scalable and declarative, thus allowing for a wide range of configurations with minimal user efort. We successfully adopted the system in real-life use cases to prove its applicability. We consider this a significant contribution because it paves the way for more widespread adoption of IIoT-enabling technologies in the industry.
Industry 4.0 brings smart factories at the center of the technology spectrum [
This is true in domotics, where appliances are often not IoT-enabled and, therefore, require tools that can bridge the gap toward the goal of integration and remote control. However, it is especially true in industry. In fact, industrial machinery is not always equipped with sensors and/or actuators. Even when some sensors/actuators are available, they may not exhaust the needs of all possible IIoT scenarios. Sensors tend to be expensive and often dificult to configure when available. Finally, industrial sensors are usually not cloud-enabled and fail to meet the Big Data requirements discussed above.
Consequently, IIoT applications tend to be complex monolithic projects with high investments
and increased design time. To facilitate the adoption of these technologies, we introduce IoT
Helper [
In the paper we present two concrete application scenarios: The first one is a typical domotics application for controlling the fan of a fireplace extractor chimney. The second one is a complex industrial application with respect to monitoring welding pliers of a robot arm.
This section introduces the IoT Helper architecture for monitoring and controlling embedded devices. The flexibility of the approach allows for a very straightforward integration of such devices into cloud-computing architectures easily, but it can also be used in fog-computing or even edge-computing solutions.
Figure 1 shows the core of our proposed architecture. It is composed of the following: ) An
Embedded System [
At the core of the Embedded System is the Arduino module [
To achieve high extensibility and improve usability, the Embedded System needs to be easily
Embedded System Sensors and Actuators Message Broker messagesSubscribe Generic Firmware Publish messages
Configuration
Module Communication
Library Quality Control
System Communication
Library Predictive Maintenance
System configurable. We model sensors as generic inputs and actuators as generic outputs. The list of the sensors and actuators defines the interface of the embedded system, which can be observed as a black box. An external system that wants to communicate with the Embedded System needs to know only its interface without knowing the actual implementation, which might change over time. This approach allows for the creation of loosely coupled systems.
For example, suppose that we want to collect data from an analog temperature sensor and to control the electrical relay of an air conditioner. The interface of the Embedded System is an analog input temp, and a digital output ac. An external system, such as a mobile application that wants to read the sensor and control the actuator, will send a generic message "read input temp" or "change the output of ac to 1" without knowing any details about the physical connections on the embedded system or the actual circuitry of the sensors. As a consequence, we can change how the embedded system physically controls air conditioning from an electrical relay to an infrared actuator, keeping the interface unchanged without changing the user application.
The Configuration Module describes the inputs and the outputs managed by the embedded system. Each input is represented by the following: (i) the type, i.e., if it is analog or digital; (ii) a unique ID used in the firmware for controlling it; (iii) a description that is useful for documentation and human interpretation; and (iv) the pin(s) where it is connected to the embedded system. Each output is represented in the same manner as the input; however, in addition, since it represents an actuator, we also store information about the allowed values.
Table 1 contains a sample configuration. In this example, we have one temperature sensor with the name "1". In addition, we have two actuators: a digital LED 1 that can be switched on and of (values 0 or 1); and an analog fan controller 2 that accepts values from 0 (of) to 6 (maximum speed).
The Configuration Module also allows for specifying network parameters in order to connect the Embedded System, typically to a WiFi network. All of the configurations are stored on file on an external SD card.
The basic operations executed on the inputs and output are as follows: (a) read an input value as the state of a sensor or actuator and (b) change the value of an output, i.e., execute an action on an actuator. Generic Firmware executes such operations with the following commands: • Read—read values of inputs 0 . . . . For example, read temperature and humidity values from the respective sensors. • RepeatRead—read of inputs 0 . . . each milliseconds. This is useful when we need continuous read operations with a fixed frequency. This command accepts a parameter representing time in milliseconds. This command is used to regularly collect data from the Embedded System and allows one to minimize the number of requests sent to the system. • Write—change values of output 0 to 0, . . . to . For example, switch the LED on and set the speed of the fan to four. • TimedWrite—change values of outputs after a fixed delay . For example, switch of the fan in two hours.
When the system starts, the Generic Firmware runs some initialization operations: (1) it reads the configuration file, (2) it configures input and output pins, (3) it starts the WiFi connection, (4) it initializes the connection with the Message Broker and (5) it starts a timer for timed commands.
After initialization, Generic Firmware waits for commands and executes them. Each command is received as a request message and generates a response, as discussed in Section 2.1.
The final model we discuss is the Message Broker. It handles the exchange of messages among client apps and the Embedded System, according to the formats described in Section 2.1.
We adopt a Publish and Subscribe (P&S) communication model [
The main benefits of the P&S approach are that the embedded systems do not know any other external application but communicates only with the message broker. Adding new subscribers will not need to modify the publisher’s behavior when they join the architecture. In addition, publishers and subscribers do not need to be online and ready simultaneously. Still, the embedded system can publish new data as soon as they are ready without waiting for the clients. This allows achieving better performance in real-time applications. Finally, the only component that needs to be reachable is the Message Broker. This can be easily obtained by installing the module on a public server or by using a cloud solution.
In our architecture, we used two channels: (i) the data channel that manages read operations, i.e., this channel is used to publish sensors data from the embedded system to the broker; and (ii) the command channel that stores commands that come from external systems or devices to the embedded system. In essence, from the point of view of the embedded system, it registers itself as a subscriber to the data command channel because it needs to receive messages, process them using Generic Firmware, and execute the corresponding operations. Generic Firmware also registers itself as a publisher to the data channel because it sends out input values. The Message Broker registers itself as a publisher in the command channel because it dispatches messages to the embedded system and registers itself as a subscriber to the data channel in order to receive data from the embedded system. The complete architecture is depicted in Figure 1.
Any other external system, such as a database, a monitoring system or an anomaly detection system, can be easily added to the data and command channels. The external device registers itself as a publisher for the command channel and subscriber for the data channel. In this manner, it can send messages to the embedded system and receive data from the sensors. Of course, any other embedded systems can be plugged into the network using the same mechanism.
Communication between the embedded system and other devices difers depending on the type of interaction. Data and command channels physically separate messages exchanged by the systems. This brings significant advantages in terms of simplicity, scalability and performance.
The command channel is the one used to send requests to sensors or actions to the actuators. Data format contains the following: (1) the command typology and (2) sensors/actuators involved. The format of a request is the following: /COMMAND_NAME/LIST_OF_SENSORS_ACTUATORS&TOKEN where • COMMAND_NAME represents the requested action that we have already discussed, and the values are read, repeatedRead, write and timedWrite; • LIST_OF_SENSORS_ACTUATORS represents the name of sensors and actuators to which we want to send the action. Sensors or actuators are separated by the special character "&." Moreover, the name used is the one used in the configuration step; • TOKEN represents a key to match diferent request–response pairs. Since communication is asynchronous, there is the need to correlate the response to the request. In real-life scenarios, multiple clients might send requests simultaneously, and since they will wait for the response on the same channel, they need to filter the response. For this reason, in the request, the client generates a unique (or random) token that will be included in the response.
Commands cannot be mixed, i.e., send read and write operations cannot be combined at the same time. For example, we have the following commands: #1 /READ/I1&I2&TOKEN=T001; #2 /WRITE/O1=1&02=255&TOKEN=T002; #3 /TIMEDWRITE/TIMER=100&O3=1&TOKEN=T018.
Command #1 represents a reading example from two sensors (1 and 2) associated with a unique token 001. For example, 1 and 2 could be, respectively, temperature and humidity sensors. Command #2 represents a written example to two actuators (1 and 2). For each actuator, we specify the value to send. With respect to digital actuators, the admitted values are zero or one (such as 1). For analog actuators, the admitted values depend on the actuators themselves. 2 is an example of an analog actuator, and we send a value of 255. Finally, command #3 represents a timedWrite operation on actuator 3. The operation is executed after 100 seconds. For each of the above commands, a token identifies the corresponding request generated from the client.
After command execution, the response is published on the data channel. The response depends on the request type. If the command is a read type, then the response contains raw data acquired by sensors. If the command is a write type, then the response contains information about the received message. Figure 2 contains example of possible responses. { " d a t a " :
{ } " I 1 " : 2 3 , " I 2 " : 0 . 6 7 } , " t o k e n " : " T001 " , " timestamp " : " 2 0 2 1 0 5 0 6 T13 : 3 8 : 0 0 " { " d a t a " :
{ }
" r e s u l t " : " SUCCESS " } , " t o k e n " : " T002 " , " timestamp " : " 2 0 2 1 0 5 0 6 T13 : 3 9 : 4 1 "
This section presents two real use cases: a small application for monitoring and managing the fan of a fireplace extractor chimney and an industrial application used in the ICOSAF project (PON R&I 2014–2020) to control a resistance spot welding process.
We deployed this app for a small factory that produces extractor chimneys. The final goal was to turn their traditional chimneys into smart appliances by allowing remote control from a mobile application. The deployed architecture is shown in Figure 3.
Since the product was designed to be used by final users, we had several conditions to meet: 1) The additional hardware cannot be expensive in order to avoid a significant increase in the market price of the chimney; 2) The chimney needs to be accessible both at home, i.e., from the local WiFi network, or from outside, i.e., from the internet; 3) Configuration and installation steps need to be as easy as possible, without the need of an IT expert.
Since the chimney has six fan speeds, we represented them as six actuators on the Embedded System. In addition, we connected two sensors to monitor temperature and humidity in the proximity of the chimney. This allows us to create simple rules to change the speed of the fan based on the chimney status. For example, “turn on the chimney when the temperature is higher than 28 ∘ C.”
For the Embedded System, we used Arduino Mega 2560 because it has a good balance between RAM size (256 KB) and price. To enable system discovery over the network, we used the Zero Configuration Network protocol by using a Bonjour implementation for Arduino (https://github.com/adafruit/Adafruit_CC3000_Library).
For the Message Broker, we opted for Software-as-a-Service (SaaS) solution, PubNub. This provides two important benefits: (a) since it is based on cloud architecture, it ofers potentially unlimited scalability, and (b) it reduces the costs of dedicated hardware and maintenance.
Finally, for the remote control, we implemented diferent client versions: a Java desktop application and two mobile versions (one for Android devices and one for iOS devices).
We also tested the efectiveness of the approach in an Industry 4.0 scenario. The experiments were conducted with Centro Ricerche FIAT (CRF) within the activities of the “Integrated Collaborative System for Smart Factory (ICOSAF)” Project.
The main goal of the experiment was to support quality assessment on Resistance Spot
Welding (RSW) used to assemble car body parts. A typical car contains more than 5000 welding
spots of diferent materials and thicknesses. Assuring the quality of this process is crucial to
guarantee the solidity of the assembled vehicle. Several ofline and online tests were proposed
to evaluate the quality of the final welded workpieces [
The quality control process starts with an operator that places a welded workpiece on a custom workbench. This bench is designed so that all the welding spots are reachable by a collaborative robot (cobot) provided with an ultrasound probe that will read the dynamic resistance curves of the spots. Before starting the probe, it is important to verify the correct placement of the workpiece. Since it has a very flexible and uneven shape, it is hard to fasten with clamps. Reading data from a misplaced location will generate dirty data that might negatively impact the quality check algorithm.
To overcome this problem, we placed several digital position sensors in correspondence with
the contact points between the shape and the bench, as shown in Figure 4a. These sensors are
then wired connected to an Arduino Mega 2560 that runs IoT Helper. The operator will check
the sensors interacting with a custom controlling software that will communicate with Arduino
using our library. Using an HMI, the operator starts the process. The controlling software will
publish a READ command for all sensors to the Message Broker. After receiving the sensor
states, if all of them are evaluated as pressed, the cobot is started. The dynamic resistance
curves of the welding spots are then read and stored in order to be processed using quality
assessment techniques. From the architectural point of view, we adopted a hybrid approach by
using edge computing to control the sensors and the cobot while dynamic resistance curves are
processed on a cloud architecture. Since the company has strict security policies, we cannot use
a SaaS solution for the Message Broker, so we opted to deploy a local Message Broker based on
the MQTT protocol [
We presented IoT Helper, a lightweight, generic framework for IoT and IIoT applications. As discussed, the main contribution of IoT Helper consists in the generic architecture that allows users to quickly prototype smart applications both in domotics and industrial scenarios. We introduced two such scenarios in which the framework has been tested with success and reported experimental data that show how, despite the high flexibility and low costs that come with the framework, it was able to handle a large volume of data and scale up nicely to real-time applications.
IoT Helper was conceived to simplify data collection, and it fits nicely into data analytics application scenarios. We believe that such a framework could be used also in medicine to collect data for ML algorithms [19, 20]. An interesting direction to extend the framework would be to integrate basic analytics features into the firmware in order to enrich and improve the generation of indicators during usage and possibly predictions based on simple machine learning models in order to push analytics to the edge of the architecture. This would have clear benefits in terms, for example, of anomaly detection and robustness of the solution. Systems Software and Middleware and Workshops (COMSWARE’08), IEEE, 2008, pp. 791–798. [18] M. Bender, E. Kirdan, M.-O. Pahl, G. Carle, Open-source mqtt evaluation, in: 2021 IEEE 18th Annual Consumer Communications Networking Conference (CCNC), 2021, pp. 1–4. doi:10.1109/CCNC49032.2021.9369499. [19] P. Lapadula, G. Mecca, D. Santoro, L. Solimando, E. Veltri, Greg, ml – machine learning for healthcare at a scale, Health and Technology 10 (2020) 1485 – 1495. doi:10.1007/ s12553-020-00468-9. [20] P. Lapadula, G. Mecca, D. Santoro, L. Solimando, E. Veltri, Humanity is overrated. or not. automatic diagnostic suggestions by greg, ml, Communications in Computer and Information Science 909 (2018) 305 – 313. doi:10.1007/978-3-030-00063-9_29.