## 2 Materials and Methods
### EAP Component  
The conceptual diagram of the entire project is shown in Figure 2. The scripts Earth-QVrancea and UpdateMeteoAsync are executed via the daily cron job, importEarthQ, to import new data into the WeatherDataVrancea table, which are subsequently used to train the EMM model. The database containing all the tables this project utilizes is a SQL Server database hosted in Azure. The data used by the EMM model for prediction over the next five days are stored in the dailyTempStats table, which is updated daily through the PredictEarthQ cron job that runs the FutureMeteoData script. The MSStack device is connected to the local internet network, which enables it to access an API developed with ASPNET. This API retrieves data from the MPU-6050 sensor through URL parameters. The API uses an App Service hosted by Microsoft Azure, ensuring real-time data processing. The MSStack and API communication involves HTTP requests that transmit sensor data to the Azure SQL Server Database, as depicted in Figure 2. Once received, the Azure API establishes a connection to the Azure SQL database, where the sensor values are stored for further analysis. Regarding system specifications, the latency considerations depend on the local network infrastructure and Azure's response times, involving both services, such as the app hosting the API and the Azure SQL Server Database. In the proposed implementation, two Azure services were employed to build the cloud infrastructure for real-time data processing:  
* Azure SQL Server Database with serverless configuration automatically scales compute resources based on workload demand. This feature allows us to handle varying data loads efficiently, as it adjusts resources to meet the application's needs while optimizing costs. The serverless tier provides automatic pause and resume capabilities,enhancing resource management by pausing during inactivity and resuming when requests are received. This ensures that we maintain high availability for the sensor data without incurring unnecessary costs;
* Azure App Service hosts the ASP:NET Web API. It provides built-in support for continuous deployment, scaling, and monitoring, ensuring that our API remains responsive under varying loads. Additionally, it integrates seamlessly with Azure's other services, enabling secure communication between the API and the Azure SQL Database. With features like auto-scaling and custom domains, Azure App Service helps maintain high application performance. Since the application features both a predictive and a reactive component, the M5 Stack modules, equipped with an ESP32 microcontroller and MPU-6050 sensors, report threshold-exceeding acceleration values via an Azure API Request to the SensorData table, where the device's geographic coordinates are stored. The EAP utilizes the relationship in Equation (1) to calculate the probability of an earthquake occurrence. This application is deployed in Azure App Service. \[P(EQ)=0.7\times P_{EMM}+0.3\times\frac{1}{N}\sum_{i=1}^{N}S_{i}\] (1) where: \[P(EQ)\] is the final probability of an earthquake occurring in a specific region on a given future day (within five days), including the predictive and the reactive components; \[P_{EMM}\] --the output of the predictive model, representing the probability that an event will occur provided from the EMM model based on predicted weather data; \[N\] --the total number of sensors deployed in the proximity. The proximity is defined by the Equation (2); \[S_{i}\] --the area's value reading from the \[i\] MPU-6050 sensor represents an exceeding pre-set threshold. When the threshold is exceeded, the value is 1. To assess the likelihood of an earthquake occurrence based on latitude and longitude, we utilize the Haversine formula, which computes the distance between two points on the Earth's surface given their latitude and longitude coordinates. The threshold distance value for the analyzed points is imposed to 200 km.