A cost-effective alertness-rating tool to enable situational awareness among on-duty static security guards in Covid-19 pandemic

27 Apr.,2023


This paper considers the specific situation where several static security guards are assigned to watch over and secure the campus gates (G) throughout a day. However, sometimes, they fail to perform their duty due to their fatigue or other secondary tasks. This fatigue or other task leads to insecure the gates, and they fail to trace the unexpected issues at campus gates in this Covid-19 pandemic situation. In this case, the present system (S) suggests a systematic, straightforward, and cost-effective solution, which triggers random alarms remotely to these gates in an unspecified manner from the HSO. The guards of those gates have to respond to the alarms. The system understands the mode of their awareness as alerted or distracted from their response recording. If they do not respond, the system identifies that guard as distracted. HSO records the real-time data of individual static security guards in a database (DB). Then, the method includes calculating their percentage of alertness and assessing their work performance through the implementation of a rating system.


Proposed system model

In this model, it has been considered that four static security guards have been assigned to watch over the four gates (G1–G4). The proposed system’s main objective is to monitor the guards’ awareness remotely from the HSO for the identification of those security guards at their locations and recoding their alertness level during their duty. HSO sends signals randomly to the selected nodes (Node 1 to Node 4) situated at the four gates through the Wi-Fi network. S1, S2, S3, and S4 are four systems placed particularly at four nodes to receive the signals from the HSO. The security guards must respond to the received signals to acknowledge the HSO that he/she is on alert mode, and HSO also identifies their alertness level from their response time. Suppose the acknowledgment signal has been not received from that particular node. In that case, HSO can recognize that the security guard on that node may be distracted by fatigue or any other secondary task. In this work, authors have used Wi-Fi over some other wireless technologies as (a) even though RFID and Bluetooth consume less power, their range of communication is short [24], (b) 4G or other LTE services would lead to high costs [24]. Hence, because of making a low-cost solution, these technologies will not fit best, and (c) ZigBee seems to be one of the most promising technologies. It has the advantage of low-power consumption, but when it comes to data transfer speed, it contributes 100 KBps, whereas Wi-Fi has a data transfer speed of 100 MBps [24]. In embedded systems, a Wi-Fi network can be established easily using the NodeMCU module, which simultaneously acts both as server and client, minimizing the load of using separate modules for the receiver and sender. The proposed system model is depicted in Fig. 1.

Fig. 1

Proposed system model

Full size image


Block diagram of the proposed system

The proposed system has been used to create a private Wi-Fi network for monitoring the alertness of the static security guards based on the simple relationship between the server and the client. The block diagram of the proposed system is depicted in Fig. 2. The components of the system are client, repeaters, and servers. The client has been placed at the HSO, servers have been placed at the end of the guards, and to collect the data from the various servers, Client has to ping the servers because Client can receive the data only after requesting it from the servers. As the proposed private Wi-Fi network has to cover a long distance, repeaters have been placed between the client and the respective servers. In this study, the authors consider the client has two repeaters (repeater 1 and 2). Repeater 1 has two servers (server l and 2), and repeater 2 has two servers (server 3 and 4). The client randomly pings to the respective repeaters. These repeaters replicate the incoming ping signal and guide it to the respective servers randomly. Security guards at the server sides have to respond to those signals to acknowledge the HSO. The client records their responses and calculates their percentage of alertness level. Further, these data are converted to the rating of individual guards.

Fig. 2

Block diagram of the proposed system

Full size image

In Fig. 3a, detailed block diagram has been presented for the communication network of server 1 with the client. At HSO, one Wi-Fi module and computer act as the client of the system. The Wi-Fi module pings to the repeater, and the computer is connected with the Wi-Fi module to record the received day-wise alertness data of the static security guards. A DB has been maintained in the computer for further analysis of the collected data. The repeater has been used between the client and the server. The repeater’s primary purpose is to extend the working distance between the two Wi-Fi modules, i.e., sender and receiver. Repeater replicates the received ping signal and guides it to the respective server. At the guards’ end, one Wi-Fi module has been used. The purpose of this Wi-Fi module is to receive the signal from the repeater and create an alarm to the guards by activating a Light Emitting Diode (LED) and sounding a buzzer for a fixed time duration. Guards have to press the push-button switch within that time. From this response, the client can identify the alertness level of the individual static security guards.

Fig. 3

Detailed block diagram of the communication between one individual server with client

Full size image


Working principle of the proposed system

The proposed system works on the simple principle of communication between two or more Wi-Fi modules. For this purpose, the authors create a private Wi-Fi network between the modules. Our sole objective is to track the on-duty static security guards, identify the distracted guards, and record their day-wise performance level. The proposed system has a client, which is a Wi-Fi module. The client is the brain of the system. It is responsible for essential functions such as randomly pinging the respective repeaters, storing the guards’ time of response. As the distance covered by the private network must be large, the authors have placed repeaters between them. These repeaters amplify the incoming ping and guide it to the respective servers. These are the same module as the client, i.e., a Wi-Fi module. The repeaters act as both server and client. The repeater acts as a server or an Access Point (AP) to receive an incoming ping request. As soon as the AP receives a request, it switches to a client and randomly calls the connected server. The servers are coupled with a LED, buzzer, and a push-button switch. When the respective server receives a ping request, it turns on the LED and sounds the buzzer for a fixed time. Within this time, the guard has to respond by pressing the push-button switch. If the guard presses the switch, a protected message is sent to the client. If the guard fails to do so, a compromised message is sent to the client, and the conclusion is that the guard is in distracted mode, and thus another alarm in a shorter time is necessary. In Fig. 4, the flow chart of the system is presented.

Fig. 4

Flow chart of the proposed system

Full size image


Proposed algorithms of the system

The authors have prepared three algorithms (Algorithm 1–3) for the Client, repeater, and server. These algorithms are required to program the respective modules at the client, repeater, and server end. The client’s algorithm is designed so that the Wi-Fi module has complete autonomy to request information from all the servers in any order and presented in Algorithm 1. It means the process is entirely random. There is generally no pattern unless set by the programmer. The first step of the algorithm requires it to generate the repeater number with which it wants to get connected. On generating, it checks if it has connected to the repeater on its previous iteration. If it has, it again generates another repeater number to get connected. The next step involves getting connected and fetching the data. On getting the unique repeater number, it connects and requests data from the server. It means the repeater gets connected to a unique server, fetches the data, and returns it to the client. The client then calculates the percentage of awareness of the guards and records it in a Comma-Separated Values (CSV) file in the database. Further, these data convert to individual guards’ rating, which is useful to evaluate their work performance.

The algorithm for the server is presented in Algorithm 2. This algorithm is designed in such a way that the Wi-Fi module act as an AP. The module running as an AP is set up with a unique Service Set Identifier (SSID) and password. If it receives a client’s request through the SSID and password, the server call func_LED () function. The func_LED () function is designed in such a way that on getting called, it activates the LED and buzzer, which are connected with the module. The LED and buzzer are set on a high or low intensity depending on the guards’ previous response. If the guard has failed to respond to an earlier ping, the buzzer and LED will glow up with high intensity; else, it has a low intensity. The devices are activated for a window of fixed delay if the guard presses the key present in the system and responds to the ping, the Wi-Fi module record the time taken by him/her to respond and return the same to the client where the percentage of alertness of the guard is calculated.

The algorithm designed for the repeater is presented in Algorithm 3. It is a mix of both the client and the server algorithms. On receiving a ping/request from the client, the repeater, which was in AP mode until now, switches to a client mode itself. It generates a random server number from the servers available to it and checks if it has not been produced on a previous iteration. If it is unique, it connects to the server and requests it to set the LED and the buzzer high with a fixed delay window. If the guard responds, the repeater fetches the response time and returns a “1” (high value) to the Client. If the guard fails to do so, it returns a “0” (low value) to the Client.

For more information Real Time Guard Tour System, please get in touch with us!