FUTURE INTERNET. Public-Private Partnership. Outcomes, achievements and Outlook

FUTURE INTERNET PHASE 1 FINAL REPORT Outcomes, achievements and Outlook

Future Internet Outcomes, achievements and Outlook September 2013 Executive Summary The overall goal of the Future Internet (FI-PPP) programme is to place Europe in a better position towards capturing the opportunities, in terms of both economic growth and well-being that will arise as a result of further digitalization in a number of economy sectors. This document describes the main accomplishments of the Phase 1 PPP projects, which in a nutshell are the following: the development and release of numerous (> 60) Generic Enablers (GEs), by FI-WARE, as common building blocks across Use Case projects, the development of many (> 100) Specific Enablers (SEs) as dedicated building blocks coming from the Use Case projects so as to support their proof of concept and build prototypes, the availability, in XiPi (INFINITY project), of over 140 infrastructures across Europe relevant to the needs of FI-WARE and Use Case projects, and the inclusion of a wide spectrum of actors and stakeholders, both ICT and non-ict, which are driving the take-up of the programme. Moreover, in this report, the plans of the five new Phase 2 Use Case projects are analysed towards the use, testing and validation of the GEs in several trials across Europe, in order to realise numerous diverse scenarios spanning from the manufacturing domain to health, content, energy, transport, logistics, and agri-food. Key element for the successful validation of the GEs is the experimental infrastructures, which include five core nodes and ten additional ones through open calls, managed by XIFI. These nodes will form the kernel of a pan-european federation of infrastructures. Finally, the plans for the preparation of Phase 3 are described, which include: development of FI-PPP service provisioning infrastructure that will be offered to internal and external actors in phase 3, showcasing of services and applications to potential actors of phase 3 and beyond of the opportunities offered in the FI-PPP, 11/09/2013 Page 2 of 96

identification and leveraging of networks of SMEs and Web entrepreneurs, and possibly the exploitation of additional supporting measures for entrepreneurial activities, Key factor for the success of Phase 3 is certainly the realisation of the FI-WARE Open Innovation Lab (OIL) which: provides a FI-WARE Cloud where third parties can setup and configure the virtual infrastructure (computing, network, storage) to run, test and validate their own experimental Future Internet Applications, makes FI-WARE Generic Enabler implementations (GEis) available for experimentation. Overall, it is clear that significant amount of work has been carried out in domains such as energy, mobility, media and entertainment, food, logistics and health in order to provide Europe with great opportunities to progress more rapidly towards a sustainable and innovation oriented economy, carrying the potential for realising a digital single market with new business opportunities for established and emerging application and service providers. 11/09/2013 Page 3 of 96

1) Introduction The Future Internet Public Private Partnership, or FI-PPP, was launched in 2011 by the European Commission in order to advance a shared vision for harmonised European-scale technology platforms and their implementation. With over 500 people working every day for the FI-PPP, the FI-PPP has two main goals: Increase the effectiveness of business processes and infrastructures supporting applications in areas such as transport, health, mobility, media & entertainment, logistics, agri-food and energy. Derive innovative business models that strengthen the competitive position of European industry in sectors such as telecommunication, mobile devices, software and services, and content provision and media. Many notable achievements are worth noting, such as the provisional implementation of nearly 200 Generic and Specific Enablers across multiple sectors, such as the two real-life demos done by SafeCity, which relied fully on FI-PPP Generic Enablers (GEs). In addition, the joint operation between OUTSMART and FI-WARE, which implemented several GEs for a use case involving Santander lighting. Lastly, the Specific Enabler Discovery Augmentation Component by the ENVIROFI project was adopted and extended in several FP7 projects including UncertWeb, GeoViQua, EarthServer, GEOWOW, AfroMaison and the ESA Prod-Trees project. Nonetheless, it is clear that more work needs to be done in Phase 2 in order to create a sustainable technology foundation framework that will be robust enough for European SMEs to use in Phase 3. Some key steps towards this goal include delivery of a transparent, open and documented process for the establishment of the XIFI federation of infrastructures, validation of the deployment of GEs and SEs in an automated process, and facilitation of the interoperability of existing infrastructures and legacy systems with the GEs provided by FI- WARE. 2) State-of-play of common building blocks (Generic Enablers) 2.1) Generic building blocks (Generic Enablers) A complete list of all GEs along with their descriptions, functionalities, use in services and applications and their competitive advantages over available commercial modules, developed by FI-WARE, can be found in Annex I of this document. 2.2) Specific building blocks (Specific Enablers) A complete list of all SEs, their descriptions, and use in services and applications, developed by the Phase 1 Use Case projects can be found in Annex II of this document. 11/09/2013 Page 4 of 96

2.3) FI-WARE Open Innovation Lab (OIL) Services that will be provided by OIL The FI-WARE Open Innovation Lab (OIL) will be a case example of a FI-WARE Instance. As such: It will provide a FI-WARE Cloud where third parties can setup and configure the virtual infrastructure (computing, network, storage) to run, test and validate their own experimental Future Internet Applications. It will make FI-WARE Generic Enabler implementations (GEis) available for experimentation. Two non-exclusive scenarios will be supported: o Enabling applications to use global accessible FI-WARE GEi instances provided as a Service, o Enabling application providers to create dedicated FI-WARE GEi instances by means of using advanced software deployment functions supported in the FI- WARE Cloud. Access to OIL The FI-WARE OIL will be accessible from: http://lab.fi-ware.eu. Applications deployed on the FI-WARE OIL will benefit from a high-speed 10 Gb connection of FI-WARE data-centres to the Internet. Third parties will be able to connect to the FI-WARE OIL website, and set up dedicated user accounts, provided they adhere to the FI-WARE OIL terms and conditions. Once they have created their accounts, they will be able to setup the virtual infrastructure needed to run their experiments and deploy their applications on top. Those applications will be able to make use of services provided by global or dedicated FI-WARE GEi instances and the FI-WARE OIL Cloud (Both collectively referred as FI-WARE OIL Services) and can be offered to experimental endusers. Relying on dedicated FI-WARE Security GEis, applications deployed on the FI-WARE OIL will be able to manage the identity of end-users and apply access control policies. Use of FI-WARE OIL Services is granted for free provided that it is solely for experimental purposes. Users will not be able to provide any production service based on FI-WARE OIL Services. Use will be also subject to certain restrictions in terms of quota (allocable resources) and period of time due to capacity limits and the need to share resources. FI-WARE OIL support will be provided in best-effort mode with no obligation to provide any particular service level or support services. FI-WARE OIL services and content available at the FI-WARE OIL site will be provided on an as is and as available basis. Each FI-WARE GEi, as well as the FI-WARE OIL itself will have a dedicated JIRA tool enabling users to issue tickets asking for support or enhancements. After the end of the FI-PPP programme, similar experimental environments, or a continuation of the existing one, will be maintained, but the exact model has not been determined yet. 11/09/2013 Page 5 of 96

Moreover, commercial environments will also be available, completing the whole innovation ecosystem. Services/applications hosted in OIL and their characteristics Any type of experimental applications can be hosted in the FI-WARE OIL environment, or the vertical application domain to which those experimental applications belong to. Application examples include smart-city applications, social web applications, any kind of SaaS application, applications dealing with management of sensor networks, etc. Hosting of OIL The FI-WARE OIL is deployed on a number of data-centre facilities referred as FI-WARE OIL nodes. There will be a first node in Seville, hosting the current FI-WARE Testbed site, while a new node is under preparation (Malaga). The physical infrastructure (servers, network switching equipment and connectivity) is owned, operated and provided by Red.es while the premises belong to the local authorities in Seville and Malaga. The connectivity and performance of the network is guaranteed by the 10 Gb link provided by Red.es. Red.es (rediris) is the National Research and Education Network in Spain. Regarding its capacity, the current estimate for the physical servers planned is a combined amount of >8,5 Tbytes of physical RAM, storage volume of >300 Tbytes with >900 computing cores. OIL support The support to the FI-WARE OIL is provided at different levels. On the infrastructure level, Red.es will ensure the availability of the servers and the network (housing). FI-WARE Cloud partners will offer the support for the cloud hosting functions that will be provided to the FI- WARE OIL users (application providers). Finally, the owners of each FI-WARE GEi deployed on the FI-WARE OIL will devote reasonable efforts to provide support for their FI-WARE GEis during the project lifetime. However, there is no obligation to provide any particular service level or support services. The FI-WARE and XIFI projects are working together to ensure that all functionalities supported in the FI-WARE OIL are equally supported in XIFI. This way, portability of applications from one environment to the other is ensured. Major differences between the FI- WARE OIL and XIFI infrastructures will be the number of nodes, capacity per node, geographical location of nodes and the kind of support each will provide to users. 2.4) Plans for Phase 3 The success of Phase 3 of the FI-PPP initiative heavily depends on the usefulness, maturity, and accessibility of the Generic and Specific Enablers. They must have a function that is useful to SMEs and web entrepreneurs; they must fulfil a certain need. They should be made available with a sufficient level of maturity and stability. And most important, SMEs and web entrepreneurs must be able to use the Enablers beyond the context of the FI-PPP, so terms and conditions for such use must be crystal clear. 11/09/2013 Page 6 of 96

Only if the above is fulfilled, the FI-PPP and European Commission could commence proper advertisement of the major outcomes of Phase I and Phase II projects to a wide audience including developers, web entrepreneurs, SMEs, startup accelerators/incubators, etc. Thus, targeted events could be organised all over Europe so as to raise awareness with respect to the availability of the GEs/SEs, the numerous scenarios for which they can be used, and the available experimental infrastructures where the newly developed applications can be run and tested. Moreover, FI-WARE should ensure that the FI-WARE OIL will be available and make open data available for experiments through it, making the whole value proposition more attractive to developers and web entrepreneurs. In this respect, FI-WARE plans to connect several cities across Europe to the FI-WARE OIL. 3) The infrastructure dimension 3.1) Mapping of infrastructure brought into phase 2 and 3 of the FI-PPP Currently, five nodes are used in XIFI (see in blue on the map to the right), namely located in Ireland (Dublin), Spain (Malaga / Seville), France (Brittany), Italy (Trentino) and Germany (Berlin). These nodes contain the necessary access, backbone, network, computing, storage, and scalability power (available in detail in the table below) necessary for phase 2; furthermore, no less than 10 nodes will be added to this network (illustrated in red on the right). The process will be managed through an open call. Table 1: Infrastructure brought into Phase 2 & Phase 3 Location Spain (Malaga / Seville) France (Brittany) Italy (Trentino) Ireland (Waterford / Dublin) Germany (Berlin) Access Commercial ISP, full range of wireless access, including LTE FTTx, full range of wireless access, 3G/4G/LTE, DVB- T2 Wireless access 500 nodes, Gbit Ethernet 10 Gbps dark fibre, wireless access, 3G, LTE via O2, commercial ISP Full range of wireless access, incl. LTE, WiMAX 2G/3G/4G femto-cells Backbone 10 Gbps up to 100 Gbps, 1 Gbps 10 Gbps 10/40 Gbps, 2x(10+1) Gbps to GÉANT > 1 Gbps via DFN Networking / Services Access switches, Gbit/s Ethernet, PDUs IMS, M2M, sensors, short range comm. OpenFlow, MPLS, PDUs Bandwidth on Demand, NaaS, MaaS, OpenFlow, IMS IMS, managed mobility EPC, Computing IaaS (48 servers) IaaS/PaaS on demand 6 x 64 VMs IaaS/PaaS on demand Blade centre (supports at least 11/09/2013 Page 7 of 96

Location Spain (Malaga / Seville) France (Brittany) Italy (Trentino) Ireland (Waterford / Dublin) Germany (Berlin) 40 VMs) Storage 2 x 100 TB On demand 4 x 600 GB 18 TB On demand Operation centre GEANT connection? / PlanetLab Europe via GARR via DFN AAA Edugain, OpenID Through IMS Edugate / Edugain in progress Through IMS QoS/IPv6 native / / dual stack / native / native Users 1.5M potential users 200K potential users, plus partnership with Monaco Telecom, Living Lab Coverage of the Trentino province 200K potential users + 4K schools Berlin Open Wireless Lab (up to 50 simultaneous users), DT Living Lab 3.2) A European infrastructure survey The INFINITY project identified roughly 400 infrastructures, ranging from application service delivery, backbone network, cloud network, data context management, mobile network, satellite network, sensor Geographical network, WIFI Distribution networks, and of wired Infrastructures access network. at the Sweden 0% Switzerland Turkey 2% 0% end of the second survey Spain 22% Uruguay 0% UK 2% USA Australia Austria Brazil 2% 4% 0% Belgium 0% Canada 4% 0% Croatia 2% Denmark 2% EU 2% Finland 4% South Korea 0% Slovenia 3% Romania 0% Portugal 2% Poland 5% France 7% Germany 5% Greece 7% Norway 3% Netherlands 2% Italy 10% Hungary Ireland 2% Israel 2% 3% Figure 1: Geographical distribution of infrastructures identified by INFINITY 11/09/2013 Page 8 of 96

In addition to providing a good landscape of where these infrastructures are located (as seen above), the study showed that these infrastructures can provide support for the common requirements coming from the Use Case projects representing credible scenarios in the Future Internet landscape. 4) Use of common building blocks by Use Case projects The following Table depicts the GEs, which were either used, tested, or planned to be used by the Phase 1 projects in several proof-of-concepts. D (green colour) means that the Use Case project has already taken the GE into its Proof-of-Concept demos U (yellow colour) means that the Use Case project has already taken the GE into consideration in its design E (light blue colour) means that the Use Case project experiments with it and might consider it based on results 11/09/2013 Page 9 of 96

Apps Chapter Data Chapter Cloud Chapter - I2ND Future Internet Table 2: Use of GEs in proof-of-concepts of Phase 1 projects FI-WARE GEs Allocation of single VMs (image instances) Management of Blueprints GE implementation product(s) name(s) / owner Envirofi FI- Content Finest Finseny InstantMobility Outsmart SafeCity SmartAgriFood N.A. U U E D D - / TID Deployment of SW on single VMs - / TID Allocation of Object Storage N.A. U E U E E E U Edgelets Management N.A. Job Scheduling N.A. Cloud Proxy - / Technicolor E E E D Complex Event Processing (CEP) IBM PROactive Technology ONline (PROTON)/ IBM U D E E E D D Publish/Subscribe Broker Context Awareness Platform / Telecom Italia U U U U U U U D Publish/Subscribe Broker Orion Context Broker / Telefonica U U U U E U U D BigData Analysis COSMOS / Telefonica E E U E U E Compressed Domain Video Analysis Codoan / Siemens U D Media-enhanced Query Broker QueryBroker / Siemens D U U E U E U Location LOCS / Thales Alenia Space E E U E U Semantic Application Support - / ATOS E E U D Semantic Annotation SANr / Telecom Italia E U E U E Service Description Repository Service Description Repository / SAP U E U E D Service Registry Marketplace (part of Business Framework) Store (part of Business Framework) Business Model/Business Elements (part of Business Framework) Revenuue Shareing (part of Business Framework) Light Semantic Composition Service Registry / SAP Marketplace / SAP U E D U U D - / UPM - / iminds - / TID Light Semantic Composition Editor - COMPEL/ ATOS U E E E E 11/09/2013 Page 10 of 96

Security Chapter IoT Chapter Future Internet FI-WARE GEs Service Composition GE implementation product(s) name(s) / owner Ericsson Composition Editor (ECE) / Ericsson Envirofi FI- Content Finest Finseny InstantMobility Outsmart SafeCity SmartAgriFood E E E E E D Service Mashup Mashup Factory / DT E E E E E D Application Mashup WireCloud / UPM D U E E D Mediator Mediator_TI / Telecom Italia E U E D Mediator SETHA2 / Thales E E E (Backend) Configuration Management Orion Context Broker - TID E E E E E E E U (Backend) Configuration Management IoT Discovery - UNIS (Backend) IoT Broker IoT Broker - NEC Middleware KIARA / several partners (Gateway) Data Handling Esper4FastData / Orange, SOL-CEP / ATOS E E E E U E E (Gateway) Protocol Adapter ZPA / Telecom Italia E E E E (Gateway) Device Management Gateway Device Management / Franhoufer Security Monitoring Service Level SIEM (SLS) / ATOS; Attack Path Engine/Thales E U E E U U Security Monitoring / IoT Fuzzer Security Monitoring / Android Vulnerability Assessment 6LowFuzzer / Inria Ovaldroid / Inria Identity Management GCP / DT D U U E U E E D Identity Management One-IDM / NSN U E U E U E E U Privacy Access Control - / IBM-CH - / Thales Data Handling PPL / SAP E E U E E U Secure Storage SSS / Thales U U E E U Context-based Security & PRRS/ATOS E E E U Compliance (Backend) Device Management IDAS DCA - TID E E E E E E U 11/09/2013 Page 11 of 96

FI-WARE GEs GE implementation product(s) name(s) / owner Envirofi FI- Content Finest Finseny InstantMobility Outsmart SafeCity SmartAgriFood DB Anonimyzer (Opt) DBA / SAP E E U Malware Detection Service (Opt) Morphus / Inria Android Flow Monitroing (Opt) Flowoid / Inria Content-based Security (Opt) Total 25 19 23 14 24 15 18 23 11/09/2013 Page 12 of 96

The overall distribution of D, U, E for all projects is shown in the figure below. It is obvious that actual usage of available GEs by the Phase 1 Use Case projects is a rather small portion of the overall consideration of available GEs (12%). 12% 54% 34% D U E Figure 2: Overall percentage of extent of GE usage by Phase 1 Use Case projects The same information (in absolute numbers) per project is depicted in the following figure. Figure 3: Number of GEs and extent of usage by Phase 1 Use Case projects 11/09/2013 Page 13 of 96

The figure below gives another insight on which projects have already used the GEs in their demos ( D ). It is clear that the projects Envirofi, Finest, SafeCity, and SmartAgriFood are the only ones which used the GEs in their proof-of-concept demos. Figure 4: Phase 1 Use Case Projects that used the GEs in their proof-of-concept demos The following figures show which projects and to what level extent have considered the GEs in their design (figure U) or experimented with them (Figure E) Figure 5: Phase 1 Use Case Projects that have considered the use of GEs (U) or experimented with them (E) 11/09/2013 Page 14 of 96

The following table includes the GEs which were actually used (in demos, designs, or experimented) by Phase 1 Use Case projects, and the SEs, which were designed/developed by the Phase 1 Use Case projects. Table 3: GEs and SEs used by Phase I projects Project GEs SEs ENVIROFI 25 30 FI-CONTENT 19 12 FINEST 23 6 FINSENY 14 5 INSTANT MOBILITY 24 8 SAFE CITY 18 33 SMART AGRIFOOD 23 4 OUTSMART 15 16 11/09/2013 Page 15 of 96

The sites/locations involved in the Phase 1 Use Case projects are shown in the figure below. *The project FINEST did not provide this information. Figure 6: Sites/Locations of Phase 1 projects The following Table depicts the GEs, which are going to be used and validated by the Phase 2 projects in several demos (status in June 2013). As previously: D (green colour) means that the Use Case project has already taken the GE into its trials U (yellow colour) means that the Use Case project has already taken the GE into consideration in its design E (light blue colour) means that the Use Case project experiments with it and might consider it based on results 11/09/2013 Page 16 of 96

Data Chapter Cloud Chapter Future Internet Table 4: Use of GEs in trials by Phase 2 projects FI-WARE GEs GE implementation product(s) name(s) / owner FI-Content 2 FISpace Finesce FI-STAR FITMAN Allocation of single VMs (image instances) N.A. (it's functionality, not a GEi in itself) U E E E Management of Blueprints N.A. (it's functionality, not a GEi in itself) E E Deployment of SW on single VMs Allocation of Object Storage Edgelets Management Job Scheduling N.A. (it's functionality, not a GEi in itself) N.A. (it's functionality, not a GEi in itself) N.A. (it's functionality, not a GEi in itself) N.A. (it's functionality, not a GEi in itself) E U U E E E Cloud Proxy - / Technicolor U E Cloud Portal - / UPM U E E E DataCenter Management Resource - / IBM U E E E Service Management Object Storage Software Deployment and Configuration (SDC) Claudia / TID - / Intel Sagitta / TID U E E E U U E E E PaaS Manager Pegasus / TID E E Monitoring - / TID U E E E Edgelets Manager - / Thales Job Scheduler ProActive Cloud Job Scheduler / INRIA Complex Event Processing (CEP) Publish/Subscribe Broker Publish/Subscribe Broker IBM PROactive Technology ONline (PROTON)/ IBM Context Awareness Platform / Telecom Italia Orion Context Broker / Telefonica E E E D U E U U E E U E E BigData Analysis COSMOS / Telefonica E U U E 11/09/2013 Page 17 of 96

IoT Chapter Apps Chapter Future Internet FI-WARE GEs GE implementation product(s) name(s) / owner FI-Content 2 FISpace Finesce FI-STAR FITMAN Compressed Domain Video Analysis Codoan / Siemens MetadataPreprocessing MetadataProcessor / Siemens Media-enhanced Query Broker QueryBroker / Siemens E Location LOCS / Thales Alenia Space E E Semantic Support Application - / ATOS U E Semantic Annotation SANr / Telecom Italia E Advanced Middleware Service Repository FI-WARE Description KIARA / several partners E U Service Description Repository / SAP D U E E Service Registry Service Registry / SAP U E Marketplace (part of Business Framework) Store (part of Business Framework) Business Model/Business Elements (part of Business Framework) Revenue Shareing (part of Business Framework) Light Composition Service Composition Semantic Marketplace / SAP E U U U E - / UPM U U E BEMES / iminds - / TID U U Light Semantic Composition Editor - COMPEL/ ATOS Ericsson Composition Editor (ECE) / Ericsson U E E E E E E Service Mashup Mashup Factory / DT E Application Mashup WireCloud / UPM U E Mediator Mediator_TI / Telecom Italia U E Mediator SETHA2 / Thales E (Backend) Configuration Management (Backend) Configuration Management Orion Context Broker - TID E E E IoT Discovery - UNIS (Backend) IoT Broker IoT Broker - NEC E E E E 11/09/2013 Page 18 of 96

I2ND Chapter Security Chapter Future Internet FI-WARE GEs (Backend) Management (Gateway) Handling (Gateway) Adapter Device Data Protocol GE implementation product(s) name(s) / owner FI-Content 2 IDAS DCA - TID E E Esper4FastData / Orange, SOL-CEP / ATOS (Gateway) Device Gateway Device Management Management / Franhoufer Service Level SIEM (SLS) / Security Monitoring ATOS; Attack Path Engine/Thales Security Monitoring / IoT Fuzzer 6LowFuzzer / Inria Security Monitoring / Android Vulnerability Ovaldroid / Inria Assessment FISpace Finesce FI-STAR FITMAN E E E ZPA / Telecom Italia E E E E E E E U E E Identity Management GCP / DT E E E E Identity Management One-IDM / NSN E D E E E Privacy - / IBM-CH U U E Access Control - / Thales E U Data Handling PPL / SAP U U E Secure Storage SSS / Thales U Context-based Security & Compliance PRRS/ATOS U DB Anonimyzer (Opt) DBA / SAP E Malware Service (Opt) Android Monitroing (Opt) Detection Flow Content-based Security (Opt) (I2ND) Connected Device Interfacing (CDI) Morphus / Inria Flowoid / Inria CBS / Thales A-CDI/Intel U E E E Cloud Proxy (I2ND) Network Information and Control (NetIC-VNEIC) OFNIC / UNIROMA1 11/09/2013 Page 19 of 96

FI-WARE GEs GE implementation product(s) name(s) / owner FI-Content 2 FISpace Finesce FI-STAR FITMAN (I2ND) Network Information and Control (NetIC-VNP) (I2ND) Network Information and Control (NetIC-OFNIC) (I2ND) Network Information and Control (NetIC-altoclient) (I2ND) Service Connectivity Capability and Control (S3C) Altoclient/ALU-D VNP/NSN VNEIC/ALU-I S3C / DT E Total 60 20 36 32 29 29 The distribution of D, U, E for all Phase 2 projects is shown in the figure below. Figure 7: Number of GEs and extent of usage by Phase 2 Use Case projects 11/09/2013 Page 20 of 96

The sites/locations involved in the Phase 2 Use Case projects are shown in the figure below. Tromso FINESCE FI-STAR Oslo Stockholm FITMAN FI-CONTENT 2 FISpace Dublin Copenhagen Lancaster Amsterdam London Berlin Brussels Köln Brittany Paris Munich Krakow Zurich Bucharest Bilbao Madrid Lisbon Barcelona Roma Ankara Athens Figure 8: Sites/Locations of Phase 2 projects trials 11/09/2013 Page 21 of 96

5) Stakeholders involved XIFI s stakeholders are broken into three major categories. The first category includes infrastructures, both those that will build the backbone of XIFI, and other infrastructures that will be able to join XIFI in its second year, after the core backbone has been created. The second category is the Early Adopters, those who will use XIFI early on in its availability, and will implement various GEs in their projects. Lastly, regional authorities ( smart cities ), national authorities, and particular businesses and individuals, such as the Living Labs, make up the third category of stakeholders. Envirofi separates its stakeholders into three major categories: (a) data providers (e.g. city of Vienna OGD initiative, municipality of Florence OGD initiative, Global Biodiversity Information Facility, Global Earth Observation System of Systems); (b) species information providers (e.g. European species lists such as Fauna Europea, Euro + Med, MARBEV; regional species lists such as Flora Italia, Austrian Vascular Plants; and European Environment Agency); and (c) individual users (e.g. hobby meteorologists, persons with allergies, outdoor sportsmen, and people at risk). FI-Content identified a number of stakeholders who have so far participated in phase 1, including Consumer Equipment manufacturers, games developers, telco domain experts, content providers, tourism stakeholders, network operators, schools, NGOs, local public organizations, broadcasters, third party application developers. FINESCE identified citizens, academia, the utilities industry as well as the ICT industry. FINEST identified software developers, academia, end users, and the public sector. FINSENY identified the utility sector, the telecom sector, academia, and end-users. FI-STAR identified academia, end users, the healthcare industry, and the PR industry. FITMAN identified the automotive industry, white goods, textiles, furniture, plastic, and manufacturing industries, as well as academia and the IT industry. Instant Mobility identified Smart Cities, the transport industry, academia and developers. SafeCity identified public safety bodies, transportation authorities, and the public sector. 11/09/2013 Page 22 of 96

Table 5: Stakeholders involved FI- NEST FI- NESCE Finseny Instant Mobility Safe City FI- Content Envirofi FI- STAR FITMAN Local Public Organisation Academia Individual Users Developers Network Operators NGO Energy Utilities & Transport Industry Species Information Providers CE Manufacturers Data providers Healthcare industry PR Industry Automotive Industry Textiles Industry Manufacturing Industry Plastic Industry 11/09/2013 Page 23 of 96

6) Phase 2 Use Cases FI-CONTENT2 will build three pan European platforms covering Social Connected TV, Smart City Guide and Gaming. These platforms will consist of a set of technical functions and services that will be built on top of Generic and Specific Enablers dedicated to the identified use cases for each platform. More specifically, for the Social Connected TV Platform, the project plans to iteratively improve and upgrade the enablers tested or developed in Phase 1, during regular agile cycles based on the feedback gained from the social connected TV lab and field trials. The focus will be on: (a) Multi-screen interaction: Intuitive interaction for advanced TV services, more versatile content presentation across screens; (b) Personalised TV experience: Content portals tailored to single and multiple users, social interaction between users (e.g. explicit recommendation) and search and discovery applications; (c) User tracking and privacy: Visualising personal content consumption, tracking implicit and explicit user interaction and providing users with simple control over personal data. Similarly, the Smart City Guide platform and the Gaming platform engage upon adapting and integrating the Generic Enablers mentioned above (Section 4). Integration of Specific Enablers, including reality mixer and networked virtual characters with 3D web services is also sought. FINESCE aims at validating the integrated Generic and Specific Enablers into field trials. The trials will be accompanied by simulation allowing for validation in a scaled-up scenario. Moreover, hardware-in-the-loop test methods based on real-time simulation capabilities can be used for validation of selected Enablers. It is envisaged that validation of integration of Generic and Specific Enablers can lead to new concepts such as Virtual Substations developing the concept of virtualization in the energy domains. FIspace s ambition is to, through its eight use case trials, use and validate almost all GEs. In addition, four cross-domain Specific Enablers or baseline apps will be developed that are expected to be used in all trials: Business Services & Contract Management App It will deliver novel facilities for (1) real-time and on-time management of business service relationships established via electronic contracts, (2) supporting the setup of new business service relationships and electronic contracts. Logistics Planning App It will provide real-time planning and re-planning facilities that augment existing transport and logistics planning solutions to exploit real-world, online event data and forecasting of future situations. The App will provide logistics planning functionality both for the logistics service clients and providers. Product Information Service (PInfS) App It will provide event-driven product information exchange between stakeholders within a supply chain. Product information includes all product-related data, such as quality certificates, sensor data, and data requests. This will facilitate controlling information flow in complex supply networks, and drastically reduce reaction times with respect to quality issues along the supply chain. 11/09/2013 Page 24 of 96

Real-time Exception Detection and Handling App It will enable users to define constraints, observations and mitigation actions for business process instances. It exploits core features of FIspace, continuously checks the compliance of these constraints to the actual situation and execution of business processes and thus can in real-time detect potential violations. FI-STAR aims to identify and validate a set of Enablers (a subset of the Catalogue) most desirable and suitable for the healthcare, wellness and ambient assisted living domain. It also wants to develop a strategy towards certification of enablers to be used in the healthcare domain and to showcase the Software to Data Paradigm for e-health clouds and provide a technological framework for its implementation into legacy systems and finally, to develop a marketplace for Enablers and provide a service strategy (sales, maintenance, updates, etc.). FITMAN plans are to test and validate as many enablers as possible via the delivery of: A Generic Platform for Manufacturing Industries, A Trials Verification and Validation Framework, A Package for Phase 3 proposals and projects, Three Platforms for Smart, Digital, Virtual Factories; Eleven Trials Validations: o o o 4 Smart Factories Trials 4 Digital Factories Trials 3 Virtual Factories Trials 11/09/2013 Page 25 of 96

7) What are the major obstacles for a broader market take-up of the common building blocks (generic and specific enablers)? Among the FI-PPP use cases, several obstacles to a broader market take-up were cited. For use cases which performed smaller pilots, there was a concern that more large scale pilots needed to be tested in order to make sure the GEs could handle more robust use cases, as will be the case if the public will use them. Clear APIs and documentation was also cited as necessary in order for Developers and SMEs (some of the most common stakeholders cited) to begin using the GEs and SEs. Clear Marketing, PR & Communication around the GEs was also cited. Booths at sectorrelated conferences, communication directly intended for the target market, and other tools were also cited. 8) Outlook for phase 3 In order for GEs and SEs to be able to deploy on a broader scale, and to be available to the public, use case projects identified various preparations which need to be done. Preparations for Phase 3 can be broken up into 4 types of work that are needed to be done. 1) Identify Target Market: Some use case projects identified a need to expand their list of potential targets, as well as to run larger-scale pilots in order to confirm GEs scalability. In order to be able to address their full market, use case projects need to know precisely what/who their target market is. 2) Identify Market acquisition channels: once the target market has been identified, use case projects expressed a need to determine optimal methods for attracting their market. Some suggested identifying regional networks that their market adheres to, or identifying conferences and expos which are relevant to their sector. 3) Automate access to GEs and SEs: In order for the broader market to able to easily use GEs and SEs, the process of implementing them for any stakeholder needs to be automated, simple, and well-documented. Use case projects expressed a need for an automated user on-boarding process, clear and simple API documentation for developers, as well as simple distribution across Europe. 4) Create clear Communication around GE and SE benefits: In order for target users and early adopters to be able to make use of GEs and SEs, clear communication and marketing materials about the benefits and targeted audience must be created. 11/09/2013 Page 26 of 96

Annex I: Generic Enablers (June 2013): 1 Generic Enablers in the Cloud Chapter 1.1 Allocation of single Virtual Machines Description This GE is key component to provide an automated control solution over Virtual Machines through scaling up/down and in/out in an automated manner and helps to save valuable time/resources by automating management of failure tasks that need to be done repeatedly. Functionality Service Manager supports the integration with any public or private Cloud provider and must help to build federated services without requiring underlying Cloud federation. Besides, it allows to organize your Virtual Machine following and architecture closed to your real world defining the following concepts: (a) Organizations; (b) Virtual Data Centers; (c) Virtual Appliances or Services; (d) Virtual Machines or Servers (a) Possibility that one Organization can manage different Virtual Data Center; (b) Automatic management of resources associated to your Data Center and division of the Data Center in several Virtual Data Centers; (c) Possibility to define completely the architecture of your service and the relationship between the different (virtual) machines; (d) Possibility to define scalability rules associated to your service in order to automatically up and down the number of instances of a specific virtual machine on demand; (e) Possibility to move your Service from one Data Center to another. Advantages Claudia enables to enhance the basic capabilities offered by OpenStack by means of supporting the powerful concept of vapp. A vapp refers to the virtual infrastructure required by an application (or part of a larger application) to run. A vapp is typically structured into tiers, each of which is made up of a set of connected virtual servers (also referred as Virtual Machines VMs) that share the same virtual image. The IaaS SM GE is able to perform up/down (vertical) and in/out (horizontal) scaling of virtual servers within the tiers of a given vapp in an automated manner, based on defined rules. The concept of vapp helps to save valuable time/resources by automating the management of tasks that need to be done repeatedly. These tasks include the provisioning of servers, volumes and networks as well as the management operations related to them. vapps can be described in a declarative 11/09/2013 Page 27 of 96

manner, using a vapp manifest, which is based on the standard Open Virtualization Format (OVF). A vapp manifest declares the vapp components, requirements, monitoring, SLA targets and elasticity rules (based on the W3C RIF standard). This eases cloning of virtual infrastructures and the support of templates for the infrastructures linked to blueprints (see Pegasus) 1.2 Allocation of Object Storage Description Object Storage is one of the Generic Enablers within FI-WARE. It offers persistent storage for digital objects, important cloud-based functionality that has been specifically requested by Use Cases. Objects can be files, databases or other datasets which need to be archived. Objects are stored in named locations known as containers. Containers can be nested thus objects can be stored hierarchically. Containers and objects can have Metadata associated with them, providing details of what the data represents. Similar to files in a traditional filesystem - objects in an Object store belong to a certain user (account). Functionality This Generic Enabler provides robust, scalable object storage functionality through an open, standardised interface: it exposes a CDMI interface on top of OpenStack Swift. The CDMI interface provides a standardised mechanism to manipulate both the binary objects that are stored, and the hierarchy of containers in which they are organised. This RESTful API can be accessed from any client technology that can communicate over HTTP. By building on top of OpenStack Swift, all the benefits of this rapidly maturing open-source cloud storage solution can be realised. The highly-available, distributed, and scalable features of swift can be exposed using commodity hardware. OpenStack Swift is a popular, powerful, scalable, distributed, open-source cloud-based object storage platform. The Cloud Data Management Interface standard, first published by SNIA in 2010, has now been designated by ISO/IEC as an international standard. By choosing this Generic Enabler for your object storage needs, you can benefit from the robustness of a leading open source storage platform, whilst maintaining the flexibility to switch with ease to standards-compliant alternatives. Advantages Services and applications that require object storage facilities, be they on public or private cloud infrastructure, may not want to engineer their solutions to be tied to a particular object storage technology. If they interact with their object store via an internationally recognised standard such as CDMI they enjoy the flexibility of being able to change their back end object 11/09/2013 Page 28 of 96

store with minimal (if any) reengineering. OpenStack is a very popular open-source community driven cloud management system suitable for both public and private cloud offerings that includes robust and scalable object storage facilities. This GE is the only implementation we are aware of that delivers standards-driven object storage on this popular open source platform. 1.3 Cloud Proxy Description The Cloud Edge (aka Cloud Proxy) is a kind of "super gateway". It is located at the borderline between the WAN and the LAN(s) and is able to locally execute any kind of application. It is based on a standard PC architecture. For economical (future business) reasons, it is meant to be ran on very small (ie: low cost) PCs such as Netbooks, small industrial PCs, Set Top Boxes or Gateways with (very) limited resources (ATOM-Class processor, 1 or 2GB of RAM and a small low cost HD). Ultimately, it is targeted to embedded dedicated cost-optimized platforms. Functionality The Cloud Edge is available as a set of code and patches to apply upon a freshly installed UBUNTU 12.04LTS distribution (xx.tar.gz). This basic way of distributing the code allows anyone to easily experiment with this code by using any available PC. It also allows the usage of dedicated hardware if the use case specifies specific usage conditions (for example, battery powered or extended temperature range industrial PCs). (a) the Cloud Proxy can locally execute part of your applications (or all of your application) near the Customer / User; (b) The CP allows to maintain continuity of service even if the remote link (c) The CP allows you to cache data transmission: it can be acting as a proxy to some well known cloud app and can cache the user's uploads (d) The CP can help managing user privacy and keep it local Advantages The Cloud Edge provides unique IaaS features inside a home gateway. It can locally execute very complex and unrestricted applications (ie: standard Linux environment with no language / API restrictions instead of more classical solutions such as OSGi for example). Also, the Cloud Edge is designed to interface with Cloud-based apps and to become a local part of them. 11/09/2013 Page 29 of 96

2 Generic Enablers in the Data Chapter 2.1 Complex Event Processing (CEP) Description The CEP GE analyses event data in real-time, generates immediate insight and enables instant response to changing conditions. While standard reactive applications are based on reactions to single events, the CEP GE reacts to situations rather than to single events. A situation is a condition that is based on a series of events that have occurred within a dynamic time window called processing context. Situations include composite events (e.g., sequence), counting operators on events (e.g., aggregation) and absence operators. Functionality CEP has three main interfaces: one for receiving raw events from event producers using a RESTful service, second for sending output events to event consumers using an output REST client adapter, and a third for receiving application definitions, also known as Event Processing Networks. In this second release all above interfaces have been designed and implemented. In addition, administration interfaces were designed and implemented to manage a multiinstance environment that allows for several CEP applications to be deployed and executed in parallel. The technology and implementations of CEP provide means to expressively and flexibly define and maintain the event processing logic of the application, and in runtime it is designed to meet all the functional and nonfunctional requirements without taking a toll on the application performance, removing one issue from the application developer s and system managers concerns. Advantages The CEP GE reference implementation provided by IBM Proactive Technology Online (a.k.a Proton) focuses on the following, compared to competitive products and engines: (a) A CEP application definition is done using a user interface without the need to write any code, with intention for visual programming; (b) The CEP application is composed from a network of Event Processing Agents. This allows the agents to run in parallel and to be distributed on several machines; (c) The event producers and event consumers can be distributed among different machines; (d) The implementation includes and adapter framework that is extensible to allow adding any type of custom adapter for sending or receiving events; (e) The expression language is extensible and functions can be added if needed. 11/09/2013 Page 30 of 96

2.2 Publish/Subscribe Broker - Context Awareness Platform Description Publish/Subscribe implements interface and functionality supporting context data acquisition from context sources or providers by application, services or end-users Functionality It also allows to the context providers to be registered in the systems with their specific context information and entities they're serving. then any "external" entity needed certain or all available context of a certain entity can obtain required information by requesting or subscribing to the instantiated Publish/Subscribe GE instance. The context information may be requested via two distinct APIs: RESTlike ContextML/CQL supporting very rich set or the requests and subscriptions or by RESTful FI-WARE NGSI based on OMA standard and supporting, for the moment, limited set of supported functionalities. Context information can be provided by many different entities in a independent way respecting to the context consumers. Therefore consumers may not know which is where context information is available. The Publish/Subscribe GE provides the mean to register the context providers and make them available for interrogation by the context consumers (applications, services or end-user). Context consumers can efficiently and simply retriever the context information asking to the Publish/Subscribe GE by a simple request when the context is required in real-time (near real-time) or by subscribing to the Publish/Subscribe for the context information matching certain conditions. This mechanism decouple the context producers and context consumers and allows to the context producers to be registered on-fly while the consumers may benefit from different ways and protocols to retrieve needed context information (position, social status, motion, temperature, etc.). However the context information itself is not within scope of this GE and shall be provided by specific context providers registered in the Publish/Subscribe GE. Advantages There is no widely adopted technology which provides a standard API for accessing Context Information. The major goal of the Context Broker GE is to cover that gap providing a very simple yet powerful API that can be adopted as a standard. This would represent a major step beyond in development of smart and context-aware applications. The Context Awareness Platform (CAP) is TI s implementation of the Context Broker GE. It is not a product itself but a service which enables entities (such as network operators or service providers) to gather and expose context information from heterogeneous sources through as much as possible standard interfaces. This GEi exposes a standard REST-full NGSI interface based on OMA NGSI derived from the TI s solution years ago. However, CAP has not been offered as a product or 11/09/2013 Page 31 of 96

service-to-sell by TI so far. Thus formally no analysis, as a product vs. other products has been performed yet. TI CAP implements a Context Cache to speed up the context retrieval and discharge the overall system. It also keeps History of Context Information which can be used for other purposes, e.g., reasoning and inference. Last but not least, CAP supports interaction using ContextML and CQL (Context Querly Langage) as alternative to the NGSI Restful API. 2.3 Publish/Subscribe Broker - Orion Context Broker Description The Orion Context Broker is an implementation of the Publish/Subscribe Context Broker GE, providing the NGSI9 and NGSI10 interfaces. Using these interfaces, clients can do several operations: (a) Register context producer applications, e.g. a temperature sensor within a room; (b) Update context information, e.g. send updates of temperature; (c) Being notified when changes on context information take place (e.g. the temperature has changed) or with a given frequency (e.g. get the temperature each minute); (d) Query context information. The Orion Context Broker stores context information updated from applications, so queries are resolved based on that information. Functionality The Context Broker is a GE of the FI-WARE platform that exposes the (standard) interfaces for retrieval of the context information, events and other data from the Context or Data/Event Producers to the Context or Data/Event Consumers. The consumer doesn t need to know where the data are located and what is the native protocol for their retrieval. It will just communicate to the Context Broker GE through a well-defined interface specifying the data it needed in a defined way: on request or on subscription basis. The Context Broker GE will provide the data back to the consumer when queried, in case of "on-request", or when available, in case of "on-subscription" communication mode. If you are developing a Data/Context scenario, a broker like the Orion Context Broker is a must. You would need a component in the architecture able to mediate between consumer producers (e.g. sensors) and the context consumer applications (e.g. an smartphone applications taking advantage of the context information provided by the sensors). The Orion Context Broker fulfils this functionality in your architecture. Advantages There is no widely adopted technology which provides a standard API for accessing Context Information. The major goal of the Context Broker GE is to cover that gap providing a very simple yet powerful API that can be adopted as a standard. This would represent a major step beyond in development of smart and context-aware applications. The Orion Context Broker is 11/09/2013 Page 32 of 96

Telefonica s open source implementation of the Context Broker GE. It relies on MongoDB therefore making it feasible to manage Context Information at a very large scale. Its design is also focused on providing the best performance. 2.4 Big Data Analysis - COSMOS Description The BigData Analysis GE is made up from several components: (a) Hadoop as the MapReduce engine for batch processing; (b) HDFS as the distributed file system to store the input, intermediate and eventually output data; (c) MongoDB as the NoSQL database to place the output data for its consumption; (d) Apache Flume, SFTP server and Telefónica's streamconnector as the collection of stream injectors; (e) HUE as the frontend for using and operating Cosmos. Functionality The BigData Analysis GE is mainly operated through a set of interfaces around HUE: (a) A web interface is available for creation, monitoring, stop and run of individual or all services in the BigData Analysis GE, scheduling and configuration (workflow design, scheduling, parameterization, etc.). (b) HUE Shell app is the command-line-based counterpart of the web interface. (c) The Filebrowser app allows viewing the results of the MapReduce jobs. The Big Data Analysis Support GE offers a continuous solution for both Big Data Crunching and Big Data Streaming. A key characteristic of this GE is that it would present a unified set of tools and APIs allowing developers to program the analysis on large amount of data and extract relevant insights in both scenarios using a standard programming paradigm (Map&Reduce). Using these APIs, developers will be able to program Intelligent Services such as Social Networks analysis, real-time recommendations, etc. These Intelligent Services will be plugged in the Big Data Analysis GE using a number of tools and APIs that this GE will support. Advantages (a) The streaming and batch processing functionalities both in one single platform. Due to batch and stream processing are managed by using totally different approaches, today Big Data platforms are uniquely oriented to a unique type of data: large log files or continuous streams of data. The envisioned GE will be able to deal with both, firstly by allowing injectors for streams that will be internally turn into batches in order to perform MapReduce techniques (first releases), and then by performing real differentiated batch and streaming processing (final releases). (b) The automatic deployment capabilities in a cloud-based cluster of nodes. Big Data platforms are designed to deploy on a cluster of commodity hardware. This GE goes far beyond and proposes replace the physical machines by virtual nodes and provides means to automatically deploy on such a cloud-based cluster. (c) The wide range of available 11/09/2013 Page 33 of 96

data injectors. The GE will expose a set of interfaces ready to accept data in several formats and ways, e.g. the above mentioned stream injectors, but also agent-based gatherers of data and conventional file transfer systems. (d) The high speed access to the resulting insights via a NoSQL database. Today Big Data platforms relay on distributed file systems to store the input data and all its intermediate transformations since it is the unique way to manage large files manipulation. Nevertheless, the throughput of these distributed file systems is not high, which becomes especially critical when accessing several times to the same piece of data: the results. Thus, the BigData GE foresees to use a NoSQL database where to copy the resulting insights and access them with high throughput rates. 2.5 Compressed Domain Video Analysis Codoan Description The target users of the Compressed Domain Video Analysis GE are all applications that want to extract meaningful information from video content and that need to automatically find characteristics in video streams on given tasks. The GE can work for previously stored video data as well as for video data streams (e.g., received from a camera in real time) Functionality A realization of the Compressed Domain Video Analysis GE consists of a set of tools for analyzing video streams in the compressed domain. Its purpose is to avoid costly video content decoding prior to the actual analysis. Thereby, the tool set processes video streams by analyzing compressed or just partially decoded syntax elements. The main benefit is its very fast analysis due to a hierarchical architecture (a) Critical product attributes for the Compressed Domain Video Analysis GE are especially high detection/recognition ratios containing only few false positives and low-complexity operation; (b) Partitioning to independent functional blocks enables the GE to support a variety of analysis methods and to get easily extended by new features. Even several operations can be combined; (c) Low-complexity algorithms and implementations enable the GE to perform very fast analyses and to be highly scalable (d) GE implementations support performing parallel analyses using different sub-components Advantages Moving object detection is probably one of the most widely used video analysis procedures in many different applications, e.g., in the security domain but also for patience care. Video surveillance systems need to detect moving persons or vehicles, trackers have to be initialized 11/09/2013 Page 34 of 96

with the objects they should track, and recognition algorithms require the regions within the scene where they should identify objects. For this reason, several components/systems for efficient object detection have been released and are offered in the security market. Most of them operate in the pixel domain, i.e., on the actual pixel data of each frame. This usually leads to a very high accuracy, but at the expense of computational complexity. As most video data is stored or transferred in compressed representation, the bit stream has to be completely decoded beforehand in such scenarios. Therefore, the Compressed Domain Video Analysis GE makes the attempt to eliminate the costly step of decoding and to perform the analysis directly in the compressed domain. Compared to currently deployed systems, this gives significant advantages in terms of computational complexity and therefore also offers cost savings especially for large-scale analytics systems. 2.6 Media-enhanced Query Broker Query Broker Description The Media-enhanced Query Broker GE provides an intelligent, abstracting interface for retrieval of data from distributed and heterogeneous data resources. Principal users of the Media-enhanced Query Broker GE include applications that require a selective, on-demand view on various data repositories via a single, unified API, without taking care about the specifics of the internal data storage and DB implementations and interfaces. Therefore, this GE provides support for integration of query functions into the users applications by abstracting the access to databases and search engine. At the same time its API offers an abstraction from the distributed and heterogeneous nature of the underlying storage, retrieval and DB / metadata schema implementations. Functionality The QueryBroker is implemented as a middleware to establish unified retrieval in distributed and heterogeneous environments with extension functionalities to integrate multimedia specific retrieval paradigms in the overall query execution plan, e.g., multimedia fusion technique. To ensure interoperability between the query applications and the registered database services, the QueryBroker uses as internal query representation format the MPEG Query Format (MPQF). MPQF is an XML-based (multimedia) query language which defines the format of queries and replies to be interchanged between clients and servers in a (multimedia) information search and retrieval environment. (a) Middleware component for unified access to distributed and heterogeneous data repositories (with extensions supporting multimedia repositories); (b) Abstraction from heterogeneous retrieval paradigms in the underlying data bases and search engines; (c) Loosely coupled, modular architecture (easy extensibility) 11/09/2013 Page 35 of 96

Advantages Today data - and especially in the media domain - is produced at an immense rate. By investigating solutions and approaches for storing and archiving the produced data, one rapidly ends up in a highly heterogeneous environment of data stores. Usually, the involved domains feature individual sets of metadata formats and the data sets are accessible in different systems supporting a multiple set of retrieval models and query languages. Thus an easy and efficient access and retrieval across those system borders is a very cumbersome task. In the last few years, several approaches for accessing multi-media data in a possibly distributed and heterogeneous environment have been proposed, but those systems are mainly dedicated to certain domains (e.g. medical) supporting only corresponding metadata formats (e.g. DICOM) and often are not able to address heterogeneous data sources. Furthermore these systems lack in the expressiveness of multi-media queries and metadata interoperability. In contrast to the existing approaches the media-enhanced Query Borker provides a unified search interface for heterogeneous and distributed data stores with a particular focus on integrating multimedia data in the query and retrieval processes. To ensure interoperability between the query applications and the registered database services, the Media-enhanced Query Broker makes use of the standardized MPEG Query Format, which provides a standardized interface to (multi-)media repositories, as well to metadata modeled with Semantic Web languages like RDF and the Web Ontology Language, and query constructs based on SPARQL. 2.7 Location LOCS Description The Location Server (LOCS) is a Thales Alenia Space France (TAS-F) platform dedicated to location management of wireless devices (2G, 2.5G, 3G, 4G). This platform is based on various positioning techniques such as A-GPS, WiFi and Cell-Id activated with intelligence whilst taking into account the end-user privacy. Functionality The Location GE in FI-WARE targets any third-party application that aims to retrieve mobile device positions and area events. The Location GE is based on various positioning techniques such as A-GPS, Wi-Fi and Cell-Id intelligently triggered whilst taking into account the end-user privacy. This GE addresses issues related to Location of mobile devices in difficult environments such as urban canyons and light indoor environments where the GPS receiver in the mobile device is not able to acquire weak GPS signals without assistance. In more difficult conditions like deep indoor, the Location GE selects other positioning techniques like Wi-Fi to locate the end-user. It therefore improves localization yield, which enhances the end-user experience and the performance of applications requesting the position of mobile devices. 11/09/2013 Page 36 of 96

Use this platform if you need to retrieve the location of IP connected devices (simulated in the test bed) using various location methods delivering different quality of service: A-GPS for very accurate positioning but slow response time in outdoor environment, WiFi for fairly accurate positioning and fast response time in indoor environment and Cell-Id for rough location but fast response time in every kind of environment. Experience the various applications available via the restful interface provided, such as location retrieval (R1), geo-fencing (R2) and dynamic selection of the location method based on the end-user environment (R2). Advantages The Location GE implements the very latest protocol standards such as SUPLv2 whereas competition currently relies on SUPLv1. SUPLv2 brings many new features like periodic tracking and geofencing features which are not possible with the previous version of the standard. Moreover, the Location GE provides a RESTFul API for accessing mobile device positions, whereas the competition relies on more complicated interfaces based on HTTP like OMA MLP. The core functionality of the Location GE is AGNSS technology which has been developed by a team of GNSS experts (TAS is system prime of EGNOS and prime of Galileo Mission Segment), bringing to the product advanced GNSS algorithms. 2.8 Semantic Application Support Description The main goal of the Semantic Web Application Enabler is to provide a framework for ontology engineers and developers of semantically-enabled applications offering RDF/OWL management, storage and retrieval capabilities. This goal will be achieved by providing an infrastructure for metadata publication, retrieval and subscription that meets industry requirements like scalability, distribution and security, plus a set of tools for infrastructure and metadata-data management, supporting most adopted methodologies and best practices. Functionality The Semantic Web Application enabler is based on the following design principles: (a) Support standards: Support for RDF/OWL, the most common standards used in Semantic Web applications. (b) Methodological approach: GE is strongly influenced by methodological approaches, so it will adopt and support, as far as possible, most adopted methodologies to achieve its goals. (c) Semantic repository features: Provide high-level common features valid for most of the existing solutions in the semantic web in terms of RDF / OWL storage and inference functionalities. (d) Ontology management: The enabler will provide an ontology registry and the API to control it, including some high-level ontology management functionalities. (e) Knowledge Base management: The enabler will provide a knowled base registry and the API to control it, including some high level knowledge base management functionalities. (f) Extensibility: The most important part of the architecture design of the 11/09/2013 Page 37 of 96

enabler is to define interfaces that allow the extensibility of the system. Where applicable the design should also be modular, to facilitate future extensions and improvements. The reference implementations should comply with this common design. Semantic Web applications skateholders will benefit from this generic enabler that: (a) Provides an infrastructure for semantic web applications that support large scale applications including: metadata storage in RDF, publication of RDF triples, querying by SPARQL and inference. (b) Provides a framework for supporting methodologies and engineering processes related with metadata management and ontology development. Advantages None 2.9 Semantic Annotation - SANr Description Semantic Annotator GE performs named entity recognition and semantically links them with Linked Open Data objects. Named Entity Recognition can recognize persons, places and organizations in a text. Once recognized, each entity is passed to a semantic broker, who tries to identify the correct correspondence over the most used linked open data repositories (dbpedia, which is general, and geonames, for places). It can also provide html snippets describing content for dbpedia entries. Functionality Semantic Annotation GE aims at performing named entity recognition and semantic annotation for a given text. The basic Idea is to use an open-source language processor (Freeling) plus some custom software to identifies the entities contained in the text to analyze. Once the entities (which are basically persons, places and organizations) are identified, the system searches into semantic triple stores and databases RDF information about those entities by means of SPARQL Queries. For each entity the system offers the set of candidates found (if existing) each one with a related score giving an hint of the one who should be closer to the real meaning for the context given by the text. Once collected, the results are returned in Json format It can be used to enrich content, contemporarily defining each entity as unique. By using the html snippet function a small snippet describing each entity can be shown directly on the content. It is also possible, for each application who may save locally concept related to a text 11/09/2013 Page 38 of 96

to offer users semantically related concept standing on the same platform or on other platforms sharing the same annotation system. Advantages Semantic Annotation GE is based on very early research results of TI giving to an entity a way to augment primary data with additional related information thanks to available public and dedicated data sources (public data bases and wikis) and is considered as a mechanism data enrichment putting together many types of data in a reasonable related way. This is a sort of recognition and artificial intelligence engine as a tool to build more comprehensive services in the environments of missing or undermined information. The Semantic Annotation GE is based on a classic tags (or key-words) extraction schemas and Linked Object Data concepts widely adopted in the information augmentation and knowledge enrichment. The component cannot be considered as a stand-alone product or service, but rather is to be operated in conjunction with other GEs. Therefore no detailed comparisons with analogous solutions of this GE have been yet performed. 3 Generic Enablers in the Apps Chapter 3.1 Service Description Repository - Service Description Repository Description It is a core enabler of the FI-Ware Business Framework. It provides a consistent uniform API to USDL service descriptions and associated media files for applications of the business framework. A service provider can use it to publish the description of various aspects of the service according to a uniform description language. Functionality It allows to publish and access service descriptions and related media files on the Web through a uniform protocol, which provides multiple various delivery formats and consistency checking. USDL is used in its Linked Data version "Linked USDL". Linked USDL describes services on a metadata level and can refer to supplemental resources of any media type. Therefore, the repository must be able to store resources in arbitrary formats. The RDF datamodel of USDL allows to refer to entities of the service description via the resource URL. Therefore, Linked- 11/09/2013 Page 39 of 96

USDL is already well prepared to allow the distribution of service descriptions all over the Internet. Advantages It is provided as an open source reference implementation for the Repository Open Specification. It is expected that the Repository GE will be provided as part of the core platform services and rather than a product on its own. 3.2 Service Registry - Service Registry Description It is used to store information on service instances necessary for run-time execution. Discovering entities and their description in an open distributed system often is achieved via registries, which have a well-known address. The registry serves as a kind of directory and for example can store detailed settings for concrete infrastructure components as well as information about human or computing agents. The information can range from stable to extremely volatile and is needed to make specific settings for and adjustments to other components in the platform. Functionality It acts as a universal directory of information used for the maintenance, administration, deployment and retrieval of services. Existing (running) service endpoints as well as information to create an actual service instance and endpoint are registered. This GE will be used by potentially all GE in the Apps Chapter in order to build a common database of runtime configuration options and properties. It can also be used by GE of other chapters, such as the Cloud, Security, Data or IoT to announce their instance specific information to the rest of the platform components. In a FI-WARE instance there could be multiple instances of the Registry for different purposes and usage domains, which are accessed uniformly according to the Repository RESTful interface specification. The FI-WARE Business Framework components in a concrete instance of the platform need to publish and retrieve information such as the runtime configuration or service endpoints. Therefore, the Registry provides directory functionality to make this information accessible. Advantages It is provided as an open source reference implementation for the FI-WARE Open Specification. The Registry GE will be usually provided as part of the core platform services, 11/09/2013 Page 40 of 96

e.g. integrated with the Marketplace. The competitive advantage of the Registry GE is that it is easy to use Web-based protocol in contrast to other registry or directory solutions. 3.3 Marketplace (part of Business Framework) - Marketplace Description It is made up from three mandatory and two optional components: Registry & Directory, Offering & Demand, Discovery & Matching, Recommendation, Review & Rating. It provides functionality necessary for bringing together offering and demand for making business. These functions include basic services for registering business entities, publishing and retrieving offerings and demands, search and discover offerings according to specific consumer requirements as well as lateral functions like review, rating and recommendation. Besides the core functions, the marketplace may offer value because of its "knowledge" about the market in terms of market intelligence services, pricing support, advertising, information subscription and more. Functionality It comes with an easy to use API that follows the REST principles and generally returns XML or JSON encoded responses. Since REST is independent from a concrete programming language, one just has to know how to make an HTTP request in the programming language of his/her choice. The core functionality of the Marketplace is to provide a uniform service interface to discover and match application and service offerings from providers and sources (e.g. published by different stores) with demand of consumers. This core functionality provides a basis for extended services depending on the domain and nature of the target markets. Advantages It is provided as an open source reference implementation for the FI-WARE Open Specification. The Marketplace GE will provided as a cloud offering of a business framework platform provider. Currently there are no standardized marketplace solutions for services available. The competitive advantage to other offerings lies in the openness of the API, the use of a Unified Service Description Language and the interoperability with other FI-WARE platform enablers. 11/09/2013 Page 41 of 96

3.4 Store (part of Business Framework) Description One key component of the Service Business Frameworks (SBFs) provided by FI-WARE is a Store for selling services to both consumers and developers of Future Internet applications and services and for end-to-end managing of offerings and sales. While a marketplace is a platform for many stores to place their offerings to a broader audience and consumers to search and compare services and find the store where to buy, a store is owned by a store owner who has full control over a specific service/app portfolio and offerings. The final business transaction (buying) is done at the store and the whole back office process (end-toend managing of offerings and sales) is handled by the store. Functionality WStore is an open source, reference implementation of the FI-WARE Store Generic Enabler. The design of the Store generic enabler does not focus on consumer-centric mobile apps, but on selling enterprise-level apps and cloud services that will leverage the FI-WARE platform in general and its business framework in particular. Its integrated support for pricing (including pay-per-use modalities), accounting, charging, billing and revenue sharing will position it one step ahead of the current market. Advantages One competitive advantage will be the availability of a viable ecosystem of related apps, services and components and a fully-fledged business framework, instead of an isolated product. Service providers will find in FI-WARE several valuable assets to create a killer application platform that would be attractive to the developer and content partner community. The Store GE is provided as an open source reference implementation for the Open Specification, under EUPL v1.1. It is also planned to offer it under a SaaS model. 3.5 Light Semantic Composition - Light Semantic Composition Editor Description It is a graphical tool which generates service compositions through BPM files. The main drawback of service composition is the difficulty for the business managers to design service compositions with any technology knowledge. Thanks to semantics, this composer close the gap with business people making use of business domain ontologies that hide as maximum all the technical details. 11/09/2013 Page 42 of 96

Functionality The Light Semantic Composition GE is based on the Service Composition Open Specification, which documentation is available via the following link: https://forge.fiware.eu/plugins/mediawiki/wiki/fiware/index.php/fiware The Service Compositors in the current panorama are too oriented to developers despite normally are business teams the people that carry out this activities. The semantics is the most suitable tool to break this gap between business and technician, since normally the team is composed of the business role that design the process and the technical role that implements it. This is a pioneer tool that provide the business teams to get full independence from developers in terms of launching the execution of business processes designed by themselves. Advantages One competitive advantage of the Light Semantic Composition GE is the gap reduction between the Business Analysts (Domain specific business processes and conceptualizations) and the services integrators (technical domain); improving the process definition and the communication among them, being more efficient and effective in creating business processes. Another advantage is the semantic approach used to annotate the processes and the tasks that will allow to work with the same vocabulary and discover the most appropriated services. 3.6 Service Composition - Ericsson Composition Editor (ECE) Description The Ericsson Composition Engine (ECE) consist of a Composition Editor and an Execution Engine. The Execution Engine is exposing and executing the composed services. The service provider/operator deploys services/mashups by fetching technical service descriptions and composition description from the repository. Using dynamic late-binding composition, the engine creates a workflow on the fly from a matching skeleton. It then it executes the business logic and manages the dataflow transformation and the control flow elements specified in the skeleton step-by-step. The Composition Editor offers a graphical user interface (GUI) to construct and configure composed services and applications. The editor allows the creation of composed service skeletons. The skeletons provide the business logic, the data and control flow, and service placeholders. 11/09/2013 Page 43 of 96

Functionality The Service Composition is a core enabler of the FI-WARE Platform. It allows users to create, manage and execute composed services. It consists of to main parts, the editor and the execution environment. The editor provides users with a graphical environment that allows them to create composed services in a more convenient way, providing graphical constructs for flow control and component service templates (and hiding away some of the service communication and data representation details). These composed service representations (i.e. skeletons) specify the main parts of the business logic of the composed services. During the run-time the composition engine dynamically decides about what services to invoke or which data source to use based on constraints evaluated at that particular time. Essentially the composition engine is creating the workflow step-by-step during runtime, and different composition decisions can be taken depending on external constraints or on the return values of previously executed services. The ECE features a powerful service creation and composition environment, allowing implementation of new applications or service components through Java EE development and/or by orchestration of existing service components into new composite applications. The ECE s Advanced Composition feature includes an intuitive graphical development environment designed to support rapid creation, deployment and modification of compositions, allowing short development lead times. Constituent services can be reused over and over again, as part of new composite applications. Advantages None 3.7 Service Mashup - Mashup Factory Description It is an experimental web-based application, which allows end users without programming know-how to compose their own services for their immediate needs in communication, organization and information. Functionality The service creator develops mashups by combining preconfigured services from a library. It contains for experimentation purposes 3rd party services of three categories: application logic (e.g. sending SMS, phone conference), data (e.g. storing data, geo data), and user interface (e.g. creating web dialogs). 11/09/2013 Page 44 of 96

It supports all phases of service composition, operation and testing in an integrated webbased environment with a minimal necessary feature set. This allows non-programmers to experiment with own applications in order to fulfil immediate communication requirements. By combining pre-configured services there is no need for service creators to develop own software integrating APIs which is costly, extensive and knowledge intensive. Advantages Mashup Factory integrates (pre-defined) APIs of external web services and allows users without developer skills or knowledge about REST interfaces, parameters, operational know how etc. to create service mashups and operate them in an unique web based user environment. This combination of easiness and process integration of service design and operation is a major benefit and differentiator from comparable products. 3.8 Application Mashup - WireCloud Description It offers a next-generation end-user centred web application mashup platform aimed at leveraging the long tail of the Internet of Services. Functionality It helps end users to innovate through experimentation by choosing the best suited widgets and prefab mashups (a.k.a. mashup-lets) for your devised mashup from a vast, ever-growing distributed catalogue. It offers its main features through two integrated tools: The wiring editor, and the piping editor By using Wirecloud one has access to the following key features: (a) Innovate through experimentation by choosing the best suited widgets, operators and prefab mashup; (b) the wiring editor allows for easily connecting widgets in a mashup to create a full-fledged dashboard with RIA functionality; (c) the piping editor allows for easily connecting widgets to back-end services or data sources through an extendable set of operators, including filters, aggregators, adapters, etc.; (d) Sharing of the newly created mashup with other colleagues and users. Comment it, tag it and rate it to foster discoverability and shareability Advantages One competitive advantage of the FIWARE Application Mashup GE (the Wirecloud platform) will be the availability of a number of libraries and APIs specifically designed to help web client 11/09/2013 Page 45 of 96

developers (i.e. javascript developers) to access different FI-WARE GEs from the MAC (widgets, operators) code. This includes the Identity Management (IdM), the NGSI-9/10 context broker, the pub/sub broker, the object storage and much more. Additionally, the Wirecloud platform will be fully integrated by design with the FI-WARE business framework, specifically with the Store and the Repository GEs in order to offer a fully-fledged store of mashable components. Another competitive advantage will be the comprehensive approach taken to application mashups, which, unlike many other products in the market, considers the mashup process at both the data and the UI level. The visual editor will offer support for wiring (i.e. communicating widgets) and piping (i.e. accessing and manipulating data sources and services with processing elements called operators and connecting the result to widgets), and will offer support for lightweight semantic recommendation. The Wirecloud GE is provided as an open source reference implementation for the Open Specification, under AGPL v3 w/ classpath-like exception. It is also planned to offer it under a SaaS model. 3.9 Mediator - Mediator_TI Description It is a middleware application responsible for providing interoperability among different communication protocols and among different data models. Functionality It is based on the open source packages WSO2 ESB and Apache Camel. Moreover, it includes custom TI code and custom virtual proxy configuration specifically developed for FI-WARE. The current version of the Mediator does not provide remote API so the creation of mediation services can be only performed using WSO2 ESB funcionalities of the Mediator and its custom pages for coding Apache Routes through Java classes. Thus, the relevant User and Programming Guide, for the current release of the Mediator, are those related to the open source packages which the Mediator is based on: Apache Synapse Virtual proxy and Apache Camel routes. The Mediator allows to (a) expose a REST web service as a SOAP web service; (b) expose a service with an xml payload with any different xml structure for the payload; (c) expose old ASCII delimited message used through old protocols such as FTP, as web services with an xml payload, both SOAP or REST. Using the Mediator one can compose a Mediation Service that realize the transformations s/he needs between the caller and the target service. The Mediation Service exposes a virtual proxy, that can be used to invoke the target service with the mediations defined in the Mediation Service. The optional SETHA2 software library, delivered as part of the Mediator GE, provides APIs that can be used to deal with matchmaking issues arising from dynamic mediation of services, based on semantic information, at runtime. 11/09/2013 Page 46 of 96

Advantages The aim of the Mediator GE is to centralize protocol and data transformation capabilities. In addition, it is able to provide dynamic mediation task, faillover and load-balancing functionalities. The main competitive advantage of the Mediator GE is its modular nature with the ability to Plugin more capabilities. 4 Generic Enablers in the IoT Chapter 4.1 (Gateway) Data Handling Esper4FastData Description It addresses the need of filtering, aggregating and merging real-time data from different sources. Applications should receive value-added data that are relevant to their needs thanks to the Complex Event Processing technology (CEP). This is also referred to as event stream analysis, or real time event correlation. Functionality It is fully integrated with the other enablers of FI-Ware, especially using the Open Mobile Alliance (OMA) Next Generation Service Interface Context Enabler (NGSI 9 / NGSI 10), which is a very useful and easy format to encapsulate all data and events from RFID tags, Zigbee or IETF devices, as many other smart things. It provides a common access to all data for several kinds of sensors and things. Using a micro database, this enabler is able to save and store locally relevant information and ensure privacy. It is also the first stage towards transforming data into events using smart rules. Advantages It provides an easy and straightforward REST API that emphasizes the main CEP features that one needs at gateway level. It allows value-added composite data to be created, thanks to rules that process and merge real-time information from lower-level devices, and various data sources. 11/09/2013 Page 47 of 96

4.2 Middleware KIARA Description The goal of KIARA is to provide a Middleware for efficient and QoS/Security- aware invocation of services and exchange of messages for the FI-PPP program and beyond. KIARA builds on top of a well-established, proven, and high-performance product RTI-DDS from RTI and combines it with innovative research results to provide an advanced middleware layer that targets the specific requirements of the Future Internet. Functionality (a) KIARA provides radical improvements in performance and scalability not only for traditional Web services, but also for distributed applications in general ranging from tiny devices in the Internet of Things to high-performance computing applications; (b) KIARA improves developer productivity and greatly simplifies application integration using a simpleto-use IDL for specifying the communication contract between peers as well as a novel API that allows applications to communicate in terms of their own data structures; (c) KIARA dynamically and transparently selects the optimal communication mechanisms, protocols, and data representations to be used between two peers, including the traditional SOAP/REST protocols but also optimized binary formats and mechanisms like pointer forwarding, shared memory, and the use of specialized network infrastructures; (d) KIARA uses simple, high-level specifications of QoS and security requirements from the application for automatically selecting the best communication strategy, thus clearly separating the high-level concerns of the application/developer from the concrete and varying technical details, such as the available network and other capabilities and resources; (e) KIARA, for the first time, uses a Secure By Design" approach for of the communication architecture, thus trying to eliminate network connections as the dominant source of security threats. Today, it is fair to say that nearly any application depends on distributed and service-based computing of some sort. This is most apparent in the mobile and cloud computing areas but this trend is quickly affecting essentially all areas of computing. Advantages The baseline asset of the current FI-WARE advanced middleware release (DDS) is already well established in real-time and reliability sensitive industries like military, aviation, air traffic control, etc. It provides robust (no single point of failure), efficient (minimum latency) communication and some QoS features to shape the data flow and deliver predictable results. It also supports multiple communication pattern like publish/subscribe, point-to-point or request/reply for more efficient communication. Release 1 of the advanced middleware GE also contains support for RPC over DDS to provide the well known Remote Procedure Call client/server communication in a simple and efficient way. The standardization process for 11/09/2013 Page 48 of 96

RPC over DDS by the OMG is still ongoing. The final release of the GE will support more efficient dynamic data handling and additional communication transports for highperformance applications, backward compatibility to RESTfull web services and advanced security features. 4.3 (Gateway) Data Handling SOL-CEP Description SOL/CEP is a fast, versatile Complex Event Processor, able to collect vast amounts of asynchronous events of different types and correlate them into single events, called Complex Events. It can read from and write to numerous different channels using various different protocols. It is driven using a domain specific language called Dolce Functionality The Gateway Data Handling GE is fully integrated with the other enablers of FI-WARE, especially using the Open Mobile Alliance (OMA) Next Generation Service Interface Context Enabler (NGSI 9 / NGSI 10) which is a very useful and easy format to encapsulate all data and events from RFID tags, Zigbee or IETF devices, as many other smart things. In the Internet of Things, systems will have to deal with an ever growing amount of data from hundreds and thousands of sensors and devices. Millions of readings of a heterogeneous nature, such as temperature, status or any type of readings have to be processed to meaningful information. The Gateway Data Handling GE is also the first stage of intelligence transforming data into events using smart rules. Applications are now able to collect in realtime large amounts of data, but only relevant data avoiding boring and asynchronous data analysis. Advantages None 4.4 (Gateway) Protocol Adapter Description It is capable to handle ZPA (ZigBee Protocol Adapter), which enables the communication with IoT Devices implementing the ZigBee specification. The goal of a Gateway Protocol Adapter GE is to translate a specific protocol (in the case of ZPA is ZigBee) into a unique internal language, 11/09/2013 Page 49 of 96

which normalizes the different communication protocols (in the case of ZPA is the Generic Device API). Functionality The ZigBee specifications of the ZigBee Gateway Device, on which this implementation of the Gateway Protocol Adapter GE is based, can be found via the following link in the official ZigBee Alliance website: http://www.zigbee.org/standards/zigbeenetworkdevices/overview.aspx The ZPA implementation is needed of a Gateway Protocol Adapter GE when one has a ZigBee WSN (Wireless Sensor Network) that wants to integrate in the FI-WARE Eco-system Advantages It holds an official certification from ZigBee Alliance of compliance with the standard, which means that ZPA is guaranteed to interoperate with a plethora of products from more than 100 companies worldwide. The product has been embedded into several telecom devices, including the Broadband Access Gateway and the Cubo device of Telecom Italia. The product has been successfully tested with several chip manufacturers, including Ember, Texas and Freescale 4.5 (Gateway) Device Management Gateway Device Management Description It is the "core" part of the gateway being the main interface towards other gateway GEs, performing basic communication capabilities towards the backend/devices, and hosting resource descriptions. It implements an HTTP REST API based on the IETF CoRE open specification for the northbound communcation with the IoT backend. Functionality It registers all devices which are directly connected with a COAP interface and proposes a Generic Device Interface to plug other Protocol Adapters and manage many other families of devices 11/09/2013 Page 50 of 96

It takes the role of connecting and integrating IoT and legacy end devices towards the Internet and an IoT backend (service enablement environment). Advantages It provides, from an application point of view, a simple access to the relevant smart thing for the application. 5 Generic Enablers in the Security Chapter 5.1 Security Monitoring - Service Level SIEM Description It offers two services, which can be used independently of one another: (a) MulVAL Attack Paths Engine; (b) Service Level SIEM Functionality MulVAL Attack Paths Engine Component is an end-to-end framework and reasoning system that conducts multihost, multistage vulnerability analysis on a network. Attack graph presents a qualitative view of security discrepancies: (a) It shows what attacks are possible, but does not tell you how bad the problem is; (b) It captures the interactions among all attack possibilities in your system. The Service Level SIEM Component provides extended correlation capabilities to the Security Monitoring GE, in terms of performance and adaptability, of huge amount of incoming security events. In the context of FI-WARE this high-performance and scalable event correlation engine is built on top of an existing open source SIEM (in particular OSSIM). OSSIM is a security event monitor system. It will check the network for latent problems, or for hints of what will turn in potential problems in the future. MulVAL Attack Paths Engine and Service Level SIEM (SLS) are contributing risk management of IT infrastructure. MuVAL Attack Paths Engine allows you evaluating the security risk assessment, the potential attack paths and improves the capability to detect security breach and the cyber-resilience of infrastructures. The SIEM allows you to raise alarms, the correlation of security events having highlighted a situation of risk (abnormal behavior, unforeseen events, action mischievous). Limitations of current SIEM (Security Information and Event Management) systems are mainly in line with performance and scalability leading to the 11/09/2013 Page 51 of 96

inability to process vast amounts of diverse data in a short amount of time. Next generation of SIEM solutions should overcome these performance limitations of its predecessors allowing in this way to monitor more systems, to process more complex rules or even to correlate events at different layers. To achieve the above commented goals, the Service Level SIEM (SLS) included in FI-WARE incorporates a high performance parallel correlation engine that will improve drastically the correlation capabilities of the current SIEM solutions available in the market. Advantages Security Monitoring will: (a) overcome SIEM (Security Information and Event Management) systems limitations (mainly in line with performance and scalability leading to the inability to process vast amounts of diverse data in a short amount of time). As such Service Level SIEM feature of Security Monitoring GE will overcome these performance limitations of its predecessors allowing in this way to monitor more systems, to process more complex rules or even to correlate events at different layers. (b) will not only offer unique features such as attack paths computation & visualization, scoring of computed attack paths/graphs and remediations computation but will also use all these features conjointly to provide tools for proposing cost-sensitive remediations and evaluating effects, thus supporting/enabling informed decision making. This is seen as true competitive advantage to what is offered today since addressing not only risk but also impact. 5.2 Identity Management - GCP Description It is a fully managed Software-as-a-Service offer covering typical identity- customer- and contract-management functionality needed for digital services. Functionality The GCP is using OpenID and the OAuth protocol. The GCP allows its business customers or partners to offer their digital services to end users without having to manage technical processes such as user-registration, login, customer-self-care or management. The GCP is a white-label platform and can be fully adapted to the brand of the partner such that it integrates with the partner s general customer experience. It can be integrated using standard technologies and interfaces, both on a user-interaction level as well as on a server-to-server communication level to enable technical integration. 11/09/2013 Page 52 of 96

The GCP covers all parts of the customer lifecycle as well as of identity management by providing both (skinnable) user-interfaces as well as technical (back-end) interfaces. One can concentrate on the development of his/her application and easily integrate an identity management system, which enables him/her to authenticate and authorises the access to his/her application. Advantages None 5.3 Identity Management - One-IDM Description Identity Management encompasses a number of aspects involved with users' access to networks, services and applications, including secure and private authentication from users to devices, networks and services, Authorisation & Trust management, User Profile management, Single Sign-On (SSO) to service domains and Identity Federation towards applications. Functionality The Identity Manager is the central component that provides a bridge between IdM systems at connectivity-level and application-level. It also delivers a multi-tenant user and profile management solution that allows Enterprises to manage consumers of their (Web based) services in the Cloud securely. Instead of developing and operating the user and profile management by themselves, it can be hosted in the Cloud as a tenant instance and will be delivered on demand. Identity Management is used in multiple scenarios spanning from Operator oriented scenarios towards Internet Service Providers (ISP). End users benefit from having simplified and easy access to services (User Centric Identity Management). Advantages There is a unique market position for Identity Management systems linking user accounts at services in the internet to identifiers of the user at the communication service provider. Thus, bridging the internet and the telecommunication world. In addition, the Identity Management 11/09/2013 Page 53 of 96

system can serve as the platform enabling privacy for the user by restrictive handling of personal attributes according to the user s needs. 5.4 Data Handling - PPL Description It mainly focuses on revealing certain attributes according to specific privacy and security conditions. It supports integrated data handling, in particular through two-sided detailed data handling, that takes into account specific preferences/policies expressed using the PPL language, based on XACML. Functionality Data usage purpose must always be declared, as it is a relevant part of the policy that must be expressed, as well as downstream usage, i.e., whether one can disclose collected data with third parties. The PPL language supports the enforcement of a number of obligations that are bound tightly to data. For instance, one can impose a specific retention period, as well as the production of user's notifications and/or logging under certain conditions. When private and sensitive data is sent and stored into external web or cloud servers, there is no real control by the owner. This lack of control is due to the absence of mechanisms and methods that provide access and usage control to the stored data during its life time. This generic enabler provides the framework and the necessary tools to give the control to the data owner by imposing obligations on the data and restrictions. Advantages PPL is a usage control tool that can be used by peers in order to ensure that data operations take place in a well-regulated way. Therefore, it permits to enforce prescriptions on data usage that can be relevant especially for sharing confidential and personal data. PPL can be used to enforce compliance with law directives, like for instance and most notably the EU Directive 95/46/EC on privacy and data protection. PPL represents an unique attempt to provide a generic service for regulating data usage. No generic access/usage control service exists, even if a part of its functionalities can be implemented to some extent in specific applications. Given the flexibility of the interaction model, that can potentially cope with any data format, and the generic implementation (i.e., data control is regulated by user-specified policies, and not by fixed templates PPL offers a significant competitive advantage for the FI- WARE platform. 11/09/2013 Page 54 of 96

5.5 DB Anonimyzer (Opt) - DBA Description DB Anonymizer is a service that helps in data disclosure activities, and in particular when considering anonymization strategies. DB Anonymizer is designed to be easily reused by other services, compositions or applications. Functionality DB Anonymizer has a very simple API. Its main functionality can be used through two simple methods, one to submit a policy to be analysed (together with its associated dataset), the other to retrieve the computation result. DB Anonymizer permits to understand if a certain anonymization policy for a dataset should be considered safe or not. The service offers a function that calculates a value, that represents the possibility of data that an attacker can reconstruct from an anonymized dataset content. DB Anonymizer exposes a ReSTful API, that allows users to send an anonymized DB dump, as well as an anonymization policy (examples are provided in the Downloads section), and to retrieve asynchronously the result of the analysis. Advantages No anonymization/re-identification risk estimation service exists, which is publicly available. The DBA implementation, through its public specifications, and focusing on personal and sensitive data, opens and sets the bar of the competition in this market segment; therefore, DBA gives the market sector leadership to the FI-WARE platform. 11/09/2013 Page 55 of 96

Annex II: Specific Enablers (June 2013): 1 Specific Enablers from Project ENVIROFI 1.1 Discovery Broker (SE-MED-1) Service to perform geospatial queries towards the observation registries and inventories registered in the ENVIROFI system. The component is able to connect existing observatories, and systems (e.g. GEOSS, INSPIRE, etc.). This component supports: metadata harvesting and distributed queries discovery of datasets, services and models discovery towards heterogeneous information sources including those based on OGC CSW, W*S, SWE. Catalogue queries for services and data. Queries towards standard catalogues (CSW/*) and inventories (OGC WFS, WMS, WCS) and Community-of-Practice catalogues and inventories. 1.2 Discovery Augmentation Component (SE-MED-2) Service to semantically enhance queries. The service accepts semantic queries and expands them into multiple geospatial queries, collecting answers. It enables multilinguality (through multilingual thesauri), concept-based queries (through ontology services), and geospatial extended queries (through gazetteers). The discovery augmentation component is currently deployed in an operational setting as one of the internal components of the GEO DAB is one of the internal components of the GEO DAB (GEO Discovery and Access Broker) which is part of the GEOSS Common Infrastructure. 11/09/2013 Page 56 of 96

1.3 Access broker (SE-MED-3) Service to access observations provided by heterogeneous sources and services. It is able to access datasets reprocessing them in order to provide them on a Common Access Environment (same resolution, coordinate reference system, etc.). The component supports resampling, interpolation, projection through external services. The SE-MED-3 ENVIROFI enabler is based on the re-engineering of the stable version of the CNR GI-axe discovery augmentation component. 1.4 Connector SOS (SE-MED-4) Connector to provide read/write access to SOS services for ENVIROFI applications This SE allows ENVIROFI applications to access the observations which are hosted on OGC SOS 1.0 servers 1.5 Connector WCS (SE-MED-5) Connector to provide access to WCS services for ENVIROFI applications None 1.6 Connector WCS (SE-MED-6) Connector to provide access to WFS services for ENVIROFI applications. 11/09/2013 Page 57 of 96

None 1.7 Connector WMS (SE-MED-7) Connector to provide access to WMS services for ENVIROFI applications. This is about to produce customized maps for the user. Interesting aspects are: Usage of SLD & SE Situation-aware presentations None 1.8 Connector Toolbox (SE-MED-8) The toolbox will provide a framework to produce connectors to access these data in a manner similar to the access to standardized services, especially for timeseries data. The TS-Toolbox has been used as a mediator allowing the AIT-s SOS service to access the observations stored in the Environmental Georeferenced Observation Service and make them available to third-party applications in standardized form. 1.9 Mediator Federated fusion result set linked data query toolbox (SE-MED-10) Component to provide clients with a single endpoint to query across heterogeneous sensor datasets & processing result sets. 11/09/2013 Page 58 of 96

All fusion services now use a backend semantic data layer that provides RDF metadata in addition to MySQL numeric result sets, and can be queried using a SPARQL query. 1.10 Download and transcoding of sensor data service (SE-MED-11) It provides a common interface for accessing and potentially massively downloading data from different data sources, transcoding them in the SWE format. If the metadata associated with data are present or inferable, they can be published in specific configurable databases and linked to the raw data. It supports configurability: via the provided input in the restful operational interface via dedicated restful management interface via configuration file Created tooling to upload data from ERDDAP and EUMETSAT which is used as pre-processing fusion steps by the spatial-temporal service SE. We have not fully automated this software, so it is not a stand-alone specific enabler. It is however integrated into the spatial-temporal service SE (FUSION-1). 1.11 Environmental geo-referenced observation service (SE-GEO-1) This enabler acts as a storage and retrieval service for observations coming from VGI applications or external data sources. Input data coming from the user interface (mobile client application/web portal) or from other data sources is validated, transformed into new observation objects when necessary and stored in the observation storage. Observation objects are defined as GeoJSON documents and stored in a database from where they can be retrieved using HTTP REST interface and via SOS O&M interface. Observation objects refer to objects of interest which is the second type of JSON documents beside the observation objects stored in the database. 11/09/2013 Page 59 of 96

The Environmental Geo-referenced Observation Collection Service SE provides a service backend for storage and retrieval of the observations from the ENVIROFI mobile observation app, as well as the means to exchange information with other enablers, and to interpret and present the observations in the way most suitable for the application at hand. Observations originating from the ENVIROFI applications (for instance a mobile client application or a web portal) or from other data sources are validated, transformed into observation objects, and stored in the observation storage. 1.12 Environmental geo-referenced observation identification and processing service (SE-GEO-4) This service will be an optional extension to SE-GEO-1. The functionality is to allow a user to analyse and classify an observation. The mobile client/web portal provides an id of an observation object and requests an identification of the observed phenomena. Other enablers are triggered to perform semantic enrichment on this object and to link this observation with related information resources in order to come to a classification result. GEO-1 service produces new events whenever an observation is added to the store. This functionality has been used to trigger external services and collet results of the processing as needed. For example, in WP1, the GEO-1 triggers the leaf recognition service, and saves the result as new observation. 1.13 Environmental geo-referenced observation visualization service (SE-GEO-5) Service for visualizing observations. The mobile client/web portal provides a list of observation object ids and requests a visualization of the observations e.g. in a tabular form or in a map. None 11/09/2013 Page 60 of 96

1.14 Environmental geo-referenced observation operating service (SE- GEO-6) Optional extension of SE-GEO-1. Service for performing algebraic and logical operations on observations. The client provides a list of observation object ids and requests e.g. a sum of observed values or a logical operation on the observations. The operation result shall be returned to the client. This will only make sense for observations of the same type, e.g. for calculating an average temperature value at a certain location or for checking if the threshold for an air pollution value was exceeded. None 1.15 Environmental geo-referenced image sample archive service (SE- GEO-7) Service to allow user and expert uploads of annotated image sample data. Annotations include species class labels, geo-references, and other visual annotations (e.g. environmental domain specific asset characteristics). This service will provide integration for crowd sourcing of environmental sample images via existing web 2.0 geo-tagged image upload apps. The image archive SE underwent an internal system test involving a small scale crowd-sourcing activity (a few ITINNO staff acting as volunteers) taking images of leaves from around the south of England. This allowed us to validate the ability of the imager archive SE to support multiple users, 100's of image uploads, different styles of camera work and images both with and without geo-tags. This system test also provided valuable feedback on the user interface resulting in incremental improvements to the SE. 1.16 Crowd-sourced sample quality assessment service (SE-GEO-9) 11/09/2013 Page 61 of 96

It supports automated quality checks using sample-specific quality metrics to identify possible inconsistencies between uploaded samples and existing training samples. The automatic quality checking will be used to monitor large volumes of crowd-sourced samples and filter incompatible and poor quality images to reduce the number of flagged samples as requiring manual checking. This is defined as automated service capable of assessing the quality of crowd-sourced observations. The implementation for "photos" capable of recognising (some) trees by their leafs has been done as the "Environmental image sample classification service" 1.17 Environmental geo-referenced observation proxy service (SE-GEO- 10) This service acts as a proxy for geo-referenced collection and retrieval services. When installed on user s device, this service can answer requests for storing and retrieval of observations even in the case network connection is currently unavailable. The interfaces for storing and retrieval of observations are inherited from SE-GEO-1. The service can be instructed to synchronize only the part of the observations that are relevant to the user, based on spatial, temporal and application-relevant criteria (e.g. type of observation). This service acts as intelligent proxy for the "Environmental Georeferenced Observation Service SE". If installed on a user s site of mobile device, this SE will answer requests for storing and retrieval of observations even in the case network connection is currently unavailable. The interfaces for storing and retrieval of observations are inherited from the Environmental Georeferenced Observation Service. As a consequence, other services and applications (e.g. "Environmental Georeferenced Observation App" SE) can access the Environmental Georeferenced Observation Proxy Service in exactly the same way they would access a central "Environmental Georeferenced Observation Service SE" instance. 11/09/2013 Page 62 of 96

1.18 Environmental geo-referenced observation app (SE-GEO-11) This SE is a mobile application for smartphones enabling the user to provide observations as VGI (Volunteered Geographic Information) as well as visualize existing observations. The Environmental geo-referenced observation app is a mobile smartphone application providing typical use cases for the visualization and acquisition of environmental data. The goal of this application is to enable a human user to act like a sensor, i.e. to input his/her observations into a system where they can be combined with other sensor data by means of data fusion and modelling. The observations are stored as geospatial data objects locally on the smartphone and transferred via the Environmental Georeferenced observation proxy service (SE-GEO-10) to the Environmental Georeferenced observation collection service (SE- GEO-1). 1.19 Uncertainty annotation of environmental data service (SE-TAG-8) Service to maintain from different user perspectives uncertainty information about environmental data. Maintaining uncertainty annotations in a separate archive allows us to exploit a linked data style approach. It was designed how this specific enabler would work but did not have concrete datasets available, with uncertainty annotation, in time to develop a proof of concept demonstrator system. 1.20 Environmental spatial-temporal data fusion service (SE-FUSION-1) Service that allows users to, on-demand, aggregate multiple heterogeneous environmental data sources and create a fused spatial-temporal result set. 11/09/2013 Page 63 of 96

The spatial-temporal data fusion service supports pre-processing, aggregation, temporal fusion and data fusion of datasets. 1.21 Environmental image sample classification service (SE-FUSION-2) Service that will classify a new image using existing annotated image training sets and further contextual and geo-spatial information. The image classifier SE has been validated on a large dataset of leaf images taken from the south of England. 1.22 Environmental asset analysis service for geo-referenced sample archives (SE-FUSION-4) Service to spatially analyse, for different time periods, sets of samples of environmental assets. This service will make use of other SEs, such as the environmental sample archives and the spatial-temporal data fusion service, as well as external domain knowledge related to assets. Created backend tools to create spatial maps of image archive datasets containing leaf observations. These maps consist of observation geometry extracted and clustered from a MySQL database (e.g. image archive SE database). 1.23 Areas classification service (SE-FUSION-5) Service to identify the affected administrative areas regarding a determined hazard simulation. The simulation contains alphanumeric and geometry attributes, the areas 11/09/2013 Page 64 of 96

classification service matches the geometry with established and well-known administrative areas The Areas classification service consists of several operations that serve as a façade towards a geocode-attributed SDI. The core concept is the wrapping of specific SDI feature types and focussing just on geocodes. 1.24 Prediction service (SE-FUSION-6) Based on a SES event the service runs a model in order to provide a forecast (e.g., forecast for the concentration of algae along the different coastal points within 2 hours). None 1.25 Environmental model-based fusion service (SE-FUSION-7) The service, called Fusion4Decision, uses the OGC web services to encapsulate model-based processing algorithms, so-called Fusors. It uses heterogeneous data sources as input and publishes the results as environmental observations. Pollutant concentration measurements are only available at certain discrete measurement sites. Using models it is possible to calculate an approximate map of the pollutant distribution based on these individual measuring points. Likewise it is possible to turn wind speed and direction measurements into a vector field with arrows showing the wind distribution. These representations are much more end-user friendly. 1.26 Alert Notification Service (SE-NOT-1) 11/09/2013 Page 65 of 96

Service to enable users and/or software components to publish and register for receiving alert notifications. The purpose of this service is to enable users and/or software components to publish and register for receiving environmental alert notifications. 1.27 Sensor Event Service (SE-NOT-5) Service which allows sensor measurement thresholds to be setup which will subsequently trigger events when the measurements cross these thresholds. Events will be published using the WS-Notification standard. This SE is part of the OGC event processing (OGC-2) and dispatching stack, and similar in nature to Complex Event Processing GE from FI-WARE 1.28 OGC charting services (SE-OGC-1) This specific enabler is as such a placeholder to document the expected use by partners in ENVIROFI None 1.29 OGC processing services (SE-OGC-2) This specific enabler is as such a placeholder to document the expected use by partners in ENVIROFI 11/09/2013 Page 66 of 96

None 1.30 OGC storage services (SE-OGC-3) This specific enabler is as such a placeholder to document the expected use by partners in ENVIROFI None 2 Specific Enablers from Project FI-CONTENT 2.1 Scalable Dynamic Spatial Database This enabler provides the following service: given a set of moving objects (mobile users, avatars,...) reporting their position on a regular basis. First implementation in FI-CONTENT and evaluations for specific functions performed for Games & virtual environments domain. 2.2 Content repository and metadata This enabler is in charge of storing and indexing of all content types with unique global identifier for each item, including real-time verification of incoming content. Consistent and unambiguous identification of contents is required. It also associates metadata model management (including various types: Textual, Visual, Audio) and definition of contextual content delivery. 11/09/2013 Page 67 of 96

First implementation in FI-CONTENT and evaluations for specific functions performed for Professional generated content domain. 2.3 Recommendation services This enabler provides a service to facilitate content recommendation for the user. Recommendations will be based on the user group constellation, context (such as available devices, network connection, situation etc) as well as existing user profiles (including explicit and implicit preferences derived from usage patterns and social graph. First implementation in FI-CONTENT and evaluations for specific functions performed for Professional generated content domain. 2.4 Device management This enabler comprises a number of functionalities: Foremost it provides services with information about presence, capabilities, connectivity and location of consumer devices (cameras, PCs, cell phones, STBs, tablets). Devices also are uniquely addressable and the discovery mechanisms allow easily detecting and including additional devices into a session when desired. First implementation in FI-CONTENT and evaluations for specific functions performed for Professional generated content domain. 2.5 Secure authorization for data exchange The Secure Authorization for Data Exchange enabler provides the ability for the user to securely pair device such as a connected TV to an authenticated online account. This enabler provides the implementation protocol and user interaction flows to facilitate this user 11/09/2013 Page 68 of 96

scenario, using either an infra-red remote control, or a smartphone-based remote control as input devices. First implementation in FI-CONTENT and evaluations for specific functions performed for Professional generated content domain. 2.6 Content Enrichment This enabler serves all major functions to enrich content in multiple ways including object identification, content annotation, content recommendation and linkage to any web-enabled supplemental information or media (audio, video, text, images, animation, PDF, contact information, social media integration, video to video navigation, content interaction). Furthermore, it provides interfaces to incorporate web 2.0 capabilities and community functionalities as well. First implementation in FI-CONTENT and evaluations for specific functions performed for User generated content domain. 2.7 Ad hoc sharing The objectives of the ad hoc sharing enabler are to share content between users in the same geographical area, disconnected from the Internet, edit existing content and share it again, and synchronize the generated or modified in infrastructure-less conditions with online content. First implementation in FI-CONTENT and evaluations for specific functions performed for User Generated Content domain. 2.8 Bandwidth on Demand 11/09/2013 Page 69 of 96

The objective of the bandwidth reservation enabler is to provide bandwidth on demand for high-quality video streaming sessions to ensure sufficient quality of experience to end users, currently unfeasible over best effort Internet. First implementation in FI-CONTENT and evaluations for specific functions performed for High end B2B services domain. 2.9 Content finding / enrichment This enabler provides capabilities to facilitate access to the right content and digital search offering a simple instrument to find and group content about a particular subject, to refine search results based on contextual info (e.g geographical, ) and to enrich content by other content (e.g. UGC, text annotations, LOD, ). First implementation in FI-CONTENT and evaluations for specific functions performed for Edutainment & Culture and UGC domain. 2.10 Multimedia Indexing Recorded multimedia data are analyzed (e.g. segmentation, structure, object and audio/speech recognition), indexed and XML metadata (e.g. MPEG-7) are generated. The indexing processes video, audio, images and text data. Depending of the medium, the Text, Audio/Voice, Images, and Video are available. The identified meta information are stored along with the multimedia objects in the content repository & metadata enabler. The content finder enabler will use this collected information as one of its preliminary data sources. First implementation in FI-CONTENT and evaluations for specific functions performed for Edutainment & Culture domain. 11/09/2013 Page 70 of 96

2.11 Federated Social Network Federated Social Network enabler is basically a set of APIs to be used jointly with a media/file repository in order to control with whom personal reports and related content are shared with. Federated social networks are natively interoperable because of the nature of the protocols implemented. In order to reach their goal, the set of API offers a complete set of functionalities that relate to people for the management of users and friendship and the activity stream for the management of shared content. First implementation in FI-CONTENT and evaluations for specific functions performed for Edutainment & Culture domain. 2.12 Reality mixer A context aware connected interactive experience must focus on the development of methods to integrate and match real or filtered video footage with rendered virtual objects and characters seamlessly. In this way the mobile device acts not as a traditional electronic display, but as a lens onto the real-world with transparently aligned augmented reality content. First implementation in FI-CONTENT and evaluations for specific functions performed for Games and Virtual Worlds content domain. 3 Specific Enablers from Project FINEST 3.1 Business Collaboration Module (BCM) The BCM aims at the introduction of an infrastructure to manage the end-to-end networks of transport and logistics partners. It integrates information from different external sources as well as other modules of the FInest platform and makes this available for end-users of the 11/09/2013 Page 71 of 96

system. In order to store this data, the BCM uses the SQL/Non-SQL Storage provided by the FIWARE BigData Analysis GE. The FInest SEs are in fact the very services that are offered by the FInest collaboration space. 3.2 Event Processing Module (EPM) FInest EPM s role is to collect events from various sources and perform complex event processing on them in order to detect situations of interest; that is, of relevant meaning to the consumer of the event enabling them to react or make use of the event appropriately. In essence, the FInest EPM builds on top of the CEP GE and extends it to deal with proactive, that is, to future probabilistic events. The FInest SEs are in fact the very services that are offered by the FInest collaboration space. 3.3 Transport Planning Module (TPM) The Transport Planning and Replanning Module (TPM) is a FInest module intended to help with the planning and replanning of a transport chain, including describing the transport demand, finding and configuring a "best choice" of transport services, quotations and booking of the selected services. The FInest SEs are in fact the very services that are offered by the FInest collaboration space. 3.4 E-Contracting Module (ECM) The E-Contracting Module (ECM) is a core module of the FInest platform. The role of this module is to support the online and real-time establishment and management of transport and logistics contracts, as well as operations in marketplaces 11/09/2013 Page 72 of 96

The FInest SEs are in fact the very services that are offered by the FInest collaboration space. 3.5 FInest Login (Single Sign on with SAML Authentication) Target of FInest Login component is let the modules gain Single Sign-on capability. Our focus, Single sign-on (SSO), is a property of access control of multiple related, but independent systems. The FInest SEs are in fact the very services that are offered by the FInest collaboration space. 3.6 System and Data Integration This SE aims to provide a technology framework to allow service and application developers to implement concrete integrations for their services to external services, systems and the IoT. The FInest SEs are in fact the very services that are offered by the FInest collaboration space. 4 Specific Enablers from Project FINSENY 4.1 Gateway for Secondary Substations using S3C GE This domain specific enabler will develop a gateway fulfilling all xdsl/gprs routers' current requirements, and adapting it for Fibre to the Home (FTTH)/ Long Term Evolution (LTE) interfaces and for the use of S3C None 11/09/2013 Page 73 of 96

4.2 IEC 61850 protocol adapter One of the most prominent future-oriented solutions for electrical grids is the IEC 61850 protocol family. This protocol family can and will be used on Smart Energy Gateways for DERs, Secondary Substations or Home Energy Management Systems as well as in the communication front-end (CFE) of the Microgrid Control Center. None 4.3 Supervisory Controller as Service It operates in a closed loop by: observing the generated events by the process, and sending controls in accordance with specifications corresponding to the control strategies. None 4.4 Electric Vehicle Supply Equipment EVSE will enable Grid Operators to stop, start or limit the charge to an EV as part of an overall demand side management solution. End-users will also be able to remotely communicate with the EVSE to schedule a charge or receive information updates. Overall the EVSE supports actively the load balancing process and thus the optimal use of renewable energy. It supports real-time simulation of power system by using tools like the real-time digital simulator (RTDS). These simulation capabilities could be used to study and experiment the influence on the power grid of a huge amount of EVs to be charged. 4.5 Demand side management 11/09/2013 Page 74 of 96

This DSE assumes dwellers having an Energy-Efficiency Control System (EECS) at home for controlling and managing the consumption of electricity in their houses. The system allows receiving Demand Side Management (DSM) signals from the DSM manager (DSMgr) based on the subscribed conditions and user preferences. None 5 Specific Enablers from Project Instant Mobility 5.1 Route Determination Prototype This domain specific enabler provides itineraries for travellers and drivers alike (multi-modal solutions for travellers and the fastest routes for drivers). Multi-modality requires to efficiently mixing multiple means of transportation in a single consistent and optimal journey proposal. This enabler takes into account all the means of transportation (private cars, buses, metro) in a consistent manner making it easy to add new transportation mode. Route Determination 5.2 Simulator The simulator has multiple purposes. First, the simulation of the travellers/drivers by performing itinerary requests to the route determination engines. These requests are based on the actual statistical data of source-destination needs of the users. Second, the simulation moves the cars, buses and other mean of transport taking into account historical flow speed at the time of travel. The simulator is also responsible of the temporal coherence of the movements and of the matchmaking between travellers and means of transport. Third, the simulator provides an interface (REST) to the mobiles to show itineraries of selected travellers (selection being done by the situation display). Multi-Modal Travel 11/09/2013 Page 75 of 96

5.3 Situation Display The situation display shows the position of travellers and mean of transportation. It calculates and shows the mobility metrics (e.g. percentage of multi-modal itineraries). It allows for the selection of the traveller/driver pair whose itinerary (and initial hand-shake dialog) can be shown on the mobiles. The display interface authorizes new events to be injected to the simulation (e.g. car broken) leading to automatic rerouting of the potential travellers when required. None 5.4 Remote Internet access service discovery and configuration in the vehicle This specific enabler aims to provide to the car computer, also called on-board unit (OBU), new means to get access to the Internet. If the Internet connectivity is not a OBU s built-in functionality, it is most of the time required to connect directly one smartphone to the OBU using a USB cable to use its own Internet connectivity. The specific enabler allows using multiple smartphones at the same time without increasing the cost of OBU and without the complexity of using multiple USB cables. In some cases, the use of multiple smartphones helps to increase the resulting bandwidth. Smart city logistics 5.5 Intersection Virtual Controller This Enabler is in charge of creating the traffic signalling plans by computing the aggregated traffic information that receives from the abovementioned components and systems. This module can apply different control strategies to control different systems and/or different sub-areas of the same system. Different control strategies can be applied according to local needs, availability of traffic measures and design options 11/09/2013 Page 76 of 96

Traffic control in-the-cloud prototype 5.6 Consignee App The Consignee App is a smartphone app, developed for Android 4.0.x, which is used by the consignee to share data on his/her whereabouts in order to agree with the transport planner about a convenient time and location to receive goods. The consignee app first retrieves transport booking information for transport bookings of which the consignee expects a delivery. The consignee then selects the calendar events for which he/she is able to receive the goods. These calendar events are then uploaded to the transport exchange portal. When the calendar events have been processed a suggestion for a drop point is presented to the consignee, who is then able to accept or reject it. Dynamic Drop Point - Smart City Logistics 5.7 Transport Exchange Portal The Transport Exchange Portal functionalities developed for the dynamic drop point prototype consist of a web portal for monitoring incoming transport bookings and transport missions, which are updated in real time as they are being processed by the transport resources. The transport exchange portal also consists of a number of other enablers, which implement the web service interface that the vehicle- and consignee applications use to interact with the system. Dynamic Drop Point - Smart City Logistics 5.8 Bundled enabler set supporting the Consignee App and Transport Exchange Portal consisting of: Vehicle Transport Management Interface, Vehicle Transport Management Interface, Consignee 11/09/2013 Page 77 of 96

API, Consignee API, Itinerary Processor, Transport Resource Persistence, Transport Booking Persistence Functionality for storing, retrieving and processing of transport bookings, transport itineraries and transport resources. Dynamic Drop Point - Smart City Logistics 6 Specific Enablers from Project OUTSMART 6.1 Service Execution Specific Enabler This SE hosts running instances of the services that provide access to the Santander Cluster devices, for retrieving sensor data and controlling actuators (such as power regulators) and exposes these services to applications. None 6.2 CKAN CKAN is an open data platform software (ckan.org). The CKAN instance used for the purpose of this cluster has been modified to suit the needs to the open data utility case, where data is securely extracted from a SCADA/production system. The Instance is deployed on an Amazon AWS server. CKAN is used at the core of the odaa.dk open data platform in Aarhus. 11/09/2013 Page 78 of 96

6.3 Super Hero Software The Super Hero Software together with the Side Kick Software offers the capability of extracting SCADA data securely via OPC and transferring the data via http to a CKAN instance. This allows organisations using SCADA to open up their data in near real time to the public. The SE has been used to open up the SCADA data from Aarhus Vand to a public open data portal in Aarhus called odaa.dk. The data is not visible on the public portal yet due to some final decision processes at the utility company, but are available on a private instance. In addition, the SE is used to share data over private channels to research and knowledge institutions replacing an ftp/script method. Specifically the Super Hero Software works deep within the production system and securely extracts data to avoid any compromising of the critical infrastructure systems. 6.4 Side Kick Software The Side Kick Software together with the Super Hero Software offers the capability of extracting SCADA data securely via OPC and transferring the data via http to a CKAN instance. This allows organisations using SCADA to open up their data in near real time to the public. Specifically the Side Kick Software offer the data transfer mechanisms required to deliver data from the production system to the DMZ (via FTP) and further to CKAN via http. The SE has been used to open up the SCADA data from Aarhus Vand to a public open data portal in Aarhus called odaa.dk. The data is not visible on the public portal yet due to some final decision processes at the utility company, but are available on a private instance. In addition, the SE is used to share data over private channels to research and knowledge institutions replacing an ftp/script method. 6.5 City Dashboard 11/09/2013 Page 79 of 96

The City Dashboard is a visualisation of open data from Aarhus in a dashboard (http://citydashboard.alexandra.dk/dashboard/). The Dashboard fetches data via a CKAN instance and visualises the data in several widget type boxes of the dashboard. Data include social media to environmental data sources The dashboard is used in public installations and is publically accessible as a case of an open data application. 6.6 Waste basket maintenance connector Specific waste basket maintenance interface bases on REStful Webservices for the Berliner Stadtreinigung (BSR). Combining five parts of maintenance: Task management, waste basket management, sensing device management, malfunction management, and maintenance tour management. For each parts exist interfaces for creation, editing, searching and deletion. The current maintenance process of the waste baskets can be enhanced by using waste basket ID e.g. stored on an RFID tag and by using the correct geo position data of each waste basket. This is the key to an efficient maintenance process. 6.7 Swisslogix INTEGRA access This SE provides access to Swisslogix fill level sensor measurement. Swisslogix uses a proprietary communication protocol to access to the filling level sensor measurements. So adapters have been implemented to interface this protocol to the outsmart platform protocol and provide the sensor data to handheld or tablet devices. None 6.8 SwissLogic GPRS Gateway 11/09/2013 Page 80 of 96

This SE provides access to fill level sensor measurement. Again adapters have been implemented to interface this Swisslogix protocol to the outsmart platform protocol and provide the sensor data to cloud-based services. None 6.9 Leakage detectors Noise loggers: these devices are the basic component of the use case. They are sensing the presence of a leakage, periodically raise alarms and report data about the field measurement. The active leakage detection service is meant to support the utility provider in the localization of leakages that may be present in the water distribution network. Detection and localization of leakages enables efficient infrastructure maintenance. The core challenge is to guarantee scalability of the deployment both in term of CAPEX and OPEX. 6.10 Operation and Maintenance Center (OMC) Collection and analysis of data coming from the capillary network. None 6.11 Communication technology (GSM/UMTS SMS service) The communication technology is based on GSM/UMTS SMS service. The hard operational conditions suggest to rely on very robust communication paradigm such as SMS services. 11/09/2013 Page 81 of 96

None 6.12 Planning and optimization prototype It implements the logic which permits to design and optimize the deployment at the urban scale and to adjust and redeploy at the need the current configuration of noise loggers optimizing for the minimum number of loggers. Logger s cost is the core bottleneck in the CAPEX figures. None 6.13 Alarms and Measurements Analyser prototype It implements the logic which permits localize the leakages and to restrict the number of candidate pipes, thus providing a user interface for data analysis None 6.14 Service Information Repository The Service Information Repository (SIR) aims at providing the possibility to search & retrieve and store the information about services already available. It allows also creating, importing, and exporting the models to use. Moreover, it has to provide a licensing model for each service. 11/09/2013 Page 82 of 96

Santander and Birmingham Services 6.15 Outsmart Service Description Meta-Model The Outsmart Service Description Meta-Model SE, based on USDL Meta-Model, aims at describing business services. Starting from USDL M5 (ecore version) this model is customized in order to create a meta-model which is able to describe a U&E service. None 6.16 OUTSMART USDL-IDE Outsmart-USDL IDE aims at providing several Eclipse plug-ins in order to allow the interaction between Service Development Tool and Service Information Repository. These plug-ins allow to create a new service description, search for already existing services, visualize the information about services, and create automatically the client starting from a WSDL file of service. None 6.17 OUTSMART USDL Editor (Desktop application) In order to provide the cluster people with an user-friendly Editor, the USDL SAP Editor was customized adopting the Outsmart Service Description Meta-Model as meta-model. This adaptation allows to describe an U&E business service using the information envisaged by Outsmart Service Description Meta-Model. 11/09/2013 Page 83 of 96

None 7 Specific Enablers from Project SMART AGRIFOOD 7.1 Certification The Certification Service shall enable to check the reliability, authenticity and validity of the certifications and logos used along the food chain as well as all the product-related information associated to them. Smart Farming Smart Agri-Food Logistics Smart Food Awareness 7.2 Product Information The Product Information Service shall enable the actors of a supply chain to provide productrelated information to other actors Smart Farming Smart Agri-Food Logistics Smart Food Awareness 11/09/2013 Page 84 of 96

7.3 Business Relations The Business Relations Service (BRS) provides an interoperability infrastructure to maintain interactions of business partners, enabling connectivity and information exchange and facilitating the addressing and search of information in a Future Internet. Smart Farming Smart Agri-Food Logistics Smart Food Awareness 7.4 Identity Management Identity Management encompasses a number of aspects involved with users' access to networks, services and applications in under the SmartAgriFood (SAF) framework. It is a sine qua non for users to develop trust in the SAF applications of the Future Internet. It binds the user s credentials to service subscriptions. Smart Farming Smart Agri-Food Logistics Smart Food Awareness 8 Specific Enablers from Project SAFECITY 8.1 Configuration Management Each ad hoc node has to be able to self-configure in order to interact with other nodes to start forming the ad hoc network (addressing, determine the gateway node, specific communication configurations, status monitoring configuration, etc.). Also, this specific 11/09/2013 Page 85 of 96

enabler manages the configuration and regarding the status of the node and the mission of the network it can compute new configurations to be applied on specific nodes. This specific enabler was used to configure ad hoc nodes and the communication links between sensors adapters and gateway. 8.2 Communication Management This specific enabler manages the communication between ad hoc nodes. The functionalities provided by this enabler are determine data routes by applying a suitable routing algorithm, forward data through data routes, and ability to adapt to topology changes such as nodes join and leave or nodes mobility. The Safe City Security Manager SE is responsible for the security of the ad hoc network communication This specific enabler was used to communicate/forward data from sensors adapters to the gateway. 8.3 Resource Management This specific enabler is responsible for applying configuration profiles on ad hoc nodes local resources (physical/hardware and virtual/software) such as network interfaces, memory usage, software applications, and so on. According to the ad hoc network purpose can be applied different profiles. Only one profile was used for all ad hoc nodes. But the ad hoc nodes are ready to apply other profiles to use local resources. 8.4 Status Monitoring 11/09/2013 Page 86 of 96

Each ad hoc node device monitors its local resources, collects data and transmits this data to the storage service on the cloud and/or locally on a log file. This data allows a remote monitoring of ad hoc networks to help make decisions and adjustments in order to optimize their overall performance. Status data that is interest to monitor in ad hoc network nodes are: (1) battery level; (2) network activity; (3) positioning (if available); (4) neighbour nodes; (5) memory usage; (6) relevant sensors data; among others. The data collected with this specific enabler were battery level and wireless network signal level. 8.5 Alerting This specific enabler is able to process the status data monitoring by specifying alert rules inside each ad hoc node. Also, the alerts can be processed on the cloud (RUBE). It was not used locally, the alerts processing were done by RUBE (SafeCity application for event processing) on the cloud. This specific enabler was responsible for sending the ad hoc nodes status data to the SafeCity gateway. 8.6 Interface Layer The Interface Layer SE provides interfaces for Data Fusion in order to be able to interact with the other SafeCity modules (applications) (i.e. Decision Support System or direct access) through an access API. The Interface Layer SE has been used in the Data Fusion System. 8.7 Data Manager Layer 11/09/2013 Page 87 of 96

The Data Manager Layer SE provides an API to help integrate at the programming level the meta-data gathered by the SafeCity data collectors. The Data Manager Layer SE has been used in the Data Fusion System. 8.8 Service Layer The Service Layer SE aims to assist in the underlying querying capabilities over the SafeCity ontology by making use of Semantic Application Support GE as a semantic back-end. Through the use of these querying capabilities, the Data Fusion application is able to retrieve knowledge from semantic metadata in order to feed the demands from the upper layers. The Service Layer SE has been used in the Data Fusion System. 8.9 Data Management It stores information; all events are stored in a database for later analysis Decision Support System 8.10 Automated Response Manager It is responsible for the generation of automated responses when relevant/critical events are detected Decision Support System 11/09/2013 Page 88 of 96

8.11 Rules Designer The goal of is to provide a MMI for the DSS application. This MMI is used by the user/operator to specify/define rules that will feed the Rules Engine Decision Support System 8.12 DSS Rules Engine It contains the rules base, the rules dictionary, engine Decision Support System 8.13 Dialog/User Interface Management It provides the communication between the user and the decision support system; specifies the protocol used for communication and the format of the alerts/operators commands Decision Support System 8.14 Gateway Manager The main objective of the Gateway Manager SE is to create a framework which can be integrated in any Gateway server and increase the interoperability and intelligence of the system, decreasing the heavy information and processing load of the C2 and improving the QoS 11/09/2013 Page 89 of 96

Gateway application 8.15 Data Integration It concerns the effective integration of all data types, sources, sensor families etc providing interoperability solutions. It includes M2M communication and data security by authentication mechanisms, ensuring that no malicious injection and unauthorized sources are being involved. Gateway application 8.16 Data Management and Prioritization It concerns estimations for the prioritization and combination of the processed outputs. Gateway application 8.17 Security Manager The Security Manager ensures information protection, in scenarios envisaged by SafeCity, by controlling all issues related to secure data transmission and establishment of a device trust relationship scheme at different levels of the SafeCity protocol stack. The SM was composed of two parts; one that is running on the IoT Gateway and is responsible for setting up and handling a multithreaded socket server and another that was running on 11/09/2013 Page 90 of 96

deployed Sensor Adapters and ad-hoc nodes that were trying to safely connect (through a secure socket) to the GT 8.18 Settings Configuration It provides local computer and group policy-based configuration and analysis of security settings. This security configuration engine also supports the creation of security policy files. In the context of both Stockholm and Madrid PoCs, the SC enabler was responsible for configuring the level of security to be applied based on the capabilities of the hosting device and the sensitivity of the transmitted data. 8.19 Data Handling It deals with the secure exchange of information between networking IoT devices and gateways. Secure data handling is the key to ensuring the integrity of transmitted data since it addresses concerns related to confidentiality, security, and preservation/retention of produced data. The DH enabler was responsible for actually transmitting (in a secure way) all necessary data over the underlying network transport protocol. 8.20 Sensor Frontend The core of the Sensor Adapter software encapsulation internal components and other SEs. Communicates northbound to the Security Manager and southbound to the Simple Sensor SE. Sensor Adapter's internal management and external sensor data communication. 11/09/2013 Page 91 of 96

8.21 Simple Sensor Abstraction of different sensor types. It is designed for sensors that send their measurements in certain fixed rate without specific request and/or are of type that cannot be requested to send the measurements. This SE provides services to Sensor Frontend SE. 8.22 Serial Communication Used for communication towards a sensor connected via serial port. It contains necessary functionalities to initialise, configure, and use the serial port the sensor is connected. This SE provides communication means towards the sensor. 8.23 Coarse Video Analytics It enables video pre-processing for video content filtering and selective video data streaming at the Gateway, which ideally is performed in real-time at low processing and memory capabilities hardware, in optimally the compressed domain (finally it performed in the pixel domain). None 8.24 Video Analytics 11/09/2013 Page 92 of 96

It enables a rich set of automated or semi-automated (when required) image/video processing and analysis algorithms, in the uncompressed video (pixel) domain Criminal identification applications 8.25 Visual Descriptors Extraction It extracts, through video analysis and feature extraction algorithms in the pixel domain, visual descriptors from previously segmented spatial, temporal or spatio-temporal regions in video data. The purpose is to efficiently describe visual primitives from video data with low-level visual metadata (the ones introduced by the MPEG-7 standard) that will further serve as input to either the Pattern Recognition SE modelling phase (during training assuming that the required amount of training video data is available) or the Detection SE matching phase. Criminal identification applications 8.26 Pattern Recognition Classification (SVM, LVQ, etc.) algorithms mainly compose this SE, receiving as input visual feature vectors (single or combined), to produce object, behavior or primitive event models during the training phase of supervised learning algorithms using training video data from prior threatening events. The modelling phase generates behavioural/object models and detected patterns in visual data from previous similar public safety threat events in archived video feeds. Criminal identification applications 8.27 Detection 11/09/2013 Page 93 of 96

It detects and identifies during the testing phase of classification algorithms the situation hint (object, primitive event or behavior) during the overall process of situation insights generation, based on results produced from the Video Analytics SE and the Visual Descriptors Extraction SE and models already stored and created by the Pattern Recognition SE. The detection phase is assisted by behavioral/object models and detected patterns in visual data to identify the exact detected object or primitive event/behavior in the currently processed video feed Criminal identification applications 8.28 Single Tracker It extracts the 3D position of people in a video stream None 8.29 Tracks Prediction It provides a functionality to predict people tracks in the areas not covered by the video camera network. None 8.30 Behaviour Simulation It provides a functionality to anticipate people actions after an incident (simulation of what if scenarios). None 11/09/2013 Page 94 of 96

8.31 3D Display It proposes an MMI displaying a 3D map and the position of persons who are present in the area. Real-time positioning based on video analysis and artificial intelligence for decision support 8.32 Tracks Management Tracks Management SE provides the 3D display content by managing the fusion of the 3D positions/tracks of people detected in all video streams with the predicted tracks of people present in the areas not covered by the video camera network. It will also use the computation of behaviour simulations in case what if scenarios are triggered. None 8.33 External Interface External Interface SE handles the communication with the other SafeCity applications (Receive and send data to Video Analysis, Rule Based Engine, data fusion and decision service support applications) None 11/09/2013 Page 95 of 96

European Commission FUTURE INTERNET Brussels 2013 Pages: 96 LEGAL NOTICE By the European Commission, Communications Networks, Content & Technology Directorate-General. Neither the European Commission nor any person acting on its behalf is responsible for the use which might be made of the information contained in the present publication. The European Commission is not responsible for the external web sites referred to in the present publication. The views expressed in this publication are those of the authors and do not necessarily reflect the official European Commission s view on the subject. European Union, 2013 Reproduction is authorised provided the source is acknowledged. 11/09/2013 Page 96 of 96