# A Regional Multi-Agent Air Monitoring Platform
## 4 The ACreM Platform
### Air Monitor Agent
The second repository is a relational database that stores our measurements. The databases contain the dynamic data received from various IoT nodes or from real-time data entered by the platform's users. The data flow commences with its inception--measurements conducted by devices within the sensor group (see Figure 19). The recorded values are subsequently read and consolidated into a singular data package by a dedicated controller device. This controller functions as an intermediary, adapting between the diverse sensor devices, each with its specific interface, and the broader system. At regular intervals (typically every 1 to 5 min), the controller transmits the data package to the Data Endpoint of the software system. Upon arrival, the data package is directed to a Data Transformation module. Its primary function is to decompose the data package into a series of individual measurements, each associated with its respective value and metric. The implementation of the Data Transformation module leverages the [PERSON]'s Flows [35]. For every measurement, the Data Transformation module initiates a discrete REST request to the OGC's SensorThings API, which, in turn, stores the measurement in the Data Storage. The Fraunhofer IOSB implementation [36] serves as the backbone for the SensorThings API. PostgreSQL, enhanced with the TimescaleDB extension [37], serves as the designated Data Storage. Once the data are securely stored in the Data Storage, retrieval becomes possible through a variety of SensorThings API read methods. These methods accommodate a broad spectrum of filters, allowing for meticulous customization of the retrieved data. Applications, such as Grafana [38], can leverage SensorThings API read methods for monitoring, visualization, or data export. Grafana, for instance, features a convenient preconfigured data source for seamless integration with the SensorThings API. _Interaction between AM and its environment_. The interaction of the AM with its environment is based on the concept of A&A (Artifacts & Agents). The A&A meta-model and first ideas for its use in agent-oriented applications are discussed in [39; 40]. One major challenge in developing agent-oriented applications is modeling the agents' environment. Usually, a suitable representation is devised for each specific case. For this reason, the creation of A&A as a formalism for representing and modeling the environment, regardless of any particular application, is a significant advancement. Accordingly, an agent-oriented system is modeled as a triple (Ags, Bdg, Env) containing the following three sets: the set of agents (Ags), the environment (Env), and the bridge (Bdg) between them [41]. Considering  
Figure 10.5 Component architecture. the abstract nature of the metamodel, various agent-oriented languages and infrastructures can offer concrete implementations. To interact with its environment, AM uses two interfaces implemented in Java and embedded as external routines in the corresponding plans. Integration is relatively easy since JaCaMo itself is also implemented in Java. The interfaces to the Air Pollution Ontology and Sensor DB are presented in Figure 10.6