## 5 The COGNIFOG Project
### Technology Demonstrator
Initial deployment of the Quick Start architecture confirms successful node monitoring, with key metrics like CPU usage, RAM usage, power consumption, and application metrics collected periodically in the management cluster's monitoring manager. In the base configuration, these metrics are gathered every minute, but it is configurable. These metrics allow for basic system health checks and redeployment decisions leveraging AI-driven solutions to automate reconfiguration based on these metrics. In Quick Start, the applications are deployed using the dedicated Helm chart. During the base deployment of our initial test case, the environmental monitoring simulation, the application components are  
* Localisation metadata (x3): Application receiving the sensor data. They are located in the relay nodes. * Weather aggregators (x2): Applications to compute weather data and analyse the current weather. * Weather map (x1): Web application to display the computed value of the current weather by the aggregators. * Object detectors (x2): Application to detect the objects in the camera frames received. * Object map (x1): Web application to display the detected objects by the object detectors. The test case involves sensor data that originates from data sources external to the working cluster. This data is derived from recorded information from open data weather platforms and then re-introduced using emulators before being sent to an MQTT Broker in the COGNIFOG framework. Importantly, all other applications function precisely as they would during a live deployment, ensuring that the COGNIFOG stack is fully operational rather than simulated. COGNIFOG project deliverables D5.1 and D5.2 provide a better understanding of what live data will be used in trials [52]. This real data (although not delivered in real-time) from weather stations and cameras, upon entering the working cluster, is first processed by the localization metadata application. This application determines the geographic location associated with each data point and enriches the payload with this metadata. Following localization, the data diverges into two distinct processing paths:  
* For weather station data, the aggregator receives the localized message and integrates all available information to determine the current weather conditions. This consolidated weather data, along with its location metadata, is then transmitted to a web application for map-based visualization. * For camera frame data, the object detection module analyses each frame, identifying objects such as cars, buses, motorcycles, and people. The detector outputs the identified object type and its associated confidence score. This information is subsequently sent to a web application, which selects the object with the highest confidence score for display on a map. As illustrated in Figure 4, weather data is transmitted at a low frequency of every ten seconds, resulting in minimal bandwidth usage. While this data is non-critical, camera frames are sent at a higher frequency of one frame per second and require significantly more bandwidth. During application design, users specify timing and bandwidth requirements within the application description model. Following deployment, the monitoring system verifies the performance matches these specifications. In the Quick Start implementation, we ensure data periodicity is set at twice the expected period and this defines the threshold used to detect deviations. If an event exceeds this threshold, the information is captured by the Polygraph monitoring component. This component measures application metrics and exposes them via a Prometheus client which allows the monitoring manager to monitor application behaviour and trigger application redeployment if constraints are not met. It is deployed in the working cluster and acquires all messages from the MQTT Broker to extract all application information. Figure 4: The data flow of the technology demonstrator application.