This section describes the main tests and results obtained after deploying the Irriman Platform. First, the WEB application functionalities are evaluated, in depth. Then, Cloud interaction performance and computational results are analyzed. Finally, agronomic results are also highlighted.
3.1. Analysis of the Functionalities Provided by the WEB Application
As mentioned before, users access to the Irriman Platform through a WEB application and using the HTTPS protocol. Such application requests a unique login identifier and a password. If they are accepted, a validation string token is sent back allowing users to obtain the information of their owned plots. To activate the options of Humidity, Salinity and Temperature, and those in the lateral menu of the WEB application, a specific plot should be selected. Then, the map shows all the measurement points installed in the plot. When a measurement point is selected, timestamped sensor values are downloaded according to a range of dates (configured through the first option of the lateral menu), and it is possible to access to the graphic representation of humidity, salinity and temperature time series (see Figure 6
A measurement point is a specific location in the plot where several sensors are installed. Such sensor channels could be part of different devices connected to the same or different data loggers. However, from the agronomic point of view, the measurement point is considered as an abstract concept, which provides information about the behavior of the soil, in a specific geolocated point in the map, through values of humidity, salinity, temperature and matric potential at different depths, independently of the electronic devices used for measuring them. As Figure 3
shows, the entity Measurement point has a complex property named “Additional features”, which stores several attributes for saving certain configuration data. There are four essential numerical configuration attributes: Irrigation End Line (IEL), Field Capacity Line (FCL), Irrigation Start Line (ISL) and Unacceptable Depletion Line (UDL). Such attributes are considered to be characteristic lines that agronomic experts define according to soil composition, type of crop and environmental conditions, and they allow farmers to know if the irrigation procedure is or is not suitable, by simply watching the chart that describes the evolution of the accumulated humidity value through time, calculated from humidity values obtained at different depths.
Note that, there is a representative measurement point defined in each plot, marked with yellow color on the map. Furthermore, the perimeter of the plot defines a polygon colored according to the legend defined in Figure 4
. Such color is obtained from the values of the characteristic lines stored in the mentioned representative point, by calling the specific service (in the designed Endpoint), that takes the plot identifier as input and returns a code, which is converted to the corresponding color. The service accesses to the last humidity values (acquired during the last measured hour), at the different depths selected by the user (such selection is also saved in the Cloud, and it can be manually changed through the WEB application). It sums the values with the same timestamp, for each selected depth and, finally, it obtains a mean value from the resultant time series. If such value is under the UDL (the polygon is yellow), the crop is very poorly irrigated, and the plant could suffer dangerous water stress. If it is in the interval [ISL, UDL] (the polygon is blue), the crop is poorly irrigated, but water stress is still low. If it is in the interval [FCL, ISL] (the polygon is green), the crop is properly irrigated. If it is in the interval [IEL, FCL] (the polygon is red), it is necessary to stop irrigation if it is active, since the applied water has exceeded the field capacity. Finally, if it is over IEL (the polygon is dark red), the crop is highly overwatered and it could trigger the leaching process, which could contribute to polluting subjacent aquifers.
shows the rest of charts which could be displayed together with the humidity and accumulated humidity time series: Water stock and Irrigation-Rain-ET0. Additionally, if matric potential time series is available, its chart is represented under the Irrigation-Rain-ET0 graphic. Furthermore, charts are synchronized with the aim of facilitating the understanding of the soil dynamics. Specifically, charts represent the acquired values taken during 20–21 August 2021.The irrigation procedure is started at 05:20 and it finishes at 08:00 every day. Water stock represents changes that happens in soil when water is provided. Increments are obtained while irrigation is active, and decrements occur when irrigation finishes. The accumulated humidity signal rapidly grows when irrigation starts, however, its fall is much slower. This depends on the soil dynamics, which is also reliant on environmental parameters (ambient temperature, for example), and crop type.
All this information and how it is represented is significantly illustrative for helping farmers to understand how irrigation is having influence in the soil and, consequently, in the plant. The expertise of agronomic engineers and technicians is necessary to manually define the characteristic lines; therefore, the Irriman Platform enables their configuration by allowing the values of such lines to be updated and stored in the Cloud. Once the lines are well defined, it is important to maintain the accumulated humidity signal in the range [FCL, ISL], as much as possible, by adapting the irrigation time and amount of added water. As mentioned before, values higher than IEL or lower than UDL could be reached. If such values stand, during a long period, in those levels, over IEL or under UDL, the leaching process could be triggered or water stress could affect plants. The first situation is environmentally harmful (for instance, in the context of protecting the aquifer connected with the “Mar Menor”), and the second one could lead to crop damage and reduce productivity. Therefore, the Irriman Platform offers a usable tool to track and control the irrigation procedure, since soil behavior (by considering different variables) is continuously monitored.
Salinity and temperature could also be monitored. The Salinity tab shows the salinity chart representing time series at the same depths as humidity and temperature. In this case, the accumulated salinity is also plotted, by using the same aggregation algorithm than applied to humidity series; that is, the user makes a selection of depths through the WEB application (which can be registered in the Cloud), and adding the time series at the selected depths, a resultant time series is obtained and represented (see Figure 8
Soil temperature information is also obtained from the same sensor device than humidity and salinity, consequently, there are time series at several depths. An aggregated set of temperature data (calculated as the mean of the values at different depths, previously selected by the user or stored in the Cloud through the WEB application), is also represented as a time series plotted together with the time series obtained from the external services provided by IMIDA SIAM, which offers daily information about the mean of air temperature (see Figure 9
The WEB application’s information cards show plot’s data and provide icon buttons that both, enable users to use the configuration tools and allow aggregation data calculation to be performed (see Figure 9
b). For example, it is possible to easily configure the characteristic lines, to select the set of depths used for aggregation operations or to perform operations from the start of the crop cycle related to irrigation or temperature.
The FCL value is calculated as the sum of all field capacities at different selected depths. For example, in Figure 9
a, FCL is 140, since it is the sum of the values assigned to each field capacity (FC), used as inputs of the aggregation operation at 10, 20 and 30 cm. Such FCs are configured through the dialog shown in Figure 10
a. When the agronomic expert uses the tool that allows the selection of active depths, he/she should define each FC value. Once the sum of FC values is updated, all the lines are erased, except the FCL. Then, the user should define the rest of the lines according to the value of FCL; thus, the order of the lines should be (from highest to lowest value) IEL, FCL, ISL, UDL.
It is also possible to track how irrigation is being applied, in a specific measurement point, through time. Figure 10
b shows two specific charts for enabling this task. One chart allows users to analyze the evolution of the irrigation procedure according to the colors used for filling the polygon that defines a plot. Therefore, it is possible to know, at a glance, how long humidity is not represented by the green color, that is, out of the optimal interval [FCL, ISL]. The other chart shows aggregate information about how much water has been applied since the crop cycle start (represented as a line), and how much water has been applied each week (represented as bars).
Finally, as mentioned in Section 2.6
, the GIS tool (see Figure 5
) can be easily accessed from the WEB application and provides all the necessary functionalities for those users interested in including punctual measurements, manually taken through specific agronomic devices, together with information provided by drones and Hyperspectral Imaging satellites. Additionally, agronomic calculations could also be performed by using a graphical interface, which simplifies the edition of typical equations often used in the agronomic context.
3.2. Results Related to Cloud Computing Techniques
One of the main advantages of using Google Cloud Tools is that many analytics tools are freely provided for performance analysis. Some parameters have been measured in this work, for example, latency, number of GAE instances consumed, CPU (Central Processing Unit) utilization, number of sent and received bytes and amount of data stored in the Datastore. Thus, it is possible to analyze the global performance of the designed system. Furthermore, economic cost is also considered.
Instances classified as backend (B) and frontend (F) are the basic building blocks of App Engine. All the necessary resources are provided by them, and, at a given time, the application could be running on one or many instances with requests being spread across them. In addition, instance classes specify the amount of memory and CPU available to each instance, its amount of free quota and its cost per hour (once free quota exceeds). Nine instance classes are available: from F1 (default), to F4_1G for frontend instances and from B1 (default), to B8 for backend ones. The F1 class provides 120 MB of memory limit and a CPU limit of 600 MHz. This is valid for the first App Engine Standard Generation Runtime, which has been used for implementing the proposed system under Java 8.
App Engine automatically creates and shuts down instances according to traffic fluctuations. There are several scaling types, controlling when instances should be created: automatic (by default, it is used in the proposed system), basic and manual. Only frontend instances support the automatic scaling type. Economic cost partially depends on scaling type, that is, the number of instances created for running the application. More instances usually involve better performance, but higher cost. The instance class also has influence in performance and cost. As mentioned above, the Irriman Platform uses the class established by default, then, the cost is USD 0.06 per hour per instance, since the selected region for deployment is “europe-west3”. As free quotas reset every 24 h, then, costs are only applied when quotas are exceeded in such period. For frontend instances the free quota is 28 h per day and for backend instances the free quota is reduced only to 9 h per day. Although the first version of the Irriman Platform was released in January 2021, and a major update was deployed in July 2021, a period of time of only one month (from 25 July to 25 August 2021), has been selected for performance evaluation. This period has been chosen, because several new plots were included in the platform after May 2021. Figure 11
shows information about CPU utilization and estimated instance count for such period.
Note that, the CPU utilization is near 3% almost all the time (see Figure 11
a), and the estimated instance count is near 2.5% (see Figure 11
b). This last value provides information about the mean number of billable instances. That means that instances have been billed because the free quota has been exceeded.
Latency statistics have been obtained for measuring how long these two services take for returning a response when they are utilised. Figure 12
shows that both spend a mean value lower 3500 approximately.
Specifically, the service “savepaquetesonda_conriegobateria_d” returns a response fast enough (under 2500 ms on average), as Figure 12
a shows, and the service “get_serie_datos_v20_ds” takes under 3500 ms (see Figure 12
b). Note that, the service utilised by data loggers is used more frequently than the one used by users to download sensor data, because sensor data are sent all the time, but downloads are requested by users when they need them. Figure 13
shows the statistic distribution of the overall latency for requests for the mentioned services, in detail, during the evaluated period.
a shows the percentiles, which provide more detailed information about the statistics distribution of the overall latency for “savepaquetesonda_conriegobateria_d”. All the requests take a time under 15812 ms and the 90% of them actually take less than 3410 ms. As strict real time processing is not necessary, latency is suitable for allowing data loggers to send data in a reliable manner by using the HTTPS protocol.
On the other hand, latency percentiles for “get_serie_datos_v20_ds” demonstrate that the 75% of requests take a time less than 3703 ms, and the 50% less than 1450 ms (see Figure 13
Note that, when any service that needs to query, insert or update the Datastore is utilised, the total time spent for emitting the response includes different operations. Several of these operations are related to Datastore service usage through the Datastore API. Figure 14
shows the overall latency and the median of the latency values by API methods. In particular, a statistical measurement of the latency for Commit
(related to database transaction operations) and RunQuery
(related to database queries) methods is shown. The method Commit
, with more than 7 million of requests carried out during the analyzed period, has an average latency of 0.024 s. More than 400,000 requests have also been carried out with the RunQuery
method, with an average latency of 0.029 s.
shows the Datastore statistics calculated from the first deployment of the Irriman Platform to 24 August 2021. More than 39 million of entities have been stored up to this date (7.31 GB of agronomic information). In addition, Datastore has automatically built almost 600 million of indexes and near 400 million of composite indexes. Therefore, the total size consumed is 71 GB. Different plots have been progressively added to the proposed system. During the first half of 2021, 27 plots have been equipped with sensors, in particular, 2152 sensor channels in 102 measurement points with 192 installed devices. Clearly, more than 39 million of stored entities correspond to the stored value, with a size of 7.31 GB. The built-in index size for this kind is high (60.04 GB), because Google scales with data size. Figure 16
shows information about the rate of bytes that the GAE application has received and sent during the analyzed period. The rate of received bytes is mostly under 0.25 KiB/s (see Figure 16
a), and the rate of sent bytes is under 0.36 KiB/s, in general (see Figure 16
b). Figure 17
shows the response latency and information about billing during all the period since the first deployment of the proposed system.
In particular, Figure 17
a shows the response latency for those HTTPS requests which returned a 200-response code (that is, the response indicating that the request has been properly processed). Billing information is monthly presented in Figure 17
b. Note that the global cost of the Irriman Platform since it was deployed is EUR 373.80. This means that the average cost, in eight months, is EUR 46.72 per month. However, not all the months present the same cost, since this is dynamically calculated by Google according to the system usage. The peak in June is due to many real tests carried out for validating the Irriman Platform version update. The first months are cheaper because many plots were equipped with sensors and their information was included after February 2021.
If a value close to EUR 60 is used as the predicted monthly cost, it is possible to calculate the economic cost for each measurement point. There are currently 102 measurement points; consequently, the monthly cost is EUR 0.588 per point. If a measurement point includes approximately about 30 sensor channels, the cost per sensor would be EUR 0.019. Obviously, more measurement points with a high number of sensors increase the economic cost of monitoring a specific user’s plot. If a farmer wants to monitor his/her plot with three measurement points, for instance, with a total number of 90 sensor channels, the monthly cost would be EUR 1.71, and the consumption of Cloud resources would be EUR 20.52 per year. These numbers would be really increased, because they are evidently dependent on the number of requests carried out by users when they use the WEB application. However, Google Cloud allows developers to manage quotas and it is possible to analyze the use that each user makes of the proposed system. Thus, billing could be dynamically distributed between all the users according to their usage.
Any other systems that use a dedicated WEB server for implementing a similar application need to include the economic cost of system administration. Therefore, according to billing data, the use of the proposed system is clearly cheap, and even the global cost for farmers would also be reduced, since plot monitoring helps them to save water and other inputs and the use of Irriman Platform contributes to optimize the irrigation procedure according to environmental needs, such as those related to ecosystem protection, for example the “Mar Menor” in the Region of Murcia, Spain.