FI-WARE May 2011

1. Future Internet PPP Core Platform FI-WAREMay 2011

2. Index • Context • Vision • FI-WARE Architecture • Structure of Activities and Work Plan

3. Index • Context • Vision • FI-WARE Architecture • Structure of Activities and Work Plan

4. What is FI-WARE?. The center of a future ecosystem FI-WARE platform will serve objectives of usage areas and will have the ambition of fulfilling the needs of a broader market Utilities and environment Tourism eHealth Transport Smart Grid The aim of FI-WARE is to be useful for Europe Other Usage areas E- business

5. Suppliers Governments Manufacturer Consumers Retailers Wholesalers App/Services ecosystem and delivery framework Cloud Hosting Internet of Things Interface to Networks We are open to the community Future Internet Core Platform Provisioning – Hosting – Refactoring – Brokering – Consumption

6. We are committed to the PPP…and beyond Our objective: create a solid basis for the Internet of the Future • 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

7. Index • Context • Vision • FI-WARE Architecture • Structure of Activities and Work Plan

8. 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 Consumers People Businesses Apps/Services Provider Platform Provider

9. Elements & Functions of FI Core Platform • 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 Usage area projects under the PPP Cloud Hosting App/Service Delivery Support Services Interface to IoT Interface to Network Security, Trust Dev Tools

10. 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

11. What is a FI-WARE Generic Enabler (GE)? • 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)

12. What is a FI-WARE Generic Enabler (GE)? Chapter 1..n Implementation Generic Enabler 1..n 1..n Component

13. 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 Use Case Trial FI Core Platform GE GE FI Core Platform Instance GE GE GE GE assemble… GE Platform Products

14. Creation of FI-WARE Instances

15. 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. Is FI-WARE an integration project?

16. 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) Scope of the FI-WARE Testbed

17. 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 Infrastructure of the FI-WARE Testbed

18. 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 FI-WARE Open Innovation Lab

19. 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 Principles about IPRs

20. 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. Principles about IPRs (cont.)

21. 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. Open vs Closed Source licenses

22. Index • Context • Vision • FI-WARE Architecture • Structure of Activities and Work Plan

23. FI Core Platform Architecture: main chapters Functionality Trust and Security Operations App/Services Ecosystem & Delivery Framework Access to Internet of Things Core Platform Support Services Cloud Hosting Interface to Network

24. Service Delivery framework • 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, ….)

25. Cloud hosting • 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

27. Access to the Internet of things • 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

28. Security and trust • 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

29. Interface to the network • 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 • …

30. Index • Context • Vision • FI-WARE Architecture • Structure of Activities and Work Plan

31. WP Structure WP1 Management WP2 Global Technical Activities WP3 Apps/Services Ecosystem and Delivery WP4 Cloud Hosting WP5 IoT WP6 Support Services WP7 Interface to the Network WP8 DevComm and Tools WP9 Security , WP10 CP Instantiation and Operational Support WP11 Experimentation and Validation WP12 Dissemination and Exploitation

32. Applying Agile concepts Define, Merge, Extrapolate, Prioritize, … • 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 • 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 • 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) Component Backlog Component Backlog Global Governance Major releases Minor releases Chapter 1 Component 1 Component 2 Component 3 Chapter 2 Component 1 Component 2 Component 3 Single Global Clock

33. 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 European Commission 23 October 2009v1a Guidance note for project coordinators planning a competitive call for additional beneficiaries in an ICT Integrated Project or Network of excellence Management of Open Calls

34. Thank You !!