A cloud-edge computing architecture for monitoring protective equipment

Abstract

The proper use of protective equipment is very important to avoid fatalities. One sector in which this has a great impact is that of construction sites, where a large number of workers die each year. In this sector as in others, employers are responsible for providing their employees with this equipment. In addition, employers must monitor and ensure its correct use. These tasks are usually performed using manual procedures. Existing tools to automate this process are unreliable and present scalability issues. In this paper, we research the benefits of using a cloud-edge computing architecture to automate the monitoring of protective equipment. The solution we propose successfully addresses all the problems that appear in hostile and unstructured work environments such as construction sites. Although these sites are used as a use case, the approach presented can also be deployed in other sectors with similar characteristics and restrictions.

Introduction

Information and Communication Technology (ICT) is used today in a wide variety of sectors to improve efficiency, sustainability, and safety. In this way, digitalization has become a strategic issue for many industries. However, there are still sectors in which the full potential of ICT has not been fully exploited. One of these sectors is, for instance, construction sites.

Although the topic of Smart Construction Site (SCS) is gaining popularity in academia [1], the use of ICT in this sector presents many challenges. Thus, the solutions proposed by academia are often not feasible for the real world. Factors such as adverse weather, lack of power supply, electromagnetic noise, or hardware damage must be considered. In addition, construction sites are extremely unstructured, dangerous, and dynamic workplaces. Moreover, employees in this sector frequently see the use of technologies as additional work on top of their duties. Finally, the advantages of ICT solutions must be leveraged and, at the same time, workers must continue to carry out their tasks as normal [2].

Regarding safety on construction sites, the proper use of protective equipment is very important to avoid fatalities. This has a great impact in this sector, where a large number of workers die each year. For example, in Spain this sector presents a higher mortality rate than any other sector. Every year around 1,000 serious accidents occur and more than 100 workers die [3, 4].

The importance of the problem is such that the European Union (EU) has recently published regulations on the design and manufacturing of Personal Protective Equipment (PPE) [5], and also on the use of PPE at the workplace [6]. These regulations define a clear legal framework for manufacturing, providing and using PPE. In addition, these regulations also state that employers are responsible for providing their employees with PPE. Furthermore, employers must monitor and ensure its correct use.

These monitoring tasks are usually performed using manual procedures. Thus, employers deliver PPE equipment to their employees and monitor them to ensure its correct use. Existing tools to automate this process are unreliable and present scalability issues. In this paper, we research the benefits of using a cloud-edge computing architecture to automate the monitoring of protective equipment. The solution we propose successfully addresses all the problems that appear in hostile and unstructured work environments such as construction sites. Although these sites are used as a use case, the approach presented can also be deployed in other sectors with similar characteristics and restrictions.

The rest of the paper is organized as follows: First, “Related work” section describes related work. Next, “Cloud-edge computing architecture for PPE” section presents the proposed solution. Then, “Evaluation” section evaluates our approach. Finally, “Conclusion” section concludes this work.

Related work

Construction sites are hostile and unstructured work environments (HUWE). For this reason, they are one of the least safe areas for workers [7]. In the first place, construction sites are hostile environments because they are outdoors, unprotected from adverse weather. In addition, dust, smoke, and hazardous materials are constantly being used or produced. Moreover, large vehicles and noisy machines are used. Furthermore, high-power tools are employed and dangerous work at height is performed. In the second place, construction sites are unstructured because they are constantly changing. Many workers, tools, machines and vehicles share a common space and move in and around the site without well-defined rules. These reasons make it difficult to deploy ICT-based solutions on construction sites.

Digitalization in the construction sector has already been addressed by many academic works. These works are usually based on solutions using smart sensors or the Internet-of-Things (IoT) [8,9,10], or on big data-driven decision-making processes [11]. To address safety, some related works propose training or awareness-raising using simulators or edutainment applications [12, 13], while other works propose monitoring workers [14,15,16,17,18], machines/vehicles [8, 19] or the environment [20]. In general, related works addressing construction site safety can be categorized according to the following three aspects: hazard identification, risk control and accident analysis [21]. In this paper, we focus on hazard identification. Certainly, hazards can only be avoided if they are properly identified. In the field of construction sites, works that focus on risk management and hazard identification typically use different types of sensors, such as Radio Frequency Identification (RFID) [22] or Ultra-Wide Band (UWB) [23]. The use of wearable physiological sensors such as health monitors is also common [24]. Another approach proposed in academic literature is the used of Building Information Modelling (BIM), either alone or combined with other technologies [25]. Some authors have also presented solutions based on computer vision [19, 26]. However, there are problems that make this technique difficult to generalize and apply in real HUWE, for example, the disparity of situations, types of risk and lighting conditions, as well as the absence of a controlled environment.

Regarding new architectures suitable for SCS or HUWE, the existing literature is limited. The vast majority of approaches propose client/server (CS) or cloud computing (CC) architectures [7, 27]. An exception is the work presented by Kochovski et al. [28], which proposes an architecture for SCS based on edge computing. However, it mainly focuses on the quality of service. The number of works focusing on PPE is even more reduced. Yang et al. [21] presents a simple architecture which links PPE with workers. Thus, it makes it possible to know which worker must wear PPE and when. It is also possible to monitor the usage of PPE. This solution is based on cloud computing. Adjiski et al. [29] also propose a solution that uses cloud computing. In this case, however, the focus is on the mining industry. Approaches that propose client/server or cloud computing architectures for real-time PPE supervision are not without issues. For instance, scalability and low-latency are not guaranteed. These issues make these approaches unfeasible on construction sites and in similar environments. Thus, other alternatives need to be explored. Edge computing (EC), in combination with cloud computing, could be an appropriate solution to address the issues that this domain presents. Note that this combination of cloud-edge computing is also referred to as fog computing (FC) by some authors.

Artificial Intelligence (AI) is another approach that has been researched in previous works to address these issues in domains such as the construction sector [30], industrial machine supervision [31], or occupational safety [32]. In general, research in this area focuses on risk prediction and risk assessment [33,34,35]. Arabi et al. [19] also uses AI for construction vehicle detection, while Jebelli et al. [36] uses AI to analyze the stress of workers. AI has proven valuable in areas such as healthcare for predicting potential issues. However, its use in the field of occupational safety has barely been investigated [37]. The same happens with the use of AI in PPE compliance. We have only found two related works that address somewhat comparable topics [2, 38]. Balakreshnan et al. [38] suggest using AI in factories to detect PPE compliance. The work presented is only a prototype and the evaluation is carried out in a restricted environment. Márquez-Sánchez et al. [2] propose an AI-based platform to monitor safety in workplaces. However, there is no real in situ experimental validation. Therefore, we can conclude that there are still research gaps on the use of AI in the construction sector.

The use of digital technologies within SCS is expected to prevent accidents in a kind of digital skin [39]. However, this approach has not yet been implemented or evaluated in real-world scenarios. This is due to challenges such as hardware and software limitations and a lack of scalability of the solutions, standards, generalizable computer architectures in SCS design, empathy with construction workers to help them accept and use digital technologies. Considering all these challenges, our proposal is focused on a scalable coherent smart architecture for HUWE. Not only in the human factor, but also in the practical one. Our goal is to achieve a solution that is both generalizable and also useful in real environments. Our research hypothesis is that cloud-edge computing is a suitable architecture for these environments. Cloud-edge architectures have already been used successfully in other environments [40, 41]. Furthermore, this type of architecture allows reliable and scalable IoT solutions and also AI algorithms for PPE compliance to be developed.

Cloud-edge computing architecture for PPE

In this section we present the proposed cloud-edge computing architecture for monitoring protective equipment. First, we describe the general architecture. Then, we explain each of the layers of the architecture in more detail.

Fig. 1

Proposed cloud-edge architecture

Fig. 2

Detailed lower layer of the proposed architecture shown in Fig. 1

Proposed architecture

Figure 1 shows the proposed architecture. As we can observe, it is composed of three layers: (i) sensorized protective equipment, (ii) edge nodes, and (iii) cloud nodes.

In the lower layer is the sensorized protective equipment. This is the layer closest to the workers. It consists of sensors installed in the protective equipment that we want to monitor, such as hard hats, railings or harness lifelines.

Above the lower layer are the edge computing nodes. These nodes are inside the construction site. They receive information from the sensors installed in the lower layer. They collect all the data necessary for monitoring, pre-process these data accordingly and forward them to the upper layer.

In the top layer are the cloud computing nodes. These nodes are outside the construction site. They receive information from the edge nodes located inside the construction site. They analyze all the data received, send reports and security alerts to the personnel in charge, store all the information needed, and allow supervisors to check the current and past status of all the sensors.

In the next sections, we explain each of these layers in more detail.

Sensorized protective equipment

Figure 2 shows the lower layer of the proposed architecture in more detail. As commented, in this layer is the sensorized protective equipment (see Fig. 1). LoRa (Long Range) [42] sensors (i.e., transmitters) are installed on the monitored protective equipment. In this paper we consider the following equipment: hard hats, railings, and harness lifelines. Sensors on hard hats and harness lifelines monitor if workers use them. Sensors on railings monitor whether the railing is removed. Sensors can also be installed in a similar way on other equipment.

As we can see in Fig. 2, LoRa is used to connect LoRa sensors with LoRa receivers. The use of LoRa provides what is called a low power connection. It refers to the ability of LoRa sensors to run with very low power consumption, which is desired when working with battery operated devices. The data rate of LoRa ranges from 0.3 Kbit/s to 50 Kbit/s, which is sufficient for our needs. The distance coverage is of up to 3 miles (4.8 km) in urban areas. In addition, it provides deep penetrating transmission, with good coverage indoors and multi-storey buildings, as is our case.

The data sent by each LoRa sensor consist of a string of N bytes, where each character is one byte. The string has the following structure: XXXXSSVVVV (10 bytes):

• XXXX is the LoRa transmitter identifier.

• SS is the sensor identifier within a given transmitter.

• VVVV corresponds to the value read by the sensor.

In addition to messages sent from LoRa sensors to LoRa receivers, there are also regular “keep alive” messages from LoRa receivers to edge nodes. These messages are used to detect possible failures in LoRa receivers.

Edge nodes

Figure 3 shows the middle layer of the proposed architecture in more detail. As commented, in this layer are the edge computing nodes. A Wi-Fi network is used to connect LoRa receivers with collection nodes (i.e., edge computing nodes in our architecture). LoRa receivers act as repeaters. They forward the messages received from the LoRa sensors in the lower layer to the edge nodes in the middle layer. The forwarded messages are sent over Wi-Fi using User Datagram Protocol (UDP).

Fig. 3

Detailed middle layer of the proposed architecture shown in Fig. 1

Fig. 4

Detailed top layer of the proposed architecture shown in Fig. 1

The edge nodes collect all the monitoring data. These data are pre-processed, removing duplicates and adding the construction site identifier, the edge node identifier, and the timestamp. Thus, the final string for every sensor read has the following structure CCCCEEEEXXXXSSVVVVYYYYMMDDHHMMSS (32 bytes):

• CCCC is the construction site identifier.

• EEEE is the edge node identifier.

• YYYYMMDDHHMMSS is the timestamp when the data was collected (year, month, day, hour, minutes, seconds).

The rest of the fields in the string have already been explained in the previous section.

In addition to sending the monitoring data to cloud servers, there are also regular “keep alive” messages from edge nodes to the cloud server. These messages are used to detect possible failures in edge nodes.

Cloud servers

Figure 4 shows the top layer of the proposed architecture in more detail. As commented, in this layer are the cloud computing nodes, a server in our case. This server is located outside the construction site. Inside the construction side, edge nodes access the Internet using a SIM card. This enables access to the Internet regardless of the construction site location.

The cloud server receives data from edge nodes and analyzes them. If it is necessary, it sends security alerts to personal in charge. In addition, it stores data appropriately, allowing supervisors to check the current and past status of all the protective equipment monitored.

As commented, there are regular “keep alive” messages from LoRa receivers to edge nodes. Similarly, there are regular “keep alive” messages from edge nodes to the cloud server. Thus, if an edge node or a LoRa receiver fails, the cloud server detects it and the issue is notified to the personnel in charge.

Evaluation

In this section we evaluate the proposed cloud-edge computing architecture for monitoring protective equipment. First, we describe the evaluation scenario. Then, we detail the specific equipment used in each of the layers of the architecture. Finally, we present the evaluation results.

Evaluation scenario

To evaluate our proposal, we consider an average construction site with 120 apartments and 120 workers. Specifically, Fig. 5 shows a construction site with two 12-storey residential buildings with five apartments per floor. As we can see, on each floor of the two buildings there is one LoRa receiver, making a total of 12 LoRa receivers per building. These receivers are located in the lift shaft. Thus, there is a direct line of sight between the LoRa receivers and the edge nodes. The latter are located at the top of each building (one per building). With this scenario, we evaluate the middle later of the proposed architecture, which has already been detailed in previous sections and shown in Fig. 3.

Fig. 5

Two 12-storey residential buildings with five apartments per floor

Fig. 6

One detailed floor of the building

Figure 6 shows one detailed floor of the building. As it can be observed, in addition to the five apartments per floor, there are also two stairs and two lifts. For our experiments, we consider that there is one worker per apartment (5 workers per floor, 120 workers per construction site). Each worker wears a sensorized hard hat. There are also three sensorized railings. One to protect the perimeter of the apartment and two for the two lift shafts. This makes a total eight LoRa transmitters per floor. These transmitters connect to the LoRa receiver which is located in one of the lift shaft, as we can see in the figure. With this scenario, we evaluate the lower layer of the proposed architecture, which has already been detailed in previous sections and shown in Fig. 2.

Finally, Fig. 7 shows the construction site with the two multi-storey buildings detailed before. As commented, at the top of each building there is an edge node. These edge nodes receive the monitoring data from the LoRa receivers on each floor. After pre-processing these data, edge nodes send data to a server located in the cloud. With this scenario, we evaluate the top layer of the proposed architecture, which has already been detailed in previous sections and shown in Fig. 4.

Fig. 7

Construction site with two multi-storey buildings

Experimental setup

Next, we detail the specific equipment used in each of the layers of the proposed architecture:

• LoRa transmitters and receivers. We use pycom FiPy modules, which can be configured as transmitters or receivers. Specifically, we use modules FiPy 1.0. Each module configured as transmitter is powered by a 3.7V 1000mAh lithium-polymer (LiPo) rechargeable battery with Micro JST 1.25 plug. The modules configured as receivers are powered by similar batteries with a larger capacity (i.e., 20Ah).

• Sensors. In the LoRa transmitters we install sensors. For the hard hats, we use MD30-60 pressure sensors. For the railings, we use a GPIO port from the LoRa modules.

• Edge nodes. We use NVIDIA Jetson Nano 4GB Development Kits. These devices are connected to the electrical network.

• Cloud server. The server used in the experiments has one 4-core Intel(R) Core i5-10300H CPU at 4.50GHz, 8GB RAM, a 256GB SSD and one NVIDIA GeForce GTX 1650 Ti 4GB GDDR6. The operating system installed on this server is Ubuntu Server 22.04.03 LTS.

Results and discussion

Table 1 shows the battery life expectancy, measured in working days, for different values of the transmission frequency, measured in hertz (Hz). The frequencies considered are 1/10 Hz, 1/60 Hz and 1/600 Hz. The table shows results for both LoRa transmitters and receivers. In the experiments, one LoRa transmitter sends messages to one LoRa receiver. LoRa transmitters are set to low power mode after sending a message. They remain in that mode until sending the next message. This allows LoRa transmitters to significantly reduce the power consumption. Thus, with a 1Ah battery it is possible to send messages every 10 minutes for more than 4 months using a transmission frequency of 1/600 Hz. This is an adequate value for our approach and allows the protective equipment to be monitored every 10 minutes. LoRa receivers, however, are set to reception mode. This mode consumes more power than the low power mode. As a result, the same 1Ah battery life is less than 3 days for LoRa receivers regardless of the frequency. For that reason, we have increased the capacity of the battery to increase the battery life for LoRa receivers. For instance, in our experiments using a 20Ah battery increases the battery life for LoRa receivers to over 1.5 months regardless of the frequency. This is a satisfactory result for our approach. In case other scenarios require a longer battery life, such as 3 months, a larger capacity battery, such as one 40Ah or two 20Ah, would be necessary. This will impact on the cost of our approach, because larger batteries are more expensive. It will also affect the space required to install LoRa receivers, because larger capacity batteries also have a larger size.

Table 1 Average battery life expectancy for LoRa transmitters and receivers depending on the transmission frequency and the capacity of the battery

Fig. 8

20Ah battery life expectancy for LoRa receivers depending on the transmission frequency and the number of LoRa transmitters

The battery life expectancy shown in Table 1 only considers one transmitter sending messages to one receiver. However, there are multiple transmitters sending messages to each receiver. Figure 8 shows the 20Ah battery life expectancy for LoRa receivers depending on the transmission frequency, but in this case varying the number of LoRa transmitters. As expected, as the number of transmitters increases, battery life decreases. Although this behavior is more noticeable at higher transmission frequencies, for lower transmission frequencies the variation is minimal.

Fig. 9

Message reception rate of LoRa transmitters and receivers depending on the transmission frequency and the number of transmitters for each building floor (scenario shown in Fig. 6). Worst case: all transmitters send messages at the same time to a receiver

Fig. 10

Message reception rate of LoRa transmitters and receivers depending on the transmission frequency and the number of transmitters for each building floor (scenario shown in Fig. 6). Best case: transmitters send messages at different times (without overlapping) to a receiver

Fig. 11

Latency of LoRa transmitters and receivers depending on the transmission frequency and the number of transmitters for each building floor (scenario shown in Fig. 6). Note that the Y axis is on a logarithmic scale

Fig. 12

Message reception rate of LoRa receivers and edge nodes depending on the transmission frequency and the number of receivers in one building (scenario shown in Fig. 5)

Fig. 13

Latency of LoRa receivers and edge nodes depending on the transmission frequency and the number of receivers in one building (scenario shown in Fig. 5). Note that the Y axis is on a logarithmic scale

Fig. 14

Message reception rate of edge nodes and cloud servers depending on the transmission frequency and the number of edge nodes in the construction site (scenario shown in Fig. 7)

Fig. 15

Latency of edge nodes and cloud servers depending on the transmission frequency and the number of edge nodes in the construction site (scenario shown in Fig. 7)

Figures 9 and 10 show the message reception rate of LoRa transmitters and receivers depending on the transmission frequency and the number of transmitters. In this experiment we evaluate the performance of our architecture in one floor of the building (scenario presented in Fig. 6). As commented, on each floor there are eight LoRa transmitters connected to one LoRa receiver. We perform test with more than eight transmitters (up to 12) to see how this influences the results. Thus, with this test we show the message reception rate depending on the number of LoRa transmitters that are sending messages to the LoRa receiver. We also vary the transmission frequency to see how it affects the message reception rate.

Figure 9 shows results for the worst case, where all transmitters send messages to a receiver at the same time. The message reception rate is only slightly affected for lower transmission frequencies. In contrast, the impact when using the highest transmission frequency results is significant. As we can observe, the reception rate progressively drops to 40% when up to six transmitters are used. For more than six transmitters, the reception rate remains at values around 40%.

Figure 10 shows results for the best case, where all transmitters send messages to a receiver at different times (without overlapping). The message reception rate is not affected for lower transmission frequencies. On the contrary, when using the highest transmission frequency the performance is impacted. As can be seen, the reception rate is not significantly affected up to nine transmitters. Over this number of transmitters, the reception rate gradually decreases. The impact, however, is not as notable as in the previous experiment, and the reception rate reduction is around 10%.

Considering the same scenario, we have also measured the latency. Results are shown in Fig. 11. In the same way as in the previous experiment, latency is measured varying the transmission frequency and the number of transmitters. The results show the amount of time it takes to send a message from a transmitter to a receiver. It is measured as round-trip latency, which includes the time the transmitter waits to receive acknowledgment from the receiver. Similar to before, we perform experiments considering the best and the worst case scenarios. As commented before, in the worst scenario all transmitters send messages to a receiver at the same time, whereas in the best scenario all transmitters send messages to a receiver at different times (without overlapping). Unlike what happens with the reception rate, this experiment is not affected by using the worst or the best scenario. The reason is that we can only measure the latency of received messages. The latency of lost messages cannot be considered.

As we can see in Fig. 11, the latency is insignificant compared to the transmission frequency. In these experiments, the latency was around 40 ms regardless of the number of transmitters. As commented, this time is very small compared to the transmission frequencies considered in the experiments, which are on the order of tens of seconds. For that reason, the latency is basically equal to the inverse of the transmission frequency.

After evaluating the performance of our architecture on one floor of the building, we now evaluate the performance of one complete building. As commented, in our evaluation scenario, shown in Fig. 5, there are 12 LoRa receivers and one edge node in each building. As explained in previous sections, LoRa receivers act as repeaters. They forward the messages received from the LoRa sensors in the lower layer to the edge nodes in the middle layer. Figure 12 shows the message reception rate of LoRa receivers and edge nodes depending on the transmission frequency and the number of receivers. In a similar way, Fig. 13 shows the latency.

As we can observe in Fig. 12, in this case, the reception rate is always 100% regardless of the number of LoRa receivers forwarding messages to the edge node. The transmission frequency does not affect either. As commented in previous sections, the forwarded messages are sent to the edge node over Wi-Fi using UDP. This explains why there are no lost messages. The downside is that the latency increases by around 2 ms, from the 40 ms of previous experiments to 42 ms. However, as shown in Fig. 13, this time is still very small compared to the transmission frequencies considered in the experiments, which are again on the order of tens of seconds. Thus, similarly to previous experiments, the latency remains fundamentally the same as the inverse of the transmission frequency.

Finally, we evaluate the performance of our architecture on the complete construction site. As commented, in our evaluation scenario, shown in Fig. 7, there are two buildings. At the top of each building there is an edge node. These edge nodes receive data from LoRa receivers, and pre-process and send them to a server located in the cloud. Figure 14 shows the message reception rate of edge nodes and cloud servers depending on the transmission frequency and the number of edge nodes. Figure 15 shows the latency.

As can be seen in Fig. 14, the reception rate is again always 100%. The number of edge nodes sending messages to the cloud node does not affect the reception rate. The transmission frequency does not affect either. As explained in previous sections, the communication of the edge nodes with the cloud node is done over the Internet using SIM card, and no messages are lost. This connection, however, increases latency to around 58 ms, while in previous experiments the latency was 42 ms. In spite of this increment, this time is also very small compared to the transmission frequencies considered in the experiments, which are again on the order of tens of seconds. For that reason, the latency remains mainly the same as the inverse of the transmission frequency, as shown in Fig. 13.

Scalability

In this section we evaluate the scalability of the proposed architecture. We study the scalability in the three layers of the architecture. Figure 16 presents the results for the lower layer. It shows the scalability of LoRa transmitters using the same LoRa receiver for different transmission frequencies. It evaluates the worst case, where all transmitters send messages at the same time to a receiver. As we can observe, the architecture scales linearly with lower transmission frequencies. In contrast, when using the highest transmission frequency (i.e., 1/10 Hz), it scales linearly up to 4 transmitters. Over this value, the number of message collisions degrades the performance and the scalability remains at an average value of 4x. Figure 17 evaluates the same scenario but in the best case, where transmitters send messages at different times (without overlapping) to a receiver. In this case, the architecture scales linearly regardless of the transmission frequency up to 9 transmitters. Over this value, we observe some degradation when using the highest transmission frequency (i.e., 1/10 Hz). However, the impact is not as significant as in the worst case scenario.

Fig. 16

Scalability of LoRa transmitters using the same LoRa receiver for different transmission frequencies. Worst case: all transmitters send messages at the same time to a receiver

Fig. 17

Scalability of LoRa transmitters using the same LoRa receiver for different transmission frequencies. Best case: transmitters send messages at different times (without overlapping) to a receiver

Fig. 18

Scalability of LoRa receivers using the same edge node for different transmission frequencies. Worst case: all receivers send messages at the same time to an edge node

Fig. 19

Scalability of edge nodes using the same cloud server for different transmission frequencies. Worst case: all edge nodes send messages at the same time to a cloud server

Figure 18 presents the results for the middle layer of the architecture. It shows the scalability of LoRa receivers using the same edge node for different transmission frequencies. It evaluates the worst case, where all receivers send messages at the same time to an edge node. It can be seen that the architecture scales linearly regardless of the transmission frequency.

Figure 19 presents the results for the top layer of the architecture. It shows the scalability of edge nodes using the same cloud server for different transmission frequencies. It evaluates the worst case, where all edge nodes send messages at the same time to a cloud server. We can observe that again the architecture scales linearly regardless of the transmission frequency.

Discussion of results

In summary, the results presented in this section show that the approach we propose is feasible on construction sites. For that, it is important to choose a suitable transmission frequency (over 1/60 Hz in our experiments). It is also important to use batteries of sufficient capacity at each layer of the architecture (in our experiments, 1Ah for LoRa transmitters and 20Ah for LoRa receivers).

The results confirm the benefits of using the technologies involved in the proposed architecture. The use of LoRa devices in the low layer successfully addresses the problems that appear in hostile and unstructured work environments such as construction sites. Thus, messages send by LoRa transmitters are received by LoRa receivers even in this adverse scenario. It is also appropriate to use Wi-Fi and UDP at the middle layer, because there is a direct line of sight between the LoRa receivers and the edge nodes. In the top layer, using a SIM card in the edge nodes to access the Internet simplifies the connection to the cloud server regardless of the construction site location.

If we compare LoRa with other alternatives, its main limitation is in terms of bandwidth. However, in our case, this was not a problem because the bandwidth provided by LoRa is sufficient for our needs. In terms of distance coverage, LoRa also provided good values for our requirements. In addition to distance coverage, in our case it is also important the penetration of the LoRa signal, which provides good coverage in a construction site. Among the existing alternatives to LoRa we find Narrowband-IoT (NB-IoT), LTE-M and SigFox. NB-IoT consumes low power and has a reduced cost. However, it requires a SIM card for each device, which is not reasonable for our approach. LTE-M provides higher bandwidth, but it also requires a SIM card for each device. SigFox is similar to LoRa, it is simpler to use and provides more distance coverage. However, it presents limitations for communicating back to transmitters, and our architecture relies on this capability to acknowledge the reception of messages. Therefore, LoRa seems to be the technology that best suits our needs.

Cost analysis

In this section we present a cost analysis for implementing the proposed solution. To that purpose, we consider the same average construction site used in the evaluation scenario. As mentioned, it is a construction site with two 12-storey residential buildings with five apartments per floor. We consider that there is one worker per apartment wearing a sensorized hard hat, making a total of 5 LoRa transmitters per floor. There are also three sensorized railings per floor, which adds 3 more LoRa transmitters per floor. In addition, on each floor there is one LoRa receiver, making a total of 12 LoRa receivers per building. At the top of each building there is one edge node, making a total of two edge nodes. Finally, there is one cloud server.

Table 2 Cost analysis for implementing the proposed solution in the evaluation scenario (estimated cost as of March 2024)

Table 2 shows the cost analysis for implementing the proposed solution in the evaluation scenario. The cost of each LoRa transmitter includes a LoRA module FiPy 1.0 and a 1Ah battery. In the case of LoRa transmitters for hard hats, it also includes a MD30-60 pressure sensor. Similarly, the cost of each LoRa receiver includes a LoRA module FiPy 1.0 and a 20Ah battery. For the edge nodes we have consider a NVIDIA Jetson Nano 4GB Development Kit. The cloud server has the features specified in “Experimental setup” section. As shown in the table, the total estimated cost as of March 2024 for implementing the proposed solution in the evaluation scenario is 14,958.17 USD.

Threats to validity

In this section we discuss the influences that may affect the results shown in this work. We follow the methodology proposed by Runeson et al. [43] for reporting threats to validity. This methodology defines the following types of validity threats: reliability validity, internal validity, construct validity, and external validity.

Regarding reliability validity, the experiments were repeated multiple times. The worst and best results were discarded and average values were taken. The relative standard deviation was used to confirm the solidness of the results. Therefore, it should be possible for other researchers to replicate the experiments presented in this work and obtain similar results.

Internal validity analyzes to which extent an experimental condition influences the results. In this case, we find one condition that could be a threat to validity. Workers were being observed during the experiments by researchers and managers. In a real scenario, workers will not be observed. The managers mentioned that workers could look for ways of cheating the sensorized equipment when they are not observed.

Construct validity refers to the effectiveness of the experiments to measure what was intended. From our point of view, battery life experiments were appropriate to measure the average battery life. For the message reception rate, we used enough number of concurrent transmitters to show at which point receivers reach the threshold of lost messages. Finally, the scalability experiments were also adequate to demonstrate the scalability of our approach.

External validity examines if the results obtained can be generalized. The evaluation scenario is an average construction site. The proposed approach is designed to be scalable. Therefore, the results obtained should also be valid for both smaller and larger construction sites.

Conclusion

The proper use of protective equipment is very important to avoid fatalities. One sector in which this has a great impact is that of construction sites, where a large number of workers die each year. In this sector as in others, employers are responsible for providing their employees with this equipment. In addition, employers must monitor and ensure its correct use. These tasks are usually performed using manual procedures. Existing tools to automate this process are unreliable and present scalability issues.

In this paper we research the benefits of using a cloud-edge computing architecture to automate the monitoring of protective equipment. The solution we propose successfully addresses all the problems that appear in hostile and unstructured work environments such as construction sites. Furthermore, the results show that our approach is feasible. For this reason, it is important to choose a suitable transmission frequency. It is also important to use batteries of sufficient capacity in each layer of the architecture.

Although construction sites are used as a use case, the approach presented can also be deployed in other sectors with similar characteristics and restrictions.