Technical Documentation - fractals-fp7.com · FRACTALS Technical Documentation Page 4 of 43 Introduction This document represents summary of previously prepared documents and articles

$Page 1: Technical Documentation - fractals-fp7.com · FRACTALS Technical Documentation Page 4 of 43 Introduction This document represents summary of previously prepared documents and articles$

Future Internet Enabled Agricultural Applications

Technical Documentation

FRACTALS Technical Documentation

Page 2 of 43

Table of Contents

INTRODUCTION ......................................................................................................................................... 4

SECTION 1: FIWARE ................................................................................................................................. 5

1. QUICK FIWARE TOUR ....................................................................................................................... 5

1.1 FIWARE in 3 steps ................................................................................................................................. 5

1.2 Background Information ....................................................................................................................... 6

2. OVERALL FIWARE VISION ................................................................................................................. 7

2.1 Background and Motivations ................................................................................................................ 7

2.2 Vision and Goals ................................................................................................................................... 8

2.3 FIWARE Generic Enabler Open Specifications, Compliant Platform Products, Instances ...................... 10

2.4 The FIWARE Testbed and FI‐Lab .......................................................................................................... 12

2.5 FIWARE in the context of the European Future Internet Public Private Partnership (FI‐PPP) Program . 12

2.6 Business Ecosystem ............................................................................................................................ 13

2.7 Terms and definitions ......................................................................................................................... 15

3. FIWARE ARCHITECTURE ...................................................................................................................17

3.1 FIWARE Architecture .......................................................................................................................... 17

3.2 FIWARE Architecture Overview .......................................................................................................... 17

3.3 FIWARE Roles ..................................................................................................................................... 21

4. SUMMARY OF FIWARE OPEN SPECIFICATIONS .......................................................................................23

4.1 Overview ............................................................................................................................................ 23

4.2 About This Document ......................................................................................................................... 23

4.3 Intended Audience ............................................................................................................................. 23

4.4 FIWARE Open Specifications ............................................................................................................... 23

4.5 Cloud Hosting Chapter ........................................................................................................................ 23

4.6 Data/Context Management Chapter................................................................................................... 24

4.7 Internet of Things (IoT) Services Enablement Chapter ......................................................................... 24

4.8 Applications/Services Ecosystem and Delivery Framework Chapter .................................................... 24

4.9 Security Chapter ................................................................................................................................. 25

4.10 Advanced Middleware and Web User Interfaces Chapter ................................................................... 25

5. FIWARE TECHNICAL ROADMAP .........................................................................................................26

6. FIWARE AGILE DEVELOPMENT METHODOLOGY .....................................................................................27

6.1 Prologue ............................................................................................................................................. 27

6.2 About Epics, Features, User Stories and Work Items ........................................................................... 27

6.3 Creating the first version of the FIWARE backlogs ............................................................................... 30

6.4 Management of the FIWARE Backlog .................................................................................................. 30

6.5 Requesting the addition of new entries to the FIWARE Backlog .......................................................... 31

7. FIWARE FREQUENTLY ASKED QUESTIONS (FAQ) ...................................................................................32

7.1 About the FIWARE Programme ........................................................................................................... 32

7.2 About the FIWARE platform ............................................................................................................... 33

7.3 About the FIWARE Lab........................................................................................................................ 38

7.4 About the FIWARE Ops suite of tools .................................................................................................. 39


Page 3 of 43

7.5 About the FIWARE Accelerator Programme ........................................................................................ 39

7.6 About the FIWARE mundus programme ............................................................................................. 39

SECTION 2: FISPACE ..................................................................................................................................40

8. FISPACE PLATFORM ..........................................................................................................................40

8.1 Basic principles of the FIspace platform .............................................................................................. 40

8.2 FIspace modules ................................................................................................................................. 41

8.3 FIspace documentation ...................................................................................................................... 42

8.3.1 App Developer ............................................................................................................................. 42 8.3.2 Business Architect .......................................................................................................................... 42 8.3.3 End User .................................................................................................................................... 42 8.4 FIspace Roadmap ............................................................................................................................... 42

8.5 Perspectives of using FIWARE in agriculture based on FIspace ............................................................ 42


Page 4 of 43

Introduction This document represents summary of previously prepared documents and articles about FIWARE and FIspace. It is divided in two section, dedicated to each of them. All presented documents and information regarding FIWARE can be found online on https://forge.fi‐ware.org/plugins/mediawiki/wiki/fiware/index.php/Welcome_to_the_FI‐WARE_Wiki All presented documents and information regarding FIspace can be found on project’s web site www.fispace.eu. The purpose of this document is to give an overview related to FIWARE and FIspace, how applicants should connect, including concrete examples, how to make the most of their usage.


Page 5 of 43

Section 1: FIWARE

1. Quick FIWARE tour

1.1 FIWARE in 3 steps Step 1: Basic Vision and Mission layed out First of all, we recommend that you start reading the Overall FIWARE Vision since it will introduce some basic concepts to you that are general to FIWARE and will be constantly referred in many other places. Some basic concepts such as Generic Enabler (GE), FIWARE Generic Enabler implementation, FIWARE Generic Enabler Implementation Instance, FIWARE Instance, FIWARE Testbed or FIWARE Open Innovation Lab are defined with precision there. Step 2: The Technical Chapters After this very first step, we recommend that you take a first overview of each of the Technical Chapters defined in FIWARE. You may visit the Overview sections linked to each of the FIWARE Technical Chapters in the FIWARE Product Vision for this purpose:

FIWARE Data/Context Management Internet of Things (IoT) Services Enablement Applications/Services Ecosystem and Delivery Framework Security Cloud Hosting Interface to Networks and Devices (I2ND)

Step 3: How it is all implemented Touching some ground, therefore going from the very abstract definition to the concrete implementation of the main concepts introduced in the Overall FIWARE Vision, could probably a good idea as a next step. Therefore, we recommend that you take a look at the FIWARE Catalogue where you will find a comprehensive description of the implementations of the FIWARE GEs that have been delivered as part of the First Release of FIWARE for each of the its Technical Chapters. Note that you may also find information there about instances of FIWARE GE implementations available on the FIWARE Testbed (usage of the FIWARE Testbed is currently limited to UC projects in the first phase of the FI‐PPP, but will be opened to other parties as part of the FIWARE Open Innovation Lab build after completion of the second FIWARE Release):

Catalogue of Generic Enabler Implementations in the Data/Context Management Chapter Catalogue of Generic Enabler Implementations in the IoT Services Enablement Chapter Catalogue of Generic Enabler Implementations in the Applications/Services Ecosystem and Delivery

Framework Chapter Catalogue of Generic Enabler Implementations in the Security Chapter Catalogue of Generic Enabler Implementations in the Cloud Hosting Chapter Catalogue of Generic Enabler Implementations in the Interfaces to Network and Devices (I2ND) Chapter


Page 6 of 43

1.2 Background Information Timing and Project Planning Information FIWARE is being materialized using an Agile approach and you may be interested to learn how we are applying Agile concepts in FIWARE but, if you are familiar with Agile, probably it is enough for you to know that:

There is a Product Backlog defined per GE with Themes, Epics, Features and User‐stories (you can explore defined Epics/Features at the Materializing the FIWARE Vision section of this wiki);

Development within FIWARE is organized through: o subsequent Sprints, one month long each, o Minor Releases, covering three consecutive Sprints, o Major Releases, covering 4 minor Releases, o Adopting a Single “clock”, i.e., a common convention for Releases and Sprints numbering, with

mapping to calendar dates. Frequent updates of the FIWARE Testbed are planned after the First Release:

Decided per FIWARE GE, after completion of a Sprint or Minor Release,

Guaranteed for all FIWARE GEs, after completion of a Major Release. You can review the FIWARE Technical Roadmap to learn what is being planned for each of the three first Major Releases of FIWARE.


Page 7 of 43

2. Overall FIWARE Vision

2.1 Background and Motivations Changing ICT Landscapes and Trends Over the last couple of years, a number of technology trends are recognized as significant new directions in the ICT landscape, which will usher in the era of the Future Internet in Europe. A first major trend is the on‐going industrialization of IT in the form of cloud computing and open service delivery platforms. The on‐demand, pay‐per‐use nature of these provisioning models is expected to fundamentally change how IT infrastructures are provisioned, essentially enabling them to be delivered as a service. Secondly, new wireless networking technologies such as LTE (4G) and the deployment of Fibre to The Home (FTTH) will offer increased network capacity and bandwidth to customers, thereby paving the way for new (real‐time) applications in mobile data networks as well as for stationary scenarios. Furthermore, the virtualization of classical carrier networks is also on‐going and starting to find new areas of application. Thirdly, the Internet of Things is safely taking hold, with the vision of ubiquitously connecting intelligent devices and sensors and offering new possibilities for contextual and environmental information sensing, processing and analysis, thereby opening the door to new automation and control applications and services in various sectors. Lastly, the maturing Internet of Services is accelerating the creation of complex value networks of service providers, consumers, and intermediaries bringing businesses and end customers innovative applications better tailored to their needs. These networks increasingly span various different players that historically have worked largely separated from each other thereby leading to more agile and dynamic business relationships and environments never seen before. The Market Stakeholder Perspectives Brought together, the above trends are the core drivers towards the emergence of a new era in the evolution of the Internet, which we may refer to as Future Internet. It will carry the potential for realizing new business opportunities for established and emerging application and service providers in areas such as telecommunications, healthcare, media and e‐government. This Future Internet will address some key demands and expectations from the various market stakeholders which cannot yet be satisfactorily met. Thus, regarding Application and Service consumers:

End customers want to gain access and easily consume applications that can effectively assist them in daily life situations. Some of the underlying problems involved are the management of the ever‐growing data and information (e.g. from their sensor‐enabled environments) and the seamless access anywhere, anytime and from any device. They also ask for improved means for communication and collaboration within their social networks, families, neighborhoods in real‐time and while being mobile, meeting security and privacy requirements. Overall, these capabilities would transform communities, homes and cities into safer and better places to live and leverage the Internet as an additional societal utility.

Enterprises and organizations on the other hand, wish to get closer to their customers in order to deliver an even more compelling user experience and better service. For this reason, they would like to exploit contextual user data which may lead to a more personalized interaction experience and service offering, and would like to realize a stronger participation of users in all phases of product and service lifecycles, thereby bringing the lessons of the Web 2.0 phenomena into the services space. In order to develop and operate their services, new methods, technologies and tools are needed to speed up the time to market, to establish value added services which may be better configured in partnership with others and to simplify access to relevant resources and capabilities, e.g., from the Internet of Things. Additional requirements on business services include reduced complexity of ICT provisioning, scaling, global availability and meeting security requirements from customers and legal authorities. An appropriate Future Internet platform would greatly contribute to meeting these demands from business customers.


Page 8 of 43

Application/service developers and providers, on the other hand, are challenged to build smart applications that cover the above mentioned needs from consumers. From a development perspective, such applications and services should be built on top of powerful but easy to use APIs, be standards based and offer flexible deployment and provisioning means (e.g., many devices, multi‐tenant architectures, global scalability, and on‐demand provisioning) and management frameworks (e.g. in the Internet of Things). Additionally, they should exploit economies of scale and protect investments in the long run. Finally, the ability to combine applications from different sources necessitates innovative revenue sharing models across partners and potentially also customers (e.g. crowd‐sourcing) which have to be adapted dynamically as market conditions change. Towards Strengthening Innovation‐enabling Capabilities The previous observations independently hold across vertical sectors such as health, transportation and logistics, energy and urban management. However, in practice, many solutions in those areas are today realized as custom made applications which are developed multiple times for particular purposes with proprietary interfaces. This severely hinders the growth of economies of scale for application and service developers, and limits the size of the addressable markets and ICT investments that can be made towards new products and services in vertical applications sectors. As most revenues in the ICT sector in 2020 will be generated by products and services which have not yet been developed, it is now commonly agreed by public and private thought leaders that investments into the innovation‐enabling capabilities are crucial for success in the global market competition. Economical, Societal, and Political Benefits brought by a FI Core Platform From an economic perspective it can be observed that many companies in the traditional ICT sector face difficulties concerning the transformation of their own business models into new areas, tackling commoditization and marginalization threats. To address this difficulty, a framework is needed where new business models can be explored and validated effectively. Such a framework could help to cultivate an ecosystem comprised of agile and innovative service providers, which in turn consume services provided by the traditional ICT players. Considering the societal dimension, the availability of a platform whereby stake holders across different sectors (e.g., healthcare, logistics, energy management, sustainability, transport etc.) can cooperate will accelerate the development of new innovative services for the European society within and across various sectors. Vertical and horizontal innovations in these areas will contribute to solving major societal challenges (e.g., Grand Societal Challenges identified by the EU Commission and EU Member States). Lastly, on the political dimension, legal and legislative barriers presently hinder the efficient cross‐border establishment of new innovative solutions due to complex or incompatible ICT policies in different countries and regions. The identification of legal and regulative aspects that could be potential barriers for innovation in the Future Internet should thereby be investigated and appropriate mitigation actions should be identified and brought to the attention of policy makers. A FI Core Platform may serve the purpose of revealing such barriers.

2.2 Vision and Goals The high‐level goal of the FIWARE project is to build the Core Platform of the Future Internet. This Core Platform, also referred to as the “FIWARE Platform” or simply “FIWARE” throughout the rest of this document, will dramatically increase the global competitiveness of the European ICT economy by introducing an innovative infrastructure for cost‐effective creation and delivery of versatile digital services, providing high QoS and security guarantees. As such, it will provide a powerful foundation for the Future Internet, stimulating and cultivating a sustainable ecosystem for (a) innovative service providers delivering new applications and solutions meeting the requirements of established and emerging Usage Areas; and (b) end users and consumers actively participating in content and service consumption and creation. Building this ecosystem will strongly influence the deployment of


Page 9 of 43

new wireless and wired infrastructures and will promote innovative business models and their acceptance by final users. FIWARE will be open, based upon elements (hereunder called Generic Enablers) which offer reusable and commonly shared functions serving a multiplicity of Usage Areas across various sectors. Altogether, such a platform will address the challenges described in the previous section. Note that not all functions that are common to applications in a given Usage Area may lead to the identification of Generic Enablers (GEs). It is the ability to serve a multiplicity of Usage Areas that distinguishes Generic Enablers from what would be labelled as Domain‐specific Common Enablers (or “Specific Enablers” for short), which are enablers that are common to multiple applications but all of them specific to a very limited set of Usage Areas. While not all elements that are suitable to be considered as Generic Enablers will be developed in the FIWARE project (this would be a goal that the FIWARE project alone, simply cannot afford), the intention is that all elements developed within FIWARE can widely be accepted as Generic Enablers, per definition above. Key goals of the FIWARE project are the identification and specification of GEs, together with the development and demonstration of reference implementations of identified GEs. Any implementation of a GE comprises a set of components and will offer capabilities and functionalities which can be flexibly customized, used and combined for many different Usage Areas, enabling the development of advanced and innovative Internet applications and services. The FIWARE Architecture comprises the specification of GEs, relations among them and properties of both. The Core Platform to be provided by the FIWARE project is based on GEs linked to the following main FIWARE Technical Chapters:

Cloud Hosting – the fundamental layer which provides the computation, storage and network resources, upon which services are provisioned and managed.

Data/Context Management – the facilities for effective accessing, processing, and analyzing massive volume of data, transforming them into valuable knowledge available to applications.

Applications/Services Ecosystem and Delivery Framework – the infrastructure to create, publish, manage and consume FI services across their life cycle, addressing all technical and business aspects.

Internet of Things (IoT) Services Enablement – the bridge whereby FI services interface and leverage the ubiquity of heterogeneous, resource‐constrained devices in the Internet of Things.

Interface to Networks and Devices (I2ND) – open interfaces to networks and devices, providing the connectivity needs of services delivered across the platform.

Security – the mechanisms which ensure that the delivery and usage of services is trustworthy and meets security and privacy requirements.

In order to illustrate the concept of GE, let’s analyze some of the GEs that have been initially identified as linked to one of the defined Architecture Chapters in FIWARE, e.g., the chapter linked to Data/Context Management Services. This chapter may comprise some sort of GE that allows compilation and storage of massive data from disparate sources. Note that this GE may in turn be based on a number of GEs, 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.), The Context/Data Management Service may also comprise a number of GEs dealing with processing of stored data, enabling generation/inference of new valuable data that applications may be interested to consume. It may finally comprise 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. To a large degree, the functionalities of the Generic Enablers will be driven by requirements from Application/ Service developers. Therefore, FIWARE will establish tools and processes that will help to closely collaborate with concrete Use Case projects dealing with development of concrete Application/Services. Discussions about requirements will require continuous interaction between the FIWARE project and partner Use Case projects. However, FIWARE development needs to be driven by requirements extrapolated for any future Application/ Service. Requirements that go beyond those of concrete Use Case projects will be brought by partners of the FIWARE consortia (based on input of their respective Businesses Units). A FIWARE product backlog will be generated from both sources and will be continuously updated, driving development of FIWARE following Agile principles.


Page 10 of 43

The FIWARE project will introduce a generic and extendible ICT platform for Future Internet services. The platform – also referred to as the “Future Internet Core Platform” or “FIWARE” – aims to meet the demands of key market stakeholders across many different sectors, strengthen the innovation‐enabling capabilities in Europe and overall ensure the long‐term success of European companies in a highly dynamic market environment.

The set of strategic goals of the FIWARE project are as follows:

To specify, design, and develop a Core Platform (hereunder referred to as “FIWARE”) to be a generic, flexible, trustworthy and scalable foundation, supporting the missions listed previously.

Design extension mechanisms so as to enable to support for yet unforeseen Usage Areas not being addressed initially. This requires a suitable extrapolation of current technology and business trends and their translation into the specific design and implementation principles of FIWARE.

To liaise between the project and relevant standardization bodies in order to: a) keep the project up‐to‐date with respect to the discussions in the standardization bodies; b) support the submission of contributions from the project in a coordinated way. The aim is to ensure active contribution of specifications leading to open standardized interfaces.

To implement and validate the FIWARE approach in trials together with Use Case projects in order to develop confidence for large scale investments in solutions for smart future infrastructures on national and European level.

To enable established players (telecoms, etc.) and emerging players in the services and application domains to tap into new business models by providing components, services, and platforms for these emerging players to innovate.

To support the development of a new ecosystem including agile and innovative Applications/Service providers consuming components and services from FIWARE thereby building new business models based on FIWARE and associated Usage Areas.

To stimulate early market take‐up by promoting project results.

2.3 FIWARE Generic Enabler Open Specifications, Compliant Platform Products, Instances Specifications of APIs (Application Programming Interfaces) and Interoperable Protocols supported by FIWARE Generic Enablers (GE) will be public and Royalty‐free. GE Open Specifications will contain all the information required in order to build compliant products which can work as alternative implementations of GEs developed in FIWARE. GE Open Specifications will typically include, but not necessarily will be limited to, information such as:

Description of the scope, behavior and intended use of the GE. Terminology, definitions and abbreviations to clarify the meanings of the specification. Signature and behavior of operations linked to APIs (Application Programming Interfaces) that the GE

should export. Signature may be specified in a particular language binding or through a RESTful interface. Description of protocols that support interoperability with other GE or third party products.

The FIWARE consortium intends to deliver a reference implementation for each of the Generic Enablers defined in the FIWARE 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 they don't desire. Note that not all components in a compliant implementation of a GE need to interoperate with components linked to implementations of another GE, nor provide APIs (Application Programming Interfaces) to Application Developers. While implementations of Generic Enablers developed in compliance with FIWARE GE Open Specifications should be replaceable, components linked to a particular implementation of a Generic Enabler may not.


Page 11 of 43

The FIWARE project will draw upon the wealth of results already achieved through earlier research projects, not only within the EU FP7 but also at national‐ or corporate‐funded levels, aiming to leverage them further through a systematic integration with a complete system perspective. In the FIWARE project, there is an equal focus on advancing technologies linked to Generic Enablers as well as integrating them in order to meet the actual requirements of all stakeholders. R&D activities in FIWARE will comprise:

Evolving components contributed by partners or available on the market in order to: o incorporate new features not covered by these components but required to implement GEs in the

context of the Future Internet, o allow GEs implemented through these components to be integrated (pluggable) with other GEs in

the FIWARE Architecture, Creating new components that may cover gaps in the FIWARE Architecture.

Products implementing FIWARE GEs can be picked and plugged together with complementary products in order to build FIWARE Instances, operated by so called FIWARE Instance Providers. Complementary products allow FIWARE Instance Providers to differentiate their offerings and implement their desired business models. For example, a company playing the FIWARE Instance Provider role may decide to develop and/or integrate their own set of monitoring/management tools, because this will allow it to benefit from a better integration with the tools already used by the company for the monitoring/managing of other services, therefore making operations much more efficient. FIWARE Instance Providers would also typically develop their own solutions for monetization of the services delivered through the FIWARE Instance they operate. This solution will typically imply integration with proprietary Billing or Advertising Support Systems. In this respect, GEs defined in FIWARE will not impose restrictions on the particular business model a FIWARE Instance Provider intends to implement. Note that the open nature of GE specifications will allow to replace a GE implementation developed in FIWARE within a particular FIWARE Instance. FIWARE GEs are further classified into core FIWARE GEs and optional FIWARE GEs. Core FIWARE GEs are required to be deployed in every FIWARE Instance.

FIWARE Instances


Page 12 of 43

2.4 The FIWARE Testbed and FI‐Lab The FIWARE project will generate a FIWARE Instance, hereunder referred to as FIWARE Testbed, which will allow partner Use Case projects (including a number of Use Case projects that are part of the European FI PPP initiative) to run and test Future Internet Applications based on FIWARE Generic Enablers. This FIWARE Testbed will be available shortly after delivery of the first FIWARE major release. FIWARE Instances linked to trials or commercial services (exploitation phase) are, in turn, referred to as “FIWARE Instances in production”. The FIWARE Testbed is aimed to be complete, in the sense that it will comprise reference implementations of all Generic Enablers defined in the FIWARE Architecture. The test bed will not necessarily be centralized, but will be under central control and be accessible from a dedicated website. The FIWARE partners will provide support to Use Case projects for the deployment of applications (e.g., the conceptual prototypes) on top of the FIWARE testbed. Tests run by the partner Use Case projects, coordinated with tests defined by the FIWARE project, will help to validate Generic Enabler Open Specifications, the reference implementations of FIWARE Generic Enablers developed within the FIWARE project, as well as the conceptual prototypes developed by Use Case projects. In order to pave the way for a successful exploitation and sustainability, the FIWARE project will work on setting up an Open Innovation Lab (FI‐Lab) similar to the FIWARE testbed after the second release of FIWARE. This FI‐Lab will support community involvement beyond the initial partner Use Case projects, offering a space where future innovations on top of the generic enablers provided by FIWARE can be nurtured. The availability of FI‐Lab per se does not guarantee innovation as such, therefore FI‐Lab will comprise all what is needed to stimulate awareness among target application providers and users so that they feel attracted to participate and build a community. It will also bring tools helping members of the community to share their experiences, needs, etc.

2.5 FIWARE in the context of the European Future Internet Public Private Partnership (FI‐PPP) Program

The FIWARE project will design, develop and implement the so‐called Core Platform within the European Future Internet Public Private Partnership (FI‐PPP) Program defined under the ICT FP7 Work Programme. More information about the Future Internet PPP initiative can be found at:

http://www.fi‐ppp.eu http://ec.europa.eu/information_society/activities/foi/lead/fippp/index_en.htm

The following figure illustrates the basic FI‐PPP approach, where several partner Use Case projects (eight in Phase 1 of the program) will cooperate with the FIWARE project to provide requirements about Generic Enablers which are distinguished from Domain‐specific Common Enablers (see previous sections). The identified requirements from the eight Use Case projects provide part of the requirements, which FIWARE has to fulfil. Other requirements come from other partner Use Case projects that may arise during lifetime of the FIWARE project or from the Business Units of the partners in the FIWARE Consortia.


Page 13 of 43

FI‐PPP Program

A first release of the reference implementation of GEs in FIWARE will be provided before the end of phase 1 in the context of the European Future Internet Public Private Partnership (FI‐PPP) programme and can be integrated to setup FIWARE Instances serving Usage Trial projects in phase 2 of that programme.

2.6 Business Ecosystem The following table describe the different roles in the overall value chain envisioned around FIWARE:

Role Description

FIWARE GE Provider Any implementer of a FIWARE GE. The open and royalty‐free nature of FIWARE GE specifications will allow parties other than partners in the FIWARE consortium to develop and commercialize platform products that are in compliance with FIWARE GE specifications.

FIWARE Instance Provider

A company or organization which deploys and operates a FIWARE Instance and establishes some sort of business model around that particular FIWARE Instance. Note that in building a FIWARE Instance, a FIWARE Instance Provider may rely on products being developed in the FIWARE project or products being developed by any sort of FIWARE GE Provider.

FIWARE Application/Service Provider

A company or organization which develops FI applications and/or services based on FIWAREGE APIs and deploys those applications/services on top of FIWARE Instances. Note that the open nature of FIWARE GE specifications will enable portability of FI applications and/or services across different FIWARE Instances.

While there are clear boundaries among these roles, a company/organization may take one or more of the roles defined above. Indeed, we foreseen it will be very common that some companies/organizations play one of these roles as its core role but will try to gain differentiation in the market or try to capture additional revenue streams by playing any of the other complementary roles. Thus, scenarios like the followings may apply:

A FIWARE Application/Service Provider may also play the role of FIWARE Instance Provider, deploying FIWARE Instances tailored to run the Applications and Services they have developed (i.e., following a sort


Page 14 of 43

of ASP model). Conversely, a FIWARE Instance Provider may decide to develop some Application/Services targeted to end customers on top of the same FIWARE Instance they offer to third‐party for development of their respective Application/Services.

A FIWARE Application/Service Provider may also decide to provide their own implementation of some GEs that will bring a differential value when bundled together with the final Application and Service they provide. Therefore, they may also play the role of GE provider.

A FIWARE Instance Provider may decide to be the Provider (implementer) of some of the GEs in the FIWARE Instance it operates. This may be because of costs (no need to buy licenses or pay per use of a particular FIWARE GE compliant product) or because it believes it may gain some differentiation by means of implementing part of the FIWARE GEs against other FIWARE Instance Providers.

Considering all the previous points, a company may decide to play all of the three roles. Many different business stakeholders will be part of the ecosystems creating Future Internet based applications and services. They are likely to have different business objectives and offerings. The following categorization summarizes the relevant stakeholders, the roles they are expected to play and, consequently, the impact FIWARE may induce: Established Telecom Industry

Telecom Service Providers: They will typically play the role of FIWARE Instance Providers as their core role, relying on FIWARE technologies to develop new open and innovative business models leveraging the assets they already have, i.e. exploring possibilities to "open up" their existing networks or the data they manage or connecting third Application/Services Providers with their large customer base. In general, trying to create a compelling ecosystems for Application/Services Providers that leverages on revenue share models. They, of course, will need to understand the technical hurdles, which need to be overcome. They can also play a relevant role as FIWARE GE Provider and accelerating the development of standards based on FIWARE results. They also may play the role of FIWARE Application/Service Providers, developing new services and applications for large Usage Areas where telecom‐based communication, security and availability levels as well as support to roaming users are required. Also to leverage their position as FIWARE Instance Provider or simply extend its portfolio, thus being able to keep growing in the Digital world.

Network equipment manufacturers (core and access networks): Develop and provide technical solutions to support Telecom Service Providers in their role as FIWARE Instance Providers. They may generate product/platforms covering a number of FIWARE GEs and provide services on which Telecom Service Providers may rely to implement their role as FIWARE Instance Providers or FIWARE Application/Service Providers. They can also play the role of FIWARE Application/ Service Providers, commercializing compelling ICT‐based services based on FIWARE which can be bundled together with other Application/Services in their portfolio to bring solutions to different Usage Areas or to enrich the Applications/Services ecosystem a given Telecom Service Provider wishes to build around the FIWARE Instance it operates.

Mobile terminal manufacturers: Develop and provide appropriate terminal devices with new features, M2M communication equipment and sensors for new application domains, which can interface easily with FIWARE Applications and Services. Some of these new capabilities may require they implement some FIWARE GEs, so that they are more suitable to run on their devices. Based on open standardized interfaces, economies of scale and affordable/interchangeable solutions for customers can be achieved.

IT Industry

Software vendors: They will typically play the role of FIWARE GE Provider. Therefore, they will explore, develop and provide new software components, services, middleware, business services (delivery) platforms and cloud‐based infrastructure components needed for emerging Future Internet applications and services in a converging IoT, IoS, and IoC environment.


Page 15 of 43

IT Providers: Many of them are evolving in a line similar to Telco Service Providers, therefore playing any of the three defined roles.

IT Solution integrators: They will typically play the role of FIWARE Application/Service Providers, adapting to the new challenges of developing and integrating new converged Telecom/IT solutions. They sometimes may decide to play the role of FIWARE Instance Providers, offering the outsourcing of all ingredients that are part of the solution.

Usage Areas The various stakeholders in the Usage Areas are expected to have very different objectives. Many of them suggest basic improvements of their business processes and the more efficient use of resources of any kind. Others request solutions to support them in the development of new cross‐sector solutions currently considered as complex to implement and operate. Both of them are in charge of supporting societal challenges either based on financial incentives or based on regulatory requirements. FIWARE is a key element to support the different sectors in their approach. Emerging Future Internet solution aggregators for converged services In a converged Future Internet ICT industry new challenges for developing/composing/deploying of (domain‐ or sector‐specific) solutions emerge. Established or new players especially from the SME sector will increasingly have to develop solutions in a world of complex service networks crossing telecom services. Therefore, they will play the role of FIWARE Application and Service Providers, thereby adapting their business models and technology know‐how appropriately. Note that convergence equally well applies to cross‐sector innovation concerning domain‐specific service providers, e.g. from the areas of logistics, healthcare, energy, services, where new services are composed by linking and services from different sectors and developing new business models around them. End users Further end users affected by the FI‐PPP and contributions of FIWARE are citizens, (non‐governmental) organizations, individuals, employees, and the generation of prosumers (possibly also aiming at generating their personal income). Solutions that have direct impact on this group of stakeholders are highly desirable Legal Notices bound to FIWARE Open Specifications

FIWARE Open Specification Legal Notice (essential patents license)

FIWARE Open Specification Legal Notice (implicit patents license)

2.7 Terms and definitions

Following are the definitions of some terms that are key to the FIWARE vision and are widely used. As mentioned before, the terms “Core Platform”, “CP” or “FIWARE” can be used indistinctly:

FIWARE Generic Enabler (GE): A functional building block of FIWARE. Any implementation of a FIWARE 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.


Page 16 of 43

FIWARE GE Open Specifications: GE Open Specifications will contain all the information required in order to build compliant products which can work as alternative implementations of GEs developed in FIWAREand therefore may replace a GE implementation developed in FIWARE within a particular FIWARE Instance. GE Open Specifications will typically include, but not necessarily will be limited to, information such as:

o Description of the scope, exhibited behavior and intended use of the GE. o Terminology, definitions and abbreviations to clarify the meanings of the specification. o Signature and behavior of operations linked to APIs (Application Programming Interfaces) that the

GE should export. Signature may be specified in a particular language binding or through a RESTful interface.

o Description of protocols that support interoperability with other GE or third party products. o Description of non‐functional features.

FIWARE Compliant Platform Product: A product which implements, totally or in part, a FIWARE GE or composition of FIWARE GEs (therefore, implements a number of FIWARE Services). Different FIWAREcompliant Platform Products may exist implementing the same FIWARE GE or composition of FIWARE GEs. Actually, the open and royalty‐free nature of FIWARE GE specifications allows the existence of alternative implementations of a FIWARE GE. FIWARE compliant Platform Products are made up of components. While implementations of Generic Enablers developed in compliance with FIWARE GE Open Specifications are replaceable, components linked to a particular FIWARE compliant Platform Product may not be replaceable.

FIWARE Generic Enabler implementation (GEi): A way to refer a FIWARE Compliant Product, or a component that is part of a FIWARE Compliant Product, implementing the Open Specifications of a given FIWARE GE.

FIWARE Instance: The result of the integration of a number of FIWARE compliant Platform Products and, typically, a number of complementary products. As such, it comprises a number of FIWARE GEs and supports a number of FIWARE Services. Provision of Infrastructure as a Service (IaaS) or Context/Data Management Services are examples of FIWARE Services a particular FIWARE Instance may support, implemented by means of combining a concrete set of Platform Products. While specifications of FIWARE GEs define FIWAREin functional terms, FIWARE Instances are built by means of integrating a concrete set of FIWARE compliant Platform Products.

FIWARE Instance Provider: A company that operates a FIWARE Instance. Note that FIWARE Instances may not consist only of the integration of FIWARE compliant Platform Products but their integration with other products which allow the FIWARE Instance Provider to gain differentiation on the market (e.g. integration with own Operating Support Systems to enhance FIWARE Instance operation or with other products supporting services that are complementary to those provided by FIWARE GEs) or to enable monetization of its operation (e.g., integration with own Billing or Advertising systems).

Future Internet Application: An application that is based on APIs defined as part of GE Open Specifications. A Future Internet Application should be portable across different FIWARE Instances that implement the GEs that Future Internet Application relies on, no matter if they are linked to different FIWARE Instance Providers.

FIWARE Testbed: A concrete FIWARE Instance operated by partners of the FIWARE project that is offered to Use Case projects within the FI‐PPP Program, enabling them to test their proof‐of‐concept prototypes. The FIWARE Testbed is also offered to third parties to test their Future Internet Applications although support to them is provided on best‐effort basis.

FIWARE Instance in production: A FIWARE Instance run by a FIWARE Instance Provider in the context of a trial (e.g., trials in phase 2 of the European FI PPP initiative) or as part of its service offering to the market. FIWARE Instances in production will typically have their own certification and developers community support environments. However, several FIWARE Instance Providers may establish alliances to setup common certification or developers’ community support environments.


Page 17 of 43

3. FIWARE Architecture

3.1 FIWARE Architecture Following is a description of the Reference Architecture linked to the different chapters of FIWARE. A description of FIWARE Generic Enablers (GEs) being supported in each chapter is provided, including the high‐level description of the APIs that each FIWARE Generic Enabler (GE) exposes to application developers or it uses to connect to another FIWARE GEs.

Cloud Hosting Data/Context Management Internet of Things (IoT) Services Enablement Applications/Services Ecosystem and Delivery Framework Security Interface to Networks and Devices (I2ND) Advanced Middleware and Web‐based User Interface

The Reference Architecture associated to each FIWARE chapter can be instantiated into a concrete architecture by means of selecting and integrating products implementing the corresponding FIWARE GEs (i.e., products which are compliant with the corresponding FIWARE GE Open Specifications). However, the description of the Reference Architecture associated to a chapter does not depend on how FIWARE GEs in that chapter can be implemented. Any implementation of a FIWARE GE (also referred as FIWARE GEi) will be, by nature, replaceable. Application developers reading contents of this document will understand how applications are programmed using APIs exposed by FIWARE GEs (i.e., what is the programming model). They will learn what the names are, basic description of arguments, behavior and responses of the main operations in those APIs. On the other hand, FIWARE Instance Providers will learn how FIWARE GEs can be connected to build FIWARE Instances. Complementing description of the FIWARE Reference Architecture you can visit the Summary of FIWARE Open Specifications to learn the rest of details about FIWARE GE Open Specifications, particularly detailed API Open Specifications. Note that FIWARE GE Open Specifications will be public and royalty‐free. Developer Community and Tools (DCT) wants to offer a comprehensive environment enabling the FI‐PPP program developers (and others) to use in the more efficient, easy and effective way the FIWARE outcomes (i.e. GE Implementations and FIWARE Instances) and exploiting collaboration means to benefit the support of the community. For more details visit the following link.

Developer Community and Tools

3.2 FIWARE Architecture Overview The following diagram depicts the schema behind the FIWARE platform the major components (the so called Generic Enablers, or GEs) and the roles interacting with the system. Find below a short introduction to the major building blocks of the FIWARE, the FIWARE chapters and their major components.


Page 18 of 43

Schematic depiction of FIWARE platform with all major chapters

Developer Community and Tools Architecture The primary goal of the Developer Community and Tools (DCT) is to offer a multi‐functional development environment ‐ FI‐CoDE ‐ enabling the development and management of the Future Internet Applications (FIApp) built to address the needs of the Future Internet and based on the adoption and integration of the Generic Enablers Implementations. Applications/Services Ecosystem and Delivery Framework The Generic Enablers (GE) for the Apps Chapter together build an ecosystem of applications and services that is sustainable and fosters innovation as well as cross‐fertilization. In particular the Apps Generic Enablers supports managing services in a business framework across the whole service life cycle from creation and composition of services to monetization and revenue sharing. A couple of basic GEs are important to realize the vision of such a service business framework which enables new business models in an agile and flexible way. Among them: a store, a marketplace, a revenue sharing engine, a set of service composition enablers and a mediator. The Business Framework is heavily relying on USDL as common uniform description format for services which does not only focus on technical aspects of service, but also on business aspects as well as functional and non‐functional service attributes.


Page 19 of 43

Data/Context Management The Data/Context Management FIWARE chapter aims at providing outperforming and platform‐like GEs that will ease development and provision of innovative Applications that require gathering, publication, processing and exploitation of information and data streams in real‐time and at massive scale. Combined with GEs coming from the Apps Chapters, Application Providers will be able to build innovative business models based on exploitation of massive data provided by end users. FIWARE Data/Context Management GEs allow to gather information from context and other sources (Context Broker), mediate metadata among GEs and applications (Metadata pre‐processor) query stored information through an homogeneous layer (Query Broker), , annotate existing information (Semantic Annotation), store and manage semantic information (Semantic Application Support), generate new knowledge from big data stores using a Map & Reduce paradigm (Big Data analysis) and react to different types of scenarios (Complex Event Processing). It also provides GEs for media management, as easy creation of advanced video applications (Stream Oriented GE) and specifically, video analysis in the compressed domain (CDVA). Interface to Networks and Devices (I2ND) FIWARE will build the relevant Generic Enablers for Internet of Things Service Enablement, in order for things to become citizens of the Internet –available, searchable, accessible, and usable – and for FI services to create value from real‐world interaction enabled by the ubiquity of heterogeneous and resource‐constrained devices. I2ND defines an enabler space for providing Generic Enablers (GEs) to run an open and standardized network infrastructure. The infrastructure will have to deal with highly sophisticated terminals, as well as with highly sophisticated proxies, on one side, and with the network operator infrastructure on the other side. This latter will be implemented by physical network nodes, which typically are under direct control of an operator, or the node functionality will be visualized – in this case the I2ND functionality can be accessed by further potential providers, like virtual operators. The I2ND architecture covers the following Generic Enablers (GEs): CDI (Connected Device Interface) towards the Connected Devices, CE (Cloud Edge) towards the Cloud Proxies, NETIC (NETwork Information and Control) towards Open Networks and S3C (Service Capability, Connectivity and Control) towards Underlying Networks. Internet of Things (IoT) Services Enablement The deployment of the architecture of the IoT Service Enablement chapter is typically distributed across a large number of Devices, several Gateways and the Backend. A device is a hardware entity, component or system that either measures properties of a thing/group of things or influences the properties of a thing/group of things or both measures/influences. Sensors and actuators are devices. IoT Resources are computational elements (software) that provide the technical means to perform sensing and/or actuation on the device. The resource is usually hosted on the device. IoT GEs have been spread in two different domains: Gateway and Backend. While IoT Gateway GEs provide inter‐networking and protocol conversion functionalities between devices and the IoT Backend GEs, the IoT Backend GEs provide management functionalities for the devices and IoT domain‐specific support for the applications. Cloud Hosting The Cloud Chapter offers Generic Enablers (GEs) that comprise the foundation for designing a modern cloud hosting infrastructure that can be used to develop, deploy and manage Future Internet applications and services. Provided hosting capabilities are of several kinds and at several levels of resource abstraction ‐‐ aiming at the needs of different applications hosted on the cloud.


Page 20 of 43

The IaaS Data Center Resource Management (DCRM) GE is offering provisioning and life cycle management of virtualized resources (compute, storage, network, etc.) associated with virtual machines. The Object Storage GE offers provisioning and life cycle management of object‐based storage containers and elements. The Job Scheduler GE offers the application to submit and manage computational jobs in a unified and scalable manner. The Edgelet Management GE offers the capability to host lightweight application components, called edgelets. Moreover, the IaaS Service Management (SM) GE provides the means to host complex applications. Lastly, the PaaS Management GE uses the above capabilities to offer provisioning and management of complete PaaS environments, leveraging also the Software Deployment and Configuration (SDC) GE which offers a flexible framework for installation and customization of software products (via Chef Recipes) within individual virtual machines. Security The Future Internet services will always be exposed to different types of threats that can lead to severe misuse and damage. Creating secured and trusted services without sacrificing much of the desired functionality, usability, performance and cost efficiency is a great challenge, especially in a dynamic environment where new threats and attack methods emerge on a daily basis. The overall ambition of the Security Architecture of FIWARE is to demonstrate that the Vision of an Internet that is "secure by design" is becoming reality. Based on achievements to date and/or to come in the short‐term (both from a technological but also a standardization perspective) we will show that "secure by design" is possible. Security, Privacy and Trust in FIWARE is mainly focusing on delivering tools and techniques to have the above‐mentioned security needs properly met. Furthermore a decision making support and the automation of countermeasures allow alleviating the workload of users and administrators while raising their security awareness. The high‐level Reference Architecture is formed by four main blocks of GEs: Security monitoring, Generic Security Services like Identity Management, Access Control, Privacy, Data Handling; Context‐Based Security and Compliance and optional Generic Security Services: DB Anonymizer, Secure Storage Service, Malware Detection Service, Android Flow Monitoring and Content‐based Security. Advanced Middleware and Web‐based User Interface The Generic Enablers (GEs) from the Advanced Middleware and Web‐based User Interface (MiWi) chapter cover a novel middleware for highly efficient and secure communication between distributed applications and well as a set of GEs that provide an advanced user experience using HTML‐5 and a Web‐based UI approach. The Advanced Middleware is backward compatible with traditional Web services (e.g. REST) but offers advanced features and performance and dynamically adapts to the communication partners and its environment. It offers "Security by Design" through a declarative API, where the application defines the security requirements and policies that are then automatically enforced by the middleware. The objective of the Advanced Web‐based UI GE is to significantly improve the user experience for the Future Internet by adding new user input and interaction capabilities, such as interactive 3D graphics, immersive interaction with the real and virtual world via Augmented Reality, virtualizing the display and driving them over the network, and many more. Developer Community and Tools Architecture The primary goal of the Developer Community and Tools (DCT) is to offer a multi‐functional development environment ‐ FI‐CoDE ‐ enabling the development and management of the Future Internet Applications (FIApp) built to address the needs of the Future Internet and based on the adoption and integration of the Generic Enablers Implementations.


Page 21 of 43

3.3 FIWARE Roles The FIWARE project intends to support the development of innovation‐driven value chains around Applications and Services. These value chains are materialized by a number of actors playing various roles supported by FIWARE technologies. The following table describes the different roles envisioned for the FIWARE‐enabled value chains. While there are clear boundaries among the following roles, a company/organization may take one or more of the roles defined. Indeed, we foreseen it will be very common that some companies/organizations play one of these roles as its core role but will try to gain differentiation in the market or try to capture additional revenue streams by playing any of the other complementary roles.

Role Description

Application Developer

Future Internet Application Developers are encouraged to develop smart applications targeting either mass markets or individual enterprises and organizations (which in turn may have a limited number of users or, again, the mass market as end users). These Applications should offer flexible means for deployment, provisioning and runtime operation “on the Cloud”. Future Internet Applications are intended to be meaningful and stand‐alone, implementing a number of functions they export “as a Service” to End Users through a number of User Interfaces but also to third Applications in some cases, through well‐defined Service APIs (Application Programming Interfaces). They typically rely on functions provided by a number of Enablers, which can be specific to the Application Domain or Generic (meaning they are general purpose).

Enabler Developer Enabler Developers are encouraged to develop software components or more complex systems that can be instantiated to provide functions easing the development, provisioningand/or runtime operation of Future Internet Applications. Enablers are intended to be universal, that is, they refer to multiple Applications that rely on the functions they implement. Those functions are exported “as a Service” to third Applications through well‐defined Service APIs and also to Admin and End Users in some cases, through a number of User Interfaces. Enabler Developers may integrate several lower‐level Enablers to realize new and more powerful Enablers. Note that Applications and Enablers resemble each other in their architecture since both implement functions that they export as services. The central differentiator between them is the primary users to be addressed (End Users in the case of Applications, other Applications in the case of Enablers). Note, however, that some products may qualify equally as Applications or Enablers.

(Application/ Enabler) Service Provider & value added service providers

Service Providers are in charge of deploying, provisioning and operating either Applications or Enablers. Stakeholders playing the Application/Enabler Developer role may also play this role. However, this is not always the case (e.g., a Public Administrator may be playing the Service Provider role with respect to applications developed by third parties that the city offers to its citizens). Application and Service Providers mainly participate in an ecosystem enabled with FIWAREtechnology through provisioning, consuming or discovering of services in relation to their business. A service provider is in general active in one business domain where his main business model is residing, but potentially is enable to be active in other business domains, enabled through FIWARE technology. As a sub‐role the value‐added service provider will be enabled to build innovative services and apps on top of the offerings other providers within and crossing the ecosystem.

(Application/ Enabler) Service Hosting Provider

Service Hosting Providers provide and operate the hosting infrastructure on top of which Applications or Enablers are deployed. They entwine themselves with the Service Providers to reduce the costs for service provision.


Page 22 of 43

Role Description

Service Hosting Providers may provide Cloud Services for hosting Applications and Enablers. Note that, in that case, they can indeed be considered a concrete case of Enabler Service Provider (here, the Enabler is the Cloud providing hosting services) so they may be also referred as “Cloud Hosting Provider”. In many cases, an entity playing the Enabler Service Provider role also hosts the Enablers it provides, therefore also playing the Enabler Service Hosting Provider role. However, note that this is not strictly required (one may think about a Enabler Service Provider that provides a number of enablers, all of them being deployedon Amazon hosting services).

(Application/ Enabler) Service Aggregators

Service Aggregators select Services from a broad variety of Service Providers and compose them to build new service offerings that address the specific requirements of niche End Users. (Application/Enabler) Service Brokers bring together a multitude of Services from diverse Providers and publish them on marketplaces where end users can compare them, matching their requirements with capabilities of published Services ‐ they should exploit economies of scale and protect investments in the long run. Finally, the ability to combine applications from different sources necessitates innovative revenue sharing models across partners and potentially also customers (e.g. crowd‐sourcing) which have to be adapted dynamically as market conditions change.

FIWARE Instance Providers

An instance provider operates and provides one particular FIWARE instance to a given ecosystem or business domain or to a use case project. He assembles a given set of Generic Enablers and defines a scenario and usage domain for the particular FIWARE Instance. Finally he provisions information about how to use the instance, defines his terms and conditions and enables others to work and collaborate on top of the given FIWARE instance. Note that not all the FIWARE GEs have to be integrated in a given FIWARE Instance. As an example, a FIWARE Instance may only incorporate GEs from the Cloud and Data/Context Management Chapter.

Roles in relation to the FIWARE Open Innovation Lab

There are a number of upcoming roles, which will play a leading role in the “FIWARE Open Innovation Lab”, yet to be defined.


Page 23 of 43

4. Summary of FIWARE Open Specifications

4.1 Overview This page summarizes the available FIWARE Open Specifications.

4.2 About This Document FIWARE GE Open Specifications describe the open specifications linked to Generic Enablers GEs of the FIWARE project (and their corresponding components) being developed in one particular chapter. GE Open Specifications contain relevant information for users of FIWARE to consume related GE implementations and/or to build compliant products which can work as alternative implementations of GEs developed in FIWARE. The later may even replace a GE implementation developed in FIWARE within a particular FIWARE instance. GE Open Specifications typically include, but not necessarily are limited to, information such as:

Description of the scope, behavior and intended use of the GE, Terminology, definitions and abbreviations to clarify the meanings of the specification, Signature and behavior of operations linked to APIs (Application Programming Interfaces) that the GE

should export. Signature may be specified in a particular language binding or through a RESTful interface, Description of protocols that support interoperability with other GE or third party products, Description of non‐functional features.

4.3 Intended Audience The document targets interested parties in architecture and API design, implementation and usage of FIWARE Generic Enablers from the FIWARE project.

4.4 FIWARE Open Specifications Following is the list of FIWARE Open Specifications structured by chapter. If you are looking for a concrete FIWARE GE API Open Specification, you may directly navigate to the Summary of FIWARE API Open Specifications.

4.5 Cloud Hosting Chapter

FIWARE.OpenSpecification.Cloud.DCRM FIWARE.OpenSpecification.Cloud.ObjectStorage FIWARE.OpenSpecification.Cloud.PolicyManager FIWARE.OpenSpecification.Cloud.SDC FIWARE.OpenSpecification.Cloud.PaaS FIWARE.OpenSpecification.Cloud.Monitoring FIWARE.OpenSpecification.Cloud.SelfServiceInterfaces FIWARE.OpenSpecification.Cloud.JobScheduler FIWARE.OpenSpecification.Cloud.Edgelets FIWARE.OpenSpecification.Cloud.SM [DEPRECATED] FIWARE.OpenSpecification.Cloud.CloudEdge [see Interface to the Network and Devices chapter]


Page 24 of 43

4.6 Data/Context Management Chapter

FIWARE.OpenSpecification.Data.BigData FIWARE.OpenSpecification.Data.ContextBroker FIWARE.OpenSpecification.Data.CEP FIWARE.OpenSpecification.Data.Location FIWARE.OpenSpecification.Data.MetadataPreprocessing FIWARE.OpenSpecification.Data.CompressedDomainVideoAnalysis FIWARE.OpenSpecification.Data.QueryBroker FIWARE.OpenSpecification.Data.SemanticAnnotation FIWARE.OpenSpecification.Data.SemanticSupport FIWARE.OpenSpecification.Data.StreamOriented FIWARE.OpenSpecification.Data.UnstructuredDataAnalysis FIWARE.OpenSpecification.Data.SemanticContextExt

4.7 Internet of Things (IoT) Services Enablement Chapter Backend

FIWARE.OpenSpecification.IoT.Backend.IoTBroker FIWARE.OpenSpecification.IoT.Backend.ConfMan FIWARE.OpenSpecification.IoT.Backend.DeviceManagement

Gateway

FIWARE.OpenSpecification.IoT.Gateway.DeviceManagement FIWARE.OpenSpecification.IoT.Gateway.DataHandling FIWARE.OpenSpecification.IoT.Gateway.ProtocolAdapter

Notes for traceability:

For R2 onwards, the former "Backend Things Management GE" has been split into the "Backend ConfMan" and the "Backend IoT Broker" keeping all previous functionalities and interfaces.

4.8 Applications/Services Ecosystem and Delivery Framework Chapter

FIWARE.OpenSpecification.Apps.Repository FIWARE.OpenSpecification.Apps.Marketplace FIWARE.OpenSpecification.Apps.Registry FIWARE.OpenSpecification.Apps.BusinessModeler FIWARE.OpenSpecification.Apps.BusinessCalculator FIWARE.OpenSpecification.Apps.Mediator FIWARE.OpenSpecification.Apps.ServiceMashup FIWARE.OpenSpecification.Apps.ApplicationMashup FIWARE.OpenSpecification.Apps.ServiceComposition FIWARE.OpenSpecification.Apps.LightSemanticComposition FIWARE.OpenSpecification.Apps.Store FIWARE.OpenSpecification.Apps.RSS


Page 25 of 43

4.9 Security Chapter Core Generic Enablers

FIWARE.OpenSpecification.Security.SecurityMonitoring FIWARE.OpenSpecification.Security.Context‐based_security_and_compliance FIWARE.OpenSpecification.Security.IdentityManagement FIWARE.OpenSpecification.Security.Data Handling Generic Enabler FIWARE.OpenSpecification.Security.Privacy Generic Enabler FIWARE.OpenSpecification.Security.Access Control Generic Enabler

Optional Generic Enablers

FIWARE.OpenSpecification.Security.Optional_Security_Enablers.DBAnonymizer FIWARE.OpenSpecification.Security.Optional_Security_Enablers.SecureStorageService FIWARE.OpenSpecification.Security.Optional_Security_Enablers.ContentBasedSecurity FIWARE.OpenSpecification.Security.Optional_Security_Enablers.MalwareDetectionService FIWARE.OpenSpecification.Security.Optional_Security_Enablers.AndroidFlowMonitoring

Interface to Networks and Devices (I2ND) Chapter

FIWARE.OpenSpecification.I2ND.CDI FIWARE.OpenSpecification.I2ND.CE FIWARE.OpenSpecification.I2ND.NetIC FIWARE.OpenSpecification.I2ND.S3C

4.10 Advanced Middleware and Web User Interfaces Chapter Advanced Middleware

FIWARE.OpenSpecification.MiWi.Middleware Advanced Web UI) Enablers ‐ Client Core

FIWARE.OpenSpecification.MiWi.2D‐UI FIWARE.OpenSpecification.MiWi.3D‐UI

Advanced Web UI) Enablers ‐ Server Core

FIWARE.OpenSpecification.MiWi.Synchronization Advanced Web UI) Enablers ‐ Supporting Services

FIWARE.OpenSpecification.MiWi.CloudRendering FIWARE.OpenSpecification.MiWi.GISDataProvider FIWARE.OpenSpecification.MiWi.POIDataProvider FIWARE.OpenSpecification.MiWi.2D‐3D‐Capture

Advanced Web UI) Enablers ‐ Application oriented Services

FIWARE.OpenSpecification.MiWi.AugmentedReality FIWARE.OpenSpecification.MiWi.RealVirtualInteraction FIWARE.OpenSpecification.MiWi.VirtualCharacters FIWARE.OpenSpecification.MiWi.InterfaceDesigner


Page 26 of 43

5. FIWARE Technical Roadmap FIWARE's technical roadmap brings information about what the different major releases of FIWARE will bring and when they will be available on the FIWARE Testbed. For each of the FIWARE chapters and for every generic enabler, the list of features available for the particular release is linked within the following pages. You can explore which release number the particular features are currently scheduled for and contact the affiliated responsible persons in charge if you need more details. The first version of the FIWARE platform was made available on the FIWARE Testbed during 3Q2012 for experiments by the use case projects within the FI‐PPP program. The overall goal for this first Release was to provide a sufficiently complete set of FIWARE GEs which Use Case Projects selected in the first phase of the FI‐PPP program could test and use in their proof of concepts. The second release of FIWARE is focused on integration (both inside and across chapters) as well as evolution of FIWARE GEs based on feedback from target Users (both Use Case Projects selected in the first phase of the FI‐PPP or other stakeholders like current/target customers of FIWARE partners). Once the development of a given minor release of FIWARE is finished, it can be made available on the testbed, typically by the end of the following month. Updates of all FIWARE GEs on the FIWARE Testbed will be planned after each major release completion. Nevertheless, updates of the FIWARE Testbed may be decided on a more frequent basis at FIWARE GE level, i.e., the following month after completion of some Sprint. Please check the Releases and Sprints numbering, with mapping to calendar dates for further information. FIWARE's Technical Roadmap is broken into 8 partial roadmaps, one per FIWARE Technical Chapter:

Roadmap of Cloud Hosting Roadmap of Data/Context Management Roadmap of Internet of Things (IoT) Services Roadmap of Applications/Services Ecosystem and Delivery Framework Roadmap of Security Roadmap of Interface to Networks and Devices Roadmap of Advanced Middleware and Web UI Roadmap of Developers Community and Tools

Besides the roadmap of functional features per chapter, a Roadmap of Global FIWARE functions is defined. Important Note: it is important to mention that most (if not all) of the Generic Enabler implementations are based on existing baseline assets (open source or proprietary), actively developed and promoted by the corresponding companies. Each company has done internal analysis of requirements and priorities for each of the technologies, based on their business needs and the needs of their customers. The goal of FIWARE is to develop these assets even further, to integrate them together to form a coherent platform, and to offer them to the FI‐PPP ecosystem, for the benefit of the community. This roadmap reflects this approach.


Page 27 of 43

6. FIWARE Agile Development Methodology by Juanjo Hierro, Chief Architect and Technical Manager of FIWARE

6.1 Prologue This section elaborates on how Agile principles are being applied in FIWARE. The approach being adopted has been very much inspired in the work carried out by Dean Leffingwell with Juha‐Markus Aalto on how to apply Agile in development of large systems. We first advice you should read Dean Leffingwell's and Juha‐Markus Aalto's white paper on a lean and scalable requirements information model for agile enterprises. Much of the methodology we are following comes from this source. We have further refined some of the definitions, and elaborated some of the concepts, described there in order to manage such a complex and large project like FIWARE. We assume that you already know the basis about Agile. Information in this page doesn't intend to be a stand‐alone and complete tutorial on Agile. Please take this into account.

6.2 About Epics, Features, User Stories and Work Items Entries in Backlogs used in FIWARE can be of any of the following types:

Epic Feature User Story Work Item Reported Bug

The Backlog in a product development project is fundamentally about "functionality that has to be developed" in the product. Seeking for clarity, and because I have found it helpful when explaining Agile concepts, I have explained that entries in the backlog indeed map into "work to be done". Actually, a lot of the work you have to do when developing a software product has to do with developing the software that implements the functionality the users expect from your product and it is the description of functionality to be supported in your product what we intend to capture through Themes, Epics, Features or User‐Stories. The rest of the work may be categorized as Work Items (creating specific parts the documentation, solving a support ticket, running an analysis or defining part of the API spec before we actually implement it, etc.).


Page 28 of 43

Epics, Features or User Stories describe functionality at different level of granularity. Epics describe functionality at a very high level. Epics are further refined into Epics, Features and User stories. When should I label a given backlog entry as an Epic, a Feature or a User‐Story? User Stories comply with "INVEST" properties which means they should be "Independent, Negotiable, Valuable, Estimable, Small and Testable". In general:

A User Story has to be something sufficiently limited in scope as to be affordable in one Sprint, unitary tests included. ("Small" property)

A User Story should be detailed enough as to be able to define a test for it. ("Testable" property) A User stories should include enough information enabling a developer to make a rough estimation of the

resources needed for designing, developing, and testing the functionality within one Sprint ("Estimatable" property).

There is no need to cover all details nor to have everything finalized before starting actual development. In other words, you shouldn't enter into that level of detail at which you are probably wasting time and unnecessarily delaying development. Just have the details that make you confident that development may fit in the duration of the Sprint. There should be details that may be worked out while developing. ("Negotiable" property).

"Independent" and "Valuable" are also relevant characteristics but I guess there may be many Epics and Features that would fulfill those properties. That's why I would make emphasis on the previous ones. Therefore, based on the above, you should ask your development teams the following questions to determine whether a new entry you want to insert in the backlog should qualify as an User‐Story or not:

Can you commit to get it developed by the end of the next Sprint? Would you be able to define a test for it?

If their answer to these questions is "No" or you see the doubt in their eyes ... it's not a User‐Story. Note that labeling an entry as User‐Story in the backlog depends very much on a fundamental parameter of your project: the duration of a Sprint. In this respect, Sprints are defined to last one month in FIWARE. What could be labeled as a User‐Story would vary a lot if we had defined a different duration for Sprints. You can consider a Feature just as a special kind of Epic. What Epics can be labeled as Features? Those describing functionality that you feel confident you will be able to develop in the course of a Product Release. Therefore, labeling an entry as Feature in the backlog depends very much on another fundamental parameter of your project: the duration of a Release. Duration of a Release should be a multiple of the duration of a Sprint and use to be 60 to 120 working days long. In this respect, Releases (also named as minor Releases) in FIWARE last three months. We have also introduced the concept of Major Releases which last a determined number of minor Releases. Therefore, we use a two digit notation to identify a Release (e.g., Release 1.3) Note that being able to state that you expect a given functionality described as an Epic to be implemented in your product by the duration of a Release simply means that you have enough information about the functionality as to feel confident that you will be able to refine it to the level of User‐Stories which, in turn, can be addressed in development sprints, all during the course of the Release. Why are we dealing with Features in addition to Epics? Because it gives hints about what functionality we expect to address within a certain period of time and this is important for the overall management of a large product development project like FIWARE and helps to share valuable information with customers about our product roadmap. Users need to have some hints on what functionality is going to be available when, so that they can plan their developments better. Other than this, you may think on Features as just Epics you expect to develop before some given date. Of course, Agile is about re‐planning the work to be done whenever you feel necessary and priorities change. That means that a Feature you initially planned for Release 2.1 of your product may get delayed and postponed for a later Release.


Page 29 of 43

Recursive Epics allow to refine abstract conceptual items as much as needed, but is not that critical as the frontier between Epics and Features or User Stories. Deriving a Feature allows us to map the corresponding functionality into a product Release. Deriving a User‐Story means you can stop refining and start actual development of a concrete functionality in your product. Whenever you derive a new backlog entry, either as result of refining previously existing Epics or Features or just because it captures new functionality, you should ask yourself: "Is the description of this functionality detailed enough as to make it affordable in the course of a Sprint? Does it own the desired INVEST properties?". If the answer is "Yes", then you should label it as a User‐Story. If not, then you should ask yourself: "Is the description of this functionality detailed enough as to make it affordable in the course of a Release?". If the answer is "Yes", then you should label it as a Feature. Otherwise, it is an Epic. When you derive a User‐Story directly from an Epic, we recommend to create a Feature with the same description. You may think in a first approach that this is unnecessary duplication of entries, but this will allow to keep a complete description of planned features for all Releases, which is important in large products/systems. Note than a given Epic may be refined into several entries, each linked to a finer‐grained description of the target functionality, but still to be considered as an Epic. Last but not least, an Epic may also be refined into a mixture of several Epics, Features and User Stories. This is natural consequence of first deriving the finer‐grained entries and then categorize them properly. A Work item refers to work that needs to be done in the course of a Sprint, trying to meet a concrete goal. It may relate to work to be done in order to refine an existing Epic (or a feature) and derive actual Features (or User‐stories) derived from it. In general, any work you need to address to progress development but may be difficult to describe in terms of "functionality supported by the product". Work Items help to report activities performed by your development team you want to report because it consumes a significant amount of resources and you want to leave a trace of that. They are also extremely helpful in monitoring progress at a higher‐level, which is something that is always needed in development of a large product/system. You may derive a mixture of finer‐grained Epics plus a list of Features, User‐Stories and Work Items when you refine an existing Epic. Similarly, you may obtain finer‐grained Features, plus a list of User Stories and Work Items when you refine an existing Feature. A Reported bug refers to work needed to fix malfunction of functionality developed. It allows to have them identified and be addressed at a specific sprint or release. To illustrate this, let's consider a concrete example. You may find out that your system needs to provide some sort of Directory functionality. In a first approach, you may have identified an Epic linked to this functionality. Here you are the description of the Goal linked to that Epic: As a user I can create/delete/modify entries in a Directory and then retrieve entries using different methods You may afterwards turn this Epic into three Features A, B and C:

A = As a user I can create/delete/modify entries in the Directory. B = As a user I can discover entries that match some given criteria, expressed in a query language similar to

SQL. C = As a user I can subscribe to events linked to creation/deletion/modification of entries in the Directory.

Those events are received spontaneously, through a callback service I can register linked to my subscription. Subscriptions may have a lifetime, be paused, resumed and canceled.

(Note: you should, of course, provide a more detailed description for each of these features in real life, but let's keep it simplified here for convenience) You may decide that such Features will be exposed through a well‐defined API. Therefore, all the three Features may get refined into:

a WorkItem M = Specifying a well‐defined REST interface 'I' through which operations linked to features A and B are exposed

another WorkItem N = Extending specifications of interface 'I' to include operations supporting feature C


Page 30 of 43

three UserStories O, P and Q corresponding to implementation of the operations in the REST interface 'I' linked to features A, B and C respectively.

When dealing with realization of the backlog through subsequent Sprints, it may happen that you decided to address WorkItem M in Sprint X of the Release 1.1 and then in Sprint X+1, also part of the same Release, you decided to address the implementation of UserStories O and P, leaving WorkItem N and UserStory Q to the Release 1.2. This illustrates a major concept in how Agile works differently than the traditional waterfall models: we are not waiting for finalizing the complete specification of interface 'I' to start implementing part of it.

6.3 Creating the first version of the FIWARE backlogs In defining how we were going to use Agile in FIWARE, we have had to deal with a fundamental characteristic of the project: it is not about developing from the scratch but from a set of selected products (assets) resulted from previous projects, many of which hadn't been developed using Agile. If we had started development of every FIWARE Generic Enabler (that's the way we name components in FIWARE) from the scratch, the FIWARE GE backlogs would contain Themes/Epics/Features/User‐stories that, all together, would summarize the whole functionality of FIWARE. But this is not the case. When creating the backlog for a given FIWARE GE, we have considered that it should contain the Themes/Epics/Features/User‐stories that, at the start of the FIWARE project, map to "functionality to be developed" in the reference implementation of the GE we are building based on a number of baseline products. We won't capture all the functionality that was already implemented in the baseline products. That would mean trying to carry out a kind of "reverse engineering" of baseline products, deriving User‐Stories from what those baseline products already support. This, apart from meaning a huge effort would not be that useful to development teams and would simply delay start of our development. Something which would precisely go against a cornerstone axiom in Agile: trying to do things that are useful for the development teams. Thus, a potential user who wants to have a detailed picture of all target functionality to be supported by a given FIWARE GE should study:

the FIWARE Product Vision, in order to understand what is overall expected for the GE, the documentation about the products that have been adopted as baseline for the reference

implementation of the GE (available on Materializing the FIWARE Vision): this should give the user a clear picture of what functionality has already been covered and therefore will be supported in FIWARE,

the backlog linked to the GE (also available on Materializing the FIWARE Vision: this will allow the user to understand what's going on and is planned on the roadmap.

In summary: the FIWARE backlogs were created to drive developments to be carried out after the FIWARE project started. They are not about documenting what he have done during many years in our respective labs.

6.4 Management of the FIWARE Backlog The FIWARE project uses a Product Backlog to drive the development of the reference implementations of Generic Enablers (GE) in FIWARE. You can find a full description of all the Themes, Epics, Features and User‐Stories linked to each FIWARE Chapter and GE visiting the FIWARE Wiki section on Materializing the FIWARE Vision. FIWARE deals with management of the lifecycle of Backlog entries using FusionForge trackers. Each FIWARE chapter owns a Backlog Management tracker (access only allowed to FIWARE Chapter members):

Cloud Hosting Backlog Management tracker Data/Context Management Backlog Management tracker IoT Services Enablement Backlog Management tracker Apps/Services Ecosystem and Delivery Backlog Management tracker Security Backlog Management tracker Interface to Networks and Devices Backlog Management tracker


Page 31 of 43

Any ticket created in a given Chapter tracker is linked to a Theme/Epic/Feature/User‐story described on the Wiki. Work Items to be carried out also have a ticket on the proper Chapter tracker. Note that Work Items are not documented on the Wiki. We have taken this decision in FIWARE because Themes/Epics/Features/User‐stories are the only Backlog entries that are relevant to FIWARE users. Sprints and Releases are numbered according to the schema defined for Releases and Sprints numbering There is a comprehensive set of tutorials explaining FIWARE project members:

How to assign identifiers to FIWARE Backlog entries (convention to follow) How to upload the full description of backlog entries to the Wiki How to create and configure trackers in FusionForge How to create entries in the "Backlog Management" Tracker of a FIWARE Chapter How to follow‐up a tracker in FusionForge

6.5 Requesting the addition of new entries to the FIWARE Backlog FIWARE users can issue request for the addition of new Epics or Features in FIWARE, linked to existing Generic Enablers or proposals for new ones. They do so by creating tickets on the FIWARE Epic/Feature Requests tracker In order to get access to the FIWARE backlog one needs to:

1. Register an account at the FIWARE FusionForge 2. join the FIWARE project in FusionForge 3. Provide a link (in the ticket) to a complete backlog entry draft in the Uncategorized Enabler backlog on this

wiki 4. Issue a ticket on the FIWARE Epic/Feature Requests tracker

In the first place, and once it is formally verified (authorized user, formally correct, in the Uncategorized Enabler backlog, etc.), the ticket will be handled by the FIWARE Chief Architect, Deputy Chief Architect or any of the FIWARE Chapter leads who may assign a ticket to any member of the FIWARE team. Handling a ticket may involve several interactions between the ticket Issuer, and the FIWARE team. FIWARE team members handle tickets following the workflow provided on How to handle FIWARE Theme/Epic/Feature requests issued by UC projects. As a result of this workflow, a new Theme, Epic or Feature may be added to the FIWARE Backlog. Since tickets and associated tasks are visible to the Issuers and even to external Observers, status and progress is completely transparent.


Page 32 of 43

7. FIWARE Frequently Asked Questions (FAQ)1

7.1 About the FIWARE Programme Why FIWARE? Few things have revolutionized our lives, and the way companies make business, so much as the Internet and the Web. Disruptive changes have been brought by the Internet and the Web in several consecutive waves, each time increasing the digitalization of life and the economy. The first wave came when, enabled by the Web, Internet became the “Information Superhighway” that made knowledge and contents accessible as never before. Internet also became a new channel that organizations adopted to manage a more effective relationship with their customer as well as other organizations (this transformation was well‐known as the so‐called e‐business transformation). A second wave arrived with the advent of the Web 2.0 phenomenon and the rapid development of Social Networks. New ways of communication emerged leveraging on the full potential of individuals and their connections. People became the center of Internet, not just the information. Visibility, meritocracy and recognition had never been so open to opportunities that everyone can benefit. Nowadays, we are experimenting the first signs of a new revolutionary wave which promises to radically impact the daily life of people and businesses once again. It will come as the result of the transformation of the Internet into the “Next Computer”. The “Operating System” of this “Next Computer” will bring components enabling the hosting of applications and data/content on the Cloud (somehow mapping to the “kernel” component of any Operating System). However, it will also come with an additional set of components (playing a similar role as the “system libraries” in any Operating System) that applications can use through a well‐defined set of APIs available “as a Service”. Based on these additional components, new innovative applications/services can be designed that will bring a radical optimization of processes and the creation of applications that will exhibit a smart, context‐aware, behavior. Thus, for example, this Operating System will bring components enabling applications to interact with physical objects (the so called Internet of Things made up of sensors and actuators) or with more sophisticated devices such as robots. It will also bring components enabling to gather, publish and process media content or data at large scale, handling them as part of the context. In addition, there will be components enabling to extract knowledge from historic data applying Big Data analysis, or enabling to build advanced Web‐based User Interfaces that support a much richer experience based on the support of Augmented Reality or 3D visualization features. Applications running on such “computer” will be based on these or other additional components, and they will be always available, seamless accessible, anywhere, from any device. The next battle will be to dominate the Operating System of the computer in which the Internet will transform. Unless a collaborative effort is made, this battle will be dominated by the existing incumbent players (e.g., Google or Amazon) with their own proprietary platforms. The FIWARE goal is to make sure that an open platform alternative will exist around which a sustainable open innovation‐driven ecosystem can be created. The same way, existence of technologies such a Linux or Apache has been crucial in how the Internet and the Web looks today, existence of an platform alternative like FIWARE can be crucial in how the Internet and the Web may look like in the Future. The existence of an open platform alternative will ensure that application providers will be able to choose who will provide and operate the environment where their applications will be hosted. Data providers, including Open Data providers, will also be able to choose who will provide and operate the environment where their data will be hosted and exploited. Their decisions can be driven not just based in economic savings but the trustworthiness of the platform provider. Applications and Data providers can also better protect their investment because of the ability to port applications and data to an alternative platform provider if a given platform provider stops meeting their requirements, thus avoiding getting locked in a given platform provider.

1 Available online on https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE_Frequently_Asked_Questions_%28FAQ%29


Page 33 of 43

Is the FIWARE programme just about creating technology? Definitely not. The FIWARE programme is not only about providing open technology alternatives but also creating an ecosystem that brings better opportunities to all the stakeholders:

Application Providers, with special emphasis on SMEs and startups, Application Customers, some of which also play the role of Data Providers, Technology Providers.

The FIWARE ecosystem will be built based on five pillars:

The FIWARE platform, which provides a set of simple yet powerful standard APIs that ease the development of Future Internet applications. The public and royalty‐free nature of FIWARE API specifications, together with the existence of products that are open source reference implementations of those APIs, will enable the existence of multiple FIWARE providers and the ability of application as well as data providers to choose what FIWARE provider they trust. You can learn more about FIWARE here.

The FIWARE Lab, a working instance of the FIWARE platform made available for free experimentation. A place where application providers will be able to test their FIWARE‐based applications with real data and users. A place where entrepreneurs can showcase their talent and ideas to potential customers and investors. A place, on the other hand, where application customers or investors can more easily discover the entrepreneurs they are looking for. A place where data providers can put their data at work. In sum, a genuine meeting point where innovation takes place! You can learn more about the FIWARE Lab here

The suite of FIWARE Ops tools, which eases the tasks that a FIWARE provider has to carry out for setting up and operating FIWARE nodes or federating them as part of a new or existing FIWARE instance (e.g., the FIWARE Lab). You can learn more about the FIWARE Ops here.

The FIWARE Accelerator programme, which provides an umbrella to support specific programs aimed at mobilizing resources that can help entrepreneurs (particularly SMEs and startups) to develop their innovative ideas using FIWARE and to experience the benefits of joining the FIWARE ecosystem. Business/technical coaching, funding, promotion or support for networking with potential collaborators are the kind of activities to be covered within these programs. The first of these programs, launched by the European Commission, has mobilized 100 Million euros of which 80 Million will be given away to SMEs and startups using FIWARE. here.

The FIWARE mundus programme, which aims at promoting FIWARE around the world, trying to make the above pillars present in any region, enabling local FIWARE ecosystems to flourish. You can learn more about the FIWARE mundus programme here.

With the creation of such ecosystem, FIWARE will contribute to the growth of the economy, the creation of local jobs and the well‐being in regions where it is adopted. How can I get in contact? A number of channels have been established so that you can issue requests or provide feedback. You can find them summarized at:

http://www.fi‐ware.org/contact‐us/

7.2 About the FIWARE platform What is FIWARE? FIWARE is a software platform that provides enhanced OpenStack‐based cloud hosting capabilities plus a rich library of components bringing a number of added‐value functions offered “as a Service”. These library components provide open standard APIs that make the development of Future Internet applications much easier. Thus, it brings components enabling the connection to the Internet of Things, the support of a smart and context‐


Page 34 of 43

aware behavior through the real‐time processing of data and media content at large scale as well as the analysis of Big Data, or the incorporation of advanced Web‐based User Interface features (e.g., Augmented Reality or 3D visualization), among others. Each component that is part of the FIWARE Reference Architecture is referred as a “Generic Enabler (GE)”. All FIWARE GE specifications are public and royalty‐free, thus enabling alternative implementations of each FIWARE GE coming from different providers. FIWARE GE specifications are “driven by implementation” as opposed to “design by a committee”. Thus, the specifications of each FIWARE GE are backed by an open source reference implementation. Thanks to that, alternative FIWARE instance providers can emerge faster in the market. What is a FIWARE GEri? A product that has been adopted as the open source reference implementation of a FIWARE GE is said to be its FIWARE GEri (GE reference implementation). As an example, the FIWARE Context Broker GE is part of the FIWARE Reference Architecture and Orion is the product that has been adopted as the FIWARE Context Broker GEri. Each open source FIWARE GE reference implementation (GEri) is developed, evolved and supported by a set of organizations that are active contributors to the FIWARE community. These organizations are committed to evolution and support of the technology they are contributing. What is a FIWARE GEi? Any product that implements the specifications of a given FIWARE GE is referred as a FIWARE GE implementation (GEi). There may be multiple FIWARE GEis associated to a given FIWARE GE, but only one open source FIWARE GEri that is considered the reference implementation of the specifications linked to that FIWARE GE. What is the FIWARE Catalogue? What will I find there? The products that are working as the open source reference implementation of each FIWARE GE in the FIWARE Reference Architecture are published in the FIWARE Catalogue. The FIWARE Catalogue will soon evolve to gather information about:

FIWARE GEris (already there), i.e., products offered as reference implementations of FIWARE GE specifications. They are all open source and there is a commitment to support them by FIWARE active contributors.

FIWARE GEis, i.e., products that claim to be compliant with FIWARE GE specifications and look for a place for raising awareness. Note, however, that this won’t mean that the FIWARE community will endorse them or that their compliance has been (or will be) tested. The FIWARE Catalogue will bring an excellent forum where users will be able to share their experiences and feedback using FIWARE GEis.

Incubated GEs/GEris, i.e., products that the corresponding owner believes that can be integrated as part of the FIWARE because a) they are generic enough and b) they cover a gap in the FIWARE Reference Architecture so they can fit/integrate well with existing FIWARE GEris and c) they will be provided as open source. They will be advertised and, their traction among the wider community of developers as well as the opportunity to integrate them within FIWARE will be evaluated from time to time so a decision can be taken about whether they should become FIWARE GEs/GEris. The process that will be followed to determine how an incubated GE/GEri can become a FIWARE GE/GEi will be transparent and neutral. It is currently under definition but we expect that it will be ready by the end of the year or first quarter of 2015.


Page 35 of 43

Domain‐specific FIWARE‐based Frameworks and Specific Enablers, i.e., frameworks developed based on FIWARE or enablers that complement FIWARE GEs/GEris to bring a complete solution for development of applications in specific domains (e.g., eHealth, Smart Agrifood, Smart Cities, etc.).

Using FIWARE means “taking it all or nothing”? How easily could I integrate FIWARE into my application? No. Using FIWARE doesn’t mean taking it all or nothing. A fundamental design principle in FIWARE has been its modularity. The adoption of this design principle was targeted to enable a gradual adoption of FIWARE GEs/GEris by application developers. It was also targeted to enable scenarios where FIWARE providers combine a subset of FIWARE GEris with their own FIWARE GEis, or scenarios where FIWARE providers provide a service just focused on a given subset of FIWARE GEs. As the result of following this modularity design principle, most of the FIWARE GEs/GEris are meaningful and usable standalone. Most of the FIWARE GEs/GEris support a RESTful API. Integration of your application with them will be as easy as with any other service that provides a RESTful API. Note that FIWARE doesn’t dictate what concrete programming language you use in the development of your application. What kind of things can FIWARE do for me? How can I incorporate FIWARE gradually? If you are an application developer, you can gradually incorporate FIWARE GEs in your application. As an example, you may first try to incorporate the Context Broker GE (reference implementation: Orion) in your architecture because it will allow you to support context‐awareness using standard FIWARE APIs. Context information is represented through values assigned to attributes that characterize those entities relevant to your application. The Context Broker GE is able to handle context information at large scale and implements the standard OMA NGSI‐9/10 APIs (OMA NGSI APIs for short) which enable your application to query on context information or subscribe to changes in context information that will be received through notifications. It also enable your application or another systems to modify the context information. This is why the OMA NGSI APIs are said to work as “the SNMP of Context”. You may start managing context information that arrives from external systems connected to your application or from end users interacting with your application using some web portal. Later you may require to incorporate management of “things” using sensors/actuators. This will require incorporating some GEs of the FIWARE IoT chapter as part of your architecture. Those FIWARE GEs will connect to the Context Broker GE and will hide all the complexity linked to management of different IoT protocols. Actually, using the FIWARE OMA NGSI API, reading from a sensor or actuating on a device will be as easy as to read or write on an attribute associated to some Context entity. Again, remember the analogy to SNMP, which would be extended to the management of the so‐called “Internet of Things”. Once you are managing the information about Context in your application using the Context Broker GE, you may introduce some other FIWARE GEs to incorporate more nice features in your application. As an example, you may take advantage of the connectors supported by the Context Broker that automatically upload records generated each time there is a change in the Context to the Datasets Publication GE (reference implementation: CKAN) or the Big Data GE (reference implementation: Cosmos). This way, you can publish part of your Context history as Open Datasets or perform Big Data analysis to extract insights that are relevant to your application (which in turn may enrich the Context).


Page 36 of 43

Later, you may want to perform some complex processing on Context Information. As an example, you may want to automatically detect scenarios that require triggering some action or raising some alarm. You can then add the FIWARE Complex Event Processing (CEP) as part of the architecture of your applications. Your application may also need to process or handle multimedia streams in real‐time. This is something your application can easily perform using the Real‐time Mutlimedia Stream Processing GE (reference implementation Kurento). Note that part of this processing may lead to generation of data you may want to manage as Context Information, consequently connecting this GE to the Context Broker GE. However, you may perfectly use it standalone, even if your application does not perform any Context Management. You may also want to incorporate advanced features in your web‐based user interface, e.g., Augmented Reality or 3D visualization features. Then we recommend you to take a look to the FIWARE GEs that have been defined in the Advanced Web‐based User Interface chapter. These components have recently been incorporated in FIWARE so we are also working on their integration with other FIWARE GEs. For example, you soon will be able to fill information linked to POIs (Points of Interest) visible in your user interface using FIWARE Advanced Web‐based User Interface GEs with context information provided by the Context Broker GE. These are some examples of what FIWARE can do for you and can do gradually. We are eager to help you in your journey! Is there anyone who has used it before? Most of the FIWARE GEris available in the FIWARE Catalogue have been used by their corresponding owners as part of their commercial offerings in the last couple of years. Several Use Case projects under the Future Internet PPP programme (now renamed as FIWARE PPP programme) have used FIWARE in the development of applications for certain domains (eHealth, Smart Agrifood, Smart Grids, Smart Cities, etc.). A number of challenges have also been run during the last year to discover a first set of interesting applications that SMEs and startups can build based on FIWARE. The target goal when we launched this challenge was to get early feedback from SMEs and startups that first approach FIWARE. You can find more info about the winners of the first round FIWARE Challenges at: http://www.fi‐ware.org/2014/02/04/winning‐apps‐from‐campus‐party‐brazil/ The second round of FIWARE Challenges will run their finals this week. You may find more info at: http://www.fi‐ware.org/challenges/ All of the feedback gathered during the last year has helped to improve what FIWARE will now deliver to thousands of SMEs and startups. Given said this, the feedback gathered so far has been rather positive. Experience shows that developers can start building applications based on FIWARE in a matter of days. Is there an active FIWARE online community to ask questions? Yes. We recommend you to visit http://www.fiware.org/contact‐us/ You will find that there are multiple channels to approach the community and ask specific questions or provide feedback. Please carefully review first the description of all of them so that you send your message to the most appropriate channel. This will ease a faster response while avoiding that the teams taking care of each channel get overloaded with questions that ultimately they will forward to other teams. As an example, if you are looking for help regarding usage of the FIWARE Lab, you should send a message to fiware‐lab‐[email protected]‐ware.org.


Page 37 of 43

If you need help while using some given FIWARE GEri (product working as the open source reference implementation of a FIWARE GE) it might be worth checking first whether such question has already been answered at StackOverflow.com which is probably the most reputed forum for asking technical questions available on the Internet. If you are not sure whether your question might be of interest to many other developers, you should direct your question to fiware‐tech‐[email protected]‐ware.org where it will always get answered, no matter if trivial. However, you might be asked to formulate your question to StackOverflow.com by one member of the FIWARE team. If it is the case, please do so because this means that the FIWARE teams have found that many other developers will be interested in the answer to your question. Who owns FIWARE? Is FIWARE open source? There will be always an open source reference implementation (a FIWARE GEri) for all the FIWARE GEs that are part of the FIWARE Reference Architecture. Intellectual Property is different from Access Rights. The Intellectual Property of a given FIWARE GEri belongs to the organizations that have contributed to its development. However, any FIWARE GEri is released under a well‐known open source license, enabling its usage, modification or distribution without paying any license fee. You can check the “Terms and Conditions” tab of the entry associated to a given FIWARE GEri in the FIWARE Catalogue in order to learn what is the open source license under which FIWARE GEri has been released. There may be proprietary, closed‐source products implementing FIWARE GEs (the so‐called FIWARE GEis). FIWARE GE specifications are public and royalty‐free, enabling any party to create products that implement them, either closed or open source. Do I need to release my application software as open source if I decide to use FIWARE? If you decide to modify the software of a given FIWARE GEri, you may have to release the modified version of that software if the open source license of the FIWARE GEri requires to do so. However, your application will typically just use FIWARE GEris without modifying their implementation, therefore you are not required to release your application as open source if you don’t want to do so. I have found that some FIWARE GEris are distributed under GPL or AGPL open source licenses … Is it safe for me? Absolutely. Issues with GPL (or AGPL) licenses are mostly related with the fact that different people assign different interpretations on the meaning of the term “derivate work” used in these licenses. Due to this, some people understand that there is a risk in just using software under GPL or AGPL licenses (even without modifying it). In order to avoid any issue, FIWARE GEri owners who have decided to release their software using a GPL or AGPL license are required to make a public statement that says: Please note that software derived as a result of modifying the source code of this software in order to fix a bug or incorporate enhancements is considered a derivative work of the product. Software that merely uses or aggregates (i.e. links to) an otherwise unmodified version of existing software is not considered a derivative work. This means that there is absolute no risk that you are forced to release the software that you may have developed using FIWARE GEris under a GPL, AGPL or any other open source license.


Page 38 of 43

How dependent will you become on owners of products in the FIWARE Catalogue when using FIWARE? What will it cost me exactly? FIWARE GEris in the FIWARE Catalogue are open source. This implies that you can use and modify them for free. How can I become an active contributor to the FIWARE community? We are eager to hear from you if you wish to actively contribute to FIWARE. There may be many ways to contribute: developing software that can be contributed as part of an existing/new FIWARE GEri, as tester, documenter, evangelist, trainer, coach, etc. Please send a message to fiware‐collaboration‐[email protected]‐ware.org if you want to contribute and let us know what you wish to do. How is a FIWARE instance setup? A FIWARE instance is setup by combining together a set of FIWARE GEis/GEris. Any organization that sets up and operates a given FIWARE instance is referred as a FIWARE provider. An example of FIWARE instance is the FIWARE Lab.

7.3 About the FIWARE Lab What is the FIWARE Lab? The FIWARE Lab (https://lab.fiware.org) is a non‐commercial sandbox environment where innovation and experimentation based on FIWARE technologies takes place. Entrepreneurs can make “hands on” the technology as well as test and showcase their applications on this environment. Multiple cities in Europe are currently working on setting up a connection to FI‐Lab to export their open data in this environment. Can I use the FIWARE Lab for whatever I want and how I want? No. The FIWARE Lab is for non‐commercial use. Usage of the FIWARE Lab is subject to the FIWARE Lab usage terms and conditions that any user of the FIWARE Lab has to accept explicitly when (s)he creates an account on the FIWARE Lab. Does the FIWARE Lab offer infinite resources? Obviously not. You will get assigned a quota once you create an account on the FIWARE Lab. Due to the fact that resources are limited and that there are people rather eager to work using FIWARE technologies, we may need to shut down your VMs if we find out you are not using them. If you are using FIWARE intensively and require more quota, please let us know by sending a message to fiware‐lab‐[email protected]‐ware.org.


Page 39 of 43

Are there FIWARE Lab nodes/regions outside Europe? Yes. A FIWARE node in Mexico is currently under friendly testing and it will be soon publicly launched. There are plans under execution targeted to the creation of FIWARE Lab nodes in Brazil and Chile. If I was interested in running a FIWARE Lab node, whom should I contact? If you are an organization that is interested in setting up and operating a FIWARE Lab node, please send us an email to fiware‐mundus‐[email protected]‐ware.org. Please note that you will be requested to bring a node that can at least contribute with 100 cores of computing capacity.

7.4 About the FIWARE Ops suite of tools What is the FIWARE Ops suite of tools? FIWARE Ops is a suite of tools that eases the deployment, setup and operation of FIWARE instances by Platform Providers. It is designed to help expanding the infrastructure associated to a given FIWARE instance by means of federating additional nodes (datacenters) over time and allowing cooperation among multiple Platform Providers. FIWARE Ops is the tool used to build, operate and expand the FIWARE Lab.

7.5 About the FIWARE Accelerator Programme What is the FIWARE Accelerator Programme? The FIWARE Accelerator Programme provides an umbrella to support specific programs aimed at mobilizing resources that can help entrepreneurs (particularly SMEs and startups) to develop their innovative ideas using FIWARE and to experience the benefits of joining the FIWARE ecosystem. Business/technical coaching, funding, promotion or support for networking with potential collaborators are the kind of activities to be covered within these programs. The first of these programs, launched by the European Commission, has mobilized 100 Million euros of which 80 Million will be given away to SMEs and startups using FIWARE. You can learn more about the goals of this programme visiting http://www.fi‐ware.org/fiware‐accelerator‐programme/

7.6 About the FIWARE mundus programme What is the FIWARE mundus programme? Despite born in Europe, FIWARE is designed with a global ambition, aiming at expanding to other regions. As a first step, partners in several countries of Latin America (Mexico, Brazil, Chile, etc.) have decided to join the FIWARE programme, working on the setup of FIWARE Lab nodes in their countries and promoting FIWARE locally.


Page 40 of 43

Section 2: FIspace

8. FIspace Platform FIspace is a Future‐Internet‐based extensible SaaS‐platform fostering seamless, efficient, and effective business collaboration across organizational boundaries. It is an on‐going project in the Future Internet Public Private Partnership (FI – PPP). The objectives of FIspace are to drive the development of an integrated and extensible collaboration service together with an initial set of domain applications, thereby establishing the standard for supporting and optimizing inter‐organizational business collaboration in global transport, logistics, and agri‐food business. The FIspace platform (www.FIspace.eu) developed in the project is a specific implementation based on the general FIWARE technology (www.FIWARE.org) in FI‐PPP.

8.1 Basic principles of the FIspace platform The primary goal of the FIspace platform to facilitate online business‐to‐business collaboration (B2B). The data providers populate the platform with apps, which in this context are online services to be used by the customers over the Internet. The implementation of these online services (software and database) resides at the provider company and the communication runs directly between the customer and the provider. In this particular call the apps will be developed by SMEs and web entrepreneurs. The role of the FIspace platform is solely to initiate and log the direct communication between the business enterprises based on authorization mechanisms in the platform (Fig. 1). This implies that the apps have to comply with certain rules that are set by the FIspace platform. For that purpose app developers will be supported by a software development kit (SDK); more information can be found at http://dev.fispace.eu/doc/wiki/Home: ‘If you are an App Developer’.

Communication routes. Blue: FIspace administration. Green: B2B communication.

An online service (app) may need data from another service (app). In precision farming, for example, a service which produces decision support for crop protection will need weather data as well as crop details and field boundaries for creating spraying maps. The farm’s crop and field data may reside at an external Service (e.g. advisory administrated database). When this service (web service) is also represented by an app in the FIspace platform, then the platform can provide the required authorization for opening a secure and optionally encrypted data exchange between the two services. The same accounts for weather data. Hence the role of an app provider will often be extended to the role of business architect that configures apps and data in order to support a complete B2B collaboration process. This configuration process is also facilitated by the FIspace platform; more information can be found at http://dev.fispace.eu/doc/wiki/Home: ‘If you are a Business Architect’. Several examples of app


Page 41 of 43

configurations are currently being developed in the FIspace trials (http://www.fispace.eu/leaflet.html). A detailed presentation on the Greenhouse Management & Control trial can be found here. The FIspace platform logs the necessary data for any financial arrangements between customers and providers as well as between interacting online services.

8.2 FIspace modules Seven major building blocks (called modules) constitute the FIspace platform. They are visualized in the figure below and briefly introduced in the text that follows.

FIspace modules

Core Layers/Tiers: The FIspace platform consists of the following three major tiers (or layers):

User Front‐End: The User Front‐End serves as the main point of access for users of the platform services and Apps, and constitutes a configurable and graphical user interface.

B2B Collaboration Core: The B2B Core ensures that all information and status up‐dates are provided to each involved stakeholder in real‐time. The B2B core allows for the creation, management, execution, and monitoring of collaborative business processes in the FIspace platform.

System & Data Integration: The System and Data Integration Layer allows for the integration of existing legacy and business systems as well as the integration of external systems and services. It includes facilities for data mediation.

App Store: The App Store provides the tool‐supported infrastructure for providing, finding, and purchasing FIspace Apps, which provide re‐usable IT‐solutions for seamless business collaboration and can be used and combined for the individual needs of users. Security, Privacy and Trust Framework: The Security, Privacy & Trust framework provides secure and reliable access and, where needed, exchange of confidential business information and transactions using secure authentication and authorization methods that meet required levels of security assurance. Authentication, authorization and accounting technologies will provide user management & access control features.


Page 42 of 43

Design and Run‐time Support: Two key elements of the FIspace platform provide support for design‐time and run‐time activities:

Software Development Toolkit: The SDK provides tool‐support for the development of FIspace Apps. The SDK will ease the work of App developers during the implementation of the Apps, providing specific tools and hiding the complexity of the platform

Operating Environment: The Operating Environment ensures the technical interoperability and communication of (possibly distributed) FIspace components and FIspace Apps and the consistent behavior of FIspace. Its main feature is the Cloud Service Bus (CSB) providing event bus and pub/sub capabilities.

8.3 FIspace documentation Depending on your role and profile, please follow the below links to get more information:

8.3.1 App Developer App Developers are the actual software and system providers who offer “packaged”/componentized solutions and applications in form of Apps. For more in information, please refer to the App Developer Guide or In‐depth Documentation.

8.3.2 Business Architect Business Architects are the experts (internal or external to the User organization of the supply chain actor) that are in charge of configuring FIspace for their individual business needs. Particularly they define customized collaborative workflows and connect those workflows with FIspace Apps and backend systems. For more in information, please refer to the Biz Architect Guide and In‐depth Documentation.

8.3.3 End User End Users are the actual (industry) users (aka. supply chain actors) of the collaboration services and Apps provided by FIspace. Those users will be supported in their daily business activities, with special focus on their interaction and collaboration with business partners. For more in information, please refer to the End User Guide and In‐depth Documentation.

8.4 FIspace Roadmap The release plans of the individual platform modules, including already available platform features, can be found here.

8.5 Perspectives of using FIWARE in agriculture based on FIspace Online services over the Internet are already widely used by agricultural ICT providers. Data exchange exists in a number of cases based on bilateral agreements, and authorisations for e.g. agricultural advisers and veterinary practitioners to access farm data are often a standard procedure. The FIspace platform offers a novel and more


Page 43 of 43

efficient way of continuing and extending such facilities with FIWARE technologies. The benefits of the FIspace platform include:

authorisations for data exchange in transparent and standardised procedures,

the exchange and use of data are completely under the customer’s control,

cost efficient development and maintenance of data exchange facilities,

the supply of services is easily overviewed and accessed by customers via the platform’s app store,

new opportunities for B2B collaboration among providers are easily spotted and implemented,

adapted/customized development of business‐specific information management system. The FIspace platform and the FIWARE technologies thus provide a feasible solution for an efficient collaboration amongst independent online services. A particular and important aspect is that this opens up an international market for agricultural ICT. A knowledge‐based decision support system developed in one country can be adapted to linguistic, climatic and biological conditions in a second country by a collaborative service delivering these adaptations. The FIspace platform is maintained by the FIspace project until the project’s completion by end of April 2015. To ensure a long‐term sustainability of the platform a FIspace foundation is being established that holds the IPR for the open source core of the platform as well as the open specifications. On top of that, an exploitation agreement is being established in order to formalize the modalities and the conditions that will govern the commercial exploitation of the project results. The exploitation agreement ensures that the FIspace platform will be available for app developers/business architects funded through the SmartAgriFood call and that the required level of support is provided. Check www.FIspace.eu for the latest developments on this.

Documents

Technical Documentation - fractals-fp7.com · FRACTALS Technical Documentation Page 4 of 43 Introduction This document represents summary of previously prepared documents and articles