**4. Experiment results**

The Python script receives the configuration file and launches the Packer command after configuring some parameters in the Kickstart file. The Packer command takes the template and runs all the builds within it in order to generate a set of artefacts and build the image in KVM. Once the image is built, Packer launches all the provisioners (Ansible) contained in the template. Ansible carries out several steps: it configures all the repositories, installs all the dependencies and software packages of the EOD modules, configures the EOD software and

The recording of the experiment data was done with Jmeter™ [15] and Nagios® [16]. Jmeter™ is installed in the Node and Nagios® in a virtual machine inside the federated cloud. It is used for the monitoring of the cloud resources and status and to extract the experimental data.

The aim of this experiment is to demonstrate the feasibility of implementing the EOD system in cloud and how its behavior improves after the optimization done by ENTICE over the

The experiment is that of a realistic recording with Deimos-2 satellite in which a real acquisition is ingested into the EOD pilot. Then, the processing of the raw data is carried out with the EOD pilot before and after the optimization process. The results are compared to evaluate the functionality of the optimized system with regard to the nonoptimized system and validate

VMI size, VMI creation time, VMI delivery time and VMI deployment time are the evaluated metrics selected to compare the performance of the system before and after the optimization

The following are the evaluated metrics to demonstrate that the functionality of the system remains the same after the optimization: processing time, imagery products size, CPU use per

The raw data used in the experiment have 3 MB size, four multispectral bands (R, G, B and NIR) and one panchromatic. The recorded area of the land surface is a rectangle of 8.86 × 16.59 km2

The virtual resources used in the experiment were the following: a virtual machine with 300 GB, a RAM of 10 GB, four CPUs of 32 bits, a shared storage with 99 GB and an additional storage volume with 50 GB. This hardware was used for both experiments (EOD before and

The raw data are managed and processed to automatically obtain the following products:

.

installs a context package to deploy the VMI in OpenNebula.

the implementation of the gs4EO modules in cloud.

process and memory use per process.

• L0R: transformation of L0 into image.

• L1A: geolocated and radiometric calibrated image.

after optimization) in order to facilitate comparison.

• L1BR: resampled image and more precise geolocation.

• L0: raw data decoded.

• L1CR: orthorectification.

**3.2. Experiment description**

184 Multi-purposeful Application of Geospatial Data

process4EO node.

process.

First, the virtual machine images of the EOD pilot were created, delivered and deployed in the cloud. Then, the virtual machine of the proces4EO was optimized and its VMI was again created, delivered and deployed. The time spent in every step is depicted in **Table 2**.

In these results, one can see the increase in the performance of the system before the runtime, i.e. up to the deployment of the system: this is a reduction of 30% in VMI size, a reduction of 37.3% in the VMI creation time, a reduction of 34.53% in the VMI delivery time and a reduction of 54.05% in the deployment time.

Next, the raw data recorded with the satellite were ingested in both the original EOD pilot and the optimized EOD pilot. The response of both optimized and nonoptimized systems were measured in the runtime. The processing time of the satellite imagery in the original EOD pilot and the EOD pilot with the optimization of the processing chain is shown in **Figures 5** and **6** respectively. It can be noticed that the processing time of the different levels is similar in both experiments, so as to the time to process the raw data up to the orthorectification level (L1CR): 33.95 and 35.75 s in the nonoptimized and optimized systems, respectively. This difference is not substantial and can be produced by some OpenNebula processes, or the cloud has used


**Table 2.** Metrics of the optimized and nonoptimized EOD pilot.

**Figure 5.** Processing time of the satellite imagery with nonoptimized EOD system.

**Figure 6.** Processing time of the satellite imagery with optimized EOD system.


some resources while executing the experiments. In addition, the size of the different imagery products in both experiments is depicted in **Table 3**. Notice that the size of the different products remains the same in both experiments. These demonstrate that the functionality of the system is intact after the optimization process, while the optimization provides benefits in

Optimization of an Earth Observation Data Processing and Distribution System

http://dx.doi.org/10.5772/intechopen.71423

187

Furthermore, the CPU and memory used in both experiments are similar for all the processing stages: in **Figure 7**, the CPU used in the processing of the satellite imagery with the nonoptimized system is shown; in **Figure 8**, the CPU used in the optimized system is depicted.

storage, creation, delivery and deployment of the system.

**Figure 9.** Memory use per process in the nonoptimized EOD system.

**Figure 8.** CPU use per process in the optimized EOD system.

**Table 3.** Imagery product sizes obtained with both the nonoptimized and the optimized EOD system.

**Figure 7.** CPU use per process in the nonoptimized EOD system.

**Figure 8.** CPU use per process in the optimized EOD system.

**Data type Raw data L0 L0R L1A L1BR L1CR Total**

**Table 3.** Imagery product sizes obtained with both the nonoptimized and the optimized EOD system.

**Figure 6.** Processing time of the satellite imagery with optimized EOD system.

**Figure 7.** CPU use per process in the nonoptimized EOD system.

3090 764 789 749 1140 1130 4572

3090 764 789 749 1140 1130 4572

**Size of the products obtained with the non-optimized system (MB)**

186 Multi-purposeful Application of Geospatial Data

**Size of the products obtained with the optimized system (MB)**

**Products**

some resources while executing the experiments. In addition, the size of the different imagery products in both experiments is depicted in **Table 3**. Notice that the size of the different products remains the same in both experiments. These demonstrate that the functionality of the system is intact after the optimization process, while the optimization provides benefits in storage, creation, delivery and deployment of the system.

Furthermore, the CPU and memory used in both experiments are similar for all the processing stages: in **Figure 7**, the CPU used in the processing of the satellite imagery with the nonoptimized system is shown; in **Figure 8**, the CPU used in the optimized system is depicted.

**Figure 9.** Memory use per process in the nonoptimized EOD system.

Besides, the memory used by the optimized system was lower: the memory use per process in the nonoptimized system can be seen in **Figure 9**, while the memory used in the optimized system can be seen in **Figure 10**.

promising results were obtained. These results indicated that real scenarios of satellite imagery managing and processing can be carried out in cloud with many advantages with respect to traditional infrastructures. Furthermore, an optimization of the EOD pilot was carried out, demonstrating a reduction of 30% in VMI size, 37.3% in the VMI creation time, 34.53% in the VMI delivery time and 54.05% in the deployment time, while maintaining the functionality of the system intact. This indicates that a PDGS system implemented in cloud in a similar manner to that of the EOD pilot can fulfill the requirements of the new Earth observation market paradigm. Specifically, these EOD pilot results demonstrate that the deployment of an optimized PDGS system in cloud can reduce the costs of storage and reduce the time to user by reducing the creation time, the delivery time and the deployment time of the system. Besides, ground stations can take the advantage of rapid, agile, resilient and secure interconnected system when are cloud-based. In addition, the global operational environment provided by a cloud infrastructure facilitates both global acquisition and distribution of data, improving the market efficiency. Finally, the system improves its scalability without vendor lock-in, covering the needs of recent on demand markets.

Optimization of an Earth Observation Data Processing and Distribution System

http://dx.doi.org/10.5772/intechopen.71423

189

In future research, different realistic scenarios with variable demand of services will be tested. With these scenarios, we will evaluate the elastic behaviour in the ingestion of raw data in the system, the processing and the distribution of imagery products to users. Furthermore, a complete optimization of the system will be tested to evaluate the complete repository storage size reduction, which was not evaluated in this work. In addition, new metrics will be measured to validate the implementation of the system for its commercial implementation in the next future.

This work has received funding from the European Union's Horizon 2020 research and inno-

[1] Denis G, Claverie A, Pasxo X, Darnis JP, de Maupeou B, Lafaye M, Morel E. Towards disruptions in Earth observation? New Earth Observation systems and markets evolution: Possible scenarios and impacts. Acta Astronautica, 2017;**137**:415-433. DOI: 10.1016/j.

**Acknowledgements**

**Author details**

**References**

actaastro.2017.04.034

vation programme under grant agreement no. 644179.

Elecnor Deimos Satellite Systems, Puertollano, Spain

Jonathan Becedas\*, María del Mar Núñez and David González

\*Address all correspondence to: jonathan.becedas@deimos-space.com

These results obtained with the EOD pilot can be related with the new paradigms of the Earth Observation market stated in [1]. **Table 4** describes how an approach of a PDGS system similar to the EOD pilot could cover the main requirements of the new EO market.

**Figure 10.** Memory use per process in the optimized EOD system.


**Table 4.** New paradigm requirements vs. EOD pilot approach.
