Progress Report on trial experimentation and App ... · Progress report on trial experimentation...

64
Deliverable D400.4 Progress report on trial experimentation and App development and updated plan for Phase 3 rollout WP 400 Project Acronym & Number: FIspace 604 123 Project Title: FIspace: Future Internet Business Collaboration Networks in Agri-Food, Transport and Logistics Funding Scheme: Collaborative Project - Large-scale Integrated Project (IP) Date of latest version of Annex Start date of the project: 01.04.2013 Duration: 24 Months Status: Final Authors: Michael Zahlmann Daan Goense Sokratis Barmpounakis Marinanne Hagaseth Agathe Rialand Gerhard Schiefer Huub Scholten Johan Bremmer Hande Koc Javier Romero Kühne + Nagel DLO NKUA MARINTEK MARINTEK CentMa Wageningen University DLO Arcelik ATOS

Transcript of Progress Report on trial experimentation and App ... · Progress report on trial experimentation...

Deliverable D400.4

Progress report on trial experimentation and App development and updated plan for Phase 3 rollout

WP 400

Project Acronym & Number: FIspace – 604 123

Project Title: FIspace: Future Internet Business Collaboration Networks in Agri-Food, Transport and Logistics

Funding Scheme: Collaborative Project - Large-scale Integrated Project (IP)

Date of latest version of Annex

Start date of the project: 01.04.2013

Duration: 24 Months

Status: Final

Authors:

Michael Zahlmann

Daan Goense

Sokratis Barmpounakis

Marinanne Hagaseth

Agathe Rialand

Gerhard Schiefer

Huub Scholten

Johan Bremmer

Hande Koc

Javier Romero

Kühne + Nagel

DLO

NKUA

MARINTEK

MARINTEK

CentMa

Wageningen University

DLO

Arcelik

ATOS

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 2 of 64

Contributors:

Aggelos Groumas

Lampros Katsikas

Konstantina Dimtsa

Nikos Petalidis

Eleni Antoniou

Odysseas Mitsonis

NKUA

NKUA

NKUA

OPEKEPE

OPEKEPE

Innovators

Reviewers: Cyril Alias

Matthias Boes

Universität Duisburg /E.

SDZ

Document Identifier: FIspace D400.4 V_05

Date: 22.10.2014

Revision: 07

Project website address: http://www.FIspace.eu

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 3 of 64

Abstract

As a use case project in Phase 2 of the FI PPP, FIspace aims at developing and validating novel Future-Internet-enabled solutions to address the pressing challenges arising in collaborative business networks, focussing on use cases from the Agri-Food, Transport and Logistics industries. FIspace will focus on ex-ploiting, incorporating and validating the Generic Enablers provided by the FI PPP Core Platform with the aim of realising an extensible collaboration service for business networks together with a set of innovative test applications that allow for radical improvements in how networked businesses work in the future. These solutions will be demonstrated and tested through early trials on experimentation sites across Eu-rope. The project results will be open to the FI PPP program and the general public, and the pro-active engagement of larger user communities and external solution providers will foster innovation and indus-trial uptake planned for Phase 3 of the FI PPP.

The project will lay the foundation for realizing the vision and prepare for large-scale expansion, comply-ing with the objectives and expected results of the Phase II use case projects. To achieve these out-comes the project will focus on the following four primary work areas, for which the main concepts and approach are outlined below:

1. Implement the FIspace as an open and extensible Software-as-a-Service solution along with an initial set of cross-domain applications for future B2B collaboration, utilizing the Ge-neric Enablers provided by the FI PPP Core Platform

2. Establish Experimentation Sites across Europe where pilot applications are tested in early trials from the Agri-Food and the Transport and Logistics domains

3. Provide a working Experimentation Environment for conducting early and large-scale trials for Future Internet enabled B2B collaboration in several domains, and

4. Prepare for industrial uptake and innovation enablement by pro-active engagement of stake-holders and associations from relevant industry sectors and the IT industry.

This document is being submitted as specified in the FIspace Description of Work (DoW) as part of deliv-erable D400.4 – update progress report on trial experimentation and App development and updated work plan. The document provides an overview of the experimentation effort and results of the eight trials. It includes a detailed work plan for the work package containing the activities and milestones of the work package as well as for each trial.

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 4 of 64

Project Consortium

DLO; Netherlands Kühne + Nagel; Switzerland

ATB Bremen; Germany University Duisburg Essen; Germany

IBM; Israel ATOS; Spain

KocSistem; Turkey The Open Group; United Kingdom

Aston University; United Kingdom CentMa; Germany

ENoLL; Belgium iMinds; Belgium

KTBL; Germany Marintek; Norway

NKUA; Greece University Politecnica Madrid; Spain

Wageningen University; Netherlands Arcelik; Turkey

PlusFresc; Spain EuroPoolSystem; Germany

FloriCode; Netherlands GS1 Germany; Germany

Kverneland; Netherlands Mieloo & Alexander; Netherlands

North Sea Container Line; Norway OPEKEPE; Greece

LimeTri; Netherlands Innovators; Greece

BO-MO; Slovenia CIT; Spain

MOBICS; Greece SDZ; Germany

Fraunhofer IML; Germany Snoopmedia; Germany

Q-ray; Netherlands EECC; Germany

FINCONS; Italy CBT; Spain

More Information

Dr. Sjaak Wolfert (coordinator) e-mail: [email protected]

LEI Wageningen UR phone: +31 317 485 939

P.O. Box 35 mobile: +31 624 135 790

6700 AA Wageningen www.FIspaces.eu

Dissemination Level

PU Public X

PP Restricted to other programme participants (including the Commission Services)

RE Restricted to a group specified by the consortium (including the Commission Services)

CO Confidential, only for members of the consortium (including the Commission Services)

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 5 of 64

Change History

Version Notes Date

01 Creation of the document 27.6.2014

02 First Draft 23.9.2014

03 Second Draft 15.10.2014

04 Third Draft incl. changes based on comments from T422, T432, T443 16.10.2014

05 Fourth Draft incl. changes based on comments from T441 17.10.2014

06 Fifth Draft incl. Changes based on comments from T431 22.10.2014

08 Final formatting for delivery 22.10.2014

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 6 of 64

Abbreviations

App Application

B2B business to Business

BPM Business Process Manage-ment

D Deliverable

DLO Dienst Landbouwkundig Onderzoek

DoW Description of Work

e.g. Exempli gratia = for example

EC European Commission

EDI Electronic Data Interchange

EPCIS Electronic Code Information Service

ESB Enterprise Service Bus

EU European Union

FFV Fruit Flowers Vegetables

FI-PPP Future Internet Public Private Partnership

FIA Future Internet Assembly

FP7 Framework Programme 7

GA Grant Agreement

GE Generic Enabler

GLN Global Location Number

GPS Global Positioning System

GUI Graphic User Interface

i.e. id est = that is to say

ICT Information and Communica-tion Technology

IP Intellectual Property

IPR Intellectual Property Rights

ISO International Standardization Organization

KPI Key Performance Indicator

LDD Large Digit Display

LSC Logistics Service Consumer

LSP Logistics Service Provider

M Month

MIP Meat Information Provenance

PC Personal Computer

PIA Product Information App

QR-code Quick response code

RFID Radio Frequency Identification

RTD Research and Technological Development

RTI Returnable Transport Item

SDK Software Developer Kid

SLA Service Level Agreement

SME Small and Medium Sized En-terprise

ST Sub-Task

T Task

TIC Tailored Information for Con-sumers

TTS Time Temperature Sum

WP Work Package

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 7 of 64

Table of Contents

Progress report on trial experimentation and App development and updated plan for Phase 3 rollout .................................................................................................................................. 1

1 Introduction ..................................................................................................................................... 11

1.1 WP400 .................................................................................................................................... 12

1.1.1 Use case trials and domain Apps (WP 400) ........................................................................... 12

2 400.4 Progress report on Trial experimentation and App development and initial plan for Phase 3 rollout .................................................................................................................. 13

2.1 Trial 421 - Crop Protection Information Sharing ..................................................................... 14

2.1.1 Trial Team ............................................................................................................................... 14

2.1.2 Report on Trial Progress ........................................................................................................ 14

2.1.3 App Development ................................................................................................................... 14

2.1.4 Key Performance Indicator ..................................................................................................... 15

2.1.5 Balanced Scorecard ............................................................................................................... 16

2.2 Trial 422 – Greenhouse Management and Control ................................................................ 19

2.2.1 Trial Team ............................................................................................................................... 19

2.2.2 Report on Trial Progress ........................................................................................................ 19

2.2.3 App Development. .................................................................................................................. 20

2.2.4 Balanced Scorecard ............................................................................................................... 21

2.2.5 Key Performance Indicator ..................................................................................................... 23

2.3 Trial 431 - Fish Distribution and (Re-) Planning ..................................................................... 27

2.3.1 Trial Team ............................................................................................................................... 27

2.3.2 Report on Trial Progress ........................................................................................................ 27

2.3.3 App Development ................................................................................................................... 27

2.3.4 Evaluation of FIspace Services and Initial Apps, and Open Call Apps .................................. 28

2.3.5 Balanced Scorecard ............................................................................................................... 31

2.3.6 Key Performance Indicator ..................................................................................................... 31

2.4 Trial 432 – Fresh Fruits and Vegetables ................................................................................ 32

2.4.1 Trial Team ............................................................................................................................... 32

2.4.2 Report on Trial Progress ........................................................................................................ 32

2.4.3 App Development. .................................................................................................................. 32

2.4.4 Balanced Scorecards ............................................................................................................. 32

2.4.5 Key Performance Indicator ..................................................................................................... 34

2.5 T433 Flowers & Plants Supply Chain Monitoring ................................................................... 36

2.5.1 Trial Team ............................................................................................................................... 36

2.5.2 Brief description about the test scenario. ............................................................................... 36

2.5.3 Test results, challenges, recommendations and advises for the project team ..................... 38

2.5.4 Balanced Scorecard Approach Flowers & Plants trial ............................................................ 38

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 8 of 64

2.5.5 Balanced Scorecard & Key Performance Indicators .............................................................. 38

2.6 Trial 441 – Meat Information Provenance (MIP) .................................................................... 38

2.6.1 Trial Team ............................................................................................................................... 38

2.6.2 Report on Trial Progress ........................................................................................................ 38

2.6.3 App Development ................................................................................................................... 38

2.6.4 Balanced Scorecard ............................................................................................................... 39

2.6.5 Key Performance Indicator ..................................................................................................... 40

2.7 Trial 442 - Import and Export of Consumer Goods ................................................................ 42

2.7.1 Trial Team ............................................................................................................................... 42

2.7.2 Report on Trial Progress ........................................................................................................ 42

2.7.3 App Development ................................................................................................................... 43

2.7.4 Scenario-Check Point Details ................................................................................................. 46

2.7.5 Balanced Scorecard & Key Performance Indicators .............................................................. 53

2.8 Trial 443 –Tailored Information for Consumers (TIC) ............................................................ 54

2.8.1 Trial Team ............................................................................................................................... 54

2.8.2 Report on Trial Progress ........................................................................................................ 54

2.8.3 App Development. .................................................................................................................. 55

2.8.4 Balanced Scorecard & Key Performance Indicator ................................................................ 55

2.8.5 Relationships between objectives and activities .................................................................... 61

3 Update on collaboration and harmonization and large scale expansion activities of the use case trials in Phase 3 ........................................................................................................ 62

3.1 Update on collaboration and harmonization ........................................................................... 62

3.2 Update on large scale expansion ........................................................................................... 62

List of Tables

Table 1: Overall FI-PPP & FIspace balance scorecard ........................................................................ 17

Table 2: Service provider balance scorecard ....................................................................................... 17

Table 3: End user balance scorecard ................................................................................................... 18

Table 4: Individual App balance scorecard........................................................................................... 18

Table 5: Updated overview of the Greenhouse trial apps development .............................................. 20

Table 6: Refined Key Performance Indicators based on the Balanced Scorecard fort he Greenhouse Management. ..................................................................................................... 21

Table 7: Key Performance Indicators for Greenhouse Management & Control trial ............................ 23

Table 8: Marketplace Operation Service .............................................................................................. 29

Table 9: Open call Apps ....................................................................................................................... 30

Table 10: Reduced scorecard of RTI Service Provider with relevance for prototype evaluation ........... 33

Table 11: Reduced scorecard of trader with relevance for prototype evaluation ................................... 33

Table 12: Reduced scorecard of retail with relevance for prototype evaluation..................................... 34

Table 13: KPIs with experimental potential related to the various Apps ................................................ 35

Table 14. Balanced Scorecard of the MIP trial ....................................................................................... 39

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 9 of 64

Table 15. Key Performance Indicators of the MIP trial. The numbers (#) refer to the coinciding rows of the balanced scorecard:............................................................................................. 40

Table 16. App development Scenarios................................................................................................... 43

Table 17. Scenario – User Authentication .............................................................................................. 44

Table 18. Scenario – User Authorization ................................................................................................ 44

Table 19. Scenario – Shipment search .................................................................................................. 44

Table 20. Scenario - Status and Event Monitoring, Map Service ........................................................... 45

Table 21. Scenario – Check Point Details. ............................................................................................. 46

Table 22: Scenario - Replanning ............................................................................................................ 47

Table 23: Scenario – Real-time Notification ........................................................................................... 47

Table 24: Scenario- Shipment Notification Management ....................................................................... 48

Table 25: Scenario-Report Event or Deviation ....................................................................................... 48

Table 26: Scenario- Check In & Check Out............................................................................................ 49

Table 27: Scenario- Create Transport Demand ..................................................................................... 50

Table 28: Scenario- Transport Demand Search ..................................................................................... 51

Table 29: Scenario- Request Shipment Details ..................................................................................... 52

Table 30: Scenario- Submission of the demand to LPA ......................................................................... 53

List of Figures

Figure 1: Desired Collaborative Business Network and the needs for the Future Internet ................... 11

Figure 2: High-level structure of WP400 “Use case trials and domain Apps” ....................................... 12

Figure 3: The Greenhouse Management and Control apps .................................................................. 21

Figure 4: Process supported by the trial ................................................................................................ 28

Figure 5: Experimentation Plan ............................................................................................................. 28

Figure 6. Overview of events and objects in the flowers and plants supply chain. ............................... 37

Figure 7. Interaction of the Apps and FIspace ....................................................................................... 42

Figure 8: Tailored Information for consumers session Agenda ............................................................. 54

Figure 9: Scorecard Product Info ........................................................................................................... 56

Figure 10: Scorecard Food Traffic Light App ........................................................................................... 57

Figure 11: Scorecard Augmented Reality App ........................................................................................ 58

Figure 12: Scorecard Shopping List & Recipes App ............................................................................... 59

Figure 13: Scorecard Push Information App ........................................................................................... 60

Figure 14: Relationship between objectives and activities ...................................................................... 61

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 10 of 64

Disclaimer

The content of the publication herein is the sole responsibility of the publishers and it does not necessarily represent the views expressed by the European Commission or its services.

While the information contained in the documents is believed to be accurate, the author(s) or any other participant in the FIspace consortium make no warranty of any kind with regard to this material including, but not limited to the implied warranties of merchantability and fitness for a particular purpose.

Neither the FIspace Consortium nor any of its members, their officers, employees or agents shall be re-sponsible or liable in negligence or otherwise howsoever in respect of any inaccuracy or omission herein.

Without derogating from the generality of the foregoing neither the FIspace Consortium nor any of its members, their officers, employees or agents shall be liable for any direct or indirect or consequential loss or damage caused by or arising from any information advice or inaccuracy or omission herein.

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 11 of 64

1 Introduction

Insights gained in Phase 1 of the FI-PPP emphasize the need for novel ICT solutions that allow radical improvements for collaboration in business networks. Numerous sectors demand such solutions including the Agri-Food and Transport and Logistics industries, which are the focus of the FIspace project. This project leverages the outcomes of two complementary Phase 1 use case projects: FInest and SmartAgri-Food. The aim of the project is to pioneer fundamental changes in how collaborative business networks work in future.

Modern business is characterized by cross-organizational business networks where several actors need to interact in order to achieve common, as well as individual, business goals. When conducting business in such highly networked, often border-crossing, dynamic and competitive environments, it becomes cru-cial for the involved actors – which can include commercial enterprises of any size, public authorities, associated service providers (e.g., financial institutions or insurance companies), etc. – to collaborate in an efficient, effective, secure and trustworthy manner, i.e., to exchange information and communicate among each other in order to coordinate their business activities.

Figure 1: Desired Collaborative Business Network and the needs for the Future Internet

Current ICT solutions do not provide adequate support for collaborative business networks. The vast majority of existing and currently employed IT solutions focus on supporting the internal business activi-ties of individual actors, while interaction with business partners is limited to manual efforts using e-mail, phone, and fax, or only partially supported through EDI. In addition, monitoring and managing of business processes still heavily relies on human involvement, leading to high latencies between the occurrence of a business event in the real-world and its observation by IT systems, and thus other stakeholders along the value chain. This results in the unsatisfying situation where there is only limited end-to-end visibility in collaborative business networks, with unacceptably high manual coordinating efforts required by each involved stakeholder leading to the establishment of mainly closed partner networks. Closed networks particularly disadvantage SMEs who generally do not have the financial or technical means for entering these networks and collaborating with larger organizations.

Novel ICT infrastructures that enable seamless B2B collaboration and facilitate the creation of dynamic and open business networks are needed – not to merely overcome today’s technical deficiencies, but in order to pave the way towards truly collaborative business networks in the future. Such a future can be realized by exploiting the capabilities of Future Internet technology developed within the FI PPP pro-gramme. These technologies allow, for instance, the gathering of real-world data via smart sensors (In-ternet of Things), cost-efficient development of value-added applications by orchestrating existing ones (Internet of Services), and ubiquitous access via Cloud infrastructures.

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 12 of 64

1.1 WP400

1.1.1 Use case trials and domain Apps (WP 400)

WP 400 focuses on leveraging and extending work performed in Phase I of the FI PPP program to setup trial sites for real world use cases and to exploit those sites for conducting initial use case experiments (with the support of WP 300) to determine and demonstrate whether the FIspace solution and the under-lying Generic Enablers being utilized are capable of delivering benefits and utility in the real-world.

Based on the needs of the use case trials themselves, baseline and domain Apps will be developed (as part of WP 400) so that the trials can be performed and the ecosystem business model envisioned for the FIspace service tested. In addition, where needed, trial-specific, local infrastructure (such as in-the-field sensors and devices) will be set-up and linked to the FIspace components hosted by WP300.

Figure 2: High-level structure of WP400 “Use case trials and domain Apps”

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 13 of 64

2 400.4 Progress report on Trial experimentation and App develop-ment and initial plan for Phase 3 rollout

This deliverable provides a progress report on the development of trial experiments and FIspace Apps as well as an overview of the plans currently being developed for Phase 3 rollout of the FIspace service for the agri-foods and transport and logistics domains. The document provides an overview of the experi-mentation plans of the eight trials proposed for the FIspace project and includes a detailed set of work plans for the work package.

Each trial progress report is concerned with the actual conduct of the defined experiments using the iden-tified experimentation environments, domain specific applications, FIspace services and FI WARE infra-structure. Experimental outcomes, based on clearly defined protocols which are being developed, will be compared to expected outcomes. Results will be documented and feedback made based on achievement of business value, performance of FIspace and FI WARE services and the domain applications. The pro-gress reports include (or will include in the future as experiments are carried out) details on the following:

Progress monitoring and control of the experimentation and domain application development ac-tivities

Definition of trial specific key performance indicators (KPI)

Documentation of experimental outcomes with a balanced score card approach

Feedback of experimental outcomes to interested domain partners, FIspace developers, domain application developers and FI WARE developers

To align with the Apps functionalities proposed in D400.6 and D400.10, involved partners have made an initial analysis of the Apps and their relationship to the trials. Alignment of the Apps with the trials is a work in progress with some trials more advanced in the analysis than others. All the trials will perform the deep inspection and analysis of the Baseline Apps necessary to ensure that these apps are properly de-veloped during the next reporting period.

Look for similar business processes within and between each trial

Avoid parallel and unaligned approaches to App development

Align on experimentation and testing scope

Establish a collaborative network among the trials

Activities and actions concerning the development and implementation of initial and domain apps, which is lead and monitored by Task 450 will be reported in D400.8 as well as in D400.12

A workplan for the WP400 activities has been established and is constantly updated trough input from the trials. The workplan is a separate document.

Harmonizing the activities of WP400 shall ensure an efficient utilization of the provided funds and a high level of productivity for achieving the aims set out in the DoW.

This report also includes discussion of the identification of potential large scale trials, identification of po-tential additional trial sites and development of a large scale trial rollout plan for Phase 3 of the FI PPP. The initial work on the set-up of Phase 3 actions includes preliminary work on:

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 14 of 64

2.1 Trial 421 - Crop Protection Information Sharing

2.1.1 Trial Team

The Crop Protection Information Sharing Trial will be realised by:

DLO-ASG Trial lead, Scheduling application, and weather & soil moisture sensor system

DLO-PRI Phytophthora advisory applications.

Kverneland Spraying.

LimeTree Farm Management Information System.

BO-MO LTD (open call partner) “Formulation of weather scenarios”

CIT Development S.L. (open call partner) Bad weather alert & Workability

2.1.2 Report on Trial Progress

Discussions between regular trial partners are on a “when needed” basis. With the open call partners a two weekly teleconference is held in which progress is discussed and some items which came up in the previous weeks. The two open call partners made a detailed work plan and produced the first deliverable as foreseen in the overall project plan.

The trial lead also participated in the two weekly calls among the WP400 trial leaders.

The interaction between the different applications which form the total business process for Phytopthora control is regularly updated by means of sequence diagrams in the rmCrop reference model. They are also included in a regular update of the interface description between the different apps.

The trial leader continued to participate in the international (ISO) and national (Netherlands) standardisa-tion activities. The trial lead (DLO-ASG), LimeTree and BO-MO LTD participated in the Smart Agrimatcis conference in Paris.

2.1.3 App Development

The number of Apps as defined in the original proposal is reduced to keep a clear overview of the whole trial on Crop Protection Information Sharing trial. Many of the originally mentioned apps were in fact sub processes of one application. This does not mean that the functionality of the trial is reduced, but unnces-sary details are not presented.

The Scheduling Application is in full development. At the end of this reporting period an initial version is up for testing. It is focused on only Phytophthora control with one Man-Machine-System and normative assumptions on required spraying actions beyond the advised period. The design is such that it can cover all types of farm operations, but that would only be possible when the FMIS and workability App used in this trial would foreseen in these extensions. In the tested version the optimal schedule is only presented in XML format. A viewer is to be developed in the next three months.

The soil moisture sensor system is ready for test by using a standard computer platform as gateway.

The Phytophthora Advisory application is thoroughly tested on its agronomical aspects during the 2014 growing season. Integration testing is done at the ends of this reporting period.

Spraying is tested for data exchange by means of data exchange by physical media. The design for web based exchange of task data is specified at the end of this reporting period and will be tested in Month 21.

The FMIS is extended to deliver data on ActivityField’s, apart from data on CropField’s which are already made available for the advisory system.

A first prototype of the app for formulation of the weather scenario is presented by means of a simple user interface. By clicking a position on a map of the Netherlands, the prediction of exactly that location is shown in tabular form. This will be extended in the coming period by including historical weather and weather of a local weather station. Also the specified interfaces will be implemented.

The first prototype of the bad weather application is presented as a detailed description of its design. A demonstration is not possible, as it is a pure webservice which presents only data in XML format.

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 15 of 64

The workability application is in development, based on the interface description which was available at the end of this reporting period. Currently data gathering from external data sources (Buienradar and KNMI stations) has been achieved during this period. Some efforts has been spend also to start to define the different workability REST messages in order to communicate FISPACE B2B Workability App.

Quite some effort is spend on developing the interface definition for weather data and sensor data in gen-eral. The design of these interfaces is based in the drmCrop reference model, which describes DataSets which hold one or more PropertyValue’s. PropertyValue’s refer to a coded PropertyVariable’s. For the weather related variables it is chosen to use two coding tables from the World Meteorological Organisa-tion. These are CREX and GRIB2. A full description and argumentation is found in the document “Sen-sorData2014NnNn.docx”

Dynamic interaction and interface description to exchange data between all applications are continuously updated in the document MessagingForCropProtectionInformationSharingVersionYyyyMmDd.docx. Dat exchange is based on xsd specifications that are generated from the drmCrop reference model. The re-sulting xsd’s are made available to all partners in the trial.

2.1.4 Key Performance Indicator

Key performance indicators are used to measure the success of the Crop Protection Information Trial by using FIspace. The performance shall be measured in respect of all stakeholders.

One of the stakeholders is the European Union with the objective of FIspace, as part of the FI-PPP pro-gramme, to accelerate the adoption of future internet technologies in Europe. A group of stakeholders are the server providers for the agricultural community who want to sell their products to the end users, in the domain of this trial the farmers. The third category of stakeholders are the end users, which are farmers and in some cases consultants which advice the farmers.

It is the objective of the server providers to reach a market as large as possible, with low distribution and service cost. Another objective is to use data and services provided by business partners at a better quality and at less cost then when they would have to do it themselves.

The objective of the farmers and consultants is to have easy access at low cost to a suite of products which together fit best in their enterprise.

Key performance indicators can be classified in:

KPI’s from the overall FI-PPP / FIspace perspective

KPI’s from the business providers perspective

KPI’s from om the Business Process of the end user (farmer & consultants) perspective

KPI’s from the individual app perspective

Some of the performance indicators are not measurable during this Phase 2 trial period, especially that of the overall FI-PPP / FIspace perspective.

An important key performance indicator is the quality of the application offered by the different Apps. This would require for our trial a meteorological and agronomical evaluation. This is out of the scope of this trial. The assumption is that the apps are of the same level of performance as offered outside the FIspace environment. The performance evaluated here is on the employability of the apps by using FIspace tech-nology.

2.1.4.1 KPI’s from the FI-PPP / FIspace perspective

The number of applications in the App store(s)

The number of purchases from the App store

The number of events processed by the NNN (former Business Collaboration Object)

Regional distribution from Apps, and purchases.

Number of entities purchasing Apps.

Number of Business Processes formed by combining Apps.

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 16 of 64

2.1.4.2 KPI’s from the business providers perspective.

The number of purchases by the FIspace App store

The availability of other Apps which can be used as input / contributed for the devel-

oped apps

The effort required to offer the app through the FIspace platform

The cost of initial employment

The periodical cost of employment

2.1.4.3 KPI’s form the Business Process and end user perspective

The effort to define business collaboration by combining Apps.

The choice of combinable Apps on the FIspace platform.

Improvement in capabilities and quality of a business process on FIspace in relation to

classical forms of the business process.

The cost of the apps (purchase, update and/or per run cost) required for a business pro-

cess on FIspace in relation to a classical forms of managing the business process.

Reduction in labour time spent to perform the advisory, planning and administrative as-

pects of the business process.

Timeliness of event messages in relation to actual events.

Handling of failing apps in the business process.

2.1.4.4 KPI’s from the individual app perspective

General:

Response time of the app. (this can be also just an acknowledge that a request is re-

ceived)

Required time to deliver the requested information.

Actuality of the App.

Handling of observed error/bugs.

2.1.5 Balanced Scorecard

Updated version, based on the work of the last 6 month

For each of the four stakeholders (groups) a balance scorecard is formulated in respect of four different perspectives. The four perspectives are:

Learning and growth perspective

Internal Business Process perspective

Customer satisfaction

Financial performance

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 17 of 64

2.1.5.1 Overall FI-PP & Fispace

Table 1: Overall FI-PPP & FIspace balance scorecard

Perspective Objective Measure Target Activity

Learning & Growth Regional distribution Number of countries

Number of Platforms Number of Platforms

Number of App providers Number of App providers

Number of End users Number of End users

Number of formed Business processes

Number of formed Business processes

Internal Business Process

Customer satisfaction Number of Apps Number of Apps

Number of Purchases Number of Purchases

Number of processed events Number of processed events

Financial Perfor-mance

Ability to run without EU sub-sidies

Total financial turnover turnover

2.1.5.2 Business Providers

Table 2: Service provider balance scorecard

Perspective Objective Measure Target Activity

Learning & Growth

Growing number of end users purchasing apps.

Number of purchasing end users.

Growing number of Apps that are input for “my” App

Number of available Apps as input

Internal Business Process

Effort required to offer the App through the FIspace platform

Learning time

Installation time per App

Customer satis-faction

Number of purchases

Growing number of Business Pro-cesses in which “my” App is used

Number of Business pro-cesses using “my” App

Financial Perfor-mance

More turnover by FIspace Turnover through FIspace platforms.

Reduced financial cost The cost of initial employ-ment on the platform

Reduced financial cost The cost of employment per year.

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 18 of 64

2.1.5.3 End User

Table 3: End user balance scorecard

Perspective Objective Measure Target Activity

Learning & Growth

The number of “competing” Apps per App Type.

Internal Busi-ness Process

Time spent on formulating a business process

Improvement in capabilities and quality of the business process

Reduction of administrative time to run a business pro-cess

Time spend behind the different computer systems.

Timeliness of event messag-es

Time (hour minutes seconds) between occurence and event message.

Tiem spend on solving problems for running the business process

Customer satis-faction

- - - -

Financial Per-formance

The total cost (per hectare) of running the business process during a season

2.1.5.4 Individual App

Table 4: Individual App balance scorecard

Perspective Objective Measure Target Activity

Learning & Growth The App uses latest ex-pertise/data

??

Internal Business Process

Response time of the App

Required Time to deliver the re-quested information

Handling of observed errors/bugs

Time spent on handling errors

Customer satisfac-tion

Number of purchases of this App

Number of activated Business processes of the App

Number of activations of the App per season/year.

Financial Perfor-mance

Turnover of the specific App

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 19 of 64

2.2 Trial 422 – Greenhouse Management and Control

2.2.1 Trial Team

The Greenhouse Management and Control trial is realised by:

NKUA Trial lead, Contributing to the development of the trial apps, expertise on Sensor Networks, and mobile/wireless communication (for the data acquisition in the greenhouses)

OPEKEPE Traceability platform provision, experimentation site, farmers mobilizing, Com-plaint Management & Product Recall apps development

Innovators Experimentation site realisation and support, aiming at ubiquitous access and IoT integration.

MOBICS Development of Crop Monitoring and Crop Analyser applications

2.2.2 Report on Trial Progress

The Greenhouse Management and Control trial is used to demonstrate how the FIspace collaboration platform supports business processes related to the agricultural domain. The principal goal of the scenar-ios is to realize efficient real-time collaboration between business stakeholders, via domain-specifc FIspace apps and the respective business entities inside the platform core.

Diverse scenarios are being realized in the context of the trial, as for each one of the scenarios, several different business stakeholders, as well as, legacy ICT systems are participating: farmers, greenhouse managers, advisory/expert systems, agronomists, Farm Management Information Systems, meteorologi-cal stations, product traceability platforms, etc.

Overall, via the use cases, which will be presented below, it is expected that farmers will handle their tasks more efficiently, producers will be able to discover potential partners in a much more sophisticated and centralized way, developers will be able to share their apps via the FIspace Store, while several business actors who are involved in the different scenarios will also gain profit from participating in such collaborative processes.

During the last six months, the Greenhouse Management and Control trial’s efforts have been focusing on the one hand on extending the initial “Advice Request” and “Search for New Farmers” scenarios, while on the other hand, progressing with other use cases of the trial, such as the “Complaint Management”, and the “Task Planning”. In parallel to the app development, the initial testing and KPI assessment is already providing some first insights concerning the value added using FIspace in the particular business domain, while a broader overview will be available after all the scenarios have been deployed and tested inside the B2B platform.

Furthermore, the Greenhouse Management and Control trial was one of the two main trials, which were selected to prepare and demonstrate their initial results in the M12 review of Fispace. In addition, The Greenhouse trial team (NKUA and MOBICS) participated in the Smart AgriMatics conference in Paris, in June 2014. The session “Smart Greenhouse Management & Control on FIspace B2B platform” was chaired by the NKUA team. Several demo sessions, as well as a lot of fruitful discussions between ex-perts of the domain took place.

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 20 of 64

2.2.3 App Development.

The table that follows gives an updated overview of the current planning of the app development with minor alterations. A new column has been added, which presents the overview of the previous and future releases.

Table 5: Updated overview of the Greenhouse trial apps development

Scenario App Type Releases

Advice Request Greenhouse Monitoring & Advice

Integrated trial-specific app (former Green-house Advice and Greenhouse Sensor Monitoring apps)

V1, M12 (available)

V2, M18

V3, M24

Greenhouse Crop Moni-toring

Open Call trial app V1, M15 (available)

V2, M21

V3, M24

Greenhouse Crop Ana-lyser

Open Call trial app

Managing Complaints Complaint Management specific app V1, M15 (available)

V2, M21

V3, M24

Search for new Farmers Marketplace Operations Service

initial app/service V1, M12 (available)

V2, M18 (available)

V3, M24

Product Recall Product Recall trial-specific app V1, M21

V2, M24

Task Planning Greenhouse Crop Ana-lyser

Task Planning app*

Open Call trial app

trial-specific app

V1, M15 (available)

V2, M21

V3, M24

*The Task Planning app will act complementary to the Crop Analyzer app, which already implements part of the task planning func-tionality

With regard to the Greenhouse trial applications, which are being developed, after the entry of MOBICS, the new Open Call trial member, parallel development in the context of the Advice Request scenario is on-going: prototypes for both the mobile Crop Monitoring app, as well as the Crop Analyser web-based app are already available. At the same time, in relation to the already presented Greenhouse Sensor Monitoring and Greenhouse Advice apps, developed by NKUA, available since M12, current development focuses on the integration of the two apps, into one, wider-scope application.

Regarding the Complaint Management scenario, the main effort focuses on the creation of the complaint data model inside the FIspace platform, and particularly the way it is being handled by the System & Data Integration module (SDI). In the same scenario, a new API was created from the side of the Greenhouse (Farm) Management Information System (FMIS), in order to implement the connection between the Com-plaint Management app and the FMIS, and enable the Complaint app to acquire the required information about raw products from the Greenhouse. With regard to the same scenario, the connection to the Trace-ability Platform is also currently in progress and expected to be realized within the next months.

The Marketplace Operations (MOS), which supports the “Search for New Farmers” scenario, is also con-tinuing to extend its functionality and provide more advanced features. MOS is an initial FIspace app de-veloped by NKUA and is currently used in two different trials. As it has already been presented, currently, MOS is in a transition stage of becoming a FIspace service, instead of an app. This will require some small architectural modifications in the structure of the app/service in collaboration with the core devel-opment team.

Furthermore, in relation to the Task Planning scenario, the Greenhouse trial team is in the process of integrating an external meteorological station and service in collaboration with Scient Act S.A., who pro-

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 21 of 64

vides the meteo service. Current on-going work comprises building the required interfaces, defining the required data models, and receiving the meteo data via the System & Data Integration module into the platform.

Figure 3: The Greenhouse Management and Control apps

2.2.4 Balanced Scorecard

The Balance Scorecard methodology provides the means to describe the objectives, the Key Perfor-mance Indicators (KPIs) and the targets of the FIspace trials from a higher level business view. Four per-spectives are taken into account: i.e., the process, the customer, the learning and the financial. In the previous report of M12, the Greenhouse Management and Control trial presented one scorecard per stakeholder category, i.e., the farmer, the producer and the external legacy system owners (e.g., the Ex-pert System owner). An updated version including some refinement on the KPIs (after some further as-sessment) of these scorecards is presented in the table below.

Table 6: Refined Key Performance Indicators based on the Balanced Scorecard fort he Greenhouse Management.

Perspective Stakeholder Objective Measure Target Activity

Process Farmer Improve productivity

Time required for handling alerts/task planning

-50% Greenhouse Moni-toring & Advice app, Crop Moni-toring app, Crop Analyser app us-age

Improve quality and production size

Production loss due to late re-sponse to crop problems

-20% Greenhouse Moni-toring & Advice app, Crop Moni-toring app, Crop Analyser app us-age

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 22 of 64

Perspective Stakeholder Objective Measure Target Activity

Producer Improve effi-ciency

Reduction of Customer com-plaint analysis required time (time/complaint analysis)

-50% Complaint Man-agement app us-age

Reduction of time required to retrieve the list of the stake-holders related to a particular product (time/ retrieved list)

-50% Product Recall app usage

Easier discovery of potential new business part-ners in a mar-ketplace (new collaborations/ year)

+10% Marketplace Op-erations app us-age

Legacy system owner

The external process of the legacy systems separately will be integrated as is

- - -

Customer Farmer Food safety reliability

Reduce com-plaints received from end-product pro-ducers

-10% Improved, effi-cient, automised procedures using the Greenhouse FIspace apps (Crop Monitoring, Analyser, etc.)

Improve ser-vices towards end-product producers

New custom-ers/ year

+10% Automised proce-dures using Greenhouse FIspace apps (Crop Monitoring, Analyser, etc.)

Producer Improve ser-vices towards end users (higher satisfac-tion)

New custom-ers/ year

+10% Automised com- plaint manage-ment & product recalling proce-dures

Legacy system owner

Attract more customers/ system users

New custom-ers/ year

+10% By integrating the system into FIspace, it is di-rectly available for participating in diverse busi-ness processes

Learning Farmer Increased flexi- Freed time in -20% Automation of

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 23 of 64

Perspective Stakeholder Objective Measure Target Activity

Producer bility in em-ployee engage-ments

Shorter learning curve for new crop production

process activity

Time required for studying about a new crop

-20%

provided services

Digital context-aware crop treat-ment resources (Crop Analyser App, Crop Moni-toring App)

Legacy system owner

Financial Farmer Lower process costs

Lower transpor-tation costs

€/process cycle

% of transporta-tion required

-10%

-70%

Optimized opera-tions, customer base increase, flexibility in em-ployee engage-ment,

reduction of travel and communica-tion costs

Producer

Legacy system owner

Increase of productivity

Product quanti-ty/ services accomplished per year

+10% Optimized opera-tions

As derived from the above objectives overview, it is becoming clear that –depending on the perspective- the KPIs are targeting between 10% and 50% of enhancement. Process perspective is the one, in which the higher improvement is expected, while from other perspectives, the gains are expected to follow a smoother route initially, and increase over time.

2.2.5 Key Performance Indicator

The Balanced Scorecard methodology presented an overview of the trial objectives, in relation to the process, the customer, the learning and the financial aspects, from a high level business perspective. In this section, we present the Key Performance Indicators (KPIs) from the technical perspective, which are the ones that will be actually assessed in order to evaluate the real outcome of the trial scenarios. In the table below, these KPIs are presented, accompanied with the means of calculation of each one of them, as well as their target values (or actual results if applicable):

Table 7: Key Performance Indicators for Greenhouse Management & Control trial

Perspective Key Performance Indicator

Means of assessment Value (target or actual result if tested)

Stakeholders

Time required to accomplish each one of the business collaborations defined in the trial scenarios

The different use cases (Ad-vice Request, Complaint Management, etc.) are de-ployed on the FIspace Ex-perimentation Environment. Each one of them will be described and run based on

The current results regard-ing the Advice Request (us-ing the initial Experimenta-tion Environment version and simulated event inside the greenhouse) provide notification alerts to the

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 24 of 64

Perspective Key Performance Indicator

Means of assessment Value (target or actual result if tested)

pre-defined steps. The time is calculated by the sum of the single step execution time.

farmer within 10 seconds after the event (end to end scenario).

Time required to get an ex-pert’s response for a specific crop problem.

The end to end time is calcu-lated from the time a farmer starts filling in a form until the time he gets a first re-sponse from an expert (some realistic assumptions on the typical expert re-sponse times should be made)

Less than the time required today, especially if addition-al info such as crop photos are involved.

Deployment costs Time required for the de-ployment, to which extent does it influence the on-going production process, network deployment (e.g., Internet connection if not available), FIspace Apps purchase (FIspace Store), IT expert responsible for the integration with the plat-form

Less or equal to legacy sys-tem deployment (to be fur-ther elaborated with domain experts)

Maintenance costs Costs for the hardware (e.g., sensor network), connectivi-ty costs (e.g., Internet con-nection costs), periodic sub-scription fees due to FIspace app usage, IT expert costs for maintenance

Less or equal to legacy sys-tem deployment (to be fur-ther elaborated with domain experts)

Update / Upgrade costs New FIspace app release cost (FIspace Store updates), additional features (in-app purchases), new devices supported (equipment)

Less or equal to legacy sys-tem deployment (to be fur-ther elaborated with domain experts)

Impact on the stakeholder’s revenues

Assess the gain from: the automation of processes, the centralized support of the software inside the plat-form, the possibility for early warning from remote experts about crop/product problems and great poten-tial for collaborations with diverse stakeholders via the FIspace Marketplace

Varying in relation to the stakeholder type. To be further elaborated.

Platform

Platform usability a) time required to integrate external systems into FIspace, b) training time for the stakeholders

a) will rely on the toolkit that will be finally provided by the T280 & T250 teams (to be further elaborated after interaction with the WP200 teams)

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 25 of 64

Perspective Key Performance Indicator

Means of assessment Value (target or actual result if tested)

b) Target is that the training time is minimal for the plat-form usage, i.e., 1 day. This will contain creating a FIspace account, logging in, browsing the FIspace Store and interacting with other stakeholder via the FIspace GUI. The required time for specific software/FIspace apps is out of scope from the platform perspective.

Response time (applied for each one of the test cases, e.g. time for alert to be trig-gered, time for advice to come back, time to find re-ceive a complaint analysis for a product etc.)

Experimentation Environ-ment (EE) testing.

Initial round of experiments has resulted in an average of 4 seconds (simulation of event generation inside the greenhouse and notification received on the FIspace main GUI and Advice app)

Scenario Step time EE testing. Initial round of experiments has resulted in 0.5 seconds time length for step 1, and 3.5 seconds for step 2 (sim-plified experiment). To be further elaborated upon extension of EE develop-ment.

Scenario Step Success Rate EE testing. Depending on the experiment step type may be time length threshold, number of notifications produced per time, etc.

Initial round of experiments has resulted in 100% suc-cess rate in all Advice Re-quest experiment steps.

Time required in order to deploy a FIspace app onto the FIspace Store

The SDK tools that are pro-vided by the T280 team provide the means, as well as the guidelines to upload a new app to the FIspace Store.

The target is <10 minutes, as the process is automated, and will be fully available via the FIspace Studio toolkit for the developers.

Quality Indicators: a. Product life time, b. User Acceptance, c. Quality of notifications (true positives, false posi-tives, etc.)

a) To be further elaboratoed in next report (TBFE) b) Questionnaires c) EE testing

a) TBFE

b) Minimum score 3/5 (5/5 corresponds to max user satisfaction)

c) 98%

Number of FIspace apps created and uploaded on the FIspace Store

n/a 6 apps (5 web-based via FIspace platform and 1 mo-bile app)

Number of different busi-ness entities created in the context of the Greenhouse trial

n/a The main business entity (BE) (which is already de-fined at its first version in-side the platform) is the Greenhouse Advice. An ex-tension of this will be need-

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 26 of 64

Perspective Key Performance Indicator

Means of assessment Value (target or actual result if tested)

ed, as well as a new, addi-tional one for the Product Recall scenario (depending on the SDK tools that will be available from the platform).

Number of stakehold-ers/SMEs/external systems involved in the scenarios

n/a Overall, there are 4 green-houses, 1 meteorological station, 1 traceability plat-form, 2 expert systems and FMIS, and 1 farmer data-base provided by OPEKEPE.

At this point, it must be highlighted that all scenarios, and as a result the respective KPIs, which will be derived during their testing, are heavily dependent on some core components of the FIspace platform. The System and Data Integration, the Event Processing and the Business Collaboration modules are some of the most representative examples. In all scenarios, the external systems, as well the FIspace apps that participate in the scenario steps, connect with each other via interaction with these core com-ponents, thus, the KPIs will rely on the efficiency of the core modules’ functionality as well.

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 27 of 64

2.3 Trial 431 - Fish Distribution and (Re-) Planning

The Fish Distribution Planning Trial is used to demonstrate the capabilities of the collaboration platform to support business processes during the planning of transport, and contributes to improvement in business interaction and collaboration between shippers and carriers. It aims at demonstrating how the combined utilization of the Apps LPA, MOS and CargoSwApp, can facilitate the planning of transport, search for services, booking-related activities for both shippers and carriers, as well as searching for replacement of late booking cancellations.

2.3.1 Trial Team

The Fish Distribution Planning trial is realized by:

MARINTEK Trial lead, trial coordination, building scenario for App test, input and feedback on App development, setting up of stakeholder meetings.

SDZ Open Call partner, developer of the Application "CargoSwApp" (search engine for re-placement cargo in last short window before departure)

NCL North Sea Container Line. Industrial representative, provides data for test, input (user needs) for App development, feedback on demo, argumentation for stakeholder meet-ings.

2.3.2 Report on Trial Progress

The work during the M13-M18 has consisted of:

Development of the App CargoSwApp: requirements, specifications, mock-up, first pro-

totype, tests and updates.

Integration with FIspace and MOS (under progress)

Contact with stakeholder community (Norwegian shippers and carriers) to create en-

gagement and receive feedback on the concept.

Value added for business user: contribution to defining potential value-creation of

FIspace business concept

Dissemination: Trial Brochure, SmartAgrimatics (France), ICTTE conference (Portugal),

ECFI conference (Germany), Stakeholder meeting with Norwegian companies.

The work plan for the remaining period described in D400.3, remains unchanged.

2.3.3 App Development

Status for App development:

CargoSwApp: very good progress, many functionalities implemented, accessible in Wirecloud, testable, data can be stored for demo. Remain some functionalities, technical corrections, and integration into FIspace.

The test scenario, described in D400.3 remains valid. However, a detailed description of each business process to be covered by the different Apps, sequence diagrams, specific scenarios to be used as demonstration, messages between Apps, etc. have been described in an annex document to facilitate communication between all parties.

The figure below shows a summary of the processes to be supported in the Trial, grouped in three main phases of operation.

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 28 of 64

Figure 4: Process supported by the trial

2.3.4 Evaluation of FIspace Services and Initial Apps, and Open Call Apps

The testing done in M13-M18 period focused on verifying whether the Applications support business pro-cesses, how effectively, and whether the integration among the Applications is ensured.

The Experimentation plan has been updated, because the CargoSwApp was able to be tested individu-ally, independently from the integration cargoswapp-MOS. The red circles indicated the tests conducted so far.

Figure 5: Experimentation Plan

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 29 of 64

2.3.4.1 Marketplace Operations Service (MOS)

The Marketplace Operation Service (MOS) version deployed on the WireCloud1 was tested during August

2014, after a first demonstration/feedback round in July. The test and results are summarized below:

Table 8: Marketplace Operation Service

Functionality tested Test result Suggestion for further development

Creation of a new service offer (tested also in M12)

OK the offer is created. Would be great to create a "service provider" user profile, to avoid re-write the same info each time one registers a service (especially for a vessel route consisting of many legs, i.e. many transport services in one voyage)

View available service offers and View details of a specific offer (tested also in M12)

OK We should be able to select the other to send a request for booking.

Textual search for a service offer (tested also in M12)

Not working, does not manage to write text in the field.

(not highest priority)

Possibility to add services with more than one leg

Would be great to be able to enter a schedule, with several ports / dates, or at least duplicate a service to only change one piece of information

More details of the service offers (ETD, ETA, price)

OK

Extended search functionality The functionality "search" is there, but the search is not launched. (no button, no changes)

Only possible for shippers searching for transport services; should be also for carriers (looking for transport de-mand)

Creation of a new service demand Allow the shipper to publish de-mands on the Marketplace

Works, but missing some pieces of data relevant for the CargoSwApp (number of containers)

Integrate the data model with Car-goSwApp

Do matchmaking between service offers and transport demands

To be done and tested by CargoSwApp

1 http://37.131.251.57:9092

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 30 of 64

2.3.4.2 Logistics Planning App (LPA)

The test was not possible within Month 18 because of unavailability of the LPA. To be done in Month 19.

2.3.4.3 Open Call Apps

The fish trial app "Find Cargo Replacement" App (CargoSwApp) has been developed in collaboration between SDZ, MARINTEK, NCL, and tested in several rounds, either through online demos, face-to-face demos, workshops among the partners etc. The CargoSwApp is deployed on the WireCloud

2.

The test and results is summarized below:

Table 9: Open call Apps

BP Task/step/process Testing

6 Carrier registers master data OK

8b Shipper publishes transport demand on marketplace (alt.2) through the CSW

OK. Unnecessary fields will be further removed and distinction between open demands on marketplace and real bookings will be done.

12 Carriers creates and update master schedule OK

14b Carriers updates booking list by importing data from backend system

OK

15b Carriers searches the marketplace (alt.2) through CSW

Not yet connected to MOS. So results of search based on dummy data.

16b,c Carriers sends offer through CSW (to MOS and sms/mail)

OK

19b Shipper checks current booking situation and cancel / change booking through CSW

OK, but need to separate what is a demand published on the marketplace, and what is a confirmed booking re-ceived from a specific carrier.

21 Carrier checks current bookings situation OK.

22 Carriers – treatment of pending reservations Under development

23 Carriers - early anticipation of cancellations Probabilities are dummy data for the moment (the system needs historic data)

24b Carriers receives cancellation of booking – status appears as deleted

Under development

25 Carriers asks for reason of cancellation and provide possibility to rebook on a later departure.

Not implemented yet – not tested

26 Carriers searches for cargo replacement (of one specific cancellation) on MOS using search engine and filter on CSW

OK

27 Carrier loads vessel capacity utilization chart OK.

28 Carriers searches for cargo to fill up available capac-ity – optimization of capacity utilization taking into account the different legs of the vessel's route

Under development

Plan for next test round: upload all data for setting-up scenarios and tests specific scenarios. Main focus will be on checking interaction MOS-CargoSwApp, and the functionality for increasing capacity utilization (nr 28).

2 http://176.9.164.3/cargoswapp/

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 31 of 64

2.3.4.4 System and Data Integration (T250)

Necessary integrations for conducting the trial:

Integration CargoSwApp-FIspace: Ongoing, in collaboration with WP200.

Integration MOS-CargoSwApp: under progress. REST API communication.

Integration CargoSwApp-back-end system Softship. This is handled through excel file exchange.

2.3.5 Balanced Scorecard

BSC introduced in D400.3 presented KPIs for evaluating booking performance (6 KPIs), operational costs for carriers (2 KPIs), values for transport users (5 KPIs), and vessel utilization (3 KPIs). Updates are the following:

"Repl.App" is now called CargoSwApp.

The functionality originally offered by the foreseen "ProbApp" is uncertain to be deployed, but the

related KPIs are still valid.

2.3.6 Key Performance Indicator

Provided that a marketplace exists, giving access to information as foreseen in the FIsh Distribution Plan-ning trial, the following estimations have been made about the Booking Performance (one of the area of performance evaluation).

The evaluation made is a calculation of potential improvement, using the example of one voyage (vessel of 350 TEUs), based on information from the container shipping operator NCL and first use of the Car-goSwApp.

The operational costs estimated in the example correspond to the time used by one person to conduct planning operations, i.e. receiving requests for shipment booking, registering bookings, changes and can-cellations, and looking for replacement of cancellations.

The to-be operational performance is expected to at least equal that of the current cases using EDI-messages.

The following estimations of as-is and to-be performance are made:

Operation As-is To-be

Registration of booking 5min / booking + 1 min / container 2 min / booking + 40 sec / container

Change in booking 3 min / booking 1 min / booking

Cancellation 1 min / booking 20 sec / booking

These are rough figures, but realistic, based on NCL's business experience, and aims at providing an indication of the potential amount of savings.

Potential improvements (Potential savings for handling bookings / changes / cancellations) in operational performance (in hours) are given below:

Scope of operations Savings in hours

One vessel, one voyage 14,5 hours

One vessel, one year (52 voyages) 754 hours

5 vessels, one year 3770 hours

The table above provides a simple overview of the potential savings in planning costs for handling book-ings, changes and cancellations. In addition to this comes the potential savings in resources for searching for cargo replacement, as well as the potential amount of replacement reachable in the short time window before departure, enabled by a shorter lead time to find cargo.

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 32 of 64

2.4 Trial 432 – Fresh Fruits and Vegetables

2.4.1 Trial Team

The Fresh Fruits and Vegetables Trial will be realized by:

CentMa: Trial lead

Europool: Trial stakeholder integrator

ATB Technology and Development partner “Initial App PIA”

GS1 Systempartner

Snoopmedia, Fraunhofer: Developmentpartner Apps “BOXMAN”, “RISKMAN”

2.4.2 Report on Trial Progress

During the last period, the trial focused on the development of the three Apps that were identified as cru-cial for efficiency and transparency in the FFV trial, the Apps PIA, BOXMAN, and RISKMAN. For clarifica-tion: for a comprehensive coverage of needs the FFV trial Apps are being complemented by the Apps developed in the Flower and Plants trial.

The App PIA is identified within FIspace as an initial App that is suitable to serve needs in other trials as well. It is continuously improved and further developed by the project partner ATB. While it was prepared for presentation to stakeholders some months ago, it was integrated during the last period with FIspace platform developments.

The Apps BOXMAN and RISKMAN are to be developed by the open call partners Fraunhofer and snoopmedia. These new partners started development during the past period. With this report they have reached the envisaged prototype status.

2.4.3 App Development.

The App developments were taking place on close interaction with the platform development groups to assure platform compatibility. Initial integration with the FIspace platform had already been reached for the initial App PIA by the time of the project review. The developers of the new Apps BOXMAN and RISKMAN were integrated into regular telco-exchanges with the FIspace platform development group.

During the period, all three development groups were participating in face-to-face meetings with stake-holders of their target group to assure fitting functionalities and to keep communication with stakeholders open. Furthermore new core stakeholders were integrated in the process.

In August, the trial lead and the stakeholder integrator evaluated the present status of the various Apps and confirmed that all three had reached their goals. The evaluations were based on performance checks that were linked with the KPIs that could be tested within a prototype environment.

For further support of App developments and harmonization, all App development groups join with other trial partners in bi-weekly telcos organized by Atos. Partners in the FFV trial organize regular follow-up telcos for dealing with specific trial issues.

2.4.4 Balanced Scorecards

The Balanced Scorecards related to the main stakeholders in the FFV chain were published in deliverable 400.3. have not been changed in light of the new App developments that were initiated by the open calls. They provide the basis and guidance for the App development by open call partners. The open call part-ners have been visiting selected stakeholders linked to the various scorecards at the initial development process. The scorecards display perspectives, objectives (representing the key performance indicators), measures, targets, and activities.

The actual scorecards do not only outline perspectives and KPIs that could be linked to experimental studies around system prototypes but also perspectives and KPIs that are only relevant for systems in operational use. The elements of the scorecards that are relevant for the ongoing development and eval-uation of prototypes are again summarized in the tables 10-12 below.

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 33 of 64

RTI provider. The reduced scorecard linked to the RTI provider (see following table) is primarily based on the App BOXMAN which is being developed by the open call partner Fraunhofer. Investment in BOX-MAN would be by the RTI provider who would be the prime beneficiary. However, he is offering it as ser-vice to his trading partners who in turn would be the secondary beneficiaries as outlined in the respective scorecards of traders and retail.

Table 10: Reduced scorecard of RTI Service Provider with relevance for prototype evaluation

Perspective Objective Measure Target Activity

> Process perspective (info collection)

Reduction in pro-cess time

Min./process cy-cle/customer

- 50% Investment in BOXMAN (automation of process)

> Customer perspective

Reduction in pro-cess time by cus-tomers (offer)

Min./process cy-cle at customers

- 50% Provision of BOXMAN to customers for facilitating data input (automation)

Reduction in input errors by customers (time saving)

Errors/cust./ pro-cess cycle

- 30% Provision of BOXMAN to customer (automation)

Trader. The reduced scorecard linked to the trader (see following table) is primarily based on investments in two Apps, the initial App PIA (Product Information) which is being developed by the project partner ATB and the App RISKMAN which is being developed by the open call partner snoopmedia. The App PIA uti-lized by the trader employs some trader specifics (PIA-trader) and is supposed to link up with the App PIA invested in and used by retail which has its own specifics (PIA-retail). The variation in Apps is also rele-vant for the App RISKMAN which the trader uses (RISKMAN-trader) and which is to be distinguished from the App RISKMAN supposed to be used by retail (RISKMAN-retail). As an example, differences in RISKMAN concern the number of quality profiles to be considered. The trader has to consider various quality profiles depending on the quality requirements of his retail customers whereas the retailer just considers his own profile.

Table 11: Reduced scorecard of trader with relevance for prototype evaluation

Perspective Objective Measure Target Activity

> Process perspective

Reduction in crate mgmt process time

Min./process cycle

- 50% Utilizing BOXMAN provided by box service (automation)

Better information about products

No of info items /delivery

+ 50% Investment in PIA-System

Better information about production status at farms (better marketing opportunities)

No of status re-ports per custom-er

+100% Investment in PIA-System

Better early warn-ing capability on deficiencies in products

Time for inform-ing customers

- 50% Investment in RISKMAN

Retailer. The scorecard linked to the retailer is primarily based on investments in the initial App PIA (in its version PIA-retail) developed by the project partner ATB and the App RISKMAN (in its version RISKMAN-

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 34 of 64

retail) developed by the open call partner snoopmedia. It relates in this respect very much to the score-card of the trader.

As a consequence, the two Apps PIA (in its two versions related to trade and retail) and RISKMAN (in its two versions related to trade and retail) are together of core relevance for the food chain actors in the Fresh Fruits and Vegetables chain.

For a further discussion of the scorecards we refer to deliverable D400.3.

Table 12: Reduced scorecard of retail with relevance for prototype evaluation

Perspective Objective Measure Target Activity

> Process perspective

Reduction in crate mgmt process time

Min./process cycle

- 50% Utilizing BOXMAN provided by box service (automiza-tion)

Better information about products (risk reduction)

No of info items /delivery

+ 50% Investment in PIA-System

Better information about production status at farms (better purchasing opportuni-ties)

No of status reports per customer

+100% Investment in PIA-System

Better early warning capability on deficien-cies in products

Number of cases where deficient products reach consumers

- 50% Investment in RISKMAN

2.4.5 Key Performance Indicator

As already discussed and based on the discussions in deliverable 400.3 the FFV chain distinguishes between KPIs that can be tested in an experimental setting and KPIs which are promises for the future and can only be analyzed after systems have been implemented and utilized by stakeholders over a peri-od of time. It needs to be mentioned that the most relevant KPIs are of the second type. In other words, the cost/benefit for stakeholders related to the first type of KPIs is limited whereas the cost/benefit of KPIs of the second type are of competitive value. Engagement of stakeholders in the trials and continuous interaction with them supports their motivation to believing in the cost/benefit potential of system imple-mentations.

The KPIs that could be dealt with in an experimental setting have been summarized for each stakeholder in the tables of the preceding chapter. However, to be suitable for experimental studies they are being linked to the various App developments. Within this group two types of experimental analysis are of rele-vance:

1. Performance check of required functionalities

2. Efficiency check

Performance checks of required functionalities are based on interaction with stakeholders who have to confirm the Apps’ performance in coping with the management deficiencies they were developed for. Performance checks are based on scenario simulation.

Efficiency measurements can be dealt with in computer based simulation experiments. As the experi-ments are based on prototypes and not on actual operational systems, efficiency experiments are not perfect but they provide an indication on the efficiency potential.

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 35 of 64

Table 13: KPIs with experimental potential related to the various Apps

KPI Measure Target Checks

BOXMAN

Reduction in process time at RTI provider Min./process cy-cle/customer

- 50% EC

Reduction in process time by trader and retail Min./process cycle at cus-tomers

- 50% EC

Reduction in input errors by trader and retail (time saving)

Errors/ process cycle - 30% PC

PIA

Better information about products for trader and retailer

No of info items /delivery + 50% PC

Better information about production status at farms for trader (better marketing opportunities) and retailer (better purchasing opportunities)

No of status reports per customer

+100% PC

Riskman

Better early warning capability on deficiencies in products for trader

Time for informing cus-tomers

- 50% PC

Better early warning capability on deficiencies in products at retail

Number of cases where deficient products reach consumers

- 50% PC

1 EC: Efficiency check; PC: Performance check

During the past period, the performance checks were performed with the exception of the KPI “Reduction in input errors…”. As the prototype systems did not yet have functionalities in place that would correct or dismiss input errors, the only conclusion that can be drawn is based on the fact that the final versions of the Apps will process data that came in and are being communicated further through electronic data transfers eliminating manual interference.

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 36 of 64

2.5 T433 Flowers & Plants Supply Chain Monitoring

2.5.1 Trial Team

Lead: DLO

Participants: Floricode, GS1 G, M&A

2.5.2 Brief description about the test scenario.

After the bankruptcy of the former business stakeholder, a new chain of orchid producing and trading companies are found to participate in the chain: Ter Laak Orchids, member of the grower Union Deco-rum, the flower auction Flora Holland, the wholesaler Vida Verde and a customer of Vida Verde. Currently the intended apps are in development. The first release of the first apps are envisaged in October 2014. Than the test will start by application of the apps in the chain, collecting data about logistics tracking and tracing, environmental conditions affecting product quality and product quality itself. The results will be used for improvement of the apps and development of the quality alert app and quality prediction decay app.

2.5.2.1 Implemented Features

The combination of events and objects (figure 6.4) shows that the trolley is an accurate indicator for the location of the products, since plants or trays are not removed from it. This is true for most activities in the supply chain. Exceptions include:

Picked plants placed in plant tray: this represents the aggregation of individual plants on a tray. It is relevant to record this because the redistribution over retail-specific CC-trolleys is done at tray level, but the plants are (also) sold individually at the retail store.

Plant tray placed on CC-trolley; here the aggregation is recorded of trays on the trolley, so that events that occur at trolley level further down the supply chain can be associated with the trays on it.

Plant trays redistributed over retail CC-trolleys; here the CC-trolleys that represent the shelves at the retail stores are build up from CC-trolleys from the different growers. Trays with plants are taken from the grower CC-trolleys and placed on specific retail CC-trolleys. The association of the trays with the trolleys has to be re-established.

Potted plants removed from shop; to be able to track the sales of potted plants, the plants have to be equipped individually with unique identifiers and be scanned when it passes the cash register (bar-code, QR-code or RFID tag). When plants are removed from the shop because of quality problems, this can be done at tray level. (This activity will probably be left out of scope.)

CC-trolleys placed in Conditioned container; this represents an aggregation event of CC-trolleys on the conditioned container. During road transport the events that are relevant for the container can be

extended to the CC-trolleys, trays and plants it contains.

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 37 of 64

Figure 6. Overview of events and objects in the flowers and plants supply chain.

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 38 of 64

2.5.3 Test results, challenges, recommendations and advises for the project team

Since no test results can be reported yet, the challenge is to use the remaining time to experiment inten-sively in order to get feedback on the apps in order to improve them and to serve as a successful basis for further rollout in phase 3. The market in ornamental products is asking for those developments.

2.5.4 Balanced Scorecard Approach Flowers & Plants trial

Vision: Quality control + increased efficiency >> saving money

Stakeholders: Grower, logistic service provider, auction, trader, retail

Understanding: Increased quality control enhances customer satisfaction throughout the whole chain

Perspectives for improvements: Processes <> employees <> customers (market) >> Finances

2.5.5 Balanced Scorecard & Key Performance Indicators

No results to be reported.

2.6 Trial 441 – Meat Information Provenance (MIP)

2.6.1 Trial Team

The Meat Information Provenance Trial will be realised by:

Wageningen University (trial lead)

GS1 Germany (standards, EPCIS and meat supply chain processes)

European EPC Competence Center (apps/software based on EPCIS)

2.6.2 Report on Trial Progress

In the period M13-M18 of FIspace the MIP trial has spent substantial effort to developing apps that are needed to implement an EPCIS based transparency system. This system will form the test-bed for the MIP experiments on meat tracking and tracing with emphasis on beef. Since April 1 2014 the MIP trial has a new partner, the European EPC Competence Center (EECC). EECC entered FIspace through the open call and substantial effort has been spent to integrate the new partner into the MIP trial. EECC will implement one or more EPCIS repositories and develop the three major apps that add functionality to the meat transparency system.

During the report period the MIP trial team worked on realising the transparency system for meat supply chains consisting of a series of apps and of one or more EPCIS repository implementations The meat transparency system is further detailed in section 2.6.3.

The MIP trial raised awareness for it at several occasions including the GIL Conference 2014 in Bonn, Germany, the SmartAgriMatics Conference 2014 in Paris, France and the European Conference on the Future Internet in Munich. Furthermore we will present the MIP trial at EURID (International Exhibition and Conference for Identification) in Frankfurt (Germany) later this year.

2.6.3 App Development

The development of the meat transparency system started after entering of EECC into the MIP trial through the open call. The first part consisted of realizing one or more EPCIS repositories, which are based on Frequenz’s (http://frequentz.com/traceability-server/) Information Repository & Intelligence Server (IRIS), one of only a few EPCIS implementations that can handle the new EPCIS standard 1.1 (released in spring 2014).

Next to this data infrastructure with functional interfaces for capturing and querying events, a series of tools has been developed by the new open call MIP trial partner, European EPC Competence Center, in

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 39 of 64

collaboration with the other partners GS1 Germany and Wageningen University, consisting of the follow-ing items:

1. Farm Capturing App: a simple web-page-like app to enable farmers to copy animal passport data (and more) as EPCIS events and master data on other aspects to an EPCIS repository;

2. Query app: the requirements for this app are described in deliverable D400.14. Meat Transparency System App for Querying a specific EPCIS repository.

3. Discovery app: the requirements for this app are described in deliverable D400.14. Meat Transparen-cy System App for discovering data sources (EPCIS repositories) containing information about specif-ic products.

4. Aggregating app: the requirements for this app are described in deliverable D400.14. Meat Transpar-ency System App for aggregating traceability information.

In the reporting period 1st releases of these apps have been realized and their functionality has been test-

ed at a technical level.

A fifth app, the consumer app will be co-designed in collaboration with FIspace’s Tailored Information for Consumers (TIC) trial. This collaboration can build on previous experiences in FI-PPP phase 1 project SmartAgriFood.

2.6.4 Balanced Scorecard

As the MIP Transparency System aims to serve three classes of end-users (consumers, supply chain partners and authorities/regulators) the MIP trial objectives can be made explicit by specifying an adapted balanced scorecard), which will be translated in KPIs in).

Table 14. Balanced Scorecard of the MIP trial

# subjective objective measure target activity

1 all user types real-time information on meat items

fast, ubiquitous and real-time access to all events along meat supply chains

realised in experi-ments

realisation of the MIP Transpar-ency System

2 authorities surgical response to meat crises

fast access to loca-tions of suspected meat items

within one hour Discovery App in combination with the MIP Transparency System

3 authorities one single point to get access to the information

prepared data at discovery service server

always available (but in practice it will be updated once or twice a day)

Discovery App in combination with the MIP Transparency System

4 authorities completeness of meat related data for proper analysis

checks on com-pleteness of these data

realised in experi-ments

running experiments with the MIP Transparency System

5 farmer integrate farmers to the chain of infor-mation

affordable infrastruc-ture and know-how

cheaper than € 1.000 Farm Capturing App in combina-tion with the MIP Transparency System

6 farmer provide data very easily to the trans-parency system

usable web-form to provide data, ac-cording existing rules

100% content from cow pass (EC1760/2000)

Farm Capturing App in combina-tion with the MIP Transparency System

7 farmer direct communication with consumers

consumer interview yes, if this can help me to get better food

Farm Capturing App in combina-tion with the MIP Transparency System and the Consumer App; farmer should provide email address and/or social media URL

8 meat proces-sors

not high investment, but based on existing systems (ERP)

affordable infrastruc-ture and know-how

cheaper than € 5.000 Enabling meat processor's ERP system to upload data to an EPCIS repository

9 meat proces-sors

more than one step back and one step forward information

testing potential steps forward and backward in SC

3 companies in total in half an hour

Query App in combination with the MIP Transparency System

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 40 of 64

# subjective objective measure target activity

10 meat proces-sors

direct communication with consumers

consumer interview yes, if this can help me to get better food

Capturing data with ERP or otherwise in combination with MIP Transparency System and the Consumer App; meat pro-cessor should provide email address and/or social media URL

11 retailer batch based origin of a specific piece of meat can be shown to consumers

consumers' attitude on acceptance and turnover plus for retailers

degree of acceptance by clients and turno-ver raise few percent for the retailer

Convincing retailers on business case and implementing the MIP Transparency System

12 consumer most relevant infor-mation on the piece of meat

display of dynamic and static infor-mation on a piece of meat

minimum set of prov-enance plus 3 user required information items

Consumer App in combination with the MIP Transparency System

13 consumer tailored information on the piece of meat

user interview good or better Consumer App in combination with the MIP Transparency System

14 consumer ease of use, e.g. smartphone, WWW

user interview good or better Consumer App in combination with the MIP Transparency System

15 consumer promptness of infor-mation on the piece of meat

time of output 5 sec and realised in experiments

Consumer App in combination with the MIP Transparency System

2.6.5 Key Performance Indicator

The MIP trial has planned 3 different series of experiments. In the first set of experiments (also referred to as the simulation experiment, starting in the autumn of 2014, the first release of all apps will be tested for beef, without the Consumer App that will be developed by the TIC trial. The emphasis will be on correct functioning of the apps and what has to be changed according to the test perceptions of (potential) end-users.

In the second set of experiments (also referred to as realistic experiments) the whole integrated MIP Transparency System will be tested for beef. This includes but is not restricted to (1) tracing of the beef history for consumers by using the MIP Transparency System and the TIC Consumer App, (2) tracking and tracing of the whole supply chain for beef supply chain partners (bi-directional with simple and more complex queries concerning data for which they have authorization to see) and (3) simulating meat alerts for beef and associated functionalities and how authorities/regulators can use it.

A recent opportunity appeared from contacts with interested parties that are affiliated with authori-ties/regulators (e.g. UN/CEFACT). In collaboration with these parties a third set of experiments can per-haps be performed with the MIP Transparency System for other types of meat, i.e. pork in the Nether-lands and poultry (chicken, duck and goose) in France. If realized it can be seen as a final validation of the MIP Transparency System.

From the Balanced Scorecard (section) Key Performance Indicators are derived and summarized in As the MIP Transparency System aims to serve three classes of end-users (consumers, supply chain part-ners and authorities/regulators) the KPIs are also specified for these three subjectives. The category sup-ply chain partners is further decomposed into farmers, meat processors and retailers, as these have largely different perspectives too.

Table 15. Key Performance Indicators of the MIP trial. The numbers (#) refer to the coinciding rows of the balanced scorecard:

# subjective kpi explanation result unit

1 all user types

access to events fast access to events h:m:s

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 41 of 64

# subjective kpi explanation result unit

2 authorities found locations of suspected meat items

all locations should be found

3 authorities measured time lag meat crisis time to find all suspected meat

h:m:s

4 authorities completeness of information all information that is re-quired, is provided

yes/no/partly

5 farmer integration farmer farmers have access and can provide all event related information

yes/no/partly

6 farmer easy entering cattle data in epcis re-pository

farmers can provide all event related information

< € 1000

7 farmer direct communication with consumer farmers that want response from consumers can get it

qualitatively

8 meat pro-cessors

integrating meat processors meat processors have ac-cess to provide data at rea-sonable costs

< € 5000

9 meat pro-cessors

access to all relevant information (whole supply chain)

meat processors have ac-cess to all data that is con-nected to the meat they processed (from farm to retailer)

yes/no/partly

10 meat pro-cessors

direct communication with consumer meat processors that want response from consumers can get it

qualitatively

11 retailer communicate origin of batch to con-sumer

retailer should be enabled to communicate the origin of all their consumer meat products to their customers

yes/no/partly

12 consumer consumer app provides complete in-formation

consumers should get ac-cess to meat related infor-mation with their smart phone and a product label

yes/no/partly

13 consumer consumer app provides tailored infor-mation

information for consumers should be filetered accord-ing to the preferences

qualitatively

14 consumer consumer app is easy to use consumers should get ac-cess to meat related infor-mation on an easy way

qualitatively

15 consumer consumer app is fast consumers should get fast access to meat related in-formation

h:m:s

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 42 of 64

2.7 Trial 442 - Import and Export of Consumer Goods

2.7.1 Trial Team

Lead: Arcelik

Participants: Kühne+Nagel AG & Open call partner FINCONS

2.7.2 Report on Trial Progress

Trial has focused on the evaluation of domain specific apps that are being developed by the opencall partner FINCONS, namely:

T442-1: Transport Demand App (TD App)

T442-2: Shipment Status App (SS App)

T442-3: Manual Event & Deviation Reporting App (MEDR App)

Due to the synergies and similarities between SS App and MEDR App, both in terms of business logic and UI component, it has been decided to combine the two apps into a single app that will provide all the requested functionalities. The interaction with the apps and FIspace is depicted in the figure below:

Figure 7. Interaction of the Apps and FIspace

The main activities performed during the last six months for the evaluation are listed below:

Functional requirements were finalized:

Functional requirements with details (actor, process, input data, output data etc.) except the inter-faces with LPA and EPM.

User right management (role of each actor and their rights) definition

Parameter specifications

Initial prototypes were prepared and partially tested.

The visual presentations of the prototypes by FINCONS.

Real life testing of prototypes on 24/07 during a face-to-face meeting in Milan.

FINCONS has also provided real-life links to the prototypes; however the validation is currently being made in an interval server and FINCONS is working on solutions to make it reachable from other servers.

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 43 of 64

Feedbacks & updates on the prototypes and their functions.

Data collection for the test scenario and continuous checks about the applicability of the data to the domain specific apps.

Alignment with LPA app development (ARC, KOC & FINCONS):

Several telcos are held in order to discuss and agree on the relationship between use case trial apps & LPA and also to clarify app outbound integrations. An internal mapping document has been prepared for each functional steps in order to report the interface, I/O parameters and logical evaluation

A telco with IBM & KOCSISTEM and FINCONS in order to clarify the relationship between EPM, Shipment Status app and LPA. FINCONS is currently working on the EPM solution in order to imple-ment the event management/ event Interfaces.

FINCONS is currently working on the connection with the backend and interfaces with external apps & services.

2.7.3 App Development

14 different scenarios have been identified for testing the app functionalities:

Table 16. App development Scenarios

Scenario Scenario Related Apps

1 User Authentication Shipment Status Mobile App ManualEvent&Deviation Reporting Feature

2 User Authorization Shipment Status Mobile App ManualEvent&Deviation Reporting Feature

3 Shipment Search Transport Execution Plan

Shipment Status Mobile App ManualEvent&Deviation Reporting Feature

4 Status and Event Monitoring, Map Service Shipment Status Mobile App ManualEvent&Deviation Reporting Feature

5 CheckPoint Details Shipment Status Mobile App ManualEvent&Deviation Reporting Feature

6 Re-Planning Shipment Status Mobile App

7 Real-time Notification Shipment Status Mobile App ManualEvent&Deviation Reporting Feature

8 Shipment Notification Management Shipment Status Mobile App

9 Report Event or Deviation ManualEvent&Deviation Reporting Feature

10 Check In & Check Out ManualEvent&Deviation Reporting Feature

11 Create Transport Demand Transport Demand Web App

12 Transport Demand Search Transport Demand Web App

13 Request Shipment Details Transport Demand Web App

14 Submission to LPA Transport Demand Web App

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 44 of 64

2.7.3.1 Scenario - User Authentication

Below table summarizes the scenario and its current status for user authentication during user login.

Table 17. Scenario – User Authentication

# Scenario steps Actor Source / System

Data sent to (System)

Status of the Implementation

1 Tap the application and add User and Password

SS App SS App Back End SDI

Login function is available in the demo but interaction with SDI is

not currently implemented.

2 The system will return the transport demand list/shipment List

SS App Back End SS App Currently implemented.

2.7.3.2 Scenario- User Authorization

Below table summarizes the scenario and its current status for user authorization during user login.

Table 18. Scenario – User Authorization

# Scenario steps Actor Source / System

Data sent to (System)

Status of the Implementation

1 Access to Back End with User and Password (Ad-min role)

Back End

Back End Back End Interaction with backend is not currently implemented since SDI interaction is not available.

2 Define the role Grant Back End

Back End Back End The roles are defined but this functionality was not present in the demo (interaction with an external system not available)

2.7.3.3 Scenario- Shipment Search

This functionality enables the user to search for the shipment of interest using the filtering parameters that are defined. The scenario and its current status is explained in the table below:

Table 19. Scenario – Shipment search

# Scenario steps Actor Source / System

Data sent to (System)

Status of the Implementa-tion

1 Login scenario SS App Back End SDI

Back End SDI

Functionality is present but not connected to the backend.

2 In “Shipment List View” tap on search icon on content menu

SS App SS App Currently not available

3 The SS App returns the search form with the following info: - Shipment Code - Shipment Status - Shipment Date (Inter-val) - Departure Location - Pickup Location - Receiver

SS App SS App Currently not available

4 Click on Ok SS App SS App Back End Currently not available

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 45 of 64

# Scenario steps Actor Source / System

Data sent to (System)

Status of the Implementa-tion

5 The SS App returns the selected shipment in the shipment List with the following details: - Shipment Code - Shipment Date - Shipment Status - Departure Location - Pickup Location - Receiver

SS App Back End SS App Available but only in the front end. Connection with LPA cur-rently not available.

6 Tap on Shipment SS App SS App Back End Available

7 Visualize the Shipment Details View Section 1

Shipment and Transport Demand Details Section 2

Checkpoint List Section 3

Replanning & Notification

Button Tab - OrderItem List

SS App LPA

SS App

Back End Tab order items list not cur-rently implemented.

2.7.3.4 Scenario - Status and Event Monitoring, Map Service

The user can tap on Map icon in order to visualize the status of the checkpoints on the map. The scenario and its current status is explained in the table below:

Table 20. Scenario - Status and Event Monitoring, Map Service

# Scenario steps Actor Source / System

Data sent to (System)

Status of the Implementa-tion

1 Login scenario SS App Back End SDI

Back End SDI

As in scenario “User Authenti-cation“ and “User Authoriza-tion“

2 Shipment Search Scenario SS App SS App Back End

Back End As in scenario “Shipment Search”

3 Tap on Map Icon SS App LPA

SS App

Back End Currently present but connec-

tion to LPA is not available.

4 Visualize the Transport Map with coloured Check-points

SS App LPA

SS App

Back End Currently present but connec-tion to backend not available. The integration with LPA cur-rently not available hence this feature is simulated in the demo.

5 Tap on CheckPoint SS App Back End SS App Currently present but connec-

tion to backend not available.

6 Tap on Cloud image SS App Back End SS App Currently present but connec-tion to backend not available.

7 Visualize the CheckPoint Details

SS App Back End SS App Currently present but connec-tion to backend not available.

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 46 of 64

2.7.4 Scenario-Check Point Details

The user can tap on each pin in order to visualize the checkpoint details. The scenario and its current status is explained in the table below:

Table 21. Scenario – Check Point Details.

# Scenario steps Actor Source / System

Data sent to (System)

Status of the Implementa-tion

1 Login scenario SS App Back End SDI

Back End SDI

As in scenario “User Authen-tication“ and “User Authoriza-tion“

2 In Shipment List View tap on Search icon on Content Menu

SS App SS App As in scenario “Shipment Search”

3 The SS App returns the search form with the fol-lowing info: - Shipment Code - Shipment Date (Interval)

- Shipment Status - Departure Location - Pickup Location - Receiver

SS App LPA

SS App

This feature is simulated in the demo.

4 Click on Ok SS App SS App Back End Available but not integrated with backend.

5 The SS App returns the

selected shipment in the shipment List with the following details: - Shipment Code - Shipment Date - Shipment Status - Departure Location - Pickup Location - Receiver

SS App Back End SS App Available but not integrated

with backend.

6 Tap on Shipment SS App SS App Back End Available but not integrated

with backend.

7 Visualize the Shipment Details View Section 1

Shipment and Transport Demand Details Section 2

Checkpoint List Section 3

Replanning & Notification

Button

SS App LPA

SS App

Back End Available but not integrated with backend.

8 Tap on a CheckPoint SS App LPA

SS App

Back End Available but not integrated with backend.

9 Visualize the CheckPoint Detail View

SS App Back End SS App Available but not integrated with backend.

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 47 of 64

2.7.4.1 Scenario- Replanning

From the “Shipment Detail View” the user can tap on replanning button in order to request a new Plan from LPA. The scenario and its current status is explained in the table below:

Table 22: Scenario - Replanning

# Scenario steps Actor Source / System

Data sent to (System)

Status of the Implementa-tion

1 Login scenario SS App Back End SDI

Back End SDI

As in scenario “User Authentica-tion“ and “User Authorization“

2 Shipment Search Scenario SS App SS App Back End

Back End As in scenario “Shipment Search”

3 According the checkpoint Status the user can tap on Replanning Button

SS App SS App LPA The integration with LPA cur-rently not implemented.

4 In the Shipment Details view the status is changed

in Replanning Requested

SS App Back End SS App It is available in the demo.

2.7.4.2 Scenario- Real-time Notification

The user can manage the notification associated to each checkpoint. The scenario and its current status is explained in the table below:

Table 23: Scenario – Real-time Notification

# Scenario steps Actor Source / System

Data sent to (System)

Status of the Implementation

1 Login scenario SS App Back End SDI

Back End SDI

As in scenario “User Authentica-tion“ and “User Authorization“

2 Shipment Search Scenario SS App SS App Back End

Back End As in scenario “Shipment Search”

3 According the checkpoint Status the user can tap on Notification Button

SS App SS App Back End Available only in the front end. Backend integration is still in progress.

4 SS app returns the Notifi-cation Screen with the CheckPoint List with their status

SS App SS App Back End

EPM

Available only in the front end. Backend integration is still in progress.

5 Tap on CheckPoint SS App SS App Back End Available only in the front end. Backend integration is still in progress.

6 The Notification Setting view and add the details

SS App SS App Back End

EPM

Available only in the front end. Backend integration is still in progress.

7 Save it and verify in the Checkpoint Details the Notification value

SS App SS App Back End

EPM

Interaction with EPM still ongo-ing.

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 48 of 64

2.7.4.3 Scenario- Shipment Notification Management

The user will choose the event from a defined list and the notification type for each checkpoint. The sce-nario and its current status is explained in the table below:

Table 24: Scenario- Shipment Notification Management

# Scenario steps Actor Source / System

Data sent to (System)

Status of the Implementation

1 Login scenario SS App Back End SDI

Back End SDI

As in scenario “User Authentica-tion“ and “User Authorization“

2 Shipment Search Scenario SS App SS App Back End

Back End As in scenario “Shipment Search”

3 Tap on Notification Button SS App SS App Back End Currently only available in the front end.

4 SS app returns the Notifi-cation Screen with the CheckPoint List with their

status

SS App SS App Back End Currently only available in the front end.

5 Tap on CheckPoint SS App SS App Back End Currently only available in the front end.

6 The Notification Setting view and modify the de-tails or remove the notifi-cation

SS App SS App Back End

EPM

Currently only available in the front end.

7 Save it and verify in the Checkpoint Details the Notification value

SS App SS App Back End

EPM

interaction with EPM still ongoing.

2.7.4.4 Scenario-Report Event or Deviation

User with specific privileges will be able to report relevant events and deviations from the original delivery plan for a specific shipment during the execution phase of the shipment. The scenario and its current status is explained in the table below:

Table 25: Scenario-Report Event or Deviation

# Scenario steps Actor Source / System

Data sent to (System)

Status of the Implementation

1 Login scenario SS App Back End SDI

Back End SDI

As in scenario “User Authentica-tion“ and “User Authorization“

2 Shipment Search Scenar-io

SS App SS App Back End

Back End As in scenario “Shipment Search”

3 SS App returns the search form with the

following info: - Shipment Code - Shipment Date - Shipment Status - Departure Location - Pickup Location - Receiver

SS App SS App Back End Currently not available

4 Click on Ok SS App SS App Back End Currently not available

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 49 of 64

# Scenario steps Actor Source / System

Data sent to (System)

Status of the Implementation

5 SS App returns the se-lected shipment in the shipment List with the following details: - Shipment Code - Shipment Date - Shipment Status - Departure Location - Pickup Location - Receiver

SS App Back End SS App

LPA

Currently available in the front end.

6 Tap on Shipment SS App SS App Back End Currently available in the front end.

7 Visualize the Shipment Details View Section 1

Shipment Details

Section 2

Checkpoint List Section 3

Report Event/Deviation/CheckIN/CheckOut Buttons

SS App SS App SS App

LPA

Currently available in the front end.

8 Tap on Report Event Button

SS App SS App Back End

LPA

Currently available in the front end.

9 Tap on a Report Devia-tion

SS App SS App Back End

LPA

Currently available in the front end.

2.7.4.5 Scenario- Check In & Check Out

When the user starts the process with the associated check point, he chooses the checkpoint and check in. When the user have completed all activities associated to a specific checkpoint, he can tap the check out button. In this case the checkpoint status will change from “Not Passed” to “Passed”. The scenario and its current status is explained in the table below:

Table 26: Scenario- Check In & Check Out

# Scenario steps Actor Source / System

Data sent to (System)

Status of the Implementation

1 Login scenario SS App Back End SDI

Back End SDI

As in scenario “User Authentica-tion“ and “User Authorization“

2 Shipment Search Scenar-io

SS App SS App Back End

Back End As in scenario “Shipment Search”

3 SS App returns the search form with the following info: - Shipment Code - Shipment Date - Shipment Status

- Departure Location - Pickup Location - Receiver

SS App SS App Back End Currently not available

4 Click on Ok SS App SS App Back End Currently not available

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 50 of 64

# Scenario steps Actor Source / System

Data sent to (System)

Status of the Implementation

5 SS App returns the se-lected shipment in the shipment List with the following details: - Shipment Code - Shipment Date - Shipment Status - Departure Location - Pickup Location - Receiver

SS App Back End

LPA

SS App Available only in the front end.

6 Tap on Shipment SS App SS App Back End Available only in the front end.

7 Visualize the Shipment Details View Section 1

Shipment Details Section 2

Checkpoint List Section 3

Report Event/Deviation/CheckIN

/CheckOut Buttons

SS App SS App

LPA

Back End

Available only in the front end.

8 Tap on CheckIN Button SS App SS App Back End

LPA

Available only in the front end.

9 Tap on CheckOut Button SS App SS App Back End

LPA

Available only in the front end.

2.7.4.6 Scenario- Create Transport Demand

The user with specific privileges will be able to create a new transport demand in a dedicated form. The scenario and its current status is explained in the table below:

Table 27: Scenario- Create Transport Demand

# Scenario steps Actor Source / System

Data sent to (System)

Status of the Implementation

1 Login Production Planner Logistics

Responsible Supplier

TD App SPT System As in scenario “User Au-thentication“ and “User Authorization“

2 Visualize Homepage Production Planner Logistics Responsible Supplier

TD App Backend Available in the frontend.

3 Import Sap Order Production

Planner

TD App Backend Currently not available.

4 Create a new Transport Demand

Production Planner

TD App Backend Available in the frontend.

5 Selection of Order Item from SAP List

Production Planner

TD App Backend Available in the frontend.

6 Save Changes Production

Planner

TD App Backend Available in the frontend.

7 Click on Request Ship- Production TD App Backend Available in the frontend.

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 51 of 64

# Scenario steps Actor Source / System

Data sent to (System)

Status of the Implementation

ment Details (TD STATUS = Shipment Details Re-quested)

Planner Logistics Responsible Supplier

8 Sending Notification Production Planner Logistics Responsible Supplier

TD App Backend Available in the frontend.

9 The user can add the Shipment Details

Supplier TD App Backend Available in the frontend.

10

Save Changes. (TD STATUS = Shipment Details Submitted)

Supplier TD App Backend Available in the frontend.

2.7.4.7 Scenario- Transport Demand Search

This functionality enables the user to search for the transport demands of interest using the filtering pa-rameters that are defined. The scenario and its current status is explained in the table below:

Table 28: Scenario- Transport Demand Search

# Scenario steps Actor Source / System

Data sent to (System)

Status of the Implementation

1 Login Production Planner Logistics Responsible

Supplier

TD App SPT System As in scenario “User Authen-tication“ and “User Authori-zation“

2 Visualize the Transport Demand List

Production Planner Logistics Responsible Supplier

TD App Backend Available in the front end only.

3 Transport Demand Search.

Click on the Search Icon

Production Planner

Logistics Responsible Supplier

TD App Backend Available in the front end only

4 Transport Demand List Production Planner Logistics Responsible Supplier

TD App Backend Available in the front end only

5 Selection of specific Transport Demand

Production Planner Logistics Responsible Supplier

TD App Backend Available in the front end only

6 Visualize the Transport Demand Details, Packag-ing Details, Shipment Details Sections

Production Planner Logistics Responsible

Supplier

TD App Backend Available in the front end only

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 52 of 64

# Scenario steps Actor Source / System

Data sent to (System)

Status of the Implementation

7 Visualize the Order Item list

Production Planner Logistics Responsible Supplier

TD App Backend Available in the front end only

2.7.4.8 Scenario- Request Shipment Details

The user with specific privileges will be able to request the details of the shipment by clicking on the „Re-quest Shipment Details“ button and a notification will be created accordingly.

Table 29: Scenario- Request Shipment Details

# Scenario steps Actor Source

/ Sys-tem

Data sent

to (Sys-tem)

Status of the Implementation

1 Login Production Planner Logistics Responsible Supplier

TD App SPT Sys-tem

As in scenario “User Authentica-tion“ and “User Authorization“

2 Visualize the Transport

Demand List

Production

Planner Logistic Responsible Supplier

TD App Backend Available in the front end.

3 Selection of specific Transport Demand with the Status = 'New Transport Demand'

Production Planner Logistic Responsible Supplier

TD App Backend Available in the front end.

4 Visualize the Transport Demand Details, Packag-ing Details, Shipment Details Sections

Production Planner Logistics Responsible Supplier

TD App Backend Available in the front end.

5 Select the button Re-quest Shipment Details

Production Planner

TD App Backend Available in the front end.

6 The Supplier will add the details and will save them

Supplier TD App Backend Available in the front end.

7 The Supplier can submit the Details

Supplier TD App Backend Available in the front end.

8 Verify TD STATUS = Shipment Details Sub-mitted

Production Planner Logistic Responsible

Supplier

TD App Backend Available in the front end.

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 53 of 64

2.7.4.9 Scenario- Submission of the demand to LPA

The user with specific privileges will be able to submit the demand to LPA by clicking on the “Submit Shipment” Button. At the end of the process the status will be updated to “Submitted to LPS” in the de-mand list.

Table 30: Scenario- Submission of the demand to LPA

# Scenario steps Actor

Source

/ Sys-tem

Data

sent to (System)

Status of the Implementation

1 Login Logistics Responsible

TD App SPT Sys-tem

As in scenario “User Authentica-tion“ and “User Authorization“

2 Visualize the Transport Demand List

Logistics Responsible

TD App Backend Available in the front end.

3 Selection of specific Transport Demand with Status “Shipment Details Submitted”

Logistics Responsible

TD App Backend Available in the front end.

4 Submit demand to LPA Logistics Responsible

TD App Backend

LPA

Not available since no interaction with LPA is implemented.

5 Verify TD STATUS = Submitted to LPA

Production Planner Logistics Responsible Supplier

TD App Backend Not available since no interaction with LPA is implemented.

2.7.5 Balanced Scorecard & Key Performance Indicators

The two main challenges that are addressed in this trial are “Shipment tracking challenge” and “Transport order management” challenge. The trial will explore the benefits of future internet applications and esti-mate how much the proposed solutions can improve collaboration between involved parties and over-come the mentioned challenges. For this end several KPIs have been defined in D400.3; however the implementation of the apps is still ongoing therefore the measurement process to evaluate the perfor-mance of the solutions has not started yet.

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 54 of 64

2.8 Trial 443 –Tailored Information for Consumers (TIC)

2.8.1 Trial Team

Lead: ATOS

Participants: UPM, Plus Fresc, CBT

2.8.2 Report on Trial Progress

Since the last reporting the trial team has been working on several tasks for the refinement of functional and technical requirements of Product Info; as well as the development of the app and it´s interaction with the Initial Apps, in this case the Product Information Tailored Information for Consumers – PIAApp TIC.

During this period a new partner has been incorporated to the trial (CBT) , this partner has been incorpo-rated through the Open Call.

The team has been also working on tasks for dissemination of the trial and FIspace project. The trial bro-chure has been created during this period and it can be downloaded from the following link http://www.fispace.eu/Documentations/Leaflets/tailored-information-leaflet.pdf

To achieve these objectives the following activities have been carried out:

1. Trial team meetings

The team has held regular meetings(one face-to-face meeting) in order to review the status of the tri-al, and to refine the functional and technical requirements of the Product Info. These meetings also served to keep informed team members not involved on app development about the Product Info sta-tus, Traffic Light App, Shopping List Recipe App, Augmented Reality Product App and Push Info App..

2. Workshops

During this period the TIC pilot has participated in the following events:

SmartAgriMatics (18-19 June 2014)

SmartAgriMatics was held in Paris (18-19 June 2014) , the TIC pilot organized a session into the SmatAwareness Topic: Session 5.1 Tailored Information for Consumers with the following Agenda

Figure 8: Tailored Information for consumers session Agenda

Open call Welcome meeting

The FIspace project held a meeting(27th May 2014) in order to welcome the Open call partners incor-

porated to the FIspace project, with this aim the TIC pilot made a detailed presentation about the Ap-plication Product Info App – TaPIA.

ECFI Munich

ECFI (European Future Internet conference) was held from 17 September to 18 September 2014 in Munich. The conference aims at bringing together key stakeholders to discuss how Europe can achieve global leadership in ICT by 2020 through innovative Internet technologies.

The TIC trial will show a demo of the Application Product Info App – TaPIA.

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 55 of 64

2.8.3 App Development.

The defined apps for the TIC trial are:

• Product Info App - TaPIA: This app allows end users to access tailored information from products located in the supermarket. The products can be scanned or search manually by enter-ing its EAN code. It also allows the user to provide feedback on products.

This app has gone under deep changes to allow data directly from the supermarket. It has been also added support to ease the integration of data models from other sources in the future.

Support for user profile is being added and there some changes are being added to improve user experience.

• Food Traffic Light App: By means of this App, product data gathered from different actors can be transformed into knowledge based on a set of rules.

This apps is currently on a early stage, developed as a web html prototype. The app has defined rules for three attributes, these rules area applied to four sample products and the attributes ap-pear on a colour depending on its value.

• Shopping List Recipe App: This Specific App will allow the consumer to manage its shop-ping list, and based on product info and consumer preferences, suggest products to elaborate se-lected recipe. This app is being developed through Open Call.

This app is under development and is expected a functional version by the end of September as an Android mobile application.

• Augmented Reality Product Info App: This Specific App will allow the consumer to access tai-lored product information at the supermarket in its mobile device by means of augmented real-ity. This app is being developed through Open Call.

• Push Info App: This Specific App will allow the retailer to push specific information (offers, alerts, birthday greetings...) to the consumer. This app is being developed through Open Call.

The development of the Augmented Reality Product Info App and the Push Info App has just started and is expected a prototype for the M18 review.

2.8.4 Balanced Scorecard & Key Performance Indicator

For the KPI a Balance Score approach is used.

Vision: Improve shopping experience.

Stakeholders: Providers, retailers and consumers.

Understanding: Improve food information to consumers to increase food trust.

Perspectives for improvements:

Farmers, Manufacturers and Providers >> Traders >> Retailers >> Consumers

Five major initiatives:

1. Product Info

1a. Investment: FIspace platform, providers and retailers.

1b. Utilization: Retailer and Consumers.

2. Food Traffic Light App

2a. Investment: FIspace platform, providers and retailers.

2b. Utilization: Retailer and Consumers.

3. Augmented Reality App

3a. Investment: FIspace platform, providers and retailers.

3b. Utilization: Retailer and Consumers.

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 56 of 64

4. Shopping List & Recipes App

4a. Investment: Retailers and Consumers.

4b. Utilization: Retailer and Consumers.

5. Push Information App

5a. Investment: Retailers.

5b. Utilization: Retailer and Consumers.

perspective Objective Measure Target Activity

Product Info

Process per-spective

Increase available product information for consumers

N of products with information from app/Total N of prod-ucts *100

+50% Investment in PIAApp - TIC

Provide new information channels to increase efficiency of product requests

N of info requests from app/N of total info requests

+25% Investment in Product Info

Customers perspective

Better trust in food products through feed-back from consumers

N of product feedback petitions/Total N of products *100

+5% Utilization of Prod-uct Info

Successful rate of feedback petitions

N of successful feed-back petitions/Total N of petitions *100

+75% Utilization of Prod-uct Info

Better trust in food products through con-sumers petitions of product info

N of product info petitions/N of product requests * 100

+25%

Utilization of Prod-uct Info

Improve consumers shopping experience through the use of apps

Number of app down-loads /Number of total costumers

+20% Investment in Product Info

Better trust in food products through num-ber of attributes select-ed for each product

N of attributes select-ed by product/ Total N of attributes by product *100

+25% Investment in Product Info

Learning Perspective

Inclusion of new food products in the shop-ping list

Number of new food products purchased / Number of total food product

+10% Investment in Product Info

Financial Perspective

Increase in new cos-tumers

Turnover / Year +5% Better trust and transparency for consumers

Increase of consumers with fidelity card

Number of customers with fidelity card / Total number of costumers

+10% Increase of sales

Increase of marginal purchase per consumer

Average purchase ticket

+5% Increase of sales

Cost reduction through lower personnel costs (personnel spend less time providing info to consumers)

Personnel for growth / Year

-5% Reduction in time and personnel. Reduction in internal costs.

Figure 9: Scorecard Product Info

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 57 of 64

Perspective Objective Measure Target Activity

Food Traffic Light App

Process per-spective

Increase available prod-uct information for con-sumers

N of products with information from app/Total N of prod-ucts * 100

+50% Investment in PIAApp - TIC

Provide new information channels to increase efficiency of product requests

N of info requests from app / N of total info requests

+25% Investment in Food Traffic Light App

Customers perspective

Better trust in food prod-ucts through consumers petitions of product info

N of product info petitions / N of product requests * 100

+25%

Utilization of in Food Traffic Light App

Improve consumers shopping experience through the use of apps

Number of app downloads /Number of total costumers

+20% Investment in in Food Traffic Light App

Learning Perspective

Inclusion of new food products in the shopping list

Number of new food products purchased / Number of total food product

+10% Utilization of in Food Traffic Light App

Financial Perspective

Increase in new costum-ers

Turnover / Year +5% Better trust and transparency for consumers

Increase of consumers with fidelity card

Number of custom-ers with fidelity card / Total number of costumers

+10% Increase of sales

Increase of marginal purchase per consumer

Average purchase ticket

+5% Increase of sales

Cost reduction through lower personnel costs (personnel spend less time providing info to consumers)

Personnel for growth / Year

-5% Reduction in time and personnel. Reduction in inter-nal costs.

Figure 10: Scorecard Food Traffic Light App

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 58 of 64

Perspective Objective Measure Target Activity

Augmented Reality App

Process per-spective

Increase available product information for consumers

N of products with information from app/Total N of prod-ucts *100

+50% Investment in PI-AApp - TIC

Provide new information channels to increase efficiency of product re-quests

N of info requests from app/N of total info requests

+25% Investment in Augmented Reality App

Customers perspective

Better trust in food prod-ucts through consumers petitions of product info

N of product info petitions/N of product requests * 100

+25%

Utilization of Aug-mented Reality App

Improve consumers shop-ping experience through the use of apps

Number of app down-loads /Number of total costumers

+20% Investment in Augmented Reality App

Better trust in food prod-ucts through number of attributes selected for each product

N of attributes select-ed by product/ Total N of attributes by product *100

+25% Investment in Augmented Reality App

Improve consumers shop-ping experience through augmented reality

Number of reality app downloads /Number of total costumers

+10% Investment in Aug-mented Reality App

Learning Per-spective

Inclusion of new food products in the shopping list

Number of new food products purchased / Number of total food product

+10% Utilization of in Augmented Reality App

Financial Per-spective

Increase in new costumers Turnover / Year +5% Better trust and transparency for consumers

Increase of consumers with fidelity card

Number of customers with fidelity card / Total number of costumers

+10% Increase of sales

Increase of marginal purchase per consumer

Average purchase ticket

+5% Increase of sales

Cost reduction through lower personnel costs (personnel spend less time providing info to consum-ers)

Personnel for growth / Year

-5% Reduction in time and personnel. Reduction in internal costs.

Figure 11: Scorecard Augmented Reality App

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 59 of 64

Perspective Objective Measure Target Activity

Shopping List & Recipes App

Process per-spective

Increase available product information for consumers

N of products with information from app/Total N of prod-ucts *100

+50% Investment in PI-AApp - TIC

Customers perspective

Improve consumers shopping experience through the use of apps

Number of app downloads /Number of total costumers

+20% Investment in Shopping List & Recipes App

Learning Per-spective

Increase of consumers food knowledge through number of recipes downloads

Number of Shopping list & Recipe app downloads / Number of app downloads * 100

+10% Utilization of Shop-ping List & Recipes App

Inclusion of new food products in the shopping list

Number of new food products purchased / Number of total food product

+10% Utilization of Shop-ping List & Recipes App

Financial Per-spective

Increase in new cos-tumers

Turnover / Year +5% Better trust and transparency for consumers

Increase of consumers with fidelity card

Number of custom-ers with fidelity card / Total number of costumers

+10% Increase of sales

Increase of marginal purchase per consumer

Average purchase ticket

+5% Increase of sales

Figure 12: Scorecard Shopping List & Recipes App

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 60 of 64

Perspective Objective Measure Target Activity

Push Information App

Process per-spective

Better early warnings to consumers

N of warnings sent to consumers

+25% Investment in FIspace platform

Improve retailer com-munication to consum-ers

N of push info com-munications from retailer

+25% Utilization of Push Information App

Customers perspective

Improve consumers shopping experience through the use of apps

Number of app down-loads /Number of total costumers

+20% Investment in Push Information App

Learning Per-spective

Inclusion of new food products in the shop-ping list

Number of new food products purchased / Number of total food product

+10% Utilization of Push Information App

Financial Per-spective

Increase in new cos-tumers

Turnover / Year +5% Better trust and transparency for consumers

Increase of consumers with fidelity card

Number of customers with fidelity card / Total number of cos-tumers

+10% Increase of sales

Increase of marginal purchase per consum-er

Average purchase ticket

+5% Increase of sales

Lower process costs with Push Information App

Used offers vouchers from apps / Total used offers vouchers (app+paper)

-20% Reduction in time and personnel

Increase of sales through push info offers vouchers

Offers sales € / Total sales €

+2% Increase of sales of specific prod-ucts (offer prod-ucts)

Cost reduction though reduction use of paper

€ used in offers bro-chures and vouchers

-10% Reduction in internal costs

Figure 13: Scorecard Push Information App

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 61 of 64

2.8.5 Relationships between objectives and activities

Figure 14: Relationship between objectives and activities

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 62 of 64

3 Update on collaboration and harmonization and large scale expan-sion activities of the use case trials in Phase 3

3.1 Update on collaboration and harmonization

Most of the work during the M13-M18 period has been focused on the development of the Apps, including the integration of the open call partners, description of concept in use, preparation of tests and prepara-tion for evaluation (KPIs).

The intensive communication between the trials as well l as with other work packages enables collabora-tion in the cross trial/domain utilization of Apps and harmonization approaches in regards of the develop-ment of FIspace.

Major interactions did happen where trials are dealing primarily with product monitoring activities during distribution. These trials have been integrated into the forthcoming FINISH project to assure that further developments will be based on a comprehensive view.

These trial activities, with relevance for the FFV trial and the Flower and Plants trial, refer to logistics planning dealt with in the trail 431.

Despite the fact that trial 431 is not directly involved in the FINISH project, the call for project proposals will consider logistics issues as well and invite the Fish trial and its development groups to get involved. To support this development, the FFV trial has already actively approached logistics companies for in-volvement in phase 3 developments.

The further expansion of the activities, will carried on also by the phase 3 projects FINISH and FRAC-TALS which are explicitly focusing on the results of the FIspace project.

The activities of Trial 441 states the significant amount of cross trial interaction as well:

The MIP trial cooperates with the Fresh Fruits & Vegetable trial on developing the PIA (Product Information App);

The MIP trial initiated the development of a common and shared data model with the Fresh Fruits & Vegetable trial, the Flowers & Plant trial, the Tailored Information for Consumers trial and sev-eral others.

The MIP trial works together with the Tailored Information for Consumers trial on a Consumer App, to be developed by the TIC trial.

Next to this collaboration, the MIP trial discusses other collaboration opportunities, e.g. the Ebbits project (http://www.ebbits-project.eu/news.php), UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business), and its project to realize transparency for pork and poultry. Furthermore interest is shown from GS1 Netherlands and GS1 Global Office (US).

These activities will prove the envisioned FIspace platform as a real generic multi domain collaboration platform.

Further activities will be documented and reported in the following M19 and M24 reports.

3.2 Update on large scale expansion

The basis for large scale expansion is the availability of the chain encompassing Apps. They describe the difference to solutions already on the market and focus on pressing issues in the sector. In continuation of ongoing initiatives, trial participants are engaged in working groups of business stakeholders of the sector organized.

Furthermore, trial participants engage in business stakeholder meetings with presentations. These initia-tives are complemented by presentations at IT oriented meetings. Of special relevance are IT meetings where whole workshops are dedicated to FIspace developments.

Presentations did raise awareness in the scientific community and provide the base for scientific business support towards new levels of transparency that could be reached with FIspace technology. This support is crucial for matching technology with new process organizations that might evolve in logistics and com-munication along the chain.

FIspace 22.10.2014

FIspace-D400.4-v07.docx Page 63 of 64

1.ECFI, Brussels

IFSA conference, Berlin (conference on Systems Research in Agriculture), Paper on ICT and FIspace

Annual SRII Global Conference 2014, Silicon Valley, San Jose, CA, USA

Horizon 2020 National Launch Event – Turkey, FInest/Fispace success story presentation

Intern. Conference of the International Food and Agribusiness Management Association, Cape Town (www.ifama.org)

SmartAgriMatics 2014, Paris, France

ECFI, Munich

In order to engage potential users and other stakeholders of single trials undertook several actions in the last six month. Below some examples of these activities are mentioned.

Koç Technology Board Annual Assembly

Article on MIP in PROZEUS NL and on PROZEUS Webpage

Demonstration of FIspace platform to national project on transport and logistics(LoFIP)

The following actions are planned for trial 443 (Detailed Consumer Information) and provide a good ex-ample of an insight look how far the expansion of FIspace and stakeholders has gone already

Demo apps videos

TAPIA v2

Traffic light

Shopping list and recipes app

User testimonial video (PF-end user) including business model and Fispace need

Press releases

Consumers workshop Inclusion of FIspace in stakeholder webpage

Update leaflet with new achievements and progresses

Certain trials are the core of the accelerator programs FINISH and FRACTALS which officially did start in September 2014. First preparations for linking up with potential system development groups have been and are going on. The FINISH and FRACTALS projects will prepare the way for larger scale expansion.

Some of the trials are preparing a Horizon2020 proposal to organize the funding of a follow-up project to improve transparency, tracking & tracing in fresh food supply chains for consumers, supply chain parties and authorities.