Individual Environmental Risk Assessment and Management in Industry 4.0: An IoT-Based Model

: This paper addresses the design of a system to facilitate individual environmental risk assessment and long-term risk management in the Industry 4.0 work context. The solution is based on IoT to provide data related to workers’ exposure to hazardous agents (dust, noise, ultraviolet radiation, poor lighting, and inappropriate temperature and humidity) through a simple interface for employees and employers. The system includes a monitoring device and a server and performs employee registration, receives secure messages from the monitoring devices, shows information about the workers’ exposure, and triggers alarms when the measures reach or exceed the limits established by applicable legislation and/or standards. The system was tested in a controlled environment, and the results are presented in this work. Our solution is still under development, and in future stages, it will include a smartphone app for employees to check their exposures and the use of artiﬁcial intelligence on the server, which is expected to enable long-term planning by companies based on the analysis of employees’ health history and their exposures to hazardous agents.


Introduction
Occupational diseases are acquired through the exposure of workers to environmental risks in situations above the tolerance limits imposed by legislation. Environmental risks may be, for example, chemical agents, such as dust, and physical agents, such as noise, heat, and vibration. Occupational diseases are caused or aggravated by specific work activities, and they are characterized when establishing the causal link between the damage to the worker's health and exposure to certain work-related risks [1].
Every year, about 2 million people die because of work-related illnesses or workrelated accidents worldwide [2]. However, many work-related accidents and diseases are not reported because in several countries, especially in developing ones, there are no adequate data collection systems. Developed countries, in turn, do not notify all cases because of the existence of informal workers. Migrant people are more susceptible to informal and/or abusive work because they usually perform activities that require low levels of education, such as construction and agriculture. In addition, environments, where people feel pressured, are in general susceptible to accidents. The sectors of the economy where the highest death rates because of work occur are agriculture, forestry, mining, and construction [3][4][5][6].
When it comes to solutions to prevent occupational diseases, as new technologies are added to workplaces, new risks and opportunities emerge. Recently, the term Industry 4.0 has become very popular and can be defined as a new paradigm that has revolutionized manufacturing through the integration of different technologies [7,8]. Industry 4.0-related technologies have significantly impacted OSH because they can be used, for example, to provide systems for monitoring occupational risks and health conditions of workers in real-time. On the other hand, the number of jobs that are characterized by sedentary

Materials and Methods
We propose a system for monitoring the exposure of workers to harmful agents: dust, noise, ultraviolet radiation, poor lighting, and inappropriate temperature and humidity. The solution is composed of a monitoring device to be used by each person during the work shift and a server responsible for collecting and processing data. The server is also responsible for informing in real time whether the exposures to the harmful agents are within the daily exposure limit value, as determined by the current regulations, or not.
The criteria for choosing the variables to be monitored were as follows: • The relationship with risks common to different work environments and various professional activities, such as noise.

•
The possibility of embedding all sensors in a single monitoring device. For example, monitoring whole-body vibration or hand-arm vibration would require separate devices, due to the way these variables should be measured (sensor positioning).
The monitoring device may be built with all the sensors mentioned above or with just some of them, depending on the company and/or work environment where it will be used. In the future, other types of sensors can be added relatively easily to monitor different risks.
The devices send the acquired exposure data via Message Queue Telemetry Transport (MQTT) [30] over Wi-Fi [31] to the server. An overview of the monitoring system is shown in Figure 1.

Materials and Methods
We propose a system for monitoring the exposure of workers to harmful agents: dust, noise, ultraviolet radiation, poor lighting, and inappropriate temperature and humidity. The solution is composed of a monitoring device to be used by each person during the work shift and a server responsible for collecting and processing data. The server is also responsible for informing in real time whether the exposures to the harmful agents are within the daily exposure limit value, as determined by the current regulations, or not.
The criteria for choosing the variables to be monitored were as follows: • The relationship with risks common to different work environments and various professional activities, such as noise.

•
The possibility of embedding all sensors in a single monitoring device. For example, monitoring whole-body vibration or hand-arm vibration would require separate devices, due to the way these variables should be measured (sensor positioning).
The monitoring device may be built with all the sensors mentioned above or with just some of them, depending on the company and/or work environment where it will be used. In the future, other types of sensors can be added relatively easily to monitor different risks.
The devices send the acquired exposure data via Message Queue Telemetry Transport (MQTT) [30] over Wi-Fi [31] to the server. An overview of the monitoring system is shown in Figure 1. In Figure 1, two people are using the monitoring devices during the work shift. These devices are sending exposure data to the server, which is running an application that checks whether the measures are inside the daily exposure limit value to decide whether to send the proper alarm status or not. This information is used to turn on the green or red LED on the monitoring devices. A manager is verifying the measures related to workers' exposure and alarms on the system's website. He or she may also change some system settings, such as adding a new worker and binding him or her to a monitoring device. In addition, one employee is accessing the smartphone app to see his or her measures and limits. The system's website should only be used by managers or the OSH team. Employees must check their exposure data on the app that will be developed in the next stage of the work. Our system architecture is described in more detail below. In Figure 1, two people are using the monitoring devices during the work shift. These devices are sending exposure data to the server, which is running an application that checks whether the measures are inside the daily exposure limit value to decide whether to send the proper alarm status or not. This information is used to turn on the green or red LED on the monitoring devices. A manager is verifying the measures related to workers' exposure and alarms on the system's website. He or she may also change some system settings, such as adding a new worker and binding him or her to a monitoring device. In addition, one employee is accessing the smartphone app to see his or her measures and limits. The system's website should only be used by managers or the OSH team. Employees must check their exposure data on the app that will be developed in the next stage of the work. Our system architecture is described in more detail below.

System Architecture: Monitoring Device
The prototype of the monitoring device is composed of an ESP32 board and sensors (light, temperature, humidity, dust, noise, and ultraviolet radiation). ESP32 boards can be used in various IoT applications, such as wearable devices. It is possible to buy a specific development kit or to design a custom embedded system built on the ESP32 microcontroller [32]. In our system, ESP32 collects measures from the sensors and sends these values through the MQTT protocol to the server. ESP32 was chosen because it is cost-effective and widely used and documented.
The circuit with ESP32 and all sensors mentioned above were prototyped on a breadboard, and in the future, a few units of the monitoring device will be manufactured so that the tests can be carried out in a real working environment. The monitoring device is intended to have energy autonomy to allow monitoring and communication for at least one workday. The weight, size, and design of the device's prototype must not interfere with the workers' routine, that is, issues related to the device's ergonomics are being considered in the project. In addition, durability and cost are intended to be viable for industries, considering the use of the device on many workers.

System Architecture: Server Side
In the proposed system, the server receives messages sent by the monitoring devices through MQTT, and then it can issue alarms to managers and workers if the exposure levels exceed the values defined by legislation and/or OSH standards. The server provides a web interface to register employees and shows information related to workers' exposure (e.g., to be used by the OSH team). A brief introduction to the MQTT protocol is presented below.

Message Queue Telemetry Transport (MQTT)
MQTT is an asynchronous and lightweight message protocol that can be implemented on devices with restrictions such as low computational power. MQTT is largely used in IoT applications. In this protocol, the standard for exchanging messages is published/subscribe. A device on the network (client) that wants to receive a specific piece of information must subscribe to this by requesting another element of the network (broker). The broker can manage all publications and subscriptions. The client connects to the broker, publishes messages on a specific topic, and sends the topic and message to the broker. This device can also subscribe to any messaging topic at the broker. MQTT interactions may occur through simple or encrypted Transmission Control Protocol (TCP) connections [30,33]. The MQTT architecture is shown in Figure 2. The prototype of the monitoring device is composed of an ESP32 board and sensors (light, temperature, humidity, dust, noise, and ultraviolet radiation). ESP32 boards can be used in various IoT applications, such as wearable devices. It is possible to buy a specific development kit or to design a custom embedded system built on the ESP32 microcontroller [32]. In our system, ESP32 collects measures from the sensors and sends these values through the MQTT protocol to the server. ESP32 was chosen because it is cost-effective and widely used and documented.
The circuit with ESP32 and all sensors mentioned above were prototyped on a breadboard, and in the future, a few units of the monitoring device will be manufactured so that the tests can be carried out in a real working environment. The monitoring device is intended to have energy autonomy to allow monitoring and communication for at least one workday. The weight, size, and design of the device's prototype must not interfere with the workers' routine, that is, issues related to the device's ergonomics are being considered in the project. In addition, durability and cost are intended to be viable for industries, considering the use of the device on many workers.

System Architecture: Server Side
In the proposed system, the server receives messages sent by the monitoring devices through MQTT, and then it can issue alarms to managers and workers if the exposure levels exceed the values defined by legislation and/or OSH standards. The server provides a web interface to register employees and shows information related to workers' exposure (e.g., to be used by the OSH team). A brief introduction to the MQTT protocol is presented below.

Message Queue Telemetry Transport (MQTT)
MQTT is an asynchronous and lightweight message protocol that can be implemented on devices with restrictions such as low computational power. MQTT is largely used in IoT applications. In this protocol, the standard for exchanging messages is published/subscribe. A device on the network (client) that wants to receive a specific piece of information must subscribe to this by requesting another element of the network (broker). The broker can manage all publications and subscriptions. The client connects to the broker, publishes messages on a specific topic, and sends the topic and message to the broker. This device can also subscribe to any messaging topic at the broker. MQTT interactions may occur through simple or encrypted Transmission Control Protocol (TCP) connections [30,33]. The MQTT architecture is shown in Figure 2.

Applications Running on the Server and Data Privacy Concerns
The server runs on a Virtual Private Server (VPS) provided by a web hosting company. The VPS runs Ubuntu 20.04 operating system and has 2 GB of memory, 2 CPUs, 2 GB disk, and 2 GB of bandwidth. Ubuntu operating system was chosen because it is a free operating system with very good documentation, and it is largely used both on desktops and servers.
Our server is composed of the following entities: • Mosquitto [34]: an MQTT broker that receives the measures sent by the monitoring devices. • Telegraf [35]: an MQTT client that subscribes to the topics that contain the exposure information of the employees and writes them in InfluxDB. Webserver: This shows the graphics generated by Grafana with information about the workers' exposure and the alarms. The server provides an interface to allow managers and/or OSH technicians to change settings, add new people, update data, and inform when a worker retires or leaves the company. These data are stored in MongoDB.

•
Machine learning module: This module is under development and aims to help employers to make long-term decisions in OSH by suggesting points that deserve attention (e.g., a worker, an entire department, or a subsidiary). This module must consider the health history of each worker, as informed on admission, the risks inherent to each job, and data on exposure to hazardous agents. For example, considering workers A and B, who have the same job and only perform slightly different activities, the system may suggest that worker A, who has a history of allergies, starts performing activities with exposure to dust only for a short time. Regarding worker B, who has a history of skin cancer and has been exposed to the sun often and for long periods, the system might suggest the company to allocate B mainly to indoor activities. Managers and the OSH team, based on this information, may choose to exchange activities between A and B. In this way, the module will provide recommendations for the OSH team, aiming to avoid overexposure to hazardous agents.

Privacy Concerns
Due to General Data Protection Regulation (GPDR) recommendations, the server does not store any personal data of the workers (such as full names or document numbers) [39]. This type of information should be stored on a separate server, under the responsibility of the company that will use the system. This is called pseudo-anonymization. For example, once each monitoring device has an ID, the server "knows" that the employee using the device with ID 6000 in the system is a 30-year-old woman who works at the factory at headquarters. The server also knows that she can work at the factory, as a machine operator that is constantly exposed to noise, and at the warehouse as well, where she is exposed to poor lighting. However, the relationship between the device with ID 6000 and full name, documents, and other data are only reached by accessing the separate server mentioned above. In this way, employee privacy is preserved. Then, a company that will use our solution can define its own policies concerning compliance with the GPDR, without the need to make significant adaptations due to the use of our system.
Regarding the MQTT messages sent by the monitoring device, they do not identify the employees. Considering the example mentioned above, the messages should be in the following format: "6000/temperature" and "6000/humidity". In this example, the system is sending the temperature and the relative humidity measured in the environment where the employee with the device 6000 is at a given moment. The communication is secured by Transport Layer Security with Pre-Shared Key (TLS-PSK), where messages originating from a device are encrypted and signed using the shared secret between the parties. The same key is used for decryption and authentication of messages by the destination. The Pre-Shared Key (PSK) is configured between each device and the MQTT broker, as recommended in [40].

Webserver Implementation
The system's web server provides a webpage accessible through the HTTPS protocol (that is, secured with digital certificates). The following functionalities were developed: registering jobs and their risks, registering employees, and associating them with monitoring device IDs, displaying the list of monitoring devices and the IDs of the employees who use them, and displaying the history of activities performed by an employee in the company, changing employees' status (reporting retirement or dismissal), and displaying the list of former and retired employees.
Registering jobs and their risks is the first step required to use our solution. Jobs and risks must be chosen from a pre-defined list. The risks that can be associated with each of the jobs are related to the variables monitored by the system. Once the jobs and risks are registered, it is possible to register employees.
Monitoring devices will receive arbitrarily generated four-digit unique identification codes when they are produced. To register an employee who will use a device, the employer must choose a device from the list shown on the webpage and create a unique fourdigit code to identify the employee. A code with more digits is not suitable to avoid direct association with document numbers. This identification code must be stored by the company in a safe place so that the employee's personal data can be retrieved later. This choice is directly related to the company's data privacy policy, as previously mentioned.
The following data for each employee are recorded in MongoDB: monitoring device ID, employee ID code, gender, date of birth, disease history, subsidiary, sector, job, job start date, job history at the company (if any), and other jobs the employee may have at the company (if any, for future exchanges).
The system is in its last stage of development and uses the following technologies: • HTML5 and CSS: Text markup and styling, respectively. They are standards for developing web pages [41,42]. • JavaScript: Programming language. JavaScript was chosen because it is the world's most popular programming language, and it is very well documented. With Node JS, JavaScript can be used on both the client and server-side [43]. • Node JS: executes JavaScript code outside the web browser, which was its original use [44]. • Pug: An intermediary between Node JS and HTML that allows the insertion of dynamic content [45]. Our system's website has several dynamic contents, such as the risks of a job, monitoring devices' IDs and employees' IDs, and job data. • Ubuntu 20.04: the system was run on a computer with the Linux Ubuntu 20.04 operating system [46].

Tests and Measurements
Tests were carried out with the following objectives: • Check the integration of the server-side software (check if any of the solutions fail and/or if any data are no longer handled correctly).

•
Check the functioning of the web server (employee registration, recording, and queries in MongoDB database).
• Check if the server has any slowdowns or fails during the tests. If it fails, the resources (memory, disk, and CPU) available on the server (VPS) might be not sufficient, and this hypothesis can be rapidly confirmed by the reports provided by the web-hosting company.

•
Check the functioning and suitability of the sensors by comparing the values read from the sensors with those provided by smartphone applications. • Full information path test: data acquisition from sensors by ESP32, sending encrypted data over the local network and Internet through the MQTT protocol, processing the data on the server, recording, and queries in InfluxDB database, and displaying the data in Grafana/web interface.
The proposed system was tested regarding the server-side functionalities available on the web interface: registration of jobs and risks on the server, registration of employees and their association with monitoring devices, visualization of registered information, and exhibition of exposure data through a web interface. We considered a fictional employee since the system has not yet been tested in a real working environment. However, in the future stages of our project, a few units of the monitoring device will be manufactured, and then usability tests will be performed in an industrial environment.
Our system was also tested regarding the communication of ESP32 with the sensors and the communication of ESP32 with the server-side applications: Mosquitto, Telegraf, InfluxDB, and Grafana. The exposure data displayed in the web interface are acquired by Grafana through queries to the InfluxDB database.
The temperature, relative humidity, and illuminance of a room were monitored. The circuit with ESP32, light, and temperature/humidity sensors was prototyped on a breadboard. ESP32 read the sensors and sent data every 10 min to Mosquitto through a Wi-Fi network. All the messages are encrypted, as explained above. Mosquitto handles the values sent by the ESP32 and Telegraf writes that data into the InfluxDB database. This test ran for 12 consecutive hours. The monitoring device (breadboard) was in the south of Brazil, and the server was in South Carolina, USA. The complete solution, with all the sensors previously mentioned, still needs to be tested for several hours and will be presented in the next stages of the project. The details of the web server tests and ESP32/sensors/server-side applications tests can be found below.

Webserver Tests
The following functionalities were tested: • Jobs and risks registration: We tried to register risks for the same job twice. This operation can be performed only once. • Employee registration and association with monitoring device: we tried to register the same employee twice (it must not be allowed by the system); we registered job and health information (known diseases) for a fictional employee who works in a warehouse. • Visualization of registered information: the webpage with the fictional employee information was shown to confirm that the integration with the database (MongoDB) works properly. • Exhibition of exposure data through a web interface: The graphs were shown on the Grafana webpage to check whether they were configured correctly and whether the database (InfluxDB) was being written properly by Telegraf. Then, these graphs were linked on our system's webpage to facilitate the visualization of data by concentrating the information in one place only.

Tests with the Monitoring Device, Mosquitto, Telegraf, InfluxDB, and Grafana
The temperature/humidity sensor DHT11 [47] and the light sensor BH1750FVI/GY-30 [48] specifications can be found in Table 1. During the entire testing period, the breadboard with the ESP32 and the sensors remained static on a table. ESP32 set the temperature and the humidity data obtained from the DHT11 sensor, as well as the illuminance, read from the BH1750FVI/GY-30 sensor, to Mosquitto for 12 consecutive hours, from 2 p.m. to 2 a.m., with the use of air conditioning set to 20 • C from 2 p.m. to 7 p.m. and to 22 • C from 7 p.m. to 2 a.m. The 9 m 2 room was lit with a 12-watt LED lamp. Measurements were taken every 10 min. Telegraf also wrote the data obtained from Mosquitto into InfluxDB. Then, Grafana queried InfluxDB every 10 min as well.

Results
Our results are described below.

Webserver Tests
As previously mentioned, to use our solution, the first step that the company must fulfill is to register the jobs and their risks. Employee registration is only possible after this step has been carried out. Figures 3 and 4 show parts of the web interface for registering and viewing data on jobs and employees and tests to assess system behavior in case of misuse. Figure 3 shows a short list of jobs and their previously registered risks. The company can register other jobs or update the risks of a job that has already been registered.     Risks for the same job cannot be recorded more than once. If an employer wants to update risks, he or she needs to click on the "Update environmental risks for a job" button. Otherwise, the proper page used to update risks is shown and a warning is displayed, as well as advice to update the risks if sure. With jobs and risks registered, it is possible to register employees and associate them with monitoring devices. For this purpose, the user must select a device from a list and enter one unique four-digit employee ID number. If the user enters a device ID or an employee ID that is already registered, an error message is shown. Another device and/or employee ID must be chosen in this case. To unlock a device ID that is already in use, it is necessary to disassociate the device from its respective employee. This can be achieved by updating the employee's status: the employee's resignation or retirement can be informed. In addition, the employee's position can be changed, and if necessary, a new device can be associated with it, unlocking the previous one. After associating the employee with the monitoring device, it is necessary to provide information about the employee's health history. If he or she has any diseases, they must be selected from a pre-defined list. The employee might have the skills to perform more than one professional activity in the company. In this case, the other job possibilities must be informed in this stage by selecting the jobs (if any) from a list, and this information can be updated as needed. Figure 4 shows the history of an employee at the company. In this example, the worker performed a single activity (in the warehouse) since he joined the company. If desired and/or needed, he can also act as a driver. His health conditions are also shown. Risks for the same job cannot be recorded more than once. If an employer wants to update risks, he or she needs to click on the "Update environmental risks for a job" button. Otherwise, the proper page used to update risks is shown and a warning is displayed, as well as advice to update the risks if sure. With jobs and risks registered, it is possible to register employees and associate them with monitoring devices. For this purpose, the user must select a device from a list and enter one unique four-digit employee ID number. If the user enters a device ID or an employee ID that is already registered, an error message is shown. Another device and/or employee ID must be chosen in this case. To unlock a device ID that is already in use, it is necessary to disassociate the device from its respective employee. This can be achieved by updating the employee's status: the employee's resignation or retirement can be informed. In addition, the employee's position can be changed, and if necessary, a new device can be associated with it, unlocking the previous one. After associating the employee with the monitoring device, it is necessary to provide information about the employee's health history. If he or she has any diseases, they must be selected from a pre-defined list. The employee might have the skills to perform more than one professional activity in the company. In this case, the other job possibilities must be informed in this stage by selecting the jobs (if any) from a list, and this information can be updated as needed. Figure 4 shows the history of an employee at the company. In this example, the worker performed a single activity (in the warehouse) since he joined the company. If desired and/or needed, he can also act as a driver. His health conditions are also shown.

Tests with the Monitoring Device, Mosquitto, Telegraf, InfluxDB, and Grafana
Figures 5-7 show the temperature, humidity, and illuminance graphs generated by Grafana. As can be seen in these figures, the integration of our server-side applications (web server, Mosquitto, Telegraf, InfluxDB, and Grafana) worked properly, as well as the communication of the monitoring device with the server. The measurements obtained from the DHT11 sensor were by the temperature set in the air conditioner. In addition, these measurements were checked every hour with the Room Temperature Thermometer smartphone app [49]. The readings differed by up to one degree and 1%, respectively. Such results are consistent with the specifications of the DHT11 sensor. these measurements were checked every hour with the Room Temperature Thermometer smartphone app [49]. The readings differed by up to one degree and 1%, respectively. Such results are consistent with the specifications of the DHT11 sensor.
As can be seen in Figure 5, it is possible to display details about a specific moment by positioning the mouse at the desired point. The minimum, maximum, and mean measurements for the entire period, in this case, 12 h, are also displayed. These preferences may be set in Grafana.   these measurements were checked every hour with the Room Temperature Thermometer smartphone app [49]. The readings differed by up to one degree and 1%, respectively. Such results are consistent with the specifications of the DHT11 sensor.
As can be seen in Figure 5, it is possible to display details about a specific moment by positioning the mouse at the desired point. The minimum, maximum, and mean measurements for the entire period, in this case, 12 h, are also displayed. These preferences may be set in Grafana.   To verify the illuminance measurements obtained by the sensor, the Light Meter smartphone app [50] was used. The environment had constant artificial lighting during the entire period, and the measured values varied from 90 up to 109 lx in the sensor readings throughout the tests. Light Meter presented values very close to these, from 93 to 116 As can be seen in Figure 5, it is possible to display details about a specific moment by positioning the mouse at the desired point. The minimum, maximum, and mean measurements for the entire period, in this case, 12 h, are also displayed. These preferences may be set in Grafana.
To verify the illuminance measurements obtained by the sensor, the Light Meter smartphone app [50] was used. The environment had constant artificial lighting during the entire period, and the measured values varied from 90 up to 109 lx in the sensor readings throughout the tests. Light Meter presented values very close to these, from 93 to 116 lx. The measurements were taken every hour.
From the tests carried out, it was possible to verify that the server features-memory, disk, and CPU-are adequate for the present stage of the study. However, if it was necessary to significantly increase the number of workers and monitoring devices (for example, to store data from hundreds of workers and consequently handle messages sent by hundreds of devices), it would be necessary to expand these resources. The integration of Mosquitto, Telegraf, InfluxDB, and Grafana proved to be suitable for the system once these solutions did not fail during the tests. It is important to point out that Mosquitto can be configured to send and receive messages with or without encryption, according to the needs of each application. In addition, Grafana has a user-friendly interface and may be used with several databases. In this way, the use of Grafana in our system creates possibilities for integration with other applications. As mentioned earlier, all server-side solutions are free software, and they are constantly updated and improved, in addition to being used by several companies and having extensive documentation available on the Internet.
The monitoring device worked correctly, and the chosen sensors proved to be suitable for the system, as well as the ESP32. However, the prototype was assembled with just a few sensors on a breadboard, and this breadboard remained static during the tests. In the future stage of this study, the tests should be performed in the laboratory with the device complete and in motion and then in a real work environment.
There is a wide variety of sensors for the same purposes, and in general, their integration with the ESP32 is easy. Sensor costs may vary widely, and for this study, the use of very low-cost solutions was prioritized, aiming at the design of a solution that can be used with many workers and with a viable cost for companies.

Discussion
As described, the server has most of its planned features implemented and tested. The web interface for registering jobs, risks, and employees works properly. The integration of Mosquitto, Telegraf, InfluxDB, and Grafana proved to be adequate for the proposal. There were no failures in any of the services during the tests. All these services were installed on the same machine (a VPS provided by a web-hosting company), and the InfluxDB database can only be accessed from that same machine for security reasons. The VPS did not show any slowness during the tests, but if it does, it is possible to improve its settings by purchasing a new plan. This can be carried out with a single command on the website of the company providing the service and takes effect immediately.
The monitoring device still needs to be tested with all its sensors. In addition, a battery must be added to the circuit so that the device works during the work shift (ideally) without needing to recharge. Then, the additional configuration must be performed in the server to handle new data.
When it comes to privacy concerns, our project is in line with the GPDR recommendations, and the communication is secured by TLS-PSK. However, at the time of tests in a company, it will be necessary to provide information in a didactic and detailed way to the participants to provide transparency in the treatment of personal data.
Regarding similar works, as mentioned above, various smart PPE and other monitoring systems for OSH have been proposed in recent years. For example, in [19], a piece of smart PPE was presented that can respond in real-time to the risks present in workplaces. The system uses a sensor network located on a helmet and a belt to monitor the state of the worker and the environment. The data collected by the system can be visualized by the user on a tablet or a smartphone. For example, if the worker is in a poorly lit environment, a flashlight on the helmet activates automatically. In [20], the authors proposed a device to continuously monitor the physiological variables of miners at high altitudes. In this system, the noninvasive sensors are embedded throughout a T-shirt and enable the calculation of heart and respiration rate. The device exchanges data with a central monitoring station. In [23], the authors presented an IoT-based construction worker physiological data-monitoring platform using an off-the-shelf wearable smart band that collects a worker's physiological data through heart rate, temperature, and accelerometer sensors. Data regarding workers' current physiological status are sent to the web and a smartphone app. In [24], a wearable system embedded into firefighters' garments was proposed to estimate their physiological state according to the data collected from sensors. Data are sent to the command center, which evaluates the gravity of the risk scenario and sends messages to the firefighters. In [25], the authors proposed a system capable of detecting anomalies in workplaces with a helmet, a belt, and a bracelet. Intelligent algorithms are applied to collected data to predict and notify anomalies with edge computing, where processing occurs closer to data sources to offer fast services. All data are sent to the cloud, where deep learning models verify anomalies due to the training with data inserted previously.
In general, solutions based on IoT have been used for monitoring physiological data and trigger alarms when dangerous conditions are identified, as presented in the studies mentioned above. To improve this type of solution and help companies in long-term risk management, the large volume of collected data may be analyzed with AI techniques, as presented in [25][26][27][28][29]. For example, the amount of data obtained from a construction site could help the OSH department to know exactly what stages of construction are most critical in terms of exposure to one or another hazardous agent and which workers are most exposed to such agents. However, artificial intelligence is still not widely used in OSH applications. In addition, none of the proposals mentioned the analysis of the health history of workers using artificial intelligence techniques. This is a big issue for future works and will be addressed in the next stage of our work.
In treating privacy concerns from an employee perspective, according to [51], devices such as wearable wristbands are widely used in workplaces to continuously collect personally sensitive data, such as geolocation. The data are transferred through wireless networks, and the potential threat to the individual's privacy can make the employees unsure about using any wearable devices [52]. Another point that deserves attention is that, despite its important role in health and safety purposes, extending the use of wearable devices from the professional to the private domain can invade employees' privacy and cause psychological pressure.
Anyway, the successful use of a solution depends on several factors, such as acceptance of workers and risk variability. It is very important to note that the difficulty of implementing new technologies can vary significantly according to the activity. For example, in construction sites, there are many hazards for workers, and because tasks change as construction progresses, monitoring hazards in these workplaces can be a very complex task [53]. On the other hand, warehouses and storerooms can also present a variety of risks, such as dust, sedentary work, and insufficient lighting, but due to the nature of the activities, which present some regularity, the risks become easier to measure.
As mentioned above, in the context of Industry 4.0, new possibilities for risk assessment and mitigation arise. However, new risks emerge from the interaction of humans with machines and robots, while mental illness becomes increasingly common, along with the worsening of conditions such as obesity resulting from sedentary jobs [9,10].
As discussed in [54], concerning legislation, noting the transformations in the industry over the years, it is possible to note that the approach to OSH changed altogether. Labor unions, laws, regulations, and standards emerged in industrialized countries, and workplace conditions have significantly improved in recent decades. OSH law and regulation play an important role in obliging industries to meet safety standards. Concerning OSH standards and legislation, updates in response to technological progress are critical because, aside from systems to help with the promotion of safer workplaces, dangerous innovations could be installed in industries as well.
Smart PPE and environmental monitoring systems in general should be mandatory in work environments to allow companies to obtain large volumes of data that can direct actions in OSH, especially in activities with higher risk, such as construction and mines. Although costs can be challenging, especially for small and medium-sized companies at first, the popularization of the use of these devices and the emergence of new manufacturers tend to contribute to making costs viable.
In the future stages of our project, as mentioned above, the monitoring device will be tested with all its sensors and then integrated with the server-side applications; new settings and graphs will be added to Grafana, and an additional configuration must be performed in Telegraf to write new data in InfluxDB.
The list of diseases that can be registered on the server will be populated with the help of at least two physicians to maintain consistency. If they do not agree, a third doctor will be consulted. Regarding the artificial intelligence module, the relationship between possible future diseases and exposure to hazardous agents will be built based on the extensive literature available on the subject and will be validated by the same doctors, using the same criteria for cases of disagreement. Then, usability tests will be performed in a real work context (industrial environment). The criteria for participant recruitment are explained below.
As criteria for the company and worker recruitment for monitoring system validation, the company must have activities with the risk of exposure to harmful agents that can be monitored by the system. To participate in the study, workers must be over 18 years of age and must be interested in remaining in the company during the entire period of testing. Preferably, some of the workers must be able to perform more than one job in the company, to allow the system to provide suggestions for job exchanges between employees. The other job options that will be included in the workers' register may or may not have a risk of exposure to the agents monitored by the system.
The company must choose an employee (preferably a manager or someone from the OSH sector) to participate in the tests. This person must support the choice of employees who will participate in the tests by wearing the monitoring device, registering employees on the system's webpage, verifying the correct use of the monitoring device by employees, and accessing the monitoring system's webpage every day to quickly check the exposure graphs of each employee, and answering the questionnaires to inform about his/her impressions about the monitoring system.
Workers, in turn, must use the monitoring device throughout the work shift, consult the app that will be available to quickly check their exposure to harmful agents every day, and answer the questionnaires that will be available to inform about their impressions of the monitoring device and the app, and immediately inform the company about any discomfort or problem with the device.
Regarding the questionnaires, workers should answer questions about possible discomforts with the use of the monitoring device, about difficulties with the use of the application, if they consider the information provided by the application useful, and if they would like to use the system (application and monitoring device) permanently during the work shift. A manager or someone from the OSH sector, in turn, should answer questions about difficulties with the use of the system (web interface) and if they would like to adopt this type of solution permanently.

Conclusions
This work presented a monitoring system prototype composed of a monitoring device and a server to receive employees' exposure data to harmful agents in workplaces (dust, noise, ultraviolet radiation, poor lighting, and inappropriate temperature and humidity). The system was tested regarding the measurement of temperature, humidity, and illumi-nance, communication of the monitoring device with the server, functioning of the web interface, and integration of the server-side software. From the tests carried out, it was possible to verify that the server features are suitable for the present stage of the study. Moreover, the integration of server-side software did not present any problems during the tests.
By facilitating the visualization of data by organizations and employees, the system is likely to contribute in the long run to reduce the incidence of occupational diseases resulting from exposure to harmful agents, assisting companies in the development and improvement of OSH systems and policies.
When it comes to innovation, monitoring working conditions and issuing alarms immediately when needed are features found in other solutions as well. However, using the information obtained to provide reports with historical data on working conditions and using such data in conjunction with employees' health history to guide long-term decisions by artificial intelligence, as will be carried out in the future stages of the project, are innovative features. Moreover, data privacy, which is addressed in this work, is mentioned only in a few other studies.

Limitations of the Work
The prototype was assembled with only three sensors: illuminance and temperature/humidity on a breadboard that remained static during the tests. In the future stage of this study, the tests should be performed with the device completed and in motion in a real work environment. We also need to complete and test the machine learning module that is intended to help employers by suggesting points that deserve attention (e.g., a worker or an entire department in the company).

Future Work
As previously mentioned, we plan to develop a smartphone app to facilitate employees accessing their exposure data. Workers will be able to check at any time whether their exposure levels have reached the limits established by the applicable standards. The machine learning module is also planned to be available in the next stage of this work, where tests will be carried out in a real working environment.

Data Availability Statement:
The authors confirm that the data supporting the findings of this study are available within the article.