Plant Disease forecasting Server:

                                               Plant Disease forecasting  Server:

The revolution in web-based technologies has led to great strides in the development and employment of decision support systems for growers and pest management specialists. The present work illustrates an approach towards that direction by the use of novel programming languages and technology for the development of a web-based system for model implementation and delivery. SISALERT is a multi-model platform that unleashes the power of hourly weather station data and hour-by-hour weather forecast information using sophisticated disease risk assessment models. These models interpret weather data giving information on past or recent disease behavior as well as predicted disease risk. The uniqueness of SISALERT format is the modularity that allows coupling crop and disease models depending on which model is under run.  

 

The software architecture was based on the MVC design pattern (Model-View Controller), an application development model that uses layers during the programming. It was divided into three layers or functional areas: Model, View and Controller (Veit and Herrmann, 2003). The Model part represented the "business logic", the state and behavior of components, managing and leading all transformations. The View provided the data produced by the model, managing what could be seen in his state, presenting them in shape images, graphs or tabular data through web pages or mobile devices. The Controller determined the flow of the application, managing the user interaction/system with the Model (Figure 1). Servers were designed to process requests and ensure the execution. They were divided into five servers: weather data management server (WDMS), database server (DBS),disease forecasting model server (DFMS), web server (WS), and crop model server (CMS). The WDMS consisted in a recovery data module to retrieve weather data from remote sites, updating the data into the DBS. The data retrieval module, which was executed every hour by the “crontab” Linux command, searches for a station file in the script directory to access an automated weather station via Internet. In the station file, the station name, IP address, and the last data retrieval were specified to telecommunicate with an automated weather station, provided by INMET (National Institute of Meteorology).To facilitate the access to station’s data, specific software was design to be deployed on remote computers, allowing to receive data from a particular station network. This software was developed in a generic and configurable way, allowingthe use in a variety of operating systems and weather stations configuration, filtering, validating and preparing the data for transferring and storing. In addition, numerical weather forecast data, provided by INPE (National Institute for Space Research) was retrieved by FTP protocol. Postgre SQL was the core of DBS and stores weather data, as well the identifiers for weather station and run-time parameters as cultivar, planting date, previous crop, and others used by the CMS.The collected meteorological data are considered adequate to generate warnings  of epidemics in extensive crops such as grains (wheat, soybeans, rice, etc.), but cannot provide the desired quality for diseases alerts in crops with high commercial value, where any damage may result in substantial marketing penalties. In a vineyard, for example, the values for meteorological variables within plant canopy may differ from those collected in a nearby weather station. Therefore, onsite data was also obtained by means of a low-cost temperature and relative humidity logging sensors that can be deployed in a spatially dense network. DBS was interfaced with WDMS and DFMS using a Java API, and with WS using an SQL module in a JSP script engine. WS retrieved information from DBS upon request by users through a client-side interface (web-browser, desktop and Smartphone applications). Model outputs are displayed either in textual or graphical formats by using a server-side plotting script. Besides the option of defining a weather station in the database, the system allowed users to input their own weather data, such as
precipitation, temperature, relative humidity, etc., customizing the results for site specific conditions.