# Cost-Aware IoT Extension of DISSECT-CF
## 4 Implementation and Validation
This option allows experiments to determine how the Application reacts to various sized sensor swarms. To realistically represent the modelled weather service, we set this value to 503 as this is their currently operated station count Station count collected on 01/04/2017. Data generation frequency (freq) could be set for the sensor set (in milliseconds). The station's caching mechanism is influenced with the tag ratio. This defines the amount of data to be kept at the local storage relative to the average dataset produced by the sensors at each data generation event. If the cached data in the local storage (i.e., storage) overreaches its limit, the station models the transfer of the data to the cloud storage (specified in the torepo tag). The station's network bandwidth to the outside world is specified by the tags maxinbw and maxoutbw. In the implementation, the Cloud class is used to specify and set up a cloud environment (i.e., allows the simplified creation and configuration of IaaSService objects). The alternative, to-be-evaluated scenarios should be defined by the Application class. The VmCollector class can be used to manage the VMs backing the Application's computing activities. Its two important methods are: \((i)\) VmSearch() matches tasks with free VMs--i.e., defines the load balancing strategy of the application; and the \((ii)\) generateAndAdd() can be used to deploy a new VM--i.e., it provides the implementation for the auto-scaler for the application. Next, we detail the generic steps followed by our Application implementation which has XML based customisation for application behaviour. This inner working is also depicted in Figure 6. By executing a simulation, the following steps are taken:  
* Step 1: Set up the cloud using an XML. As we expect meteorological scenarios will often use private clouds, we used the model of a Hungarian private infrastructure (the LPDS (Laboratory of Parallel and Distributed Systems) Cloud of MTA SZTAKI (Institute for Computer Science and Control, Hungarian Academy of Sciences). Figure 5: XML-based description of IoT systems. * Step 2: Set up the necessary amount of stations (using a scenario specific XML description) with the previously listed eight sensors per station. * Step 3: Load the VM parameters from XML files, which also describe the cloud and IoT costs. Start the Application to deploy an initial VM (generateAndAddVM()) for data processing and to start the metering process in all stations (startStation()). * Step 4: The stations then monitor (Metering()), save and send (startCommunicate()) sensor data (to the cloud storage) according to their XML definition. Parallel to this, CloudCostCounter() and IoTCostCounter() methods estimate the price of IoT and cloud operation, based on the generated data and processing of those data. The process of cost calculation depends on the chosen provider. If provider pricing is not time-dependent, like in case of Bluemix, we have to pay only after data traffic, then this loop is executed only once, at the end of the simulation. Otherwise, if the provider cost is time-dependent, the time interval for the measurements is given in the period attribute, as shown in Figure 2. This interval represents the frequency value to be used by the extended provider class, and the corresponding cost counter methods are executed in all cycles. * Step 5: A daemon service checks regularly if the cloud repository received a scenario specific amount of data (see the tasksize attribute in Figure 5). If so, then the Application generates the ingest compute tasks, which will finish processing within a predefined amount of time. * Step 6: Next, for each generated task, a free VM is searched (by VmSearch()). If a VM is found, the task and the relevant data is sent to it for processing. * Step 7: In case there are no free VMs found, the daemon initiates a new VM deployment and holds back the not yet mapped tasks.