D5.1.2 pilots description and requirements elicitation report

This project is partially funded under the ICT Policy Support Programme (ICT PSP) as part of the Competitiveness and Innovation Framework Programme by the European Commission under grant agreement no. 621074

COMPETITIVENESS AND INNOVATION

FRAMEWORK PROGRAMME

CIP-ICT-PSP-2013-7 Pilot Type B

WP5 – Pilots Preparation, Execution and Evaluation

D5.1.2: Pilots Description and Requirements Elicitation Report

Deliverable Lead: SERESCO

Deliverable due date: 30/06/2015

Actual submission date: 30/06/2015

Version: 2.4

D5.1.2 Pilots Description and Requirements Elicitation Report

http://www.foodie-project.eu Copyright © FOODIE Project Consortium. All Rights Reserved. Grant Agreement No.: 621074 Page: 2 / 100

Document Control Page

Title D5.1.2 Pilots Description and Requirements Elicitation Report

Creator Ismael Suárez Cerezo (SERESCO)

Description

In the FOODIE project, it is of crucial importance to have well defined, and detailed, functional and technical specifications of the FOODIE service platform hub. In view of this objective, the task 5.1 Pilots Specification and Stakeholders Requirements Elicitation, within the Work Package 5, has an important role in serving as primary input for technical work packages. By taking feedback from users as soon as possible and delivering software incrementally, FOODIE will greatly improve results and will be focused on user needs and not on technical needs. Pilots in three different countries have been established: Czech Republic, Germany and Spain. These pilots and their stakeholders will be the basis for collecting the requirements to design the FOODIE platform and provide the services that will fulfil their needs. In addition to the stakeholders involved in the pilots, other end-users partners will provide requirements and participate in the testing of the platform

Publisher FOODIE Consortium

Contributors

Ismael Suárez (SERESCO)

Antonio Manuel Campos (SERESCO)

Miguel Ángel Esbrí (ATOS)

Karel Charvat K (Wirelessinfo)

Raúl Palma (PSNC)

Rodrigo García, Alfonso Noriega, Javier Rodríguez (CTIC)

Jarmila Mekotova (MJM)

Walter Mayer (PROGIS)

Moreno Broccon (BIM)

Cristina Monteserín (SERESCO)

Rodolfo de Benito (SERESCO)

Creation date 17/03/2014

Type Text

Language en-GB

Rights copyright “FOODIE Consortium”

Audience internal public restricted

Review status

Draft WP leader accepted Technical Manager accepted Coordinator accepted

Action requested

to be revised by Partners for approval by the WP leader for approval by the Technical Committee for approval by the Project Coordinator

Requested deadline



STATEMENT FOR OPEN DOCUMENTS

(c) 2016 FOODIE Consortium

The FOODIE Consortium (http://www.foodie-project.eu) grants third parties the right to use and dis-

tribute all or parts of this document, provided that the FOODIE project and the document are properly

referenced.

THIS DOCUMENT IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY

EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF

MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. EXCEPT WHAT SET

FORTH BY MANDATORY PROVISIONS OF LAW IN NO EVENT SHALL THE COPYRIGHT OWNER OR

CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR

CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE

GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER

CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT

(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS

DOCUMENT, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

About the project

FOODIE project aims at creating a platform hub on the cloud where spatial and non-spatial data related to agricultural sector is available for agri-food stakeholders groups and interoperable. It will offer: an infrastructure for the building of an interacting and collaborative network; the integration of existing open datasets related to agriculture; data publication and data linking of external agriculture data sources, providing specific and high-value applications and services for the support of planning and decision-making processes.

FOODIE project is addressed to four basic groups of users: a) stakeholders from the agriculture sector as end-users of final applications, b) public sector for communication with farmers about taxation, subsidies and regulation, c) researchers for large scale experimentation on real data and d) ICT companies for the development of new applications for agriculture and food sector, mainly using implemented tools

FOODIE specifically works on three pilots:

Pilot 1: Precision Viticulture (Spain) will focus on the appropriate management of the inherent variability of crops,

Pilot 2: Open Data for Strategic and Tactical Planning (Czech Republic) will focus on improving future management of agricultural companies (farms) by introducing new tools and management methods,

Pilot 3: Technology allows integration of logistics via service providers and farm management including traceability (Germany).

Contact information

Miguel Angel Esbrí

Project Coordinator

Atos Spain, Madrid, Spain

E-mail: [email protected]

URL: http://www.foodie-project.eu

Twitter: https://twitter.com/FOODIE_Project

http://www.foodie-project.eu/

mailto:[email protected]


https://twitter.com/FOODIE_Project



Table of Contents

Glossary...................................................................................................................................................................... 7

Abbreviations and Acronyms ...................................................................................................................................... 8

Executive Summary .................................................................................................................................................... 9

1 Introduction ....................................................................................................................................................... 10

2 Methodology ..................................................................................................................................................... 11 2.1 Relationship to the ISO Reference Model ........................................................................................................ 11 2.2 General Description .......................................................................................................................................... 11 2.3 Use Case Analysis Methodology ....................................................................................................................... 12

2.3.1 Use Case and Requirements Modelling .................................................................................................... 12 2.3.2 Use Case Template ................................................................................................................................... 13 2.3.3 Requirement Template ............................................................................................................................. 16 2.3.4 Relation Types between Use Cases and Requirements/Components ...................................................... 19 2.3.5 UML Representation ................................................................................................................................. 20

2.4 Validation Process Description ......................................................................................................................... 22 2.5 Change Management ....................................................................................................................................... 22 2.6 Tool support...................................................................................................................................................... 24

3 Spanish Pilot Description ................................................................................................................................... 25 3.1 Introduction ...................................................................................................................................................... 25 3.2 Pilot Scenarios .................................................................................................................................................. 26

3.2.1 Scenario A – Registration of geo-located information about operations in field ..................................... 28 3.2.2 Scenario B – Obtaining of recommendations and predictions of interest for vine-growers .................... 30 3.2.3 Scenario C – Geographical, textual and numerical representation of the registered information .......... 32

3.3 Users and Roles ................................................................................................................................................ 34 3.3.1 Technical Director ..................................................................................................................................... 34 3.3.2 Field Operator ........................................................................................................................................... 34 3.3.3 Web Service .............................................................................................................................................. 34

3.4 Data Sources and Data Input ............................................................................................................................ 35 3.4.1 FOODIE Sources ........................................................................................................................................ 36 3.4.2 External Sources ....................................................................................................................................... 37

3.5 List of Use Cases ............................................................................................................................................... 37 3.6 List of Requirements ......................................................................................................................................... 40

4 Czech Pilot Description ...................................................................................................................................... 46 4.1 Introduction ...................................................................................................................................................... 46 4.2 Pilot Scenarios .................................................................................................................................................. 47

4.2.1 Scenario A – Improving efficiency of transport in agriculture. ................................................................. 47 4.2.2 Scenario B – Telematics of farm machinery ............................................................................................. 51 4.2.3 Scenario C – Monitoring of in-field variability for site specific crop management................................... 54

4.3 Users and Roles ................................................................................................................................................ 58 4.3.1 System operator ....................................................................................................................................... 58 4.3.2 Experts ...................................................................................................................................................... 58 4.3.3 System for optimization of transport ....................................................................................................... 58



5 German Pilot Description ................................................................................................................................... 66 5.1 Introduction ...................................................................................................................................................... 66 5.2 Pilot Scenarios .................................................................................................................................................. 67



5.2.1 Scenario A – Geographical Information System – WinGIS ........................................................................ 68 5.2.2 Scenario B – Farm Management System – DokuPlant .............................................................................. 70 5.2.3 Scenario C – Logistics Platform ................................................................................................................. 74

5.3 Users and Roles ................................................................................................................................................ 79 5.3.1 Experts ...................................................................................................................................................... 79 5.3.2 Farmers and Advisors ............................................................................................................................... 79



6 Other end-Users’ requirements ......................................................................................................................... 86 6.1 Consorzio B.I.M. Piave Belluno ......................................................................................................................... 86 6.2 Poland ............................................................................................................................................................... 87

6.2.1 Introduction .............................................................................................................................................. 87 6.2.2 Scenarios. .................................................................................................................................................. 89

6.3 Latvian Scenario ................................................................................................................................................ 91 6.4 Turkish Scenario................................................................................................................................................ 92

7 Common Features and Functionalities ............................................................................................................... 93 7.1 List of Generic Use Cases .................................................................................................................................. 93 7.2 List of Generic Requirements ........................................................................................................................... 95

8 Conclusions ........................................................................................................................................................ 98

References ................................................................................................................................................................ 99

Annexes................................................................................................................................................................... 100



Index of Figures

Figure 1. FOODIE Pilot Areas ............................................................................................................................................ 10 Figure 2. Procedure of the FOODIE Use Case Analysis ..................................................................................................... 13 Figure 3. Relationships between Use Cases, Components/Requirements, Actors and Information Resources .............. 20 Figure 4. Schema for the Graphical Representation of a Use Case .................................................................................. 21 Figure 5. Change Request Flow Diagram .......................................................................................................................... 23 Figure 6 Spanish Pilot Scenarios/Use Cases...................................................................................................................... 27 Figure 7: Spanish Pilot Use Cases for Scenario A .............................................................................................................. 29 Figure 8: Spanish Pilot Use Cases for Scenario B .............................................................................................................. 31 Figure 9: Spanish Pilot Use Cases for Scenario C .............................................................................................................. 33 Figure 10 Spanish Pilot Users and Roles ........................................................................................................................... 34 Figure 11 Czech Pilot Scenarios/Use Cases....................................................................................................................... 47 Figure 12: Czech Pilot Use Cases for Scenario A ............................................................................................................... 51 Figure 13 Czech Pilot Use Cases for Scenario B ................................................................................................................ 53 Figure 14: Czech Pilot Use Cases for Scenario C – Aerial Survey ...................................................................................... 57 Figure 15 Czech Pilot Users and Roles .............................................................................................................................. 58 Figure 16 German Pilot Scenarios Description ................................................................................................................. 67 Figure 17 web-Map-Service based orthoimages accessible to FOODIE ........................................................................... 68 Figure 18: German Pilot Scenario A Use Cases ................................................................................................................. 70 Figure 19 The 4 a.m. Expert Datasets ............................................................................................................................... 72 Figure 20 German Pilot Scenario B Use Cases .................................................................................................................. 73 Figure 21 DokuPlant snapshot .......................................................................................................................................... 74 Figure 22 German Pilot Logistics Platform ....................................................................................................................... 75 Figure 23 German Pilot Scenario C Use Cases .................................................................................................................. 78 Figure 24 Stages of system development ......................................................................................................................... 88 Figure 25 Possible location of Demonstration Farms ....................................................................................................... 88

Index of Tables

Table 1: Abbreviations and Acronyms ................................................................................................................................ 8 Table 2. Description of the FOODIE Use Case Template .................................................................................................. 16 Table 3. Description of the FOODIE Requirements Template .......................................................................................... 19 Table 4. Description of the Change Request Registration Template ................................................................................ 24 Table 5: References .......................................................................................................................................................... 99



Glossary

The glossary of terms used in this deliverable can be found in the public document “FOODIE_Glossary.pdf” available at: http://www.foodie-project.eu




Abbreviations and Acronyms

Abbreviation / Acronym

Description

GEO Group on Earth Observations

GEOSS Global Earth Observation System of Systems

GMES Global Monitoring for Environment and Security

INSPIRE Infrastructure for Spatial Information in Europe

MODIS Moderate Resolution Imaging Spectroradiometer. It is an instrument aboard on Terra and Aqua satellites.

OGC Open Geospatial Consortium

OLI Operational Land Imager. It is an instrument aboard on Landsat 8 satellite.

REST Representational State Transfer

RM-ODP Reference Model for Object Distributed Processing

SDI Spatial Data Infrastructure

SERVUS Design Methodology for Information Systems based upon Geospatial Service-oriented Architectures and the Modelling of Use Cases and Capabilities as Resources

SOA Service Oriented Architecture

SoS System of Systems

SWE Sensor Web Enablement

TIRS Thermal Infrared Sensor. It is an instrument aboard on Landsat 8 satellite

UML Unified Modelling Language

VGI Volunteered Geographic Information

VP Viewpoint

W3C World Wide Web Consortium

XML Extensible Mark-up Language

Table 1: Abbreviations and Acronyms



Executive Summary

The FOODIE project aims at building an open and interoperable agricultural specialized platform hub on the cloud for the management of spatial and non-spatial data relevant for farming production, for integration of ex-isting and valuable European open datasets related to agriculture, for data publication and data linking of exter-nal agriculture data sources contributed by different public and private stakeholders, and for providing specific and high-value applications and services for the support in the planning and decision-making processes of differ-ent stakeholders’ groups related to the agricultural and environmental domains.

In the FOODIE project, it is of crucial importance to have well defined, and detailed, functional and technical specifications of the FOODIE service platform hub. In view of this objective, the task 5.1 Pilots Specification and Stakeholders Requirements Elicitation, within the Work Package 5, has an important role in serving as primary input for technical work packages. By taking feedback from users as soon as possible and delivering software in-crementally, FOODIE will greatly improve results and will be focused on user needs and not on technical needs.

Pilots in three different countries have been established: Czech Republic, Germany and Spain. These pilots and their stakeholders have been the basis for collecting the requirements to design the FOODIE platform and pro-vide the services that will fulfil their needs. In addition to the stakeholders involved in the pilots, other end-users partners have provided requirements and will participate in the testing of the platform.



1 Introduction

The purpose of this deliverable is to present the results of the works carried out in the task 5.1 Pilots Specifica-tion and Stakeholders Requirements Elicitation. The document describes the pilots that are going to be executed throughout the project and presents all the information gathered in this phase.

The analysis has been done in a formal way in order to be able to help as an input for the platform description, so the use of a well-established methodology has been an important point to agree on. This analysis will follow the RM-ODP methodology which has been successfully applied in many previous EU research projects related to the geospatial, environmental and agricultural domains. Methodological approach is described in chapter two.

FOODIE concepts and objectives will be demonstrated in three different pilot scenarios across Europe: Spain, Czech Republic and Germany.

Figure 1. FOODIE Pilot Areas

Each of the pilots has its own chapter that fully describes their objectives, scenarios and use cases that have been identified. Following the methodology, three types of requirements have been drawn throughout the anal-ysis phase: functional, informational and non-functional.

Scenario representations provide a means to identify, clarify and classify pilot issues. The pilot specification will have to make explicit and formalize the pilot requirements, expressing at a technical level how the objectives of the project could be addressed. A set of specific elements and sources of information to be integrated within the platform needs have been identified throughout this stage of the process.

Reaching an agreement on common pilot functionalities is an important aim achieved. A broad range of stake-holders shall have different requirements and priorities in each pilot scenario leading to differing expectations of the platform. The key priorities of the all stakeholders have been be assessed. Considering that each final user is most likely to be concerned about their own interest and for its specific activity, this is difficult, but it is a neces-sary step in order to be able to define the FOODIE platform for true useful purposes.

The final result of this task and, hence, the final content of this deliverable, is a set of use cases and require-ments which are being the main input for the technical packages (WP2, WP3, WP4), for the definition of the ar-chitecture, data model and services to be developed.



2 Methodology

2.1 Relationship to the ISO Reference Model

The analysis of user requirements and the derivation of requirements on different software/hardware compo-nents cannot take place without having in mind a common FOODIE system architecture. Here, FOODIE proposes to rely upon agreed international standards such as ISO RM-ODP. Inspired by “distributed processing systems based on interacting objects”, ISO defined the Reference Model for Open Distributed Processing (ISO/IEC 10746-1:1998).The RM-ODP standards have been adopted widely. They constitute the conceptual basis for the ISO 191xx series of geospatial standards from ISO/TC211.

The viewpoints of RM-ODP are applied as follows:

The Enterprise Viewpoint: it describes the purpose, scope and policies of that system and contains the use cases described in the following sections.

The Information Viewpoint: it describes the semantics of information and information processing and contains the information resources identified as the use case extension.

The Computational Viewpoint: it describes the functional decomposition of the system into compo-nents and objects which interact at interfaces. In FOODIE, this viewpoint is also referred to as Service Viewpoint acknowledging its application in (geospatial) service-oriented architectures as predominant architectural style [1].

The Engineering Viewpoint: it describes the mechanisms and functions required to support distributed interaction between objects in the system.

The Technology Viewpoint: it describes the choice of technology in that system.

The use case analysis methodology described in the following sections comprises the activities of the ISO RM-ODP Enterprise Viewpoint. Hence, the specification of use cases and the requirements are artefacts of this view-point and constitute the FOODIE Enterprise Viewpoint specification. Following the RM-ODP model this specifica-tion is the foundation for the abstract system design resulting in the information and service viewpoint, and, fur-ther on, for the concrete system design in the technology and engineering viewpoint.

2.2 General Description

This section provides an overview about the FOODIE Use Case Analysis Methodology. This methodology is in line with the SERVUS methodology [1], partially developed in ENVIROFI project, that aims at a Design Methodology for Information Systems based upon Geospatial Service-oriented Architectures and the Modelling of Use Cases and Capabilities as Resources.

The purpose of the SERVUS methodology as applied in FOODIE is to capture and analyse the requirements of the three pilots of FOODIE. These requirements are elaborated in a first step as use cases (UC) by the experts of the pilots and involved end-users (i.e., in the work package WP5) and documented in this deliverable. Applying an iterative approach, the use cases are continuously refined and extended.

The next sub-sections describe the instantiation of this idea in more detail. In particular, they comprise:

the description of the analysis process (section 2.3.1)

the description of the UC template including an explanation of the UC elements (section 2.3.2),

the description of the requirements template including an explanation of the requirements elements (section 2.3.3), and

the description of the possible relations between use cases and requirements, hence a kind of UC meta-model (section 2.3.4).



2.3 Use Case Analysis Methodology

Use case modelling has been proven to be an efficient and powerful approach to reach a common understanding of the system itself and its behaviour. In interdisciplinary projects, involving thematic experts from different do-mains (e.g., air and water) as well as IT-experts, it is as challenging as essential to reach consensus on a common terminology. Otherwise, the consequences would include different interpretations and assumptions about the systems to be developed. Thus to avoid misunderstandings, use case descriptions shall be based on a common vocabulary, stemming from the glossary and the thesaurus whenever possible.

The description of use cases is necessary to capture all functional and non-functional requirements of the sys-tem. The use cases also describe the interaction between the users and the system. Use cases are the most common practices for capturing and deriving requirements. The requirements of the system are described in a narrative way with minimal technical jargon. In a nutshell: “a use case describes who can do what with the sys-tem and for what” [2].

Those quotes indicate that the most important basis to implement the systems foreseen case studies is use case modelling. Cockburn states that use cases are the central aspect in a software development project. The descrip-tions should be clear and sophisticated.

In this project use cases are described in a semi-formal way, based on a structured textual description in tabular form derived from a template initially proposed by [2]. Other recent European research projects (such as SANY [3], EO2HEAVEN [4], TRIDEC [5] and ENVIROFI [6]) based the description of their use cases on this template, too.

According to the SERVUS design methodology [1] additional information about the requested information re-sources (e.g. type and format of needed data) is necessary to completely describe a use case from both a user’s and system’s point of view. Furthermore, the requirements should be derivable from the use cases. Three types of requirements can be identified:

Functional requirements,

Informational requirements,

Non-functional requirements.

Functional requirements can be derived from the sequence of actions (main success scenario, extensions and al-ternative paths). The informational requirements address data that is exchanged between two communication partners, i.e. between users and the system or between system components. The non-functional requirements cover all requirements that do not alter the foreseen functionality of the system, e.g. the quality of data and re-sults.

2.3.1 Use Case and Requirements Modelling

Figure 2 illustrates the analysis phase as a prelude of the SERVUS Design Methodology [7]. As part of the project planning there needs to be some agreement of how to document use cases. For this continuous activity, a use case repository, accessible by all participants of the analysis process, has to be determined. In FOODIE, this UC repository is provided by the tool Enterprise Architect as described in section 2.6.

As a first step of an analysis iteration loop a set of preliminary use cases (UC) is identified, mostly by those the-matic experts/end-users involved in the project pilots. The methodology proposes that use cases are initially de-scribed in structured natural language but already contain the list of requested resources. This small extension with respect to the approach of [2] heavily facilitates the transition to the abstract design step (here: the specifi-cation of the information model in the Unified Modelling Language UML) but is still very easy to understand by thematic experts.



Hence, this description is the language which is used in the UC discussion that takes place in workshops that are facilitated by the system analyst. Depending on the level of agreement that can be reached the iteration loop is

entered again in order to refine or add new use cases.

In order to identify inconsistencies and check the completeness of the UC model, the system analyst may transform the semi-structural UC description into formal UML specifi-cations. However, these UML dia-grams should still be on a high ab-straction level such that a discussion with the end-user is possible. It is the advantage of this formal transi-tion step already in an early analysis phase to detect inconsistencies and missing information as quickly as possible. The UML specification helps to (re-)discuss and check the use cases together with the themat-ic experts.

However, in addition to the usual UML use cases they already com-prise the links to the set of request-ed (information) resources, their representation forms and the re-

quirements to create, read, write or delete them. Guidance about these UML diagrams is provided in section 2.3.5. Once an agreement is reached about the set of use case descriptions and related UML specifications it is then up to the system analyst to specify the resulting information model taking the resource model as a first guidance.

2.3.2 Use Case Template

Based on the state-of-the-art analysis of the previous section, this section describes the adapted approach for the use case description in this project and also the guideline to fill out this template.

As mentioned above, the approach of [2] provides the basis for the use case development in this project. How-ever, the SERVUS methodology proposes that beside the functional and non-functional requirements the infor-mational requirements are very important to complete the use case description. For a more detailed analysis (especially for IT-experts) and as a first step towards information modelling it is necessary to consider input data, data format, data type, data encoding, and the desired format of the output data, too. Thus the template con-tains additional issues like ‘Requested Information Resources’.

The common form of a use case description is to describe it from the user’s point of view where only the external perceivable behaviour is reflected. The described system is a black box for the user. This template should be used by both sides, the users and the system developers and operators. Both sides and all involved experts have to understand the use cases in the same way. Especially the IT experts should understand the user’s requirements because they have to develop the IT-components on the basis of the descriptions. It is foreseen to describe each use case in a semi-formal way. A form was created to structure the textual description. The table represents the use case template and is shown in Table 1. The methodology describes the use case template items, explains what each item mean, instructs how to fill them out and includes additional examples and tips.

Generally, to avoid getting lost in details, [8] proposes to concentrate on the standard cases for each Use Case (what most likely will happen) in the first iteration of developing a specific Use Case. In the next iteration, exten-sions and alternative paths are modelled that only happen under certain conditions like optional, seldom or al-

Figure 2. Procedure of the FOODIE Use Case Analysis



ternative steps.

Use Case At-tribute

Description Examples

Use Case Name

Name of the use case Visualise proposed water height after the tsunami event

Use Case ID

Unique identifier of a use case according to the following scheme:

FOODIE-UC-PILOT<pilot>.<scenario>-<category>-<use case no.>.-V<version no.>

* pilot number, i.e. Spain (Pilot 1), Czech Republic (Pilot 2) and Germany (Pilot 3)

* scenario: The number of the scenario within the pilot

* category: no particular scheme has to be applied. One can either specify it e.g. with 'mob' (for mobile applica-tion) or use 'any' if no specification needed.

* (sub) use case number: two digits for each separated by a dot

* version number: two digits with V prefixed

FOODIE-UC-PILOT1.2-mob-05.06-V02

Revision and Reference

Revision = version number of use case ID V02

Use Case Dia-gram (option-

al)

Description of the UML use case diagram for the actual use case. The diagram should include extend and include relationships if there is any.

The actual UML diagram figure may be added at the bot-tom of the template by uploading a bitmap generated from a UML editor, e.g. Enterprise Architect of SPARX systems.

Status Status of the use case development

One of the following:

planned

in progress

completed

cancelled

Priority of ac-complishment

(optional)

The priority of the use case to be considered when as-sessing its importance for a development cycle.

One of the following:

Must have: The system must implement this goal/ assumption to be accepted.

Should have: The system should implement this goal/ assumption: some deviation from the goal/assumption as stated may be ac-ceptable.

Could have: The system should implement this goal/assumption, but may be accepted without it.

Goal Short description (max. 100 characters) of the goal to be achieved by a realization of the use case.

System generates alerts based on user observations

Summary Comprehensive textual description of the use case. The user opens the browser which shows map-window with the water height after the tsunami event in the affected area

Category (op-tional)

Categorisation of use cases according to overall refer-ence architecture.

Data Input



Use Case At-tribute


Actor List of users of the use case (actors) Examples may be citizen, administrator or farmer

Primary Actor (initiates)

Actor that initiates the use case execution.

Stakeholder (optional)

Company, institution or interest group concerned by the execution of the use case

Requested In-formation Re-

sources

(optional)

Information category or object that is required to exe-cute the use case or is being generated during the course of the use case execution.

The requested information resource shall be listed to-gether with its requested access mode (create, read, up-date or delete) or “manage” which encompasses all ac-cess modes.

user observation (read)

user-specific effect (read, update)

alert (manage)

Preconditions

Description of the system/user status statement) that is required to start the execution of the use case.

Note that use cases can be linked to each other via „pre-conditions“. This means, a precondition for a use case can be either an external event or another use case. In this case the use case ID should be provided in the field “preconditions“.

The user has opened the portal successfully.

Triggers (optional)

(External) event that leads to the execution of the use case.

Note that use cases can be linked to each other via „trig-gers“. This means, a trigger for a use case can be either an external event or another use case. In this case the use case ID should be provided in the field „triggers“.

The user chooses water height forecast.

Main success scenario

Numbered sequence of actions (use case workflow) to be carried out during the execution of the use case.

1. User chooses assessment report.

2. He specifies one or more components (default should be all).

3. He sets a time-frame (last 24 hours, last week, last month)

4. The system shows a report as graphical visualisa-tion.

Extensions (optional)

Extension of an action of the main success scenario. The action to be extended shall be referred to by its number (e.g. 1) appended by a letter (e.g. 1a).

1a. The user defines the temporal extent

1b. The user defines an unavailable temporal extent. A new dialogue window opens and requires a new temporal extent.

Alternative paths (op-

tional)

Alternate path through the main success scenario w.r.t. an identified action.

4a. User can select to view report in different for-mats, e.g. tabular or graphical map

Post condi-tions

Description of the system/user status (statement) that holds true after the successful execution of the use case.

Report is displayed on the screen.

Non-functional re-quirements

Description of non-functional requirements for this use case w.r.t. performance, security, quality of service or re-liability.

Display of report expected after 20 seconds at the latest.

Validation statement

List of statements that indicate how to validate the suc-cessful realization of the use case.

Notes Additional notes or comments (also by other users).

Author and Author of use case, date of last edition. ATOS, 2014-04-08



Use Case At-tribute


date

Table 2. Description of the FOODIE Use Case Template

2.3.3 Requirement Template

In this section the current template for the analysis of the (requirements for) generic and specific components in FOODIE system architecture is shown. It applies the agile software requirements analysis methodology based upon so-called backlog items [9].

Requirements Attribute ENUM Description Comments

Requirement ID No

Unique identifier of a requirement ac-cording to the following scheme:

FOODIE-REQ-<requirement>-V<version no.>

* requirement number,

* version number: two digits with V pre-fixed

FOODIE-REQ-06-V02

Requirement Name No Descriptive name of the entry This will be an acronym.

Goal No Short phrase describing the goal for this entry

Version No Version associated to the entry. Helpful to monitor progress and follow-up mod-ifications

Source Yes Project or organization who identified the use case / feature

Source contact No Contact point in Source project or or-ganization (was "Author")

Contact point of the source

Stakeholder Yes (per item in

list)

List of additional projects or organiza-tions interested in coverage of the use case / feature (the source is considered to be a stakeholder)

The value of this field may change over time




Scope Yes

Could be:

"Platform" = it relates to a functional or non-functional feature required at plat-form level (not yet agreed whether "common" or "generic")

"Platform Generic" = It relates to a fea-ture required at platform level and gen-eral purpose

"Platform Common" = It relates to a functional or non-functional feature re-quired at platform level but whose ap-plicability is restricted to applications in a few number of domains (pilots)

"Application" = It relates to a user story related to some functional o non-functional feature required at applica-tion level

"Global" = It relates to some functional or non-functional feature required both at platform (generic or common) and application level

"Not Yet Determined" = when decision still has not taken place

The value of this field may change over time

Status Yes

Should be "Pending" (still not revised), "Planned" (is in the roadmap), "Under execution" (being developed in current sprint), "Done" (has been already devel-oped) or "Deprecated" in which case the Description field should explain why and the list of Ids of entries replacing it when applicable.

Maybe we need to establish here a link to some ticket in a ticket management tool like bugzilla or the FusionForge tracker




MoSCoW priority Yes

MUST - Features that absolutely have to be done are categorized as Must. If any of these features are not done, the pro-ject will be considered a failure.

SHOULD - Features that are important to the success of the project, but are not absolute musts (they have a worka-round or will not cause the project to fail) are categorized as Should.

COULD - Features that are nice to have but are not core features are catego-rized as Could.

WONT - Features that are not going to be implemented this time are marked as Won't.

In the first place, while "Owner" has not been identified, this priority will be assigned by the Source. Stakeholders may agree to change it. Final value will be assigned by the "Owner", although a new entry may be created, keeping the previous one for the sake of history (which would change to "Deprecated" status pointing to the new en-try).

Clarification on WONT priority: Why should we have WONT features in the backlog? There are two reasons. One is that feature priorities can change as the project goes on. These features could have started as Should and been re-prioritized to Wont, and they may be re-prioritized back again. The second is that these features are a starting point to the second ver-sion.

Remember that features prioritized as “Must” should be only those features without which the project cannot be put into production, and will cause the project to fail. When you decide to mark a feature as “Must”, ask yourself if the pro-ject will have to be cancelled if this feature is not implemented. Only if the answer is yes should you go ahead and prioritize it as Must.

Relative priority No Priority number relative to the same MoSCoW priority

In the first place, while "Owner" has not been identified, this priority will be assigned by the Source. Stakeholders may agree to change it. Final value will be assigned by the "Owner", although a new entry may be created, keeping the previous one for the sake of history (which would change to "Deprecated" status pointing to the new en-try). We may use maybe a number of 2 digits, with the first one linked to the MoSCoW priority and the second to the relative priority. That would allow to order entries just based on this number. Thus, we may have: Priority 35 = "Should" with priority 5 among those labelled as "Should"

Category Yes

Will refer to categories in FOODIE archi-tecture (e.g.,: - "Cloud" - "Data services" - "Visualization" - "Processing" - "Security", etc.).

Component No

Only applicable to Platform features. It identifies the component to which this entry (feature) in the architecture ap-plies.

Rationale No Rationale of why the feature is needed




Description No

Description of the feature.

Proposed information but this will not be mandatory: - Actors - Primary Actors - Facades - Preconditions - Triggers - Main success scenario ("How to demo") - Extensions - Alternative paths - Postconditions - Notes

Complexity Yes

Number describing how complex sup-porting the use case / feature will be. Will map to the following categories: - XXL: Costs quite a lot - XL: Costs a lot - L: Has a significant cost - M: Medium cost - S: Doesn't take that much - XS: It's almost trivial

Creation Date No Date of creation

Last modified No Last date at which it was modified (any field)

Table 3. Description of the FOODIE Requirements Template

2.3.4 Relation Types between Use Cases and Requirements/Components

The following types of relations will be implemented to link use cases to other use cases or to link use cases to requirements and/or components in WP2:

UC to UC

Includes (inverse relation: is included in): one UC is included in another UC, i.e. one UC is included as a whole in the main success scenario, extension or alternate path of another UC.

refines (inverse relation: abstracted from): one UC is a refinement of another UC, e.g. it provides more details in its main success scenario, adds an extension or interprets a more abstract UC in the context of a thematic domain.

UC to REQ

Maps to (inverse relation: is derived from): a UC is mapped to a REQ defined by WP2 (--> generic com-ponent/requirements or --> specific component/requirements).

REQ to REQ

Related to (bijective relation): one REQ is related to another REQ, i.e. there is some relationship be-tween the components/requirements. This relation has to be better qualified in the future. It could be a unilateral or bilateral dependency but also some similarity in terms of concepts, design pattern or tech-nology.

These relations are illustrated in Figure 3.



Figure 3. Relationships between Use Cases, Components/Requirements, Actors and Information Resources

(Note: The relationship between Use Cases, Requirements, Components and Test Cases will be described in a later stage of de project.)

Further important concepts in the use case modelling are actors and (requested) information resources. For completeness, they are also contained in Figure together with their relationships although they are not yet im-plemented as distinct identifiable concepts in the UC server. The possible relations are as follows:

UC to Actor

Performs (inverse relation: is performed by): a UC is performed by an actor.

UC to Information Resource

Requests (inverse relation: is requested by): a UC requests an information resource in a defined access mode (create, read, update, delete).

Information Resource to Information Resource

Refines (inverse relation: abstracted from): an information resource is a refinement of another infor-mation resource (in the sense of inheriting all properties of the more abstract information resource).

Related to (bijective relation): an information resource is related to another information resource. The meaning of the relation may be defined during the information modelling design step.

2.3.5 UML Representation

After having described the use cases in a semi-formal way using the template, a more formal step is recom-mended to represent the use cases. They are modelled in a formal graphical way by using the UML tool Enter-prise Architect of SPARX Systems. This figure shows the general schema for such UML representations. In addi-tion to the conventional UML use case diagrams they comprise the links to the requested information resources.



Figure 4. Schema for the Graphical Representation of a Use Case

The graphical description is divided into three parts:

The upper region comprising

o All information objects (requested information resources) necessary for the execution of the use case,

The middle section comprising

o All actors, and

o The main use case and all related use cases, and

The lower section comprising

o The additional result objects (also in terms of requested information resources).

According to section Relation Types between Use Cases and Requirements/Components we distinguish the fol-lowing relation types between these graphical elements1:

a) Relation types between actors and use cases:

Here the relation type “uses” is applied, i.e. an actor <<uses>> a use case.

b) Relation types between use cases:

The relation type <<include>> may be applied.

1 In UML marked as <<stereotypes>> with the associations.



The relation type <<refine>> may be applied.

The relation type <<update of>> may be applied.

c) Relation between Use Case and Information Object:

This relation expresses the involved information objects (requested information resources). In most cases a distinction is made between a <<creates>>, <<reads>>, <<updates>> or <<writes>> relation, expressing the access rights to create an instance of the related object, to read its attributes, to write (update) its attributes or to delete an instance of the related object. All these relations to-gether may be encompassed by the relation <<manages>>.

d) Relation between result objects and further information objects.

The relation “depends on” describes that the existence or the contents of the result object depends on the existence or contents of another information object.

2.4 Validation Process Description

The validation process aims to ensure that the set of requirements gathered throughout the process of analysis and the model of the system meets the needs of the different stakeholders that will be the final users of the FOODIE platform.

The process validation lifecycle involves:

Selecting the products and the method for validation: in this case, the object of the validation is the model of the system; the methods to perform the validation are the stakeholders’ revision and the proto-type demonstration. The prototype shows explicitly the interaction between user and system helping to validate the functionality modeled by the use cases.

Establishing validation criteria: the validation of the model ensures that the products and services will not be developed based on wrong specifications. Here, the validation criterion is that all the functionalities requested by the user in the analysis process are properly included in the set of use case and require-ments. The model specified has to fulfill the user requirements as well as it has to satisfy the user expecta-tions. Besides, from the methodological point of view, the validation process will reject those require-ments that are not:

o Complete: the requirement contains all relevant information. o Consistent: the requirement is compatible with the others. o Viable: the requirement can be implemented with the available resources. o Unambiguous: the requirement doesn’t have different interpretations. o Comprehensible: the requirement is understandable by all the stakeholders. o Traceable: the requirement must be related with at least one use case.

Performing the validation using the validation methods and criteria previously defined. Stakeholders will have to revise and approve the requirements and use cases changing their status from “Pending” to “Planned” if applies.

Analyzing validation results: the review of the results of the validation will establish the acceptance of the requirements and use cases or define the issues that have to be solved.

2.5 Change Management

The purpose of change management is to ensure that all changes are planned, communicated, recorded and im-plemented successfully.

This are the steps to be followed for all changes in the model that could potentially have impact in the system:



Figure 5. Change Request Flow Diagram

Identify and define the scope: once the need of change is detected, the scope has to be fully defined. The

impact of the change has also to be established together with its viability. As a result of this stage, the docu-

ment including the description of the change, tasks involved in its implementation and planning is elaborat-

ed. This document has to include, at least, the following items (see template below):

o Date of the change request

o Petitioner

o Change description

o Justification

o Priority

o Impact of the change (on cost, schedule, resources…)

o Risks (with implementing the change and with not implementing it)

o Alternatives (if apply)

o Estimation (in terms of cost and working days)

Approve/Deny: the change evaluation document generated previously has to be delivered to the appropriat-

ed stakeholders in order to approve or deny the change request and, if approved, establish when it must be

included.

Implement: if the change request is approved, it will be included and the related documentation will be up-

dated in order to reflect the result of the change. The traceability established between all the elements in the

process of analysis (scenarios, use cases and requirements) will assure that, despite the changes in individual

elements, all the information will remain consistent.

Close: once the change is performed and, after verifying its consistency, the change request is finished.

All changes must be documented with this template for change request registration:



Change

Request

Attribute

ENUM Description Comments

Date No Date of the change request

Petitioner No Stakeholder who performed the request

Description No Comprehensive textual description of the change re-quest

Justification No Reasons why the change is necessary

Priority Yes The priority of the change request to be considered when assessing its importance for a development cycle.

1. High

2. Medium

3. Low

Impact No The impact of the change in terms of cost, schedule, re-sources, and whatever it involves.

Risks No Description of the risk, if apply, with implementing the change and with not implementing it.

Alternatives No Description of alternatives, if apply, to the change, when it is not viable, in any way, to achieve the specific change.

Estimation No Estimation in terms of cost and working days

Notes No Additional notes or comments

Author and date No Author of change request, date of last edition.

Table 4. Description of the Change Request Registration Template

2.6 Tool support

FOODIE team members use Sparx Enterprise Architect (EA) software, which enables the edition and manage-ment of the UC and requirements descriptions including their interdependencies between these concepts.

The objective of usage of this tool is to provide a collaborative tool to share the edition of use cases. Due to the possibility to link use cases with other use cases and to requirements, it also enables the easy navigation and browsing through the use cases and requirements.

Furthermore, the tool allows automatically generate documents in pdf format out of the use case and require-ments descriptions. This facility is being used in order to generate the following reports:

List of pilot specific uses cases summarized in sections 3.5, 4.5 and 5.5; provided as annex A to this de-liverable

List of generic (abstract) use cases summarized in section 7.2 and provided as annex B to this delivera-ble

List of specific requirements (based on the list of specific use cases) summarized in sections 3.6, 4.6 and 5.6; provided as annex C to this deliverable

List of generic requirements (based on the list of generic use cases) summarized in section 7.3 and pro-vided as annex D to this deliverable

A common repository will be established, gathering SERESCO the different repositories from the partners in or-der to integrate them. The complete version will be shared in Alfresco repository.



3 Spanish Pilot Description

3.1 Introduction

The main objectives of Precision Viticulture (or PV, which is the focusing concept of the Spanish Pilot) are the appropriate management of the inherent variability of crops, an increase in economic benefits and a reduction of environmental impact. Variable-rate application (VRA) of inputs and selective harvesting at parcel level are productive strategies which provide significant benefits for winegrowers, as well as for farmers in general. There are specific aspects for vineyards, as differentiation of various grape qualities at grape harvest time, yield predic-tion and greater precision and efficiency of samplings conducted at parcel level, prevention of pests… that are crucial.

The expected results are based on the following working hypothesis:

The zoning of the parcels will allow us to deepen the understanding of the spatial variability, the differ-ences between parcels and their qualitative possibilities.

The plant vigour analysis by vegetation indices, the electromagnetic mapping of the soil and the de-ployment of a network of sensors, will provide crucial data for proper vineyard management such as the nutritional status, climatic conditions and so on, which would help to optimize tasks such as phyto-sanitary treatments applied or nutrient supply needed of each parcel among others.

As a result, we will be able to extract from each different parcel or homogeneous set of parcels its qualitative potential, adjusting their nutritional needs and their protection against common diseases in the area.

This pilot will take place in Spain, in the region of Galicia, province of Pontevedra, where Terras Gauda, a wine pro-ducer, has 160 ha. (400 acres roughly). The total extension being part of the project will amount 150 acres.

These are the fundamental tasks to perform:

1) Initial zoning of the parcels, based on known geo-climatic and topographical information The aim is to identify the areas that reveal similar productive potential and which, therefore, can be uni-formly managed. The yield map (grape harvest, soil depth, etc.) obtained previously constitutes the first link of data analysis. Analysis of spatial variability is important for two reasons: from the perspective of PV, it al-lows the identification of areas of different productive potential within the parcel and an evaluation of the opportunity for their differential management; from the perspective of viticulture experimentation, allows better interpretation of the results. Management zones normally differ between them in terms of soil prop-erties, slope and microclimate. Analysis techniques, which consider scalable data analytics because of the huge amount of data which can be obtained from diverse public datasets, must be used to allow zoning at parcel level.

2) Selection, installation and management of sensors and monitors, VRA equipment and machinery FOODIE will provide tools for GIS and data analysis but must be complemented with other technologies: GPS and differential GPS (DGPS), crop sensors and monitors, local and remote sensors, VRA equipment and ma-chinery. There will be twenty sensor nodes and three more for relay purposes to avoid the problems arising from the existence of relatively large distances between the different parcels.

3) Quantification and evaluation of within-field variability through:



Grape harvest monitoring systems and local/remote sensors to measure soil and/or crop properties will provide significant amounts of data at parcel level. In addition, public datasets will provide huge amounts of valuable data, which can be obtained for different properties and for successive years. The analysis will take into account and integrate, in addition to local gathered data, available data from dif-ferent sources that have been identified as relevant for the project:

Land satellite images: will be used to characterize the fields in detail, combined with geographical information, to allow determining more efficient cultivation practices.

Environment and biodiversity information: monitoring and observation of the Earth (mainly by sat-ellite sensor instruments) so as to detect changes in vegetation, atmospheric conditions (tempera-ture, humidity, rainfall, solar radiation, wind speed and direction).

Agro-food statistical indicators: provided by national and international agencies, such as FAO and Eurostat, information which is very valuable to understand the structure of the wine sector and the evolution and competitiveness of the market.

The integration of open data will allow obtaining the benefits of the comparison between local and global information and this will improve the decision-making processes since the information obtained from multi-spectral images has been frequently used to estimate crop vigour and to forecast yield, with good results.

All this different sources of data must be selected and combined to provide mapping of the variables sam-pled on site over one reference grid (raster map or surface map), that is, to obtain a yield map, which con-stitutes the basis of the PV management tools.

4) Measures of final grape production and wine quality, depending on the initial zoning The analysis procedure of both the grape production and the wine quality, according to the defined zoning will give essential relationships between spatial variability and those parameters and that will enable an ac-curate objective assessment of wine grapes.

5) Zoning review in accordance with the results A final revision of the results will allow a new zoning of the parcels and a new process to be initiated so as to refine the model and subsequently improve the results.

3.2 Pilot Scenarios

This section contains a high level description of the scenarios and their use cases identified in the requirement elicitation process. A very complex process involving interviews with the technical direction of the wine compa-ny, a pre-analysis of the information provided by the final user and in-situ observation of the vineyards.

As a result of this process three main needs were identified:

Register and geo-localize all the operations and information regarding the vineyard, such as the treat-ments applied to, the results of soil analysis or the yield production for each grape variety.

A decision support system based on recommendations and predictions taking into account vigor and moisture indices of crops, near real-time measures of temperature and humidity or weather predic-tions, among others.

Representation of all this information in a spatial and temporal dimension interacting with the system in order to obtain an intuitive representation of these data on a GIS viewer.

These needs are considered in the three scenarios considered in the pilot:

Scenario A – Registration of geo-located information about operations in field.

Scenario B – Obtaining of recommendations and predictions of interest for vine-growers.

Scenario C – Geographical, textual and numerical representation of the registered information.



Following sections describe the scenarios and their use cases. Figure 6 (next page) shows the scenarios and links them with the main use cases of each one.

Figure 6 Spanish Pilot Scenarios/Use Cases



3.2.1 Scenario A – Registration of geo-located information about operations in field

The identification of homogeneous zones of crop land areas is a key factor in the precision agriculture context. These management zones (MZ) address spatial variability of crops grouping areas that share similar soil proper-ties in order to apply specific farming practices to each MZ. This scenario provides the user the functionalities to register the inputs and outputs of the Management Zones identified by the UC: FOODIE-UC-PILOT1.B-01. Vali-date Management Zones.

In this precision agriculture scenario, the treatments applied to the crops as well as production, irrigation and the analysis of samples of soil, leaf and grape juice are recorded including spatial and temporal references.

Name ID Goal

Register treatments FOODIE-UC-PILOT1.A-01 Register geolocated and temporal data related with treat-ments applied to the crops

Register production FOODIE-UC-PILOT1.A-02 Register geolocated and temporal data about production

Register irrigation FOODIE-UC-PILOT1.A-03 Register geolocated and temporal data about irrigation

Register the results of analysis FOODIE-UC-PILOT1.A-04 Register the results of analysis of selected samples from representative parcels

Register treatment plans FOODIE-UC-PILOT1.A-05 Register the treatments composition that will be ap-plied along the campaign

Figure 7 (next page) shows the use cases diagram related with this scenario.



Figure 7: Spanish Pilot Use Cases for Scenario A

uc Use Cases Register geolocated and temporal data

System

Field Operator

Technical Director

FOODIE-UC-PILOT1.A-01.

Register treatments

FOODIE-UC-PILOT1.A-

01.02. Register

phytosanitary treatments

FOODIE-UC-PILOT1.A-01.01.

Register herbicide treatments

FOODIE-UC-PILOT1.A-

01.03. Register fertilizer

treatments

FOODIE-UC-PILOT1.A-

01.04. Register pruningFOODIE-UC-PILOT1.A-

01.05. Register

observ ations

FOODIE-UC-PILOT1.A-01.05.01.

Register issues


Register production


Register irrigation activ ities


Register the results of

analysis


Register leaf analysis


Register soil analysis


Register grape juice analysis

«InformationResource»

FOODIE-IR-DP-02. Database of

precision v iticulture management


FOODIE-IR-DP-04. GPS instrument

of agricultural v ehicles


FOODIE-IR-DP-05. GPS instrument on

mobile dev ice

Web Serv ice


Register Treatment plan

«extend»

«extend»

«write,read»

«read»

«extend»

«extend»

«write,read»

«extend»

«write,read»

«extend»

«read»

«extend»

«write,read»

«extend»

«extend»



3.2.2 Scenario B – Obtaining of recommendations and predictions of interest for vine-growers

The knowledge of the vine-grower about the crops and soil could be a starting point in the delimitation of ho-mogeneous zones, however methods for a systematic MZ identification such as the classification of apparent soil electrical conductivity or the analysis of soil reflectance are needed.

On the other hand, weather conditions are one of the key factors that affect the health and the growing of crops. The knowing of meteorological variables and indicators of vigour and moisture for a particular manage-ment zone allows providing recommendations based both on these data and on weather forecast. Recommen-dations such as harvesting date, irrigation and fertilization needs as well as where and when the phytosanitary treatments must be applied, are the core of the decision support system. Historical data, weather conditions and soil analysis are considered in order to estimate production.

Name ID Goal

Validate Management Zones

FOODIE-UC-PILOT1.B-01 Identify Management Zones

Obtain annual Irrigation and fertilization planning

FOODIE-UC-PILOT1.B-02 Provide annual fertilization composition that will delivered by irrigation

Obtain precision recom-mendations

FOODIE-UC-PILOT1.B-03 Provide recommendations for MZ related to irrigation, fertili-zation, herbicidal and phytosanitary treatments

Obtain recommendations about harvesting

FOODIE-UC-PILOT1.B-04 Provide recommendations related with when and where to start the harvesting

Obtain prediction about an-nual production

FOODIE-UC-PILOT1.B-05 Provide recommendations related with the expected produc-tion by MZ




Figure 8: Spanish Pilot Use Cases for Scenario B

uc Use Cases Precision Recommendations and predictions

System

Technical Director

(from

Users and

Roles

(Actors))

Weather resources

+ FOODIE-IR-DS-01. Public agro-meteorological station

+ FOODIE-IR-DS-02. Public weather radar of Xunta Galicia

+ FOODIE-IR-DS-03. API MeteoGalicia

+ FOODIE-IR-DS-04. WRF (Weather Research Forecast)

(from Data sources)

FOODIE-UC-PILOT1.B-01.

Validate management zones

FOODIE-UC-PILOT1.B-02.

Obtain annual irrigation and

fertilization planning

FOODIE-UC-PILOT1.B-03. Obtain

precision recommendations

FOODIE-UC-PILOT1.B-03.01.

Obtain precision

recommendations about

fertilization


Obtain precision


irrigation


Obtain precision


phytosanitary treatments


Obtain precision


herbicidal treatments


recommendations about harv esting


prediction about annual

production


Other resources::FOODIE-IR-DS-05.

Phytosanitary bulletin of Deputation of

Pontev edra

(from Other resources)


Databases::FOODIE-IR-DP-02. Database of

precision v iticulture management

(from Databases)


Instruments and sensors::FOODIE-IR-DP-01.

Waspmote plug & sense sensors deployed in

field

(from Instruments and sensors)


Instruments and sensors::FOODIE-IR-DP-03.

Spectrophotometer cameras mounted on

agricultural v ehicles


Satellite resources

+ FOODIE-IR-DS-06. MOD09GQ data product from Terra satell ite

+ FOODIE-IR-DS-07. MYD09GA data product from Aqua satellite

+ FOODIE-IR-DS-08. OLI data product from Landsat 8 satell ite

+ FOODIE-IR-DS-09. TIR data product from Landsat 8 satell ite

+ FOODIE-IR-DS-10. Data products from Sentinel-2 satell ite

(from Data sources)

«read»

«read»

«read»

«read»

«extend»

«read»

«read»

«read»

«read»

«extend»

«write,read»

«read»

«write,read»

«read,write»

«read»

«read»

«read»

«read»

«read»

«extend»

«read,write»

«extend»



3.2.3 Scenario C – Geographical, textual and numerical representation of the registered information

Data managed at Scenario A, and other geo-referenced information used and captured by the system have a spatial dimension. The possibility of see and filter this information in a Geographic Information Service (GIS) viewer will be crucial to gain a holistic knowledge about the crops not only in the spatial dimension, but also in a temporal one.

Name ID Goal

Display data from agro-meteorological in-field stations

FOODIE-UC-PILOT1.C-01 Show near real-time measures collected by in-field sensors and their localization

Display Vegetation Indices of the crops FOODIE-UC-PILOT1.C-02 Show contour lines the Vegetation Indices at MZ

Display treatments applied FOODIE-UC-PILOT1.C-03 Show the localization of treatments applied to MZ and registered on the system

Display historical data about production FOODIE-UC-PILOT1.C-04 Show historical data about production of each MZ and its representation in the map

Display historical results of analysis of samples

FOODIE-UC-PILOT1.C-05 Show historical data about the analysis of samples for each MZ and its representation in the map

Display treatment plans FOODIE-UC-PILOT1.C-06 Search and show the data regarding the treatment plans




Figure 9: Spanish Pilot Use Cases for Scenario C

uc Use Cases Diagram. Data Visualization

System

FOODIE-UC-PILOT1.C-02. Display

v egetation indices of the crops

Technical Director

(from

Users and

Roles

(Actors))

FOODIE-UC-PILOT1.C-01.

Display data from agro-

meteorological in-field stations

FOODIE-UC-PILOT1.C-02.01.

Display moisture indices


Display structural v egetation

indices


Instruments and sensors::FOODIE-IR-

DP-03. Spectrophotometer cameras

mounted on agricultural v ehicles



Display treatments applied


Instruments and sensors::FOODIE-

IR-DP-01. Waspmote plug & sense

sensors deployed in field



Display phytosanitary

treatments


Display herbicide

treatments


Display fertilizer treatments

FOODIE-UC-PILOT1.C-03.04

Display prunes


Display observ ations about

crops

FOODIE-UC-PILOT1.C-03.05.01.

Display issues detected


Display historical data about

production


Display historical results of

analysis of samples


Display the results of leaf

analysis


Display the results of soil

analysis


Display the results of grape

juice analysis


Satellite resources::FOODIE-IR-DS-

06. MOD09GQ data product from

Terra satellite

(from Satell ite resources)


Satellite resources::FOODIE-IR-

DS-07. MYD09GA data product

from Aqua satellite



Satellite resources::FOODIE-IR-DS-08. OLI

data product from Landsat 8 satellite



Satellite resources::FOODIE-IR-DS-10.

Data products from Sentinel-2 satellite



Databases::FOODIE-IR-DP-02.

Database of precision v iticulture

management

(from Databases)


Display treatment plans

«read»

«extend»

«extend»

«read»

«read»

«read»

«read»

«extend»

«extend»

«extend»

«read»

«read»

«extend»

«extend»

«read»

«extend»

«read»

«extend»

«read»

«extend»

«read»

«extend»



3.3 Users and Roles

Description of the actors involved in the use cases and their roles. Three main actors have been identified in the different scenarios and use cases: Technical Director, Field Operator and Web Service.

Figure 10 Spanish Pilot Users and Roles

3.3.1 Technical Director

The technical director is responsible for establishing, organizing and leading vineyard service in order to improve the yield and get high quality grapes for the elaboration of wine. This work requires a deep learning of the soil, vineyard and its spatial variability, adapting the technical and agro-technical operations particularly for every va-riety of grape and location. However this knowledge about the vineyard it is not enough to make decisions and establish strategies. Information about weather prediction, near real-time measures of temperature and humidi-ty, vigor and moisture indices of crops and other factors are key ones for improve the aforementioned decision process and strategies. This set of information have a spatial and temporal dimension and the technical director must interact with the system for obtain an intuitive representation of these data on a GIS viewer.

From a UML viewpoint, technical director is a specialization of Field Operator. The actor starts the same use cas-es as the Field Operator and, in addition, initiates all the UC from scenarios B y C.

3.3.2 Field Operator

The field operator follows the guidelines established by the technical director and performs the required opera-tions and treatments applied to crops such as pruning or herbicide treatments.

This actor takes part mainly in use cases in Scenario A and is involved in registering the information related to the aforementioned operations.

3.3.3 Web Service

This actor represents the interface between the system and the input resources such as in-field sensors, the in-struments of agricultural vehicles and the App running on mobile devices.

uc Users and Roles Diagrams (Actors)

Technical Director

Field OperatorWeb Serv ice



3.4 Data Sources and Data Input

Information about data sources and data input extracted from requirements elicitation.

Information Resource Attribute


Information Resource ID

No

Unique identifier of an information resource accord-ing to the following scheme:

FOODIE-IR-<type>-<information resource>

* type: DS for data source and DP for Data

* Information resource number

FOODIE-IR-DS-01

Information Resource Name

No Descriptive name of the entry Weather radar

Short Description No A short description of the information resource

Meteorological radars generate Plan Position Indicator (PPI) about rainfall. From this data product the following estimations are generated upon the raindrop size distributions and radar reflectivi-ty, according to Marshall-Palmer's formula

Version No Version associated to the entry. Helpful to monitor progress and follow-up modifications

Source Yes URL of the information Resource http://www.meteogalicia.es/observacion/radar/radar.action?request_locale=es

Data Access No A description of how access or download the data of the information resource

Via HTTP

Status Yes

Should be "Pending" (still not revised), "Planned" (is in the roadmap), "Under execution" (being devel-oped in current sprint), "Done" (has been already developed) or "Deprecated" in which case the De-scription field should explain why and the list of Ids of entries replacing it when applicable.

MoSCoW priority Yes

MUST - Features that absolutely have to be done are categorized as Must. If any of these features are not done, the project will be considered a failure.

SHOULD - Features that are important to the success of the project, but are not absolute musts (they have a workaround or will not cause the project to fail) are categorized as Should.

COULD - Features that are nice to have but are not core features are categorized as Could.

WONT - Features that are not going to be imple-mented this time are marked as Won't.

Remember that features priori-tized as “Must” should be only those features without which the project cannot be put into pro-duction, and will cause the pro-ject to fail. When you decide to mark a feature as “Must”, ask yourself if the project will have to be cancelled if this feature is not implemented. Only if the answer is yes should you go ahead and prioritize it as Must.

Category Yes

- Instruments and sensors - Database - API

- Analytical

Related Use Case Yes An enumeration of ID of UC related with this re-source.

FOODIE-UC-PILOT1.C-01



Information Resource Attribute


Related Informational Requirements

Yes An enumeration of ID of requirements related with this resource.

FOODIE-REQ-02, FOODIE-REQ-03

Data Description No A description of the data provided

The type and intensity of the rain-fall: • Light rain: intensity lower or equal than 2 mm/h. • Moderate: intensity greater than 2 mm/h and lower or equal than 15 mm/h. • Heavy rain: intensity greater than 15 mm/h and lower or equal than 30 mm/h. • Very heavy rain: intensity great-er than 30 mm/hand lower or equal than 60 mm/h. • Extreme rain: intensity greater than 60 mm/h And the rain accumulated in 6 hours.

Data Format No The format of the data HDF

Creation Date No Date of creation

Last modified No Last date at which it was modified (any field)

3.4.1 FOODIE Sources

For more information regarding FOODIE Sources, please check Annex E.

ID Name Category Status Priority Version

FOODIE-IR-DP-01

Waspmote plug & sense sensors de-ployed in field

Instruments and sensors Planned MUST 1.0

FOODIE-IR-DP-02

Database of precision viticulture man-agement

Database Planned MUST 1.0

FOODIE-IR-DP-03

Spectrophotometer cameras mounted on agricultural vehicles

Instruments and sensors Planned COULD 1.0

FOODIE-IR-DP-04

GPS instrument of agricultural vehicles Instruments and sensors Planned SHOULD 1.0

FOODIE-IR-DP-05

GPS instrument on mobile device Instruments and sensors Planned SHOULD 1.0

FOODIE-IR-DP-06

Database SIGPAC Database Planned COULD 1.0

FOODIE-IR-DP-07

Database INE Database Planned COULD 1.0



3.4.2 External Sources


FOODIE-IR-DS-01

Public agro-meteorological station Instruments and sensors Planned SHOULD 1.0

FOODIE-IR-DS-02

Public weather radar of Xunta Galicia Instruments and sensors Planned COULD 1.0

FOODIE-IR-DS-03

API MeteoGalicia API Planned SHOULD 1.0

FOODIE-IR-DS-04

WRF (Weather Research Forecast) Analytical Planned COULD 1.0

FOODIE-IR-DS-05

Phytosanitary bulletin of Deputation of Pontevedra

Analytical Planned COULD 1.0

FOODIE-IR-DS-06

MOD09GQ data product from Terra satellite

Instruments and sensors Planned SHOULD 1.0

FOODIE-IR-DS-07

MYD09GA data product from Aqua satellite

Instruments and sensors Planned SHOULD 1.0

FOODIE-IR-DS-08

OLI data product from Landsat 8 satel-lite


FOODIE-IR-DS-09

TIR data product from Landsat 8 satel-lite


FOODIE-IR-DS-10

Data products from Sentinel-2 satellite Instruments and sensors Planned COULD 1.0

FOODIE-IR-DS-11

Data products from Sentinel-1 satellite Instruments and sensors Planned COULD 1.0

3.5 List of Use Cases

List of use cases. For a detailed catalogue with all the attributes see Annex A.

Name ID Goal Status Priority Ver-

sion

Register treat-ments

FOODIE-UC-PILOT1.A-01 Register geolocated and temporal data related with treatments ap-plied to the crops

Planned Must have 1.0

Register herbi-cide treatments

FOODIE-UC-PILOT1.A-01.01 Register geolocated and temporal data about herbicide treatments


Register phyto-sanitary treat-ments

FOODIE-UC-PILOT1.A-01.02 Register geolocated and temporal data about phytosanitary treat-ments


Register fertiliz-er treatments

FOODIE-UC-PILOT1.A-01.03 Register geolocated and temporal data about fertilizer treatments





sion

Register prunes FOODIE-UC-PILOT1.A-01.04 Register geolocated and temporal data about prunes


Register obser-vations

FOODIE-UC-PILOT1.A-01.05 Register geolocated and temporal observations about crops

Planned Should have 1.0

Register issues FOODIE-UC-PILOT1.A-01.05.01

Register geolocated and temporal data about issues detected on crops


Register produc-tion

FOODIE-UC-PILOT1.A-02 Register geolocated and temporal data about production


Register irriga-tion

FOODIE-UC-PILOT1.A-03 Register geolocated and temporal data about irrigation


Register the re-sults of analysis

FOODIE-UC-PILOT1.A-04 Register the results of analysis of selected samples from representa-tive parcels


Register leaf analysis

FOODIE-UC-PILOT1.A-04.01 Register the results of leaf analysis of samples from representative parcels


Register soil analysis

FOODIE-UC-PILOT1.A-04.02 Register the results of soil analysis of samples from representative parcels


Register grape juice analysis

FOODIE-UC-PILOT1.A-04.03 Register the results of leaf analysis of grape juice from representative parcels


Register treat-ment plan

FOODIE-UC-PILOT1.A-05 Register the treatments composi-tion that will be applied along the campaign


Validate Man-agement Zones

FOODIE-UC-PILOT1.B-01 Identify Management Zones Planned Must have 1.0

Obtain annual Irrigation and fertilization planning

FOODIE-UC-PILOT1.B-02 Provide annual fertilization compo-sition that will delivered by irriga-tion


Obtain precision recommenda-tions

FOODIE-UC-PILOT1.B-03

Provide recommendations for MZ related to irrigation, fertilization, herbicidal and phytosanitary treatments


Obtain precision recommenda-tions about fer-tilization

FOODIE-UC-PILOT1.B-03.01 Provide recommendations related to fertilization needs


Obtain precision recommenda-tions about her-bicidal treat-ments

FOODIE-UC-PILOT1.B-03.02 Provide recommendations related with the need of apply herbicidal treatments

Planned

Should have

1.0

Obtain precision recommenda-tions about phy-

FOODIE-UC-PILOT1.B-03.03 Provide recommendations related with the need of apply phytosani-tary treatments

Planned

Should have

1.0




sion

tosanitary treatments

Obtain precision recommenda-tions about irri-gation

FOODIE-UC-PILOT1.B-03.04 Provide recommendations related with needs of irrigation

Planned

Should have

1.0

Obtain recom-mendations about harvest-ing

FOODIE-UC-PILOT1.B-04 Provide recommendations related with when and where to start the harvesting

Planned

Must have 1.0

Obtain predic-tion about an-nual production

FOODIE-UC-PILOT1.B-05 Provide recommendations related with the expected production by MZ

Planned

Should have

1.0

Display data from agro-meteorological in-field stations

FOODIE-UC-PILOT1.C-01 Show near real-time measures col-lected by in-field sensors and their localization

Planned

Must have 1.0

Display Vegeta-tion Indices of the crops

FOODIE-UC-PILOT1.C-02 Show contour lines the Vegetation Indices at MZ

Planned

Must have 1.0

Display moisture indices

FOODIE-UC-PILOT1.C-02.01 Show the contour lines for mois-ture indices at MZ

Planned

Should have

1.0

Display vegeta-tion indices

FOODIE-UC-PILOT1.C-02.02 Show the contour lines for vegeta-tion indices at MZ

Planned

Should have

1.0

Display treat-ments applied

FOODIE-UC-PILOT1.C-03 Show the localization of treatments applied to MZ and registered on the system

Planned

Must have 1.0

Display herbi-cide treatments

FOODIE-UC-PILOT1.C-03.01 Show the localization of herbicide treatments applied to MZ

Planned

Must have 1.0

Display phyto-sanitary treat-ments

FOODIE-UC-PILOT1.C-03.02 Show the localization of phytosani-tary treatments applied to MZ

Planned

Must have 1.0

Display fertilizer treatments

FOODIE-UC-PILOT1.C-03.03 Show the localization of fertilizer treatments applied to MZ

Planned

Must have 1.0

Display prunes FOODIE-UC-PILOT1.C-03.04 Show the localization of the prunes Planned

Must have 1.0

Display observa-tions about crops

FOODIE-UC-PILOT1.C-03.05 Show the localization and attached information of the observations annotated at the MZ

Planned

Should have

1.0

Display issues detected

FOODIE-UC-PILOT1.C-03.05.01

Show the localization and attached information of the issues detected at the MZ

Planned

Should have

1.0

Display histori-cal data about production

FOODIE-UC-PILOT1.C-04 Show historical data about produc-tion of each MZ and its representa-tion in the map

Planned

Should have

1.0

Display histori-cal results of

FOODIE-UC-PILOT1.C-05 Show historical data about the analysis of samples for each MZ

Planned

Should have

1.0




sion

analysis of sam-ples

and its representation in the map

Display the re-sults of leaf analysis

FOODIE-UC-PILOT1.C-05.01 Show the results of leaf analysis for each MZ and its representation in the map

Planned

Should have

1.0

Display the re-sults of soil analysis

FOODIE-UC-PILOT1.C-05.02 Show the results of soil analysis for each MZ and its representation in the map

Planned

Should have

1.0

Display the re-sults of grape juice analysis

FOODIE-UC-PILOT1.C-05.03 Show the results of grape juice analysis for each MZ and its repre-sentation in the map

Planned

Should have

1.0

Display treat-ments plan

FOODIE-UC-PILOT1.C-06 Search and show the data regard-ing the treatment plans

Planned

Must have 1.0

3.6 List of Requirements

List of specific requirements of the pilot. For a detailed catalogue with all the attributes see Annex C.

Code Type Short Description/Rationale Status Priority Version

FOODIE-REQ-PILOT1-01-V 1.0

Informational The system will use data from public agro-meteorological stations

Pending SHOULD 1.0


Informational The system will use data from the agro-meteorological station located at Terras Gauda

Pending SHOULD 1.0


Informational

The system will send to FOODIE plat-form the data collected from the agro-meteorological station network deployed in field

Pending MUST 1.0


Informational

The system will send to FOODIE plat-form the data collected from the agro-meteorological station network deployed in the vineyard

Pending MUST 1.0


Informational The system will use data about phyto-sanitary alerts sent by public organ-isms

Pending COULD 1.0


Informational The system will use data about phyto-sanitary bulletin sent by the Deputa-tion of Pontevedra, Spain

Pending COULD 1.0


Informational

The system will use multispectral and thermal information from remote sensing instruments on satellite to calculate vegetation indices georefer-enced

Pending MUST 1.0


Informational The system will use data from Ter-ra/Aqua satellites

Pending MUST 1.0




Informational The system will use data generated from Landsat 8 satellite

Pending MUST 1.0


Informational The system will use data products from MODIS sensor related with sur-face reflectance

Pending MUST 1.0


Informational The system will use multispectral data from OLI instrument

Pending MUST 1.0


Informational The system will use thermal data from TIR instrument

Pending MUST 1.0


Informational The system will use data from numer-ic forecast model WRF (Weather Re-search Forecast)

Pending COULD 1.0


Informational The system will use numeric forecast information served by the API Mete-oGalicia.

Pending COULD 1.0


Informational The system will use numeric forecast information from the MeteoGalicia operational modelling data

Pending COULD 1.0


Informational

The system will use data from weath-er radars in order to get information about rain precipitation and its evolu-tion

Pending COULD 1.0


Informational The system will use data from the weather radar of Xunta Galicia

Pending COULD 1.0


Informational The system will collect data from Sen-tinel 2 satellite

Pending MUST 1.0


Informational

The system will send data to FOODIE platform from the analysis of selected samples of leaf from representative parcels

Pending SHOULD 1.0


Informational

The system will send data to FOODIE platform from the analysis of selected samples of leaf from representative parcels of the vineyard

Pending SHOULD 1.0


Informational

The system will send data to FOODIE platform from the analysis of samples of the agricultural product from rep-resentative parcels

Pending SHOULD 1.0


Informational

The system will send data to FOODIE platform from the analysis of grape juice samples of representative par-cels at the vineyard

Pending SHOULD 1.0


Informational

The system will send to FOODIE plat-form the data from the analysis of se-lected samples of the soil from repre-sentative parcels

Pending SHOULD 1.0




Informational

Every year the system will send to FOODIE platform the data from the analysis of selected samples of the soil from representative parcels

Pending SHOULD 1.0


Informational

The system will send to FOODIE plat-form the vegetation indices from data acquired by spectrophotometer cam-eras mounted on agricultural vehicles

Pending COULD 1.0


Informational The system will collect geolocated da-ta related with treatments applied to the crops

Pending SHOULD 1.0


Informational The system will collect the GPS posi-tion of the vehicles that are applying the treatments to the crops

Pending SHOULD 1.0


Functional The system will calculate vegetation indices from reflectivity data for a ge-ographical zone and period of time

Pending MUST 1.0


Functional The system will calculate the NDVI Normalized Difference Vegetation In-dex

Pending MUST 1.0


Functional The system will calculate the EVI En-hanced Vegetation Index

Pending MUST 1.0


Functional The system will calculate the NDWI Normalized Difference Water Index

Pending MUST 1.0


Functional The system will calculate the NDI7 Normalized Difference Water Index 7

Pending MUST 1.0


Functional The system will calculate the SIWSI Shortwave Infrared Water Stress In-dex

Pending MUST 1.0


Functional The system will calculate the SWIRR index

Pending MUST 1.0


Functional The system will calculate the MSI Moisture Stress Index

Pending MUST 1.0


Functional The system will calculate the GVMI Global Vegetation Moisture Index

Pending MUST 1.0


Functional

The system will calculate the NDVI Normalized Difference Vegetation In-dex from MODIS MYD09GA data product

Pending MUST 1.0


Functional

The system will calculate the NDVI Normalized Difference Vegetation In-dex from MODIS MOD09GD data product

Pending MUST 1.0




Functional The system will calculate the EVI En-hanced Vegetation Index from MODIS MYD09GA data product

Pending MUST 1.0


Functional The system will calculate the NDWI Normalized Difference Water Index from MODIS MYD09GA data product

Pending MUST 1.0


Functional The system will calculate the NDI7 Normalized Difference Water Index 7 from MODIS MYD09GA data product

Pending MUST 1.0


Functional

The system will calculate the SIWSI Shortwave Infrared Water Stress In-dex from MODIS MYD09GA data product

Pending MUST 1.0


Functional The system will calculate the SWIRR index from MODIS MYD09GA data product

Pending MUST 1.0


Functional The system will calculate the MSI Moisture Stress Index from MODIS MYD09GA data product

Pending MUST 1.0


Functional The system will calculate the GVMI Global Vegetation Moisture Index from MODIS MYD09GA data product

Pending MUST 1.0


Functional The system will calculate the SRWI Shortwave Infrared Water Stress In-dex

Pending MUST 1.0


Functional

The system will calculate the SRWI Shortwave Infrared Water Stress In-dex from MODIS MYD09GA data product

Pending MUST 1.0


Functional The system will use a GIS viewer to show georeferenced information at the parcels

Pending MUST 1.0


Functional The system will show the geo-referenced information on separate layers for each type of information

Pending MUST 1.0


Functional The system will show geo-referenced data for a selected date interval

Pending MUST 1.0


Functional The system will show Vegetation Indi-ces of each parcel in a GIS viewer

Pending MUST 1.0


Functional The system will show geo-referenced actions performed on the crops

Pending MUST 1.0


Functional The system will show geo-referenced issues detected by the farmer on the crops

Pending MUST 1.0


Functional The system will show geo-referenced data of the measures taken by the sensors deployed on the field

Pending MUST 1.0




Functional The system will show contour lines for the variables measured by the sensors deployed on the field

Pending MUST 1.0


Functional The system will show contour lines for the Vegetation Indices in a GIS viewer

Pending MUST 1.0


Functional The system will show the estimated percentage of the attack of mildew fungus in a GIS visor

Pending MUST 1.0


Functional The system will show the levels of soil nutrients according to the results of soil analysis

Pending MUST 1.0


Functional The system will show the values of the results of the analysis of grape juice in a GIS viewer

Pending SHOULD 1.0


Functional The system will calculate the percent-age of infection of mildew fungus

Pending MUST 1.0


Functional The system will provide functionali-ties for the registration and visualiza-tion of soil analysis

Pending SHOULD 2.0


Non functional The mobile App must be follow design guidelines in order to improve its usa-bility

Pending SHOULD 1.0


Non functional Enclosure of portable agro-meteorological stations will be rated at least IP-65

Pending MUST 1.0

FOODIE-REQ-PILOT1-64-V1.0 Functional

The system will provide functionalities for searching, registering and display-ing treatment plans.

Pending MUST 1.0


The search for treatment plans will in-clude criteria for campaign, type, name of the product and ID of the treatment plan

Pending SHOULD 1.0


Information for the visualization of a treatment plan

Pending MUST 1.0


The system will provide functionalities for the registration and visualization of agricultural interventions

Pending MUST 1.0


The system will provide functionalities for the registration and visualization of pruning interventions

Pending MUST 1.0


The system will provide functionalities for the registration and visualization of herbicidal treatments

Pending MUST 1.0


The system will provide functionalities for the registration and visualization of phytosanitary treatments

Pending MUST 1.0


The system will provide functionalities for the registration and visualization of fertilizer treatments

Pending MUST 1.0




The system will provide functionalities for the registration and visualization of annotations

Pending SHOULD 1.0


The system will provide functionalities for the registration and visualization of issues

Pending SHOULD 1.0


The system will provide functionalities for the registration and visualization of the yield production

Pending MUST 1.0


The system will provide functionalities for the registration and visualization of irrigation activities

Pending SHOULD 1.0


The system will provide functionalities for the registration and visualization of analysis

Pending SHOULD 1.0


The system will provide functionalities for the registration and visualization of leaf analysis

Pending SHOULD 1.0


The system will provide functionalities for the registration and visualization of grape juice analysis

Pending SHOULD 1.0


The system will show the summary of the yield production

Pending SHOULD 1.0

FOODIE-REQ-PILOT1-81-V1.0

Functional The system will provide precision agri-culture recommendations

Pending SHOULD 1.0


Functional The system will provide PA recom-mendations about fertilization treat-ments

Pending SHOULD 1.0


Functional The system will provide recommenda-tions about herbicidal treatments

Pending SHOULD 1.0


Functional The system will provide PA recom-mendations about irrigation

Pending SHOULD 1.0


Functional The system will provide PA recom-mendations about phytosanitary treatments

Pending SHOULD 1.0


Functional The system will provide PA recom-mendations about harvesting

Pending SHOULD 1.0


Functional The system will provide predictions about the yield production

Pending SHOULD 1.0


Functional The system will provide the annual planning for irrigation and fertilization

Pending SHOULD 1.0


Functional The system will provide a prediction about the delimitation of management zones

Pending SHOULD 1.0


Informational The system will collect data from Sen-tinel 1 satellite

Pending COULD 1.0


Functional The system will provide contextual re-sponsiveness

Pending COULD 1.0



4 Czech Pilot Description

4.1 Introduction

The Czech pilot is focused on improving future management and logistic of agricultural companies (farms) and agriculture service companies, introducing new tools and management methods, which will follow the cost op-timization path, transport reduction, reduction of environmental burden, improving the energy balance while maintaining production level. These tools and methods will be integrated within current Prefarm (modifying sys-tem according additional needs and adding new functionality beyond precision farming). This requires a complex optimization of production (reducing the energy intensity of production, optimizing machinery movements in re-lation with long-term crop rotation optimization, optimizing workflows, etc.) and logistic inside of farm but also among the farm and service organization. Thus, the goal of project is not only to introduce new solution on the farm and advisory level, but also build new business for service organization offering services to the farmers through the cloud and offering them also hardware, necessary for improving farm efficiency.

The purpose of the pilot is creating a complex solution for introducing of optimal management methods, reduc-ing energy consumption in the farm crop production and optimizing farms logistics. This optimization will be based primarily on the analysis of farm processes, analysis of existing data, cost intensity of production of specif-ic crops in specific fields and analysis of movement of agricultural machinery and vehicles, which perform, har-vesting, processing and supply. Verification of knowledge management in the service company and test farms will involve a complex evaluation of efficiency of agricultural production of agricultural enterprise which produc-tion planning and production processes will be integrated into the context of farm’s knowledge management. This will not only allow to precisely control the individual operations on the fields, but also to plan crop rotation and machinery movements. This approach will also support controlling the sustainability of farm production us-ing standardized economic, energy and agro-environmental indicators for the evaluation of its performance.

For the Czech pilot it is very important to establish processes, which will enable obtaining relevant data, focus will be on satellite data and aerial images. If we want to optimize production, general information about costs related to individual crops is insufficient. We need to know the costs of growing the crops on individual fields. For crops which high costs of growing, the costs can increase even more if the crop is grown on field with high dis-tance from the farm.

The Czech Pilot will include three scenarios:

Improving efficiency of transport in agriculture inside of large service organization, which will support better logistic on different levels of agriculture services

Telematics of farm machinery – focus on complete monitoring and assessment and optimization of all operation on farm level

Monitoring of in-field variability for site specific crop management – for the purpose of variable applica-tion but also for the purpose of yield forecast and management of operation on the level of the farm



Figure 11 Czech Pilot Scenarios/Use Cases

4.2 Pilot Scenarios

4.2.1 Scenario A – Improving efficiency of transport in agriculture.

Introduction

In the relation to farms MJM plays role of agriculture service organisation, trade partner and advisory organisa-tion. MJM acts on both sided of market, supply and demand side.

On the market of inputs to agriculture, MJM plays the role of supply side. They supply farms with fertilizers, pes-ticides, and other materials. In some cases MJM only sells these products and delivers them to customers, in other cases they provide complete services including application on fields. In connection with these supplies, MJM must fulfil their legal obligation to take back empty packing. On the market of crop product MJM act as demand side purchasing products from farms.

Transportation is an essential part of all of these relations and it is affecting both economic and energy efficiency of agriculture. Transportation in this use case involves following topics.

Transport of fertilizers and other materials from warehouses of MJM to customer’s warehouses.

Transport of fertilizers and other materials from warehouses of MJM directly to machinery performing application on field

Take-back of empty packing.

Transport of crop products directly from fields to warehouses of MJM.

Transport of crop products from farm’s warehouses to warehouses of MJM.



Organisational structure of MJM involves various department and the mentioned transportation activities are re-lated to several of them. At this moment each of the departments is using the transportation more or less inde-pendently on the other departments however, in some cases they are sharing capacity of vehicles. For the pur-pose of transportation, MJM is using both, owned vehicles and services of external carriers.

The planning of transport is performed by executives of individual departments without support of information system. The executives are obtaining various kinds of requirements and the planning of transport is based mainly on their experience, good knowledge of customers and surroundings.

The main purposes of system for optimization of transport in agriculture, which is going to be implemented in MJM are:

better overview about transport related topics for purposes of MJM management,

efficient information sharing between individual departments and between elements involved in transport processes,

increased economic and energy efficiency of transport.

At this moment, it is possible to recognize several basic features of the system, which are required. Exact func-tionality will be defined in the next steps and continuously modified according to the testing and MJM manage-ment feedback.

Basic features of system

In general optimization means controlling processes, which are under direct control of decision maker with in-tent to archive optimal value of selected criteria and respect all constraints connected with the processes.

Processes under control

In this use case MJM can directly control movement of vehicles. Decision related to vehicles movement consists from several parts.

Choice of vehicles which will be sent to their routes. Vehicles include: o own vehicles, o vehicles of external carriers.

Choice of drivers in case of own vehicles.

Choice of routes including: o one destination or more destination, o time schedule including requirements for loading and unloading cargo.

The system must be able to address all of these parts.

Information and constraint

The transportation plan must respect various constraints. All constraints are related to information available to MJM. As the information are coming with various advance before realisation of transport, it is necessary to con-sider various time horizons of planning.

Long-term - Some information is available to MJM long time before realisation of transport. This allows creating part of transport plan several weeks ahead.

Mid-term Some information is known several days before realization of transport. This information causes adding new items to transport plan or modifying existing items.

Short-term Some information comes few hours or minutes before transport, or even during transport. This situation requires rapid response.



The following table contains examples of various kind of information which can affect transportation plans.

Information Basic description Prevailing time hori-

zons before realisation of transport.

Location of farms/fields

Position of places, where loadings, unloading, or applications on field occurs. As MJM knows their trade partner and cooperates with them repeatedly, this information is mainly long term.

Long-term

Technical specifica-tions of vehicles

Information about speed, capacity, suitability for various kinds of cargo etc.

Long-term

Available number of vehicles

Information about availability of vehicles including own vehicle and ve-hicles from external carriers

Long-term, mid-term

Restrictions related to farms/fields.

In cases of some customers, it is not possible to use some kind of vehi-cles due to various reasons. (for example low gate to the farm)

Long-term

Transport requests Requests to deliver fertilizers, pesticides, etc., to load crop products or to take back packing.

Some requests can be known long time before realisation (e.g. take-back of packing), some several days before realization (e.g. load crop product from warehouse of customer) and some several hours before. (e.g.,. loading product directly on field must be done ASAP in case of ex-pected rain.)

Long-term, Short-term, Mid-term

General schedule of agricultural works.

The most common times of harvests of various crops, fertilizing etc. Long-term

Weather In long term, weather can influence for example general expectation about time of harvest (harvests delayed after long winter). In mid or short term, weather can directly influence schedule of agricultural works and related transport. Some weather conditions may directly ini-tiate transport request sand requires rapid response.

Long-term, mid-term, short term

Information about transport infra-structure

General information about transport network including distances, travel speed for various kind of vehicles, accessibility of individual roads for various vehicles etc.

Long-term

Actual traffic infor-mation

Actual information about closures, accidents, reconstructions. Mid-term, short term

Structure of actual crop production and expected yields

This information can help to estimate expected workload of vehicles during harvest and to make decision about amount of vehicles from ex-ternal transport companies, which is necessary to book in advance.

Long-term, Mid term

This information will be used to create constraints of problem and to specify goal of optimization (objective func-tion). Constraints will be related for example to quantity of cargo, capacity of vehicles, possibility to combine ve-hicles for various types of cargo, travel times, suitability of vehicles for individual tasks and to and transport re-quirement.



Transport requirements will play role of crucial constraint, and ways of handling these constraints will be subject of further analysis. At this moment, it is clear, that each transport requirement will contain at least following items.

Place of loading.

Place of unloading.

Information about kind and quantity of transported cargo.

Requested time of loading/unloading on the field or in warehouse of MJM’s partner. The requested time will be specified by interval, which can be several weeks long in cases of non-urgent transportation (take-back of packings) to several hours in urgent cases (harvest in case of imminent bad weather)

For case of situation, which is not allowing to fully satisfy all time requirements, or where full satisfaction of re-quirements would be economically prohibitive, it will be necessary to set priorities of requirements and specify rules for dealing with these priorities.

The goal of optimization

There are several possible approaches to the goal of optimization. These approaches will be further analysed in cooperation with MJM. As a result of this analysis, it will be decided to choose one of the approaches or involve more of them into system and let the user switch between them according to the current needs. There are sev-eral examples of possible approaches.

Creating transport schedules, which are satisfying all constraints and minimizing transport costs.

Creating schedules, which are minimizing deviation from requested times of loading/unloading (taking in account priorities) and satisfying other constraints. In this case, allowed costs of transport will be ad-ditional constraint defined by system user.

Assigning costs to unsatisfied loading/unloading times and aggregating the costs with transportation costs. Than creating schedule respecting other constraints and minimizing the aggregated costs.

Created schedules based on some of multi-criteria decision methods.

During proof of concept stage, it was considered, that all transport related activities are to complex problem to cover within the scenario A, so MJM selected one topic to cover during project. The selected topic is optimiza-tion of take-back of empty packings.

Name ID Goal

Obtain input data FOODIE-UC-PILOT2.A-01

Obtain all available long-term, mid-term and short-term information related to the transport optimiza-tion

Compute transport schedule FOODIE-UC-PILOT2.A-02 Create optimization models based on the input data, find and analyse optimal solutions

Display results FOODIE-UC-PILOT2.A-03 Display transport schedule including various alterna-tives and accompanying analysis



Figure 12: Czech Pilot Use Cases for Scenario A

4.2.2 Scenario B – Telematics of farm machinery

Introduction

Operation of agricultural machinery significantly influences the economic profitability of crop management. First of all, the fuel consumption, machines and operators workload, control of performed treatments and the envi-ronmental effects such as reducing the risk of deterioration of soil physical properties.

From technical point of view the monitoring system involves tracking of the vehicles position using GPS com-bined with acquisition of information from on-board terminal (CAN-BUS) and their online or offline transfer to GIS environment.

Verification of the monitoring system will be done at medium-sized farm, where it will serve for an evaluation of tractors work during basic operation such as soil tillage, fertilization, sowing and application of pesticides. Similar monitoring will be tested at the enterprise which is offering services for farmers (e.g. MJM Litovel) for assessing the quality of work for customers.



Main purposes and expected benefits:

Evaluation of the economic efficiency of machinery operations within the fields

Precise records of crop management treatments

Management of machinery operations - increasing the efficiency of planning of crop management

Control of requirement for field operations: o control of pass-to-pass errors and overlaps, coverage of maintained area and recommended

work speed o Control of applied input material in comparison to prescribed rates o Compliance of agro-environmental limits (Nitrate Directive, GAEC, protection of water re-

sources, etc.)

Description of telematics system

Based on the level of information processing and their interaction with other farm data, three use cases were de-termined within the Scenario B:

UC1 – tracking the machinery fleet which allows localization of farm vehicles in real time. This infor-mation provide an overview of current operations of machines and is crucial for the planning of field work and an evaluation machines usage in time. Monitoring of machine location using GPS and GSM/GPRS allows calculating working time, downtime and base information from CAN-BUS. The base alarm function could be implemented into the system to alert when machine is leaving of defined area or in case of rapid decrease of the fuel level.

UC2 – an evaluation of economic efficiency of the crop management treatments within the fields. A prerequisite is the identification of fields and tractor equipment for the accurate estimation of field job costs based on the fuel consumption and used and working time. An analysis of tractor passes with in-formation about machine parameters allows evaluating compliance of working widths and operation speed, which are an indicator of the quality of field work. Simultaneously records of performed opera-tions will be used in agronomic registration.

UC 3 – an evaluation of machinery passes on the soil environment. This includes detailed analysis of the tractor trajectories within the fields considering the site specific conditions. The aim is to estimate the negative effect of machine tracks on the soil environment (especially soil compaction) and compli-ance of agro-environmental limits (nitrates directive, GAEC, protection of water resources, etc.). An op-tional extension of this evaluation represents a connection of machinery tracking with the records of applied materials (fertilizers, pesticides) from the board computer to check the accuracy of the applica-tion of agrochemicals.

Name ID Goal

Tracking the machinery fleet FOODIE-UC-PILOT2.B-01 Register geolocated data related with farm machin-ery operations

Evaluation of economic effi-ciency

FOODIE-UC-PILOT2.B-02 Evaluate the costs of crop management treatments

Evaluation of machinery passes on the soil environment


Evaluate the negative effect of machine tracks on the soil environment and compliance of agro-environmental limits



Main features of monitoring system:

Versatility and easy portability to different machines

Tracking using GPS and online data transfer via GPRS

Connection to CAN-BUS/ISO-BUS

Tool for identification of the tractor equipment

Tool for Identification of drivers

Visualization of data in a GIS environment with the implementation of the background data

Aggregation of records by crops, field job, field, machine, driver and time window (day, week, month, vegetation season, year)

Figure 13 Czech Pilot Use Cases for Scenario B



4.2.3 Scenario C – Monitoring of in-field variability for site specific crop management

Introduction

The services provided by MJM for farmers as the support of decision making in crop management are connected with variable rate application of farm inputs and different treatments within the field. For these reasons, infor-mation about the in-field variability of soil and crop stand is required. The use of remote sensing is a key step in obtaining whole-area data for agronomical treatments during the vegetation season.

The aim is to develop a stable monitoring system for effective identification of spatio-temporal variability of crops and use this remote sensed information to optimize the crop management practices. The main areas of crop production are plant nutrition and fertilization, plant protection, assessment of coverage of wide-row crops or estimation/prediction of crop yields.

The system should be versatile enough to cover crop management practices of different crops, which are com-mon in the region (in case of Czech Republic: winter wheat, spring barley, maize, oilseed rape, sugar beet, etc.). Besides, it should be also scalable to implement other mapping methods, such as on-the-go plant sensing, prox-imal soil sensing, soil sampling, yield mapping and other.

Main purposes and expected benefits:

Assessment of the spatio-temporal variability of vegetation crops for whole-area growth modelling

Optimizing crop management practices regarding the crop status (coverage, nutritional status, health status, stress symptoms, amount of biomass). This will lead to followed effects:

o Efficient use of fertilizers according to the plant requirements and nutrient supply conditions o Optimized use of pesticides ( fungicides, herbicides, growth regulators) with respect to current

and predicted properties of crop stand

Integration of environmental limits in observed locality according to the legislative and natural condi-tions

Prediction of crop yield - quantitative and qualitative parameters

Decision support for crop management practices regarding to the crop status

Obtaining feedback after accomplished variable rate treatments

Spatial identification of the economic efficiency of crop management in form of field zones.

For delineation of the fields managed by the farmers, two information sources will be used:

Central geodatabase Land Parcel Identification System (LPIS), which is managed by Czech Ministry of Agriculture. It was created to fulfil the EU request for Integrated Administration and Control System (IACS) for direct payments. Registration of land parcels into this database is mandatory for all farmers applying for any subsidies programs. LPIS geodatabase allows can be accessed in the form of exported shape file or as the Web Feature Service.

Local geodatabase of service providers (MJM) or farmers, which is usually based on the LPIS, but is en-riched by the other farm and agronomist data (crop records, field operations, machinery operations).

Description of monitoring system

The monitoring system for strategic planning includes three types of observation to provide information about crop variability at different spatial and temporal level:

1. Operative aerial remote sensing with high spatial, but low temporal resolution 2. Periodical satellite remote sensing with medium spatial and temporal resolution 3. Agro-meteorological observation with high time frequency of recording in coarse grid



Name ID Goal

Operative aerial remote sens-ing


Mapping of vegetation within the fields at high spa-tial resolution for preparing the prescription maps for variable applications of fertilizers and pesticides

Periodic satellite remote sens-ing

FOODIE-UC-PILOT2.C-02 Identification of spatial variability and capturing the dynamics of vegetation growth

Meteorological monitoring FOODIE-UC-PILOT2.C-03 Register meteorological data for modelling of crop growth and to support decision

1. Operative aerial remote sensing

Description: Aerial remote sensing represents whole-area mapping of vegetation within the fields at high spatial resolution but with low frequency – temporal resolution. The aim is to prepare the prescription maps for variable applications of fertilizers and pesticides, estimated by the spectral measurement of crop parame-ters. The frequency of the survey depends on the crop type, agronomical operations, crop management in-tensity and weather conditions. MJM assumes several flight missions during the growing season, which will cover most important growth stages of field crops.

Technical resources: In the project, the aerial imaging will be carried out by an external provider of photo-grammetric services. Multi-spectral imaging is performed by CIR system Microsoft Ultracam X mounted in the aircraft carrier Piper or Cessna. Spatial resolution is 15 to 50 cm per pixel, according to client requirements. Within the project, a workflow will developed for pre-processing of acquired images (radiometric and geo-metric corrections) and their analysis and classification according to MJM interpretation algorithms.

Scalability: Development of hyperspectral aerial imaging and favourable prices for survey services can be ex-pected in the near future and thus its use also for agricultural applications. The advantage is a more accurate assessment of the spectral properties of the observed objects, which allows identification of more robust vegetation indices (e.g. red edge Inflexion point). Another opportunity is to implement Unmanned Aerial Sys-tems into monitoring. However, the lower quality of data and disability to map large area in short time are limiting their use for providers of agricultural services.

2. Periodic satellite remote sensing

Description: Periodic satellite remote sensing for wide-ranging identification of spatial variability and simul-taneously capturing the dynamics of vegetation growth, both at medium level of spatial resolution (30m per pixel, once per 14 days). Due the high risk of cloudy days and delay of images availability is the use of satellite images as the main information for decision making limited.

Technical resources: Suggested satellite survey is based on the free available data with medium spatial and temporal resolution. At present, the suitable option is choice of Landsat 8, which data are freely available on the webpage USGS Earth Explorer (http://earthexplorer.usgs.gov). Multispectral images with a resolution of 30 m (OLI sensor) and 100 meters per pixel (TIR sensor) are provided in 10 to 14 days interval with approxi-mately two weeks delay. The main information is the vegetation index NDVI determined from R and NIR bands. The absolute values of NDVI, their relative to mean value of the field and change detection will be im-plemented for assessment of crop stands and delineating of management zones.

Scalability: For 2015 European Space Agency is planning to launch Sentinel-2 satellite system. In comparison with Landsat offers Sentinel-2 higher spatial resolution (15 m per pixel) and different spectral bands (red edge band). If it will be possible to have free access, the monitoring system should be extended by tools for down-loading and processing of this data.



3. Meteorological monitoring

Description: Meteorological monitoring at farm level to capture detailed dynamics of weather conditions on the ground. Weather data will be recorded at the specific localities in high frequency (10 – 15 minutes). Main goal is to obtain data for modelling of crop growth and to support decision making by agronomist for plant protection (prediction of the plant pests and diseases infestation), plant nutrition (crop growth and nutrient supply), soil tillage (soil moisture regime) and irrigation (soil moisture).

Technical resources: Meteorological monitoring will be carried out in form of wireless sensor network or by separate meteostations. Main requirement is to measure basic meteorological characteristic such as air tem-perature, air humidity, air pressure, rain precipitation, soil moisture, soil temperature, etc.

Scalability: The hardware configuration of meteostation should be able to add other sensors for specific re-quirements of user. Similar the software environment for data processing and reporting must be versatile to implement different crop growth and infestations models in various environmental conditions.



Figure 14: Czech Pilot Use Cases for Scenario C – Aerial Survey



4.3 Users and Roles

Description of the different actors involved in the use cases and their roles… the contents for this section are to be drawn from use cases description…

4.3.1 System operator

System operator is main person interacting with system for optimization of transport schedule. He is responsible for inserting transport requests, preferences and initiating the optimization. Other responsibility is initiating data requests in case of data, which are not updated regularly and automatically.

4.3.2 Experts

Experts group involve data experts and optimization modeling experts. Especially In first stages of implementa-tion, data experts will cooperate with development team on automation of data obtaining and processing. They will also act as support for system operators. Optimization modeling experts will be responsible for definition of structures of models. Once the models are created, they will be used repeatedly with various input data and preferences. In this stage, optimization modeling experts will also play role of support for system operators. Optimization modeling experts will also be responsible for redesign of models, if new kind of features are re-quired, or if testing shows necessity of modifications.

4.3.3 System for optimization of transport

The system will include web based user interface, modules for data obtaining, data processing, analytical and modeling components and tools for visualization results. The system will interact with system operators and ex-perts. Some tasks will be performed autonomously; other will be initiated by operators or experts.

Figure 15 Czech Pilot Users and Roles

uc Users and Roles (Actors)

System operator Expert

System for

optimization of

transport






FOODIE-IR-DP-01

GPS instruments with GPRS modem on agricultural machinery

Instruments and sen-sors

Planned MUST 1.0

FOODIE-IR-DP-02

CAN-BUS/ISOBUS interface for GPS data-logger

Instruments and sen-sors

Planned SHOULD 1.0

FOODIE-IR-DP-03

Aerial multispectral images catalogue Database Planned MUST 1.0

FOODIE-IR-DP-04

MJM field crop geodatabase Database Planned MUST 1.0

FOODIE-IR-DP-05

Database of crop management treat-ments


FOODIE-IR-DP-06

Meteorological station Instruments and sen-sors

Planned MUST 1.0

FOODIE-IR-DP-07

Meteorological records Database Planned MUST 1.0

FOODIE-IR-DP-08

Satellite imagery repository Database Planned MUST 1.0

FOODIE-IR-DP-09

Database of vehicles used by MJM

and external carriers


FOODIE-IR-DP-10

LOCATIONS of MJM’s trade partners

and other relevant info

Database Planned should 2.0



FOODIE-IR-DS-11

OLI data product from Landsat 8 satellite Instruments and sen-sors

Planned MUST 1.0

FOODIE-IR-DS-12

TIR data product from Landsat 8 satellite Instruments and sen-sors

Planned COULD 1.0

FOODIE-IR-DS-13

Data products from Sentinel-2 satellite Instruments and sen-sors

Planned COULD 1.0

FOODIE-IR-DS-14

Background WMS layers (orthophoto, topographic)

Database Planned SHOULD 1.0

FOODIE-IR-DS-15

Topographic layers (DEM) Database Planned SHOULD 1.0

FOODIE-IR-DS-16

LPIS database of fields and farms Database Planned MUST 1.0

FOODIE-IR-DS-17

Database of crop management treat-ments


FOODIE-IR- Crop and Pest models Database Planned COULD 1.0




DS-18

FOODIE-IR-DS-19

Road network extracted from OSM Database Planned MUST 1.0

FOODIE-IR-DS-20

Real time traffic data Database Planned COULD 1.0

FOODIE-IR-DS-21

Database of fertilizers and other agricul-tural inputs




Name ID Goal Status Priority Version

Obtain input da-ta

FOODIE-UC-PILOT2.A-01

Obtain all available long-term, mid-term and short-term information relat-ed to the transport optimization

Pending Must have 1.0

Compute transport sched-ule


Create optimization models based on the input data, find and analyze optimal solutions


Process data for optimization model

FOODIE-UC-PILOT2.A-02.01

Process input data into structure ac-cepted by optimization modelling tools


Find optimal so-lutions


Compute optimal or suboptimal solu-tions using tools based on exact algo-rithms or heuristics


Compute ac-companying analysis


Compute accompanying analysis com-paring solutions based on different preferences

Planned Should have

1.0

Display results FOODIE-UC-PILOT2.A-03

Display transport schedule including various alternatives and accompanying analysis


Display solutions FOODIE-UC-PILOT2.A-03.01

Display one solution or several solu-tions (based on different preferences) to decision maker


Display accom-panying analysis


Display analysis comparing various as-pects of the solutions

Planned Should have

1.0

Tracking the ma-chinery fleet


Register geolocated data related with farm machinery operations


Collect GPS posi-tion of vehicles, machinery pa-rameters and operational CAN-BUS information

FOODIE-UC-PILOT2.B-01.01

Tracking of the vehicles position using GPS combined with acquisition of in-formation from on-board terminal (CAN-BUS) and their online or offline transfer to geodatabase


Show machinery tracks and treatment pa-rameters in GIS


Display vehicle passes of various crop treatments in GIS viewer





viewer

Evaluation of economic effi-ciency


Evaluate the costs of crop management treatments

Planned Should have

1.0

Identification of field, job, driver and tractor equipment


Identification of fields, field job, tractor equipment and driver

Pending Should have

2.0

Calculate fuel consumption and job time for de-fined field and vehicle


Calculation of machinery costs for de-fined field operation

Pending Should have

2.0

Evaluation of machinery pass-es on the soil en-vironment


Evaluate the negative effect of machine tracks on the soil environment and compliance of agro-environmental lim-its

Planned Should have

1.0

Analyse vehicle movement with-in the fields


Calculation of tractor passes over the field parts

Planned Should have

1.0

Overlay machin-ery passes and zones with agroenvironmen-tal limits


Show field job tracks within the zones of agro-environmental limits (GAEC, ni-trate directive, protection of water re-sources)

Planned Should have

1.0

Operative aerial remote sensing


Mapping of vegetation within the fields at high spatial resolution for preparing the prescription maps for variable ap-plications of fertilizers and pesticides

Planned Should have

2.0

Process aerial multispectral im-ages


Pre-processing of multispectral images and NDVI calculation

Planned Should have

2.0

Identification of management zones


Overlay analysis and delineation of management zones for site-specific treatments based on the crop growth monitoring

Planned Should have

1.0

Display results FOODIE-UC-PILOT2.C-01.03

Show management zones defined by NDVI and requirements for crop treat-ments

Planned Should have

1.0

Periodic satellite remote sensing


Identification of spatial variability and capturing the dynamics of vegetation growth


Download Land-sat imagery into geodatabase


Automatized downloading of Landsat OLI and TIR images into image reposito-ry

Planned Should have

1.0

Compute time differences of Landsat NDVI images


Calculation of NDVI and change detec-tion of images


Show dynamic of FOODIE-UC-PILOT2.C- Display NDVI cumulative and relative Planned Must have 1.0




crop growth 02.03 differences between observation dates

Meteorological monitoring


Register meteorological data for model-ling of crop growth and to support de-cision


Collect weather data from me-teo-station


Capture detailed dynamics of weather phenomena by meteorological moni-toring


Aggregate and visualize mete-orological data


Display recorded values and results of statistical analysis

Planned Should have

1.0

Implement pest and crop growth models


Integrating crop and pest models into decision support system

Planned Could have

1.0





Informational The system will use data about location of fields and warehouses of MJM’s partner

Pending MUST 2.0


Informational The system will use data about road network Planned MUST 1.0


Informational The system will use technical specification of vehi-cles used by MJM

Pending MUST 2.0


Informational The system will use data about quantity of availa-ble vehicles

Pending MUST 2.0


Informational The system will use data about current traffic situ-ation

Planned SHOULD 1.0


Informational The system will use various weather forecasts. Planned SHOULD 1.0


Informational The system will use data about actual structure of agriculture production

Planned SHOULD 1.0


Informational The system will use information about transport requests

Pending MUST 2.0




Informational The system will use preferences of MJM’s decision makers

Planned MUST 1.0


Functional The system will process input data for optimization model

Planned MUST 1.0


Functional The system will compute optimal transport sched-ule and accompanying analysis

Planned MUST 1.0


Functional The system will display solution and analysis Planned MUST 1.0


Informational The system will collect the GPS position of the farm machinery

Pending MUST 1.0


Informational The system will collect the CAN-BUS data from ve-hicles

Pending SHOULD 2.0


Informational The system will collect the ISO-BUS data from ap-plicators

Planned COULD 1.0


Functional The system will show GPS track lines for defined time interval with the descriptive information from CAN-BUS (speed, precision, fuel consumption)

Pending SHOULD 1.0


Functional The system will show background layers in GIS viewer via WMS (ortho, DEM, LPIS, topo)

Planned SHOULD 1.0


Functional The system will calculate usage properties (usage time, speed, fuel consumption) of crop treatment within the selected time interval and field

Planned MUST 1.0


Functional The system will alert when GPS leaves defined ar-ea

Planned SHOULD 1.0


Functional The system will calculate the machinery swath based on the GPS tracking

Planned SHOULD 1.0


Functional The system will calculate the costs of machinery operations based on the fuel consumption and us-age time

Planned SHOULD 1.0


Functional The system will classify field area into the zones with different number of tractor passes

Planned SHOULD 1.0




Informational The system will use multispectral orthophotos from airborne survey

Planned SHOULD 2.0


Functional The system will preprocess aerial images for geo-metric and radiometric correction

Planned SHOULD 1.0


Functional The system will calculate and classify NDVI within the defined fields

Planned MUST 1.0


Functional The system will delineate MZ based on the crop spectral parameters

Planned SHOULD 1.0


Informational The system will use data generated from Landsat 8 satellite

Pending MUST 2.0


Informational The system will use multispectral data from OLI in-strument

Pending MUST 2.0


Informational The system will use thermal data from TIR instru-ment

Planned COULD 1.0


Informational The system will collect data from Sentinel 2 satel-lite

Planned COULD 1.0


Informational

The system will use multispectral and thermal in-formation from remote sensing instruments on satellite in order to calculate vegetation indices georeferenced

Planned MUST 1.0


Functional The system will calculate the NDVI Normalized Dif-ference Vegetation Index

Pending MUST 2.0


Functional The system will calculate NDVI differences be-tween satellite images for change detection

Planned MUST 1.0


Functional The system will use a GIS viewer to show geo-referenced information at the parcels

Planned MUST 1.0


Functional The system will show the geo-referenced infor-mation on separate layers for each type of infor-mation

Planned MUST 1.0




Functional The system will show Vegetation Indices of each parcel in a GIS viewer

Planned MUST 1.0


Functional The system will show geo-referenced actions per-formed on the crops

Planned MUST 1.0


Functional The system will show contour lines for the Vegeta-tion Indices in a GIS viewer

Planned MUST 1.0


Informational The system will send to FOODIE plat-form the data collected from the agro-meteorological station at pilot farm

Planned MUST 1.0


Functional The system will aggregate meteorological data for defined time interval

Planned SHOULD 1.0


Functional The system will show the tabular and graphical re-sults of meteorological monitoring

Planned MUST 1.0


Functional The system will integrate pest and crop models Planned COULD 2.0



5 German Pilot Description

5.1 Introduction

The pilot project “Machine Cooperatives” will take place in Germany together in partnership with the German Machine Cooperatives as well as single farmers and machine producers. Outside of FOODIE it is planned to do similar projects in Austria and Romania. The project itself is defined and described in the following pages.

For non-expert readers we have to describe upfront the Cooperatives themselves: The German BMR e.V. (Bun-desverband der Maschinenringe) represents approx. 193.000 agricultural enterprises (farms), organized in 263 local cooperatives within 12 country-organizations where the farmers are members. Main tasks are representing their interests, public work, information and qualification.

The member organizations (= farmers) support in Germany around 7.760.000 ha agricultural area what repre-sents ca. 49% of the total agro area in Germany. With a staff of total 2.423 people the Machine Cooperatives with their daughter companies make a turnover of approx. 1,1 bn €. In several regions they are important busi-ness factors. The average turnover of one cooperative is ca. € 4 m, per average staff € 440.000,--.

The German Machine Cooperatives have following overall concept: Basic platform and idea is the solidarity be-tween their members. Then the cooperative offer and support business- and social services. The cooperatives support herewith also the rural area in general and support the agricultural enterprises and the agriculture in to-tal.

To compare - the Austrian machine cooperatives manage with 77.000 members (from around 160.000 farmers) more than 50% of the agricultural area in Austria. An important segment beside machine use is also personal leasing as well as the management of organizations like biomass industries etc. In Romania cooperatives are un-der development but the model is strongly supported by central and regional governments that play at the mo-ment an intermediate role; further we have also local IT partners as well as excellent cooperation with local Uni-versities supporting expert models.

The Machine Cooperatives have been established starting from Bavaria in the early Seventies and then Austria in the mid of the seventies of the last century and are more or less country covering Germany and Austria but are growing fast also into other countries throughout Europe as well as also outside of Europe into other continents as the concept to use machines within smallholder farmers – worldwide everywhere available – and allow them also to benefit of new technologies.

The Machine Cooperatives further also have to take into consideration the new services they will have to pro-vide around ICT use that will open new fields of work for them.



5.2 Pilot Scenarios

Figure 16 German Pilot Scenarios Description



5.2.1 Scenario A – Geographical Information System – WinGIS

The goal of this scenario is the development of a digital geography of all farmers, farms and fields in a region (country) including the corresponding database information a structure, plus all infrastructure data needed for further applications like logistics.

Due to an agreement between PROGIS and Microsoft we have access to a web-Map-Service based orthoimage with 30 cm resolution of complete Western Europe (see figure 17). The flights have been done 2011-2013. The images are JRC - certified . With this images we can support any partner in the mentioned countries – see map, also Germany. It will have to be parallel evaluated if there are other ortho- or satellite images in an adequate quality (high resolution) from public or other private sources available and compare them with the MS Bing im-ages also with the target to make governments understand that if they do not build up a WMS service, private will do this (have done it!). If necessary, these further images has to be converted in an applicable file format (ECW or the PROGIS image format PRE) and geo referenced considering the local projection(s).

Figure 17 web-Map-Service based orthoimages accessible to FOODIE

The images in big part of Western Europe are ready, the light green areas are covered in the meantime and we could get a JRC/ISPRA verification about the 30cm ortho-images: Data is compliant according EU standards for LPIS (Land Parcel Information System) and IACS (Integrated Agriculture Control System) - color and CIR ortho-images fit correctly, Tallin, November 2011

Preconditions:

1. Microsoft will provide their high quality 30cm ortho BING images for the related region incl. vector based street maps.

2. Because the Bing Maps embedded Module communicates directly with the MS images servers, there must be a sufficient and stable internet connection (e.g. DSL/UMTS/HSDPA) available; PROGIS will pro-vide a solution that a download of a specific region that is needed to fulfill a specific task can be done if internet access is available and the data can be stored as long as an agreement is valid on a local com-puter – stationary or mobile.

In this pilot project also the vector data have to be built up. These data consist basically of the fields, parcels and the corresponding database attributes like owners, identification data and other descriptive information. This digitalization can be done based on the already integrated images or on the visualization background of the Bing Maps embedded Module. Another way of including vector data (polygons, lines, points) is the use of a mobile and low cost GPS device. In this case the WINTEC WBT-200/300 GPS logger should be used, because a direct in-terface to this device is already implemented in WinGIS.

Workflow of digitalization via GPS:

Configuration of the GPS device (logging mode)

Recording the GPS positions (e.g. corner points of fields)

Downloading these data from the device and import to the WinGIS project



Evaluation and eventually post processing of the recorded/imported data

Adding the corresponding database information the each object (field)

Within the project areas a link to the cadaster data will be established that allows a farmer or the machine ring automatically to order and integrate the farmers (group of farmers) cadaster data into the system.

Additional geo-data: In addition to the basic geography, extended geo-data can be added to the GIS project. These data consists of:

Public street map – available due to BING maps, but other sources will be evaluated

Rural road network – will be established in pilot regions with the help of the Open Street Map technol-ogy, also embedded into BING Maps and linked to WinGIS

Cities

Official cadaster – see above, converters have to be developed for the pilot regions and models for later upgrade for other regions to be setup

Points of interest – in relation to agricultural needs – a model has to be implemented – and data can be made access-able on the FOODIE platform

Additional topographic / infrastructure data – if available as e.g. soil maps, geological maps, meteoro-logical maps etc. should be integrated within the pilot project region and models for further regions to be stored on the FOODIE platform made available.

If this information is available in a standard GIS/CAD file format (e.g. SHP files, DXF files) – the most suppliers have these formats available - then it can be directly integrated to the GIS project via the WinGIS import inter-faces after downloaded from the FOODIE platform. Data suppliers can make their data available on the FOODIE platform.

All the recorded and digitized geo-data including all the attribute information will be combined and converted to a central farm management database stored on the FOODIE platform. The data structure and the interfaces have to be defined and implemented as well as – see later – the business-models and ownership models.

The main task within the project is, that WinGIS that at the moment runs on a local platform only, has to be con-verted to become cloud enabled, that means that in future on a FOODIE platform – or even on another cloud platform - also the GIS system WinGIS can be made available for users against an e.g. daily fee. This needs a sig-nificant update and upgrade of WinGIS to move it into the cloud. After project end WinGIS has to be available in both forms, as cloud enabled GIS system as well as running on a local platform. This is needed as in the mid fu-ture we will have any amount of rural areas on the world where a cloud technology will not be access-able.

With this step – to have WinGIS, but also all other modules used within the pilot project – available on local sys-tems as well as on a cloud and also on mobile devices we will have a huge step done using newest technologies.



Figure 18: German Pilot Scenario A Use Cases

5.2.2 Scenario B – Farm Management System – DokuPlant

The new system on a cloud platform that has to be developed within the FOODIE project has to reflect like the DokuPlant system on a local PC at every time the three important dimensions within the rural area. Those di-mensions are:

Where? Where is the plot?

What? What is growing? What has to be done on the plot?

Where are all the plots with a certain crop?

When? When have they been cultivated? When which action has to be done?

Time management: The entire system is built in a way that also the time dimension has to be displayed dynami-cally. Whereby the user has the chance, at any time, to go back in the history as well as look forward in the fu-ture. This feature will not only display it will also efect the other two dimensions like graphic and attribute in-formation. With one mouse click in the present, past or future the system will display What? Where? and When?.

The time management for the future has to give to the end-user / farmer or in many cases the advisor the chance to better plan and simulate in order to know economic and ecological answer for his enterprise accord-ing the GAP targets of the EU or also regional specific defined ecological targets!.



Display of the time: The time has to be displayed dynamically so it is up to the user if he wants to display one day, three years or one month (zoom into the time management).

Time management and resources: The time management has also a strong impact on the other resource e.g. prices of the crop, price of the gas etc. Which means for example the prices can be filled in from every user and are valid for a certain time (day, week, month, year etc…).

The regional adaption of PROGIS software technology “DokuPlant” is divided three parts:

Ortho images – MS BING maps, JRC certified will be embedded

Expert database – will be within the pilot project updated for Germany on 2015 level

Activity based cultivation models – will be within the pilot project updated on 2015 level

The AGROffice Admin-Version, which is part of DokuPlant – the basic documentation tool, is used for adapting and modifying the expert database of DokuPlant. The system can be used by farmers, group of farmers, farm ad-visory services, machinery cooperatives and other organisations which adapt and modify the whole expert data-base at once and provide it to a number of farmers within regions or countries.

The expert database – will be update as a.m. on 2015 level - includes the following contents

Crops and varieties for crops

Crops will be defined with the following main property: time (from seeding to harvesting), etc.

Resources including prices/times/contents like

Agricultural machines

Seeds

Available fertilizers – organic and inorganic with their most important chemical contents

Permitted plant protectors

Yearly cultivation activities for crops

Production methods

Different production methods give the possibility of building different models for one crop and using them in one simulation file. By using different combinations of production methods, users can define a huge number of new crop models, always using the existing crops.

How many production methods should be introduced?

In total nearly 400 production methods are already implemented for Germany. At least ten production methods that stand for common variations in cultivation (direct seeding, extensive plant protection, intensive fertilisation, etc.) should be introduced new to increase the understanding. Overall following additional data will be made available for the users/farmers/advisors:

Cultivation restrictions

Nutrient values

Public data like postcodes, communes, banks, etc.

Extras like currencies

Activity based cultivation models including their resources

After filled expert data information – see also figure 19 - one can define an unlimited amount of activity based cultivation models. Different Production Methods give the possibility of building different models for one crop and using them in one simulation file. By using different combinations of production methods, the qualified user can define any amount of new crop models, always using the existing crops or using the models defined by ex-perts.



Figure 19 The 4 a.m. Expert Datasets

Machines, fertilizer, pesticides, seeds – can be combined to cultivation methods

Main todos during the pilot project is beside the use of the technology at machine cooperatives and at farm level as step one will be the move of the complete DokuPlant technology in to the cloud that – similar as with WinGIS – all the technology can be used as a locally to be installed technology or used as cloud service technology also in cooperation with the expert model. Further it is planned to enable with the Admin-Version of DokuPlant that al-lows to generate an expert model for a region or country – also the Admin version will be moved into a cloud en-abled version – that a database within the FOODIE platform will be setup that allows different user groups around the world to develop expert models as described above and move them into the cloud that a farmer- or advisor-user can access this platform and will be enabled to link a specific expert model for a country/region to his DokuPlant system.

Further it is also planned within the pilot project to setup a model to certify such a database with the help of high end experts (like international organization (e.g. GFAR = Global Forum of Agricultural Research, a UN organiza-tion with whom PROGIS is cooperating) or local Universities and to work out a business model that supports this concept.

Further DokuPlant will be upgraded with a contract module that will also be developed within the pilot project and links to the logistic system. It means with a few clicks a farmer can send a contract from DokuPlant to the lo-gistic system of the machine cooperative (or any other service oriented group – and they can move the contract further to a specific farmer/machine that has installed mobGIS. Contract sending will be implemented on a cloud platform too.

The contract module as well as the expert models must be developed in a manner that both can be used also from other FMIS (Farm Management Information Systems) based on a defined interface.

Weatherforecast:

Due to recent developments at PROGIS we will integrate beside the use of a PESSL weather station within the next 6 months UBIMET´s worldwide meteorological data forecast model. This is based on a global network of 29.000 weatherstations and several satellite data, combined towards VERA (= Vienna Enhanced Resolution Anal-ysis – a method combining several types of data. Beside the standard 22 x 22 km grid, we also can provide then within DokuPlant or any other application a global 9 x 9 km grid as well as a 100 x 100 m grid taking into consid-eration also the heights resp. topography. Besides ordinary weather forecast – severe weather warnings can be



sent via SMS - we plan to collect historical data in form of big data to be able in future also to do together with local agro-phytopatological experts a phytosanitary forecast model for spraying of pesticides. As far as possible we plan to showcase this integration also at the German Pilot during the second part of the project duration.

Location based circular flow model for feed – manure – soil – LB-FMS:

Further we also plant to integrate within the German Pilot in the second part of the duration our totally new “lo-cation based circular flow management system” and educate partners within the training phase to understand in detailed based on NIRS (Near Infrared Analysis) data supported by standard chemical analysis the chemical nu-trient contents of feed (too much feed is only to much manure without too much N and a wrong chemical pro-cess that stinks) as well as of manure itself (an optimized manure contains an optimized pH to be continuously measured by a new sensor) as well as integrate soil analysis to take all three of them for a precision farming model. One element alone is too less, we need in future to understand the whole process from feed via manure to soil and back embedding also the quality of products.

Figure 20 German Pilot Scenario B Use Cases



Figure 21 DokuPlant snapshot

DokuPlant that within the FOODIE project will be cloud enabled and implemented on the FOODIE platform con-sists of 4 elements: geography, database, time-related activity management and expert model. The expert mod-el can be an agricultural one as part of this project but might be also a forest-, environmental- or ecological-expert model.

5.2.3 Scenario C – Logistics Platform

Support farm management and/or advisory management, further logistics for the industry and precision farming tasks.

These general targets of the Machine Cooperatives are embedded into 5 further targets:

1. Minimize the costs of production: E.g. one farmer owns a machine and he is able to support many others

with this machine; the cooperative does know, who has a machine and who needs a service with this

machine and is organizing this. This is done with PROGIS logistic tools (Logistic central unit, mobGIS). Tar-

get within FOODIE project is, to move this technology into the cloud that a cloud enabled central unit is

organizing the transfer of the contracts to and from DokuPlant to machines and after fulfilled contract

back to DokuPlant.

2. Opening additional income inside and outside of agriculture: For example the Cooperative is organizing

to clean in winter 1000 rail-way-stations from snow as well as farmers are managing the same for many

parking places of food companies. The farmer gets an additional income and is using his machine more

hours per year as one of the biggest problems in agriculture is the underuse of the machines – e.g. a

good tractor could manage 500 ha and the average farmer in Austria or Germany is around 25 -30 ha (the

biggest avg. in UK with 90 ha and the smallest in Greece with less than 5 ha). These numbers show one of

the big problems in agriculture! Also these additional services delivered by farmers are managed in many

cases by PROGIS logistic tools. A cloud enabled technology in connection with the FOODIE platform will

enable new possibilities.

3. To optimize working conditions is a general target to work with machine producers to optimize their

tools; we will negotiate with 2 to discuss change of their terminals to PC-terminals enabling the integra-

tion of logistic and precision farming.



4. Optimizing of management, support and optimization, stabilize of enterprises and advise and interven-

tion of services within their members. This is done as a permanent education process on one side as well

as on the other hand also advise services are done.

Figure 22 German Pilot Logistics Platform

5. New services for machine cooperatives are:

Help to manage the farm in a worst-case scenario (illness etc.)

The farmer as service provider

- Also outside of agriculture

Intervention of machine services

- Also outside of agriculture, see above

ICT

- Advise better with the help of ICT tools

Networking with the support of ICT

toolshttp://www.maschinenringe.org/content/maschinenring-magazin

Such a NEW INCLUSIVE ADVISORY SYSTEM will have following tasks & steps to be undertaken and sup-ported with ICT:

(Re-)define and structure the existing private support and advisory processes

Objectives: To define in close cooperation also with the public side (Ministry of Agriculture in one of the German Bundesländer, probably Baden-Württemberg) the processes, which technol-ogy should be implemented and how as well as what are the on top tasks of private advisory services and how are the interfaces between public and private advisory services to avoid con-flicts and double work using one integrative ICT system based on PROGIS technologies, existing ICT structures within the Ministries and other needed 3

rd party technologies should be integrat-

ed. In detail it has to be evaluated the public advisory processes, technology integration, the pri-vate advisory processes and the technology integration, the organizational and integration tasks. Following papers have to be developed:

- public and private process description

http://www.maschinenringe.org/content/maschinenring-magazin



- Public and private technology integration

- Organization and integration

Change existing solutions to fit into new needs, to integrated them and make available on

FOODIE platform

Objectives: In close cooperation with the MR the existing ICT solutions WinGIS, DokuPlant and Logistics have to be (re-)defined and prepared for implementation and better integration of the modules GIS – FMIS and Logistics has to be realized. Further they will be implemented locally and on the FOODIE platform together with existing and new datasets in the project country. To be prepared have also:

- A training and education model for MR members

- A TTT (Train The Trainer) model for the cooperative staff

- A model to upgrade sustainable the expert data for pilot regions (machines, fertilizer,

pesticides, crops, methods) with local partners (Institutes, University) and to

- Evaluate the possibility to implement a locally subsidy module as part of DokuPlant to

avoid overlapping as they are available today and define the technological needs

- PROGIS will during the project duration convince users to use them with getting access

to it cost free against a documentation of the use

Technology implementation at customer sites and at the end do a customer evaluation report

Last but not least the processes have to be implemented and the outcomes critical evaluated

under the aspect of a New Inclusive Advisory Model (NIAS) as well as fine-tuning needs have to

be described.

In detail a description has to be delivered of the TTT modules, the expert data, other data linked

to WinGIS incl. IACS, LPIS and subsidy data and the advice for nutrient balance and a process im-

plementation and evaluation report.

On the farm level on farmer´s fields, nutrient balance and business calculations have to be shown as well as the data transfer from the farm management tool to a trust centre (FOODIE platform). A description will be worked out how such a platform has to be setup that enables a third party on demand easily to develop such a trust centre.

On top several showcases have to be installed and shown for logistics and precision farming. Lo-gistic should be implemented on three sites, precision farming showcases also on three sites to-gether with a machine producer as well as one sample of an newly defined and evaluated envi-ronmental model fine-tuned by local experts has to be demonstrated, probably a water optimi-zation model.

Stakeholder integration and data transfer from farmer/advisor to the FOODIE platform:

An important task will be the stakeholder integration (beside MR and farmers). There have to be evaluated with-in the selected regions stakeholders and integrated into the processes to optimize not only farmers but also stakeholder´s processes. Together with the stakeholders discussions should be held to workout business models to guarantee a sustainable model for later countrywide implementation.

Potential stakeholders will be

farmers (smallholders and larger farms),

the food/feed industry and suppliers (fertilizer, seeds, ..) industry also for logistics incl. transport,

further agro-banks and agro-insurance if available and

naturally the cooperatives with all their tasks; further stakeholders are

control- and certification units as well as

R&D units incl. top down info distribution of information/data on one side and the bottom up feedback to R&D.



Documented have to be the models and the implementation reports for farmer´s overall processes supported by ICT and further reports for buyers/suppliers of ICT supported processes, reports regarding banks and insurance companies, the cooperatives themselves and the control-/certification-units and R&D.

The understanding of the stakeholder´s integration needs will reflect to the development of the overall system also on the cloud platform to enable a later integration of stakeholders for a traceability or trust centre concept.

Information flow, trust centre and business model: In close cooperation with WP2 the information flow (bot-

tom up collection) to and from the FOODIE platform has to be described. It has to be defined in detail the in-

formation that has to be collected within the processes and transferred to the FOODIE platform, which pub-

lic and private partners could use the data/information later if made available by the data owners and work

out models based on the concept of ownership of information that can be at the final end implemented with-

in a Trust Centre and retrieved according rules by partners.

In detail it has also to be described the Trust Centre – definition and general rules, the data transfer incl. rules the data transfer to banks and insurance companies, the transfer/neutral exchange to farmers and coopera-tives, the data transfer to buyers, suppliers, the transport sector as well as to the certification and control units and to and from the R&D. Further the business model for the trust centre has also to be negotiated with the selected partners.

E I P – European Innovation partnership: To enlarge the project there should be started negotiations with the

Ministries of Agriculture in Germany and Austria and Romania how far within the EIP (European Innovation

Platform) set up also for agriculture and starting with the negotiations in 2014 and the project start at the

earliest from 2015-2016 on, that means exactly in streamline with the FOODIE pilot projects, the FOODIE pilot

project can be:

either enlarged within a EIP project

or even used to setup with the FOODIE partners or also outside of this community FOODIE related

projects in other countries under this EIP program2

This point might be an important step in regard to sustainability of the project as:

The project will be disseminated beside the project countries also outside of the mentioned countries

The project will be time-wise enlarged to a period after the FOODIE project is closed

2 Details about EIP can be found on http://ec.europa.eu/agriculture/cap-post-2013/legal-proposals/com627/627_en.pdf and will be discussed at the next partner meeting in Naples/Italy.



Figure 23 German Pilot Scenario C Use Cases

It needs an intensive discussion with the FOODIE partners and preparation of the partners regarding their lo-cal EIP model due to negotiations with local Ministries to allow the Know How developed within FOODIE to use also in other projects with the FOODIE partners.

Similar as with the a.m. mentioned two tasks – WinGIS and DokuPlant implementation – the main task within the pilot project will be to move the complete Logistic tools on the cloud platform to enable the users to use either a local version or a cloud enabled version of the logistic tools for a use of a SaaS.

With the help of the machine cooperatives, these technologies will be made available for several coopera-tives and also for farmers that will be additionally be enabled to link their DokuPlant system with a contract module that will be developed within the pilot project to the logistic system – see also there - what means with a few clicks a farmer can send a contract to the logistic system of the machine cooperative - or any other service oriented group – and they can move the contract further to a specific farmer/machine that has in-stalled mobGIS.

When the contract will be enlarged with a map, a contract can be sent with a field map as add-on – whoever did the map (service provider, farmer himself, based on several input parameters like soil investigation, satel-lite chlorophyll maps, soil maps, know-how of the crop of last year and the next year´s crop, a harvest result map from the last year(s) etc. – directly via the logistic tool and the mobGIS to a (1) terminal of a sprayer or fertilizer machine on the tractor in the case of a new tractor or (2) on a smartphone that tells based on the know-how of the coordinates where the tractor is (location, coordinate) and the know-how what needs to be done on a specific area of the map.

With two machine providers and terminal producers we will demonstrate this possibility during the pilot pro-ject and workout and describe a business model how with the use of these technologies, partners can link their terminals – without or with our help - to the system as well as also how service providers that want to setup services for precision farming can use the overall technologies and data within FOODIE from WinGIS via DokuPlant to Logistics and mobGIS, contracting and map communication for their and the farmers benefit.

Beside the communication of a map-based contract to the machine it will also be implemented the return of the done activity to DokuPlant incl., if done with a service provider and not from the farmer himself, the bill-ing and archiving for later use. It has to be evaluated how a FOODIE platform can manage these tasks too.



5.3 Users and Roles

5.3.1 Experts

Before DokuPlant can be used by farmers or advisors, experts have with the Admin version to setup the local ex-pert data. They are grouped as follows:

Machines: We use at the moment the machine data from 2.500 agricultural machines, supported and sustainable managed by the German organization KTBL (Kuratorium für Bau und Technik in der Land-wirtschaft). These data (machine type, costs to buy, costs per hour, effort per hour etc.) are embedded into DokuPlant and users can also directly from DokuPlant link into their database to check all data or to modify them. In a new country we are on the way to sign an agreement with KTBL under which rules experts in other countries can use their dataset as well as enlarge and/or change it to make it fit to the specific country as prices, costs of diesel etc. will be slightly different country by country; also new ma-chines have to be entered.

Organic and inorganic fertilizer: Beside the machines PROGIS worked in a large 2 year project together with KTBL a database of organic and inorganic fertilizer and their chemical contents. Despite the inor-ganic was easy to be defined, we also did hundreds of organic rests of the fields – e.g. after sugar beet harvesting the leaves stay on the field and give an organic fertilizer – which chemical contents of N, P, K, Ca, Mg, these 5 contents are part of the database. In total around 2.500 fertilizers are part of the data-base. With an Admin version local experts get access to these data and can enlarge and/or modify them according local needs.

Pesticides: The database contains 850 on the market registered and registered pesticides, their chemi-cal active substances, the most important use rules etc. With a DokuPlant Admin version local experts get access to these data and can enlarge and/or modify them according local needs.

Seeds and varieties: According the existing datasets of seeds and their varieties the data for Germany are available and can the experts enlarge and/or modify them with the Admin version to create a spe-cific version for the target country.

Crops and methods database: Out of these four basic database structures – machines, fertilizer, pesti-cides, seeds and varieties - the experts are now able to develop for specific crops specific methods, maybe also more than one, e.g. standard and organic etc., and define the use over the time, e.g. step 1 take a tractor and a plough on a specific data and manage a field (GIS) with a specific size and calculate the costs of the machines, the time to be used, maybe the diesel use on the field etc. Then the next and over-next step till harvesting or processes after harvesting are described in a similar manner. The exist-ing German database contains already 400 crops with their proposed methods. The Admin version of DokuPlant is able to manage these processes in a user friendly manner that also symbols for activities can be developed, a timeline is generated where the activities are shown etc.

GIS experts are responsible for geo-data preparation: Creation of maps based on external data sources like LPIS data, cadaster data, soil maps, integration of ortho- or satellite-images via Web Maps Services (WMS) and database preparation for further use in the farm management software and logistic plat-form.

It has to be evaluated how FOODIE platform can be THE platform where internationally experts can use the technologies and define their local expert models and upload them onto the FOODIE platform. Be-side the technological implementation also a business model has to be worked out.

5.3.2 Farmers and Advisors

When these databases are ready and the specific methods for crops are accepted by the farmer or advisor, the planning process is reduced to a single click or drag and drop – where (on which field on the GIS) to grow what (specific crop). With these planning drag and drop all data for a specific field are base of the possible output cal-culation later done, if cost – calculation or nutrient balance or – we are working on a carbon balance too at the moment but outside of FOODIE. The data can naturally also be aggregated, e.g.: all fields of a farmer, the wheat fields of a farm, all wheat fields of all farmers at an advisors system with comparison – anonym – of different farms etc. This gives a powerful planning tool where during the working period over the year the farmer can en-ter the done activities and we compare the delta between plan and done. The done activities can be entered via



keyboard or also interfaces are foreseen for input via precision farming terminals. Within an advisory model the farmer just puts activities done on a paper and the advisor enters them later all at once and can also do the out-put for the farmers.

The difference between farmers- and advisors-systems is only that the farmer can manage one farm only (if the farmer has two farms he can manage also two farms, or three etc.) and an advisor can – defined by the system and also by practical limits how many farmers one advisor can manage – e.g. manage 250 farmers or 500 farm-ers on one system; also a combination is possible that a farmers has the DokuPlant system as he is capable to do the job himself and can transfer all the data with one click to the advisors system. The advisory system is called DokuPlant Mandant.

Aggregation of advisors: Via a database hosted by a large system, many advisors can send their datasets to a central server – FOODIE platform integration has to be evaluated - where the data can be aggregated over a re-gion or a country.

General remarks

FOODIE plan: The plan within FOODIE is to offer all these services online and offline whereby the expert data – many experts worldwide can build up these datasets – will be stored on the FOODIE platform and are access-able against a fee or free of charge – a business-model for experts must be embedded and the data must be stored according countries linked with a GIS system to allow users to select the database they would like to use, e.g. a user in Austria could also use the database of Germany when he accepts the rules defined.

5.3.3. Tractor or other drivers:

Are WinGIS and DokuPlant technologies that will be used by expert users like service providers or by advisors or farmers, we have also to see that we have user groups like drivers of machines and have to guide them into the easy use of technologies implemented with mobGIS but also make them in an easy to use manner cloud enabled. The existing user Interface will be with the help of a to be developed questionnaire investigated again with the help of driver-users as we see them as the most important decision group for a successful use of a group of tech-nologies as needed within the agri-food-chain.






FOODIE-IR-DP-01 Expert data – machines Analytical Planned MUST 1.0

FOODIE-IR-DP-02 Expert data – fertilizer Analytical Planned MUST 1.0

FOODIE-IR-DP-03 Expert data – pesticides Analytical Planned MUST 1.0

FOODIE-IR-DP-04 Expert data – seeds Analytical Planned MUST 1.0

FOODIE-IR-DP-05 Expert data - methods Analytical Planned MUST 1.0



FOODIE-IR-DS-01 Ortho photos from official German data providers via WMS

Raster data Planned SHOULD 1.0

FOODIE-IR-DS-02 Public cadaster data Vector data Planned COULD 1.0

FOODIE-IR-DS-03 Public LPIS data Vector data Planned MUST 1.0

FOODIE-IR-DS-08 Telemetry data from PESSL weather stations

Instruments and sensors

Planned SHOULD 1.0

FOODIE-IR-DS-09 Soil maps from official data provid-ers

Analytical Planned SHOULD 1.0

FOODIE-IR-DS-10 Microsoft Bing Maps ortho photos Raster data Planned SHOULD 1.0

FOODIE-IR-DS-11 GPS data from WINTEC WBT 200/300

Instruments and sensors

Planned MUST 1.0




Customization of user interfaces


Regional adoptions of user interfaces of the geographical information system, e.g. translations of language files

Planned Should have

1.0

Ortho image specifications


Decision for ortho image quality, age, reso-lution, color/IR, certification

Planned Must have

1.0



Selection of ortho image provider


Decision for the ortho image provider (online or offline) depending on specifica-tions

Planned Must have

1.0

Cadastre data availability and precision


Analysis of cadastre data availability and quality

Planned Must have

1.0

Integration of ca-dastre data


Selection of cadastre data format, coordi-nate system (projection), data format

Planned Should have

1.0

LPIS data availa-bility


Selection of LPIS data provider depending on quality (field polygons or block of fields)

Planned Must have

1.0

Additional data availability


Decision for geological, soil, hydrological maps and data formats

Planned Should have

1.0

Farm maps FOODIE-UC-PILOT3.A-06

Map of farm holding with ownership (ca-dastre) and LPIS (field) data on ortho image

Planned Must have

1.0

Advisory model FOODIE-UC-PILOT3.A-06.01

Summary of groups of farms Planned Must have

1.0

Countrywide model


Summary of all advisor (and farmer) data Planned Must have

1.0

Customization of user interfaces


Regional adoptions of user interfaces of the farm management software, e.g. transla-tions of language files

Planned Should have

1.0

Expert data as background in-formation


Building up or updating database for ma-chinery, organic fertilizer, inorganic fertiliz-er, pesticides, seeds and varieties (all incl. costs), methods for all crops and variants with selected machines, fertilizers and pes-ticides used, all needed time information (when to do what and where)

Planned Must have

1.0

Planning FOODIE-UC-PILOT3.B-03

LPIS data filled with crop (where to grow what) from expert data put on a location (field polygon) – with this step all activities incl. values are predefined acc. expert models repeat on other polygons (fields) and change/delete (validity/modify: attrib-utes, property, types, restrictions, mixed LPIS data filled with crop (where to grow what) from expert data put on a location (field polygon) – with this step all activities incl. values are predefined acc. expert models repeat on other polygons (fields) and change/delete (validity/modify: attrib-utes, property, types, restrictions, mixed crops, sludge fertilization)crops, sludge fer-tilization)

Planned Must have

1.0

Realisation FOODIE-UC-PILOT3.B-04

Detailed documentation of activities Planned Must have

1.0

Data entry FODDIE-UC-PILOT3.B-04.01

Data entry manually by farmer / advisor or data entry from machinery

Planned Must have

1.0

Print maps FODDIE-UC-PILOT3.B-05

Printing out crop maps and/or ownership and LPIS maps

Planned Should have

1.0

Cost calculation based on expert

FODDIE-UC-Calculation of costs per field, per farm and Planned Should 1.0



data PILOT3.B-06 per crop have

Nutrient balance based on expert data

FODDIE-UC-PILOT3.B-07

Calculation per field, per farm and per crop Planned Should have

1.0

Documentation of all activities per field

FODDIE-UC-PILOT3.B-08

Internal documentation and also for trace-ability uses with single activity transfer to FOODIE traceability module

Planned Should have

1.0

Journal FODDIE-UC-PILOT3.B-09

Journal data for a single plot, grouped or all plots

Planned Should have

1.0

Statistics FOODIE-UC-PILOT3.B-10

Statistical output over selected crops (fields, crops, plots, varieties)

Planned Should have

1.0

Subsidy tool FOODIE-UC-PILOT3.B-11

Development by the local subsidy tool de-veloper, definition of data interface and in-tegration of the module into farm man-agement software

Planned Should have

1.0

Admin module FOODIE-UC-PILOT3.B-12

Tool to create and edit all expert models Planned Must have

1.0

Mandant module FOODIE-UC-PILOT3.B-13

Allows for advisors to manage more than one farmer on one PC and summarize the data, compare them anonymous and trans-fer them to a higher level aggregation

Planned Must have

1.0

Contract to lo-gistic server


On which field what has to be done when and by whom is sent as a contract to a lo-gistics server and after fulfilment sent back and stored at the field level for later ana-lyse.

Planned Must have

1.0

Weather forecast interface


To showcase the new worldwide working weather forecast based on the new VERA (Vienna Enhanced Resolution Analysis) model integrated in DokuPlant.

Planned Should have

1.0

Location based circular flow management


Together with lab-partners and a new de-veloped NIRS model that integrates feed –manure and soil investigation a location based circular model can be shown and will guide to an integrated Precision Farming integrating feed, manure and soil chemical content to support a circular flow man-agement as the nature does it.

Planned Should have

1.0

Logistic server FOODIE-UC-PILOT3.C-01

Setting up logistic server environment Planned Must have

1.0

Contract from farm manage-ment software


Receiving a contract dataset from the farm management software and stores it in a central database

Planned Must have

1.0

Transmission of contract to mo-bile units


The advisor/cooperative defines the used contractor and sends the contract to the mobile logistic unit

Planned Must have

1.0

Acknowledge-ment of contract


Receives the acknowledgement of the con-tract from a mobile unit and gets on a geo-based server permanent online status in-formation of his contracts/jobs, gets after fulfilment the finalization acknowledge-ment of the contract /jobs

Planned Must have

1.0







Informational The system will use public raster data (ortho / satel-lite images)

Pending MUST 1.0


Informational The system will use public cadaster data in standard GIS formats (DXF, SHP, KML)

Pending COULD 1.0


Informational The system will use public LPIS data in standard GIS formats (DXF, SHP, KML)

Pending MUST 1.0


Informational The system get regional agricultural expert data (machines, fertilizer, pesticides, seeds and methods) from FOODIE platform

Pending MUST 1.0


Informational The system will use weather station and sensor data from PESSL weather stations

Pending COULD 1.0


Informational The system will use geological data (soil maps) Pending COULD 1.0


Informational The system will use online ortho or satellite images from Bing Maps

Pending COULD 1.0


Informational The system will use data from various GPS devices Pending MUST 1.0


Informational The system will send data to FOODIE platform from the analysis of documentation in the farm man-agement software

Pending SHOULD 1.0

Billing system FOODIE-UC-PILOT3.C-01.03

Development and integration of a billing system according local requirements

Planned Should have

1.0

Module logistic units


Installation of mobile logistic software on vehicles

Planned Must have

1.0

Contracts from logistic server


Receives contracts from logistic server and starts the contract on demand or when en-tering the contracted field polygon

Planned Must have

1.0

Protocols FOODIE-UC-PILOT3.C-02.02

Recording all activities and sends them for further processing and visualization to the logistic server

Planned Must have

1.0

Contract trans-mission


Closes the contract after finalization and sends the acknowledgement via logistic server back to farm management software

Planned Must have

1.0

Bill transmission FOODIE-UC-PILOT3.C-02.04

According local requirements the bill will be setup and transferred as well

Planned Should have

1.0

Contract finaliza-tion


Closes the contract on all systems and stores it in the farm management software for later use

Planned Must have

1.0




Informational The system will send data to FOODIE platform from the analysis of documentation in the mobile and central logistic software

Pending SHOULD 1.0


Informational The system will send contract data from farm man-agement software to logistic platform

Pending MUST 1.0


Informational The system will receive contract acknowledgement data from logistic platform in the farm management software

Pending MUST 1.0


Informational The system will receive billing information from lo-gistic platform in the farm management software

Pending SHOULD 1.0


Functional The GIS system will visualize farm (holding) maps based on ortho image and LPIS data

Pending MUST 1.0


Functional The GIS system will visualize additional vector data (e.g. cadaster) on farm maps

Pending SHOULD 1.0


Functional The GIS system will visualize geo based logging data from logistic system

Pending COULD 1.0


Functional The logistic system will collect the GPS positions of the machines that are applying the activities to the crops

Pending SHOULD 1.0


Functional The farm management software will collect crop and activity data for further documentation

Pending MUST 1.0


Functional

The farm management software will collect sensor data from PESSL weather stations for activity plan-ning and will implement an interface weather fore-cast data from UBIMET

Pending COULD 1.0


Functional The system will use time management component in the farm management software

Pending MUST 1.0


Functional The system will integrate the GIS component in all farm management and logistic modules

Pending MUST 1.0


Functional The system will send regional agricultural expert da-ta (machines, fertilizer, pesticides, seeds and meth-ods) edited by local experts to FOODIE platform

Pending MUST 1.0


Functional Analysis of location based circular flow manage-ment sensor data.

Pending SHOULD 1.0



6 Other end-Users’ requirements

The following section describes additional requirements collected from end-users not involved in the three main pilots proposed in FOODIE project.

6.1 Consorzio B.I.M. Piave Belluno

The area of intervention

The reference area of the pilot project is the province of Belluno. The area, fully fitted, is located in the north -east of Italy and includes 60% of the Dolomites a UNESCO heritage site.

The agricultural sector in the province of Bellun

In agriculture there are 1,985 active local units, with an average of 31.1 firms per municipality. The largest num-ber of units, in relation to land surface, is present mainly in Valbelluna (the southern area), due to the best oper-ating conditions for agricultural activity and the rather small size of the municipalities. At higher altitudes the number of local units tends to fall. The UAA (Utilized Agricultural Area) of the province is 282,948 hectares and the area cultivated by farmers is 52,893 hectares accounting for 18.7 % of the total which means that businesses use less than one-fifth of the available surface area. The total gross agricultural production from 2000 (the most recent data available) was € 85.115 million. About €16 million came from herbaceous crops, with a prevalence of forage crops (€ 9 million) and cereals (€ 4 million). The production of livestock products was €47.585 million, mainly derived from beef cattle; Related Services contributed € 11 million and forest products with €8.588 mil-lion.

Agricultural activity in Belluno results as secondary compared to livestock farming and forestry. Bean production in Lamon, with PGI trademark, deserves a note of importance as well as dairy production. Both, though facing increasing difficulties, are liable to increase. It is worth noting that the use of forests and pastures could be im-proved and become a good resource, especially in the production of fuels that are already showing signs of re-covery and in the production of beef, sheep and goats in the livestock industry. However the current growth margins do not appear properly used by Belluno enterprises. Another interesting area is the prospect of growth in the production of small fruits and herbal products, although for now these appear to be niche products with a limited possibility of increase.

Moreover, the province of Belluno has regional primacy of both the surface of the woods and gross forest pro-duction. However, a large part of these forested areas is not of high quality as it grew naturally on abandoned pastures, or is difficult to cultivate at an acceptable cost. The number of local units engaged in forestry activities is 211.

Collateral aspects of agriculture in the mountains

Agriculture in mountain areas is not only productive but has reproductive functions and conserves natural bal-ances. It holds a priority position with respect to maintenance and prevention of environmental risks, as well as in the works of restoration and conservation of the alpine landscape and rural areas in general. To apply purely economic criteria to it and not to assess the environmental and social value of agricultural activities would be an error of perspective that, when programming and planning, could lead to adverse effects. Farms are also rural properties whose architectural features are significant in town-planning.

It appears relevant to promote the multi-functionality of businesses and farms in order to supplement the in-come of entrepreneurs and farmers while connecting their business to tourism, markets and local supermarkets, nursery production, maintenance of gardens, urban and rural green areas and the recycling of organic waste for the purposes of quality agricultural fertilizer.

Parameters for the knowledge of the land in agricultural mountain

MORPHOLOGY: steepness, anthropogenic modelling, exposure, soil science, hydrology of surface and ground waters, wooded or bushy areas.

CLIMATOLOGY: trends in temperature, rainfall, ventilation, radiation, presence of specific microclimatic



factors.

INFRASTRUCTURE: roads and their classification, food and water for irrigation, mains electricity, tele-phone and internet coverage, weather detection devices.

REGULATIONS: the presence of hydrogeological constraints, SCI and SPA zones, landscape protection, planning for agricultural areas, specific sector plans.

TRADITIONAL VOCATION: historical registers, mapping, photographic documentation, yearbooks, agri-cultural and forestry products.

Possible information layers:

Managing of slopes in entire municipality

Management of mowing fields for mountain areas

Definition of river areas for flooding of cultivation lands

Damage to agriculture resulting from the presence wildlife (e.g. deer, wild boars, etc.).

Managing pastures and mountain hut allotment

Chemical composition of soils

Managing spreading organic manure (modality, types, quantity, periods, authorization)

Existing crop types and associated companies

Historicity Plan: advancement of the forest and cutting plans for re-balancing and recovery of areas to grow

Locating access roads to cultivable areas including tractor, forestry and farm use

Rainfall data to address crops

Establishing land type for master plan development of active cultures

6.2 Poland

6.2.1 Introduction

Creation of Decision Support Systems (DSS) is associated with introduced from 1 January 2014 the obligation to apply the principles of integrated pest management by all professional users of plant protection products. Use of DSS is result of provisions of Art. 14 Directive 2009/128/EC and art. 55 of Regulation No 1107/2009/WE. General principles of integrated pest management are set out in Annex III to the above Directive.

One of the tools to facilitate the implementation of the principles of integrated pest management is decision support systems in crop protection. These systems are useful in determining the optimal terms of crop protec-tion, and thus allow obtaining high efficiency of these treatments while reducing the use of chemical pesticides to a minimum.

The objectives of the practical use of DSS systems:

creation of local agro-meteorological forecasts at selected locations based on the local network of me-teorological stations,

practical application of the system of distribution of decision support systems for farms with simultane-ous verification of their quality,

estimating the quantifiable effects the use of decision support systems by farms of various types,

the creation of agro-meteorological forecasting standard, which in cooperation with other monitoring systems will in the near future for wider application and use of decision support systems in agricultural practice.



Planned stages of system development:

Figure 24 Stages of system development

The proposed institutions to cooperate in the development of the system, in particular the models of disease:

Instytut Ochrony Roślin - Państwowy Instytut Badawczy

Instytut Ogrodnictwa – InHort Skierniewice

Instytut Uprawy Nawożenia i Gleboznawstwa Państwowy Instytut Badawczy

Polska Akademia Nauk

Uniwersytet Przyrodniczy w Poznaniu

The implementation of the system is proposed to use a network of demonstration farms of Wielkopolska Agricul-

tural Advisory Centre in Poznań and also Exhibition Centers and Training of Wielkopolska Agricultural Advisory

Centre in Poznań.

The Centres:

1. Exhibition and Training Centre in Sielinko

2. Centre for Education and Exhibition in Marszew

3. Centre for Exhibition and Education in Gołaszyn

In these centers are possible field tests, demonstration plots and farmers trainings.

Network of demonstration farms - possible implementation of pilot and demonstrations:

Figure 25 Possible location of Demonstration Farms

Meteo stations purchase

Implementation of algorithms for mathematical models

Web-based decision support system



6.2.2 Scenarios.

Scenario A – Data on crop and weather data.

Scenario B – Modeling diseases and pests.

Scenario C – Presentation of data and calculation results.

Scenario D – Notifications.

6.2.2.1 Scenario A – Dane o Data on crop and weather data.

The scenario is designed to create a collection of procedures and mechanisms to input data into the system. These data must serve for mathematical models as a source of data for the calculations.

Name ID Goal

Parameters of crop and grow-ing

A-01 Register data on specific crops in a given season and the farmer.

Data about the field, and its location

A-02 Register information about the fields in a given farmer in given geographical location.

Meteorological data A-03 Register data from meteorological stations.

Treatment plant protection database

A-04 Information from farmers about performed crop protection treatments for the crops and fields.

Irrigation database A-05 Information about irrigation treatments performed for data fields.

Farm details A-06 Database users of the system.

6.2.2.2 Scenario B – Modeling diseases and pests.

The aim is to implement the scenario modeling algorithms plant diseases. The result of the modeling is to be in-formation for farmers or agricultural advisors about the risks and the conditions conducive to the occurrence of diseases and pests. An optional task may be to develop new models or adapting existing models to Polish climat-ic conditions and the system needs.

Name ID Goal

Potato blight (Phytophthora infestans) B-01 Potato blight model

Wheat leaf rust on rye (Puccinia recondita f. sp. Recondite)

B-02 Wheat leaf rust model

Dry-rot of cabbage in rape (Leptosphaeria macu-lans – L. biglobosa)

B-03 Dry-rot of cabbage in rape model

Apple scab (Venturia inaequalis) B-04 Apple scab model

Potato blight I tomatoes (Phytophthora infestans) B-05 Potato blight I tomatoes model

Fusarium in cereals (Fusarium) B-06 Fusarium in cereals model

Other diseases B-nn There is a need to look for opportunities to connect to other disease models



6.2.2.3 Scenario C – Presentation of data and calculation results.

The objective of the scenario is the presentation of the output - the results of calculations of mathematical mod-els. An additional aim is to present the input data in the context of the data result.

Name ID Goal

Charts of meteorological data C-01 Presentation of data from meteorological stations

Graphs the results of calculations of disease risk

C-02 Presentation of the results of mathematical models - the risks

Summaries of recommendations to plant protection

C-03 Information on the occurrence of disease risk - a rec-ommendation of the system or agricultural advisor

Made plant health treatment summar-ies

C-04 Data presentation from the farmers about surgery performed

Summaries of irrigation C-05 Data presentation from the farmers about surgery performed

Archives database C-06 Presentation of data from previous years

Imaging - hazard maps C-07 Presentation of the macro data in the form of hazard maps

6.2.2.4 Scenario D – Notifications.

The scenario is used for the direct notifications of personalized results. The aim is to directly inform the recipient of exceedances defined thresholds threats - the output.

Name ID Goal

SMS notifications D-01 Informing farmers about the dangers on the mobile phone

E-mail notifications D-02 Informing farmers about the dangers on the e-mail box



6.3 Latvian Scenario

The scenario “Melting Kristal” will take place in Latvia in close partnership with the most progressive and tech-nically promoted cranberry growing farm in Latvia named “Gundegas” (Buttercups).

The main objective of the scenario is the crop protection using wireless sensor technologies (WSN) for com-prehensive real time monitoring of meteorological data with main aim to forecast dangerous weather condi-tions for plant and harvest development. Main focus will be gathering data for early warning of radiation frosts and summer overheating.

Scenario of implementation at proof of concept stage will cover semiautomatic gathering and processing of in-put data. The scenario will be devoted for registration of air, crops green canopy, and soil temperature; air and soil humidity; duration and intensity of sunlight, atmospheric pressure. Comprehensive local weather condition monitoring, collection and storage of data will be done storing metadata conforming open data and FOODIE data model concepts for further implementation within existing precision farming and farm management sys-tems.

For data visualization the captured data will be displayed using geo referenced system. It will be possible to make data accessible and available for other interested stakeholders. Additionally, the data could be used for calculation of information such as vegetation indexes, necessary treatments, early warning and prevention of pests, historical yield and results of production.

This is the list of use cases for the Latvian scenario:

Creation of meteorological data capturing infrastructure

Creation of data model

Analysis of gathered data

Evaluation of frost impact prevention methods

Evaluation of overheating impact prevention systems

Evaluation of eventual mathematical models

Evaluation of the system for possible synergies

Evaluation of economic efficiency



6.4 Turkish Scenario

Agricultural area of Turkey is around 49% of the total land with the pastures 28%. Land quality and climate fa-vour animal farming in Turkey, however, small scaled and scattered organization and traditional techniques de-crease the productivity and destroying the pastures. A sustainable animal farming can be achieved by integrating ecological, financial and farming data. Current resources should be inventorised.to achieve this integration.

Collection of pasture/grassland data has been started with the initiation of the law on pastures no: 4342 of Tur-key that defines the basic procedures and rules for the allocation of pastures to farmers. Pasture boundaries should be defined and allocation should be made by the Ministry of Agriculture. Merbis Project (Grassland In-formation system) which is carried on by Netcad for the Ministry of Agriculture enables an online inventory of the grassland/pastures country-wide.

Analysis, correction and integration of the data collected are projected to be the requirement for any pas-ture/grasslands information system.

Department of Pasture and Forage as a part of ministry of Agriculture has been informed and a number of possi-ble scenarios have been co-created.

Supervision of Pasture Occupation: As the law on pastures states, pasture land cannot be used for any other purpose. Detection of any buildings or any different types of vegetation should be achieved.

Rehabilitation of Pastures: Soil quality and ingredients should be analysed.

Determination of Boundaries: As the law on pastures states, pasture boundaries should be renewed every five years. Boundaries should be detected and compared.

Quantity and Quality of vegetation of Pastures: As the quality and quantity of vegetation of pastures have a direct effect on animal farming productivity, several vegetation indices should be utilized.

Prediction of meat production cost: Production cost is greatly dependent on forage cost in animal farm-ing. Analysis of forage on pastures will be great help for cost prediction.



7 Common Features and Functionalities

This chapter presents common features and common functionalities identified in the analysis of the different scenarios and use cases described above.

7.1 List of Generic Use Cases

List of generic requirements identified, detailed in Annex B.

ID Name Goal Status Priority Version

FOODIE-UC-GENERIC.01

Identification of man-agement zones

Delineation of management zones for site-specific treatments



Register precision agricul-ture data

Data entry manually by farmer/advisor or data entry from machinery



Represent precision agri-culture data with a GIS viewer

Represent the geospatial data associated to crops


FOODIE-UC-GENERIC.03.01





Register soil properties Register nutrients balance of the soil Planned Must have 1.0


Obtain analytical infor-mation

Statistical output over selected crops (fields, crops, plots, varieties)



Access semantic infor-mation

Provide access to semantic information Planned Must have 1.0


Store semantic infor-mation

Planned Should have

1.0


Link datasets to semantic data

Allow the creation and modification of links from different datasets (e.g., sensor observations, cartography, statistical in-formation) to semantic data.

Planned Should have

1.0


Service performs algebra-ic and logical operation on datasets

Support simple datasets processing in FOODIE applications

Planned Should have

1.0


System sends alerts/notifications to us-ers

System pushes information to users ac-cording to their subscription preferences



User provides new da-taset(s) to the system

Provide dataset by user Planned Must have 1.0


User accesses existing da-tasets

Assure that the user can query datasets (e.g., observations, features, maps) and





present them in an appropriate way


Run simulations with ob-servations as data input

The system can run simulations based on observations and publish the results

Planned Should have

1.0


User subscribes for re-ceiving alert notifications

The user specifies his/her preferences in order to receive personalized alerts



System disseminates alert notifications

The system pushes alert notifications to the subscribed users



System uniquely identi-fies users

Assure application can perform user-specific actions



Register User New User is registered in FOODIE system Planned Must have 1.0


Authenticate User User is identified by system. Planned Must have 1.0


Access dataset or service that requires payment

To allow users to access a data set or ser-vice that requires payment



Protect the privacy of the contributors

To protect the privacy of the contributors while assuring the application functionali-ty and data quality as well as providing the appropriate acknowledgments for their contributions



Provide visualization of requested data

Visualize data from different sources in a useful way



Search datasets, services and applications

Farmers and stakeholders must be able to find reports and datasets, as well as ser-vices and applications provided by FOODIE (e.g., semantic annotation service, crop yield simulator) and external stakeholders from a common virtual space (market-place).



Manage dataset, service and application publish-ing lifecycle

Farmers and stakeholders must be able to publish and offer their own datasets, ser-vices and applications, modify the publica-tion or remove them from the market-place.



Provide different access methods to marketplace

Farmers and stakeholders may access some datasets and applications free of charge, but may be required to pay for ac-cess others.



Semantic data genera-tion, integration and pub-lishing

The semantic layer will support the inte-gration of heterogeneous data, including both structured and non-structured pieces of information, and the finding of “hid-den” relations between the datasets.






Access and query da-tasets as semantic linked data

To enable the access and query of collect-ed datasets, including non-structured and structured sources, using powerful se-mantic search mechanisms that will sup-port the provision of advanced search in-terfaces to Farmers and other stakehold-ers



Offline operations with client Apps and synchro-nization capabilities

Rural remote areas will probably have lim-ited internet access, so a generic use case of the platform is the use of app clients in an offline scenario. Both, the platform and the apps, will provide functionalities for the synchronization of contents.

Planned Should have

1.0

7.2 List of Generic Requirements

List of generic requirements identified, detailed in Annex D.


FOODIE-REQ-GENERIC-01-V1.0

Non Functional Scalability Pending SHOULD 1.0


Non Functional Extensibility Pending SHOULD 1.0


Non Functional Availability Pending SHOULD 1.0


Non Functional Identity Management & Access control Pending MUST 1.0


Non Functional Big Data Management Pending MUST 1.0


Non Functional Interoperability Pending SHOULD 1.0

FOODIE-REQ-GENERIC-19-V1.0.

Non Functional Dependability Pending SHOULD 1.0


Non Functional Privacy Pending SHOULD 1.0


Non Functional Virtualized Resources Pending SHOULD 1.0


Non Functional Cloud Data Storage Pending SHOULD 1.0


Non Functional Job Scheduler Pending SHOULD 1.0


Non Functional Multiple Data Centers in the Cloud Pending MUST 1.0




Non Functional Vocabulary Specification Pending MUST 1.0


Non Functional Semantic Annotation Pending MUST 1.0


Non Functional Compliance with Linked Data Principles Pending MUST 1.0


Non Functional Semantic Repository and Query Endpoint Pending MUST 1.0


Non Functional Transformation from Non-RDF to RDF Data Pending COULD 1.0


Non Functional Integrate Web map services Pending MUST 1.0


Non Functional Compliance with GEO/GEOSS specifications Pending MUST 1.0


Non Functional Compliance with INSPIRE specifications Pending MUST 1.0


Non Functional Support integration of meta-information Pending MUST 1.0


Non Functional Support information modelling Pending MUST 1.0


Non Functional Support different data types Pending MUST 1.0


Non Functional Access sensor observations Pending MUST 1.0


Non Functional Support generation of personalized alerts Pending MUST 1.0


Non Functional Access mediation Pending MUST 1.0


Non Functional Fuse spatial and temporal data sources Pending MUST 1.0


Non Functional Enable user management Pending MUST 1.0


Non Functional Enable security and rights management Pending MUST 1.0


Informational The system will send to FOODIE platform the data collected from the agro-meteorological station at pilot farm

Pending MUST 1.0


Informational The system will use public raster data (ortho / satellite images)

Pending MUST 1.0


Informational The system will use public cadaster data in standard GIS formats (DXF, SHP, KML)

Pending MUST 1.0


Informational The system will use data from public agro-meteorological stations

Pending MUST 1.0


Informational The system will use data from various GPS devices

Pending MUST 1.0




Functional The GIS system will visualize farm (holding) maps based on ortho image and LPIS data

Pending MUST 1.0


Functional The system will collect the GPS position of the farm machinery

Pending MUST 1.0


Functional The farm management software will collect crop and activity data for further documen-tation

Pending MUST 1.0


Functional The system will show geo-referenced data for a selected date interval

Pending MUST 1.0


Functional The system will show geo-referenced ac-tions performed on the crops

Pending MUST 1.0


Functional The system will aggregate meteorological data for defined time interval

Pending MUST 1.0


Functional The system will show the geo-referenced information on separate layers for each type of information

Pending MUST 1.0


Functional Advanced Visualization Components Pending SHOULD 1.0


Functional Searching in Marketplace Pending MUST 1.0


Functional Publishing in Marketplace Pending MUST 1.0


Functional User Management in Marketplace Pending MUST 1.0


Functional Business Models for Marketplace Pending MUST 1.0


Functional Admin Panel for Marketplace Pending MUST 1.0



8 Conclusions

This deliverable presents the results of the works carried out regarding the pilot descriptions and stakeholder requirements elicitation.

Three different scenarios have been designed and analyzed: Spain, Czech Republic and Germany. Each of them has its own characteristics and peculiarities, so they have been described separately. Together with the descrip-tions, different scenarios and use cases have been identified, and many requirements were drawn. These use cases and requirements have been largely detailed and catalogued. Different sources of information to be inte-grated within the platform have been also identified.

Some more stakeholders have been presented, in a less detailed way. They will enlarge the number of use cases and requirements and will play a very important role in the evaluation of the FOODIE platform.

A common methodological approach has been agreed and the analysis has been done in a formal way in order to be helpful for the platform description. Following that methodology, three types of requirements are consid-ered: functional, informational and non-functional.

As a further result of the works, there have been analyzed and extracted the common features and functionali-ties between the pilots. This is a search for homogeneity in order to facilitate the specification of the service platform.

The content of this deliverable has, as a fundamental aim, to gather a set of use cases and requirements, which are being the main input for the technical packages in the project, for the definition of the architecture, data model and services to be developed.



References

References

[1] Usländer, T., 2010. Service-oriented Design of Environmental Information Systems. PhD thesis of the Karlsruhe Insti-tute of Technology (KIT), Faculty of Computer Science, KIT Scientific Publishing. ISBN 978-3-86644-499-7.

[2] Cockburn, A., 2001. Writing Effective Use Cases. Addison-Wesley, Reading, ISBN-13 978-0-201-70225-5

[3] EU FP7 project no. 033564 Sensors Anywhere (SANY) - http:///www.sany-ip-eu

[4] EU FP7 project no. 244100 Earth Observation and ENVironmental modelling for the mitigation of HEAlth risks (EO2HEAVEN) - http://www.eo2heaven.org

[5] EU FP7 project no. 258723 Collaborative, Complex and Critical Decision-Support in Evolving Crisis (TRIDEC) - http://www.tridec-online.eu

[6] EU FP7 project no. The Environmental Observation Web and its Service Applications within the Future Internet (ENVIROFI) - http://www.envirofi.eu

[7] Usländer, T. , Batz, T., 2011. How to Analyse User Requirements for Service-Oriented Environmental Information Sys-tems. In: Hřebíček, J., Schimak, G., Denzer, R. (eds.) ISESS 2011. IFIP AICT, vol. 359, pp. 165–172. Springer, Heidel-berg.

[8] Balzert, H., 2004. Lehrbuch der Objektmodellierung. Spektrum-Akademischer Verlag.

[9] Leffingwell, D., 2011. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the En-terprise (Agile Software Development Series). Addison-Wesley Professional; 1 edition (January 6, 2011). ISBN-13: 978-0321635846.http://viticulture.hort.iastate.edu/info/pdf/prunecanopy.pdf

[10] http://ir.library.oregonstate.edu/xmlui/bitstream/handle/1957/39902/em9069.pdf

[11] Harrison, R., Flood, D., & Duce, D. (2013). Usability of mobile applications: literature review and rationale for a new usability model. Journal of Interaction Science, 1(1), 1-16. Available at: http://www.journalofinteractionscience.com/content/1/1/1

Table 5: References

http://www.sany-ip-eu/

http://www.eo2heaven.org/

http://www.tridec-online.eu/

http://www.envirofi.eu/

http://viticulture.hort.iastate.edu/info/pdf/prunecanopy.pdf

http://ir.library.oregonstate.edu/xmlui/bitstream/handle/1957/39902/em9069.pdf

http://www.journalofinteractionscience.com/content/1/1/1



Annexes

Annexes A. B, C and are generated automatically from the pilot and generic use cases and requirements com-piled through the Enterprise Architected tool.

They can be found in the annex document to this report.