## 6 Experiment and Result
### Emergency Service
The tests lasted 180 s to obtain a minimum controlled time window. The size of this time window allowed for covering the stability of the data flow in the messaging subsystem at the beginning of each test and covering the minimum expected response time of the system for the alert notifications generated. Additionally, the tests took into consideration two simulation conditions (\"A\" and \"B\"). The test carried out with simulation condition \"A\" was a reference test to measure the response time of the system to produce an alert, sending only emergency messages to the messaging subsystem. In this test, the Ptolemy simulator sent to the messaging system 10 messages (approximately at the rate of one message every 4 s) with the vital signs of one patient in a critical health condition. The  
Figure 20: Test environment to measure the response time to generate an emergency alert. This environment consists of (1) a simulator of multiple patient vital sign messages, (2) a simulator of vital signs of a patient in critical condition, (3) a real smartphone with an app that collects data from the simulator of vital signs y contains the alert manager 1, (4) the messaging subsystem in the cloud computing environment consists of the EMQ cluster, MQTT–Kafka bridge, and the Kafka cluster, (5) a Spark application that was implemented as alert manager 2, and (6) a real smartphone belonging to medical personnel with an app that collects the emergency message from the EMQ cluster. Additionally, the figure shows the two analyzed routes through which emergency messages could be sent to paramedics: a–b and c–d. tests carried out with simulation condition \"B\" consider the most realistic use of the system components and their impact on the response time of the system to notify an alert. In these tests, the K8s-JMeter cluster simulates the data flow of vital signs (normal health status) of N patients. In parallel, the Ptolemy simulator sent to the messaging system 10 messages (approximately at the rate of one message every 4 s) with the critical health status. The data with the abnormal condition were sent 90 s after the start of the experiment (approximately 1/2 of the total experiment time). Table 6 shows the parameters for the execution of the JMeter test plan and the scalability conditions of the MQTT-Kafka bridge. Furthermore, Table 6 gives the results obtained by Apache JMeter, the number of messages that arrive at the Kafka cluster, and the measurement of the system response time to notify an emergency. The spreadsheet where we collected the parameters and simulation results used in the preparation of tables and graphs is available in the Supplementary Materials (Spreadsheet S4). The following events considered for measuring the response time of the system to notify an emergency alert were:  
1. The time when the patient monitor simulator performs data sampling;
2. The moment when the alert notification message (generated in alert manager 1) reaches the smartphone of the paramedic;
3. The moment when the alert notification message (generated in alert manager 2) reaches the smartphone of the paramedic. Figure 21 shows a fragment of the logs supported by smartphones and related to one of the messages sent from the Ptolemy simulator. The response time of the alert notification service was measured using the record of the timestamps collected in each of the smartphones. From Figure 21 we were able to extract:  
1. The message with the patient's vital signs and the moment in which the data were sampled. The timestamp is \"Wednesday, 25 November 2020, 20:41:55.607000000\" (see Figure 21a);
2. The alert message generated by alert manager 1 and received on the paramedic's smartphone. The arrival timestamp is \"Wednesday, 25 November 2020, 20:41:58.56900000\" (see Figure 21b);
3. The alert message generated by alert manager 2 and received on the paramedic's smartphone. The arrival timestamp is \"Wednesday, 25 November 2020, 20:41:59.59300000\" (see Figure 21c).