We collect all of the sensor data for multiple hypothetical emergencies or scenarios for testing. After recording the sensor responses, we classified the severity level into three range values: low, minimal, and high risk. We will then alert the emergency responder or emergency contacts, depending on these emergency scenario severity levels.
5.1 Sensor Data Receive
Kitchen fires typically exhibit characteristics such as flames, elevated temperatures, and significant smoke production. The temperature, smoke, LPG, and flame detection levels in the kitchen and living room after different fire and gas leak incidents are shown in Table 1.Given the presence of fire, detecting LPG in such scenarios is less likely. Conversely, gas leakage incidents in the kitchen result in increased LPG levels in the surrounding environment. In the event of a living room fire caused by factors like electrical short circuits, LPG presence is minimal, with flames likely being of low intensity but temperatures elevated above normal. Smoke generation varies based on the severity of the fire.
Table 1: Detection levels in different incidents
Incidents
|
Flame
|
Temperature
|
LPG
|
Smoke
|
Fire in the Kitchen
|
150
|
53
|
3
|
1050
|
Gas leakage in the Kitchen
|
900
|
32
|
150
|
3
|
Fire in the living room
|
200
|
40
|
1
|
680
|
170
|
42
|
2
|
1260
|
Inorder to evaluate the severity of an issue, an emergency response system must precisely evaluate a variety of environmental elements. Flame, temperature, LPG, and smoke levels are used to trigger alerts or emergency actions, the below code sample illustrated. Each situation is assessed against predefined levels before notifications are sent to the user app or emergency response service.
# Define conditions to evaluate warning and emergency situations
warning = 1 if (flame < 500 or temperature > 49 or LPG > 500 or smoke > 600) else 0
emergency = 1 if (flame < 500 and smoke > 1000) or (smoke > 3000 and temperature > 50) else 0
# Test scenarios
scenarios = [
{"flame": 200, "temperature": 40, "LPG": 1, "smoke": 680},
{"flame": 170, "temperature": 42, "LPG": 2, "smoke": 1260}
]
|
In the previous code, the levels of flame, heat, gas, and smoke are assessed. The current level of each component is compared with predefined integer values and from that, it’s determined if an emergency or a warning is present. If the levels are greater than predefined values, the user app or emergency service is notified of a warning or an emergency. For instance, it will issue a warning if the flame level is excessive. In the event that there is smoke, gas, and extremely high temperatures, an emergency alert will be sent for assistance immediately. People can be kept safe by using the code to check these levels.
Different occurrences might lead to difficulties or malfunctions in vehicle events which we stated in table 2 and need quick action or remediation tactics. It is critical to understand the impacts of different circumstances to keep passengers safe and the vehicle in proper working condition, including engine fires, gas leaks, or crashes. Each case involves unique obstacles, which are usually presented in the form of sensor readings and critical system indicators changing.
Table 2: Detection levels in different incidents for the vehicle
Incidents
|
Flame
|
Smoke
|
CNG
|
ax
|
airbag
|
GPS
|
P1
|
P2
|
P3
|
P4
|
P5
|
Fire in the vehicle engine
|
50
|
630
|
93
|
0.3
|
0
|
23.770616,90.397149
|
100
|
115
|
103
|
94
|
137
|
Gas leakage in the vehicle
|
1023
|
2
|
543
|
0.12
|
0
|
23.770616,90.397149
|
103
|
105
|
104
|
103
|
98
|
Heavy collision on side of the vehicle
|
980
|
340
|
2
|
-6.5
|
1
|
23.770616,90.397149
|
102
|
115
|
863
|
917
|
137
|
# Define warning conditions
warning = 1 if (flame < 500 or smoke > 600 or CNG > 500 or ax < -10 or GPS == (0.0, 0.0) or any(p > 600 for p in [p1, p2, p3, p4, p5])) else 0
# Define emergency conditions
emergency = 1 if (airbag == 1 or (flame < 200 and smoke > 600) or (any(p > 600 for p in [p1, p2, p3, p4, p5]) and ax < -10)) else 0
|
The system then assesses whether any of the presented predefined thresholds meet the predefined warning or emergency condition while the sensor readings are available and the vehicle is in a normal condition. CNG levels are high, alarms are high flame, or alarms are excessive smoke, and a notification is issued via an app on the user’s phone. Notifications are also sent to emergency responders for quick engagement in scenarios where emergency conditions are recognized, such as airbag deployment or critical sensor readings, enabling rescue and fire suppression operations. No additional action is necessary if neither the warning nor the emergency conditions are met, guaranteeing effective resource allocation and reaction management.
Table 3: Summary table of health status
Parameter
|
Test Case
20-year-old pregnant woman
|
Temperature(°C) (T)
|
35.1[35]
|
Humidity (%) (H)
|
88.07 [85]
|
GSR (µS) (G)
|
323.53 [350]
|
Heart rate (bpm) (HR)
|
99[95]
|
SpO2 (%) (S)
|
102.2 [97]
|
AD8232(mV) (A)
|
Fetal Heart rate detected: Yes
|
Health Status
|
T-Normal H-Normal G-Normal HR-Normal S-Normal
|
Pregnant women's health is evaluated by the health monitoring system using sensor data analysis. Normal and risk ranges are defined by reference values for blood oxygen saturation, heart rate, stress, temperature, and stress. For instance, a usual range of 32°C to 37°C was motivated by variations in temperature readings. Three thresholds for stress levels were identified: normal, low-risk (400-540µS), and high-risk (>540µS). Risk levels were also established by oxygen saturation and heart rate data. These thresholds are compiled and recorded data in table 3, which makes it easier for expectant patients to understand health data.
The system's responses for each of these test situations are shown in table 4.
Table 4: System Response for Test Cases
Test
|
Devices
|
Cases
|
Anticipated Reaction from the System
|
Findings
|
1
|
Home
|
Kitchen Flame
|
Notification sent to both app and emergency response service
|
Success
|
2
|
Kitchen Gas Leakage
|
Notification sent only to smartphone app
|
Success
|
3
|
Living Room Fire 1
|
Notification sent only to smartphone app
|
Success
|
4
|
Living Room Fire 2
|
Notification sent to both app and emergency response service
|
Success
|
5
|
Vehicle
|
Car Engine Fire
|
Notification sent to both app and emergency response service.
|
Success
|
6
|
Car Gas Leakage
|
Notification sent only to smartphone app
|
Success
|
7
|
Car Side Collision
|
Notification sent to both app and emergency response service
|
Success
|
8
|
Health
|
Woman Sitting or Standing
|
No trigger activated (No risk)
|
Success
|
9
|
Woman Fallen
|
Trigger 1 activated, Trigger 2 activated, Trigger 3 activated (High risk)
|
Success
|
10
|
Woman Fallen and Unable to Recover
|
Trigger 1 activated, Trigger 2 activated, Trigger 3 activated, Trigger 3 deactivated (No risk)
|
Success
|
All test scenarios provided successful results, accurately matching the system's expected responses. This shows that the system is capable of identifying and handling a range of emergency situations, as seen by the notifications that are sent to the emergency response agencies and the smartphone app as necessary. Additionally, to improve security and effectiveness, threshold values and notification mechanisms can be modified gradually.
5.2 Device Notification System Development
An Android device allows the user to search saved info instantly. For instance, when a user requests to access device data, the application will run a PHP script intended to display data in the "Current data" table. This script will ultimately provide the data from the specified rows and columns of the table. One data point will be displayed each second in the application. Every time the application uses the PHP script, it also verifies the data to see if there has been an accident or emergency. If this is the case, the user will get a notification on the app informing them of the occurrence. One app can monitor several devices because it is compatible with both home and car devices. The different interfaces of the application are shown in figure 6.
5.3 System for Emergency Responder:
When we use the word "Emergency responder," we mostly mean the fire department, ambulance service, hospitals, and civil defense. They are our system's important emergency responders. Since responders must react to user crises, the system's service is more effective in the areas where responders are registered.
Each Emergency Responder is equipped with a web dashboard from which they may access notifications about emergencies, such as building fires or local auto accidents. Their location will be displayed as their home location on a separate screen. An emergency flag will be present in the database when the previously described PHP scripts identify an emergency illustrated in figure 7 and figure 8.
The dashboard utilizes an API to check flag fields, ensuring prompt response to emergencies. If any device signals an emergency, the system retrieves its location and searches for nearby hospitals and fire services. Currently, five hospitals in Dhaka, including Dhaka Medical College Hospital and Apollo Hospital, are integrated into the system. During emergencies, the system compares the location with these hospitals using the API of the Google Maps Location, allowing the dashboard to display notifications visually and audibly. Once an emergency is identified, the dashboard provides location details for immediate assistance by the responder team. Also an SMS alert will be sent to the registered emergency contact number, one sms format is illustrated in the figure 8b.
5.4 Security and Privacy analysis
Our comprehensive system integrates three essential components: the home kit, vehicle kit, and health kit, each catering to a diverse user base. This framework systematically collects sensor data from several users and stores it in a MySQL database to enable continuous monitoring and conditioning procedures. Transmission of this to a cloud server is executed through both TCP and MQTT protocols, resulting in substantial data storage volumes on a daily basis. To fortify the security of this data, our system prioritizes encryption techniques and implements IP address access restrictions, addressing prior concerns regarding security and privacy. Notably, both the MySQL database and MQTT broker "Mosquitto" are password-protected, providing an additional layer of security for data sharing and storage. Furthermore, access to the system is restricted solely to specific IP addresses, further enhancing security protocols. When it comes to sharing data with emergency services, only pertinent information such as name, contact number, and live location is disclosed, prioritizing user privacy and confidentiality. Looking ahead, our future plans entail the incorporation of Google's firewall service to bolster user authentication measures. Notably, within the health kit, we leverage the ThingSpeak dashboard to enhance data visualization and analysis capabilities, further optimizing health monitoring functionalities for our users.