# Enhancing Sustainable IoT Systems Through a Goal-Oriented Requirements Analysis Framework
## 4 Goal-Oriented Requirements Analysis Approach for IoT Software Systems
### Application Example: IoT System for Monitoring Air Quality
#### 4.2.5 QVT for Model-to-Model Transformations
* Sensor Simulation: Environmental parameters were synthetically generated using a Python script that published readings to MQTT topics every five seconds. The data followed realistic patterns of indoor environmental variation. * Node-RED: Employed for flow-based integration and visualization of MQTT topics, enabling real-time interaction with data streams and actuator commands. * InfluxDB: A time-series database used to store sensor values, actuator states, and system-generated events, supporting long-term analysis and benchmarking. * Grafana: Preconfigured dashboards provided both real-time and retrospective visualization of sensor metrics, actuator activity, and alert conditions. Two distinct implementations were compared:

1. Baseline Flow: A conventional system using manually crafted Node-RED flows, static threshold-based triggers, and direct actuator control via MQTT messages. 2. GORA Flow: A goal-oriented system in which high-level objectives and domain constraints were encoded in i* models and automatically transformed into executable Python code, enabling adaptive and sustainability-aware control of smart devices. All components were deployed on a shared internal Docker network and executed simultaneously for a two-hour evaluation window. Runtime metrics--including CPU and memory usage, latency, and development effort (measured by lines of handwritten code)--were collected using Docker statistics and InfluxDB queries. This experimental configuration facilitated a controlled and reproducible analysis of the engineering and sustainability trade-offs between conventional and model-driven approaches in a smart home IoT context. ### Evaluation Metrics

To assess the performance, sustainability, and developer effort of the GORA-based implementation relative to a conventional baseline, the following evaluation metrics were defined. * Energy Consumption (mWh): Estimated using Docker container CPU usage data and mapped to a Raspberry Pi 4B equivalent power profile to approximate real-world energy demands. * System Latency (ms): Measured as the average response time between a simulated sensor event and the corresponding actuation command published to MQTT. This includes processing time in the logic layer and message propagation delay. * Memory Usage (MB): Computed using Docker memory statistics collected during runtime to assess the memory efficiency of each implementation. * Code Generation Error Rate: Quantified as the number of runtime or syntax errors encountered during automatic code generation and execution on ten deployment runs. * Developer Effort (Lines of Code--LOC): Measured by comparing the number of handwritten lines of logic (e.g., function nodes or Python routines) in the baseline system with the model-transformed lines generated automatically in the GORA-based system. These metrics were selected to evaluate both the technical performance and engineering productivity, especially in terms of sustainability (e.g., energy savings and resource usage) and maintainability (e.g., automation and code quality). The chosen indicators reflect common concerns in the development of smart home IoT systems and provide quantitative support for the advantages of a MDD goal-oriented approach. ### Results

The empirical results of the experiment are summarized in Table 1, which compares the implementation based on GORA with a conventional manual coded baseline. All metrics were collected over a continuous two-hour simulation period, during which both systems received identical sensor input streams and operated under the same environmental conditions. The GORA-based implementation outperformed the baseline in all dimensions. The system achieved a 18.9% reduction in estimated energy consumption, mainly due to the use of event-driven logic and the elimination of busy waiting loops. The system latency was reduced by 23.0%, enabling faster actuator response and more timely user alerts. The memory usage was also optimized, with an 8.6% improvement attributed to the leaner runtime environment of the generated Python services.