The FI-WARE Project – Base Platform for Future Service Infrastructures FI-WARE May 2011 Future...

The FI-WARE Project – Base Platform for Future Service Infrastructures

FI-WARE

May 2011

Future Internet PPP Core Platform


Index

2

1. Context

2. Vision

3. FI-WARE Architecture

4. Structure of Activities and Work Plan


Index

3

1. Context

2. Vision




Other Usage areas

eHealth

Tourism

Smart Grid

Transport

E- business

Utilities and environment

FI-WARE platform will serve objectives of usage areas and will have the ambition of fulfilling the

needs of a broader market

What is FI-WARE?. The center of a future ecosystem

The aim of FI-WARE is to be useful for Europe


We are open to the community

Future Internet Core Platform

Provisioning – Hosting – Refactoring – Brokering – Consumption

App/Services ecosystem and delivery framework

Cloud Hosting Interface to NetworksInternet of Things

Suppliers

WholesalersManufacture

r Retailers

GovernmentsConsumers


We are committed to the PPP…and beyond

Working IT and Telcos together to make

New services for everybody Smart applications Innovative business models

Providing

– Tools to avoid fragmentation

– Results from existing research

Our objective: create a solid basis for the Internet of the Future


Index

7

1. Context

2. Vision




The VISION

FI-WARE will be a technological foundation to satisfy the demands of application/services providers and consumers across various usage areas, stimulating and cultivating a sustainable FI service ecosystem

Platform Provider

Apps/Services Provider

People Businesses

Consumers


Elements & Functions of FI Core Platform

9

The FI Core Platform comprises a set of technological “Generic Enablers” which are considered general purpose and common to several current and future “usage areas”

Generic Enablers (therefore, the FI Core Platform) will provide open interfaces for development of Applications

Cloud Hosting

App/Service Delivery

Support Services

Interface to IoT

Interface to Network

Security, Trust

Dev Tools

Cloud Hosting

App/Service Delivery

Support Services

Interface to IoT


Security, Trust

Dev Tools

Usage area projects under the PPP


What is a FI-WARE Generic Enabler (GE)?

A FI-WARE Generic Enabler (GE) is a functional building block of FI-WARE

Any implementation of a Generic Enabler (GE) is made up of a set of components which together supports a concrete set of Functions and provides a concrete set of APIs and interoperable interfaces that are in compliance with open specifications published for that GE

There might be multiple compliant implementations of a given GE

Each Architecture Chapter (linked to WP3 until WP9) in FI-WARE will lead to definition of a set of GEs

10



As an example, the Data/Context Management System may comprise:

• A set of GEs allowingcompilation and storage of massive data from disparate sources, each specialized in gathering data from a specific source (e.g., data from connected “things”, data obtained from user devices, data provided by the user, data exported by applications, etc.)

• A number of GEs dealing with processing of stored data, enabling generation/inferencing of new valuable data that applications may be interested to consume.

• A GE which supports a well defined API enabling Future Internet Applications to subscribe to data they are interested in, making them capable of receiving this data in real time.

A FI-WARE compliant Platform Product implements, totally or in part, a FI-WARE GE or a concrete composition of FI-WARE Ges

A FI-WARE Instance is the result of integrating a number of FI-WARE compliant Platform Products and, typically, a number of complementary products (e.g. Billing support systems)

11



12

ChapterChapter

ComponentComponent

Generic EnablerGeneric Enabler ImplementationImplementation

1..n

1..n

1..n


Core Platform Instances and Use Case Trials

Future Internet Applications run on top of “FI Core Platform Instances” built upon selection and assembly of “Platform Products” implementing “Generic Enablers” of the “FI Core Platform”

Use Case trials will consist on application scenarios running on top of FI Core Platform Instances, involving real users

FI Core Platform

Platform Products

FI Core Platform Instance

13

Use Case Trial

assemble…

GE GE

GE

GE

GE

GE GE


Creation of FI-WARE Instances

14


Is FI-WARE an integration project?

The FI-WARE project will draw upon the wealth of results already achieved through earlier European research, not only within the FP's but also at national- or corporate-funded levels

In the FI-WARE project, there is an equal focus on advancing components/technologies linked to GEs as well as integrating GEs

R&D activities in FI-WARE will comprise:

• Evolving components, contributed by partners or available on the market, to:

› incorporate new features required to implement GEs

› allow GEs to be integrable with other GEs in the FI-WARE Architecture

• Creating new components that may cover gaps in the FI-WARE Architecture

Both R&D activities may be performed by:

• partners in the original consortium

• new partners that will be added to the consortium following an open call for additional beneficiaries.

15


Scope of the FI-WARE Testbed

The FI-WARE project will generate a FI-WARE Testbed as a case example of a FI-WARE Instance. It:

• will allow Use Case projects and third parties to run and test Future Internet Applications based on FI-WARE Generic Enablers.

• is aimed to be complete, in the sense that it will comprise reference implementations of all GEs defined in the FI-WARE Architecture.

• will not necessarily be centralised, but will be under central control and be accessible from a dedicated website.

FI-WARE partners will provide support to UC projects in deploying their conceptual prototypes on top of the FI-WARE testbed

Tests run by the UC projects, coordinated with tests defined by the FI-WARE project, will help to validate:

• Generic Enabler (GE) Open Specifications

• reference implementations of FI-WARE GEs developed in FI-WARE

• conceptual prototypes by UC projects (but not our responsibility)

16


Infrastructure of the FI-WARE Testbed

The FI-WARE project is in conversations with several parties that are willing to sponsor the physical resources (servers, connectivity, etc.) required in order to run the FI-WARE Testbed

Because of this, no budget is planned to acquire these physical resources.

In case these negotiations with external parties fail, physical resources for the testbed will be considered part of the beneficiaries’ indirect costs

17


FI-WARE Open Innovation Lab

The project will work towards the establishment of an Open Innovation Lab around the FI-WARE testbed that may help third parties and not just the Use Case projects, to test how innovative applications may be developed on top of FI-WARE GEs

In short:

• FI-WARE Open Innovation Lab = FI-WARE Testbed + FI-WARE DevCommE

It is intended that this Open Innovation Lab be available to third parties after the second year

18


Principles about IPRs

Specifications of APIs (Application Programming Interfaces) and Interoperable Protocols supported by FI-WARE Generic Enablers (GE) will be open and Royalty-free

The FI-WARE project will deliver a reference implementation for each of the GEs defined in the FI-WARE Architecture

• Some components of these reference implementations may be closed source while others may be open source

• The concrete open source license selected by the owning partners who work together in the implementation of a given component will be agreed by them, taking into account the Access Rights obligations and avoiding any impact on other Project partners and their work packages

In those cases where an open source reference implementation of a FI-WARE GE will not be provided by any partner(s) in the consortium, and there are enough reasons that justify asking for one, FI-WARE will consider issuing an open call looking for partners who develop it

19


Principles about IPRs (cont.)

Other than in exceptional circumstances and only for Background specifically identified, no costs shall be charged for granting Access Rights to Foreground and Background needed for the execution of the FI PPP projects.

Access Rights to Foreground, and for Background and Sideground needed for the use of any Foreground, outside FI PPP program activities shall be granted on Fair and Reasonable and Non-Discriminatory (FRAND) Conditions.

Software distributed under Open Source Licenses are considered granted on FRAND conditions.

20


Open vs Closed Source licenses

The parties acknowledge the existence of different business models regarding the exploitation of the results of the project, esp. the software deliverables. Software is disseminated and exploited under different licences, according to different business models.

Different licences (e.g. proprietary or open source) may be incompatible with each other with regards the combination of software components coming from different parties.

As soon as such situations occur during the work of the project, the involved parties shall determine if the licences proposed for the different components allow for their intended combination, and in the case of incompatibility, the parties will resolve the matter by choosing the same or compatible licenses.

The resolution of such issues shall be governed by a set of rules that have to be elaborated and delivered within three months after the start of the project.

21


Index

22

1. Context

2. Vision




FI Core Platform Architecture: main chapters

23

Op

erat

ion

sO

per

atio

ns

Tru

st a

nd

Sec

uri

tyT

rust

an

d S

ecu

rity

Fu

nct

ion

alit

yF

un

ctio

nal

ity

App/Services Ecosystem &

Delivery Framework

Access to Internet of

Things

Core Platform Support Services

Cloud Hosting



Service Delivery framework

24

Enables applications, implementing processes or linked to "things" and contents, to be accessible by end-users: • from any device

• within and across domain-specific Core Platform instances (federated applications catalogs)

Enables applications “mash-up“ and the exploitation of user-driven innovation

Incorporate Open Application/Services Marketplace capabilities and the publication of applications through different channels (Facebook, AppStores, ….)


Cloud hosting

25

Enable application providers to host their applications on a cloud computing infrastructure so that:• ICT resources are elastically

assigned as demand evolves, meeting SLAs and business requirements

• They only pay for actual use or ICT resources

Support both IaaS-oriented and PaaS-oriented provisioning of resources

The cloud computing infrastructure linked to a Core Platform instance can be federated with that of another Core Platform instance or external Clouds, through standard APIs/protocols


26

Support and Data handling

Collection of enablers supporting:• Access to Context Info

(including user profile and preferences) to ease development of context-aware apps

• Storage of large amounts of data

• Processing, correlation and distribution of large amounts of events

• Processing of multi-media contents

Accessible through standard set of APIs


Access to the Internet of things

27

Enables an uniform access to the “Internet of Things”: • Universal (unique)

identification of “things”

• Standard information model

• Standard management APIs

• Standard APIs for gathering data

Implemented as a common layer which mediates with the different types of sensor and device networks


Security and trust

28

Trust and Security:• Spanning from infrastructure and

“things” all up to the application layer

• Common enablers for identity, authentication and authorization

• User privacy management

Operations• Lifecycle Management Support

• End user usage accounting

• Platform usage accounting

• Support for Analytics


Interface to the network

29

Interfaces wrapping access to network enablers that would be published to application programmers (materializing and further developing efforts in initiatives such as JIL, BONDI, GSMA oneAPI)

Interfaces required for development of Platform components:• Interfaces to control QoS and Network Resources allocation

• Gateway communication middleware and hosting interfaces

• …


Index

30

1. Context

2. Vision




WP Structure

WP1 Management WP1 Management

WP2 Global Technical ActivitiesWP2 Global Technical Activities

WP11 Experimentation and Validation

WP11 Experimentation and Validation

WP12Dissemination and Exploitation

WP12Dissemination and Exploitation

WP3 Apps/ServicesEcosystem and Delivery

WP3 Apps/ServicesEcosystem and Delivery

WP4Cloud HostingWP4Cloud Hosting

WP5 IoTWP5 IoT

WP6 Support Services

WP6 Support Services

WP7Interface to the Network

WP7Interface to the Network

WP8Dev Comm and Tools

WP8Dev Comm and Tools

WP9 Security , WP10 CP Instantiation and Operational SupportWP9 Security , WP10 CP Instantiation and Operational Support


Applying Agile concepts

32

Component Backlog

Component Backlog

Features Backlogs per Usage Area

(Features identified by a given Usage-Area)•Representatives from each Usage-Area project meet regularly with TM and WPLs to review features backlog•Features within each Usage-Area Backlog has a priority assigned

Define, Merge, Extrapolate, Prioritize, …

Following Agile principles, FI-WARE interaction with Usage-Area projects will be rather dynamic

Final priorities in Chapter Backlogs will be assigned according to indicators such as implementation time, number of UAs requiring the feature, support by stakeholders, Impact on overall Architecture, Genericity, …

Results from prioritization will be public and shared with Usage-Areas as part of the overall FI-WARE roadmap

Conflicts will be resolved within PPP Governance Bodies (mainly Architecture Board)

SP1 SP2 SP3 SP4 SP5 SP6 SP7 SP8Vision

….Sprint0


….Sprint0


….Sprint0


….Sprint0

SP1 SP2 SP3 SP4

Vision

Sprint0


….Sprint0

Minor releases

Global Governance

Chapter 1

Single Global Clock

Chapter 2

Component 1

Component 2

Component 3

Major releases

Component 1

Component 2

Component 3

Features Backlogs per Architecture Chapter (WPs 3-9)

(Features in Roadmap of FI-WARE Architecture Chapters)•Each Backlog owned by the corresponding WPL•Planning of Sprints decided within corresponding WPC •and supervised by PCC


Management of Open Calls

We plan to maintain ~30% (12M Euro) of the project budget for distribution among new partners

New partners will be selected through Open Calls to allow for responding to emerging user requires not identified at the start of the project, e.g.,

› due to new usage areas, new technologies, new economic conditions

Specific component of the budget will be reserved for SMEs (aprox 30%) and Research Centers (aprox 30%)

Selection of new partners will be done according to the procedure issued by the Commission

33

European Commission23 October 2009v1a23 October 2009v1a

Guidance note for project coordinators planning a competitive call for additional beneficiaries in an ICT Integrated Project or Network of excellenceGuidance note for project coordinators planning a competitive call for additional beneficiaries in an ICT Integrated Project or Network of excellence


Thank You !!

The FI-WARE Project – Base Platform for Future Service Infrastructures FI-WARE May 2011 Future...

Documents

Transcript of The FI-WARE Project – Base Platform for Future Service Infrastructures FI-WARE May 2011 Future...